<![CDATA[[SecurityRatty] tag: partial]]> http://securityratty.com/tag/partial Wed, 25 Jun 2008 15:50:57 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[Is That a Coffee Table or a Munition?]]> http://securityratty.com/article/bcc3ebc100f5b51c419148587e587e92 http://securityratty.com/article/bcc3ebc100f5b51c419148587e587e92 One of the standard software security prescriptions for the SDLC is to data classification and enforce least privilege. From a security perspective this sounds fantastic, especially on a whiteboard. When the rubber meets the real world road, things often turn out slightly different. 


It turns out that it is hard to conduct business with excessive granularity.
D3408BB1

Here is an article from The Economist on the challenges of space technology, commercialization and information sharing. This is widely applicable to corporate information security policies:

Gravity is not the main obstacle for America’s space business. Government is

IN THE spring of 2006 Robert Bigelow needed to take a stand on a trip to Russia to keep a satellite off the floor. The stand was made of aluminium. It had a circular base and legs. It was, says the entrepreneur and head of Bigelow Aerospace in Nevada, “indistinguishable from a common coffee table”. Nonetheless, the American authorities told Mr Bigelow that this coffee table was part of a satellite assembly and so counted as a munition. During the trip it would have to be guarded by two security officers at all times.


Exporting technology has always presented a dilemma for America. The country leads the world in most technologies and some of these give it a military advantage. If export rules are too lax, foreign powers will be able to put American technology in their systems, or copy it. But if the rules are too tight, then it will stifle the industries that depend upon sales to create the next generation of technology.

It is a difficult balance to strike and critics charge that America has erred on the side of stifling. They claim that overly strict export controls have so damaged the space industry that America’s national security is now threatened by its dwindling leadership in space technology. The system, they complain, fails to distinguish between militarily sensitive hardware that should be controlled and widely available commercial technologies, such as lithium-ion batteries and solar cells. The zealous application of the export rules is the American space industry’s biggest handicap.


Read the whole thing its fascinating. So what started off as well intentioned asset protection eventually compromised the most important asset of all - strategic advantage.

So what's a better model? I am partial to think about these sorts of problems as free trade agreements. Each integration point should have a set of policies, and enforcement mechanisms that also include compensating transactions.

For example, did you know that in the US you can buy companies that trade on other exchanges through ADRs? You buy the ADR of say a French Telco which trades on a European exchange only you buy the ADR on the NYSE or Nasdaq. Then the French Telco issues you a dividend because you are a shareholder, but the French government withholds the dividend for foreign owners. Yet because there is a free trade agreement between the two countries, the US lets you write off the unreceived portion of the dividend on your taxes. (this may or may not be the case in US-France just an example). Anyway, its not a silver bullet but its an interesting strategy.

]]> Tue, 25 Nov 2008 09:40:20 +0000 coffee table technology american technology free trade agreement trade space technology french telco issues common coffee table information security policies Is That a Coffee Table or a Munition? <![CDATA[Download: H1 2008 Desktop OS Vendor Report - Vulnerabilities and Days-of-Risk]]> http://securityratty.com/article/3dadf3c9dc033dffce216e9be647ff0d http://securityratty.com/article/3dadf3c9dc033dffce216e9be647ff0d This report looks at all of the vulnerabilities fixed by Apple, Microsoft, Red Hat and Ubuntu during the first half of 2008. At the vendor level, the report examines all vulnerabilities as well as Days of Risk (DoR) associated with those vulnerabilities. The report further drills down to examine just those issues affecting the commonly installed desktop operating system components.

