George Washington University Slides on Cyber-Security

In the last post I returned as I often do to the question “How to be secure when each component of your solution is itself insecure?”. I find that most practitioners, and in particular their management, are in denial on this issue. While my first suggested step which is to practice security hygiene is useful it does not help against a determined attacker.

While I am not sure if anything short of not connecting to anyone will work all the time, two possible approaches seem promising.

First, is the concept of an OODA loop. OODA stands for Observe, Orient, Decide, Act. It was developed by a US Air Force Colonel John Boyd who has since passed away, there is a rich set of literature on the topic for those interested in reading more. My slide 19 has an illustration of how this approach works at a conceptual level.

My simple interpretation is to be able to change faster than the bad guys are able to penetrate.  It was Boyd’s contention that in modern warfare the adversary who has the faster OODA loop would generally win. With cybersecurity, as with all security, the attacker generally has an inherent advantage of motion over the defender. Thus it requires serious planning to have an architecture that is agile enough to change and adapt and still remain operational.

A second approach is to use a biological construct. For example, your body has many viruses wandering around inside it at any point in time, yet in general people are healthy and the body defends itself well against these viruses – though with some help from time to time from a doctor.

The concept of having loosely coupled systems working together, like the cells in your body do, is called being Stigmergic systems, described in my slide 20.

In the class I described ants as an example of a Stigmergic system. An ant which finds food leaves a trail that other ants then follow. While none of them ‘talk’ directly to each other, they work together indirectly. This kind of swarm intelligence is characterized by fast adaptation, living OODA loops.

Once again, this kind of capability would have to be built into systems in order to work, it would require a completely different approach to system design.

I considered each of these merely thought exercises, I do not have much personal experience with either. However, earlier today when I was working on this post, I ran across an article about a Wake Forest University professor who is working on digital ants to check networks for viruses, so perhaps Stigmergic systems are one serious way to go:

http://www.tgdaily.com/security-features/56255-digital-ants-check-networks-for-viruses

Quoting Professor Errin Fulp: “As they move about the network, they leave digital trails modeled after the scent trails ants in nature use to guide other ants. Each time a digital ant identifies some evidence, it is programmed to leave behind a stronger scent. Stronger scent trails attract more ants, producing the swarm that marks a potential computer infection.”

And anyway, who wouldn’t want to be able to use the word Stigmergic in casual conversation at a cocktail party. Of course, that would imply that a Stigmergic designer would get invited to one.

George Washington University Slides on Cyber-Security

I wanted in this entry to talk about my thoughts on what organizations should consider when dealing with cyber-security issues. My discussion here is based on slide 18 – Thoughts On What To Do (duh). I will cover the final slides in a following entry.

I believe a lot of people start with the wrong premise. They assume that the goal of cyber-security implementation is to end-up with a secure systems architecture. In fact, at least in my opinion, that goal is unrealistic and planning with that objective in mind can lead to negative results.

Money is wasted playing what I refer to as whack-a-mole security, chasing after incidents that have already happened, and spending too much of an organization’s limited resources defending everywhere when the bad guys only need to find one vulnerability.

As I write “The fundamental question is how to be secure when every component is insecure.” I suggest two parts to the response, the first of which I discuss here.

As step one, practice security hygiene. Make sure that you have not made it easy for your systems to be penetrated. The reason we put locks on the doors of houses is not because this makes it impossible to break in, but at least we make it hard for the casual intruder and we slow them down to increase the chance of apprehension.

Much of what I talked about while I was at the Department of Transportation is in fact being accomplished, better than I did for that matter, currently in the Federal Government. There is an increasing movement away from the static oversight of FISMA report creation to the dynamic oversight of real-time situational awareness.

You cannot defend something when you do not know what is happening. Integrating sensors into your network or even better developing systems that themselves provide situation status are a big plus.

Second, it is important to build security into the budget process. My not well-formed thoughts at DOT were that depending on the categorization of software projects, low/medium/high, from a criticality (or some other kind of measurement) there should be a percentage range of the total budget that was required to be associated with security explicitly with a separate plan as to how the money would be spent. I found that when I went back and looked at systems that had been developed at DOT before I joined, the security investments were often not documented and when documented, the percentage of the total expense varied very dramatically.

