You are currently browsing the category archive for the ‘Executive Order/NIST Framework’ category.

Edit: This class has *significantly* changed, expanded, and improved since i posted this. Ask me about it. 

As I may have mentioned…a lot…in several forums….including my previous post here…I’ll be teaching a cybersecurity framework class this year around the United States.  It will use the NIST Framework and ES-C2M2 as foils, but it won’t be “training” for them.  What it will REALLY be about is using a structured approach to scope out what cybersecurity means from a business perspective and how to apply existing practices and thoughts to actually reducing security risk, instead of just building the same old security program over again and hoping for the increasingly unlikely “best”. Anyway, find dates and sign up at the following link and see the Class Abstract and Outline below. (Also, at the very end, find two of the key custom models I’ll be using): http://www.energysec.org/upcoming-live-events/

Practical Cybersecurity Frameworks Applied to Real World Problems

 OVERVIEW This 2-day class – the first of several throughout the U.S. in 2015 – is intended for those leaders, decisions makers, and technologists who feel that they are lacking a usable bridge between the technology and business aspects of cybersecurity and wish to do more than simply build a standard security program and hope for the best.

A three-part class, students will begin by exploring the theory behind using structured information to create value and the theory behind cybersecurity as a business problem and discipline.

With that theory as a foundation, the class will then use two existing frameworks – the new NIST-Facilitated Cybersecurity Framework and the Department of Energy’s Capability Maturity Model (C2M2) – as foils for discussing how best to build framework bridges between “Security Programs”, “Risk Management”, and “Business Value Management”.

The final day of the class will be used as a facilitated workshop in which the class will either solve “conceptualized” real world problems or, if appropriate, bring their own existing problems to the table to work through.

We hope that students will, at the end, feel they have gained a deeper understanding of cybersecurity and frameworks as they pertain to their own fields than they would have received in more traditional “Training” in products, technologies, and frameworks and will be able to apply these new perspectives to enhance the job they do in the real world.

More than anything else, we hope students will find value in spending two days considering cybersecurity in ways they might not have before.

Students should also be aware that, despite some use of jargon, no technical experience or security expertise is assumed and each class will be tailored to the experience levels of those in attendance wherever possible.

CLASS OUTLINE

  1. WELCOME AND INTRODUCTION
    1. Ice Breaking Exercise
  1. FRAMEWORK THEORY: Structuring Information to Enhance Value
    1. Defining Frameworks
    2. Four Framework Design Principles
      1. Label Awareness: Types of words and meanings
      2. Protocol Stacks: Using Layers to Abstract Common Framings
      3. Model/View/Controller: Humans are Systems, Too
      4. Stages of Value: The Means Can Be As Important as the End
  1. SECURITY THEORY: Creating a Consensus Model
    1. Defining Cybersecurity as a Problem: A Parasitic Model
    2. Scoping Cybersecurity as a Discipline: Contrasting Perspectives
  • COMPARISON #1: VULNERABILITY INTRODUCTION VS. EXPLOITATION
  • COMPARISON #2: QUALITY MANAGEMENT VS. RISK RESPONSE
  • COMPARISON #3: HUMANS VS. TECHNOLOGY
  • COMPARISON #4: STRATEGY VS. TACTICS
  • COMPARISON #5: RISKS FROM VS. RISKS TO (CIA)
  • COMPARISON #6: ENABLEMENT VS. PROTECTION
  • COMPARISON #7: DEFENDING VS. IMPROVING
  • COMPARISON #8: ONE-TIME VS. CONSISTENT BEHAVIOR
  • COMPARISON #9: INCIDENT VS. EXPOSURE MANAGEMENT
  • COMPARISON #10: ERROR VS. DEFAULT HANDLING
  • COMPARISON #11: PERCEPTION VS. FACT
  • COMPARISON #12: EMERGENT VS. PREDICTABLE STATE
  • COMPARISON #13: CYBER VS. PHYSICAL SPACE
  • COMPARISON #14: EFFICACY VS. COMPLIANCE
  1. FURTHER STRUCTURAL CONSIDERATIONS: Helpful Linking Concepts
    1. Common Terms & Parenthetical Comparisons
    2. Kill Chains
    3. Metrics Defined
    4. Control Convergence
    5. Development Lifecycles
    6. “Capabilities” Defined
    7. Risk Management
    8. Others
  1. CONNECTING FRAMEWORK THEORY TO SECURITY THEORY
    1. Demonstrate a <Model> containing elements of both the framework and security discussions to be used as a Reasoning Aid throughout the remainder of the class
    2. Adjust the Model
  2. EVALUATING THE NIST FRAMEWORK AND C2M2
    1. Using the domain models discussed earlier, the class will evaluate the structure and content of both the NIST Framework and the C2M2. We will describe use cases, dependencies, how they can be linked together, and how our own class models can be used to fill the shared gaps in both frameworks. The intent of this section is not to critique other work, but to understand the concepts and work needed to build custom integration approaches and frameworks that will help students more effectively utilize existing work to reduce overall risk in their own environments.
  3. DAY-LONG FACILITATED WORKSHOP
    1. We will scope a theoretically-real security problem, use framework design principles, and eventually (hopefully!) arrive at successful risk reduction approaches over the course of the day. This workshop may flex according to student need and desire.

