You are currently browsing the tag archive for the ‘White House’ tag.

Per last post, I’ll be at the White House today for the rollout of the NIST Voluntary Cybersecurity Framework that many of us worked on last year.  You can see it live today at 1pm here:

http://www.whitehouse.gov/live

Also, I’ve been working on my alternate version which will cover the 80% space that the NIST facilitated framework doesn’t.  Particularly, I’m focusing on the environment that leads to security.  My framework will help minimize the space your security teams have to cover by addressing how and where the business vulnerabilities that lead to technical vulnerabilities are introduced.  This approach should both reduce security program costs while at the same time making them more effective.  Expect a draft this week.

Advertisements

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

COMMENTS ON THE NIST PRELIMINARY CYBERSECURITY FRAMEWORK

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.

PROBLEM SPACE

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.

IS THE FRAMEWORK THE TOOL WE NEEDED?

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.

THE TOOL WE BUILT 

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.

EXTERNALITY/ECOSYSTEM

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 | jack@energysec.org | |http://twitter.com/sintixerr | 12/13/2013

Over the past week, I’ve had a number of questions from industry, people at various cybersecurity conferences, friends, and…well..my job….ask me about my opinion on the executive order.  Here are some interpretations in the form of a FAQ.  It’s worth mentioning that, although I am familiar with the culture, language, and *some* small number of the actual background discussions here, I have no ownership nor formal role in most of it. Just some wacky alien putting some other wacky aliens’ behavior in terms more earth-like. If I use definitives like “is” or “will” please read an implied “my best educated guess” into them. 

1. What is the Executive Order and why was it issued?

This is a two prong answer. First, obviously it was absolutely a political goad to congress to write legislation and to poke at the Republicans. However, more importantly, it is also potentially a very valuable order that was seriously thought through and that will be used.

Think of it like a mother (the White House) telling kids (DHS, SSA’s) to “clean up the house”.  Based on existing house rules (overarching critical infrastructure directives/laws), she expects it will be done and goes off to handle other things.She comes back to find out that the kids of swept once or twice then went on to xbox, pushed stuff under the bed, or made more of a mess of the toy box trying to clean it than it was before.

Mom comes back and says “Ok, I left you to your own devices, here are the specific ways – again within the larger context of house rules – you are going to clean up. In the case of cyber security, the White House has said: You – DHS and SSAs and everyone else – are going to remove barriers to information sharing, work with our customers (industry) to build some coherent approach to solving the problem to our satisfaction  – some standard way of organizing the whole mess, and you’re each (especially you SSA’s!) are going to create explicit privacy and civil rights protections or else you fail.

2. What are the main thrusts of the Order?

1) Improve Information Sharing

2) Use business-function driven risk analysis to determine priorities

3)Create a framework of standards for reducing risks from cyber security issues to critical infrastructure

4)Engage industry to the greatest extent possible, and assure privacy and civil liberties are embedded in the entire process.

Whether any of this will be successful or remain uncorrupted is a different question.

3. Could this in any way infringe on individual freedoms if misinterpreted?

The short answer is “not any more than before”. DHS messaging is that privacy and liberty assurance is one of the three primary focuses of the EO. The Executive Order relies on existing government privacy and civil liberties mechanisms and embeds them throughout the order. Whether or not you think those mechanisms were sufficient is one question, but the EO doesn’t make them worse or better.

4. What will the “Framework” described be?

Based on comments from NIST: The framework will includewhatever will achieve effective cyber: processes, technologies, architectures, concepts, specifications, etc.  It is intended to be layered and include broad principles, common practices, and sector specific realities.

The role of NIST is to support the industry development of the framework.  The government will depend on the actions of the private sector after sharing, up front, performance goals. NIST is being engaged because it has experience gathering lots and lots of input, but this will NOT be a typical NIST thing.

The aim of the framework approach is to enhance adaptability, with cost and impact to economics of business being an integrated explicit part of the conversation.

