You are currently browsing the tag archive for the ‘dhs’ tag.

So, I’ve recently written up two separate pieces talking about Business Security, Frameworks, Cybersecurity.  One is for <UNDISCLOSED>, the other is for CForum (hey, I was the next highlighted blog post after Ron Gula’s!).  Let me know what you think of them, they’re below.  (Also, two posts more directly about the new NIST Framework and the DHS Voluntary Program are HERE and HERE)


Cybersecurity is, broadly, the enablement of an environment in which business objectives are sustainably achievable in the face of continuous risk resulting from the use of cyber systems.

The risks from using cyber systems usually take the form of actors desiring to use those systems as a means of repurposing business value chains to alter the value produced, inhibit the value produced, or producing new value in support of actor objectives.

Managing these risks involves two focus areas:

  1. Creating a business environment which limits the window of opportunity provided to actors in which to achieve their objectives
  2. Executing a security-specific program that is able to identify, mitigate, and respond to actor activity which is occurs within the remaining window of opportunity.

Leaving the business environment unmanaged provides a large continuous window of opportunity which is, at best, not cost effective for security-specific programs to effectively respond to.  At worst, the window of opportunity created by an unmanaged business environment leaves the window of opportunity too wide for security-specific programs to protect, even with excessive financial investment.

On the other hand, no organization can manage its business environment and reduces actor opportunities sufficiently to remove the need for security-specific programs.

Both focus areas must be addressed for sustainable, effective, cost-limited cybersecurity and the NIST Framework can help with both.

Cybersecurity Frameworks, generically may provide business value to an organization in three ways:

  1. Scope and Completeness Assessment
  2. Coverage Validation
  3. Efficacy Testing

In the case of security-specific programs, the NIST Framework can be used directly as a positive model for determining program scope and completeness, it can (using the tier model) be augmented with additional information to assist with security program coverage validation, and it can play a role within a larger model in testing efficacy of security program efforts.

Within the business environment focus area, the NIST Framework can also play a supporting role as a negative model to help determine areas which must be better controlled by the business before security-specific programs can effectively manage residual cybersecurity risk flowing down from that environment.

While XYZ is focusing specifically on the former, security-program specific, focus area, its resulting efforts can, with forethought, go a long way to providing a foundation for the less-well explored area of cybersecurity risk reduction through business environment management and lead us toward the kind of comprehensive cybersecurity risk management approaches that will, over time, reduce our risk across organizations, the sector, and the nation sustainably, cost effectively, and independent of increases in complexity and changes in actor behavior.


What’s next? 

This is a question on all of our minds – not just for the Framework but also cybersecurity more generally.

Executives have started to get on board, the press is paying attention, manufacturers are starting to include security in their ICS products, grass roots organizations such as I Am The Cavalry and others are forming to help to move Automotive and Medical Device security forward, the White House has issued the Executive Order, Congressional staff discusses cybersecurity regularly, and together we have created a common practice consensus “flag” with the NIST Framework, and this very forum now exists to help us collaborate more effectively.

So, how do we use this momentum to continue to move forward coherently toward sustained risk reduction?

I’ve heard a lot of good ideas here, at the 6th NIST workshop, and in many other venues about what to do next, but a lot of these ideas, thrown up into the air, fall down with no structure to catch them. There is no bigger picture into which to slot next step ideas and see how they relate to past work, need, and each other.

Without such a common reference structure, making progress from here on out will be increasingly difficult and I believe we need to learn from the very recently successful past and build a framework to do so.

The new framework I’m envisioning would, far from a “2.0” of what we’ve already built, have a completely different goal. Instead of collecting and organizing common solution elements into a document, this framework would identify the types of problemswe face doing business in a hostile, ICT (Internet and Communication Technology) enabled world and provide a context in which to organize the existing NIST Framework solutions.

In other words, if we identify a common language and reference for the “cybersecurity problem space” – especially the areas outside of the CISO organization – it should be much easier to go back, find out where the Framework excels, where it needs help, and where it simply does not apply and, from there, allow us to organize future efforts effectively and sustainably.

Maybe we should have done this earlier, but maybe it took creating a Common Practice Framework to highlight the need to go back and create a “Problem Space Framework”. How many of us have looked at strategy documents that said things like “Will reduce cyber attacks” or “Improve Cybersecurity” and thought “But wait, what does that mean?” Shouldn’t there be goals, or non-security objectives for security to help frame, limit, and shape our efforts to some productive end?