securityconsiderations2 hackervaluechain2

As you may have heard, I’ll be teaching a cybersecurity framework class around the country this year. It will be fun, educational, practical, and unique.  Im going to try to open the two day class up with a LEGO exercise and we’ll close with a day long practical workshop where we solve a problem or two with a customized integration of existing frameworks.  In between, we’ll talk about the theory of security, the theory of frameworks, and do deep dives into the ES-C2M2 and the new NIST Cybersecurity Framework (#NISTCSF).  If this sounds worthwhile – and I promise it will be to techies, executives, and in-between – check out the detailed description here and look for a class near you here.  In the mean time, as a teaser, here’s one of the diagrams I’m working on for the class. It’s a parasitic model of security that tries to communicate that security is neither about technology nor can its sustained improvement be effectively modeled in terms of “incidents”.

hackervaluechain2

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)

SCOPING FRAMEWORK USE

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.

FRAMING THE FUTURE (From CForum)

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.

Here is the actual slideshow from the #NISTCSF Webinar I did:

Download it here:

http://www.slideshare.net/sintixerr/nist-cybersecurity-framework-background-and-review-jack-whitsitt

The recording of the webinar is here:

http://www.energysec.org/events/webinars/webinar-interpretations-and-forecasts-looking-beyond-rumors-myths-and-misunderstandings-about-the-new-nist-cybersecurity-framework/

This is OVER but you can see the recording HERE: http://www.energysec.org/events/webinars/webinar-interpretations-and-forecasts-looking-beyond-rumors-myths-and-misunderstandings-about-the-new-nist-cybersecurity-framework/

 

Interested in hearing a more lengthy – and more frank – NIST Framework discussion that also includes both historical context and REAL security discussion? Join me as my employer and I host a webinar March 5, 2014 at 1pm ET.

Registration is HERE.

The official description follows this blurb, but you should also know that in addition to the usual Energysec community, I’m also going to try and aim this webinar at groups like IATC (I Am The Cavalry) and NovaHackers.  As such, not only will I run down my written framework assessments in more detail,  but I’m also going to try and help these other communities understand the levers the framework uses, the state of dialogue that led to it, and how to get engaged in the ongoing process.  Please come prepared to hear more than you will elsewhere. Some pre-reading, if you are so inclined, can be found in my comments on the preliminary draft HERE.

Interpretations and Forecasts: Looking Beyond Rumors, Myths and Misunderstandings About the New NIST Cybersecurity Framework

 
 On February 12, 2014 the White House released the first version of the NIST Cybersecurity Framework. NIST was directed to create this framework in response to Executive Order 13636, Improving Critical Infrastructure Cybersecurity. Since the preliminary framework was released last October, many rumors have been going around about what the framework is or is not. Additionally, a number of organizations have been making what we believe will likely turn out to be inaccurate representations about how the framework should be used and what expectations will be surrounding it.
In this webinar, we will explore a number of the more common scenarios we’ve heard recently and attempt to provide educated but unaffiliated realism around the document, its uses, its gaps, and what’s going to happen moving forward.
 
