Appendix 4
ANSSI Security Measures

This appendix presents the measures proposed by the ANSSI guides (ANSSI 2013a; ANSSI 2013b). They are defined according to the class of the system (Chapter 6).

Recommendations are prefixed with an R and directives with a letter D.

A4.1. Organizational measures

A4.1.1. Knowledge of the industrial system

Table A4.1. Recommendations and guidelines for system knowledge

Roles and responsibilities C1 R1 – A cybersecurity chain of responsibility must be put in place. It should cover all systems. R2 – Responsibilities for cybersecurity should be clearly defined for each of the stakeholders regardless of the aspect concerned (development, integration, operation, maintenance, etc.).
C2 D3 – R1 is mandatory.
D4 – R2 is mandatory.
C3 D5 – The identity and contact details of the person in charge of the cybersecurity chain of custody must be communicated to the cyber defense authority.
D6 – The limits of liability must be reviewed periodically, at least once a year.
Mapping C1 R7 – Build a map:
  • – physical;
  • – logical (flow);
  • – of applications.
C2 D8 – Build a map:
  • – physical;
  • – logical (flow);
  • – related applications;
  • – of the system administration.
  • R9 – Review the mapping at least once a year and with each modification.
C3 D10 – R9 is mandatory.
Risk analysis C1 R11 – Carry out a risk analysis for cybersecurity, however brief.
C2 D12 – Carry out a risk analysis for cybersecurity according to a method chosen by the responsible entity.
C3 D13 – In addition to class 2, updating is required once a year.
R14 – Require the analysis to be carried out by a certified service provider.
Backup management C1 R15 – Set up a backup plan to allow recovery in the event of an incident.
R16 – Save the configurations before and after any modification, including when they have been made “hot”.
R17 – If possible, regularly test the backup process, possibly on a limited but representative subset.
The data concerned are all the data needed to restore the system after a disaster: programs, configurations, firmware, process parameters, data useful for traceability, etc.
C2 D18 – C1’s recommendations are mandatory.
C3 No additional requirements.
Documentation management C1 In the documentation describing the system (functional analyses, list of variables, various plans, etc.), some documents may be sensitive.
R19 – The sensitivity level of the documentation should be defined and appear on the documents that must be processed accordingly.
R20 – All design, configuration and operational documents should be considered sensitive.
R21 – Store documents in an IS with an appropriate level of sensitivity.
C2 R22 – Ensure integrity and confidentiality.
R23 – Review the documentation at regular intervals.
C3 D24 – R19, R21 and R22 are mandatory.

A4.1.2. Managing the stakeholders

Table A4.2. Recommendations and guidelines for participants

Participant management C1 R25 – Implement stakeholder management procedures (creation/destruction of computer accounts, local access, mobile terminal management, sensitive document management).
R26 – Implement a competency management process to ensure that stakeholders have the appropriate competencies.
C2 D27 – Class 1 recommendations become mandatory.
C3 D28 – As class 2, plus periodic review at least once a year.
Awareness and training of participants C1 R29 – Workers should be empowered and trained in cybersecurity.
R30 – If possible, set up a charter of good conduct to be signed by all stakeholders.
C2 D31 – Class 1 recommendations become mandatory.
C3 D32 – Mandatory cybersecurity training before intervention.
R33 – Training provided by a certified service provider.
R34 – Provide training at the same time as site safety and security training.
Intervention management C1 R35 – If possible, set up an intervention management procedure to identify:
  • – intervener and principal;
  • – date and time;
  • – perimeter;
  • – actions taken;
  • – list of equipment removed/replaced;
  • – changes made and impact.

R36 – Identify and update the hardware and software used for interventions.
R37 – Have the intervention authorization validated by the responsible entity.
R38 – Audit the process once a year to verify compliance with the procedure.
C2 D39 – Class 1 recommendations become mandatory.
R40 – If the intervener brings his own tools, in exceptional cases, provide a procedure to verify the level of safety of these tools.
C3 D41 – As class 2, but the use of special tools brought by the intervener is prohibited.

