Convergent Security Risks in Physical Security Systems and IT Infrastructures

A large number of physical security device are fast entering the market that interface with traditional IT infrastructure for their monitoring and control. For example –

Electronic access control, including identification technologies such as
Magnetic cards, smart cards, biometrics and radio frequency interference (RFI) devices
Closed circuit television (CCTV)
Alarm and sensor systems
Communications and fire controls
Environmental system controls

A broad analysis and evaluation based on the class of security system, keeping the traditional IT security parameters in perspective (privacy, integrity, confidentiality, availability, authentication, authorization, investigations and forensics, fraud prevention and identity theft) provides the following broad guidance to security managers and professionals to evaluate and take adequate precautions to address the security implications of convergence of all these devices.

Security risks to systems and devices designed to provide physical security and process control are growing because systems are increasingly being connected to organizations’ networks.
Originally, security controls for these systems and devices were frequently sufficient to address the security risks that these systems and devices faced because they relied on direct and physical wiring installed between components. Changes in these systems and devices over time, as part of a general trend to open architectures across TCP/IP-enabled networks, have resulted in new, serious security risks that are often overlooked. Few individuals realize, for example, that closed circuit cameras are misnamed in that they are no longer “closed” from a networking standpoint. When these special systems and devices are connected to organizations’ networks, they often introduce a multitude of new, previously unanticipated security risks.

Security controls that were once adequate in deployments of physical security and other systems are often still present, but they are no longer adequate. The systems and devices themselves become potential targets of attacks launched from the local network or remotely potentially originating from anywhere in the world if organizations’ networks connect to the Internet. Local and remote attackers can potentially gain unauthorized access to these systems and devices, enabling them to function as authorized users.

Denial-of-service (DoS) attacks against the network can render such systems and devices inoperable. Clear text data from these devices are frequently sent over the network, making the data prime targets for anyone who has installed a sniffer along the route over which data are sent.

Special systems and devices are increasingly being deployed in a manner that exposes them to external access from the Internet.
Perpetrators who gain unauthorized access to these systems and devices may be able to use them to launch attacks on other resources within the network, some of which may be business-critical. Those who deploy special systems and devices often overlook the security risk that these systems and devices create for the rest of the network. Again, they frequently assume that security controls for these systems and devices are adequate-something that may have been true in the past.

These systems are frequently deployed without considering where they are placed within the network, the types of unauthorized access that are possible between them and other systems (especially business-critical and operationally critical systems), and the implications for network security. An attacker who gains unauthorized access to one or more of these special systems and devices may be able to launch vulnerability scans from them, and use the results to initiate DoS attacks against one or more parts of the network, to gain unauthorized access to other systems, and so forth.

Special systems and devices are becoming more sophisticated and diverse, making security increasingly difficult to control.
The types and sophistication of systems are proliferating, making the achievement of security control more difficult. Not that long ago the functionality of systems was limited to the extent that they could not be remotely accessed by anyone, let alone attackers. Even if they could be remotely accessed, they often did not possess sufficient functionality to allow malware to infect them or a perpetrator to use them to launch attacks on other systems. Even if they did, they were limited in the control functions they supported to the point that security breaches in them could result in compromise of a single or very limited set of physical security or plant process control function(s). Now the opposite has become true: today’s special systems and devices have become multifaceted and multifunctional, resulting in increased difficulty in controlling security risks.

Many vendors of special systems and devices have not adequately considered security in the design, implementation and support of their products.
Vendors have too often designed and implemented physical security and control systems and devices under the assumption that they would not be connected to any network, or, if they were, that they would connect to a separate, dedicated network. Consequently, these systems and devices often come with easy-to-guess passwords (or sometimes with no passwords whatsoever), few if any auditing capabilities, and other weaknesses. Worse yet, when systems are implemented, the pre-supplied passwords frequently are not changed or may be hard-coded into the system.

Over time, vendor products have grown considerably in functionality, especially in network functionality, without including concomitant security functionality. Vendors tend not to use standard IT terminology to talk about their systems, which makes providing meaningful information to IT personnel difficult. Security system and other vendors need to be able to communicate meaningfully with IT staff, yet confusion concerning the meaning of terms, e.g., client and server, abounds among vendors.

Furthermore, vendors frequently do not supply customers with trustworthy and complete documentation that describes security features and capabilities, recommended configurations, vulnerabilities that require workarounds, encryption capabilities (if available), how to close ports to prevent certain kinds of attacks (if this capability exists), and other important information.

