You are currently browsing the monthly archive for September 2009.

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

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…

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.

Follow me on Twitter

My Art / Misc. Photo Stream

20170417_164900

20170411_203014

phoenixhike - 4

phoenixhike - 3

phoenixhike - 2

More Photos