The PDF document holds a single paged scan of an internally distributed mail from German telecommunications company T-Systems (Deutsche Telekom), revealing over two dozen secret IP address ranges in use by the German intelligence service Bundesnachrichtendienst (BND). Independent evidence shows that the claim is almost certainly true and the document itself has been verified by a demand letter from T-systems to Wikileaks.

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 one of the primary contributors to the SIRs, so naturally I think you should download it immediately and read it cover to cover  ;-)  However, I understand that some of you may not wish to read a 150 page technical analysis document, except as a way to fight off insomnia.

Because of that, if you go over to the main SIR page at www.microsoft.com/sir, there is also a "Key Findings" document that is only 18 pages long and provides a nice summary of the findings from each section.

For my section, on Industry and Microsoft vulnerability disclosures, I'll be posting up some brief PowerPoint screencasts over the next few days where I'll talk through my findings while showing some pretty graphs.

Regards ~ Jeff

Lots being written about the Cloud, most of it quite dark and gloomy.  In fact I’m surprised, that Hoff hasn’t got a preso spooled up called “The Toxic Cloud” or something similarly ominous for his next speaking tour.
That said, the Economist does a great job distilling the issue into a simple statement -

Cloud computing is a trade-off between sovereignty and efficiency.

Let me ask you -  if you had to put your money on one of those horses, considering your average profit-preoccupied business, which would it be?  I’d put my bottom dollar on the thoroughbred named “Cost Center Reduction”, to place.

WHO ARE WE TO STAND IN THE WAY OF “PROGRESS”?

I’m always fond of Jack’s rule that the role of information risk management boils down to three deceptively simple premises:

• Reduce Risk.
• Reduce Loss.
• Create Operational Efficiencies.

So it would seem antithetical to the charter of the Chief Security Officer to stand in the way of progress as embodied by “cloud computing” (not to mention dangerous to long-term job security).  And I think that this presents opportunities to discuss strategies for managing risk, strategies that aren’t too theoretical and have practical application (though actual “cloud” use by enterprises may be rare at this point).

ON RISK REDUCTION IN THE CLOUD (or, How To Learn From the Shortcomings of PCI DSS)

The good news is, there’s already a well-established model for managing the risk around outsourcing the processing of “confidential” information.  The bad news is, that model kinda sucks it.

The Payment Card Industry, known as the “PCI” or “meal ticket” to many in the industry, faced a similar problem with the introduction of GLBA.  As I see it (and I’m not at all close to the PCI, at all, so this is all just abstract soliloquy) the PCI had one of two choices when faced with the prospect of other people managing their sensitive information:

1. Accept the *massive* amount of GLBA risk their business creates and spend a TON of money to build out the infrastructure (both process and IT) to manage the consumer data themselves (in conjunction with the banks, of course) and never have it grace the computing systems of the retailer.  Or,
2. Transfer the GLBA risk down to the retailer and have them bear the majority of the risk (and cost of reducing risk to a level that might be tolerable to the US Government).

(Martin, you may recall our Twittering about PCI a while back.  This is the crux of my view on the subj.)

Now fortunately, the CSO’s of the world are going to be a little more “invested” in protecting the information they are stewards over, and unlike the PCI, will remain primarily responsible for the C, I, & A of the data in the Cloud.  The cool thing is, this actually presents a great opportunity to start building a meaningful model for co-management of risk!  In fact, we can take the PCI model of contractual risk transference but modify where it goes all wrong, and start working to create something better.  And we can start by euthanizing some faulty assumptions.

JUST HOW INFORMATIVE IS PCI DSS?

What might be the.greatest.mistake of the standards compliance mentality is the assumption of value for the past-state measurement.  That is, I believe that the CSO needs more than some “past-state” assurance in order to understand their risk.    If you look at the concept of “PCI compliance” it really is an examination of a past state of nature that is assumed to be relevant to current and future states.   Many people (myself included) are not at all convinced that this past-state is nearly as informative as those who mandate it’s measurement believe it to be.

That’s not to condemn past-state measurements as completely non-informative,  they most certainly are useful.  It’s just that no self-respecting CSO sleeps well because they were deemed “PCI compliant” 10 months ago.  They sleep well because they have good visibility into current-state information and confidence in their strategy concerning future-state (based on that visibility and the outcomes of sound IRM models).

MOVING PAST THE VULNERABILITY SCANNER INTO INTELLIGENCE AND WISDOM

So realizing this new importance (to me, at least) concerning visibility and IRM models, I’m lead to the conclusion that if we are to manage risk in the Cloud, we’ll have to move beyond “PCI Compliance” or the concept that some regular “audit” of controls in place at the host is all we need to understand our ability to manage risk.  No, the CSO must have good information concerning current and probable future states.   This is that “visibility” I spoke of above.  In fact, we’ll need significant amounts of piercing, transparent visibility.  And in order to gain that visibility, our insight into Cloud Risk Management must include significant provisions for understanding a joint ability to Prevent/Detect/Respond as well as provisions for managing the risk that one of the participants won’t provide that visibility or ability via SLA’s and penalties . These SLA’s must be expressed in measurable terms (more visibility), and those metrics must have their roots in the things that help understand how we manage risk (those aforementioned IRM models).

THE CLOUD COMPUTING SECURITY SILVER LINING (sorry couldn’t resist)

As I mentioned earlier, I do see an opportunity to create insight.  The need for visibility and IRM models would allow us to create a “guidance” if you’ll allow me to use the term.  Not a standard or a “best practice” to audit by, but simply a reference document that says “if you’re going to put information on somebody else’s systems and still hold some significant responsibility for that information, here’s the considerations, why they are considerations, and how you might go about collaborating on the management of risk”.

