The problem is that (Chris’ analysis is) completely impractical. I’ll take a recent, and fairly typical situation as an example. I was taking issue with the manner in which remote access was being provisioned for a third party vendor to connect to a system hosted by one of our European business units. To cut a long story short, it was not only a breach of policy but highly insecure. I wanted the access to be disconnected, the business unit director wanted my risk assessment. And he didn’t want to wait for it.

To quote Chris Hayes, spending time on working out the expected effectiveness of controls, over a given timeframe, as measured against a baseline level of force was not going to pacify an angry Italian fearful that my decision was going to cost him money. He wanted my explanation of the risk and more importantly, what I was going to offer as a solution to keep his business functioning

As Chris is someone who actually does this for a living in a large company, and this is typical of his actual day job, I really find Stuart’s “impractical” comment to be, um, misinformed.

Also, I think Stuart mistakes the purpose of a risk analysis.  The purpose of the risk analysis is not to force someone to be “secure”, but to provide knowledge for decision making.  Using it as a “hammer” to knock in the nail of your personal risk tolerance impairs efficiency and in the long run retards “security” as it creates political resentment.  Seriously, who cares if something might violate policy or not in a pre-implementation discussion?  Policies are not stone tablets handed down from on high, they are state-in-time codification of the data owners risk tolerance.  This risk tolerance changes sometimes, and that’s OK.

To that extent, I appreciate (and I’m sure Chris does, as well) that risk analysis does not create rationality in the data owner.  Someone who sees you as a speedbump on the route to progress they may not be ready to appreciate your point of view even if it is stated in the most rational manner possible.   But it’s worth noting (and Stuart’s example is indicative of this point) that risk analysis does not create rationality in the analyst, either.  If one is being so “security minded” as to ignore the risk tolerance of the business owner - we’re bound to get a reaction similar to that Stuart encountered.  In fact, a practical risk analysis like Chris performed on his blog, done in 30 minutes, should identify the critical point of disagreement between Stuart and the data owner (again, Stuart doesn’t own the data, the agitated Italian does).

But let’s stay rational and open to alternatives to what Chris offers.  Stuart states his approach to risk analysis as:

When I need to document a risk assessment I use a very simple form: list the threats, state the level of vulnerability, list the associated operational costs and potential revenue hits. High, medium, or low risk? Describe the controls and options. Write up who needs to do what, and how much of their time it’s going to take. Job done.

At first glance, I don’t think what Chris has done is any less efficient, and it provides greater insight (using Frequency and Capability instead of just ‘listing the threats’).  But what is key here is that Chris’ approach is consistent and defensible.  Less generous risk geeks and CSO’s I know would have no little difficulty with Stuart’s approach.  But to particularly answer Stuart’s main objection (impracticality) I would offer that with practice, Chris’ work is probably quicker and easier than Stuart’s described process as it eliminates much of the ambiguity an immature risk analysis creates - reducing the need for further discussion and arguments with data owners (regardless of disposition or nationality).

Finally the irony of Stuart’s post is that the reason he had this confrontation may in fact be because he was incapable of bringing a salient model for risk to the table, one that identified the factors that create risk and developed a defensible belief statement concerning risk.   We’ll never know if one would have helped him in this isolated instance, but I can tell you that in organizations like Chris’, good risk models and strong risk anlayses create operational efficiencies, reduce costs, and streamlines intra-departmental communications.

I am in Barcelona, Spain with Michael Howard and Adam Shostack at the TechEd EMEA: Developers Conference.

In addition to teaching and attending security sessions, we are in Barcelona to formally announce the launch of the SDL Optimization Model, SDL Pro Network and the Microsoft SDL Threat Modeling Tool Beta!   For those of you who are unaware of these initiatives here’s a description of each…

SDL Optimization Model: The SDL Optimization Model was created to facilitate gradual, consistent and cost-effective implementation of the SDL in development organizations outside of Microsoft. It allows development managers and IT policy-makers to assess the state of the security in development and create a vision and road map for reducing customer risk.

