RISK ASSESSMENTS identify the probability that a vulnerability can be exploited by first determining the probability that a threat (hacker, error, etc.) will attempt to exploit the vulnerability and then determining the probability that the attempt will be successful. For each mitigating control in place, the probability of success is reduced. In addition to the probability of occurrence, an estimate of impact – sometimes financial – is also made. The resulting overall probability and impact can then be used to rank the vulnerabilities by priority.
In situations where the probabilities are well defined from statistical evidence, they can be used to compute a ballpark number for the financial value of implementing the mitigating controls by multiplying the probability by the financial impact. Unfortunately, exact probabilities for security incidents are difficult and a documented sample of incidents involving control systems does not exist.
However, relative probabilities can be determined – the probability of an external hacker trying to gain access is lower than a malicious insider which is lower than accidental incidents. Using relative probabilities, it is possible to prioritize the risks.
An additional benefit of risk assessments is buy-in from the stakeholders of the subject systems. By participating in the risk assessment workshops, they gain a better understanding of the vulnerabilities and threats, and assignment of the probabilities and impact is a group process usually resulting in group ownership of the results.
Penetration Tests attempt to exploit discovered vulnerabilities to establish unauthorized access to the SCADA environment and to accomplish unauthorized manipulation of the environment. Penetration tests are much like invasive vulnerability assessments in that they can cause unintended disruption to the SCADA environment. For this reason, if they are pursued, they should be performed by persons knowledgeable of SCADA systems or supervised by someone who is knowledgeable.
Typically, the passive Vulnerability Assessment is the first step in the cyber security risk assessment methodology process. From that point, the client can stop there or choose any combination of other options, including invasive vulnerability assessment, risk assessment and/or a penetration test. the following illustrates the methodology that KEMA uses for a passive vulnerability assessment, followed by a risk assessment.
Incident response plans have to be tailored to the unique organizational structures and management philosophies of each company. Even so, there are some common tasks that need to be examined and included when drafting your plan.
Who Is In Charge?
Most plans tend to identify technical staff with specific skills to be in charge during an incident. However, my experience has indicated that the manager with the most skin to lose is the one who takes charge. One solution might be to have a technical response coordinator and an overall incident manager from the business unit that is responsible for the systems that are compromised.
It is important to identify what can and cannot be done by system administrators when an incident is discovered. Keep in mind that the incident may be discovered at 1 a.m. and by the time management is available to make a decision, the incident is out of control. While it may be prudent to give system administrators emergency authority to shut down or cut off email servers or file servers, it may not be prudent to give the same authority for shutting down or cutting off control system devices. These issues need to be explored and clearly communicated to front line responders what they can do on their own authority and what must be approved regardless of the emergency situation.
Incident Response Team Membership
The team members required for incident response must be identified for each type of incident. For a virus or worm infection, membership from information security, system administration and IT Management may be sufficient. But, if it is suspected that a security breach has occurred that compromised customer credit cards, then Legal, HR and Public Relations might be needed. Also, it is always a good idea to have one person – usually someone who is both technical and familiar with management – to be the management liaison.
The last thing the technical staff that is responding to a virus outbreak needs is to be interrupted every 10 minutes by different managers asking about the status. The role of the management liaison is to regularly solicit updates from the technical response team, and report these to management.
A good practice is to develop forms that address all possible questions management may have and file these on a pre-approved schedule from the time the incident is declared until the incident is resolved. These forms will also provide good documentation on what was done, when it was done, what worked, and what could have been done differently.
Table Top Drills
Table top drills that explore what people would do to respond to different types of incidents are invaluable. Make a list of all the different threats (identified in vulnerability and risk assessments) and discuss with the each target what they would need to do to recover. For instance, if you discovered that a malicious hacker had been in your control system telecom environment for 10 days, what would you do to ensure that all your systems were configured and working properly?