Dear Implementers:
What could be the KPIs by which I, being Management Representative,
can show complete picture in a compiled brief/short report? Your
response would be highly awaited.

Which I think is a great question!  Talk about no-nonsense.  None of this “high-falutin” nonsense about ISO adoption providing ‘piece of mind’ and ‘common language’ or ’strategic currency’.  No this is straight from the hip - tell me right now how I can communicate the value of an ISO implementation to non-security management.

I’m not sure I’ve got a good answer.  Do you?  You guys (loyal, cool, readers) are really bright and many of you CxSO’s in your own organizations.  Leave comments and in our next post  I’ll publish the best and brightest (as well as some of my own thoughts).

As promised, we recorded all of the day’s presentations and we’ve published them on TechNet:

Keynote Address by Scott Charney, Corporate VP, Microsoft Trustworthy Computing

Threat Modeling at EMC and Microsoft by Danny Dhillon of EMC and Adam Shostack of the Microsoft SDL team (of course)

Mitigations Unplugged by Matt Miller, Microsoft Security Science team

Concurrency Attacks on Web Applications by Scott Stender and Alex Vidergar of iSEC Partners

Fuzzed Enough? When it’s OK to Put the Shears Down by Jason Shirk, Dave Weinstein and Lars Opstad, Microsoft Security Science team

Real World Code Review – Using the Right Tools in the Right Place at the Right Time by Vinnie Liu of Stach & Liu

In addition to the presentations, we also recorded some short interviews (about 10 minutes long) with each of the speakers. If you’re just looking for a quick summary of a particular talk, these interviews are the place to start:

Threat Modeling at EMC, Danny Dhillon

Threat Modeling at Microsoft, Adam Shostack

Mitigations Unplugged, Matt Miller

Concurrency Attacks on Web Applications, Scott Stender and Alex Vidergar

Fuzzed Enough? Jason Shirk and Dave Weinstein

Real World Code Review, Vinnie Liu

I hope at least 96% of online readers will be able to directly apply this material to their products, just like the show attendees. Please post back and let us know, either way. And let us know what you’d like to see for next year. We have big plans to build on our success and make SDL Sessions 2.0 even bigger and better than the first.

Corporate custodians of confidential medical data should be closely monitoring events connected to a nightmarish computer security breach in the St. Louis region.

Express Scripts is one of the nation’s largest pharmacy benefits managers. The company, with headquarters in St. Louis County, handles approximately 500 million prescriptions per year for 50 million workers at 1,600 American companies. Early in October, it received an extortion letter, the details of which it released on Nov. 6.

The letter included personal information on about 75 Express Scripts clients — Social Security numbers, dates of birth and, in some cases, information about prescription medications. Whoever sent the letter demanded money from the company — the amount has not been disclosed — and threatened to use the Internet to reveal personal and medical information about millions of people if the demands were not met.

...

Beyond the scale of the problem for Express Scripts — and the potential impact on the company is enormous — the issue extends well beyond the mounting concerns about identity theft, a phenomenon with which most people have become at least somewhat familiar.

The greater problem is the unique nature of personal medical records, the importance of moving to computerization of such records to improve health safety and reduce costs and the irreversibility of the damage people can suffer if confidential medical information becomes public. The stakes are so high that a federal law establishes strict standards for maintaining the privacy of medical information and stiff fines for failing to do so.

Medical records of all kinds — paper and, especially, electronic — must be protected with the most sophisticated kinds of security systems available, including backup protections and automatic alerts of security violations. Yet Express Scripts learned of this breach in the “worst way,” as InformationWeek.com security correspondent George Hulme put it in an online report: “via an extortion letter.”

The Express Scripts breach raises many questions for all elements of the health industry: hospitals, clinics and doctors’ practices, benefits management firms, insurance companies, pharmacies, employers and government agencies:
Are they using the most advanced information security technology possible? Do they minimize the amount of data they collect and keep it only as long as necessary? Do they have strict protocols governing access to personal and medical data — and systems to enforce those protocols? If criminals were to hack into their systems, how would the companies know? How soon? And are the systems capable of instantly cutting off illegal access as soon as a breach is discovered?

Confronted with a grave breach of electronic security, Express Scripts has responded by contacting law enforcement, establishing an informational website, offering a substantial reward and hiring a private consulting firm to help clients who have privacy concerns and investigate situations that “appear to be tied to identity theft” and provide “identity restoration services.” There is no question that the company is taking the situation extremely seriously.
Given the ongoing criminal situation, information about how Express Scripts’ data systems were compromised — and whether it could have been avoided — has yet to be disclosed. But the American people have the right to expect that their sensitive personal and medical information is zealously protected and kept secure — not only by Express Scripts but also by every person or company entrusted with it.

"Customers and customer relationships...have tangible measurable value to businesses, and their value is much easier to communicate to those who fund projects. So in an enterprise risk management scenartio, their vlaue informs the risk management process...[For example, consider] a farmer deciding which crop to grow. A farmer interested in short term profits may grow the same high yield crop every year, but over time this would burn the fields out. The long term focused farmer would rotate the crops and invest in things that build the value of the farm and soil over time. Investing in security on behalf of your customers is like this. The investment made in securing your customer's data build current and future value for them. Measuring the value of the customer and relationships helps to target where to allocate security resources."

The key to a con is not that you trust the conman, but that he shows he trusts you. Conmen ply their trade by appearing fragile or needing help, by seeming vulnerable. Because of THOMAS [The Human Oxytocin Mediated Attachment System], the human brain makes us feel good when we help others--this is the basis for attachment to family and friends and cooperation with strangers. "I need your help" is a potent stimulus for action.

This is interesting. They say that all cons rely on the mark's greed to work. But this short essay implies that greed is only a secondary factor.

After Interop Las Vegas you may have seen our analysis of the data that we collected and delivered in our NOC view.  I thought I’d recreate the same data for NY and do a short comparison.

1) Like in Vegas, uptime for the network 100%.  This is no small feat considering that we introduced a new wrinkle in NY, taking down the primary NOC while the education portion of the show was still going on.  This was a forced failover to the backup systems, and it went flawlessly.  I’d like to give a little credit to EM7 on the 100% uptime as it caught a failover to battery power that allowed AC to be restored before a series of critical equipment would have gone down.

2) Again like Vegas, the average monitored device in the show network didn’t even hit 10% CPU utilization.  Still lots of computing overhead availabe in the show network.

3) The NY show network wasn’t nearly as busy as in Las Vegas, sustaining an average of only 27Mbps of usage (versus 56 Mbps) in Vegas.

4) Power consumption for the network and NOC in NY clocked in at 445kwh per day, about 25% less than the Las Vegas show.  This wasn’t because the equipment was any more power efficient, but instead because the show was smaller and therefore there was less network gear.

5) Finally, a stat we didn’t track too carefully in Las Vegas, but that I find interesting.  During show hours the wireless network average 1,100 users attached.  That’s a lot of people and a lot of wireless devices.

The good news is there was nothing too unexpected in the data, overall the smaller show led to a smaller number of tickets and smaller consumption of resources across the board.  We hope to have the opportunity to work with the InteropNet team again next year and take a look at this data year-over-year for each show.

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.