Specific objectives of the model include the following:

·         Enable organizations outside of Microsoft to create more secure and privacy-enhanced software by successfully implementing the SDL

·         Allow organizations to self-assess current software development security practices and create a strategy for gradual improvement

·         Provide SDL Pro Network service providers with a consistent and effective framework for providing SDL services

SDL Pro Network: The SDL Pro Network is a group of security service providers that specialize in application security and have substantial experience and expertise with the methodology and technologies of the Microsoft SDL. SDL Pro Network service providers will guide and support organizations in implementing the SDL into their environments.

The primary focus area for all members, both now and in the future, will be to deliver on the program’s commitment to make the SDL available outside Microsoft, specifically focusing on these issues:

·         Protecting the customer - Helping customers adopt the SDL or general secure coding practices.

·         Improving the SDL - Leveraging member knowledge to understand how the SDL is used by customers, what needs to be modified and what customer needs must be met in the future.

SDL Threat Modeling Tool Beta: The Microsoft SDL Threat Modeling Tool Beta allows for structured analysis, proactive mitigation and tracking of potential security and privacy issues in new and existing applications.  Microsoft developed the tool and we use it internally on many of our products. This tool offers a threat modeling methodology that any software architect can lead effectively — in contrast with other processes, which are more expert-dependent. A few quick notes about the features:

·         Automated guidance and feedback in drawing threat diagrams

·         Guided analysis of threats and mitigations based on the STRIDE taxonomy

·         Integration with bug-and issue-tracking systems like Visual Studio Team Foundation Server

To learn more about these, visit the SDL portal, http://www.microsoft.com/sdl.

By the way, if you are in Barcelona and want to stop by and chat, the session list is below:

SDL Theater Sessions:

·         Getting started with the new SDL Threat Modeling Tool                             

Adam Shostack, Theater 1, Tuesday, Nov. 11, 15:20 – 15:40

·         You could do that but it would be wrong – a discussion of pros/cons of threat mitigations

Michael Howard & Adam Shostack, Theater 1, Thursday, Nov. 13, 10:20 – 10:40

General Sessions:

·         DVP308  How I Learned to Stop Worrying and Love Threat Modeling      Nov. 12, 10:45 – 12:00

·         DVP309  How to Review Your Code and Test for Security Bugs                  Nov. 13, 3:15 – 4:30

·         DVP312  Top Ten Strategies to Security Your Code                                       Nov. 14, 10:45 – 12:00

One easy, inexpensive way to actually increase your effectiveness in 2009 is to, right now, make a quick review your risk management processes.  As you take a look at how you’re using risk in your organization, I’d ask you to make sure that those processes are providing value for the energy you’re spending.  If they’re not - if you’re not successfully using risk within security and with the other lines of business that you serve - then I’d like to invite you to  come take advantage of RMI’s public training session for 2008, held in Columbus Ohio on December 10-12.  >A brochure is here<.

For three days and $1,995 - you’ll get real answers to many of the commonly voiced frustrations RMI hears concerning risk & risk management.  Answers around measurement, application, communicating risk to other lines of business, heck, basic answers as to what risk is and how to get consistent, defensible values that actually mean something.

Not to mention - Strengthening your Risk Management processes increases your ability to manage risk, which reduces the amount of risk you actually face.

NEW TO THE PUBLIC STUFF!

I’m personally excited because this is the first time that our public training we’ll feature measurement “calibration” exercises and include excel tools to take home and use for quantitative FAIR analysis.  These are benefits we’ve only previously reserved for private client workshops.

I know that FAIR can help you and your organization, but as the sales guys always say, “don’t take my word for it”.  Here’s something we recently received (unsolicited) from the CSO of one of the 10 largest banks in the US, who has had several of his analysts receive this same basic training:

I would like to also add my deep appreciation for what FAIR and RMI has brought to (us) and how we go about the business of risk analysis. We have had some great conversations around risk with the lines of business that have ended very favorably for us.

