BC Hydro: Risk management is essential for security planning
I listened in on a deep-in-the-trenches discussion yesterday about the benefits of a multi-layered security architecture when it comes to deploying AMI.
Doug Powell, manager of security, privacy and safety for BC Hydro, was front-and-center in an Energy Central webcast, "Securing AMI at BC Hydro: The Benefits of a Multi-Layered Security Architecture," presented by Itron, addressing the importance of risk management in security planning.
From the utility perspective, risk is a four-pronged fork. "What is the risk we're talking about?" Powell asked. "Reliability (keeping the lights on); reputational risk (not doing anything that would negatively affect the utility's reputation); public safety (including socio-economic issues and system failure); and financial - most often the key concern for utilities," he said.
And risk is viewed, in Powell's perspective, on two levels: the threat perspective, or how risk management could be applied; and the core perspective, or what the root cause is that the utility needs to get to.
To take the perspective one step further, he compared threats to catching the flu. "A common view might be that the flu is inevitable. Then the mitigating activity would be: what can be done about it?" he said. Taking the analogy further, the common view, or approach, to the flu would be to prevent it if you can, and to deal with it when you catch it. These views, or assumptions, also have their own sets of mitigating activities.
The next step in the analogy would be the risk management approach - prevention, personal prevention, and managing your environment. The same is true with malware and its mitigation, he said. The mitigation of malware has certain realities and requirements. It's best showing in a situation-and-response balance, if I might borrow for a moment some notes from Powell's PowerPoint.
- IT threats are real -- They impact us every day
- Prevention/Situational Awareness -- Know the threat agents and plan against critical cyber assets and processes; understand the virus (mutations, etc.)
- Clean up your operations -- GRC, training & awareness, enforcement, backgrounds
- Manage your environment -- Contractors, vendors, employees, patching, password management
- Deal with it if you catch it -- Detection, SOPs, segregation, self-healing environments, DR, redundancy
Threat concerns with regard to AMI, or advanced metering infrastructure, he said, include: unauthorized access to the metering network, manipulating the meter, spoofing the meter and injecting false responses to commands, falsifying meter readings, altering the HAN interface to manipulate demand response, denial of service (DoS) attacks and hacking the SCADA system.
Within the world of risk management, all of these identified threat concerns, of course, lead to applications concerns, according to Powell. These can include network monitoring capabilities (having the right tools in the NOC, having the right people monitoring, etc.), password protection, sensitive data management, physical tampering, and more.
Big data management is another threat concern, he said: "This is often overlooked. But data flooding impacts network monitoring." Field tool vulnerabilities are another. "This woke us up in a big way," Powell said. "This can be the weakest link, so everything gets assessed."
Identifying the risks is one of the first steps in a risk management strategy, imperative when deploying new technology.
While not discussing BC Hydro's risk management strategy in detail, Powell identified for the webcast audience the priorities in a good risk management strategy overall. In order, these are:
1) Assemble a team of experts proportionate to the complexity of your AMI solution.
2) Then, create the standards framework. It must be comprehensive to guide the architecture, he said, and he suggested beginning with NISTIR 7628 and NERC CIP, and expand from there. "Even though NERC CIP is not a mandatory requirement for AMI, you can learn from it," he said.
3) Design the architecture intelligently, by assigning the right resources and the right expertise, and using the standards framework created in step 2.
Those, Powell said, are "Priorities 1a, 1b and 1c." From there, he suggested:
4) Align vendors and contractors to the framework requirements.
5) Begin with a baseline GRC risk assessment. Don't build on quicksand, he said, reminding listeners too that legacy systems impact the AMI solution significantly and increase security concerns.
6) Assess each component of the AMI architecture against the security framework.
7) Vulnerability assess each component of the AMI architecture.
8) Complete privacy impact assessments for each component and interface.
9) Penetration test the solution.
This short list, Powell explained, is but an overview of the drill-down points within each step. Those involved in risk management know full well there's much, much more to it. And if you're beginning to hear the word "assess" ring in your head, there's a reason for that. Assessment and validation every step of the way is critical. And penetration testing of the security of your solution is vital, as well.
Powell presented a list of work priorities of interest well worth perusing, as well. In the interests of space, I can't share it here, but you can view the entire webcast on demand here.
No discussions yet. Start a discussion below.