Cyber Security Policy

Transcription

1 Cyber Security Policy Revision Date Description Originator Checked E 16 th May 18 Document converted from White Paper to full policy APB TC Page 1 of 21

2 Document history:- Revision Date Description Originator Checked A 12 th Aug 15 Initial issue for comment APB APB B 21 st Aug 15 Initial review meeting updates APB APB C 15 th Dec 15 Progress review APB APB D 19 th Feb 16 tasks added, other minor updates included APB APB E 16 th May 18 Document converted from White Paper to full policy APB TC Revision changes in this colour. Page 2 of 21

3 Contents:- 1.0 Scope Policy statement Referenced documents Reference documents Business security Background Access policy Anti-virus protection Network infrastructure Desktop anti-virus Mobile device risks Use of memory sticks Desktop screen lockout Server physical protection FileShare Access NDA-related project data Recording project passwords Reviews Product security Process control threat sources Product network protection Redundant control and process networks Simplex control and process networks SCADA application with single network Simple application with single network TFW engineering overhead Programming tool vulnerability Other measures of protection Appendix 1 Permitted attachments A2.1 Archive files A2.2 Certificates A2.3 Audio files A2.4 Documents A2.5 Executable files A2.6 Image files A2.7 Multimedia files Page 3 of 21

4 Page 4 of 21

5 1.0 Scope Cyber security measures are intended to protect the confidentiality, integrity and availability of any computer system from being compromised through deliberate or accidental attacks. Cyber security affects us in a number of ways but the two key aspects are:- Business security minimizing the impact on our ability to operate in the event of an attack on our own business. Product and safety security for our clients - minimizing the risk that one of our control systems will be infected. The scope of this document is to identify the cyber security measures and policies that have been developed and adopted by Charter Tech to protect the company in it s day-to-day business activities as a provider of safety-based systems and to protect our delivered solutions. 1.1 Policy statement The officers of Charter Tech Limited are responsible for ensuring that all staff and contract employees are fully aware of the need to maintain secure systems and fully understand their responsibilities and limits as outlined in this document. All staff and contract employees are responsible for ensuring that they understand and comply with the business security aspects of this document, summarised as follows: To protect all information against unauthorised access. To maintain information confidentially. To not disclose information to unauthorised persons through deliberate or negligent actions. To maintain the integrity of information preventing unauthorised modification. To ensure that no actions impact on business continuity. To highlight all breaches of information security and to highlight any perceived weaknesses. Where NDAs permit, to ensure that data is accurately and reliably disseminated to other organisations within the bounds of a formal data sharing agreement. To ensure that mitigations and recovery plans are fit for purpose. At the proposals stage, all potential projects will be reviewed and assessment made of any cyber security measures that may be required. These will be identified to the client in the quotation. At project inception, the project manager will review the proposed measures, ensuring that they are appropriate and complied with. Page 5 of 21

6 2.0 Referenced documents 2.1 Reference documents The following standards and guidance documents are frequently referenced when cyber security is mentioned:- Standard or Guidance Document IEC 62443: 4 Parts (formerly ISA-99) ISO/IEC 27001:2013 PAS 555 FERC / NERC CIP HSE og-0086 ISA-TR National Cyber Security Centre National Cyber Security Centre NIST Special Publication Definition Network and system security for industrial-process measurement and control Information technology - security techniques - information security management systems -requirements BSI document: Cyber security risk governance and management Federal Energy Regulatory Commission / North American Electric Reliability Council, Critical Infrastructure Protection Cyber security for industrial automation and control systems (AICS) Security countermeasures related to safety instrumented systems (SIS) 10 Steps to cyber security Security for industrial control systems Guide to industrial control systems (ICS) security Page 6 of 21