A4.1.3. Integration of cybersecurity into the lifecycle

Table A4.3. Recommendations and guidelines for lifecycle management

Inclusion in specifications C1 R42 – Integrate the requirements identified during the specification phases.
R43 – Define a contact point in charge of liaising with the responsible entity’s chain of responsibility, ensuring compliance with the policy, communicating differences.
R44 – Include the expected documents in the specifications: risk analysis, functional analysis, organic analysis, operation and maintenance file, mapping.
R45 – Plan cyber security tests during the acceptance phase (follow recommendation R71).
C2 D46 – C1’s recommendations are mandatory.
Add to the specifications:
D47 – A confidentiality clause.
R48 – If possible, a regular clause for revising the risk analysis.
R49 – Describe in the specification documents the technical, human and organizational means to trace them and be able to verify the level of cybersecurity.
R50 – The contractor must have a security insurance plan describing all measures that meet the requested cybersecurity requirements.
R51 – The contractor uses a secure development environment.
R52 – The contract includes a clause allowing contractors and suppliers to be audited.
C3 D53 – C2’s recommendations are mandatory.
R54 – Add a clause requiring the provision of hardware and software labeled for cybersecurity.
R55 – Require software developers to demonstrate that their development processes, employ state-of-the-art engineering methods, quality control processes and validation techniques to reduce software failures and vulnerabilities.
R56 – Labeling the contractor.
Integrations in the specification phases C1 R57 – Take into account all the technical measures presented below.
For example, the necessity:
  • – to authenticate participants;
  • – to define a secure architecture;
  • – to secure the equipment;
  • – to be able to requalify a system following security updates.
R58 – Provide procedures and technical means to allow preventive and curative maintenance operations in order to maintain the level of cybersecurity over time.
R59 – Take into account physical security when defining the location of equipment.
R60 – Require in the specifications that operations not essential to the operation of the industrial system be performed on another information system.
C2 D61 – C1’s recommendations are mandatory.
R62 – Integrate into the design of tools and mechanisms to manage security and facilitate requirements such as:
  • – configuration control;
  • – the hardening of configurations;
  • – vulnerability management.
C3 D63 – The recommendations of C2 are mandatory.
Integration in the design phases C1 R64 – During design, limit interfaces and system complexity to a minimum in order to limit the introduction of vulnerabilities during implementation.
Integrate cybersecurity features of equipment (authentication mechanisms, segregation of rights, etc.) into the equipment selection process.
R66 – Define roles for integrated stakeholders in the management of computer account rights with a policy of least privilege.
C2 D67 – C1’s recommendations are mandatory.
C3 No additional requirements.
Cybersecurity audits and tests C1 R68 – Set up regular audits, which may be internal.
R69 – The audit must be followed by an action plan validated and monitored by the responsible entity.
C2 D70 – C1’s recommendations are mandatory.
R71 – The audit program must contain:
  • – boundary tests;
  • – error tests of business functions;
  • – testing of verification and exception handling;
  • – the development of threat scenarios (penetration tests and attempted takeovers during maintenance phases);
  • – the verification of security mechanisms (patch deployment, event log analysis, backup recovery, etc.);
  • – the evaluation of the system’s performance;
  • – the audits carried out by certified service providers.
C3 D73 – The elements suggested for the audit in class C2 are mandatory.
D74 – Conduct audits at least once a year.
Transfer in operation C1 R75 – Before commissioning:
  • – establish a comprehensive inventory of the system’s cybersecurity level;
  • – ensure that the available means are available to maintain it at an acceptable level.