When the executive order came out and I heard about how the NIST Framework was going to be used to support “Performance Objectives”, I thought, “Great! Finally, we’re going to have the electrical current that non-security-activity goals provide to security activities to drive them to defined, implementable, and effective ends”.

Unfortunately, that doesn’t seem to be happening and there doesn’t seem to be consensus that that was even the original intent. But that doesn’t mean we don’t still need to create that organizing current around security activities.

The “Tier” concept in the existing framework, as incomplete as it is, definitely speaks to the need for the application of a maturity model to what we’re doing, but even maturity models need to exist inside a larger context of “Why?” that is framed by all of the ways organizations – and those who work for them – introduce risk. If we don’t have a framework for risk introduction in a broad business and national context, how will we ever be able to tell ourselves, each other, our customers, or anyone else that we’ve applied the NIST Framework in some legitimately effective or helpful way?

This shouldn’t be a hard problem to solve. As with the Common Practices in the NIST Framework, we’re in a situation where a lot of different people have very different but valid views into the cybersecurity problem space. The material and knowledge exists, we just need to gather it, write it down, gain consensus, and begin to apply it.

From my own point of view, I think this begins by identifying (and documenting) how the major, common roles within organizations (and of organizations) introduce cybersecurity risk through legitimate, authorized means in the course of doing business. If we can nail this down across the entire business value chain – from Boards and CEO’s to CFO’s to Operations Managers to IT to Procurement to Sales and Marketing to HR to Industry Partners to Insurance Companies to Regulators all the way to the CISO shops that the NIST Framework already assumes solutions for – we will have a much better understanding of what we’re solving for. This is because our cybersecurity risk profiles are, when it comes down to real root causes, exclusively the result of the series of decisions made by people in legitimate, authorized capacities. Whether or not the decisions are in your sphere of influence, knowing how they are influencing your cybersecurity risk profile over time is the first step in determining how to most effectively apply the controls from the existing NIST Framework. From there, that knowledge can be applied to contextualizing the maturity levels in models like the ES-C2M2 in a way that provides “Management Metrics” to those responsible for managing organizational behavior, and those maturity levels can then guide the scope, goals, metrics, and placement of those controls that exist in the NIST Framework.

Beyond the tactical benefits of the knowledge such a framework would give us, our ability to act strategically will improve. If we know how our CEOs and those who work for them are introducing risk, if we can find commonalities across organizations, then we can describe the goals, effectiveness, and mitigating controls in terms that are much less dependent on far too rapidly changing technology and external threat actors. This would provide a much more stable platform over time from which to begin doing sustainably successful risk management, maturity modeling, and NIST Framework implementation and adoption.

That said, this is just one way we might go about creating a “Problem Space Framework” – there are others. Regardless of which one we choose, I strongly believe building one will clarify, speed up, and make our way forward much more effective at reducing risks created by the use and operation of ICT’s.


Just wrote up a review/comments on the new 2013 NIPP released by DHS at the end of December for work. While the NIPP isn’t cybersecurity specific, it is still the policy environment in which non-regulatory critical infrastructure cyber security work happens. Some excerpts most pertinent to this blog are below, but you can (and should!) read the whole thing here:

“…the language used in the new NIPP implies a (positive) evolutionary shift in collective thinking…”
“…It seems like, some of the lessons from the EO and the Framework development process may have influenced the writing of this document…”
“…it does appear that the new NIPP will maintain support of existing public/private partnership mechanisms such as Sector Coordinating Councils (SCC), Government Coordinating Councils (GCC), Critical Infrastructure Protection Advisory Council (CIPAC), Information Sharing and Analysis Centers (ISAC)… Still, it is exceedingly good to see that these mechanisms will not be the *only* ways to partner.”
“…There are a number of stakeholders who, up to this point, have not been part of this dialogue and it would be valuable if they found a way in…The two that come immediately to mind are “The Public” and “Unaffiliated Security Subject Matter Experts (SME).” First, “The Public” is critical infrastructure – at least as customers of risk management – and currently, they have little voice here. Second, most smart hacker or security types, if they are involved at all, are filtered through the business and political realities of their parent organizations and their industry associations. It would be nice to find away to add those voices to the mix, if only to offer a reality check to things like the #NISTCSF.”
“…More serious than the Risk Management Lifecycle problem, however, is what appears to be a philosophical miss.  It is good that cyber and physical security should be more integrated. The change in tone and apparent improvement in flexibility is appreciated, and outcome goals are absolutely a minimum requirement for driving effective security initiatives. However, the new NIPP still doesn’t effectively deal with the overall immaturity of the cybersecurity discipline itself – particularly when compared to the physical space.  It feels like there is an assumption that someone knows the right answers and all we have to do is implement them, but that’s not true.  In fact, the entire problem space needs reframing away from how the security industry has defined it for us over the past 10 years into something with a business quality assurance baseline that is then supported by risk management…”
“The NIPP and related public/private partnership mechanisms could do with more methods for and focus on the definition of  successful cyber security paths forward to meeting collaborative outcome goals, rather than a focus on selecting and then implementing existing paths.”