Finally, vendor training seldom includes security-related training.

Special systems and devices are frequently deployed and managed outside of the influence of information systems and security professionals.
For a variety of reasons, individuals who have the best levels of knowledge and skill needed to achieve suitable integration of security systems into the IT infrastructure or the protection of these systems have frequently not been involved in decisions related to the purchase, implementation or management of such systems and devices. IT systems personnel responsible for systems management, networking and change processes are often not consulted when physical security systems are added to the IT infrastructure or are not provided with the information that is useful in planning and completing the integration of these systems into the IT infrastructure.

System vendors and integrators may not have detailed, complete or comprehensive information that is expressed in terms that are typically used to describe network bandwidth utilization or system performance.

Information security personnel may not be involved in physical security system specification, implementation or integration. To the extent that physical security systems and devices are considered part of an organization’s critical infrastructure, communicate sensitive or essential information, or support a critical business process, these systems need to be included in an organization’s overall security and business continuity plan.

Confusion concerning applicable security standards exists.
A plethora of standards that apply to physical security, plant process control and other special systems exists. At the same time, however, this “standards plethora” has resulted in confusion concerning the ones that genuinely need to be implemented, especially when security-related controls are concerned.

No widely accepted security standards that apply to such systems exist, and current standards seldom recommend priorities in selecting and implementing needed security-related controls in such systems. Standards, which are typically used in relation to system design, functionality, development, deployment and use, are often not used as references for physical security systems, even though physical security systems may need to comply with these standards when they become part of the larger IT infrastructure.

Auditing security controls in special systems is often difficult.
The independent audit function helps assure that deployed controls are sufficient in managing risk and that risks that are accepted will not adversely impact the organization. Due to a variety of factors-among which is lack of suitable audit standards-physical security, plant process control and other systems are not, however, often adequately audited.

Auditors often do not genuinely understand the nature, purpose, technology and vulnerabilities of such systems. Additionally, special systems and devices often lack the sophistication of auditing functionality to allow evaluation of individual accountability. Finally, as discussed previously, there is a lack of uniform, widely accepted standards for security controls in such systems.

Recommendations ( general)
To adequately address the security-related risks described in this report, organizations should consider the recommendations outlined in the following subsections.

Establish a governance framework for managing security-related risks in systems such as physical security systems and process control systems.
This is the most important step in dealing with security risks in these systems. Organizations must create a policy that specifies the elements of a risk management program for special systems and devices and a management infrastructure for providing resources, establishing accountability and ensuring compliance. Issues such as roles and responsibilities, separation of duties, data classification and data retention need to be addressed. Detailed procedures and standards pertinent to security in special systems and devices need to be written and constantly updated.

Define security requirements for physical security, plant process control and other similar systems early in the planning cycle. Failing to define applicable requirements upfront almost invariably results in cost escalation, including costs associated with retrofitting features to meet newly created requirements. Security is no exception. The process of defining the requirements for such systems thus needs to include the convergence of these systems with the IT infrastructure. Planning should involve a wide range of functions within an organization, including physical security, IT, information security, risk management, auditing and general counsel.

Understand the technology better.
A widespread lack of understanding of the technology exists, and the implications of integrating this technology into the wider IT infrastructure need to be recognized. Insufficient understanding, in particular when systems are network-connected, increases vulnerability to attacks and increases points from which attacks can be launched against other computers on the same network. Similarly, many individuals assume that because systems such as SCADA systems are complex and require specialized knowledge to understand, successfully attacking them is nearly impossible.

This assumption is false, however, as the numerous documented break-ins to these systems show. Auditors should better understand special systems and risks to identify security-related impacts to the enterprise.

Analyze and understand security-related cost-benefit trade-offs.
Connecting special systems and devices to organizations’ networks introduces new and usually serious levels of risk. The trade-offs between connecting these systems to organizations’ networks and the security risks that doing so introduces thus need to be better analyzed and understood.

Develop a unified set of meaningful standards.
As discussed, there is no absence of relevant standards relating to physical security systems. The problem is instead related to the plethora of standards that exist. It is difficult to determine which particular standards among the many are most important, and also how to comply with them. Governments need to write more condensed and specific guidelines concerning how to secure security and process control systems. Standards need to be applicable not only to entities that deploy these systems, but also to vendors.

Deploy special network security controls.

If special systems and devices must be network-connected, they should be located in an isolated and specially controlled part of the network-an isolated “security zone.” Network security controls such as firewalls, intrusion detection systems and intrusion prevention systems need to be implemented to better protect systems such as physical security systems and process control systems.