And I think that if we undertake this journey, there is going to be a lot of growth and risk management innovation along the way.  But keen insights into what it means to manage risk will be necessary, and secure and forthright collaboration will be of absolute importance.

I say that last bit because, if these pundits are right about the utility of a hosted computing model - the Cloud will happen regardless of the CSO’s ability or desire to manage it.

This requirement was put in place to prevent use of certain older C runtime functions that lead to buffer overrun flaws and have been deprecated. In the Security Development Lifecycle book, an entire chapter is dedicated to the topic of banned function calls. In the book, we also provide a copy of the banned.h header file on the companion CD. This header file allows you to locate any banned functions in your code.

On MSDN, we have document the SDL list of Banned Function Calls, but the header file has not been publicly available outside the SDL book until now. Today, we are providing the banned.h header on the Microsoft Download Center.

Find the banned.h header here

By including this header file, then using #include “banned.h”; you will be able to locate any banned functions in your code. The full list of banned APIs is also included in the header file.

Alternately, if you are using the compiler in Visual Studio 2005 or later, you have a built-in way to check for these banned functions. To catch banned C runtime functions, you can compile with /W4 and then triage all C4996 warnings. In code reviews, you should always remove any code that disables the C4996 warnings - e.g.: #pragma warning(disable:4996). This is one simple way to ensure your code is released without banned functions.

Sanitizing your code to remove potentially insecure APIs is a vital protection. Whether you include the banned.h header file or leverage the /W4-C4996 warnings in the Visual Studio 2005 compiler, you now have two ways to check your code and meet another SDL requirement in your development phase.

TECHNOLOGY AREAS: Air Platform, Information Systems, Space Platforms, Human Systems

The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), which controls the export and import of defense-related material and services. Offerors must disclose any proposed use of foreign nationals, their country of origin, and what tasks each would accomplish in the statement of work in accordance with section 3.5.b.(7) of the solicitation.

OBJECTIVE: Develop visualization techniques for planning and execution of Cyberspace operations.

DESCRIPTION: Fulfilling the Air Force mission “… to fly and fight in Air, Space, and Cyberspace” requires effective C2 tools for the observation, planning and execution of cyberspace operations. Conventional battlespace visualization tools were developed for the physical world (i.e., geospatially oriented), where the battlespace, weapons and effects are concrete, often observable entities. Cyberspace and its critical electronic infrastructures are an artificial world that must be created, modified and sustained by the warfighter. This artificial world of cyberspace has concrete links back to the physical world that shape the information landscape, affect the decision-making process, and control the communication channels crucial to C2.

Standard, geospatially oriented C2 tools are not suitable for providing cyber combatants with comparable situation awareness to understand events, evaluate options, and make decisions in the electromagnetic domain. The combatants in the cyber domain needs to be able to quickly see and understand not just the physical relationships of the traditional battlespace, but also the logical relationships and information dependencies in the abstract landscape of cyberspace. Cyber C2 visualizations need to provide information for strategy, tactics and execution of effects that may, or may not, have physical correlates. Examples of these cyber events include network attack detection, attack identification, damage assessment, denial of service (DOS) warnings, and information warfare or cyber-attack operations.

For example, a commander may be planning to intentionally disrupt a portion of his network to investigate a cyber-attack. He will need to understand what ripple effects will occur across the functionally diverse and geographically distributed network. These ripple effects will have both a cyber component (e.g., locations that will lose connectivity or suffer degraded performance characteristics) and a real-world component (e.g., information about enemy forces may be unavailable or delayed, reducing blue force effectiveness) that must be visualized, explored and tasked from within his C2 tools.

Decision makers will greatly benefit from innovative visualization tools that can improve their understanding of all aspects of the Cyber domain. These aspects include 1) the current state of the information environment, the physical and virtual battlespace and enemy and friendly capabilities and vulnerabilities; 2) the scope and scale of courses of action that affect information or information networks; 3) the primary effects and ripple effects of an operation in both the physical and cyber battlespaces, and 4) the risks for collateral damage associated with cyber warfare activities.

PHASE I: Identify cyberspace characteristics relevant to C2 visualization. Identify correlation methods and visualization techniques to understand battlespace, operations, and effects. Define metrics to evaluate efficacy. Document results in a written report, including mockups of proposed visualizations.

PHASE II: Construct a working prototype to demonstrate integrated visualization of cyber data showing 1) the status of information environment, 2) its effect on the conventional battlespace, and 3) the status of information operations. Evaluate effectiveness using metrics defined in Phase I.

PHASE III / DUAL USE: Military application: Additional military applications include command and control environments, like the Air Operations Centers (AOCs). Commercial application: Monitoring and defending infrastructures (e.g., financial and energy) against cyber-attacks. Visualization cyberspace is beneficial for security of commercial communication and information networks.

REFERENCES:

1. ‘Air Force leaders to discuss new ‘Cyber Command’

2. Laura S. Tinnel, O. Sami Saydjari, and Joshua W. Haines, An Integrated Cyber Panel System, IEEE Computer Society,

3. Anita D’Amico and Stephen Salas, Visualization as an Aid for Assessing the Mission Impact of Information Security Breaches, IEEE 2003.

4. Tim Bass, “Cyberspace Situational Awareness Demands Mimic Traditional Command Requirements,” AFCEA Signal Magazine, February 2000.

KEYWORDS: visualization, cyber, human factors, planning, situation awareness, command and control, HCI

Reference. SITIS Topic Details, Visualization for Command and Control of Cyberspace Operations

See also:  http://www.dodsbir.net/solicitation/sbir083/af083.doc