More information can be found on RMI’s website here:  http://www.riskmanagementinsight.com/12_2008_training.html

Thanks.

Oh and tomorrow, we’ll talk a little bit about quantitative and qualitative risk.

We had an email recently from an observer "curious as to why the webcam that was inside the shop/bar is no longer there, or at least, functional". The email was from the Defense Threat Reduction Agency in the United States.

When we replied that it was simply a short term technical problem, we asked why on earth they could be interested in the comings and goings of a small Distillery off the West Coast of Scotland. Were there secret manoeuvres taking place in Loch Indaal, or even a threat of terrorists infiltrating the mainland via Islay?

The answer we received was even more surreal. Evidently the mission of the DTRA is to safeguard the US and its allies from weapons of mass destruction -chemical, biological, radiological, nuclear and high explosives. The department which contacted the Distillery deals with the implementation of the Chemical Weapons Convention, going to sites to verify treaty compliance. Funnily enough chemical weapon processes look very similar to the distilling process and as part of training there is a visit to a brewery for familiarization with reactors, batch processors and evaporators. As they said, it just goes to show how "tweaks" to the process flow or equipment, can create something very pleasant (whisky) or deadly (chemical weapons).

As they say: "In the post-Cold War environment, a unified, consistent approach to deterring, reducing and countering weapons of mass destruction is essential to maintaining our national security. Under DTRA, Department of Defense resources, expertise and capabilities are combined to ensure the United States remains ready and able to address the present and future WMD threat. We perform four essential functions to accomplish our mission: combat support, technology development, threat control and threat reduction. These functions form the basis for how we are organized and our daily activities. Together, they enable us to reduce the physical and psychological terror of weapons of mass destruction, thereby enhancing the security of the world's citizens. At the dawn of the 21st century, no other task is as challenging or demanding".

But that credit card weirdness is nothing compared to the one I’m about to describe.

Before we do that, let’s take a moment to discuss the design principle of failing securely. The general idea is that if a security mechanism fails, it should fail closed. If your firewall crashes, it should block all traffic, not allow all the packets through. If the power source to your card key system is interrupted, it shouldn’t unlock all the doors. If the connection between your application server and your LDAP directory is severed, subsequent authentication requests should be rejected, not approved. This is not rocket science.

So back to credit cards. I had a conversation last night with an old friend who related a bizarre situation they had encountered during the QA process for one of their web applications. One of their tests involved repeatedly attempting a credit card transaction using a canceled/expired American Express card. Here’s what they saw in their logs, paraphrased by me:

Attempt 1: Denied
Attempt 2: Denied
Attempt 3: Denied
 .
 .
 .
Attempt 49: Denied
Attempt 50: Denied
Attempt 51: Approved

What the…? Approved? That can’t be right. So they ran the test again. Every time, after multiple consecutive rejected attempts, the transaction would inexplicably go through. The threshold wasn’t always 50, but the general pattern was consistent — keep trying and eventually it’ll work. Clearly, this had to be a bug in the code, but a deep-dive into the guts of the application turned up nothing. The application security group got American Express on the phone to see if they had any insight on this odd behavior. The answer? They didn’t concede the failure was on their end, despite log data showing the successful authorization codes.

My gut instinct would be that the application requesting the transactions wasn’t failing securely (e.g. network connection to AmEx timed out, so just approve the transaction). But that explanation wouldn’t account for authorization codes coming back.

So what in the world is going on here? Why would the system behave this way? Is it by design? I can’t think of a single legitimate use case for failing open like this. If this is actually a design decision by the credit card companies, I have no doubt that someone in our audience knows the rest of the story.

Richard Stallman - the man that gave us GNU - doesn’t trust Cloud providers with his data and says you shouldn’t either.  Richard believes we should store our private data on our own computers using ‘free’ (as in freedom) software.  The ironic part for Richard is that a significant portion of the Cloud is powered by open source software which he indirectly created (think gcc).

Richard sees it as a question of control.  Control is important but it isn’t the only variable.  Rather, I see it as a question of control, competence and economics.

