A gulf exists between California consumers' understanding of online rules and common business practices. For instance, Californians who shop online believe that privacy policies prohibit third-party information sharing. A majority of Californians believes that privacy policies create the right to require a website to delete personal information upon request, a general right to sue for damages, a right to be informed of security breaches, a right to assistance if identity theft occurs, and a right to access and correct data.

These findings show that California consumers overvalue the mere fact that a website has a privacy policy, and assume that websites carrying the label have strong, default rules to protect personal data. In a way, consumers interpret "privacy policy" as a quality seal that denotes adherence to some set of standards. Website operators have little incentive to correct this misperception, thus limiting the ability of the market to produce outcomes consistent with consumers' expectations. Drawing upon earlier work, we conclude that because the term "privacy policy" has taken on a specific meaning in the minds of consumers, its use should be limited to contexts where businesses provide a set of protections that meet consumers' expectations.

It's not just terrorism; it's any rare risk in the news. The big fear in Canada right now, following a particularly gruesome incident, is random decapitations on intercity buses. In the US, fears of school shootings are much greater than the actual risks. In the UK, it's child predators. And people all over the world mistakenly fear flying more than driving. But the very definition of news is something that hardly ever happens. If an incident is in the news, we shouldn't worry about it. It's when something is so common that its no longer news - car crashes, domestic violence - that we should worry. But that's not the way people think.

Psychologically, this makes sense. We are a species of storytellers. We have good imaginations and we respond more emotionally to stories than to data. We also judge the probability of something by how easy it is to imagine, so stories that are in the news feel more probable - and ominous - than stories that are not. As a result, we overreact to the rare risks we hear stories about, and fear specific plots more than general threats.

The problem with building security around specific targets and tactics is that its only effective if we happen to guess the plot correctly. If we spend billions defending the Underground and terrorists bomb a school instead, we've wasted our money. If we focus on the World Cup and terrorists attack Wimbledon, we've wasted our money.

It's this fetish-like focus on tactics that results in the security follies at airports. We ban guns and knives, and terrorists use box-cutters. We take away box-cutters and corkscrews, so they put explosives in their shoes. We screen shoes, so they use liquids. We take away liquids, and they're going to do something else. Or they'll ignore airplanes entirely and attack a school, church, theatre, stadium, shopping mall, airport terminal outside the security area, or any of the other places where people pack together tightly.

These are stupid games, so let's stop playing. Some high-profile targets deserve special attention and some tactics are worse than others. Airplanes are particularly important targets because they are national symbols and because a small bomb can kill everyone aboard. Seats of government are also symbolic, and therefore attractive, targets. But targets and tactics are interchangeable.

The following three things are true about terrorism. One, the number of potential terrorist targets is infinite. Two, the odds of the terrorists going after any one target is zero. And three, the cost to the terrorist of switching targets is zero.

We need to defend against the broad threat of terrorism, not against specific movie plots. Security is most effective when it doesn't require us to guess. We need to focus resources on intelligence and investigation: identifying terrorists, cutting off their funding and stopping them regardless of what their plans are. We need to focus resources on emergency response: lessening the impact of a terrorist attack, regardless of what it is. And we need to face the geopolitical consequences of our foreign policy.

In 2006, UK police arrested the liquid bombers not through diligent airport security, but through intelligence and investigation. It didn't matter what the bombers' target was. It didn't matter what their tactic was. They would have been arrested regardless. That's smart security. Now we confiscate liquids at airports, just in case another group happens to attack the exact same target in exactly the same way. That's just illogical.

This essay originally appeared in The Guardian. Nothing I haven't already said elsewhere.

It's unclear if this error is random or systemic. If it's random -- a small percentage of all votes are dropped -- then it is highly unlikely that this affected the outcome of any election. If it's systemic -- a small percentage of votes for a particular candidate are dropped -- then it is much more problematic.

Ohio is trying to sue:

Ohio Secretary of State Jennifer Brunner is seeking to recover millions of dollars her state spent on the touch-screen machines and is urging the state legislature to require optical scanners statewide instead.

In a lawsuit, Brunner charged on Aug. 6 that touch-screen machines made by the former Diebold Election Systems and bought by 11 Ohio counties "produce computer stoppages" or delays and are vulnerable to "hacking, tampering and other attacks." In all, 44 Ohio counties spent $83 million in 2006 on Diebold's touch screens.