Finally wrote these up. They’re a bit long winded and lecture-y, but I honestly had mixed feelings about sending them in at all.  Sometimes you feel like you’re talking to the wind.

“Lord knows I’ve tried to say but I’ve / Heard a million conversations / Going where they’ve been before” – Sisters of Mercy


To Whom It May Concern:

First, thank you NIST, DHS, and NSS staff who contributed to what has been, in my opinion, a very successfully run cybersecurity partnership endeavor.  I have attended all of the sessions, have appreciated the dialogue both online and off, and have learned quite a bit.  And also, thank you again for taking the time to read these final comments at the end of what must have seemed a long process.

With regard to this document, I have elected to break my response down into four sections: A problem space assessment, discussion of whether the framework as it is is the tool we needed to build, comments on the quality of the tool we did build, and externality/ecosystem thoughts. I will attempt to answer the direct questions asked in these sections – if indirectly.


One of the gaps in the framework process, in my opinion, has been in the determination and socialization of a problem definition – I feel like that was not done proactively.  Building a “framework” means many things to many people.  “Making things more secure” is even more nebulous – even within the context of Executive Order definitions and scoping.  I believe many of my concerns and criticisms could have been alleviated by the government spending more time and effort educating participants on the hows and why’s and what’s of the Executive Order and the Framework up front.  Not everyone had a strong historical background and it was evident at the workshops.

That said, rather than making that same mistake here and providing comments without context,  I have included several assertions below that have guided my thinking and evaluation of where we are with the framework. Your mileage may vary:

  1. We are failing at cybersecurity.  If we were not, the topic would not be receiving this much attention or funding and we would not be going through this process.  As a nation, just looking at the number of substantial public breaches makes this very clear.
  2. We are heavily investing in cybersecurity.  Many organizations spend vast sums and use known best practices regularly in their environments.
  3. These organizations are still getting breached at unacceptable (to the nation and to themselves) rates despite their security efforts
  4. Asking for their “best practices” and “what works for them” typically results in a list of things that, by themselves, are not effectively protecting us from cybersecurity risks
  5. Very few, if any, organizations are “doing security” using a substantially different model than anyone else.  For the most part, differences are a matter of degree, not philosophical approach
  6. Given the high-end investment with lack of consistent success in reducing risk to acceptable levels in those quarters, it is safe to assume that merely eliciting “best practices” and re-framing them will lead to a continued lack of success.
  7. In many cases, it appears that this failure occurs in several areas: a) It’s very difficult to follow these best practices consistently over time. b)Existing practices assume a level of non-security business, IT, and operational maturity that is not addressed by most best practices and is certainly not often culturally socialized, and c)Expecting thousands of organizations to be able to fund or maintain the level of operational and technical maturity required to substantially reduce risk the way we currently build/implement IT/ICS systems is a potentially irrational expectation – even when everyone is on board with the idea.
  8. Despite continued failures, it is still very difficult to elicit a comprehensive view of cybersecurity that does not focus on things like incident response, firewalls, or other “best practice controls” found in documents like 800-53.
  9. Open ended elicitation attempts, lacking guidance, typically result in the re-documentation of this “tribal” knowledge and cover no new ground. Cybersecurity is, and continues to be, a discipline that is poorly understood or defined outside of its historically technical focus.  This is gap that must be remediated or all future efforts will ultimately fail.
  10. Starting with and then breaking down the problem into its fundamental business and cultural considerations – not controls – is critical to identifying and remediating these choke points. Ie, instead of focusing on the execution of security,  successful efforts will improve the “environment in which cybersecurity occurs”.
  11. An example of a method more likely to elicit the environmental/cultural/business underpinnings of cybersecurity would be to start with business outcome (enablement) objectives – any of them will do since security controls tend to collapse/overlap across objectives —  and then elicit a framework to meet these objectives while assuming a lack of  a dedicated security team and without making references to cybersecurity specific technologies. This forces a dialogue shift onto new ground and the resulting work could then be linked to existing “hard” security.
  12. There is a difference between “improving the strategic relationship between everyone and the bad guys” and “defending my organization today”.  This difference must be consciously and explicitly articulated and enforced – the framework and EO, in my opinion, are aimed at the former while many practitioners are so busy fighting fires that they’re focused on the latter. This shows in resulting work.
  13. The length of time it takes to gather consensus opinion on things like the framework – which is filled with content that for the most part already existed – supports the view that there is an underlying reference model needed to get all parties on the same page that has not been articulated, documented, or socialized.
  14. Cybersecurity is ultimately a quality assurance problem that consists of a rate (flaws over time).  Rate problems cannot all be solved by doing more of the same.  I cannot pay someone enough money to, say, flap their arms and fly.  The most helpful frameworks, instead of focusing on how we are flapping our arms, actually spend time to break down the problem into it’s most basic pieces and help us solve for flight in an engineered, not ad hoc, way.
  15. Until we’ve solved the quality problem, risk management is a red herring. Risk management allows us to identify risks so that we can pivot towards protecting ourselves against those threats we care about most.  But, if our organizations are too immature to pivot – have too low a quality of security – the prioritization process will not help us.


