Defense in Depth strategies – Part 10 – Third Parties Security Management
Third parties security management
Supply Chain Management
Potential vulnerabilities in system components, which can lead to the compromise of the entire system and potential loss of operational abilities, can have their origins even before a system component is installed.
The supply chain poses a considerable risk to ICS systems.
The security challenges start already in the development life cycle of components, systems and applications – according to ICS-CERT cases of commercial off-the-shelf equipment with embedded unauthorised code in its firmware or operating system that provides a back door into the equipment or allows the programme to “call home” once installed have been reported.
To contravene such cases asset owners must pay careful attention to procurement contract arrangements, quality control and validation of performance to specifications processes as well as perform thorough testing, including vulnerability testing, before installing systems in a production environment.
Another weak point of the supply chain is the ability of rogue actors to obtain information about sensitive hardware/software from vendors’ websites, which is often provided. This is an easy way for threat actors to fine default passwords, operational instructions, vendor manuals and information provided by the users of software/hardware on the internet (such as white papers, blogs, social media, etc). With this kind of information publicly available, adversaries are well-equipped to compromise systems.
In order to make the ICS more resilient to potential attacks ICS owners should work closely with vendors demanding them to implement security by design principles that would deliver attack-resilient algorithms, architectures and control systems that can survive a cyber assault with no loss of critical functions.
Many organisations outsource functions or services which require highly specialised technologies and/or skills mainly for financial reasons – it is cheaper. Organisations often outsource many IT security functions such as incident response forensics, cyber vulnerability assessments, risk management, supply chain management, or other functions that they rarely use or that require expertise they don’t have.
In order to establish a framework for working together under an outsourcing arrangement, a service level agreement (SLA) is a typical means of identifying the service requirements for the outsourced firm’s responsibilities. When engaging with a third party for security services, it is crucial that both parties agree on roles, responsibilities, incident handling and reporting, and also the security of any interconnections, remote access policies and procedures, or interfaces that a user may require. In addition to the SLA, organizations should develop a memorandum of understanding/memorandum of agreement (MOU/MOA) and interconnection security agreement (ISA) to outline the specific management and technical requirements for the services.
If the outsourced agreement includes performing technical assessment or testing, involved parties should establish and agree on rules of engagement (RoE). The RoE includes directions about what activities may take place in what systems and who may perform those activities. It includes decisions about whether testing takes place within the primary (active production) control system or some credible substitute such as a backup or secondary control system, a test network, or a stand-alone system. As a general rule, active scanning of production control systems should be avoided, as they can cause operational issues or create a denial-of-service situation. Passive activities, such as network sniffing, may be adequate.