7 3.0 Business security 3.1 Background In reviewing cyber security for our clients we can t ignore our own business security. All company desk-top PCs and laptops are connected to our intranet so theoretically an infection picked up on one machine could be easily replicated via the domain controller to all other machines, including smart phones and tablets. It is well known that threats can come in many forms: external hacks, as a result from visiting web sites; from attachments; from unauthorised access via our WiFi link and even from memory sticks that may be brought in from outside the organisation. Our measures are designed to mitigate against all of these. The following points define the potentially vulnerable areas and our internal mitigations and protective measures to minimise the risks. 3.2 Access policy Access to company data is based on least privilege passwords and access rights. In effect, passwords assigned to users limit access rights, only permitting access to data and company services pertinent to the role of the user. Access to data areas that are not explicitly required by the user are disabled. 3.3 Anti-virus protection Every business-related computing device in the company, including smart phones and tablets, is loaded with an instance of our anti-virus software package. This is centrally managed via global settings on our Sophos_server, a virtual server running on a desktop PC. Scans and health checks run automatically and the threat database updates daily. Our anti-virus package is periodically reviewed to make sure that the selected package remains best in class. 3.4 Network infrastructure Internet connectivity (ADSL Firewall) Considering Internet-derived, external attacks via our broadband link. All external traffic is routed through our firewall-protected router. This is configured to provide the best protection possible commensurate with permitting users access to the Internet and services Internal network risks Our internal network risks are minimised by employing multiple, physical and Virtual Local Area Networks (VLANs). This arrangement is particularly effective in that visitors using guest-connected devices via our internal WiFi are prevented from seeing our corporate network. The following diagram illustrates the arrangement:- Page 7 of 21

8 3.4.3 Domain control To further tighten our internal security our domain controller is configured to only accept connections from specific MAC addresses, i.e. our current network devices. This minimises the risk of ad-hoc devices getting access to our internal systems. Page 8 of 21

9 However, it is recognised that from time to time it may be necessary to allow an alien PC, smart phone or tablet to access our network. To facilitate this, a procedure has been written to describe the steps needed to add and delete a device from the list of allowable MAC addresses. This procedure is limited to Director and network administrator use only Visitor connection As noted above, visitors are permitted to access our client guest WiFi network to browse the web and pick up their s from anywhere in the building. This link is password protected, using a password generator administered by our network administrator. The password is changed on a monthly basis. It is not possible to gain access to our internal networks using this connection VPN risks On occasions we work from home and use a dedicated VPN connection to gain access to our desk tops and servers. However, if any PC other than a company laptop is used remotely we are exposed to whatever viruses or malware might exist on that PC. To minimise this risk external VPN connections will only be accepted from a company laptop. The domain control modifications noted in section will also assist in blocking connections from untrusted PCs. 3.5 Desktop anti-virus The importance of using up-to-date anti-virus software should not be underestimated. The change from Kaspersky to Sophos further enhances our protection measures. The attack log functions are frequently reviewed to ensure that threat levels are quantified Operating system firewall Each PCs operating system firewall must be switched on. It is recognised that on occasions a new program may have to be installed for a specific application and the installation process may require the firewall to be turned off. It is important that users remain focussed on this aspect and verify that the firewall has been reinstated on completion of the installation process. 3.6 Mobile device risks Personal computing devices brought into the company, including smart phones and tablets, must not be connected to an office PC or network, even for charging, without initially being checked and validated by our Infrastructure Engineer. This process will check that the device has a fully operational and current anti-virus/malware protection package installed. In the event that this can t be demonstrated then an instance of our default, mobile anti-virus package will be loaded before any connection access or recharging will be granted. 3.7 Use of memory sticks Flash drives and memory sticks pose a potentially high risk as they can contain multiple threats from a variety of sources. However, the anti-virus package installed on every PC contains an active and intelligent scanning mechanism. This checks each file as it is about to be opened or loaded, from Page 9 of 21

