Ruling Out Best Practices

So I was sitting in a critical infrastructure cyber security talk earlier this week and had a small revelation.  The talk itself wasn’t all that interesting – it was another attempt to collect and identify consensus best practices for critical infrastructure security from a governance point of view – but it still led me down a path that surprised me.

The authors of the paper being presented had done interviews and other research and derived a number of principles required for critical infrastructure cyber security governance based on what they commonly heard over and over. At the talk, we had break-out sessions where they were pinging us for our thoughts on their findings.  During the session, I realized that I’d heard it all before (obviously, right? It’s a consensus paper) and was wondering why we couldn’t get past the stale “wisdom” repeated ad nauseam without effect…when it hit me: the use of their paper might be directly opposite of what they might think it is, but it’s still useful!

The thought process is as follows:

1. Assumption: We all “agree” that cybersecurity for critical infrastructure is insufficient and we’re missing something.
2. Assumption: The paper represented the community opinion, to date, on what needs to happen for good cyber security
3. People are trying to improve security, but despite sporadic improvements, we haven’t made nearly as much progress as we think we should. Something is missing.

Conclusion: Whatever it is we need to do …..isn’t in that paper.  If we collect a series of best practices and community consensus on a topic where we generally consider ourselves to have failed, collecting that consensus should be used – instead of as a driver of activity – a hint at what won’t, by itself, get us where we need to be. The lists should be considered things to exclude as solutions to our unidentified sticking points, but the solutions themselves.

OWASP Podcast Roundtable with myself, Doug Wilson, Matt Fisher, and Dan Phillpot

You can find it here: http://www.owasp.org/download/jmanico/owasp_podcast_42.mp3

The topic was “FISMA” in the context of OWASP and, while I don’t really do web app security, I’m still a “managed assurance” guy for risk, and I think that fit in well with everyone else’s perspective.  That said, I hate listening to myself talk, so tell me what you think of how it came out – I haven’t listened to it yet!

Also, it’s “National Cyber Security Awareness” month. What does that mean? Are we making everyone aware that we’re all 0wnz0red?  I like the idea – and socializing security was one of the recommendations that came out of the Estonia Ddos mess – but I have concerns about how the good intentions here aregoing to pave a specific road to a specific place.  The concern has to do with security productization.

You see, I have a suspicion that we’re not going to educate people about the nature of security. Or really that we’re going to get across how “security” is really this thing that everyone does all the name and we should stop treating it like this extra set of things we need to do -in addition- to actual requirements.

Instead, I think it’s going to come out as (from DHS’s website):

• Make sure that you have anti-virus software and firewalls installed, properly configured, and up-to-date. New threats are discovered every day, and keeping your software updated is one of the easier ways to protect yourself from an attack. Set your computer to automatically update for you.
• Update your operating system and critical program software. Software updates offer the latest protection against malicious activities. Turn on automatic updating if that feature is available.
• Back up key files. If you have important files stored on your computer, copy them onto a removable disc and store it in a safe place.

This is all admirable stuff, but it’s dogmatic. Dogma in security leads to blind trust in marketing and products.  Blind trust in marketing and products will never lead to secure systems or computers.

Yes, it’ll get us baby steps forward, but then we’ll be left with ye olde “I did what you asked me, isn’t that enough?” faith-based security and we’ll be in a pickle when we realize that, architecturally, we have some serious work to do to get where we want to be and no one is interested in doing more.

OWASP AppSec DC 2009 Coming Up – Remember to Register!

I just wanted to make sure everyone remembers to register for this great conference in DC this year.  From their website:

Press Release August 20th 2009 — Speaker Agenda Released and Registration Open!

We are pleased to announce that the OWASP DC chapter will host the OWASP AppSec 2009 conference in Washington, DC. The AppSec DC OWASP Conference will be a premier gathering of Information Security leaders. Executives from Fortune 500 firms along with technical thought leaders such as security architects and lead developers will be traveling to hear the cutting-edge ideas presented by Information Security’s top talent. OWASP events attract a worldwide audience interested in “what’s next”. The conference is expected to draw 600-700 technologists from Government, Financial Services, Media, Pharmaceuticals, Healthcare, Technology, and many other verticals.

AppSec DC 2009 will be held at the Walter E. Washington Convention Center (801 Mount Vernon Place NW Washington, DC 20001) on November 10th through 13th 2009.

Who Should Attend AppSec DC 2009:

• Application Developers
• Application Testers and Quality Assurance
• Application Project Management and Staff
• Chief Information Officers, Chief Information Security Officers, Chief Technology Officers, Deputies, Associates and Staff
• Chief Financial Officers, Auditors, and Staff Responsible for IT Security Oversight and Compliance
• Security Managers and Staff
• Executives, Managers, and Staff Responsible for IT Security Governance
• IT Professionals Interesting in Improving IT Security

Follow-up: “Mission Oriented” cyber security

Al McDougall from Evolutionary Security Management made the following point in response to my last post, and I thought it was useful to repeat it here:

“End result, the system view is lost because everybody works within their part of the behemoth but forgets about the mission.”

He’s right, of course. Furthermore: “Mission oriented” sounds “fuzzy” and people tend to blow it off, but it’s is not – it’s quite important.  In western culture, we seem to need to rush to go solve problems, without really ever trying to understand the nature of what we’re solving. This leads to all sorts of mayhem and things going wrong. We look back and can’t figure out why our solutions arent working or why they’re causing all these weird other problems.

What we need to do, instead, is spend our time groking the problems we’re wrestling with until we understand their deeper natures.  If we learn to ask sufficiently detailed questions, correct elegant answers will present themselves.  This, in many respects, is the essence of SABSA and Enterprise Architecture (although, especially in the case of the latter, an essence that is often missed).