Additional benefit is that, by increasing interoperability of requirements, concepts, expectations, etc, baseline security can be driven to market/products (my comment: which has been a vendor/industry complaint often voiced)

Moreover, a goal of the EO – both in context of information sharing and the framework – is harmonization of efforts (this was repeated extensively and resonated with my experience in the dialogue) – particularly nby the federal government (which, again, has been a substantial private industry complaint).

5. Standards? What is meant by standards? That sounds scary!

Not as much as you’d think. Based on comments from NIST: Generally, common basis of comparison…some are performance…but some are norms to promote collective collaborative action. These latter are developed by industry and what the EO is referring to. In other words, the Framework of Standards is meant less to be comparative and more to allow everyone and everything to be working together.  (Jack’s note: I’ve said for years there should be a Chinese menu of options selectable by environment and risk, this looks like it might be going down that path).

6. What are some simple things to know ahead of time that I might not already?

There are laws, mandates, and programs on the books now and have been for years.  This includes strategic planning, incident response, information sharing, and engagement. The sector specific agencies’ jobs(SSA) are to take broad cybersecurity capabilities within DHS and apply them in sector (industry) specific ways.  All major players in industry have been actively engaged in the dialogue so far.  There have been certain cultural, process, political, perception, legal, and conceptual barriers to progress despite existing work and engagement.  The Executive Order attempts to rectify these barriers while keeping in tact most of the fundamental structures already in place.

7. How does the new PDD relate to the Executive Order? 

The PDD is an update/replacement to HSPD-7.  These documents are not cyber specific, but are the policy  context under most critical infrastructure protection activities that the federal government engages in (including cyber security) are driven by.  The old HSPD-7 and the National Infrastructure Protection Plan from DHS which supports it have been around for years and understanding them is necessary to understand a lot of the intent behind the executive order.

8. What is an SSA, as defined by HSPD-7, the new PDD, and the NIPP?

SSA’s (ref’d above) are the sector (Energy-DOE, Transportation-TSA, Chemical-DHS, etc) specific agencies who are the functional owners of engaging their segments of the private industry in gov cyber security efforts. The EO and the new-PDD update their responsibilities from what they were under the old HSPD-7, but they’re similar.  For reference, a paraphrased overview of the old SSA responsibilities is to:

  • Use mechanisms like Critical Infrastructure Partnership Advisory Council (which allows gov/industry cooperation) to bring Sector Coordinating Councils (made up exclusively of non-lobbyist private industry) together with Government Coordinating Councils (Sector Specific Agency points of contact) to work together on planning the reduction of risk
  • Encourage organizations with information to share with those who need it and encourage development of information sharing programs and mechanisms
  • Promote education, training, and awareness within industry in coordination with other government and private sector partners
  • Identify, prioritize, coordinate federal Critical Infrastructure Protection activities in sector – ie, make sure the government is organized and doesn’t overburden the private sector
  • Appraise congress of industry’s current status and progress in reducing risk, based on engagement and feedback from industry
  • Increase integration of cyber security efforts with other all hazards protection and response programs – in other words, since cyber attacks can have physical implications, make sure first responder type organizations are working with cyber ones
  • Develop and implement sector risk management program (within the government) and framework and use to determine risk priorities of sector and coordinate (not require) risk assessment and management programs with industry. This means create a process by which, facilitated by government, industry can get together and figure out where it is and what it’s priorities

9. How does CISPA relate to this?

An executive order cannot change already legislative assigned federal responsibilities, so everything the EO directs occurs under existing mandates and laws.  Further, the EO addresses information sharing AND getting the government’s overall act together in cyber security.  CISPA, on the other hand, is aimed (for better or worse, this post isn’t for my opinions on it) on removing legal barriers to information sharing and addressing specifically problems associated with industry cybersecurity needing to intersect with the intelligence community.

10. What guarantee do we have to transparency in any of this?