C2 D76 – Obligation for the entities responsible to approve the system.
C3 D77 – Obligation to have the system approved by an external organization. Prior authorization for commissioning is required
Change management C1 R78 – For PLC programs, SCADA applications and equipment configurations, use tools to quickly check the differences between the current version and the version to be installed, and ensure that only the necessary and requested changes have been applied.
R79 – Track changes.
C2 D80 – C1’s recommendations are mandatory.
R81 – For PLC programs, SCADA applications, set up a process to check the running program versions against a reference version.
R82 – Evaluate changes in a test environment.
C3 D83 – R78 is mandatory + have the impacts validated by the responsible entity before going into production.
D84 – C2’s recommendations are mandatory.
Monitoring process C1 R85 – Implementation of a process to monitor threats and vulnerabilities.
C2 D86 – R85 is mandatory.
R87 – Contractualize the distribution, by suppliers, of vulnerability bulletins for all hardware and software equipment used.
R88 – Set up a monitoring process on the evolution of protection techniques (can be based on open sources available such as the ANSSI website).
C3 D89 – C2’s recommendations are mandatory.
D90 – Set up a monitoring process on the evolution of attack techniques. In case of significant changes, repeat the risk analysis.
Obsolescence management C1 R91 – Include clauses in contracts relating to the management of obsolescence of equipment and software (with support end date).
Indeed, for software or equipment that is not maintained, vulnerabilities are not fixed.
R92 – Include a replacement plan for obsolete equipment and applications.
C2 D93 – C1’s recommendations are mandatory.
C3 No additional requirements.

A4.1.4. Physical security of the facilities and premises

Table A4.4. Recommendations and guidelines for physical security

Access to premises C1 R94 – Provide a physical access control policy, including:
  • – retrieve an employee’s keys or badges upon departure;
  • – regularly change the company’s alarm codes;
  • – never give keys or alarm codes to external service providers, unless it is possible to trace access and restrict it to specific time slots.

R95 – Access to the premises must be logged and auditable.
C2 D96 – C1’s recommendations are mandatory.
R97 – The control mechanisms must be robust (ref1).
R98 – Put the accesses under video protection.
R99 – Restrict access to equipment to authorized persons only.
C3 D100 – C2’s recommendations are mandatory.
D101 – Implement an intrusion detection system for vital areas, especially those not occupied 24 h a day.
Access to equipment and wiring C1 R102 – Install the servers in rooms with access control.
R103 – Install station CPUs, PLCs and network equipment in locked cabinets.
R104 – Do not leave industrial network access sockets in areas open to the public.
C2 D105 – C1’s recommendations are mandatory.
D106 – Do not leave industrial network access sockets in unattended areas.
R107 – Protect the physical integrity of the cables.
R108 – Close the plugs dedicated to maintenance and define a procedure for removing the plug including prior authorization.
R109 – Set up an opening detector with alarm for cabinets of sensitive equipment or visual control means, and define a procedure for opening including prior authorization.
C3 D110 – C2’s recommendations are mandatory.

A4.1.5. Reaction to the incidents

A disaster recovery or business continuity plan ensures the recovery or continuity of service following a disaster, regardless of its origin. With regard to cybersecurity, it is based on risk analysis, which has made it possible to identify impacts and threats.

Table A4.5. Recommendations and guidelines for incident response

Recovery or business continuity plan C1 R111 – Set up a backup plan for sensitive data, so that the system can be rebuilt afterwards.
R112 – Consider cybersecurity in recovery and business continuity plans.
C2 R113 – Test the plan at least once a year.
C3 D114 – The recommendations of C1 and C2 are mandatory.
Degraded modes C1 R115 – Plan to include in the intervention procedures an emergency mode to be able to intervene quickly in case of need, without significantly degrading the level of cybersecurity, in particular not to affect the traceability of the interventions.
R116 – Integrate degraded modes for stopping allowing them to:
  • – either stop without causing damage (material or human);
  • – or continue to operate by piloting in “manual” mode.
C2 No additional requirements.
C3 D117 – C1’s recommendations are mandatory.
Crisis management C1 R118 – Implement a crisis management process to determine:
  • – what to do when an incident is detected;
  • – who to alert;
  • – who should coordinate actions in the event of a crisis;
  • – what are the first steps to be taken.

