PHYSICAL SECURITY OVER INFORMATION TECHNOLOGY GUIDANCE DOCUMENT March 2014 This guidance document has been produced by CPNI in conjunction with MWR InfoSecurity. Disclaimer Reference to any specific commercial product, process or service by trade name, trademark manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation or favouring by CPNI or MWR InfoSecurity. The views and opinions of authors expressed within this document shall not be used for advertising or product endorsement purposes. CPNI and MWR InfoSecurity accept no responsibility for any errors or omissions contained within this document. In particular, CPNI and MWR InfoSecurity shall not be liable for any loss or damage whatsoever arising from the usage of information contained in this document.
Contents Introduction...3 Achieving secure PSIT systems...4 Convergence of IT and physical security...5 PSIT technology...6 Associated infrastructure... 11 Network topologies... 12 Additional topology considerations... 16 Case Studies... 18 Glossary... 21 References... 22 2
Introduction Whether it is simply a PC displaying feeds from CCTV cameras or a sophisticated series of systems which correlate employees swiping into their office with their network logon at their PC, there is a trend towards convergence of IT and Physical Security. In future all our physical security systems will be dependent on IT systems and common networking protocols to support their operation. This will bring additional flexibility in deployment, the ability to use centralised security control rooms for IT and physical security monitoring, and potential cost savings. However, whilst this convergence brings benefits it will also expose users to risks that didn t previously need to be considered. There are many challenges, including: Business buy-in Changing threat environments and increasing risk levels can be difficult to explain. If existing physical security systems have not (yet) been breached there is little buy-in for change. Vendor service level Inter-operability of equipment can be a challenge. It is difficult to switch vendor if IT security requirements cannot be met or when the responses to reported security issues are not adequate. This is compounded if explicit IT security requirements are not written into the contract. System complexity Once a system has been proven to meet its initial operational requirement there is little incentive to redesign it when extensions to the requirement are identified. Modifications and enhancements to the PSIT environment can result in highly complex systems very different from those designed from new. System evolution Where systems have been upgraded and extended, the threat model of the system should be updated otherwise new and evolving threats might not be addressed. This can lead to exposure to risk through issues that are inherent to legacy technologies and system architectures. Legacy deployments Although IT systems and components within physical security systems have met operational requirements and have not needed to be upgraded or enhanced, they are often out of date. Separation of security teams Physical security systems have traditionally existed outside the IT domain as they have not required management, support or maintenance from the IT department. IT support for physical security systems has typically been provided by equipment vendors and integrators. The implications of this are a lack of IT security provided to physical security systems and a lack of shared security solutions between IT and physical security domains. Cost of segregation The convergence of physical security systems with the main business network is often cheaper but a segregated PSIT network can be more secure. Often, systems remain segregated because of system complexity and dependency on the vendor s processes. 3
Achieving secure PSIT systems The following high-level process is recommended to everyone operating a PSIT environment: 1. Identify a senior risk owner at board level who can help the process. 2. Ensure that physical security and IT security teams collaborate to define the requirements of the PSIT environment and work together to achieve a workable secure solution. 3. Identify the systems and environment you have to support physical security and ensure this is suitably audited and documented. This documentation should include architecture diagrams, contractual agreements with any 3 rd parties, IT security operating procedures, associated IT security policies and the threat assessment. 4. Identify which topology you are operating based on the information in this document. Use this as input when assessing the availability and suitability of the controls within your environment. 5. Identify where gaps exist between those controls identified in this document and the environment you are operating. This should cover gaps in documentation and policy down to issues at a technical level. Ideally this gap assessment should include system audits and where possible security assessments and testing. 6. Assess the risks that are inherent in your PSIT environment and identify whether further action is needed to deal with issues identified in stage 3. 7. Devise and implement a plan to close any gaps to ensure long term management of the risks associated with the system. Repeat this in line with security best practice. 8. On-going monitoring Include the PSIT systems within the scope of your Information Assurance processes and systems and ensure they are continually monitored. 4
Convergence of IT and physical security Convergence is well underway, although to what extent it has already happened is often underestimated by IT security managers and departments. Often this information is held within the remit of the physical security departments who may not understand the issues. Not only does this mean that organisations are exposed to the risks that convergence brings, but also the potential benefits of it are not being realised. By their very nature, physical security controls are only capable of operating where they are deployed, whereas the IT capabilities of the system enable site-wide control and operation. Targeting the IT can result in a more widespread impact and can be used to affect an area that is physically remote from the attacker. It is therefore important, when anticipating IT-based attacks against a physical security system, to factor in whether the impact will be local to the point of attack or whether it will also affect remote systems. This illustrates how the threat is changing with respect to blended attacks and why IT security and physical security need to be considered together. Attackers are increasingly sophisticated in their thinking and approach and the possibility of an IT-based attack on a physical security system is real. In its least sophisticated form this may simply be disruption of physical security monitoring capability using an attack against the PSIT system. In its most sophisticated form this may involve the use of targeted malware to open doors, alter the position of cameras and prevent sensors from detecting the presence of an intruder. The Top 20 Critical Security Controls for cyber defence are a baseline of high-priority information security measures and controls which can be applied across an organisation in order to improve its cyber defence. CPNI is participating in an international government industry effort to promote the top 20 critical controls for computer and network security. The development of these controls is being coordinated by the SANS Institute. For more information, visit www.cpni.gov.uk/advice/cyber/critical-controls/ 5
PSIT technology Physical security technologies which use IT systems and communicate over IP networks can be divided into three types: Automatic Access Control Systems (AACS) Closed Circuit Television (CCTV) Intrusion Detection Systems (IDS) Each provides different capabilities to a physical security environment and inherently contains a number of risks which may be exposed if used or operated in an insecure manner. A summary of each of these technologies is provided in the following pages. Automatic Access Control Systems AACS allow the management of access to secured rooms or facilities based on a physical token and pin code or biometric reader. Systems allow for granular control of access permissions, even in large sites with multiple zones. Token readers and keypads are located by the side of a door and validate the user before allowing access. To mitigate the risks posed by putting an IP connection outside an organisation s site perimeter, any CPNI-assured reader will communicate with the door controller over a fixed-cable, serial-based protocol which is bridged onto the IP network within the perimeter. Access control systems often have a central server running software that manages users and door controllers and can check access requests against a database to decide whether to trigger the door release or not. Figure 1: Topology for an Automatic Access Control System with door controllers 6
The high-level topology of an access control system is illustrated in Figure 1. These systems work by sending details obtained from the user by the door reader over the IP network to a centralised server which then validates the user. Often the door controllers will synchronise with the centralised system so that in the event of a network outage or unavailability of the back-end services the door can still process requests. Security staff will then run software on a standard PC-based workstation (not pictured) that communicates with the server over the same IP network and allows them to manage users and access permissions and review log files. In many environments the access control system is located on the main corporate IT network as it often interfaces with HR systems for adding and removing users as part of the joiners and leavers process. In other organisations the HR team access the system directly from their corporate workstation. This is often why the system runs over the corporate network. CCTV / Thermal imaging systems CCTV permits the monitoring of a site by a small number of staff. As well as live monitoring by video analytics and/or CCTV operators, CCTV is also stored to allow for post-event investigation. There is now increased use of thermal imaging technology, which uses electromagnetic radiation in the infrared part of the spectrum to provide the images. In many environments the CCTV system is still entirely an analogue system with feeds from cameras running over coax cable directly into the control room and video recorders. (Note: these systems are not within the scope of this guidance.) When they do use an IP network, video feeds can require significant bandwidth and so it is often not possible to deploy cameras on the corporate network. It is usually for this reason and not specifically for security reasons that these systems are placed on a segregated IP network. Figure 2: Topology for a camera system with DVRs bridging to IP 7
The high-level topology of a typical CCTV system is illustrated in Figure 2. In this example cameras are connected to Digital Video Recorders (DVRs) via coaxial connections. These DVRs are then accessible across the IP network using the vendor s software. Typically a workstation (not pictured) on the same IP network will connect to the DVR to gain access to the live video streams or to recover previously recorded footage from the system. The CCTV images are usually displayed on a screen in the control room using the workstation s desktop display which shows the required streams from the cameras via the DVR. When offline analysis of images is required this is often done using the same vendorprovided software on another workstation which has its own monitor. NVR Figure 3: Topology for a camera system with IP enabled cameras In modern systems the cameras also have an IP interface and connect directly to the same IP network as the workstations and Network Video Recorders (NVR) (see Figure 3). In these environments the cameras typically stream their data to the NVR across the IP network and workstations still access the pictures from the NVR. However, with this technology it is often possible to view the streams directly from the cameras by either directing the vendor s software, or in some cases by simply directing a browser to the IP address of the camera. In some environments, usually those encountered in a physical security control room, additional components are used to control which images are displayed on the monitoring screens. These devices may be configured to accept messages from the detection or access control system so that live or previously recorded video streams can automatically be viewed on the screens when an event is triggered, e.g. the 15 seconds of footage before an alarm was triggered may be displayed alongside the current view from that camera to enable the individual monitoring it to respond to the alert. 8
Intrusion Detection Systems and alarms Intrusion Detection Systems (IDS) are devices which attempt to detect people who are crossing perimeters or entering restricted areas. A variety of technologies can be in use, from traditional infra-red detectors within buildings to radar systems along external perimeters. If sensors are triggered then staff can be alerted and investigate. Figure 4: Topology for a typical alarm system The high-level architecture of the system is typically as shown in Figure 4. A number of intrusion detection sensors will connect via coaxial cable to a controller unit which then talks to the central alarm server over an IP network. The sensors generate alerts when an intrusion is detected or when a tamper alert is caused. Alerts can also be generated by the controller should a particular sensor not respond to polling signals which are regularly sent. The alarm server is responsible for managing these alerts and then presenting them to the security control room, typically via a workstation (not pictured) that connects directly to the alarm server over the IP network. In more modern systems the sensors themselves may have an Ethernet connection and an IP interface that allows them to be contacted directly by the alarm server without the need for a controller (see Figure 5). 9
Figure 5: Topology for an IP-enabled alarm system Integration and intelligent buildings In some environments security systems are combined on a single network or communicate with each other to provide more context to the data they are processing, such as automatically directing CCTV cameras to the site of an intrusion or to the site of an access request at an AACS reader. There is an increasing trend towards the use of a single platform for managing all physical security components within an environment. These systems effectively act as a centralised location for collecting and correlating event data. These systems provide the opportunity to enhance operational effectiveness but are also an attractive target for an attacker as they allow for significantly greater control to be gained over the PSIT environment. Further integration is beginning to occur with other building management systems. This is not recommended by CPNI. See Intelligent Buildings: Understanding and Managing the Security Risks [18] for further information. 10
Associated infrastructure A number of devices and systems are needed to deploy a physical security system over an IP network. Key components are typically: Switches - devices to connect different Ethernet ports together and allow traffic to flow from one device to another. Switches can be fairly advanced and enforce rules on what communications are allowed or which devices can connect. However, switches are often installed in an insecure configuration and it is important to take some basic precautions to protect them from attack. This will often be highly vendor-specific. For further guidance see reference [1]. Routers - connect networks together, typically allowing IP traffic to route from one network to another. As with switches, routers can enforce rules on what communications are allowed. Depending on the vendor of the router there is also typically a best practice approach to configuration. For further guidance see reference [2]. Firewalls - devices which can be placed between connections; they are typically configured to block all connections except those explicitly allowed. They are an important control that prevents network devices from communicating with each other in ways other than those that have been defined. In some cases firewalls will be separate devices, however the functionality can be included in routers or switches or in the end-user systems themselves. For guidance see reference [3] Anti-malware / anti-virus server - aims to detect viruses and other malware but is dependent on regular, sometimes daily, updates to inform it of current viruses. Enterprises will often have a server which communicates with anti-malware software running on desktops to obtain updates. In corporate networks the central server typically connects to the vendor s system across the internet to obtain these updates; however, in a PSIT environment a manual process may be required if internet connectivity is not directly available. Security patch and update server - Typically, security patches are obtained directly from the operating system or software vendor. However, organisations will often use a centralised patch distribution server as it allows the organisation to manage the deployment across its estate. The technology used will determine whether it is possible to distribute updates for the core operating system and additional software applications through this mechanism. In a PSIT environment the main consideration for the use of such a system is whether a manual patching process can be supported given the scale of the environment. For links to patching solutions see reference [4]. Domain controller - Windows systems can join a domain wherein users and policy can be managed centrally rather than requiring administration of individual workstations. A domain controller is a server that manages authentication and authorisation of users and the policies that are applied to systems in the environment. The current mechanism for storing and accessing user and policy information is called Active Directory (AD) and can be used to create logical containers for users, systems, groups and roles within the environment. A powerful tool that is capable of supporting vast estates, AD is equally adept with small, self-contained systems. In a PSIT environment containing a number of Microsoft Windows workstations and/or servers, Active Directory and a domain controller can be very useful for managing security, although effective design and configuration is not trivial. See reference [5] for secure configuration of an Active Directory environment. Application servers - In PSIT environments it is common for components of the system to run on servers which are installed with a specific software application, e.g. an intrusion detection system 11
will use an application server to query the sensors and to display the results to the operators. This is achieved by running services on the system which can be accessed across the IP network. The software used in these environments is primarily proprietary to the physical security equipment vendor and often will not use open standards or protocols for communication. Secure setup and configuration of the software component will be vendor- and product-specific; however, the underlying operating system can be subject to secure configuration. See references [6] and [7]. Workstations - In a PSIT environment alarm data and camera feeds are displayed on screens in the control room to enable security personnel to identify and respond to intrusion attempts and security exceptions. If analogue systems are used these pictures are typically driven directly from the cameras. When communication over IP is used these pictures are typically displayed from a PC workstation. This system will often run vendor-specific software that communicates with application servers and shows the status of a camera or sensor alerts on screen. As with application servers these systems should be subject to secure build and configuration. See reference [7]. Support laptops - Once a PSIT system is installed and configured, it is necessary to perform administrative tasks from time to time to ensure safe and reliable operation of the system. This can require dedicated laptops as it may be necessary to connect directly to components using vendorspecific software. However, if not correctly secured, configured and maintained, the laptops may introduce risk if, for example, they have malware that subsequently spreads to systems in the environment. Event logging system - Failed or successful logins will usually be logged by the system on which the event occurred. It can be useful to aggregate these logs on a central logging server to permit easy analysis and alerting. Individual computers upload their logs to a central server which can then manage alerting or monitoring. Administrative or security staff should be able to access the central logging host and thereby easily review the logs for all servers at once. It is often desirable to consolidate all alerting across an organisation into a centralised system although this does not typically occur when the PSIT environment is separate from the corporate IT environment. See reference [8]. 12
Network topologies The architecture and design of a PSIT environment should be driven by the operational requirements it supports rather than an idealistic information security model. This doesn t mean that a secure and well-designed architecture can t be used to support it, but the architecture should complement and support the ORs not attempt to drive or define them. The guidance in this document is based around three topologies for PSIT environments, representative of the high-level design of environments used across a wide variety of organisations. Topology 1: Standalone security network Here, the PSIT network is separate: it has no remote connectivity and does not connect to the corporate network. Where multiple standalone security networks are connected through dedicated secure networks these are also considered as standalone. Figure 6: Standalone security network Drawbacks Benefits The PSIT network has no remote connectivity and support contracts must include provision for on-site maintenance/support. The PSIT network cannot share corporate services and a separate process for services such as patching, aggregating and monitoring logs is needed. The PSIT network can be robustly secured with strict controls that may not be appropriate for the corporate network. The PSIT network can either be designed in from the outset or implemented later in a network s life by segregating PSIT components onto a separate network. Improved Quality of Service on both networks as systems which require higher bandwidth, such as CCTV, are segregated from the busy corporate network. Primary security feature: it is possible to greatly reduce the attack surface by preventing or restricting unauthorised devices from connecting to the PSIT network something that may be difficult to achieve with the corporate network. However, it can be more difficult to maintain and patch as there is no connection to the outside world. Where devices such as USB keys or laptops are used to administer the network then security controls need to be implemented to ensure they cannot be used as a vector to compromise the network. 13
Isolation from the corporate network means that the PSIT system will not automatically benefit from services such as log aggregation and monitoring or organisation-wide management of user roles. A process for aggregating and monitoring logs should be put in place to achieve this. It is still important to apply defence-in-depth. Also, the isolated nature of the network should not be relied upon as the only security control. Otherwise, should attackers find a way to introduce an arbitrary device or otherwise communicate with the network, they would be relatively unhindered in compromising systems. Topology 2a: Standalone with remote access This topology is similar to the standalone system except that it is possible to access the PSIT network remotely. The PSIT and corporate networks remain isolated and it is possible to have multiple sites which do not directly connect as shown in topology 2b. If the business appetite is for segregated PSIT and corporate networks, but support contracts mandate remote access to PSIT systems, then it is possible to preserve the overall topology but implement a remote access solution. Figure 7: Standalone with remote access Drawbacks Cannot share corporate services; a separate process for services such as patching, aggregating and monitoring logs is needed. Risk of compromise through the remote access link; the network of the remote supporting party, or any other legitimate users of the remote access solution. Benefits The PSIT network can be robustly secured with strict controls that may not be appropriate for the corporate network. The remote access link can be secured and limited to read only. Improved Quality of Service on both networks because systems which require higher bandwidth, such as CCTV, are segregated from the busy corporate network. Remote maintenance is possible via the remote access solution, e.g. offsite aggregation and analysis of logs. 14
Topology 2b: Multiple-site standalone with remote access Topology 2b is effectively the same as 2a but with two sites rather than one. Basically each site is treated as a separate entity, as illustrated in Figure 8. Figure 8: Multiple-site standalone with remote access In this topology CPNI recommends that the guidance for the single site is followed but that it is applied in a similar manner at both sites. Typically in this scenario, the operational requirements will determine whether connectivity is required between sites, either through the PSIT system or operationally through other forms of communication. Topology 3: Interconnected system with remote access Some organisations interconnect the PSIT and Corporate networks. This may include remote access solutions in order to comply with support contracts. Figure 9: Interconnected system with remote access Drawbacks Physical network is shared with other departments; security may not be the priority customer. Issues with Quality of Service on both networks because systems which require higher bandwidth, such as CCTV, are integrated with the busy corporate network (any reduction in the bandwidth allowed to the CCTV will reduce its effectiveness as a security system). Risk of compromise through the remote access link, the network of the remote supporting party or any other legitimate users of the remote access solution. 15
The attack surface is significantly increased as there is a logical route from the corporate network to the PSIT network and compromises of computers on the corporate network may lead to an attacker being able to access and attack resources in the PSIT network and vice versa. Controls can reduce the risk but there will still be a route (possibly circuitous) between the networks. Benefits The PSIT network can share corporate services to centrally manage users, detect threats and administer servers. It is possible to restrict access using network security controls, e.g. by ensuring that only corporate machines on a particular VLAN can access PSIT machines and even then only specific services. It is possible (although expensive) to implement one-way interconnection with minimal exposure by using data diodes; the remote access link can be secured and limited to read only. Remote maintenance is possible via the remote access solution, e.g. offsite aggregation and analysis of logs. Additional topology considerations There are additional factors to consider when identifying which topology is appropriate for your organisation. Multiple security zones When considering overall topology for a PSIT environment it is important to factor in the use of multi-level security models and zones into the design. For example, whilst the high-level topology for a network may be Topology 1 (a standalone network with no remote connections) it may be necessary to consider this differently. The following example illustrates this scenario: Figure 10: Single high security zone within a low security zone 16
Figure 10 shows a high security room inside a wider office environment. Only a subset of users is permitted to enter the high security room. If a single standalone PSIT network is used to provide the security controls for both zones it may be possible for a user with access to the low security zone to escalate their access to the high security zone by attacking the PSIT system. For example, if the access control server for the door control on the high security zone sits in the main office zone this may provide more opportunity for it to be attacked by someone with the minimum level of access. In this scenario it may be preferable to consider the high security zone as the trusted PSIT network with the main office PSIT network effectively becoming analogous to the corporate network (i.e. it is less trusted). This may change the high-level topology being considered and different controls being applied. To segregate or not to segregate The ideal is a fully-segregated environment with all required security controls being deployed into it. However, at a practical level the cost of replicating security controls already present on the corporate network (e.g. patching or anti-malware solutions in the PSIT environment) may be prohibitive. A balance is needed between the risk of opening access to these services from the PSIT network against that of maintaining a segregated network without these controls present. This is a difficult area for guidance and depends on the organisation, its requirements, contracts, systems and processes. Whichever option is chosen there should be full appreciation of the benefits and risks of each. There is no one size fits all solution. Figure 11: Multiple high security zones within a low security zone 17
To remote or not to remote In the definitions of the topologies a distinction is made between remote access and no remote access. Where there is remote access but it is provided via a site owned physically and logically secured network this is considered as no remote access. For example in Figure 11 there is communication between the PSIT systems in two high security zones. If the link was via an untrusted network and/or was not physically protected between the two locations then this would be Topology 2b and would require the correct implementation of a secure remote access solution. If the link was directly via a secure network and was physically protected the PSIT networks could be considered as Topology 1. This is intended to illustrate that the definition of site in this context is based on the threats that exist and should not be applied literally to the physical environment. 18
Case studies 1. A single point of failure Organisation X has a control room that acts as a central hub for all physical security monitoring activity within the facility. All the systems that feed into this control room used a single Ethernet switch to carry the communications between the main network and the PCs that display the images on the screens. When this network switch suffered a hardware failure it effectively blacked out the control room and prevented access to all live CCTV images and intrusion detection system alerts. The network switches were not covered by the support arrangements so it took several days to source a replacement device through the authorised procurement channels. To complicate matters further the configuration details had not been backed up and further delays were experienced. During this time the control room was out of action. It is important to identify single points of failure in the network supporting physical security systems and ensure that appropriate mitigations are put in place. 2. The forgotten user accounts In organisation Y the employees accounts on the operating system of their automatic access control servers were not revoked at the same time as their physical access rights because the leaver s process did not take account of people having this type of access. As a result the employees could still access the automatic access control system and could therefore manipulate their privileges from within the operating system itself. They only needed access to the company s IT network to be able to add themselves as a user with access to any part of any site controlled by this system, even though other access rights had been revoked. This highlights why all systems on the physical security network should be included in the company s leaver s process and why regular audits of all user accounts within the system should be completed. 3. No test environment Organisation Z conducted a security test but did not have a test or development environment for their physical security system. Therefore the test had to be carried out against the live system. There were several implications of this, not least that the testing was more expensive to perform as additional safeguards had to be built into the process. When a number of significant weaknesses were identified in the system as a result of the testing there was no way to validate fixes and configuration changes before they were applied to the production system. As a result of the challenges that were encountered during this process the organisation decided to build and run a small segregated development environment which was a key resource during subsequent security tests and audits. 19
4. The cameras that went dark The CCTV system operated without major incident for five years after the original manufacturer had gone bust. During this time spares and new devices became more scarce until eventually they could only be acquired through online auction sites. When key components of the CCTV environment then suffered hardware failures it was not possible to restore the service until a complete new system had been designed, sourced, procured and installed. This process took a little over six months to complete and during that time the site was effectively operating blind and relying solely on manned guarding to provide physical security; the cost of extra guarding being many times more the cost of the entire new CCTV system. These are costs that would have been avoided if the upgrade project had been instigated in the time between the manufacturer going bust and the system failure occurring. This highlights why the availability of maintenance and support for all vendor equipment on the physical security system should be maintained and why upgrades are sometimes necessary even if the system is functioning correctly. 5. System requirements In another organisation the contractual agreement with a 3 rd party supplier included no wording or references to maintaining the security of the IT systems that supported the physical security controls. After an audit of the PSIT environment was conducted a number of additional management processes were recommended. However, the cost of the 3 rd party completing these processes (which were outside the contractual agreement) was calculated to be too high to fit within the constraints of the physical security budget and the processes could not be implemented internally as the organisation s IT function would not support the 3 rd party s software build. This was then compounded by the fact that the 3 rd party would not continue support of the software components if the internal IT function adopted the Operating System. As a result of a long term contractual lock-in the issues could not be resolved and the close relationship between the 3 rd party and the physical security team prevented the issue being escalated internally. If the organisation had mapped out their IT security requirements during the initial contract negotiations this issue would have been avoided. 6. The undocumented network The design and construction of the network supporting the physical security system was all stored in the head of one key employee rather than in the form of system documentation and diagrams. The individual s management chain did not understand the importance of documenting the system and therefore did not pursue it as a key objective. When an incident affecting the CCTV cameras occurred it was not possible to respond to it until this individual was available to assist. Additionally it was not possible for the specialists called in to conduct the investigation to make progress until the system architecture had been documented. It was estimated that the lack of documentation added at least two working days onto the start of the investigation. As a result the site was without CCTV coverage for an extended period until the source of the issue had been identified and the affected component had been identified and replaced. 20
Glossary AACS ACLs ACS AD AV BIOS CCTV CPA DMZ DVR Ethernet HR IDS IP IT LAN MAC NVR OR OS PSIT RFID SCADA SOC VLAN VPN Automated Access Control System Access Control Lists Access Control System Active Directory Anti-Virus Software Basic Input / Output System controls the hardware on a PC Closed Circuit Television Commercial Product Assurance scheme De-militarised zone Digital Video Recorder Wired network Human Resources Intrusion Detection System Internet Protocol Information Technologies Local Area Network Media Access Control a unique identifier for each network adapter Network Video Recorder Operational Requirements Operating System Physical Security over Information Technology Radio Frequency Identification Supervisory Control And Data Acquisition systems for managing industrial processes Security Operations Centre Virtual Local Area Network Virtual Private Network 21
References For the latest cyber security advice and vulnerabilities refer to the CPNI website, www.cpni.gov.uk. [1] Microsoft, Guide to Designing Applications to run at a Low Integrity Level [Online]. Available: msdn.microsoft.com/en-us/library/bb625960.aspx. [2] NIST, Guide to General Server Security, July 2008. [Online]. Available: csrc.nist.gov/publications/nistpubs/800-123/sp800-123.pdf. [3] Microsoft, Secure loading of libraries to prevent DLL preloading attacks [Online]. Available: support.microsoft.com/kb/2389418. [4] NIST, Guide to Intrusion Detection and Prevention Systems, July 2012. [Online]. Available: csrc.nist.gov/publications/drafts/800-94-rev1/draft_sp800-94-rev1.pdf. [5] NIST, BIOS Protection Guidelines, April 2011. [Online]. Available: csrc.nist.gov/publications/nistpubs/800-147/nist-sp800-147-april2011.pdf. [6] NIST, BIOS Protection Guidelines for Servers (Draft), July 2012. [Online]. Available: csrc.nist.gov/publications/drafts/800-147b/draft-sp800-147b_july2012.pdf. [7] NIST, User's Guide to Securing External Devices for Telework and Remote Access, November 2007. [Online]. Available: csrc.nist.gov/publications/nistpubs/800-114/sp800-114.pdf. [8] NIST, Guide to Storage Encryption for End User Devices, November 2007. [Online]. Available: csrc.nist.gov/publications/nistpubs/800-111/sp800-111.pdf. [9] NIST, Guide to Computer Security Log Management, September 2006. [Online]. Available: csrc.nist.gov/publications/nistpubs/800-92/sp800-92.pdf. [10] NIST, Guidelines for Media Sanitisation, September 2012. [Online]. Available: csrc.nist.gov/publications/drafts/800-88-rev1/sp800_88_r1_draft.pdf. [11] NIST, Guide to Industrial Control Systems Security, June 2011. [Online]. Available: csrc.nist.gov/publications/nistpubs/800-82/sp800-82-final.pdf. [12] NIST, Guidelines of Firewalls and Firewall Policy, September 2009. [Online]. Available: csrc.nist.gov/publications/nistpubs/800-41-rev1/sp800-41-rev1.pdf. 22
[13] NIST, Guide to Enterprise Patch Management Technologies (Draft), September 2012. [Online]. Available: csrc.nist.gov/publications/drafts/800-40/draft-sp800-40rev3.pdf. [14] NSA, Operating Systems Secure Configuration Guides, June 2012. [Online]. Available: www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/operating_systems.shtml. [Accessed March 2013]. [15] NSA, Cisco Router Secure Configuration Guides, June 2012. [Online]. Available: hwww.nsa.gov/ia/mitigation_guidance/security_configuration_guides/cisco_router_guides.shtml. [Accessed March 2013]. [16] Microsoft, Best Practice Guide for Securing Active Directory Installations, [Online]. Available: technet.microsoft.com/en-us/library/cc773365(v=ws.10).aspx. [17] NSA, Switch Secure Configuration Guides, [Online]. Available: www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/switches.shtml. [Accessed March 2013]. [18] The Institute of Engineering and Technology Intelligent Buildings: Understanding and Managing the Security Risks www.theiet.org.uk 23