Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

OPSEC and Culture in Control Systems, Lecture notes of Control Systems

By using methods of operational security (OPSEC), the security culture empowers management and users to maintain and enhance cyber security by instilling ...

Typology: Lecture notes

2021/2022

Uploaded on 09/27/2022

asdlol2
asdlol2 🇬🇧

4.4

(8)

233 documents

1 / 31

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Using Operational Security
(OPSEC) to Support a Cyber
Security Culture in Control
Systems Environments
Version 1.0
Draft Recommended Practice
February 2007
DISCLAIMER
This report was prepared as an account of work sponsored by an
agency of the U.S. Government. Neither the U.S. Government nor
any agency thereof, nor any employee, makes any warranty,
expressed or implied, or assumes any legal liability or responsibility
for any third party’s use, or the results of such use, or any
information, apparatus, product, or process disclosed in this
publication, or represents that its use by such third party would not
infringe privately owned rights.
i
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f

Partial preview of the text

Download OPSEC and Culture in Control Systems and more Lecture notes Control Systems in PDF only on Docsity!

Using Operational Security

(OPSEC) to Support a Cyber

Security Culture in Control

Systems Environments

Version 1.

Draft Recommended Practice

February 2007

DISCLAIMER

This report was prepared as an account of work sponsored by an agency of the U.S. Government. Neither the U.S. Government nor any agency thereof, nor any employee, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for any third party’s use, or the results of such use, or any information, apparatus, product, or process disclosed in this publication, or represents that its use by such third party would not infringe privately owned rights.

i

ii

iv

CONTENTS

Keywords

Control Systems, Operations Security, OPSEC, Security Culture, Cyber Security, Industrial Networks

Introduction

Information infrastructures across many public and private domains share several common attributes regarding IT deployments and data communications. This is particularly true in the control systems domain. Many organizations use robust architectures to enhance business and reduce costs by increasing the integration of external, business, and control system networks. Data security is often deployed using specialized technologies and is supported by the creation of a cyber security “culture” that is based on policy, guidance, and operational requirements. By using methods of operational security (OPSEC), the security culture empowers management and users to maintain and enhance cyber security by instilling procedures and guidelines into the day-to-day operations.

However, the cyber security strategies required to protect the business domains and the associated security culture that is created to support the security programs may not be easily translated to the control system space. Factors such as operational isolation, legacy networking, and inflexible roles in job activities may not be conducive to creating environments that are rich with cyber security capability, functionality, or interest. As such, guidance is required to help organizations leverage operational security and establish effective, self-sustaining security cultures that will help protect information assets in the control systems architectures.

This document reviews several key operational cyber security elements that are important for control systems and industrial networks and how those elements can drive the creation of a cyber security-sensitive culture. In doing so, it provides guidance and direction for developing operational security strategies including:

  • Creating cyber OPSEC plans for control systems
  • Embedding cyber security into the operations life cycle
  • Creating technical and non-technical security mitigation strategies.

Audience and Scope

This document is designed for managers and security professionals charged with developing, deploying, and improving the cyber security in their control systems domains. Although designed to be flexible enough to be read and used by system operators and engineers, the material is intended to be used by those that are deploying cyber security programs and creating security-sensitive cultures in control system environments. It is not designed to replace a sector-specific approach to creating a cyber security program, but rather guide interested parties in some of the more common areas requiring special attention. It may be found most appropriate by those that have experience in deploying cyber security programs in modern information

technology (IT) domains and are beginning to address the issues related to deploying cyber security strategies for industrial control architectures. The scope of the material is not technically demanding and can be used to provide a foundation for creating or augmenting existing information resource protection initiatives.

In the interest of brevity, and assuming the general readership will have experience with some IT security aspects, only some generalized standards for cyber security are discussed. The document is designed to address a few of the major issues encountered in developing a cyber OPSEC plan that can contribute to developing a security-sensitized culture. From these baseline standards, the reader is encouraged to investigate other related work and guidance that may be more applicable to their specific sectors. Moreover, it is important to note that as organizations use their own IT security framework as a baseline to create OPSEC in their control domains, other robust sector-specific cyber security initiatives can be used to augment best practices.^1 With more than 40 standards organizations worldwide working on guides that either directly or indirectly impact the security of control systems, readers can use this document as a basis in developing their own OPSEC programs based on other efforts.^2

Background