R119 – Include in the crisis management plan a procedure to manage incidents at the right level of responsibility and decide accordingly:
  • – whether to initiate a disaster recovery plan;
  • – if legal action is necessary.

R120 – Include in the crisis management plan a postincident analysis phase to determine the origin of the incident.
C2 R121 – Test the plan at least once a year.
C3 D122 – The recommendations of C1 and C2 are mandatory.

A4.2. Technical measures

These technical measures potentially involve:

  • – servers, workstations and workstations;
  • – engineering stations and programming consoles;
  • – mobile equipment: laptops, tablets, computers, etc.;
  • – supervision software and applications (SCADA);
  • – CAMM and MES software and applications, if available;
  • – human–machine interfaces (touch screens);
  • – PLCs and remote units (RTU);
  • – network equipment (switches, routers, firewalls, wireless access points);
  • – intelligent sensors and actuators;
  • – etc.

A4.2.1. Authentication of stakeholders

The authentication of a user in a computer system requires the definition of an account, often associating a name (identifier) and a password (authentication). Other identification modes exist.

Accounts can be associated with an operating system (Windows, Linux, etc.), an application or equipment that uses a dedicated system.

Accounts have different levels of privileges, offering more or fewer possibilities to users. Administrators are often distinguished from simple users.

Table A4.6. Recommendations and guidelines for authentication

Account management C1 R123 – Identify each user in a unique way.
R124 – Protect all accounts with important privileges such as administrator accounts with an authentication mechanism.
Separate user and administrator accounts.
R125 – Avoid generic accounts, especially those with significant privileges; if impossible to avoid, limit them to very specific and documented uses.
R126 – Define roles, documented and implemented so that users’ privileges correspond exactly to their needs.
R127 – Perform an audit of events related to the use of accounts.
R128 – Delete or deactivate the accounts of former users.
C2 D129, R123, R124 and R125 are mandatory.
Do not use default or generic accounts unless there are strong operational constraints.
Do not use generic accounts with high privileges.
Separate high privilege accounts (admin) and user accounts.
D130, R126 are mandatory with validation by the user’s line manager.
D131, R128 are mandatory and complete D27 (stakeholder management procedure).
R132 – Conduct an annual review of user accounts to verify the above obligations, with particular attention to administrative accounts.
R133 – Configure read-only access for first-level maintenance tasks.
R134 – If account management is centralized, audit the configuration of the centralized directory regularly and at least once a year.
C3 D135 – R127, R132 and R134 are mandatory.
Authentication management n C1 R136 – Only make the various components (hardware and software) accessible after authentication with ID and password.
R136 – Passwords must be robust, and default passwords must be changed.
R137 – Prefer an inhibition delay to blocking in case of authentication failure.
R138 – Protect passwords in integrity and confidentiality if transmitted over the network.
R139 – If software authentication is not possible due to operational constraints, define and document palliative measures, such as:
  • – apply physical access control;
  • – limit the accessible functionalities;
  • – implement smart card identification;
  • – compartmentalize the equipment more.

An example of such a case is a SCADA joint account.
R140 – Keep password files, ensuring integrity and availability.
R141 – Define a secure procedure to reset passwords in case of loss.
C2 D142 – C1’s recommendations are mandatory.
R143 – Use strong authentication (smart card, one time password, etc.) for workstations and servers. Do the same for field equipment (PLCs, remote e/s, etc.) that allow it.
R144 – If R143 cannot be applied, reinforce the password policy (keep password history, check its quality, force renewal).
R145 – Log authentication failures and successful authentications of privilege accounts.
C3 D146, R136, R144 and R145 are mandatory.
D147, R143 are mandatory for all exposed equipment (workstations, laptops, engineering stations, programming consoles, firewalls, VPN, etc.)

A4.2.2. Architecture security