While this will be an editorial webinar, and we cannot claim to represent an official stance on anyone’s behalf, we believe our experience in this area and lack of vested interest will provide attendees with the tools – lenses, if you will – with which to better interpret what you hear from other third parties.

Well. Long overdue, but here nonetheless, is the next draft of my NIST Cybersecurity Framework “B-Sides” (Alternate). It’s just a draft, but it builds on the last one I posted and is designed to provide a much more comprehensive and much more effectively structured beginning to a framework than the one industry created with NIST, DHS, and the White House.  It’s also substantially broader and, I think, more effective than some of the other alternatives that have come from industry.  It’s not “complete”, but I believe the structure is the key to a successful framework and I think I’m close to nailing it here. Check out the image at the end of this post. You may also want to pre-read THIS:

The framework consists of 5-components that provide the “Model” elements that go into cybersecurity management at an organizational level:

  1. Business Consequence Framing
  2. External Threat Framing
  3. Business Vulnerability Introduction Assessment
  4. Business Quality Management
  5. Cyber Vector Control

Each of these components are co-dependent on each other in assuring that cybersecurity is effectively managed.  They will each contain sub-elements that can be attached to specific practices (processes/controllers) and views.  (Note: the components are not completely filled in with these sub-elemtns – they just contain quick swags.)

Of the components, The “Business Vulnerability Introduction Assessment” is the most notable and, in combination with “Business Quality Management” it represents one of the largest and meaningful gaps in cybersecurity thinking today – including the #NISTCSF.  The premise is that business decisions lead to security vulnerabilities and that the frequency and type of decisions that introduce vulnerabilities can be identified, quantified, and managed through a quality assurance program. Further, doing so will reduce the business’s exposure surface and allow their cyber security, risk management, and compliance programs to more effectively (with regard to both risk reduction and cost reduction) target areas for specific improvement in a rapidly evolving world.

The Processes (including roles and responsibilities within an organization) by which these model components are executed and the Views in which the associated information is stored and made available to appropriate stakeholders will represent two critical, but future layers to this framework.

Finally, almost all classic “cybersecurity best practices” such as those existing in NIST 800-53, the SANS 20, etc. are to be found in the “Security Program” sub-element under “Cyber Vector Control”.  This relatively “small” position in the overall framework does not detract from the importance of those best practices – they are, after all, the sharp edge of the sword – but their placement should be a strong message about the amount and type of underlying support from the rest of the organization that is required to make those best practices sustainable, efficient, and effective.

If this seems simple, I’ll grant that. There are YEARS of thought and experience going into distilling a complex topic into what is essentially just 5 boxes. But,  if that seems obvious or innocuous,  I’ll disagree. There are *many* layers of complexity supporting this model, why it’s framed this way and not another, and (more importantly) still more layers of complexity that this model **will enable** through its simplicity. You can find the older draft HERE

businesscyberframeworkb

HERE BEGIN MY RESPONSES TO COMMENTS SO FAR THAT ARE ILLUMINATING

1. SV Said: “it puts risk management as a sub-component at the bleeding edge; it definitely does not belong there”.  I responded with:

I would not categorize the bottom element as the bleeding edge. Instead, it is the edge that steers the ship and that gets things done. It loops back and informs the very top of the stack – the intersection of strategy and and environment. Further, and this is a critical point for me, you can have risk management without the other elements happening, but it won’t be very good risk management. Think of it like a sports team. You can get a bunch of people off the street, teach them the rules, and they’ll play a game. But if you want them to win, they need to run laps. Practice with the ball. Play as a team effectively in practice. In other words, they need to have discipline and be conditioned. The other elements – Business Consequence Framing, External Threat Framing, Decision-Vulnerability Introduction Assessment, and Business Quality Management are the fundamental elements that allow the organization to not only more effectively inform risk management, but also to more effectively take advantage of the benefits of risk management in a way that allows it to pivot toward and address prioritized threats. Again, how these place relative to each other in an organization is another “View” of the framework that is not complete or shown here.

Follow me on Twitter

My Art / Misc. Photo Stream

20170417_164900

20170411_203014

phoenixhike - 4

phoenixhike - 3

phoenixhike - 2

More Photos