By Chris Paul and Jeff Whitney
SUPERVISORY CONTROL and Data Acquisition (SCADA) systems provide information and control over geographically-dispersed complex and critical processes. As these systems have evolved, they have succeeded in providing enhanced control capabilities through improved data and analysis performance.
SCADA systems are comprised of a complex set of interrelated components, addressing operational, technical, security, and regulatory requirements. Until recently, the operational component of SCADA has consistently and justifiably remained the focus of SCADA, as this is the primary function of the system. System users have therefore emphasized operational stability by addressing functional and technical issues, while striving to
improve ergonomics, increase security, and meet corporate and industry requirements.
This paper discusses a broader view of SCADA, addressing issues with not only the operational, but also the security, regulatory, and legal components. The also provides suggested solutions to help meet the challenges posed by ever-increasing security and compliance demands, in an environment of increased regulatory scrutiny
and legal exposures.
The changing environment
The emerging regulatory environment is placing increased demands on SCADA systems, driving data capture and retention, documentation, training, security, policy, and reporting requirements. As a result, operators and vendors are taking steps to incorporate the impact of regulatory and legal issues (sometimes referred to collectively as "compliance" issues) into the design and use of the systems.
Legal requirements and trends have placed new emphasis on maintaining compliance, as compliance issues are increasingly subject to enforcement. Compliance is of great significance in any incident where SCADA systems may be a core component of an investigation, lawsuit, or regulatory enforcement action. Compliance failures have resulted in bad press, large fines, and jail time.
In this new environment, threats for operators also include the potential for misinterpretation and misuse of data. Knowledge of the data, and the obligation to understand what it means or implies, can now be imputed to operators and management. This represents a significant shift in liability, moving responsibility up the chain of management. Operators and management are now facing the potential of charges of negligence being changed to allegations of wilful misconduct. In addition, they are confronted with the possibility of criminal liability and increased civil exposure.
Businesses with any form of SCADA-controlled operations must be aware of potential liabilities and take action to minimize them. Personnel with the responsibility and expertise to manage SCADA for and in these businesses are the first line of defence against charges of violations and lawsuits. These
personnel should have an in-depth understanding of the business and operations of the company. In addition, they should be able to recognize the various exposures faced by the company, if the SCADA system (or an operation controlled by SCADA) fails operationally, suffers a security breach, or is in violation of compliance issues.
The impact on operators
The following illustrates the types of problems that can flow from a failure in an operation (an incident occurs). Although a failure may be SCADA related, the cause of the problem is usually external to the SCADA system. Provided the SCADA system is integrated correctly (incorporating operations, security, and compliance), it can actually help supply the answer to what caused the problem.
If an operation fails in any way that is significant to a party outside the company, then it usually follows that outsiders will become involved. "Significant outside the company" can mean an adverse economic impact on a third party ("the pipeline went down because of a leak, resulting in a supply disruption"),
injury or damage to the environment, or injury or death of any person (including an employee).
The outsiders will look at the failure and the company, either because they have the public charter to do so (the FTC or DOT at supply disruption, OSHA at injuries or deaths, the EPA at environmental issues), or because they see an opportunity to make money (plaintiff lawyers). The outsiders will look at operations with 20/20 hindsight and, depending on the incident, may look deep into records, security, policies, procedures, and the decisions of the company.
The SCADA records likely will have a critical place in the midst of the scrutiny. The first hurdle facing the company is ensuring that the records can be produced. There are certain requirements in regulatory schemes for records retention (for example, see 49 CFR 195.404 regarding liquid pipelines in the United States). Failure to produce the required records may not only be a violation, but may also raise a presumption that the company destroyed the data because it has something to hide. If a civil lawsuit is filed, rules regarding evidence preservation may come into play, along with issues regarding records that are part of common law requirements and regulations like Sarbanes-Oxley in the United States.
Assuming the records and data are available, they will be carefully reviewed to point out any problems in operations. Unfortunately, the scope of the investigations will not end there. Regulators and plaintiff lawyers will look at compliance, training given to operator personnel, the manuals and policies underlying training, the age of the system, physical security of
the system, the ergonomics of the SCADA control room and system, and many other factors to find fault with the company. Even if the incident resulted from a security breach caused by a criminal act of a third party, the company will be held responsible on the theory that its security, since breached, was obviously insufficient.
The impact on vendors
Vendor exposures are also multi-faceted. During the course of an investigation, vendors will be subject to subpoena and discovery by regulators and plaintiff lawyers seeking information about the activities of the vendor on behalf of an operator.
Vendors will need to have maintained their working files in accordance with the requirements of the operator's contract. Although contracts normally require the vendor to provide prompt access to its records and files, such access is predicated on auditing by the operator of the vendor's work, rather than seeking to preserve records that may become important during an investigation or litigation.
Further, the vendor may be subject to legal action by operators who believe the vendor did not perform as required under the contract. Vendors thus need to ensure that their contracts, in conjunction with their insurance coverage, provide them
adequate protection in the event a problem arises that may be
related to the work that they perform.
In the best of circumstances, vendors can plan on having their business disrupted if their client has a problem; in the worse case, the vendor can plan on being a defendant itself. In this scenario, the vendor may face the choice between accepting some liability or blaming its customer for the failure. The latter action may result in the vendor crippling its business prospects with not only the customer involved, but other operators in the industry.
Solutions
The good news is that there are ways to determine how your company will fare, in the event that it is placed under the spotlight of public and regulatory scrutiny. The key is to take steps for management to learn about the factors and issues that will come into play during such scrutiny.
Figure 1 represents a highly-simplified view of the three primary
factors influencing SCADA operators and management in the current environment, while Table 1 below illustrates the effects of placing emphasis on the specific factors of operations, compliance, and security. Solutions to assist companies with SCADA systems must be designed to achieve a balance between operations, security, and compliance. The suggestions below are offered to help align these objectives; they are not meant to be all inclusive.
|
Major emphasis
|
Advantage
|
Disadvantage
|
|
Operations
|
Maintain 99.999% uptime, improve ergonomics and functionality.
|
Little to no emphasis on security or compliance, leaving operations, operational personnel and management exposed for security and regulatory scrutiny and/or action, and increased exposure in lawsuits.
|
|
Security
|
Maintains maximum protection from threats to PCN.
|
If not properly integrated, may sacrifice some business objectives and operational functionality. Security and operational policies and practices may not meet regulatory compliance mandates.
|
|
Compliance
|
Protection against adverse regulatory actions and lawsuit exposure if an event occurs.
|
Don't want lawyers running your SCADA operation. If not done properly, may compromise some business objectives and operational capabilities. Security and operational policies and practices will need to be aligned with regulatory compliance mandates.
|
|
Operations and security
|
Maximize capabilities while maintaining a secure environment.
|
May expose operational personnel and management to regulatory scrutiny and/or action, and increased exposure in lawsuits.
|
|
Operations and compliance
|
Allows focus on operational capabilities while addressing compliance.
|
Requires increased staff involvement to accomplish. Security issues may develop between enterprise layer requirements and regulatory security mandates.
|
|
Security and compliance
|
Aligns security policies and practices with regulatory compliance mandates.
|
If not properly integrated, may sacrifice operational capabilities and business objectives.
|
|
Operations, security & compliance
|
Maximizes operational efficiency and security while minimizing regulatory and lawsuit exposure.
|
Staff may need to cross internal political boundaries to accomplish.
|
Suggested solutions for operations are not provided, as business objectives, technology, and infrastructure vary from company to company, with the subject matter too broad to address in the scope of this paper. Likewise, compliance and security solutions must be tailored to the organization and its systems, though some basic recommendations can be universally applied.
Compliance
The current regulatory environment is a moving target. Regulations and laws provide boundaries, but these are not always clear. With the overwhelming amount of new"guidelines," "standards," and "requirements" being released, it is difficult at best for operators to keep abreast of current developments. As a result, operators must be diligent in order for them to stay compliant. Further, operators who believe that meeting the letter of the law, as set forth in regulations, is sufficient to protect against liability, are sorely misguided.
Compliance will often mitigate legal exposure, but will not provide an absolute defence against liability. Failure to meet the requirements set forth in regulations guarantees a level of legal exposure. The severity of the exposure will depend in part on the severity of the violation and the severity of the event that may somehow be related to the compliance violation.
While compliance with regulations means that there is not an automatic finding of liability, compliance with regulations does not preclude liability. This is a result of the standard for effectively defending against regulatory inspections and lawsuits moving to "reasonable practices" or, in most cases, "best practices."
The minimum requirements to avoid a finding of noncompliance, from an inspection for example, may be found in the regulations. Minimizing liability, in the event of an operational failure that adversely impacts the public, employees, or the environment, requires measurement against what actions peers have taken and what might have been done to prevent or mitigate a negative event. From a public policy standpoint, the expectation is that compliance alone is not enough. Positive results are required to protect organizations involved in activities that may expose the public to any level of danger.
One method of staying current with best practices is to assign
compliance responsibilities to a single staff member, or hire a compliance officer. Their job function should include monitoring corporate, industry, and regulatory compliance issues, updating polices and procedures, and appropriately reporting potential deficiencies and opportunities for improvement to management, among other duties.
No compliance or security programme can ultimately withstand legal scrutiny, unless the programme is tested for
efficacy and efficiency. Audits are critical to evaluating,
maintaining, and improving programmes. Failure to conduct an audit may result in operational failures, as well as severe legal implications. Failure to actively look at systems to evaluate security levels may itself be a negligent act, subjecting the company to regulatory action or a civil lawsuit in the aftermath of an incident. The government, and juries, may hold operators liable for failures of their security, even if a breach is caused by third-party criminal conduct.
Audits can be performed on the entire SCADA system, including the PCN, application layer, operation systems, field devices, communications, etc., or focused on SCADA security policies and procedures, physical security, or compliance. These are necessary and important activities, but need to be conducted in a fashion that avoids the creation of unnecessary exposures.
Conducting an audit creates its own set of issues, as any form
of system analysis may create evidence of an incriminatory
nature that could be used against an operator by a regulator
or plaintiff attorney. The internal information created by an
audit could be used as a platform to claim defects in the system that resulted in some non-compliance or damages, however
remote from the actual facts. Therefore, any audits should be
performed under attorney-client privilege. Doing so will help minimize the opportunity for audits to be taken out of context
or otherwise misused by agencies or plaintiffs who are more
interested in their own agendas than in using audits as a tool to improve programme performance.
Along with the audit itself, programmes need to be in place to
provide mechanisms for addressing the issues raised in audits.
These programmes should recognize and document changes in operations on an ongoing basis, to include training personnel to recognize and address these changes.
Security
As new standards have developed, multiple organizations/agencies have sifted through the myriad of documents from
government agencies and other sources to assist integrators,
applications providers, and end users with achieving
compliance and addressing security. In spite of these recent
efforts, security criteria are still unclear. As with compliance, a
single individual should be assigned to monitor the current
security "guidelines," "standards," and "requirements" being
released by organizations and agencies (DHS, Sandia National
Labs, Idaho National Labs, API, ISA, AGA, etc.). This person should co-ordinate efforts to help identify, prioritize, and
budget security improvements. In addition, they should be
responsible for scheduling and managing security audits.
The security issue must address not only the highly-publicized "cyber-threats," but also, more mundane but more probable
events and threats. These include internal errors or intentional
misconduct that may damage SCADA operability, as well as
questions regarding the adequacy of overall physical security and the ability to survive or recover from natural or manmade
disasters.
Operators who define security narrowly, failing to take a broad
view of potential sources of failure, often overlook ancillary
security threats such as a disgruntled employee, inadequate
policies, or loss of an externally-controlled power source or
distribution system. For security processes to be adequate, security must not just include the obvious firewalls and physical
access controls, but must also contemplate and evaluate any
other issues that might cause a system to cease working properly.
Conclusion
The approach to SCADA systems must be expanded to include and integrate operations, security, and compliance. Taking this holistic approach will help maximize operational efficiency,
maintain a secure operating environment, and minimize the
risk of regulatory scrutiny and/or action, while achieving
business objectives.
Authors' note
The information published here is not, nor is it intended to be, legal advice. You should consult an attorney regarding your particular situation. We reserve the right to determine whether to accept any matters referred to us for representation. Until we have agreed to being hired by you in regard to any legal matter, we are not your lawyers. Never send confidential or sensitive information to us by email without our permission. By sending such information, you may be waiving any potential attorney-client confidentiality privilege.
Jeff Whitney is an owner/principal of Berkana Resources Corporation (BRC), which provides integration, security, compliance, and audit services to customers utilizing SCADA processes. As an independent integrator, BRC provides these services using a wide range of SCADA applications in the oil, gas, water, and utilities markets.