A Security Risk Assessment Process for Utilities and Building

Automation Systems

Daniel Adinolfi & Joe Homza Cornell University IT Security

Office

� The Scope: Cornell and Our Facilities Networks

� The History: A funny thing happened on the way to the Trustee Meeting

� The Plan: Play the FBI card first… � The Findings: Sterilized for your (and

our) safety � The Future: Where do we go from here?

Cornell and Our Facilities Networks

� We maintain: •  Power generation plant(s) (gas turbines, someday solar). •  Steam generation plant (gas turbines). •  Water purification plant. •  Lake source cooling system as part of chilled water plant. •  Hundreds of buildings with thousands of building control

systems components. � We also have our own police department and

medical center. •  Security systems and cameras. •  Medical equipment. •  Fire/smoke/toxic gas sensors.

� Labs that require 24/7 cooling/heating/power.

� Student and staff residences. � 24/7 libraries, common areas, etc. � Vet college with many living things. � Hockey rink (Go Big Red!).

� Dedicated networks with almost 10,000 devices and growing. •  Mostly closed off to the world. •  But need remote access for vendors. •  Open jacks for techs and visiting techs. •  Cross-campus monitoring. •  Very high availability requirements.

� Thousands of nodes •  PLCs, HMIs, PCs, "other”.

� Running protocols of all sorts •  BACNet, IP/TCP/UDP/ICMP, "other”.

A funny thing happened on the way to the Trustee Meeting

� With news reports of SCADA systems and other utilities systems under attack by bad guys, questions about our state of affairs came up at the Trustee level.

� Never let a good crisis or a concerned Trustee go to waste!

� CIO engaged ITSO and Facilities Management.

� ITSO had a contact in the FBI who could speak to criminal activity related to SCADA/Facilities systems.

� Came in and gave the Facilities folks a good scare.

� Everyone agreed, "We should do something!"

� Assessment project established based on ITSO Security Risk Assessment Service (see below).

� ITSO is leading the project, but the project is co-sponsored.

� Buy-in at top management levels (not just because Trustee asked).

� Dedicated resources (for meetings and info gathering).

� ITSO made it clear that they had no intention to make huge changes. •  Collaboration throughout. •  Never use the "audit" word.

� Official ITSO Service. � Goal is to find risks to the University's IT

resources. � Use home-grown assessment

questionnaires/templates. � Needed to adapt to the specialized world

of SCADA/BAC systems.

� Where do we start? To the standards! Get some training!

� CSET - Cyber Security Evaluation Tool •  http://ics-cert.us-cert.gov/Assessments •  "CSET is a desktop software tool that guides

users through a step-by-step process to assess their control system and information technology network security practices against recognized industry standards."

� Choose your standard, answer the questions, add documentation, generate report.

� How do the "experts" complete an assessment?

� Is the threat landscape real? � How does the typical enterprise look? � What standards should be followed? � Step by step?

� Many standards to audit/assess against. •  NIST Special Publication 800-82 Guide to

Industrial Control Systems Security, June 2011 •  NIST Special Publication 800-53, Recommended

Security Controls for Federal Information Systems Rev 3 and with Appendix I, ICS Controls

•  Etc. � How to use the NIST Standards?

� Conduct physical security assessment. � Request inventory, and all documentation

from customer. � Sniff the network. � Port scans. � Flip switches (or show you can). � Present your findings.

� Hacktivism and animal rights folks. � Nation-states. � Script kiddies with little clue. � Disgruntled employees. � Technical issues (XP EOL, worms,

architectural weaknesses, etc.).

� Some was created during the assessment.

� Couldn't verify all the policy was being followed, especially the newer policy.

� Made a list of what was missing.

� Defined the data elements for the inventory early on.

� Facilities created their version of the inventory based on that structure.

� ITSO did some network-based probes to create our version of what is out there.

� Compared the two to learn some things. •  Things are always in flux. •  Inventory tracking, in its natural state, is spread out

across many places. •  Lots of info is out there.

�  Sitting in a room with lots of well-paid technicians and doing endless Q&A leads to madness.

�  ITSO reviewed CSET. �  Created "essay questions" to summarize the intent of

the specific, yes/no questions in the tool. �  Asked Facilities to answer the essay questions. �  ITSO answered the yes/no questions for them. �  Benefits:

•  Less boredom. •  More directive and proactive process. •  Getting to the question behind the question. •  Less repetition (same questions asked over and over).

� ITSO staff aren’t physical security experts.

� Recommended review by campus police (the local physical security experts) or consultants.

� Did do a walk-through, and found where policy didn't match practice.

Sterilized for your (and our) safety

� Policy exists, sorta. � Local policies are ephemeral. "Policies

and practices" aren't always written down.

� Starting with robust, documented University-wide policies helps.

� To defend against auditors, document everything.

� Hard on the outside, soft and chewy on the inside.

� No surprise. � High availability demands few impediments

and as little complexity as possible. � Change is scary. � Architectures are decades old (as are

protocols).

� Need to mitigate risks in ways that prioritize availability.

Where do we go from here?

� Still reviewing the inventory. � Reviewing some network architecture

changes. � Waiting on additional policy. � Latest update: completed a penetration

test on a building's controllers.

� But everyone seems happy!

� Don't audit; assess. � Get high-level buy-in. � Collaboration from the beginning. � Research the sector. � Use standards as guides, but don't follow

them blindly. � Be sensitive to the operational needs.

(Don't be the squirrel in the transformer.)

� Questions?

� Dan Adinolfi, dra1@cornell.edu � Joe Homza, jh688@cornell.edu

� http://www.it.cornell.edu/security/