The key point here is that security dealt with after development generally has little value and even then costs much more than when designed into the system development process.

Third, it is important to be as transparent as possible. There is a tendency to try and hide security status with the excuse that this makes a system more vulnerable by exposing weaknesses that would otherwise not be known.

This premise is generally wrong for at least two reasons. Bad guys will eventually find all of these weaknesses anyway; they spend more focused time doing so then most of us have in protecting. Most important, it is only with transparent exposure of status that we are likely to focus on fixing problems.

It is just as likely that resistance to transparent exposure of status is fear of oversight more than security protection. Management visibility is the biggest cure for problems.

This last issue is representative of the broad issue of information sharing versus information protection, a topic I have discussed many times. I remain convinced that while both have to be paid attention to, organizations that want to be successful in accomplishing their mission need to lean to the information sharing side of the argument.

Next will be my wrap-up of the presentation continuing the conversation about what to do about security while having inherently insecure systems.

My conclusion is that I do not and therefore wanted to reuse a few old ones.

While there will be a lot of closing the barn door after this particular horse has left action steps, in my opinion the bigger message is to reinforce the premise that the battle between information protection and information sharing is over and done with. Information protection has lost. I remain convinced that security planning focused purely on protection, in particular focusing on periphery protection, is a waste of time and money.

The underlying reason remains that the value of sharing information, or conversely the penalty of not sharing information, is so great for any organization of any type today that this need will drive decision making. Unless an organization is prepared to make the kind of investments that the Government does in setting up a structured set of security levels, e.g. confidential, secret, top secret, and so on, then it not possible to cause corporate culture to both share and protect very well at the same time. And even the Government security apparatus with its enormous associated investments leaks information, WikiLeaks being only the most recent example.

If I ran the security world I would focus on the following:

• Security hygiene
  • Achieving situational awareness
  • Implementing security policies associated with situational awareness, see my post http://www.ourownlittlecorner.com/2010/12/18/brief-thoughts-on-security-and-other-it-policies/
  • Identify the data I really want to protect and focus only on that limited data, if more than ‘limited’ rethink what you want to protect
  • Create a strategy that takes into account that no individual component of your system is impenetrable
    • If concerned about availability – consider a biological construct with multiple copies of your applications and data available; e.g. the human body works fine, mostly, even with viruses all over the place
    • If concerned about penetration – consider increasing your OODA loop speed, observe-orient-decide-act, http://en.wikipedia.org/wiki/OODA_loop

Each semester I find I learn a great deal from reading the papers and interacting with the students about them.

I have drawn three conclusions about policy creation from my past experience at the Department of Transportation, modified slightly from the current set of papers:

(1) Policies whose impact cannot be measured cannot be enforced.

(2) Measurements which are not created in some kind of automated fashion will not persist.

(3) Measurements which are not made visible don’t exist.

First, we put security in charge.

Second, we kept secrets.

If we solved for those two issues, we would not have a security problem.

Of course, I was joking. Well sort of.

The point I was making regarding security being in charge was to illustrate that in the end security was an advisory function supporting the business owner. The business owner needed to make the final call regarding what to do re operational systems.

Taking the extreme example at the Department, which happily we never faced, was what if the air traffic control system had been infected with a virus which we felt might spread to other operational systems. The senior executives who were responsible for air traffic control would be the responsible officials deciding if we could take the systems off-line, not security.

My second point was that if we needed to much more aggressively think through what systems, and data, we really needed to protect. The more we needed to protect the less likely we were able to protect anything. My final line was always if we didn’t have any secrets we wouldn’t have a security issue.

In retrospect, I have more recently realized that in addition to being a bit flippant, I was also wrong. As any security professional knows, even without secrets we still will have a serious security issue – that of integrity. By integrity I mean both of the data and the systems themselves.

Since it remains my contention that in today’s world, all organizations have to ultimately choose if they are going to be great at information sharing or information protection AND that all organizations are going to eventually have to choose information sharing (I’ll do a separate post on this); this leads to a problem.