Based on the above assertions, it should be clear that I think not. Originally, I was very hopeful.  The executive order spelled out the need for outcome objectives which could be met by using the framework.  There was talk of linking these objectives – potentially derived from approaches like DHS’s CARMA – to business maturity domains (like those found in C2M2.)  This was exciting and would have provided an approach to deriving a critical knowledge intersection that is so often lacking in large scale security efforts: non-security specific business needs with non-security specific business structure.  This intersection is what helps clearly communicate security to executive stakeholders while allowing those stakeholders to provide the rest of the business with clear success metrics and implementation rails.

Instead, the framework does not help define outcomes, it supports technologists while making vague references to business, it has no methodology or philosophy that speaks to cost-effectiveness, and it completely fails to describe a functional link between cyber and business risk (although I do not believe the two should be different).  The language is written in the same terms as other control catalogues that business leaders do not understand (raising the level of abstraction is not the same as putting it in business terms), and the structure of the document reflects a cybersecurity practitioner’s view of incident response, not the structure of a business.  When it comes time to implement the framework, it will suffer from exactly the same difficulties as other control catalogues.  The control language is vague enough that it will be difficult to use it as a “Rosetta Stone”, although it could be useful as a link between other frameworks for contract purposes.

We needed a strategic, business-centric framework to help conceptualize the different aspects of security that were not being addressed by other security-specific documents. We needed to structure cybersecurity conceptually so that everyone can get out of each other’s way, normalize the conversations, and solve for reduced risk.  Instead, we ended with – in my opinion – a rehash of existing material that gives, at best, lip service to some of the other higher level considerations.

Ultimately. I believe the framework does little to change business as usual. For the next round, I believe we should look at this version of the framework, turn it inside out, and include everything except what is in this version.


Despite the nature of the framework being a miss on what I think we needed, it at least doesn’t attempt to go very far beyond being a control catalogue (despite language suggesting it does.) This allows us to take the base and create products on top of it that can provide different, more targeted views – such as a re-write for small utilities. I hope there will be a space created for framework users to store and share these “views” or “lenses” that they create.

One substantial structural problem, though, is the incident response functional layout.  There are many reasons why I believe the functions will make consistent implementation difficult, but that would require a longer document – so I’ll leave this suggestion:  Re-frame it around organizational structures and roles.  This will allow different people and parts of an organization know what they need to be doing, how they need to do it, and how they fit into the larger picture. This is a much more business friendly approach and will actually improve efficacy of implementations.  It also creates a better metrics environment by allowing the treatment of role/responsibility failures as vulnerabilities which can be managed by the C-suite.