The key findings for 1H08:
  • The four vendors fixed a total 585 vulnerabilities in 1H08. 26.8% affected multiple vendors and of those, only 8 were fixed on the same day – the rest had an average 35 day delay between the first available fix and the last available fix..
  • Microsoft had the lowest average Days of Risk for all vulnerabilities fixed at 24.22 days, with the next closest vendor at 72 days.
  • For desktop OS vulnerabilities, Windows Vista had the fewest vulnerabilities in 1H08 at 21. The next lowest number was Windows XP SP2 at 26.
  • Windows Vista customers experienced full or partial mitigation for 46% of the 26 vulnerabilities affecting Windows XP SP2 in 1H08, but also experienced one additional vulnerability in new code.

In addition to these measurements for the vendors and products, the body of the report also provides weighted analysis which provides a lesser consideration for lower severity issues. Please read the full report for details.

]]> Mon, 27 Oct 2008 04:00:00 +0000 vulnerabilities vulnerabilities fixed report windows vista customers windows vista fixed days windows average days Download: H1 2008 Desktop OS Vendor Report - Vulnerabilities and Days-of-Risk <![CDATA[Partial Disclosure - The Good, Bad, and Ugly]]> http://securityratty.com/article/0f6f787360fca21b1b1d9b08ece3672b http://securityratty.com/article/0f6f787360fca21b1b1d9b08ece3672b There is apparently a bit of fear going around information security circles that the next big trend in the disclosure wars is going to be “Partial Disclosure”. In the past, the vulnerability research community has embraced the concepts of “Full Disclosure” and/or “Non-Disclosure”. Once those concepts had been sufficiently played out, the general consensus was to move towards “Responsible Disclosure” whereby the security researcher responsibly discloses the discovered vulnerability to the vendor and works in a cooperative fashion in an effort to minimize the risk to the general user populous. This has worked well in the vast majority of cases that I have had the pleasure of managing the disclosure process.

Partial Disclosure - The Good

The responsible disclosure process tends to break down in rare occasions where the vendor doesn’t want to fix the issue. When this occurs, the researcher is put into a difficult position whereby full disclosure could put users’ systems at high risk of compromise. The other case where partial disclosure becomes an alternative is when the researcher has discovered a design flaw in a protocol or underlying multiple vendor component. Examples of this case include the DNS flaws published this past summer by Dan Kaminsky and the TCP denial of service condition discovered by Robert E. Lee and Jack Louis that is currently in the disclosure process. When the flaw affects a very large number of vendors and the actual problem is located within the underlying protocols that support the communications of the Internet as a whole, one possible solution is to follow a partial disclosure model where phasing the details to the general public can be used to encourage adoption and creation of patches throughout the enormous target audience.

Partial Disclosure - The Bad

What is driving the fear surrounding partial disclosure is the potential for abuse. When a major flaw is partially disclosed, a number of potential issues may occur. First and foremost, the further along the partial disclosure path we are, the more details will be released to the public, and the higher the probability that someone (either good or bad intentioned) will figure out the exploit and disclose the details. Second, when partially disclosing, the vendor’s hand is being forced into a situation that could speed up fixes, reduce testing, and cause ripple problems elsewhere within the infrastructure. It is difficult enough to dance the fine time line when doing responsible disclosure, but if we are escalated to the point of partial disclosure, additional fuel is added to the fire.

The Ugly

The real ugly part of partial disclosure is when we add to the equation the ability to spread fear, uncertainty, and doubt into the normal user community. It is generally well accepted that FUD can be used to drive additional revenue. If it is possible to increase the perceived magnitude of the “problem” that your product or service solves, it is possible to directly impact the demand for that product or service. That is the major fear imposed by the growing trend of partial disclosure. By releasing just enough information to trigger wide scale speculation into the flaw, it is possible to create buzz and garner media attention resulting in a lot of speculation and very little hard facts around the issue. The potential for abuse by the security industry at large is enormous.

The Fix

