Jump to content

Jack Whitsitt

  • Content count

  • Joined

  • Last visited

About Jack Whitsitt

  • Rank

Profile Information

  • Gender
  • Location
    Washington, DC and National
  • Interests
    Frameworks, Public Private Partnerships, Creating Strategic and Sustainable Cybersecurity Quality Improvements
  • First
  • Last
  • Company Name
  • Sector
  • Country
  1. Current or Target super smash debate

    For what it's worth, the Framework leaves out a profile. The profiles should read "Current, As Is", "Current, As Believed", and "Target Profile". The key starting point is bridging "As Is" and "As Believe" before ever considering "Target", as the gap between the former set is exploited far more often than the gap between the latter set and minimizing that gap creates (and speaks to) the kind of organizational maturity that will make the gap between ultimate priorities and "reasonable steps" much smaller.
  2. CSF and SDLC?

    I think only a cursory glance at the framework demonstrates it only touches on a partial list of information security controls, mentions risk management but doesnt assist with it, and barely even dips into the broader concepts of cybersecurity as a problem space (or suite of disciplines). Of particular pertinence, it really lacks many controls for managing/limiting how businesses introduce the exposure which must be managed by infosec and supporting operations. The SDLC gap is a part of that broader gap. It also mentions but doesn't really provide insight into how to use business risk management to guide technical risk management, how to test for effectiveness at reducing risk, etc. Ie: It provides no framework for identifying and applying the kind of context required to make its own control generalizations implementable in a valuable, coherent way. That said, it was a pretty interesting assessment of where typical critical infrastructure and other companies were from a mindset perspective. (NIST's term "Common Practices" is apt) When I use it in my class, I mostly use it as a guide to gaps in consensus perspective.
  3. Class Available: Bridging the Risk Management/Business Gap

    The Phoenix class went well, for what it's worth. I encourage everyone to come out to the next one in Minneapolis. We'll be looking at what it takes to create a business context that will create specific objectives and implementation details for NISTCSF and then use those to guide and prioritize security management through the use of C2M2 domains.
  4. As a follow-up to my blog post here in December, I wanted to mention a class I'll be offering in different U.S. throughout this year that helps define cybersecurity as a problem space, as discipline, and which attempts to fill in some of the larger gaps in the framework: Risk Management, Metrics, Communicating about Cybersecurity, etc. Hopefully some of you will see value in attending; I think it is relatively unique content with an unusual perspective. Overview: This 2-day class – one 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. Value: The instructor will use two common security frameworks (NIST and C2M2) alongside custom material (developed over 9 years and unavailable elsewhere) to provide students with the necessary cybersecurity, framework, and communication theory required to make practical improvements to their cybersecurity environments, including, potentially: More effective management of the organizational behaviors outside of the CISO shop that lead to increased cybersecurity risk Enhancement of the functioning and efficacy of security-specific programs and organizations Development of appropriate, actionable metrics for all organizational levels, including the executive Increased assurance that critical business success criteria are met despite ongoing cyber risk More comprehensive plans to defend against specific external threats Improved management of Perception, Communication, Scale, and Uncertainty risks associated with cybersecurity Improved partnership and collaboration within and across organizations, public and private Reduced gap between “Compliance” and “Security” Easier, more effective development of custom formal and informal frameworks to bridge gaps between disciplines Audience: The target audience for this class includes executives, security leaders, technology practitioners, architects, policymakers, lawyers, and other individuals interested in moving beyond industry and media hype to develop a broader understanding of both the problem space and discipline of “Cybersecurity” as it applies to their specific roles. Class will be tailored, within the constraints of the topic areas, to the backgrounds and needs of attendees. The first day will focus on theory presentation and the second day will apply that theory to practical problems – some as requested by students - in a workshop environment. 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. Dates: Phoenix, April 14-15 Minneapolis, June 16-17 Portland, August 11-12 Dallas, October 13-14 Nashville, November 10-11 Custom Dates and Locations Available http://www.energysec.org/upcoming-live-events/
  5. List of Existing Mappings and Add-Ons?

    Thanks for this, Tom, these links are helpful (Sorry for the delayed acknowledgement, I've been buried). I'm likely going to have to start compiling links and references. If I do, I'll post them here.
  6. How far is up?

    I'd argue that the main value of the framework was in its creation and socialization. It's not detailed enough to, with the content inside it, really move the ball too far forward from a risk reduction point of view. If we take Intel's report, for example, we can see that they primarily leveraged mature, advanced internal knowledge and capability to make effective use of the framework (and I really think they did a great job, to be clear). If an organization doesn't have a fairly mature perspective already, they may be able to make a pretty standard looking security program by using the framework, but that program is pretty unlikely to actually reduce risk. That said, now we have a flag. We've put down common practices in one place, created a document around which future policy discussions can occur, we have a place from which to advance more specific discussions, etc. And that, I think, is going to be the framework's primary long term success. If you want to effect and measure actual risk reduction - whether tactical and technical or strategic and environmental - it's going to be, by itself, the wrong document to do so. What remains to do, and what wasn't really attempted by the framework, is to teach organizations to manage their environments and ecosystems outside of "build a better security program" and to more effectively link organizational behavior to security outcomes and then derive metrics from those boundaries. But that gets to the heart of how businesses make money and cannot be relegated to CISCO-levers and executive "Fund More Security" levers and so is unlikely to be resolved in a public-private partnership environment anytime soon without some substantial cultural shifts... Anyway, just one opinion.
  7. Does anyone know of a list that's being maintained (or at least that's been created) of mappings and add-ons folks have done to/for the framework so far? I've seen plenty floating around, but it seems like keeping track of the public ones would be helpful (I sure could use such a list right now myself).
  8. Framing the Future

    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 problems we 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.
  9. Are the tiers a maturity model?

    Tom, I disagree with your comment that a maturity model can't be created that's appropriate for all 16 CI sectors - and the ES-C2M2 is actually (and ironically, given that it is a sector document) a good example of why. One of the things that the ES-C2M2 *doesnt* include is a model for justifications and goals (or it didn't when I last looked at it). These sector (or even individual business priorities) should provide the context required to determine what the appropriate maturity level for a given domain is - and they help constrain the implementation of the activities or practices in the domain - but they do not define either the domains or the supporting maturity levels. In other words, there are many fundamental cybersecurity truths that a reasonably good security model can/should describe independently of the prioritization and shaping of those truths to achieve a specific set of (sector or business specific) performance goals. It's that shaping to meet goals that should be specific to a sector, not the underlying maturity model itself. Just IMO.
  10. Are the tiers a maturity model?

    Tiers provide some indication of maturity, but calling something a "maturity model" (while somewhat a matter of semantic difference, true) implies, to me, something more robust and complete than what exists in the framework as written. What the tiers functionally provide, in my mind, are stubs hinting at how a maturity model might be developed on top of the framework (or stubs with which to link the framework into existing maturity practices). By themselves, though, the tiers are pretty sparse. If there had been a full blown maturity model attached to or built into the framework, I don't think we would be seeing the kind of disagreement we're seeing on what implementation or adoption mean (or even which term to use). As a related aside, I believe that at some point the idea was to use the Framework to support the Performance Objectives developed outside of the NIST/Framework Process (Performance as in "mission/business goals for security programs using the framework to achieve", not metrics performance) - and this would have led down a more robust maturity model path if it had happened. But, lacking that driving context, the framework seems to have stopped at "framework" and will rely on us to extend it further.
  11. Your 3 Recommendations from the 6th Workshop

    Nadya, no disagreements, but additional thoughts: Those using it as a risk management tool tend to already have risk management capabilities and/or knowledge in house (or, it seems that way). So a clearer takeaway might be, IMO, that the Framework is useable as an augment to Risk Managed environments but that the tools with which to do so are not entirely contained in the framework itself. Work needs to be done (in the community) to develop and publish linking patterns. Beyond communicating cybersecurity matters to the Executive and the Boards of Directors (which other tools, or even just the media, are starting to do), the Framework also does not address a related but perhaps more important gap: It does not provide many insights into how Executives and Boards can use the many, various levers at their disposal to improve cybersecurity in their organizations. The focus seems to be (implied) on sustaining or increasing funding for CISO type shops or "Planning" - but the "Planning" type of advice is unhelpful in that it typically does not describe specific Exec/Board levers beyond funding.