The partitioning of industrial information systems is a key measure to improve security. It is very well developed in the IEC 62443 standard (Chapter 7).

Table A4.7. Recommendations and guidelines for architecture

System partitioning C1 R148 – Cut the system into functional areas or coherent technical areas and partition them.
R149 – Implement a filtering policy between zones.
R150 – For non-IP flows, filter on source and destination identifiers.
It will also be possible to filter on the type of protocol allowed.
R151 – As far as possible, achieve physical partitioning between the functional areas of the industrial system.
R152 – Perform a logical partitioning during a physical separation by VLAN, for example.
R153 – Separate the equipment administration network from other networks (switches, gateways, routers, firewalls, etc.), at a minimum logically.
R154 – Keep the administration workstations only for this purpose and do not connect them to the Internet or a management network.
C2 D155, R148 to R151 are mandatory.
D156, R153 and R154 are mandatory. If it is not possible to carry out a partitioning because the equipment does not allow it, study possible countermeasures and assess the level of residual risk.
R157 – If possible, make the flows unidirectional between class C1 and C2 systems. A firewall can be used.
R158 – Separate the equipment administration network from other networks (physically, at least logically, using VPN tunnels using qualified products).
C3 D159 – Make unidirectional flows between C3 and non-C3 systems. Unidirectionality is physically ensured by a data diode.
R160 – Use a labeled diode.
D161 – Physically separate class 3 systems from lower class systems. It is forbidden to use a logical partitioning.
Interconnection of the management information system (considered by default of class C1) C1 R162 – Protect the interconnection with a firewall device.
R163 – Limit flows to the strict minimum.
R164 – Implement a flow filtering policy as above.
C2 D165 – C1’s recommendations are mandatory.
R166 – Make the flows unidirectional between the C2 system and the management system. A firewall can be used.
C3 D167 – Make unidirectional flows between C3 class systems and the management system. Unidirectionality is physically ensured by a data diode.
R168 – Use an organism-certified diode.
Internet access and remote sites C1 R169 – Limit Internet access. In particular, supervisory positions and equipment should not have access to them.
R170 – Limit Internet access to the system.
R171 – Use an IPSec VPN interconnection between remote sites for confidentiality, integrity and authenticity.
R172 – Set up a firewall at the interconnection gateways.
R173 – Configure the gateways in a secure way.
C2 D174, R169, R170, R171 and R172 are mandatory.
R175 – Use labeled gateways.
C3 D176 – Prohibit interconnections between the C3 system and the public network.
Remote access for nomadic workstations C1 R177 – When remote management, remote maintenance or remote diagnosis operations are required, the following rules should be applied:
  • – make connections at the request of the responsible entity;
  • – authenticate the remote connection equipment;
  • – change the login password regularly;
  • – enable logging;
  • – terminate the communication after a maximum period of inactivity;
  • – partition the equipment and filter the flows;
  • – use secure protocols that ensure integrity and authenticity.

R178 – In the case of a modem connection, use a callback system.
R179 – Use labeled connection equipment.
C2 D180 – Use a solution with:
  • – a guarantee of confidentiality, integrity and authenticity of communications (example: IPsec VPN);
  • – strong two-factor authentication;
  • – compartmentalize connection equipment and filter flows;
  • – log security events.

R181 – Use a detection probe at the gateway to analyze incoming and outgoing traffic.
C3 D182 – Remote maintenance prohibited (if necessary, integrate remote equipment into the C3 system and apply C3 level rules).
D183 – Remote diagnosis possible with the following measures:
  • – remote connection on a partitioned server;
  • – data pushed to the server via a labelled diode.
