4th Cybersecurity Framework Workshop: Good News and Bad News

I had a chance to visit a number of industrial events this year and can see the evolution of cybersecurity in the industrial field. One of these was the 4th National Institute of Standards and Technology’s (NIST) Cybersecurity Framework Workshop (CFW). Kaspersky was in attendance at the previous events, but the main difference with this one, was that now we had sponsors.

The 4th Workshop was another round to gather feedback on the latest version of the cybersecurity framework published on August 28, 2013. My takeaways from this workshop include (well, not too far from the previous 3rd workshop):

• The Cybersecurity Framework  is not about “how,” it’s about “what”
• The CFW is more of a marketing push for newbies and a refresher for pros
• There is a huge demand for industrial people to decide on how.
• Whitelisting and Default Deny are a must

Overall, the resulting framework is not specific enough for any of the Government-specified 17 Critical Infrastructure Sectors, to understand the practical steps of implementing a cybersecurity strategy or to at least understand the practical set of instruments (aka security controls).

For those who are not familiar, the Framework consists of five functions, categories for each of those functions, subcategories for each category; and separately, security profiles and maturity tiers.

Functions describe in general, what your cybersecurity should consist of: Identify, Prevent, Detect, Respond and Recover. Most people agree on these functions, while some argue that Improve/Update should be explicitly added in the security domain. As opposed to many other frameworks, security is becoming more obsolete, because while you may be secure today, in 12 months that could no longer be the situation because of new attack methods.

The Categories included in the Framework are  comprehensive as well. But, unfortunately, the subcategories (please find the full list in the document itself, see page 14) are a mix between abstract categories which helps to see the domain and potential goals, but leaves the selection of methods to the reader, and technical security controls that many sectors find inapplicable or incomplete. So it’s unsurprising that for the second Workshop in a row we see the same story: whenever any of the workgroup starts speaking about subcategories the work stalls. Most of the participants failed to examine the entire list, besides representatives of different sectors are unsatisfied with the way subcategories are set at all – for their own reasons.

Overall, the subcategories decided upon can be considered quite a failure. For example, the only control related to Industrial Control Systems simply says, “PR.PT-5: Manage risk to specialized systems, including operational technology (e.g., ICS, SCADA, DCS, and PLC) consistent with risk analysis”. It’s very specific, and helpful for OT people, if you know what I mean.

Apparently, it’s rather hard to have “Security Controls” done in a universal way for different sectors – including  IT and industrial systems and this doesn’t even take into account smaller sectors. For example, financial sectors normally are believed to take care of data quite well, but the example of Treasury was quite illustrative – all data is public, so confidentiality isn’t a major concern, but transaction and data integrity of shares in peoples’ possession, is a must. This is similar to the situation for industrial controls systems.

My impression is that NIST has decided to leave the work on defining the exact set of subcategories and controls to individual critical infrastructure sectors.

However, this method is not good for certain sectors depending on the industrial network, as there are 9 sectors where industrial systems prevail, but regulators and industry associations are different – DoE, DoT. So it is unclear whether each sector has to do the “instantiation” of the framework on their own, and whether or not this should be repeated nine times with different results, as they share much of commonalities due to their reliance on Industrial Control Systems.

Also, NIST will leave the Framework implementation details to each sector. One of the questions that’s wasn’t answered at the workshop was, “How do you implement security along this framework, or at least, what will you start with?”

One option  is to remove subcategories from the framework, to make it consistent, and to try not to present universal security controls, but rather make the Categories a goal-setting framework.

The Framework also includes another dimension – Profiles (what does your organization need among the variety of categories and controls – what are  your security priorities, based on the business specifics), and Tiers (how mature are you in cybersecurity). While it seems to be common sense, all of the frameworks in different domains basically share the same approach on “Flexibility” and “Maturity”. However in practice, in CFW it’s rather a mess because it is unclear how to measure what Tier you have and in turn what that tier stands for.

So what’s the good news?

• NIST adopted Kaspersky Lab’s whitelisting (Default Deny) approach for security for Critical Infrastructures – namely, “PR.PT-3: Implement and maintain technology that enforces policies to employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs on organizational systems (aka whitelisting of applications and network traffic)”. We believe that this totally makes sense, and we are happy to know that our voice has been heard and our vision shared.
• A major goal and major impact of the Cyber Security Framework is marketing – pushing all Critical Infrastructures, including many of those who do not yet have any cyber security programs, to start doing something, and providing more of a budget to CISOs of those who have a clear vision already. Many people suggested putting a framework in a marketing brochure to make it clear.
• The third positive as a result of this workshop, is that once pushed widely, the Framework can help people from different companies. Helping companies better understand each other in the cybersecurity domain is important, as most critical infrastructures are interconnected and outsourcing to each other, which can bring a serious domino effect in a potential cyber security incident. Cybersecurity marketing efforts could be helpful in many countries for the sake of cybersecurity of  Critical Infrastructures.
• Fourth, sector-specific jobs on specifying the security controls and mapping the Framework to existing sector and industry standards will be done, though that person or group has not been identified. The cyberframework could become a cross-reference between different sector’s standards and frameworks, which will also help build better understanding between entities on the technical level.

While the Cybersecurity Framework may serve as the first step in pushing Critical Infrastructure security,  the only way to actually increase protection is to make sure it goes with step two (where do I start?) and step three (what are the best practices to follow?) for each of the Critical Infrastructure sectors. Among these sectors, there are 10 industrial-centric ones that  are less-experienced in IT security overall and have a different nature to their processes (high-availability instead of high-confidentiality).

So, the question still remains –how can we make industrial security more practical for the current threat landscape?