Recently, there has been extensive literature pertaining to potential cyber attacks on control networks by terrorists, nation-states, hackers, and insider threats.^3 These critical systems, many decades old in their technology, are rapidly becoming connected to business networks, to the Internet, and to each other. The security implications are evident, and there is reason for both concern and prudent action.^4 However, many of the industries that may be affected are likely to place cyber security at less than top priority for a variety of reasons: lack of resources for cyber security, the inability to deploy an effective cyber security function, or no substantial evidence of a threat. Additionally, personnel responsible for the cyber security of control systems may have little knowledge to accurately determine which products and actions are most appropriate for their specific control network or how to reduce their cyber risk in the most efficient way. Even once the technology required to protect key control systems has been deployed, the security culture that is required on an operational level to maintain, support, and sustain the defensive strategies may not evolve naturally.

Businesses that operate in a recognized critical infrastructure industry,^5 such as energy, water, transportation, and chemical manufacturing, need to practice due care and diligence on the cyber security of their control system or industrial network. This is no small task as it is a delicate operation to take the right steps to achieve the necessary level of security while balancing issues such as purpose, effectiveness, ease of use, compliance with regulatory requirements, and cost constraints. Ongoing effort and discipline is required during the control

(^1) The reader is encouraged to review specific cyber security work done by ISA SP99, NIST, NERC, CIDX and other sector- guidance that has been published. More information is at http://www.us-cert.gov/control_systems/csdocuments.html (^2) ISA Intech Magazine, December 2006, page 57 “Power to Security Standards’, Joseph M. Weiss

(^3) http://www.us-cert.gov/control_systems/csthreats.html

(^4) http://www.us-cert.gov/control_systems/index.html

(^5) http://www.whitehouse.gov/news/releases/2003/12/20031217-5.html

2

The above table clearly illustrates how requirements in each of the IT and control domains can impact security topics required in an OPSEC plan. Mapping an existing IT centric plan into the control domain without proper impact analysis can have negative consequences. As such, key foundations must be prepared in developing the cyber OPSEC plan that can accommodate for these differences. Some core concerns that may be considered in developing a cyber OPSEC plan for control systems are:

How does the need for real time data impact the deployment of security technology? Is latency an acceptable by-product of security technology deployment (i.e., encryption)?

How does the operator community and the associated job specialization impact OPSEC activities?

How does physical security at remote facilities impact access to components for upgrading software and firmware? What about recovery and incident response times?

If there is no testing or staging facility, how can upgrades for security software (i.e., antivirus) be evaluated prior to installation in production environments?

This document introduces some of the more essential cyber security activities that are important for control system OPSEC programs and, as a result, important in creating a cyber security culture. In addition to balancing these activities with normal business operations, these activities must be routine in nature and enable the industrial network and individual computer-based control systems to continue to run reliably and securely. This document is divided into three major sections, all of which focus on developing a control system cyber security culture by addressing key OPSEC ideals:

Section 1: Creating OPSEC Programs: From Management to User

Section 2: Sustaining Cyber Security Culture: Embedding Security into the Operations Life cycle

Section 3: Technical and Non-Technical Solutions

Section 1 covers key issues of administrative management, accountability, and the steps managers can take to create an effective cyber OPSEC program. It reviews the core components of the OPSEC discipline and applies them to the issues of creating an OPSEC program, populating the program with control-sensitive content, establishing management boundaries, and nurturing the program during its lifetime.

Section 2 discusses how cyber security can be embedded into the development and operational life cycle and provide a mechanism for meeting major security objectives in control systems and industrial networks. In doing this, organizations can provide a capability to create and maintain a self-sustaining cyber security capability for the control systems domain that is applicable to managers, operators, and other entities. As such, this second section addresses

4

issues such as “single points of failure” along with classic IT concepts of using clustering and backups.

Section 3 provides insight into mitigation strategies that cover both the technical and non-technical perspectives. Presenting cyber security in this manner, along with the previous discussion on OPSEC foundations, users will be able to enhance their overall lexicon for cyber security and decide how to present it so that a security culture is supported. Content in this section discusses technical activities for mitigation security issues in the control domain, training and awareness activities, and suggestions for enhancing and growing the cyber OPSEC program. A discussion of attacks and countermeasures is not included, but the reader is encouraged to review existing material at US-CERT regarding cyber attacks and control systems. 7

1. Creating Cyber OPSEC Programs: From Management to Users