Implement effective authorization, accountability and auditability controls.
In closed systems, or when systems are not part of the critical infrastructure, actions by users, operators or supervisors may not need to be restricted, recorded or audited. When systems take on a more significant role, or are included in an infrastructure where accountability, authorization and the ability to audit are requirements, these functions need to be provided. Physical security systems should be able to be integrated into the organization’s formal access structure. For example, when role-based access is implemented organizationwide, physical security systems should be able to incorporate the same control structures.

Critical systems need to be treated as critical and included in the organization’s continuity plans.
To the extent that physical security systems are considered critical or support critical business functions, they need to be included in the organization’s disaster recovery and business continuity plans. Data and applications need to be classified according to criticality and sensitivity. Data recovery needs to be considered when offsite records retention and recovery plans are developed. Similary, security systems and security system services and functions need to be considered when developing recovery and continuity plans are created. These systems also need to be included in recovery plan tests to ensure that plans are effective.

Physical security systems serve as important sources of information in corporate investigations.
Systems need to be adequately protected to ensure their integrity and their usefulness in supporting forensic activities. Physical security systems may provide important forensic information required to support an investigation. These systems may also be significant to support an investigation of a network compromise if they are involved in this compromise.

Physical security systems that are part of the network need to be deployed so their system clocks and that of other network devices are consistent. This way, actions that are part of an intrusion can be more easily traced. System integrity needs to be provided for, so any change or use of the system can be identified and explained as part of system operation. Procedures need to ensure the proper protection of system records in the event of an investigation. Security for the system needs to be defined in such a manner that physical security systems and their components are protected from intrusion, misuse or tampering.

Require that the amount of auditing and logging in special systems be increased.
Given the risks that security and process control systems introduce, the availability of audit data that readily identify attempted and actual security breaches, and the source of such attempts, is a critical consideration. At a minimum, system auditing (where available) should be configured to yield information necessary to answer such questions. Better yet, special auditing and logging that are available only through third-party tools should be implemented to enable analysts to determine whether the use of security and process control systems has been legitimate.

Develop and require tailored security training and awareness.
Lack of knowledge concerning security-related risks and suitable control measures concerning convergence risks is currently prevalent among users, system administrators and managers/owners of security and process control systems. Tailored security training and awareness among these groups would go far in combating these risks.

Put increased pressure on vendors to play a more active role with respect to security.
Vendors need to do more than create and offer products that incorporate necessary security controls and eliminate common vulnerabilities. They should create baseline security standards for these products. Additionally, they need to standardize key terms and definitions and produce detailed documentation for their products. They need to also create and offer training and awareness that focus on security-related issues.

Expand the audit function to cover special systems and devices. Audit functions within organizations need to be expanded to focus specially on systems such as physical security systems and process control systems and the convergence problems that these systems and devices introduce.

Recommendations (specific)

Closed Circuit Television (CCTV)
Security issues to consider for CCTV include:

Many operational uses of CCTV exist outside of security, e.g., for process control.
Sophisticated video storage and archiving systems that create pressure on IT for storage are being introduced.
Vendors of control room equipment have no idea what ports on their systems are open or the implications for the potential of being attacked and compromised. Most vendors look for support from developers such as Microsoft for answers.
Systems may not even provide an opportunity to close open ports that are not needed.
Video DVR records what data have been accessed but not viewed-one can see all information on the hard drive; there is no limitation on access.
Access controls and audit information for physical access may not be established for video systems.

Access Control

Security issues to consider for access control include:

There is a lack of understanding in the physical security world of role-based access controls.
Access can be gained through the panel switch. From there, data can be downloaded or modified, granting unauthorized access to protected areas.
Each panel needs to be identified as a specific device to the system and authorized for certain activities.
Operators can open doors, leaving no record of who entered, because they may not have to swipe a card and may not have to sign in.
Wireless access devices can store 4,000 entries that may not be encrypted.
The problem of “enrollment on first read” persists.

Environmental Controls

Control systems in which individuals can control the temperature for their area potentially pose many risks. For example, can someone who is not authorized gain control and change environmental settings? These issues can have implications for areas in which environmental requirements are
important.

Command and Operations Centers

Security issues to consider for command and operations centers include:

The more systems converge, the greater is the need for more granular access control, such as logging, and procedural controls, such as background checks, two-person rules and the identification of single points of failure.
When multiple officers work a common command center, they often share the same ID and stay logged in for a shift. There are often poor password controls that result in outcomes such as writing passwords in operator logs or taping them to the side of terminals. The ability to establish accountability is lost. The problem of people engaging in unauthorized actions and/or misusing authority and/or using systems to gain unauthorized access or privilege in corporate network and systems is serious.

General

General security issues to consider include:

Network availability often depends on the particular time of day; some organizations may bring down the network at night or may be less concerned from an IT operations standpoint about service outages when security systems are most required.
Voice-over Internet protocol (VoIP) is a technology that has generally well-documented bandwidth requirements. Physical security devices have not been documented to the same extent however, so it is difficult to effectively plan and anticipate the requirements with these devices.
With physical security systems, there is little real operational testing, so it is difficult to anticipate performance.
Vendors do not have trustworthy documentation with regard to bandwidth and other IT-related requirements.
Auditing physical security systems is difficult, since there are generally few, if any, applicable standards that can be used as the basis of the audit.
There is an issue of system architecture and deployment requirements. Physical systems are often deployed without understanding the network architecture (switches and routers), network configuration and routing implications.
Physical security device manufacturers and integrators have done a poor job of documenting how systems really work and in training people in operations.
The evolution has been from firmware development to software in DoS and then Windows operating systems. Companies have done only enough to get products out the door without the rigor that is normally part of systems development. Quality control is missing.
Vendors have not used standard IT terminology to talk about their systems, which makes providing material to IT personnel difficult. There is also confusion about what terms mean, e.g., server and client. These are used in different ways, adding to the confusion.
System specifications need to spell out architecture and components within the architecture.
There is a difficulty planning bandwidth in particular, as events cannot be planned and the demand for bandwidth requirements and utilization cannot be predicted.
Physical security products typically have long life cycles.
Large companies are reluctant to invest in technologies where there are no standards.
Security system vendors need to be able to talk to IT staff and provide meaningful information.
Security systems are conceived and designed within the context that they are local, but the deployment is increasingly enterprise wide.
Compliance is forcing organizations towards standardization.
The company needs to address the question of who administers systems- IT or physical security department personnel-and who is accountable.
In most organizations, IT controls the network and has the budget power.
Physical and IT security have a great deal in common.
Auditors need to look at separation of duties, the need for which may cause changes in system design and operational characteristics.
For federal agencies, physical systems are considered to be part of the IT infrastructure and are, therefore, subject to the same regulations.
For the customer, integrator or manufacturer, liability for system flaws does not exist.
Standards and testing, e.g., Underwriters Laboratories Inc. (UL), for fire and life systems exist. Physical systems do not have to meet these standards, although they can be defined as being part of the critical infrastructure.
Fire systems liability can be spread among design, implementation, testing agencies (e.g., UL) and fire marshals, who approve systems once they are implemented.
Security managers may not be able to answer detailed questions about systems they have deployed or plan on implementing, since they tend to purchase the system as a whole and do not look at or have easy access to detailed system information such as the encryption algorithms being used. The vendor or integrator may not have this information, either.
Security system data may be covered by privacy regulations and there may be a need for reporting when personal information is disclosed.
Security system data should be classified and protected. Owners of security system data should be defined, as is common for other corporate data. Retention, storage and destruction requirements should be specified.
Security departments should require a warrant when records are requested.
There needs to be consistency in data retention. For example, in some airports, seven days of video footage is available before destruction. At other airports, video footage is available for longer periods. Some may keep data for variable time periods.
Physical security system data need to be handled according to their classification (sensitivity, criticality).
Access levels for viewing and monitoring need to be defined in security procedures.
There needs to be an audit trail of operator actions. Operators need to be accountable for their actions. Currently there may be no way to verify what has changed or who changed it; fully tracing events may not be possible.
There are often no physical security controls over physical security devices and control rooms.
All physical security systems should share a common time stamp with all other networked devices.
Physical protection for equipment needs to be provided. Access controls need to be placed in areas where sensitive devices such as control panels are located. Tamper switches may be bypassed or may not be in place, however.
Physical security systems should be treated as part of the critical infrastructure because of life safety issues, legal liability implications, protection of proprietary data, protection of critical assets, continuity of business and data integrity-related issues. They should be placed in protected data centers.
Patching physical systems is not always feasible because of system development issues.
Logical system security failure may adversely impact physical systems.

Reference: Report of The Alliance for Enterprise Security Risk Management (AESRM)
Posted: Aug 02, 2010