Recently I have been talking to professionals who touch DoD and military doctrine, an area I am pretty unknowledgeable. A number have mentioned the work of John Boyd, http://en.wikipedia.org/wiki/John_Boyd_(military_strategist). Boyd came up with the concept of decision cycles, what he called an OODA Loop:

• Observation
• Orientation
• Decision
• Action

A simplistic summary of Boyd’s thinking was that in combat, the organization with the fastest, high quality OODA loop would win; where combat could be combat in anything.

Taking this concept to cyber-security, one conceptual approach would be to not try and protect the periphery of a network but to be able to rapidly change the network or access to it, or its contents, so that an adversary would never have the opportunity to penetrate and/or corrupt it.

As usual, I am much more able to articulate these kinds of things conceptually than to actually understand the implementation implications. However, I hope to interact with people who can help me understand those details as well as let me know if this is a reasonable approach to security.

A few people asked me to post my presentation, but I have found that my current job as the COO at Powertek Corporation has caused me to miss many of my self-imposed deadlines for doing many things, including updating my blog.

However, has now been overcome, at least for a few moments, and here it is.

UMUC Slides 

My talk was divided into four parts:

• Context where I discussed what I call First Principals, what I feel are the underlying causes of much of the technological disruptions happening these days
• Some thoughts on security trends, after all this was a Cybersecurity Symposium
• Comments about the demand for security professionals, after all this also was a Job Fair
• Ending with some thoughts on the goals for security and some general advice

I think the slides are pretty self-explanatory though I keep hoping to turn some of them into individual blog entries.

I had two key pieces of advice.

First, I related an old joke by Steve Martin that talked about how to make a million dollars and not pay taxes. The first step was to ‘find a million dollars’. I find that many proposed solutions to security, well, actually to almost anything hard is the functional equivalent of that first step.

Second, I told them to remember that the primary mission of almost every organization they will work for is NOT security. Because of that fact, one of the primary jobs of a senior security professional is to learn how to articulate the reasons for security investments in the context of the actual mission goal. Otherwise, organizational senior management will not make the right decisions.

The webinar, moderated by Adam Ross, the Managing Editor from the SANS Institute, will focus on some of the challenges faced in creating secure Federal Systems. With the growing movement for speed-to-market and the movement to the cloud, and associated buzz words, and with the increased publicity about cyber-attacks, how we should best deal with such issues is becoming a still greater issue.

Pat and I will look at these issues in three parts.

First, we will look at the context that we now face. I find that without understanding the context of a problem, it becomes difficult to really deal with the systemic issues. Second, I will review some of the high-level goals that I would focus on, putting on my now dusty CIO hat from my Department of Transportation days. Finally, Pat will tackle real-world issues with implementation suggestions, looking at how to integrate security planning rather than dealing with it as an afterthought. He will also offer his thoughts relating to SCADA design issues (Supervisory Control and Data Acquisiton – e.g. computers managing things like the electrical grid, power plants, and so forth).

Registration details are at:

http://event.on24.com/r.htm?e=195825&s=1&k=D14C3C31F1889E77A82E235253D58190

The Government Executive website is at: http://www.govexec.com/

Powertek Corporation’s web site is at: http://www.powertekcorporation.com/

The Nuclear Regulatory Commission’s web site is at: http://www.nrc.gov

The theme of the conference was Lowering the Cost of Government with Technology though the panel’s comments ranged from cost issues to government 2.0 and social networking to cyber-security in general.

The panel was moderated by Chris Dorobek, the afternoon co-anchor for WFED. The other panelists included Vance Hitch, the Department of Justice CIO, Pat Howard, the Chief Information Security Officer, CISO, for the Nuclear Regulatory Commission, Dr. Ron Ross, a key figure in defining security requirements and policy at the National Institute of Standards and Technology, NIST, Gary Galloway, the Deputy Director for Information Assurance at the Department of State, and Rue Moody, the Director of Strategic Technology at Citrix.

I was called on first after the introductions to frame the conversation based on the pre-meeting discussions the panelists had held. I discussed four issues.