In tandem with a robust cyber security policy, having management create, support, and maintain an effective cyber security program is critical to an overall healthy cyber security posture. There are many cyber security consequences that an industry with an IT enterprise system and automated control network needs to consider, including disclosure of confidential product data, corruption of control data, interruption of services, and physical destruction of the assets under automation control (the latter being a unique aspect of control systems and industrial networks in comparison to IT networks). From a management perspective, the creation and maintenance of a cyber OPSEC program in the control system domain is very similar to traditional IT domains. However, certain nuances and cultural differences can make the management of the cyber security program challenging. Thus, the challenge becomes how to reuse appropriate OPSEC fundamentals from the IT domain in the control systems environment.

To mitigate these issues, managers must be able to instill a program that accounts for the unique needs, capabilities, and operational requirements of those users and operators working in the industrial domain. Such programs often have familiar key components such as:

Generate a cyber OPSEC program for control systems users

Define management responsibilities and cultural considerations

Define OPSEC management boundaries for control systems

Write a cyber security OPSEC policy for control systems

Ensure control system operator/user input on development of the security culture

Implement and monitor a control system OPSEC program

(^7) http://www.us-cert.gov/control_systems

5

1.2.3 Organization of Information Security (Internal and External)

A management framework needs to be established to initiate, implement, and monitor a security governance structure. Security programs need senior-level approval and support, and wherever possible security functions need to be incorporated into other IT functions in the control environment. External parties are also included in these areas, and security issues and activities with third party or other vendors need to be addressed.

1.2.4 Asset Management, Classification, and Control

As organizations require understanding of the information assets they have in their industrial control systems environments, the cyber OPSEC plan needs to be shaped in such a way that those resources are protected appropriately. By the assignment of assets to owners and application of security functions to that ownership, both the issue of asset classification and responsibility are addressed. Information assets in the control domain need to be classified to indicate the degree of protection; the classification should result in appropriate information labeling and assignment to user, operator, and process.

1.2.5 Human Resources Security

Organization oversight for access and assignment are required at all times. Allowing Human Resources to assign requirements based on the “joiners, users, or leavers” model empowers a control system business to have a perpetual understanding on user and employee status while they are using control system assets. This model provides for applying security and appropriate care in the protection of assets before the hiring of the user, during the user’s employment, and after the user leaves the organization. Depth of functional resources should also be provided to ensure multiple personnel share responsibility and accountability for the various roles of configuration, monitoring, and operation of control system assets.

1.2.6 Physical and Environmental Security

Many control system domains already have an effective physical security apparatus in place. These components, often introduced into the control systems environment prior to the deployment of any IT capability, may require refreshing to accommodate for new security technologies. Such review may cover physical entry control, the creation of secure offices, rooms, facilities, providing physical access controls, and providing protection to minimize risks from fire, electromagnetic radiation, or sabotage. In critical control domains, this may be extended to include providing adequate protection to power supplies and data cables for some of the activities.

Access control and physical access must also include consideration for the installation and management of system-centric media (i.e. software/firmware upgrades) in remote facilities. In many system architectures, the locations where control equipment require servicing are often geographically disperse and may not have appropriate physical security. However, these locations are often accessed by workers, so upgrades or modifications to the resident technology can be performed. This concern for loading and unloading of media into the systems may justify the cross-correlation of cyber activity with physical access, as in many cases the remote facilities are effective connection points into the master control network. As such, logging activities

7

pertaining to physical access may be cross-referenced with cyber-specific activities to provide a more robust perspective on overall system access. (see 1.2.8)

1.2.7 Communications and Operations Management

Accurate documentation of the procedures for the management and operation of all information processing resources in the control systems domain should be established. Core sub components of Communications and Operations Management can include:

  • Operational Procedures o Change Management o Separation of Duties o Access to Development Environ
  • Backup and Data Retention Activities
  • Protection from Malicious Software (Malware) and Attacks
  • Third-Part Service Delivery
  • Systems Planning and Acceptance
  • Network Security and Monitoring o Secure Network Management o Networks Security Technology o Firewalls, Routers, Intrusion Detection

Of particular interest is the network management component. Cyber security requirements for control systems domains require a range of controls that may be different than those found in common IT networks. Measures, such as Defense-in-Depth strategies, can significantly increase overall security posture in these environments.^9 To achieve and maintain security in control system computer networks, special controls should be established to safeguard the confidentiality and integrity of data passing over connected public networks. Special controls may also be required to maintain the availability of the network services.

