Last week I described real life SCADA vulnerabilities. My intent was to assist IT security people to dialogue with their executive management about security budgets. This week I will continue by identifying mitigation steps for the vulnerabilities.

I know that you already know these steps. But sometimes it’s helpful in discussions with management when you, the internal IT security team, quote recommendations by a third party, impartial security “expert”. So here goes.
CIP 002-1 Critical Cyber Asset Identification
Create a central list of critical SCADA IT assets including hardware, software, and services. The list should include both a physical and logical SCADA network diagram and an emergency contact list. This information should be regularly updated and centrally available to all people on a need to know basis. The list could be deployed in house in a format as simple as a spread sheet or on a documentation software package, or outsourced to a documentation storage provider.

CIP 003-1 Security Management Controls and CIP 007-1 Systems Security Management
Similarly to creating asset documentation above, create a set of high level policies which must be signed- off by an executive committee. No sign –off; no teeth. The document can be very short and in point-form, with a goal of creating action items to implement policy.
Then write a set of IT security procedures, starting with access and authentication controls, perhaps starting with third party access to the corporate network, then expanding to IT security operations, and then to end users. Since access and authentication controls consist of technology and people processes, both are included as part of the policy implementation budget.
In my opinion, for small and medium size organizations, policy and procedures documents should be created on spread sheets that include forms for documenting important events.
A process should be created for IT security to report their progress to the executive committee and for the executive committee to update security policy in accordance with changing business priorities. And Voila, you have created a dialogue for IT security Governance.
CIP 004-1 Personnel and Training
Ensure you include the need to enforce compliance for policy and procedures for all applicable groups. Then include compliance testing, training and IT security awareness as part of implementation.

CIP 005-1 Electronic Security Perimeter(s)
Here’s your chance to include in IT security operations procedures all the things you want to do but may not have the time or cycles (translation budget) to do: ongoing regular self initiated internal or external vulnerability assessments; structured process for implementing patches / revisions including and for: testing the updates prior to implementation, testing to ensure all intended updates were implemented successfully; implementing a robust log retention / recovery process; correlation of vulnerability assessments with current patch / revision levels; in house or third party evaluation of firewall rules to check for inconsistencies; hardening reviews of SCADA network architecture; implementation of both network and host IDS with provision for ongoing tuning out false positives; ongoing review of event logs; regular or ongoing correlation of event logs with firewall rules / IDS rules / vulnerability assessments / anti-virus or anti-spam filters.

CIP 006-1 Physical Security of Critical Cyber Assets
Again, here’s your chance to itemize budget requirements for IT physical security procedures; secured junction boxes situated in the field; implement physical security alarms on junction boxes or remote stations (attended and unattended) in the field and on doors in at the SCADA operations perimeter; visitor accompaniment or challenge policy.

CIP 008-1 Incident Reporting and Response Planning and CIP 009-1 Recovery Plans for Critical Cyber Assets
Here’s an opportunity to nudge into existence an IT security Governance process while building IT security working relationships with other departments. Request budgets for implementing; IT security incident identification, reporting and response plan; create or test outdated DRP and BCP.

We Can Not Afford All This! Or Can We?
I think you can, even with a limited budget.

The key is to write the documentation with an emphasis on ease of implementation. Keep the initial documentation short and simple, in a format that is easy to update, and keep it updated.
Once you have proved the initial policy, process, and other documentation to be successful in terms of meeting objectives, then you can look for budget to expand scope. I have seen this approach work successfully many times.
As far as technology implementation budgets, I’ve seen best success with creating a multi-year plan with smaller annual budgets. As long as you can prove success with meeting each year’s goals, your chances of getting successive budgets of course improves. Nothing succeeds like success.
Have a secure week. Ron Lepofsky CISSP, CISM www.ere-security.ca