Some have suggested a group of security researchers be convened to vet the requirement of partial disclosure and to allow for independent peer review of any security research that requires the partial disclosure process. This suggestion leaves questions regarding who would stand on this group and who would be impartial enough to ensure that the right thing was always done regardless of profit potential. It also leaves open the opportunity for member researchers to utilize the information gathered during the vetting process to position themselves to profit from the data upon release. It might be wiser to rely on a higher level authority or government entity to manage this process and use the services of security researchers as required for subject matter expertise. While a group of this type wouldn’t ensure that all partial disclosure is appropriate, it would hopefully limit the potential for abuse and the ever present chance that people try to profit from the FUD that surrounds the current partial disclosure process.

]]> Tue, 21 Oct 2008 09:58:00 +0000 partial disclosure process responsible disclosure process partial disclosure process disclosure partial disclosure model responsible disclosure partial disclosure path disclosure andor non-disclosure Partial Disclosure - The Good, Bad, and Ugly <![CDATA[Use Gmail to fight spam]]> http://securityratty.com/article/a7b566267647afe811ef831bea10add1 http://securityratty.com/article/a7b566267647afe811ef831bea10add1 Sun, 12 Oct 2008 20:00:00 +0000 inboxes planet-wide spam favorite method gmail mailwasher tools spamassassin bane partial Use Gmail to fight spam <![CDATA[PC Webcams Might Be Abused Through Clickjacking To Silently Spy On Users]]> http://securityratty.com/article/f402048be80afa0d975aa76a5393c0ed http://securityratty.com/article/f402048be80afa0d975aa76a5393c0ed Tue, 07 Oct 2008 19:32:08 +0000 israeli security researcher javascript game pcs video cam months partial disclosure game demo secretly spy cross-platform attackthreat surveillance zombie PC Webcams Might Be Abused Through Clickjacking To Silently Spy On Users <![CDATA[Is an incorrectly implemented security program better than a non-existent one ?]]> http://securityratty.com/article/5893399324f415d7cb19e54c1340401b http://securityratty.com/article/5893399324f415d7cb19e54c1340401b carefully on this one. Think long term. Think about implementation hurdles, think about project documentation.

The answer to this IMHO is a big "DEPENDS".

To explain:

Imagine you're working in a company that has no security controls in place - and is in desperate need of getting a security program impemented. They hire a new CISO to make sure their physical and logical controls are in place, network and applications are secured appropriately and their incident management and forensics capabilities are upto date. At this point the CISO clearly knows that he needs to create and implement a number of programs and hires a bunch of people to perform and manage a series of tasks. Till this point, things are going smoothly. Everyone understands the need, and is working towards meeting a common goal. The program is not in place yet, but people know and understand the urgency need to act immediately. The CISO's risk radar has a list of projects ranked by priority and everone begins to tackle them.

Now consider the scenario when certain security programs are not done right - say, a few of the high risk applications are not considered in the initial risk matrix or there are certain business units that have been granted an 'exception'to the process that is being put in place, with the most common excuses of:

1. This is a pilot
2. We will get to this in the next phase
3. The group has a number of high profile clients who don't want it implemented right now
4. <plug your own excuse here>

Well - initially, everyone is completely aware that they have more issues to remediate and and have honest intentions to fix that too, once the pilot and
PoC is well established and in place. But then things change. Leaders change. Managers change. People's roles change. What doesn't, is the documentation regarding the project. But documents usually tend to highlight what the project does, not what it doesn't do. Nobody seems to remember there are additional tasks that need to get completed. People take a quick look at documents detailing what was done in the program and begin to assume that it is well established, completely ignoring the fact that a very important Phase 2 still needs to be in place. A false sense of security is now well in place... and life goes on.

Till you get hacked.

..and then a forensics team attempts to determine the cause. A new CISO comes in, reviews the existing program, decides it is too complex and structureless and decides to do away with it entirely and create a new security program.. and the cycle continues.

The moral of the story: When you have no security program - be very careful while diligently working to get one in place

But when you have a partial one, be extremely careful and don't leave any loose ends while getting it completely and correctly put in place.


On a lighter note - here's an email I received from a school I was doing some courses from ..