The quick rebuttal to Richards’ view is this: the average computer user is not as smart as you.  Control is not the same as competence.  Control is about exercising choice, not about requiring everyone in the world to develop sufficient skills to protect complex hardware and software systems (aka their computer) against ever increasing threats.

My view is that privacy is not ‘free’.  It comes at a cost.  Whether you run your own systems or rely on someone else to do it, there is a cost.  There is cost in designing and implementing mechanisms to support privacy.  Beyond upfront costs there are ongoing expenditures to ensure privacy is maintained e.g. maintaining access control lists, testing and applying security patches, data leakage prevention etc.  None of these things are ‘free’.

If we agree that privacy costs money then how much is your privacy worth?

Stop for a second - think of a number…  

Now did we all think of the same number?

The problem with a one size fits all approach to privacy is that we each place a different value on it.

Checking in on the EPIC site, I saw this:  

A new report from Pew Internet and American Life Project indicates that “cloud computing” applications, such as web-based email and other web apps, are raising new privacy concerns. The report Use of Cloud Computing: Applications and Services found that 69% of online Americans use webmail services, store data online, or use software programs such as word processing applications whose functionality is located on the web. At the same time, “users report high levels of concern when presented with scenarios in which companies may put their data to uses of which they may not be aware.” For example, 90% of respondents said that they “would be very concerned if the company at which their data were stored sold it to another party,” 80% say “they would be very concerned if companies used their photos or other data in marketing campaigns,” and 68% of “users of at least one of the six cloud applications say they would be very concerned if companies who provided these services analyzed their information and then displayed ads to them based on their actions.”

What does that tell us?

The average (American) Internet user finds Cloud services convenient but has concerns about how their privacy might be affected by Cloud providers actions (duh!).  The survey identifies a lack of awareness in how private data is used in some consumer based Cloud services (consistent with web advertising awareness surveys).  

Unfortunately, the results of this survey are not very actionable.  The survey doesn’t mention whether these are all ‘free’ Cloud services (we can only assume they are) or ask the respondents what their expectations of privacy are and how much they would be willing to pay for different privacy assurance levels. 

On a sidenote, respondents were not asked if they had actually read the privacy agreement for the services they signed up to.  But the providers know if they did or not…  Or at least, they have the data to figure it out.  At sign up time they can measure the time between displaying the privacy agreement and the user clicking ‘I accept’.  If its just a few seconds then its pretty obvious there was more scrolling than reading going on.  But I think we can probably guess the answer without the data ;-).

I believe we need to be able to link expectation of privacy with cost.

• How much are you willing to pay for privacy?  What level of privacy assurance do you need?
• How much is your Cloud Provider paying to protect your privacy today?  What privacy services could they reasonably offer if they had customers willing to pay?  How might this compare with how you manage your private data on your home computer today?

The cynical view is that we expect privacy but don’t want to pay for it.  Its a bit like uptime - there is a parallel universe out there, where internal IT departments allegedly meet their 99.999% uptime SLAs, but when Gmail goes down, the Sergey Brin witchcraft dolls come out.

From a provider perspective, the “cost” of privacy invariably gets bundled under that line item called ‘Information Security’.  And don’t be fooled, the cost of privacy in reality is more than the salary of the person employed to be the privacy advocate (if there is one).  If we can’t see how much our providers are spending on our privacy then how can we judge if they are spending enough?  And what is enough?  And what can I get if I’m willing to pay a little extra?

Personally, I would rather we get some transparency around privacy costs and assessment of offerings.  However, without a sufficiently sized market of customers willing to pay for privacy assurance and Cloud Providers willing to be more open, I won’t hold my breath.

What about you?  Would you be prepared to pay for privacy?  Should providers be more transparent about what they do and don’t do and how they do it?
 
 

Baltimore is one of what I believe are still three test markets that will go into commercial availability, albeit as much as a year after initial plans, and then months delayed after revised plans were announced. Still 2 to 4 Mbps is far above the level that current cell technology can achieve as a consistent range.