In the case of cyber security, we absolutely blow past figuring out and AGREEING ON the nature of the problem and rush straight to the “solving” phase with perfectly predictable results.

My compatriots at TSA are asking me to, before I depart for INL,  transition my approach to the role of the SSA in the NIPP framework, but it really isn’t detailed or special. Fundamentally it is this: Figure out ahead of time what you’re asking and why. What is the mission being supported by cyber systems? What do you need to know to make sure those cyber systems continue to enable that mission? Start from the mission and work down. You’ll get there.

Hmm. Start somewhere and finish? That sounds like “Alice and Wonderland” – “start at the beginning and, when you get to the end, stop” – but it also sounds like a “process”. A “process” is what the NIPP lacks, yes? More to come…

Labels of Cyber Confusion and a New Job

Starting September 14th, I will no longer be contracting to TSA (via KCG, who have been wonderful). Instead, I will be working for Idaho National Labs (INL) onsite at DHS as a liaison between the smart people exploring the vulnerabilities of our nation’s critical infrastructure and the smart people at DHS CSSP doing the many things that they do.

Before I head out, though, I’d like to comment a little bit on an issue I’ve dealt with at TSA that I think also extrapolates to national cyber security efforts and is in no way unique to a single agency, or even the government. The issue is the label “cyber security”.  At TSA, as at DHS, as within the media, as within popular culture, there is confusion as to what “cyber security” means – even at a very high level. The term gets bandied about so loosely that it means everything and nothing. Still, people are making policy based on it without any definition.  The amorphous nature of the conversation is going to kick us in the pants sooner rather than later. Can we please nail it down more specifically when we discuss “cyber security”?

Below, find some areas of confusion that I’ve personally run into:

1. The internet, government networks, SCADA/ICS: This one is simple. When we talk about cyber security, we really need to preface our statements with which of these areas we’re discussing. They’re NOT THE SAME and the strategies, ownership, and etc to deal with them are NOT THE SAME either. Over and over again a lack of explicit distinction here burns us.

2. “IT Security” and Technology vs Strategy: Often, in my role, we were lumped in with what IT Security does: “Isn’t that the same thing, only with more computers?” was a popular sentiment.  There is the concept that these efforts are technical in nature and that they look a lot like FISMA shops: Assess, Remediate, Certify, etc.  against some standard or set of standards.  Nothing could be further from the truth.  “Cyber security” issues are of a strategic business and programmatic nature. We know how to fix computers, we don’t know how to define what security means to our businesses, how computers affect our operations, and we don’t know our risk appetites. In other words, “cyber security” in an executive (CEO, CFO, COO, CTO, CIO) issue, not one for technologists.

3. Computers vs Infrastructure vs Business Assets: We don’t care in most sectors if our computers work. Really, we don’t. What we care about is that our energy grid keeps pumping out power, our chemicals get mixed right, our cars are manufactured correctly, our financial transactions are accurate, our goods get delivered on time, etc.  These are the “assets” we are protecting. We are not protecting the internet, we are not protecting government computer systems. We are protecting the national operational interests of the United States.

4. Think globally, act locally: We’re so used to thinking about single companies and single systems within those companies that we forget that everything we do cooperates to larger goals. Our enterprise systems work together to achieve business goals which must be protected. Our business goals within critical infrastructure sectors, in aggregate, also work together to support national goals. For instance, the thousands of independent companies in “the transportation sectors” all combine to “move people and goods throughout the US and the world on time, to the correct destination, in acceptable condition”.   Many decision makers believe that it’s ok to ignore this larger context and focus on single system security or, at best, enterprise security. This is dangerous. Since these systems are interdependent whether we acknowledge it or not, they can be be used to exploit each other and damage our soft assets (goals) if we don’t regular take a look at and secure the larger picture.

Quartz Composer Webcam Audio Visualizer from Artomatic Available Now For Free Download!

For all of you who have asked for this, I’ve made my Artomatic Quartz Composer based webcam audio visualizer available as a free download.(Keep in mind, this is only for Mac OS X users – Quartz isn’t portable). 

 You can download it here: http://jackwhitsitt.com/Artomatic09-final-whitsitt.zip

(Im calling it “WAVIQ” for short…Webcam Audio Visualizer In Quartz”…since it needs some sort of a name and I dont feel that creative about it.)

A quick overview:

The composition has two inputs – the webcam and an audio source.  If you have a built in webcam, it will default to that. Likewise, if you have a built in mic (most laptops do), the composition will default to using  that as your audio source.  You can change these by going into the patch inspector for the Video and Audio patches and selecting “settings”. (In the case of the audi, double-click the macro patch “Audio Source” and then click on “Audio Input” to get there). 

The only other settings you’ll be interested in are the Increasing Scale and Decreasing Scale parameters found in the Audio Input patch. These affect how fast the values for movement, color, etc. get bigger and how fast they get smaller. This will affect how the composition responds to different music.  Also, keep in mind that in the audio settings of OS X itself, you can change the mic sensitivity. This will affect how the composition responds as well.

You can also find a basic tutorial to get you started on tweaking this in the links below.

Thats it. Drop me a line with any questions and have fun with it. If you do end up using it, I’d love to hear about it.

Thanks!

Jack

• Tutorial I wrote explaining the basics of how this works:
  • http://sintixerr.wordpress.com/2009/02/01/quartz-composer-webcam-audio-visualizer-art-tutorial-and-demo/
• Stop-Motion Video Example of how I’m using it at Artomatic:
  • http://vimeo.com/5045791
• Screen-shots of my Artomatic Art Installation:
  • http://jackwhitsitt.com/2009/05/the-kitchen-sink-at-artomaic-is-done-i-hope/