Another suggestion is to, in the future, take a modular policy management approach by letting the framework speak at a very high level and then create more specific technical/process specs which can be updated independently of and much more frequently than the framework itself. This shouldn’t be too much of a stretch from how it’s written now. This will help solve the “it’s too high level!” “it’s too specific!” problem and make it easier to maintain over time.


While my above comments may be read as exceedingly critical, I still view the entire process as a success.  As first round efforts go, the government and industry came together in what is, by typical measures a rush and created a viable first round product.  This initiative, the resulting momentum, and the earned goodwill and trust are perhaps more key to the reduction of cybersecurity risk as any framework that could have been created.  We have done good work. Further, it would be naive to believe that a first round effort such as this would product a document too far off from center and I am looking forward to the next round.

On that note, and although most of these comments have been written from my own, individual, perspective, we (Energysec) as a non-profit community in the electric sector, believe strongly in this process, the framework, and the ecosystem going forward.  In particular, we believe non-profits may serve in key roles.  We are interested in providing input into how this framework gets implemented and how to manage/support the required trusted communities that will be involved.

Thank you again for your time, consideration, knowledge, and patience.

Jack Whitsitt | Energysec | | | | 12/13/2013

Well, I’ve been waiting awhile to be able to write this (see future post).  Finally, I can:

It’s always interesting dealing with the somewhat schizophrenic nature of government messaging.  While I understand the constraints, the risks, and the realities of trying to run a free-for-the-private sector service that actually DOES something in the government, it was always a little disheartening to hear (or read) people suggest that the government wasn’t doing anything for some of our cyber security problems, that it didnt have the services available, or “Well, I heard DHS started ICS-CERT, but I think they shut it down?” And, with the media so often just not getting it – and people so often not doing basic research – this happened more frequently than it should.  So, now that I’m in the role of customer here (and not on the floor there), I can finally say:

If you’re an asset owner, a vendor, a service provider, a customer, or otherwise a stakeholder in private sector or government critical infrastructure / key resources, you should be aware of CSSP and ICS-CERT (ICS-CERT has been functioning, in its current form, since earlier this year).

To start with: The Control Systems Security Program (CSSP) is an offering out of Homeland Security which:

“attempts to…reduce industrial control system risks within and across all critical infrastructure and key resource sectors by coordinating efforts among federal, state, local, and tribal governments, as well as industrial control systems owners, operators and vendors. The CSSP coordinates activities to reduce the likelihood of success and severity of impact of a cyber attack against critical infrastructure control systems through risk-mitigation activities.”

This includes providing a FREE cyber security assessment tool, onsite assessment visits, and the well-run Industrial Control Systems Joint Working Group (ICSJWG) and its associated conferences. CSSP also provides a variety of free-training in Control Systems Security, both locally in DC as well as, for it’s hands-on Red/Blue Team training,  in Idaho Falls.

Then, providing a tactical operational arm to the more strategic CSSP, ICS-CERT is a fully functioning free CERT service for your CIKR organizations. ICS-CERT will, as part of its mission:

  1. Provide onsite fly-away technical incident response
  2. Perform digital media analysis on media potentially affected by an incident
  3. Coordinate the responsible release of vulnerabilities (involving third party researchers, vendors, etc.)
  4. Provide timely situational awareness
  5. Coordinate national response, via its seats in the National Cybersecurity Communications and Integration Center (NCCIC), with US-CERT, NCC, Law Enforcement, and other organizations.

All you have to do, basically, is ask.  They’ve assisted, during my tenure, quite a few organizations – large and small – and continue to do so.

(Importantly, ICS-CERT has neither a law-enforcement NOR a regulatory function. Their mission is to assist you in defending yourselves and responding to incidents. Your data is, and remains, yours, in any interaction with them. )

And you thought the government doesn’t do anything for cyber security :)

To contact ICS-CERT:

  • Call the ICS-CERT Watch Floor: 1-877-776-7585
  • Email regarding ICS related cyber activity:

Their website is:

I normally don’t have much to say here about my day job (partly why you’ve seen more of a focus on art), but I thought (since I’d been previously linking to the DHS Control Systems Security Program pages) that it was worth mentioning that ICS-CERT has its own website these days:

Take a look at it if you’re in the control systems / SCADA and security/emergency space (particularly with regard, but not limited, to cyber).

Edit/Update: Now that I’m no longer there, I do have a brief take on the subject and a summary of information HERE

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