4th Cybersecurity Framework Workshop – Marketing is good but not for engineers

Recently, I had the chance to visit a number of industrial events and could 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 next version of the cybersecurity framework published on August 28, 2013. My takeaways from this workshop include (not too far from the previous 3^rd 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

-Allowlists 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 help 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 hard to have “Security Controls” done in a universal way for different sectors – including  IT, industrial systems and this doesn’t even take into account smaller sectors. For example, financial sectors normally believed to take care of data, but 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 9 times with different results, as they share many commonalities due to their reliance on the Industrial Control Systems.

Also, the NIST will also 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 put the Categories as a goal-setting framework.

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, each framework in different domains basically shares 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 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 allowlists of applications and network traffic).” We believe that this 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 doman 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 the cybersecurity of Critical Infrastructures.

-Fourth, sector-specific jobs that specify the security controls and map the Framework to existing sectors and industry standards will be done, though that person or group has not been identified. Cyberframework could become a cross-reference between different sectors’ standards and frameworks, which will also help build a better understanding between entities on the technical level.

While the Cybersecurity Framework may serve as the first step towards 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. Amongst these sectors, there are 10 that are industrial-centric and  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?