Beautiful !! Here is your PIN (username). But we will not give you your password over email. I was sooo impressed when I got that! - Could it be that schools and universities are finally waking up and trying to understand security ? No more SSNs as IDs ? No more default 'password' passwords ? This was great. I followed the procedure outlined to receive a new password - it asked for my name, DOB and email.. and then .. I receive this:




For those who cannot see the image:


the email says:

blah blah blah blah blah blah..
your PIN:
your password: password1234

blah blah blah blah blah blah]]> Wed, 03 Sep 2008 12:02:00 +0000 security security program program security controls change leaders change programs security programs roles change Is an incorrectly implemented security program better than a non-existent one ? <![CDATA[EPTS: Proposed Event Processing Definitions, September 20, 2006]]> http://securityratty.com/article/c90d53785950324b36b55747a92766da http://securityratty.com/article/c90d53785950324b36b55747a92766da For interested readers, here are the event processing definitions we provided to the (future) EPTS working group on September 20, 2006, coordinated (edited) by David Luckham and Roy Schulte;

adaptive process management (n.) an element of resource and business process management, adaptive search and event processing. Sometimes referred to as “Level 4” event processing or process refinement.

application concept (n.) a definition of a set of properties that represent the data fields of an application entity. An application concept can describe relationships among themselves. For example, an order concept might have a parent/child relationship with an item concept. A department concept might be related to a purchase requisition concept based on the shared property, department_id. Application concepts can include an application state model.

application state modeler (n.) a UML-compliant application that allows you to model the life cycle of a concept instance — that is, for each instance of a given concept, you can define which states it will pass through and how it will transition from state to state. States have entry actions, exit actions, and conditions, providing precision control over the behavior of an event processing agent. Transitions between states also may have rules. Multiple types of states and transitions maximize the versatility and power of the application state modeler.

derived event (n.) an event that is created as a result of processing one or more other events.

complex event (n.) an event that is a situation-entity abstraction of two or more simple, derived or other complex events.

complex event processing (n.) CEP is a technology for extracting information from message-based systems. CEP is primarily an event processing concept that deals with the task of processing multiple events from an event cloud with the goal of identifying the meaningful events within the event cloud. CEP employs techniques such as detection of complex patterns of many events, event correlation and abstraction, event hierarchies, and relationships between events such as causality, membership, and timing, and event-driven processes.

event (n.) a instance of an event definition. It is an immutable object that represents a business activity that happened at a single point in time. Just as one cannot change the fact that a given activity occurred, one cannot change an event — events are immutable.

event aggregation (n.) the aggregation of simple, derived or complex events into higher levels of event abstractions.

event definition (n.) a set of properties related to a given activity that represents an important or interesting change of state in a human, system or computational activity. An event definition includes event properties such as event priority, event time to live (TTL), and a description of the payload, which is comprehensive information related to the activity that occurred. Events expire when the TTL has elapsed, unless the event processing agent has instructions to consume them prior to that time.

event channel (n.) a communications channel in which events are transmitted from event source to event receivers, typically received as electronic messages. Each channel can have multiple destination and. events can be configured to transmit to a default destination. JMS is an example of an event channel.

event cloud (n.) a partially ordered set of events (poset), either bounded or unbounded, where the partial orderings are imposed by the causal, timing and other relationships between the events. Typically an event cloud is created by the events produced by one or more distributed systems. An event cloud may contain many event types, event streams and event channels. The difference between a cloud and a stream is that there is no event relationship that totally orders the events in a cloud.

event-driven (n.) the behavior of a human, system or computational entity whose execution or actuation is in response to events, typically received as electronic messages.

event-driven architecture (n.) an architectural style for distributed computing applications in which some of the components are event-driven and communicate by means of events.

event processing (n.) computing that performs operations on events, including modifying, creating and destroying events.