10 whatever source, memory stick, flash drive, CDROM, etc. This check by exception scanning process greatly reduces the time overhead when transferring files to or from memory sticks. An additional point to be aware of: not all memory sticks used in the office contain a recognised directory structure or file type, e.g. those containing software licences or used as hard-lock keys (dongles). The impact of these should be reviewed to ascertain if they can pose any additional risk. One final point, any new PC bought into the office must be loaded with an instance of our anti-virus software before any memory stick or flash drive is connected to it (see section 5.6). 3.8 Desktop screen lockout Although considered a low risk, any visitor to these offices could access someone s desktop when they re not present as they are always on during working hours. To minimise the risk auto log off will be implemented if the keyboard or mouse has not been used for a predefined period. This will be centrally administered with the delay to log off initially set to 60mins. This is part of a larger and longer-term plan to centrally administer PC access rights, core applications, desktop configurations and corporate appearance. 3.9 Server physical protection Server cabinet doors are kept locked shut with the keys located on a hook inside the software cabinet FileShare Access Due to access limitations imposed by several of our major clients our FTP server has been replaced with a web-browser friendly FileShare service. This is based on a Seafile package with enhancements giving it a company-specific look and feel. The FileShare server is based on Linux and runs virtualised on the legacy server. Two layers of protection are provided: it uses a dedicated VLAN to isolate it from our internal networks and an instance of ClamAV, Ubuntu s native anti-virus package, is installed on the server. Our legacy FTP server remains operational for the foreseeable future in case it is needed. It remains fully protected by an instance of our anti-virus package NDA-related project data In a number of project instances we have signed up to Non-Disclosure Agreements (NDA) with clients. To provide better protection for any received sensitive information all NDA-related client data must be stored in a dedicated and password protected folder called: NDA Protected Data Page 10 of 21

11 The NDA Protected Data folder should be a sub-folder attached to the project folder set on the Project drive and the folder access password must be stored in ProjectWorks Vault. It is the project engineer s responsibility to ensure that any NDA-referenced documents being worked on are returned to this folder promptly. NDA-related documents must not be shared with any other organisation without express authorisation from the client. NDA-related data from us to the client should also be kept secure. It is recommended that, as a minimum, data sent to the client should be zipped up and password protected before ing or making available via FileShare. The password should be ed separately to the primary recipient Recording project passwords Project-related sensitive information must be recorded in the project-related document list to ensure that we are able to support the client. Sensitive information typically includes:- Laptop and PC IP addresses, machine names and login details Safety PLC program login details Other program access details NDA client folder access and sent zip file passwords This functionality has been integrated into ProjectWorks using a generic access button Vault and a project-specific tab, thus ensuring that details are maintained consistently and in one place. This has the added advantage that access is already restricted to users with appropriate access rights The exponential increase in traffic poses a particular and significant threat to our business as problems can come from many sources. Typically these include: Simple scams, where an individual is invited to click on an icon and visit an infected web site. Directly from bogus individuals with a virus attached to the . Embedded in an image file or section of html. From a genuine and known source but with an undetected virus attached. We ve already seen instances, and been a victim of, address book hijacking, with s seemingly being sent from an individual s account, but with some very dubious attachments or embedded text. Once infected it takes a significant amount of effort to clean up and even more effort to regain credibility with our suppliers and clients. For the reasons outlined above the anti-virus protection protocols on our services are particularly strict as it s better to prevent the problem getting in rather than have to clean it up once it s inside the organisation. Every sent and received is scanned and all attachments, embedded images and documents are verified against our centrally administered policy tables. Any objects that don t conform are removed. To summarise the actions are as follows: Prohibited file as an attachment: o Specific attachment is discarded, and other attachments are allowed through with notification to recipient and administrator. Prohibited file embedded within a document: Page 11 of 21