1.2.8 Access Control

Due to the inherent trust and privilege that exists in many control domains, access control needs to be applied to more than just users in the operational environment. To account for the interconnected nature of control systems, as well as the inherent capabilities that many control devices have, many components need to be considered in developing an access control function of a cyber OPSEC plan. To define robust access control, one has to consider:

  • Managing user access and user responsibility
  • Managing business requirements for access control (which may be very different from those in the corporate domain)
  • Monitoring operating system access control

(^9) http://csrp.inl.gov/Documents/Defense%20in%20Depth%20Strategies.pdf

8

Continuity Management (BCM) plans in place for the resumption of operations following an interruption due to physical or other non-cyber incidents. However, only recently have organizations begun to consider the BCM activities required to support cyber operations in control system environments; initial efforts have included the translation of existing business domain BCM plans into the control systems domain. Like the business domain, these plans needs to be periodically tested, maintained, and refined based on changing circumstances, operational capabilities, and overall control system architectures. The reader is encourage to research sector-specific work that has been done in this area (i.e., ISA, NERC) and ascertain the applicability to their own environments.

1.2.12 Compliance

In many sectors, it is essential that strict adherence is observed to the provision of standards, regulatory guidance, and associated laws. Many best practices are emerging for cyber security in the various control systems domains, such as Energy, and many more are on the horizon.^13 Moreover, as in the IT domain, adherence to laws, trade agreements, intellectual property, and vendor licensing is key to maintaining good OPSEC practices.

2. Sustaining Cyber Security Culture: Embedding Security into the

Operations Life Cycle

The operations life cycle in control system environments is non-trivial and often requires the integration of many associated functions such as operator activities, business requirements, technology upgrades, vendor support, and perpetual training and awareness as it applies to safety. With that, the interaction of these (and many more) functions creates a delicate and complex environment in which security must be pervasive. Most organization have a security culture, as it relates to the protection of the physical assets of the control domain, but emerging practices that connect these once isolated systems to corporate entities, business partners, and peer sites now require enhancing the security culture to include cyber security.

As mentioned before, the assignment of technology ownership to operators and users can help provide tactical protection of information assets and introduce some cultural activities as it relates to cyber security. However, to help maintain the security function and create a self-perpetuating security capability within the control systems domain, the incorporation of cyber security and an OPSEC program into the system life cycle, as shown in Figure 2, is required. By doing so, cyber security can be introduced at all levels of operations, achieve the pervasiveness required, and provide a good environment for the cyber security culture to grow.

(^13) http://www.nerc.com/~filez/standards/Cyber-Security-Permanent.html

10

Figure 2. Notional system life cycle with security components.

From the above diagram it is clear to see that there are a number of opportunities to embed cyber security into the life cycle, and like other core life cycle components, security can become part of the common strategy and permeate into the overall operational culture. Recognizing that security is in itself a process rather than a function that is simply done once, organizations have some flexibility in implementing a cyber OPSEC plan into the control systems domain using the life-cycle approach. However, to ensure truly effective security, an OPSEC program must have its foundations as early in the life cycle as possible.

In the control system environments, some elements require special attention due to the nature of industrial control systems (i.e., vendor specificity) and their subtle differences from their standard IT counterparts, which can make incorporation of cyber security into the phases a challenge. Yet, regardless of the level of effort, it has been proven that an after-the-fact approach to cyber OPSEC usually costs more in terms of time and money and renders security an unfavorable aspect in the opinions of operators, engineers, and managers. This in itself can impact the cyber security culture in a negative way and should be avoided. Proactive inclusion of cyber security into all operational aspects is indeed an element of an OPSEC best practice.

When control system hardware, software, and cyber security products are evaluated for specific levels of assurance they provide, many times operational assurance and life-cycle assurance are part of the evaluation process. Operational assurance concentrates on a specific industrial control system network product’s architecture, embedded features, and functionality, which enable an industry customer to continually obtain the necessary level of protection when using the product. Examples of operational assurances examined in the evaluation process are access control mechanisms, the separation of privileged and user program code, auditing and monitoring capabilities, covert channel analysis, and trusted recovery when and if the product

11