event-object (n.) an software object that represents an event, generally for the purpose of computer processing, that exhibits both encapsulation, inheritance and polymorphism.

event prediction (n.) computational activity where the impact of events, complex events, and situations caused by events identified, including both opportunity or threat. Sometimes referred to as “Level 2” event processing, impact assessment or predictive analytics.

event pre-processing (n.) computational activity where events are cleansed or normalized to produce semantically understandable data. Sometimes referred to as “Level 0” event processing.

event processing (n.) computational activities on events dealing with the association, correlation, and combination of event data and information from single and multiple event sources to achieve refined identity and situation estimates for observed event objects, and to achieve complete and timely assessments of opportunities, threats, and their significance. Event processing is characterized by continuous refinements of event estimates and assessments and by evaluation of the need for additional sources, or modification of the process itself, to achieve improved results.

event processing agent (n.) an EPA is a computational entity that performs event processing.

event processing network (n.) a set of event processing agents and a set of event channels connecting them.

event properties (n.) data representation of an event, typically by name-value pairs of type string, integer, real, boolean or a complex data type.

event refinement (n.) filter, identify and track events & make initial processing decisions based on association, correlation and state estimation. Sometimes referred to as “Level 1” event, or event-object, track and trace.

event stream (n.) a time-ordered sequence of events. An event stream may be bounded by a certain time interval or other contextual dimension (content, space, source, certainty), or be open ended and unbounded.

event stream processing (n.) a time-ordered sequence of events. An event stream may be bounded by a certain time interval or other contextual dimension (content, space, source, certainty), or be open ended and unbounded.

rule (n.) defines what triggers unusual, suspicious, problematic, or advantageous activity within an event processing agent and what the EPA does when it discovers these types of activities. Rules execute actions based on certain conditions on events, instances, or a combination of both. A rule includes a group of condition-rule statements and action-rule statements. The condition statements instruct the EPA what to look for in events, and action statements instruct the EPA how to respond when conditions are met. If all the conditions in a rule are satisfied by events or instances or both, the EPA fires the actions. The action might be to execute tasks, create an event instance, modify property values in an event instance, create and send an event, or something else.

rules engine (n.) a type of event processing agent that uses a declarative programming model to process events. Formally described as “an abstract structure that describes a formal language precisely, i.e., a set of rules that mathematically delineates a (usually infinite) set of finite-length strings over a (usually finite) alphabet“. Informally, it can be any system that uses rules, in any form, that can be applied to data to produce outcomes.

rule language (n.) is an artificial language that is used to control the behavior of an event processing agent. Rules languages, like human languages, have syntactic and semantic rules to define meaning.

situation refinement (n.) identify situations, or complex events, based on event clustering, event-event relationships and relationship analysis and context. Sometimes referred to as “Level 2” event processing.

simple event (n.) an event that is not an abstraction or composition of other events.

virtual event (n.) an event that is imagined, modeled or simulated.

