You are currently browsing the tag archive for the ‘Cyber Security’ tag.
Ill have a longer discussion of SIRACon later, maybe, but for now, you can find my talk slides here:
Some of it is old material, but some of it is new. I really like how it’s fitted together and ordered here.
I got to give about…half…of this presentation this week near Seattle. Obviously it’s missing a lot without the verbal presentation, but I think it’s a good one and maybe folks can get value out of the deck.
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.
- WELCOME AND INTRODUCTION
- Ice Breaking Exercise
- FRAMEWORK THEORY: Structuring Information to Enhance Value
- Defining Frameworks
- Four Framework Design Principles
- Label Awareness: Types of words and meanings
- Protocol Stacks: Using Layers to Abstract Common Framings
- Model/View/Controller: Humans are Systems, Too
- Stages of Value: The Means Can Be As Important as the End
- SECURITY THEORY: Creating a Consensus Model
- Defining Cybersecurity as a Problem: A Parasitic Model
- 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
- FURTHER STRUCTURAL CONSIDERATIONS: Helpful Linking Concepts
- Common Terms & Parenthetical Comparisons
- Kill Chains
- Metrics Defined
- Control Convergence
- Development Lifecycles
- “Capabilities” Defined
- Risk Management
- CONNECTING FRAMEWORK THEORY TO SECURITY THEORY
- 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
- Adjust the Model
- EVALUATING THE NIST FRAMEWORK AND C2M2
- 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.
- DAY-LONG FACILITATED WORKSHOP
- 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.
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:
- Creating a business environment which limits the window of opportunity provided to actors in which to achieve their objectives
- 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:
- Scope and Completeness Assessment
- Coverage Validation
- 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)
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.
I just wrote-up the following for someone in the Communications Sector. It’s entirely stream-of-consciousness and un-edited, so forgive the language and grammar shoddiness, but as far as content goes, I think it sums up very well how I think of cybersecurity at an organizational (as opposed to industry/sector/national) level right now:
The vulnerabilities hackers exploit are created in the design, implementation, operation, or control of your business’s strategy, resource allocation, capability maturity, and value chain. These vulnerabilities, created by your business decisions, allow hackers to repurpose your business and infrastructure – in part or entirely – to their own ends.
Therefore, cybersecurity can be said to be “The management of all business decisions made by your organization in a way which will inhibit malicious actors from using technology to repurpose your infrastructure or value chain for their own ends.”
While much of the focus on security has been on security specific controls and roles, those controls and roles only help to temporarily mitigate security problems. True improvement in effectiveness and lowered costs will only come if the rest of the business manages decisions in a way that reduces the number of business and technological vulnerabilities that your security programs must account for. These vulnerabilities can be introduced in typically “non-security” areas of your business such as product release timing, IT product selection, change management discipline, cross-team communication, business process design, policy compliance culture, service and product feature selection.
And, so, use of security Frameworks such as the new NIST Voluntary framework, while important, only accounts for security control at one layer of several interdependent layers of control and will not, by itself, successfully protect your organization. Business leadership priorities, business capability management, business process and IT architecture, operations, education and culture management, and classic “cybersecurity” must be paid equal attention and be tightly integrated.
A tight integration of these areas will not only reduce the overall number of vulnerabilities being introduced that are exploitable by hackers, but will also allow the organization to more effectively identify and pivot toward defending against new threats and attack vectors. Without this overall business maturity, no threat data will ever be actionable because there is simply too much area for your security teams and programs to cover. However, with the entire business working together to minimize exposure, your security team will be able to use threat based intelligence from external organizations to help them understand what gaps remain, mitigate those threats in the short term, and then inform business leadership of areas of vulnerability which might require longer term strategic organizational change to mitigate.
Ultimately, this should be seen as the development of two risk management life-cycles: One which looks at long term threats to your organization resulting from vulnerabilities created by organizational decision making, and another which focuses on short term tactical threats to your infrastructure. These two risk management life cycles can then inform each other without replacing each other.
In the longer term, business management lifecycle, typical “barriers” such as operational, market, consumer, technology and policy considerations should be considered “cybersecurity vulnerabilities” to be managed. Metrics could include such measurements as “number of times a security control was pushed to a later release in order to accommodate product release commitments made by marketing.” Security improvement initiatives could focus on changing organizational processes and decision making to the point where product release commitments and security control introduction were in conflict less often.
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:
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.