12 o Entire and all attachments are discarded with notification to recipient and administrator. Regarding the second bullet point, it should be noted that the scanning process checks inside documents for invalid links, etc. Therefore it s possible that a seemingly innocuous document from a known source may be deleted. This behaviour is to be expected Valid attachments Because of the restrictions, when discussing file formats with suppliers and clients it is preferable to stick to the most common types, these are explicitly: Grouped and archive files: Zip, 7Zip Portable document format: Pdf MS Office: doc, docx, xls, xlsx, ppt, pptx A complete list of permitted file types, by group, is identified in Appendix 1. File types that match the identified suffixes are detected and allowed to pass through, all others will be rejected Safe option In all cases, the preferred option for transferring alien documents is to Zip them or request them to be zipped before sending. Assuming the zip format is valid the document set will pass through the server security protocols. However, this won t bypass all of our protection layers leaving us vulnerable, the contents will be checked by our anti-virus as soon as the set is unzipped Reviews Much as we annually review our QA and FSMS systems, a similar review cycle is in place for all aspects of internal cyber security. This includes quarterly attack logs so that we can get some idea of the overall threat level and the number of attacks we ve been able to repel. Page 12 of 21

13 4.0 Product security To meet a specific project specification we may be required to implement a network solution that achieves a high level of cyber security. This requires additional hardware, configuration time and defined countermeasures to reduce the threat level. However, we must be cautious about over-selling this aspect, the state of total security can never be reached as vulnerabilities and new threats are evolving daily. All we can really do is put in place measures to reduce the risk to as low a level as reasonably practical within the financial constraints of the project. The following aspects should be considered. 4.1 Process control threat sources In general, process control solutions that we engineer are reasonably secure in that they tend to be stand-alone and not connected to WiFi or the Internet. Nevertheless, in certain circumstances they may become vulnerable to cyber-attack through a number of routes. These include:- 1. Programming software tools. 2. PC or laptop that the programming tools reside on. 3. Process data collection servers or communication nodes. 4. Client intranet. The majority of these threats can be reduced with the incorporation of one or more, strategically located Tofino firewalls (TFWs) and the remaining threats can be minimized by implementing PC access-right restrictions and good management practices. See following section for clarification Why Tofino? Tofino has been designed from the outset to be used in industrial applications where PLC, DCS or fail-safe controllers are employed. It supports all of the commonly used industry-standard protocols. Each access port can be enabled with a configurable set of rules to restrict traffic flow across the network. Communication requests from unauthorised sources are prohibited from passing through and rogue events can be logged for diagnostic purposes. A dedicated programming tool Tofino Configurator is used to set up firewall rules using dedicated, protocol-specific Loadable Security Modules (LCMs). LCMs include:- Firewall ModbusTCP Enforcer OPC Enforcer Ethernet/IP Enforcer NetConnect LSM The NetConnect LSM is used in systems that are centrally managed. It allows the configurator to communicate securely with TFWs on an IP-based network, including LANs and WANs. Page 13 of 21

14 5.0 Product network protection The measures put in place to protect our delivered control systems and products from cyber-attack are usually dictated by the requirements of our clients and vary according to their own infrastructure arrangements. However, in the absence of any client-specified requirements this section identifies the minimum measures that should be considered for inclusion. The diagrams on the following pages identify the location of the cyber security protection devices for various networking scenarios. Note that PLC-derived, web served graphics will not be permitted in a cyber-secure environment. Page 14 of 21

15 5.1 Redundant control and process networks The diagram below shows a typical DCS-based network architecture with redundant control and process plant networks. In these systems pairs of TFWs are used to cater for the different sub-nets. In this case the process shown is not zoned. Page 15 of 21

16 5.2 Simplex control and process networks The diagram below shows another typical DCS-based network architecture but in this case with single control and process networks. It also indicates how various security zones may be set up, grouping nodes by protocols. Page 16 of 21