Note:  The Emerging Technologies Engineering Team at TIBCO Software significantly contributed to these event processing terms and definitions.

]]> Thu, 21 Aug 2008 01:47:11 +0000 event event-object business process management process event correlation process refinement simple simple event process events EPTS: Proposed Event Processing Definitions, September 20, 2006 <![CDATA[Information Security and Liabilities]]> http://securityratty.com/article/58f3a18307a0d05fd6b06c9da81ce4e3 http://securityratty.com/article/58f3a18307a0d05fd6b06c9da81ce4e3 Guardian last Thursday, I talk about information security and liabilities:
Last summer, the House of Lords Science and Technology Committee issued a report on "Personal Internet Security." I was invited to give testimony for that report, and one of my recommendations was that software vendors be held liable when they are at fault. Their final report included that recommendation. The government rejected the recommendations in that report last autumn, and last week the committee issued a report on their follow-up inquiry, which still recommends software liabilities. Good for them. I'm not implying that liabilities are easy, or that all the liability for security vulnerabilities should fall on the vendor. But the courts are good at partial liability. Any automobile liability suit has many potential responsible parties: the car, the driver, the road, the weather, possibly another driver and another car, and so on. Similarly, a computer failure has several parties who may be partially responsible: the software vendor, the computer vendor, the network vendor, the user, possibly another hacker, and so on. But we're never going to get there until we start. Software liability is the market force that will incentivise companies to improve their software quality – and everyone's security.
]]> Wed, 23 Jul 2008 11:09:21 +0000 security information security liabilities liability software liability computer vendor vendor report automobile liability suit Information Security and Liabilities <![CDATA[A Brief Introduction to Blackboard Architectures]]> http://securityratty.com/article/22d6319038389d6b246f89f8c8e84bc2 http://securityratty.com/article/22d6319038389d6b246f89f8c8e84bc2 A blackboard architecture is a distributed computing architecture where distributed applications, modelled as intelligent agents, share a common data structure called the “blackboard”  and a scheduling/control process.  The blackboard can be either centeralized or distrbuted, depending on the requirements and constraints of the application(s).

To solve a complex problem in the blackboard-style, the intelligent agents cooperate as functional specialists, observing updates to the blackboard and self-actualizing in an event driven process) when there is new information to process.  Agents continually update the blackboard with partial solutions when the agents capabilities for processing match the state of the blackboard. 

The blackboard architecture is a distributed computing model for a metaphor describing how people work together to collaboratively solve a problem around a blackboard (whiteboard in todays lingo).   For example, one person is standing at the whiteboard working on a solution while three other people are sitting (or standing) around watching.   One of the observers sees new information on the whiteboard, thinks of how he (or she) can contribute, and then jumps up, takes the whiteboard marker from the person working, and adds to the solution.  This process is repeated in various scenarios.  

The blackboard architecture can be very effective in solving complex distributed computing problems, including event processing problems; however, scheduling the self-actuating agents can be a key challenge.   Another core challenge is how to model and manage the blackboard itself, especially in distributed blackboard architectures.  

John McManus, former CTO of NASA, wrote an excellent PhD dissertation in 1992,  Design and Analysis Techniques for Concurrent Blackboard Systems, at the College of William and Mary, addressing challenges in BB systems.

The table below lists two books that focus on blackboard architecture:

Date Editor(s) Publisher ISBN Title
1989 V. Jagannathan et al Academic Press 0123799406 Blackboard Architectures and Applications
1988 Robert Engelmore and Tony Morgan Addison-Wesley 0201174316 Blackboard Systems

One of the thought leaders in blackboard architecture is Daniel D. Corkill a professor at the University of Massachusetts Amherst. 

Blackboard architecture is relevant to the field of event processing, and in particular complex event processing.   I will go into more details in future blog posts on this topic, including how blackboard architectures relate to grid computing, distributed object caching (of the blackboard), and CEP.

]]> Sun, 20 Jul 2008 09:57:12 +0000 blackboard architecture blackboard architecture isrelevant blackboard blackboard architectures architecture systems concurrent blackboard systems blackboard systems complex problemin A Brief Introduction to Blackboard Architectures <![CDATA[A Question of Integrity: To MD5 or Not to MD5]]> http://securityratty.com/article/e51d112f447a686d685e24eda7ede3bf http://securityratty.com/article/e51d112f447a686d685e24eda7ede3bf Cloud Storage offers pay per drink off-site storage. Data to be saved is shuffled from the customer to the Cloud Storage Provider by the network. This all works wonderfully most of the time, what you upload is what you get back later. But what happens where the gremlins strike and what you send is not what is received?

This happened recently to some Amazon S3 customers. There were complaints in the AWS forums about ‘S3 Corruption’. The first post in the forum was recorded at Jun 22, 2008 5:05 PM PDT (although in subsequent posts some people reported emailing Amazon prior to this):

