Yesterday’s post on the CIPC meeting in St. Louis got a little long, thanks to exposition from me regarding the ES-ISAC. If you find yourself wondering what I’m talking about, take a look at the post. Onward…
NERC staff also discussed the kickoff of the CIPV-Whatever standards development team, which is responsible for addressing changes in CIPv5 that FERC is requiring (see Order 791 for the nitty gritty). For those of you who have been sleeping, get some coffee, because all the development efforts will be going down over the next 6-8 months to meet the FERC required filing data of February 5, 2015. The major changes are for 4 specific areas, which NERC has created 4 subgroups to address the varying areas.
The major point about the CIPV-Whatever development at CIPC is that NERC is calling for participation by owners and observers in each of the subgroups. They want technical and policy experts to weigh in, I assume swiftly, on how things should be addressed. This is *especially* important for owners that have assets that were previously not under consideration as Critical Assets. The decisions made in the Low Impact Assets subgroup will affect what requirements your Low Impact asset must comply with, so you should weigh in on the sanity/insanity of those rules. And fair warning, there will be no discussion of “no controls” for Low Impact, that question was decided well over a year ago. Participate, and prosper, or ignore and take what comes.
It’s my opinion (and I heard this voiced during the NERC Atlanta conference as well) that the interests Low Impact assets may not be represented fully during the subgroup deliberations. It is imperative that future Low Impact asset owners work with their industry groups, those who understand their interests, to provide guidance and information so that the development team can write objective controls that are appropriate for your operating environment. As with all standards efforts, you get back what you put in.
One of the more interesting presentations at CIPC was regarding the use of Attack Trees to help evaluate the risk to the bulk electric system from High Impact, Low Frequency events. I first came upon Attack Trees being used to evaluate critical infrastructure in a 2012 ICSJWG presentation by Mark Fabro, but the concept itself is much older. To summarize, the basic idea is to represent how a given system could fail (in this case, failure is through cyber security means, but it certainly isn’t restricted to it). I learned a similar, but far less subjective, method to calculate overall system failure timeframe from the individual component failure timeframe.
Now, the term “Attack Trees” is a really sensational one, it evokes images of paratroopers, tanks, and trees-carrying-guns, so I caution readers that this is a formal risk assessment process, not a Michael Bay movie.
The concept is valuable in that it requires that the steps necessary to compromise a system be exhaustively defined, which leads to a greater awareness of the risk from compromise. Each of those steps is coupled with a binary “AND” or “OR” logic, defining whether a set of steps must be taken all together to compromise, or whether there are alternative methods. The idea is simple, but putting it in practice at scale is complex (the math gets to exponential quickly). Below, I’ve included a basic attack tree describing how to compromise my apartment as an example, but I’ve left out the explicit AND/OR logic. The next step in the attack tree analysis for my apartment would be to determine a level of difficulty for each of those steps. If you look at the chart, you’ll notice some of those steps are rather easy, others are more difficult.
However, attack trees are not a panacea. They are very subjective in nature, a fact the ATTF noted in their presentation, relying on a number assigned by a person rather than an objective measurement or statistic. I would add that the expertise of the assessors is also critical; having a group of assessors that have the experience in the activities (i.e. picking locks, busting down doors from my example) would be crucial in maintaining the accuracy of the trees. Some assessors would rank my “Use Radio Key Override” node as a very difficult exercise, while I know it to be moderate difficulty due to tools like the rfCAT to replay radio traffic on a specific band and my experience in using those tools. Lastly, the attack trees would need to be updated regularly as conditions change. The capabilities of attackers get better, physical security measures get added, new technologies are developed; all these changes must be incorporated on a regular basis to maintain accuracy. The sample space an attacker has to work with is huge, a lack of vigilance on their capabilities would lead to looking for needles in very large haystacks.
There are software packages being used when the pros do this analysis, and the Attack Tree Task Force (ATTF) is using one to make their lives much easier, and the analysis more meaningful. I would assume that certain node values (i.e. hopping fences, digging up cables) would also be reflected in the software, but I’m less sure of that. I would hope that there was a ‘componentizing’ capability as well. As an example, picking a lock is a common activity, and I use it a lot in my apartment attack tree. This should be a common node, one with attributes that could be globally changed (and hence, globally updated).
Where I see attack trees having a real impact is in analysis of vulnerabilities. When a new vuln comes out for control systems, it could be applied to these attack trees to see how it alters the risk profile. This altered risk profile could then be used to make decisions on measures that could be taken. To use my example, if I were to lose my keys sometime, then the path that requires picking locks would no longer be necessary, and I would want to consider changing my locks. title image by AZRainman