In other news, election officials sometimes take voting machines home for the night.

My 2004 essay: "Why Election Technology is Hard."

For those of you who aren’t familiar with XSS Filter, a brief summary is that it is a client-side defense against reflected cross-site scripting (XSS) attacks.  It works by recognizing that reflected XSS attacks inject script into the string that the browser sends to the targeted web server.  If the server doesn’t neuter or strip out the injected script, it gets sent back to the browser and executed in the context of the target web page.  Bad things then happen.  At a high level, XSS Filter remembers the string that the browser sent to the server, and looks at the server’s response to see if any of the script was actually in that string.  If it was, then XSS Filter decides that it got there because it was injected by an XSS attack and blocks the script from executing.  The rest of the web page renders as usual.  This is a vastly oversimplified sketch of XSS Filter – for details, see the post by David Ross, inventor of XSS Filter on the Security Vulnerability Research and Defense blog.

So what does XSS Filter have to do with the SDL?  Well, for almost nine years, since XSS was first discovered at Microsoft, we’ve been trying to figure out effective ways to reduce vulnerability to XSS attacks.  Our focus has been on improving the ways that web page developers code their pages, and we’ve developed a lot of tools and techniques for making web content safer from XSS attacks and for detecting XSS vulnerabilities in live pages.  The SDL requires the use of many of these tools and techniques, and we’re sure we’ve prevented a lot of XSS vulnerabilities from being introduced into Microsoft web pages as a result. 

But while we identify (and the SDL requires) measures that allow developers to avoid classes of vulnerabilities, we also look to identify more sweeping solutions that can either 1) eliminate classes of vulnerabilities, 2) reduce their severity, or 3) reduce the likelihood of attacks being successful.  The process usually starts from deep understanding of a class of vulnerabilities and attacks, and then we broaden defenses from there.  In the case of XSS Filter, David’s years of work researching XSS led him to come up with an approach that blocks many of the most common vulnerabilities to reflected attacks found on the web today.  The solution is compatible with existing web pages (doesn’t “break the web”) and thus we were able to enable it by default for users of Internet Explorer 8.  Because it’s a client-side mitigation, it will help protect users from attacks even though the sites they visit may be vulnerable to XSS. 

Our work on buffer overrun defenses follows a somewhat similar pattern – we started by prescribing coding techniques, banning the use of some APIs, and building tools that detect coding constructs that look like buffer overruns.  As we gained a deeper understanding of how buffer overruns can be exploited, we enhanced the /GS compiler flag and added ASLR in a quest to cause classes of exploits to fail even if a buffer overrun remains.  We’re not yet close to eliminating the SDL requirements for use of tools and coding techniques, but the SDL also requires the use of the mitigations to reduce the severity of vulnerabilities that slip past.  Will we ever get to the point where the mitigating technologies are so strong that we can relax the coding requirements?  Maybe not, but we will continue to introduce technologies that reduce the chances of a successful attack.

Similarly, in the case of XSS, even after IE8 ships, the SDL will continue to require the use of safe web site coding practices and tools such as the Anti-XSS library both to protect users of browsers other than IE8 and to provide protection in recognition of the fact that XSS Filter is a mitigation or defense in depth rather than a complete solution.  But we’ll also be keeping our eyes open (and doing active research) in the quest for an even more effective defense – whether client or server side – that eliminates XSS for good.

This post is a little far afield from the normal content of the SDL blog, but I thought it was important to provide a picture of the role of security science and security research in defining SDL requirements and in making major improvements in software security.  You can read more about our work in security science in the Security Vulnerability Research and Defense blog.

IBM announced today that it was spending US$300 million to build out 13 data centers in 10 countries in 2008 - IBM refers to these sites as "Business Resilience service delivery centers". These centers will certainly help IBM deliver more of its traditional IT recovery services but they will also support the next generation of IT continuity services - repeatable, scalable, productize services such as online backup and virtual recovery.  These types of services don't require massive capital investment in an inventory of heterogeneous server and storage platforms, instead the service provider can focus its efforts on building a scalable pool of virtualized servers and shared storage built with industry standard components.