we are having some serious S3 issues.

all data we store on S3 has gone through the same code path for months. starting a couple days ago a small percentage of the objects we are retrieving are not checksumming to the correct values. we hash and store objects by checksum and rehash the objects when we retrieve to ensure there is no data corruption. all the objects we’re having issues with were uploaded at approximately the same time period a few days ago.

we’ve stored 10’s of millions of objects in S3 and never encountered such problems. please let me know ASAP if you have any idea what could be going on here. thanks.

Amazon responded 6 minutes later (!) and started investigating. To troubleshoot they asked customers to email aws@amazon.com with the ‘Bucket-Name and few keys that you believe are having issues’.

Others weighed in reporting similar problems. Amazon provided status updates and on Monday Jun 23rd at 6:10pm PDT, provided the following explanation:

We’ve isolated this issue to a single load balancer that was brought into service at 10:55pm PDT on Friday, 6/20. It was taken out of service at 11am PDT Sunday, 6/22. While it was in service it handled a small fraction of Amazon S3’s total requests in the US. Intermittently, under load, it was corrupting single bytes in the byte stream. When the requests reached Amazon S3, if the Content-MD5 header was specified, Amazon S3 returned an error indicating the object did not match the MD5 supplied. When no MD5 is specified, we are unable to determine if transmission errors occurred, and Amazon S3 must assume that the object has been correctly transmitted. Based on our investigation with both internal and external customers, the small amount of traffic received by this particular load balancer, and the intermittent nature of the above issue on this one load balancer, this appears to have impacted a very small portion of PUTs during this time frame.

What are some of the takeaways?

  • If you are directly using the AWS S3 API, make sure to calculate and send MD5 checksums along with actual data. Check status return codes - an HTTP 400 error code means ’something went wrong’ - respond appropriately.
  • If you are relying on 3rd party tools to access S3, be sure to check with your software vendor that they are following the advice from Amazon to use MD5. If they are not then your data can get silently corrupted…
  • Downloads, aka HTTP GETs, can also be affected. The thread in the forum continues and questions are asked as to whether the corruption caused by the loadbalancer was affecting both incoming and outgoing traffic. The conclusion was yes. If you are hosting media on S3, and the browser is using partial GET requests (to download in chunks) then the corruption will not be automatically detectable.
  • If your business relies on Cloud Storage, are you prepared to wait a 36 hours for a resolution? This isn’t a swipe at Amazon, this is true for any provider. Check your SLA’s, check the trouble ticket resolution times, ask about availability of experts for troubleshooting etc.
  • Cloud Providers will increasingly need to instrument their services such that they can ‘early detect’ negative operational events. In this case, Amazon has stated plans to use better logging and analysis to automate detection of unusual error patterns (i.e. anomoly detection).
  • This incident - caused by an Amazon malfunctioning loadbalancer - did not make it onto the AWS status page at http://status.aws.amazon.com/. Taking Amazon at face value, this incident only affected a small number of transfers, relative to the total number of S3 transfers. But this begs the question, what level of outage or service problem needs to happen before Amazon will flag the issue on their status page? On a sidenote, based on the timestamps, 31 hours passed between the loadbalancer being taken out of service and Amazon providing the explanation on the forum.
  • When Amazon update their S3 API documentation, it would be useful to have entries in the S3 API index for ‘checksum’, ‘MD5′, ‘integrity’ and ‘corruption’.
  • Stepping back, will customers hold Cloud Service Providers to a higher standard than their own internal IT teams?

I’m sure there are more takeaways I didn’t cover. What say you?

###

Kudos for the heads-up on the S3 issue goes to my friend and colleague Jason Harper - network supremo and crypto-head. Thanks Jason!

]]> Wed, 25 Jun 2008 15:50:57 +0000 amazon prior amazon aws aws status page md5 load balancer single load balancer status data A Question of Integrity: To MD5 or Not to MD5