Distributed industrial systems C1 R184 – Use secure protocols that protect confidentiality, integrity and authenticity for flows through unprotected networks.
R185 – Use VPN labeled gateways at the ends of the links.
R186 – Position the equipment behind a firewall allowing only the strictly necessary flows to pass through. In particular, traffic external to the VPN should be blocked.
R187 – If necessary, avoid the Internet and use leased lines.
C2 D188, R185 and R186 are mandatory.
R189 – Use a detection probe at the gateway to analyze incoming and outgoing traffic.
C3 D190 – Prohibit links on public networks.
D191 – R189 is mandatory.
Wireless communication C1 R192 – Limit the use of wireless technologies to what is strictly necessary.
R193 – Sign or encrypt and sign flows according to usage.
R194 – Use wireless access points with:
  • – authentication of the access point and the device that connects to the infrastructure;
  • – network access control features (e.g. EAP);
  • – connection logging.

R195 – Maximize the partitioning of wireless communications by isolating wireless devices in a separate physical or logical network.
R196 – If there is no centralized supervision of safety events, review them regularly.
R197 – Reduce the range of emissions to a minimum.
C2 D198, R196 are mandatory.
D199 – Regularly apply security patches to wireless network equipment.
R200 – Use a detection probe at the connection of the access point with the rest of the network.
C3 D201, R200 are mandatory.
D202 – Avoid the use of wireless links if possible.
D203 – Prohibit the use of wireless links if critical availability is required.
D204 – Monitor security events centrally.
R205 – Use certified equipment.
Protocol security C1 R206 – Disable unsecured protocols (http, telnet, ftp, etc.) in favor of secure protocols (https, ssh, sftp, etc.) to ensure integrity, confidentiality, authenticity and absence of replay of flows.
C2 R207 – If protocols cannot be secured for technical and operational reasons, if possible, implement compensatory measures such as:
  • – perimeter protections (firewall);
  • – VPN to ensure the integrity and authenticity of flows.
C3 D208, R206 and R207 are mandatory.
Hardening of configurations disabling unnecessary components C1 R209 – For equipment, deactivate:
  • – the default accounts;
  • – unused physical ports;
  • – removable media, if not used;
  • – non-essential services (e.g. web service).
  • R210 – On workstations, laptops and servers, disable or delete:
  • – debugging and development tools for systems in production;
  • – test data and functions, as well as associated accounts;
  • – all non-essential programs.
    R211 – For PLCs and SCADA applications, disable or delete:
  • – debugging functions (integrators and equipment manufacturers);
  • – mnemonics and comments.
C2 D212, R209 are mandatory.
C3 D213, R210 and R211 are mandatory.
Hardening of configurations: reinforcement of protection C1 R214 – Apply the recommendations for hardening operating systems1.
R215 – Run applications only with the privileges necessary for their operation.
C2 D213, R215 are mandatory.
R217 – Set up tools for in-depth workstation defense, set up a white list of applications on the equipment that have the right to run.
R218 – For PLCs, when the equipment allows it, set up:
  • – access protection to the CPU and/or program;
  • – the restriction of the IP addresses that can be connected;
  • – disabling the remote programming mode.
C3 D219, R217 and R218 are mandatory.
R220 – Use labeled tools.

NOTE.– An antivirus is not always suitable for industrial systems:

  • – updating signatures often requires a connection to an external system, which can bring vulnerability;
  • – it may be incompatible with the principles and requirements of operational safety, especially if it is periodically triggered.

A4.2.3. Equipment security

In the following section, we distinguish between:

  • – programming consoles, which are nomadic equipment for PLC programming;
  • – engineering stations, which are fixed workstations dedicated to process engineering of the industrial system;
  • – administration workstations that are dedicated to the administration of infrastructure equipment (switches, servers, station, firewall, etc.) of the industrial system.

Table A4.8. Recommendations and guidelines for equipment

Hardening of configurations: integrity and authenticity C1 R221 – Integrate an integrity (checksum) and authenticity (signature) verification mechanism for software, updates and configuration files, such as:
  • –firmwares;
  • – standard operating systems and software;
  • – SCADA software packages;
  • – PLC and SCADA programs;
  • – network equipment configuration files.