Online backup is an important service because it provides an affordable information protection service for small and medium businesses and it's even useful for enterprises as a means to backup PCs corporate-wide as well as small servers at remote locations. In addition to the $300 million that IBM is spending on its new resiliency centers, late in 2008, it acquired Arsenal Digital Solutions, one of the major players in online backup.

In addition to online backup, recovery services using software-based replication to a cloud infrastructure will also open up new opportunities. These services will provide a much a better recovery time and recovery point than tape-based services but won't cost nearly as much as custom services based on storage-based replication and dedicated hardware. The cost of these services is more than most small and medium, even some large enterprises can or are willing to pay for. SunGard was the first to announce such a productized service, Forrester expects all the traditional DR service providers to bring similar offerings to market over time.

These cloud-based service offerings are important for several other reasons, first, it could help stem the tide of enterprises who are just so fed up with the traditional disaster recovery services model that they take DR back in house, second, it could convince, more medium size businesses that they can afford more advanced IT continuity solutions and lastly, it will help protect their market against new competitors who can simply partner with cloud providers such as Amazon S3 and Google to offer similar services.

IBM is not only using its expansion and acquisitions to stay competitive, it's also also hoping that customers will recognize the value of IBM expertise, process and best practices in BC.

What do you think? Does the reputation and expertise of BC and IT Continuity service providers like IBM and SunGard critical in your decision-making or can new players enter the market? Do these lower cost services that offer better RTO and RPO renew your interest in service providers or do you still plan to keep DR in-house?

I welcome your thoughts.

From the Confidential Memo Prepared for the MBTA which was publicly disclosed by the MBTA is court filing:

This seems to break all the rules of integrity of sensitive data storage. How could someone store money on a magnetic stripe in 2008 and not store an identifier that references the account in a central database?

The tickets do have a unique identifier generated when the card is initially purchased so a fraud detection system could be in place or is planned. But this would require tracking the value on the ticket or the usage of the ticket centrally so it isn’t clear why the value is stored on the card in the first place.

There are so many question about the security of this public system.  Fraud costs the Massachusetts taxpayer money and refitting an insecure, ill-designed system costs the Massachusetts taxpayer money. [Disclosure: I am a Massachusetts taxpayer.]

It should be a requirement that the current system or the (hopefully) upgraded system be tested by an independent organization that specializes in cryptosystems.  If the independent testing uncovers vulnerabilities, they need to be fixed before the system is fielded. Then the system should be retested to verify the fixes.  Once the system is deemed secure by an independent organization, a summary of the test document should be published for public inspection.  It should include the types of testing conducted and the results.

The public trust requires inspection of taxpayer funded projects to make sure they meet acceptible standards and vendors held responsible for deficiencies.  Projects that use computers and software should not get a free pass. It will be interesting to see if the CharlieTicket system is ever held up to public scrutiny.

From the Confidential Memo Prepared for the MBTA which was publicly disclosed by the MBTA is court filing:

This seems to break all the rules of integrity of sensitive data storage. How could someone store money on a magnetic stripe in 2008 and not store an identifier that references the account in a central database?

The tickets do have a unique identifier generated when the card is initially purchased so a fraud detection system could be in place or is planned. But this would require tracking the value on the ticket or the usage of the ticket centrally so it isn’t clear why the value is stored on the card in the first place.

There are so many question about the security of this public system. Fraud costs the Massachusetts taxpayer money and refitting an insecure, ill-designed system costs the Massachusetts taxpayer money. [Disclosure: I am a Massachusetts taxpayer.]

It should be a requirement that the current system or the (hopefully) upgraded system be tested by an independent organization that specializes in cryptosystems. If the independent testing uncovers vulnerabilities, they need to be fixed before the system is fielded. Then the system should be retested to verify the fixes. Once the system is deemed secure by an independent organization, a summary of the test document should be published for public inspection. It should include the types of testing conducted and the results.

The public trust requires inspection of taxpayer funded projects to make sure they meet acceptible standards and vendors held responsible for deficiencies. Projects that use computers and software should not get a free pass. It will be interesting to see if the CharlieTicket system is ever held up to public scrutiny.