Workshops kick off in April.  NIST has questions to industry on its website and will be reaching out further (more proactively than “on the website”) in the near future. If you read my earlier NIST post, you’ll see transparency and participation are core, not tangential, tenets here and are one of the things that will (or is intended to at least) distinguish this from past efforts. Further, if you have been on any of the DHS calls with industry, every single conversation revolves around getting more and better industry involvement. They are very serious about it.  Finally, in my own work with some of this (which is tangentially related), transparency and engagement have been priorities I’ve seen.

11. Indeed it’s written with the basis that Government will continue to be the determining data librarian for cyber threats.

Over and Over and Over industry tells gov “we need better threat info”.  Most of EO not dealing with the framework is written to that end – it primarily deals with pushing data TO the private sector because they have requested it. However, post-order messaging has (correctly) been: Look, we don’t have a classified pot of information at the end of the rainbow that’s going to save the day. Industry, you guys know about yourselves way more than we do – or you should.  If you don’t share, that’s fine, but we can’t help you unless you help us to do it.

I don’t like the disproportionate focus on Information Sharing. I think it’s a waste of time, but we collectively have created this stupid beast. I might be a red herring, but it’s our collective red herring.This deserves a longer treatment than a couple of sentences, so come see me talk about it at SOURCE Boston

12. Why is the Cyber EO so obtuse? And while the PPD adds context – it’s clear that we require more (and more) clarity

Much of the obtuseness is because a) some is to be defined later by b) federal agencies who will get very clear direction from those in the WH charged with implementing the EO within the context of c) existing language on the books and in response to d) specific beefs from industry and dialogue failures in the past. What most people lack is the appropriate context from which to interpret it, since most people are not critical infrastructure owners and operators or feds who have been engaged in the discussion. Much of the insight Im trying to provide here isn’t direct experience with the EO iteself, but the cultural language which has developed in the civilian space on the topic of critical infrastructure protection over the past several years.  It’s not understood well outside of Washington, but those it is speaking to understand it.  This is a huge problem and one I’ll try to address in Boston

13. Is this more of the government telling private sector they’re coming?

Gov’t is already there: HSPD-7, NIPP, SSA’s, CIPAC, CSCSWG, CNCI, NCCIC, foobar.   Regulatory capability already there: TSA, DOE(NERC CIP), etc. This EO speaks to and sorts out this *existing* stuff in one prong and tries to sort out information sharing barriers in another prong (barriers which, right or wrong – mostly wrong – industry has cited over and over and over as the reason their cyber sucks)

14. Why do we have any faith that Government has the agility and consistency to get it right this time?

We don’t. but, the way the framework components are laid out, we have an interesting opportunity to force it to work by the order’s focus on creating real consensus business-driven requirements. In particular, I believe cyber security is a quality assurance problem over unbounded time driven from business priorities and is almost 100% a human-centric problem.  There might be space here for that conceptual shift to occur.  More on that later, possibly in Boston

15. Should the Cyber EO have been so broad? Look at the “Designated Critical Infrastructure Sectors and Sector-Specific Agencies” list in the PPD.

Don’t forget that the PPD is based on years old definitions and, more importantly, is an all-hazards list primarily focused on physical attacks. In large enough scale, most things are critical in the terms of the broader discussion.

The trick is, for cyber, determining what within those spaces is critical. It’s a different functional discussion – as this is all laid out – than which sectors are critical. That’s handled in a process – a version of which I’ve been facilitating at a sector level for the past year – that is designed to base decisions on business driven threat scenarios.  It’s not perfect, but it’s a huge improvement from past methodologies.

16. If and only if (IFF) the Cyber EO was really meant to get action to answer these questions – then it should not have been issued so broadly, so politically charged, and otherwise tied to SOTU the way it was.

Agree. It’s over-politicized – but that gets into questions of its effectiveness and clarity in the current political and cultural environment, and that’s out of scope here.

17. Why not leverage the bodies of work existing up-front?