C2 D222, R221 are mandatory.
R223 – Regularly check the integrity, authenticity of firmware, software and application programs (PLCs, SCADA, etc.). Ideally, once a day automatically.
C3 D224, D222 are reinforced: The supplier (OEM, developer, integrator, etc.) must sign the critical elements and the responsible entity must verify the signature upon receipt.
D225, R223 are mandatory.
Vulnerability management C1 R226 – Implement a vulnerability management process to:
  • – search for available patches to fix these vulnerabilities;
  • – identify known vulnerabilities and measure their impact on systems;
  • – deploy patches starting with the most important ones;
  • – identify vulnerabilities that could not be fixed (either because of a lack of patches or because the patch could not be applied due to operational constraints).

R227 – Apply patches as a priority on the most exposed workstations (workstations, laptops, engineering stations, programming consoles, firewalls, VPN, etc.).
C2 D228 – Clearly identify uncorrected vulnerabilities, and then implement specific monitoring and palliative measures to reduce exposure due to these vulnerabilities.
R229 – Have patches validated by suppliers before deployment.
R230 – Conduct an effective verification of the application of security patches and possibly use it as a monitoring indicator.
C3 D231, R226, R227, R229 and R230 are mandatory R232 – Implement a test environment to ensure that patches do not cause regression.
Connection
interfaces:
removable
media		 C1 R233 – Define a policy for the use of removable media (USB key, floppy disk, hard disk, etc.)
R234 – As far as possible, limit the use of removable media to the strict minimum.
R235 – Use a decontamination station to analyze and decontaminate all removable devices before using them on the industrial system.
R236 – Prohibit the connection of undecontaminated, removable devices.
R237 – Provide stakeholders with removable media dedicated to industrial systems, and prohibit the use of these media for other uses and the use of other media.
C2 D238 – C1’s recommendations are mandatory.
R239 – Disable removable media ports when their use is not necessary. If physical blocking is not possible, deactivate it logically.
C3 D240, R239 are mandatory.
D241 – Set up an airlock to exchange data with the industrial system, located in a controlled area. Data exchange is a one-off action that must be governed by a procedure.
R242 – Use a labeled airlock.
Connection
interfaces:
network access points		 C1 R243 – Clearly identify and identify access points.
R244 – Disable unused access points (switches, hubs, patchbays, maintenance sockets on fieldbuses, etc.).
C2 D245 – C1’s recommendations are mandatory.
D246 – In case of attempted connection and disconnection on network ports, report an alert and process it.
C3 D247 – Allow network access points to be accessible only in controlled premises.
Connection interfaces:
mobile equipment		 C1 R248 – Prohibit the use of personal devices (computers, tablets, USB sticks, cameras, etc.).
R249 – Set up guidelines for the use of mobile terminals and signage to remind the charter.
R250 – Identify and validate the equipment authorized to connect to the systems.
R251 – Implement a process for allocating mobile terminals in order to:
  • – validate the assignment of the terminal by the line manager;
  • – ensure traceability between the terminal and its users;
  • – make the user aware of the rules of use in force.