As a reference, you may have seen this briefing, one of many where I show these functional relationships, Mythbusters: Event Stream Processing Versus Complex Event Processing, from DEBS2007.  For example slide 23 shows the functional relationship between events, pre-processing, event tracking, situational detection, historical patterns (the output of BI tools, for example), visualization and business process management.

In Faithful Representation, Richard Veryard reminds his readers that the most challenging part is in the situation models (not the system integration).  Unfortunately, by accident, Richard incorrectly attributes Opher Etzion’s “first order situation model approximation” to both Opher and I in this quote from Richard’s post, “a simple situation model of complex events, in which events (including derived, composite and complex events) represent the “situation”.   

Actually, that simple situation model above is Opher’s, not mine.  I have offered a more general and comprehensive (first draft) situation model, in A Simple Situation Model for Complex Events based on a cognitive situation model used by researchers at the University of Notre Dame.  I do not believe that complex events and situations can be modelled accurately using Opher’s simple model of derived, composite and complex events.   This model is overly simple, in my opinion. to represent the vast majority of CEP classes of problems, perhaps explaining why Opher and I do not agree on the state-of-the-art of CEP.  Opher tends to view CEP as mostly an extension of active database technology where I see CEP as a technology that is much more closely aligned with the cognitive models represented in the art-and-science of multi-sensor data fusion (MSDF).  

Complex events represent situations, and situations must be accurately modelled if we are going to accurately detect them in real-time.  If your business cannot model a complex event (situation) then it does not matter what software you buy, how much money you spend, or what event processing and integration platform you use.   The models are hard.  The system integration is relatively easy.

The secret sauce is the situation and complex event models.

As mentioned here a few times, it does not matter how fast you process events in real-time, if your model is wrong, you just detect the wrong thing very fast.  This is very bad and quite dangerous.  You will make bad decisions fast.  You will waste time, money and resources.

This is why CEP benchmarks should be based on accuracy in situation detection, not in latency and other low-level performance metrics.   First, get the models right; then refine to detect faster, if speed is required.   What has happened in CEP to date, is that the models are so simple, they do not really detect complex events, they just process and act on simple events that are easy to model. 

In particular, SSL certificates (as used to identify https websites) might contain one of these weak keys — and so it would be possible for an attacker to successfully impersonate a secure website. Of course the attacker would need to persuade you to mistakenly visit their site — but it just so happens that one of the more devastating attacks on DNS has recently been discovered; so that’s not as unlikely as it must have seemed back in May.

Anyway, my old friend Ben Laurie (who is with Google these days) and I have been trawling the Internet to determine how many certificates there are containing these weak keys — and there’s a lot: around 1.5% of the certs we’ve examined.

But more of that another day! because earlier this week, Ben spotted that one of the weak certs was for Sun’s “OpenID” website, and that two more OpenID sites were weak as well (by weak we mean that a database lookup could reveal the private key!)

OpenID, for those who are unfamiliar with it, is a scheme for allowing you to prove your identity to site A (viz: provide your user name and password) and then use that identity on site B. There’s a queue of people offering the first bit, but rather less offering the second : because it means you rely on someone else’s due diligence in knowing who their users are — where “who” is a hard sort of thing to get your head around in an online environment.

The problem that Ben and I have identified (advisory here), is that an attacker can poison a DNS cache so it serves up the wrong IP address for openid.sun.com. Then, even if the victim is really cautious and uses https and checks the cert, their credentials can be phished. Thereafter, anyone who trusts Sun as an identity provider could be very disappointed. There’s other attacks as well, but you’ve probably got the general idea by now.

In principle Sun should make a replacement certificate and that should be it (and so they have — read Robin Wilton’s comments here). Except that they need to put the old certificate onto a Certificate Revocation List (CRL) because otherwise it will still be trusted from now until it expires (a fair while off). Sadly, many web browsers, and most of the OpenID codebases haven’t bothered with CRLs (or they don’t enable their checking by default so it’s as if it wasn’t there for most users).

One has to conclude that Sun (and the other two providers) should not be trusted by anyone for quite a while to come. But does that matter ? Since OpenID didn’t promise all that much anyway, does a serious flaw (which does require a certain amount of work to construct an attack) make any difference? At present this looks like the modern equivalent of a small earthquake in Chile.