First, there is an inherent conflict between data sharing and data protection. In my opinion, you cannot do both perfectly. Even though almost everyone will take the position that you will have to pay attention to both, it is important to pay attention to which way you lean and why and the implications. I noted how impressed I was towards the end of the last administration, when Mike McConnell, then the Director of National Intelligence, DNI, talked about if he had to take some security risks in order to increase the ability to share information within the Intelligence Community, he would. I am sure that I am not capturing the nuances of his talk, but the messaging was very powerful. It is a position that those who know me recognize I agree with very strongly.

Second, security is difficult to measure and more importantly there is little agreement among security experts as to what metrics to use. This is a particular problem for those agencies and departments who do not have security as part of their day job.

What I mean by that last sentence is that those departments who have security as part of their primary mission have a great deal of day-to-day experience in making tradeoffs involving security spending. Even if the rationale for decisions is merely experiential as opposed to quantitative, over time senior management gets to be fairly experienced at making these kinds of decisions.

For most civilian departments and agencies this is not as true. Trying to decide if taking money from safety inspections, which might be an agencies primary mission, and spending it on cyber-security is a difficult decision to make. Without defined metrics the likelihood of making the correct decision isn’t very high.

I was heartened in reading recently about the establishment of a Security Metrics Task Force by Vivek Kundra and the Federal CIO Council, http://it.usaspending.gov/?q=content/blog, chaired by Vance Hitch, who discussed this during his remarks at the panel, and Rob Carey, the Department of the Navy CIO.

Third, it is hard for people in large organizations, especially governmental organizations to prioritize; that is, to implement the results of risk analysis. The fundamental reason is that prioritization requires someone to decide to work on one set of requirements and thus to NOT work on the rest of the requirements. Few, if anyone, wants to be the person who is associated with the latter decision, the not work on part. If anything bad happens that could be associated with a requirement that is in the lower set of priorities, that will get extra attention from the various oversight groups that look over the shoulders of IT providers in the Federal Government. As someone who had the pleasure of testifying on the hill I can promise you it is not a goal for most people.

The end result is that often organizations try to do everything and thus end up doing very little of anything.

Finally, I noted that the general overemphasis on protecting the end-points of networks is starting to be balanced against the need for creating systems that are resiliant and have high-availability. Obviously, it would not be a good plan to ignore investments in protection against bad guys getting into networks. But it is equally important to recognize that regardless of the level of protection built into an architecture, at least some bad guys will get through. Therefore, it is also important to think about how to make sure systems stay up and running with protected data even while a system has been otherwise penetrated.

As hard as it is to build in protections and to measure the results, it is harder still to do the same for regarding building resiliant systems. Thus the greater emphasis on protection first, which i believe still needs to be adjusted further.

One point which I didn’t make as well as I would have liked at the Conference is the fact that security has both positive and negative cost implications. It can be positive if there is greater standardization which tends to lower support costs and can do so dramatically if done well. It can be negative if there is no clearcut methodology to making investment decisions. Without associated risk management and security metrics, security spending becomes an endless investment with no well-defined result.

Many thanks to Goldy Kamali for inviting me to be part of the panel and for putting together a great conference. Everyone who missed it missed some great discussions and networking opportunities.

The Editor’s Letter headline is:

“Whac-A-Mole” Approach to Security

and contains the following paragraph:

“It’s hard to imagine more appropriate imagery for our cover story (“Moving Target”) about the widespread frustration with mounting cybersecurity threats and the lack of an effective U.S. government response. CTO Daniel Mintz of consulting firm CSC aptly describes the feds’ “Whac-A-Mole security” approach as one where long-term strategy takes a back seat to daily tactical responses.”

http://www.cio.com/article/495811/A_Whac_A_Mole_Approach_to_Security

I appreciate the mention and anyone who has heard me talk about cyber-security will know I use that term a lot. My one question is whether it should be “whack” or whac” …

The full article is located here:
http://www.cio.com/article/496125/Obama_s_Cybersecurity_Push_What_It_Means_for_CIOs