Sometimes organizations have to accept risk rather than implement best practice or even standard of due care security controls. Ideally the organization has a security policy and has documented approved exceptions to this policy.

Even in cases where no policy exists and formal approval of exceptions is lacking, the operations team likely is aware of security deficiencies they have chosen to live with because alternatives were too expensive or infeasible. Some common examples include:

• Systems that are missing security patches because the patch would break a required function or application
• Systems with hard coded passwords
• Systems that support one or small number of accounts requiring shared user credentials
• Systems that require a large number of ports allowed through a perimeter firewall
• Applications that only run on an obsolete operating system like Windows NT
• Hardware, such as communications boards, that are no longer produced by a reliable source (is a gent in a garage a reliable source?)
• Systems that cannot be scanned because they tip over
• The list could fill the page

At one point in time someone in the organization reviewed the situation, hopefully applied some compensating controls, and accepted the risk. This should be done formally, documented, and the decision to accept risk made at the appropriate level. A short time out for a story:

We worked with a client that had an unwritten policy that all communication to SCADA field sites required a primary and backup communication method such as frame relay with dial back-up or microwave with VSAT backup. They did a nice job with this at about 75% of the field sites, but the team responsible for communication decided the remaining 25% of the sites were less important and would be too expensive for a second, backup communication method. They even said management would never spend the money, but they never asked. When this was brought to management’s attention in an assessment debrief along with the impact of a communication outage, management was shocked and immediately started a project to address the deficient, by their unwritten policy, 25%. The team that made the 75% decision was using their best judgment, but they should have presented the cost to management along with a recommendation rather than make the decision. This is a classic example of the wrong level in an organization accepting risk.

So let’s assume at some point in time your organization approved a security exception. That exception may have warranted at the time, but one, two or five years later that exception may no longer be necessary. Maybe the vendor has addressed the problem in a patch or upgrade. Perhaps a new system should be considered. Maybe the threat level has changed as you have more connections to the enterprise and business partners so the exception is no longer represents an acceptable risk. These are reasons why an organization should review exceptions at least once a year.

So here are your tasks for the January SCADA Security Checkup:

• If you have not previously, take the time to identify and document all exceptions to written or unwritten security policies
• Verify these exceptions have been approved at the appropriate risk acceptance level in the organization
• Review previously granted exceptions. Is there a new cost effective solution or compensating control? Has the risk changed? Is the risk still acceptable?