R252 – When the equipment contains sensitive data, encrypt its storage memory.
C2 D253, R248 to R252 are mandatory.
R254 – Use equipment dedicated to the industrial system, including for external service providers.
R255 – Do not allow this equipment to leave the site.
C3 D256, R251, R254 and R255 are mandatory.
Security of
programming
consoles and
administration
workstations		 C1 R257 – Use engineering stations dedicated to engineering tasks, do not connect them to the Internet, install them in premises with access control, apply the hardening rules described above and switch them off when not in use.
R258 – Use programming consoles dedicated to maintenance and operation activities, do not connect them to the Internet, do not connect them to systems other than the industrial system, apply the rules for mobile terminals and the rules for hardening configuration and strengthening protection, store them in a secure room, add a clear identifier (visual marking for example).
R259 – Use administration workstations dedicated to the administration of infrastructure equipment, do not connect them to the Internet, install them in premises with access control, apply the hardening rules described above and switch them off when not in use.
R260 – Do not install development tools on production machines. Only production environments (runtime) should be installed on SCADA servers and stations for example.
R261 – If the above recommendation is difficult to implement, as in the case of the use of digital control-command systems (DCS), then compensatory solutions should be considered to isolate the system and reduce its attack surface.
C2 D262, R257 to R261 are mandatory.
C3 R263 – Do not use administration stations for permanent system monitoring.
Secure development C1 R264 – Define rules of good programming practice, then apply them and check their implementation. For example, use the advanced options of some compilers or tools dedicated to checking good programming practices.
C2 R265 – Use a development environment dedicated to the industrial system.
R266 – Implement and apply secure coding rules in addition to the good development practices mentioned above.
R267 – Systematically use static analysis tools and robustness tests.
R268 – Have code audits performed by external service providers.
C3 D269, R265, R266, R267 and R268 are mandatory.
D270 – The security level of the development environment must be verified by audits.

NOTE.– Installation of patches is a tricky operation, because it can jeopardize the proper functioning of the installation. This update should preferably be carried out as part of maintenance operations.

NOTE.– Some compilers, SCADA and PLC development workshops have many options for reporting additional warnings to the user. Often, these options are not enabled by default. They prevent many programming errors and bugs that can lead to vulnerabilities and should be used.

A4.2.4. Industrial system monitoring

Table A4.9. Recommendations and guidelines for monitoring

Event logs C1 R271 – Define an event management policy to:
  • – determine which relevant events should be taken into account;
  • – organize their storage (volume, shelf life);
  • – define the conditions for analysis (preventive, postincident, etc.);
  • – define the events that should generate alerts.

R272 – Enable traceability functions for hardware and software that allow it, such as syslog, SNMPv3, Windows Event.
R273 – Implement a centralized and secure event log management system that takes into account backup, confidentiality and integrity.
R274 – Trace and record parameter changes for sensors and actuators, servo and control functions, etc. This can be done by some SCADA software.
C2 D275, R271, R272 and R273 are mandatory.
R276 – Regularly analyze newspapers.
C3 D277, R276 are mandatory.
R278 – Implement a SIEM solution centralizing event logs and allowing logs to be correlated to detect security incidents.
The SIEM must be placed behind a diode to avoid being considered a class 3 device.
Means
of
detection		 C1 No additional requirements.
C2 R279 – Implement intrusion detection means on the periphery of the systems and on the points identified as critical, which include in particular:
  • – interconnections between remote systems;
  • – interconnections of remote management systems;
  • – interconnections between the management IS and the industrial IS;
  • – specific connection points to the outside world (e.g. industrial Wi-Fi);
  • – the airlock stations;
  • – the federating network of industrial supervision stations (SCADA);
  • – networks of PLCs considered sensitive.

R280 – Use labeled detection means.
R281 – Centralize the events collected by the probes.
R282 – Develop the process that describes the consideration of events reported by the probes.
C3 D283, R279, R281 and R282 are obligatory.

Here is a non-exhaustive list of audit events to configure:

  • – authentication attempts (success or failure);
  • – user actions in the system;
  • – use of privilege accounts;
  • – failures of safety mechanisms;
  • – network connection attempts;
  • – start and stop the audit functionalities;
  • – activation, deactivation and modification of the behavior or parameters of security mechanisms (authentication, audit generation, etc.);
  • – actions taken due to a failure in the storage of audits;
  • – any attempt to export information;
  • – use of the management function;
  • – modification of the user group that is part of a role;
  • – detection of a physical violation;
  • – any attempt to establish a user session;
  • – attempts to load, modify or recover programs, firmware or firmware;
  • – modification of system parameters (time, IP or non-IP address, cycle time, watchdog, etc.);
  • – modification or forcing of application data;
  • – switching an equipment into stop, on, stand-by, restart mode.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.133.160.14