17 From the above diagram, Zone 1 is allocated to Safety PLCs. These will have the tightest security, probably with only one protocol permitted and with very restricted, read-only memory access. Zone 2 includes DCS controllers providing BPCS functionality. In this case two or three protocols may be implemented to allow data to be collected, set points to be adjusted and controller upload/download tasks to be implemented. Other zones are incorporated as required to permit the process plant to operate efficiently whilst maintaining a high level of security. In this type of application it is very likely that a virtual server would be configured to provide a centralised security management function. This would be used to configure and maintain all TFWs on the networks and provide a real-time, event log database with reporting functions. 5.3 SCADA application with single network The diagram below shows a typical SDCADA implementation with a single safety controller and a separate BPCS controller linked to a PC running an industry standard protocol, for example Modbus/TCP. In this case the SCADA PC would be preloaded with an operating system firewall and anti-virus software, with a single TFW used to protect the PLCs. Note that a programming and diagnostic laptop is shown, see later section for further details of Trusted PCs. Page 17 of 21

18 5.4 Simple application with single network The diagram below shows a typical entry-level scheme with a single safety controller linked to an HMI, all in the secure zone. In this case a single TFW is used to protect the control area from external influences. It is envisaged that a single protocol would be configured with very restricted, read-only memory access. Page 18 of 21

19 5.5 TFW engineering overhead There is an engineering and configuration overhead when implementing TFW-based, cyber security measures. Obviously the project-specific TFW configurations have to be tested, recorded, backed-up and maintained. But on larger systems, particularly those with multiple communication sources or redundant networks, a physical or virtual server may be required to centrally administer the array of TFWs and log all attack events for diagnostic purposes Commissioning overhead There is also a commissioning overhead. For a simple system a minimum of a day should be allocated to aligning the TFW configuration with the site s network and protocol requirements. However, considerably more time will be required to integrate a scheme with dual-redundant network systems. 5.6 Programming tool vulnerability With almost every delivered system a programming tool set is included, increasing the system s level of vulnerability. To ensure that cyber security measures are maintained the following rules will be applied:- 1. Any new PC purchased specifically for a project will be quarantined, i.e. not enabled to connect to WiFi or be connected to any office network, until the following has been completed: 1.1 The Operating System has been installed. 1.2 The project-specific anti-virus package has been installed or alternatively a temporary instance of our anti-virus package. 2. Any client PC brought into the office specifically for a project will be quarantined until our Infrastructure Engineer has checked it for a valid and current anti-virus package. If none exists then a temporary instance of our anti-virus package will be installed before it can be released from quarantine. 3. The laptop or PC used to configure and commission the system must be registered as an authorised Trusted communications device. 4. Logon access rights should be restricted to prevent users from adjusting the machine s settings. 5. The operating system s firewall must be enabled. 6. Loaded programmes should be limited to those specifically required to interface with the delivered equipment. 7. When work is complete, i.e. at the point of delivery the WiFi will be disabled and any temporary anti-virus licence will be removed. At this point the PC will effectively be quarantined again. Page 19 of 21

20 5.7 Other measures of protection Other measures of protection are generally physical barriers to prevent unauthorised access to the devices in the secure zone. These may include:- 1. Key locks on all control enclosure doors. 2. RJ45 jack locks to prevent casual and unauthorised access to Ethernet ports (see 3. USB lockable port blockers to prevent casual and unauthorised access to USB ports (see previous). Page 20 of 21

21 Appendix 1 Permitted attachments The following attachments, direct or embedded within the body of a document, are permitted under our security policy rules:- A2.1 Archive files 7z Zip Mso Gzip odf PKZip RAR A2.2 Certificates All types of certificates are permitted as they serve a security function. A2.3 Audio files No audio files are permitted as attachments or embedded within s. A2.4 Documents Odf Dxf Dwg Vso Pdf epub Chm xls xlsx Mpp doc Docx Ppt Pptx Mobi xps rtf A2.5 Executable files No executable files are permitted as attachments. A2.6 Image files Apff Gif Jpeg Jpg png A2.7 Multimedia files No multimedia files are permitted as attachments. Page 21 of 21