Because the process of engagement in finding and applying those existing bodies of work is the key element of this part of the EO, not the outcomes themselves. It’s an attempt to build in continuous flexibility and applicability in changing environments and compared to differing and dynamic priorities.  Think “it’s not the destination but the journey” here and add on “and the requirement to iterate through multiple journeys as a lifestyle”. The mechanism NIST and the collective gov builds to continuously engage industry in the development and adaptation of the framework are where our real opportunities to make this valuable come in – but we need to work together coherently. More in this in Boston.

Also see this document from NIST: http://www.nist.gov/itl/cyberframework.cfm

18. What makes this a compelling DHS issue instead of economic development, science, or other component of Government?

Because the EO can only really address already existing legislatively assigned authorities. This EO is a goad for further legislation, and that might change the agency assigned responsibilities. That said, I actually agree this should be a DHS issue – no other agency has the type of broader mission required to effectively coordinate cybersecurity in the broad terms it requires – NSA would be one of the worst choices, since their core mandates are, in many cases, only of use in terms of focused support.  Think correlation with physical and geographically dispersed response and coordination.  The FBI, similarly, would be a terrible choice since their mandate is “prosecute and convict”.

19. What about regulation of industry?

There are a number of agencies who *already have* regulatory authority over private sector critical cyber infrastructure – some have used it, some haven’t. The EO asks that they use the new processes in the EO to reevaluate whether they should regulate and how if they don’t now and the effectiveness of any regulation if it’s already in place. Every two years, the government is required to check with industry to make sure any regulation is a) effective and b) not too burdensome.  In my opinion (based on work with some of the processes which will be used),  this is much less likely to result in additional regulation than is suspected. (This is because the processes attempt to be more empirical and data-informed than the more speculative and subjective attempts in the past.)

20. Why haven’t I heard about any of this and why does it not resonate with me?

So much of this has been driven by lobbyists and industry associations….unfortunate in many cases…but almost impossible to get substantive input from more fair representation.  The reasoning behind this is something I’ll cover in Boston and it’s something we need to culturally change together – and we can.

UPDATE: I am much happier with how the EO Framework is going to play out based on subsequent messaging by NIST and DHS.  What I said below is still accurate conceptually, just the EO is more ++ in these terms than the — I thought.)

(CAVEAT: I wrote this in about 10 minutes. Please Understand if it’s not complete or poorly worded)

So,  the Executive Order (full text HERE ) looks like it is more focused on an Asset Based risk perspective than a Functions and Business centric one – particularly in the definition and use of the upcoming NIST framework and the determination of criticality. I might be wrong, and a lot hinges on what the NIST framework ends up looking like, but the language as it sits now has me….watchful.  Some thoughts on why an asset-centric approach is problematic:

1. Attackers use different paths to achieve different real world objectives (things blown up, data stolen, etc)

2. Asset criticality therefore changes according to the path the attacker takes, which objectives are chosen, and which defenses are in place. In other words, asset criticality is dynamic.

3. Assets can be protected to a very high level without any assurance whatsoever that undesired consequences are not caused by attacks.

4. Functions and business objective centric protection approaches (such as DHS’s CARMA) linked to capability domain frameworks (such as the ES-C2M2) tied into technical assessments (such as DHS CSET) assure that protection programs and measures are working together to reduce actual dynamic tactical and strategic risks and reduce the risk of ineffective controls inappropriately targeted and configured.

5. Asset centric approaches create static defenses which attackers can work around while functions and business consequence focused approaches actively address the reality of how attacks occur, where controls should be placed, and to what level they must be configured.

6. Functions based approaches also create a more lexically coherent framework that assures all stakeholders are having the same conversation.  Asset Based approaches, though speak to fixed points where each stakeholder may have a different perspective on the goals of any controls.

7. Functions and business consequence driven frameworks can also be more effectively used to determine the success or failure of cybersecurity efforts and provide more realistic and useable metrics and goals.

FURTHER CONTEXT **HERE** AND **HERE** AND **HERE**

Follow me on Twitter

My Art / Misc. Photo Stream