Providing detection and notification of a cyber security irregular event or activity within the control systems domain is in essence similar to the historical meaning (i.e., irregular event monitoring). The cyber security threshold is a baseline for cyber-related activities that are considered as normal for a control system before alarms are raised. Like the clipping level associated with monitoring normal operating activities, a cyber security clipping level will trigger alarms associated with irregular activity associated with user and cyber activities.

To accommodate for what may be a large number of events, contemporary intrusion detection systems (IDS) may be used to track these activities and behavior patterns because it would be too overwhelming for an individual to continually monitor stacks of audit logs and properly identify certain activity patterns. The goal of using clipping levels is to augment the overall situation awareness that can alert mangers to problems before damage occurs and to be alerted if a possible cyber-related attack is underway. Moreover, results from these observations can provide input to the mitigation strategies that are either technical or non-technical in nature and provide data points for ascertaining more accurate asset behaviors and thus, the risk to those systems. The reader is encouraged to review more in-depth discussions of security technologies for the control system domain.^15

2.2 Configuration, Access, and Change Management

As communications networks inside these domains become connected and entities such as peers and business networks connect to the control domain to collect operational data, strategies to account for the protection of the information resources need to be deployed. It is in the cyber OPSEC plan that the organization can address these issues and provide guidance in key areas such as Asset Management and Operations Management.

One area that deserves special attention within this management enclave, related to the Maintenance phase of the system life cycle, is Change Control. Organizations operating industrial systems will most likely have a change control policy as it relates to the Maintenance phase of the system life cycle, but may not apply the change management practices to the actual automated processes. This policy is usually applicable to the changing of major system components such as communications systems, operator interfaces, diagnostic tools, and others that relate to overall system reliability. As systems become connected, extensions to traditional change control processes are required to accommodate for the required protection of the information assets that are networked or are critical to safety and process control. Components of the change control include: how changes take place within a facility; who can make the changes within a control system network; how the changes are approved; how the changes are documented and communicated to other control system users and other employees; and how the changes are backed up to support system restoration.

Without these policies in place, control system users can make changes that others do not know about and may not have been approved. Although it is uncommon for changes at the industrial level to go undocumented (such as upgrading field devices or swapping in a new human-machine interface [HMI]), last-minute changes to the cyber infrastructure may be made out of necessity and can go undocumented and have negative effects. As seen above as an

(^15) http://csrp.inl.gov/

13

element in Communications and Operations Management, these procedural OPSEC elements have a key role in supporting security culture. Yet, it cannot go without mention that change control is intimately connected to both the Design and Operate phases as well, requiring that testing and evaluation are done prior to instantiating changes into an industrial production environment (see Section 2.2.1 below).

Heavily regulated industries, such as pharmaceuticals and energy, have very strict guidelines regarding what specifically can be done to their control systems and industrial networks and at exactly what time and under which conditions. These guidelines are intended to avoid problems that could impact downstream partners and, ultimately, the users of the product. Without strict controls and guidelines on changes, vulnerabilities can inadvertently be introduced into an industrial control systems network. Additionally, without change control, auditing the changes after implementation is a very complicated task. A well-structured change management process should be put into place to aid administrators. This process should be laid out in the change control policy. Although the types of changes vary, a standard list of procedures can help keep the process manageable and ensure that it is carried out in a predictable and repeatable manner.

Reporting requires interaction, and as organizations map a change control policy to the industrial domain, opportunity is presented to create an environment that will foster a security culture. Wherever possible, organizations should create working groups and outreach teams to ensure effective and timely reporting of changes to the information infrastructure. The following subsections are examples of elements that should be part of any industrial system change control policy that impacts network communications, security, or information-based processes.

2.2.1 Request for A Change to Take Place

Requests should be presented to an individual or group that is responsible for approving control system changes and overseeing the activities of changes that take place within a control system environment.

2.2.2 Approve the Change

The individual requesting the change must justify the reasons and clearly show the benefits and possible pitfalls of the control system change. Sometimes the requester is asked to conduct more research and provide more information before the change is approved.

2.2.3 Document the Change

Once the change is approved, it should be entered into a change log. The log should be updated as the process continues toward completion.

2.2.4 Test and Present Results

The control system change must be fully tested to uncover any unforeseen results. Depending on the severity of the change, the change and implementation may need to be presented to a change control committee. Unlike IT networks, changes to industrial networks and their control systems cannot simply be tested 24-hours-a-day, 7-days-a-week, and 365-days-a-

14