Implementing Security: what technology for which controls?

Implementing Security: what technology for which controls?

Overview

Whether in Information Technology or Operational Technology environments, fully understanding industry-specific policies, technologies, and sector-aware control requirements can be daunting. The focus of security professionals should be on foundational security capabilities necessary to protect the system and information CIA (Confidentiality, Integrity, and Availability), and the mechanisms needed to achieve that.

This article reviews security technologies and techniques that implement controls and countermeasures reported in standards and regulations, and used in threat modeling. A special focus is on the ISA/IEC 62443 standard series and NIST SP 800-53. Our aim is to provide practical solutions that map high-level security requirements and desired security capabilities into the actual technologies and mitigation techniques implementing them, along with example products and vendors.

Introduction

Cybersecurity standards usually define a set of requirements and objectives for the security of target systems. The NIST cybersecurity framework¹, for instance, defines five core functions divided into categories that represent high-level cybersecurity objectives. Each category is further split into sub-categories representing more specific desired outcomes, which are generally implemented using third-party security solutions and techniques. Similarly, the ISA/IEC 62443 framework defines 7 foundational requirements, each of which is further split into system or control requirements, which are then used to implement four different security levels².

In general, cybersecurity standards and frameworks do not define specific mitigation techniques and security technologies (or products/vendors) capable of implementing security requirements or controls. This is left to the organization's IT and security experts who should identify the technologies and products that best integrate with the IT infrastructure and existing tooling. Some standards, however, still provide an overview of security tools, and mitigation mechanisms or technologies, that might be applied to protect target systems. This is the case of the ISA/IEC 62443, part 3-1 (Security technologies for industrial automation and control systems), which is the technology-oriented part of the standard discussing mechanisms that would be used in implementing the security requirements discussed in other parts of the standard; essentially parts 3-3 (System security requirements and security levels) & 4-2 (Technical security requirements for IACS components).

On the other hand, the NIST SP 800-82 (Guide to Industrial Control Systems Security)³ does not discuss security technologies and techniques, nor security controls for that matter. It provides, in Appendix F, guidance for applying controls that are defined in NIST 800-53, which, in its revision 5, specifies 20 control families. NIST 800-82 gives, however, guidance on how to adapt those control families for applicability in OT environments (except PII processing, which is not considered).

Other publication series are more hands-on, e.g., NIST’s 1800 series, which presents practical solutions by building example implementations of real-world architectures and using security technologies from a set of collaborators (cybersecurity vendors). NIST SP 1800-10⁴, for instance, dedicated to protecting information and system integrity in manufacturing environments, evaluates the endpoint solution Carbon Black (VMware) against two security capabilities; application allowlisting and file integrity checking. Three other capabilities (anomaly/modification detection, user authentication and authorization, and remote access) are mapped to other security products from 8 different vendors, including Microsoft and Tenable⁴.

Define relevant and strategic security capabilities

The considered standards outline security capabilities that fall under all functions of the NIST framework (Identify, Protect, Detect, Respond, and Recover). However, depending on the security policy and strategy, focus areas, business imperatives, the threat landscape, and risk tolerance, each company would define its own list of priorities and how to allocate resources, given its strategic and improvement goals.

The ISA/IEC 62443 standard, for instance, defines the following 7 security capabilities, called foundational requirements, totaling, in turn, 58 controls and system requirements:

• FR1: Identification and authentication,
• FR2: Use/Privilege control,
• FR3: System Integrity,
• FR4: Data confidentiality,
• FR5: Restricting data flows,
• FR6: Timely and structured response to events, and
• FR7: Resources availability.

On the other hand, NIST SP 800-53 controls (a total of over 1000) are defined within the following 20 families:

• AC: Access Control,
• AT: Awareness and Training,
• AU: Audit and Accountability,
• CA: Assessment, Authorization, and Monitoring,
• CM: Configuration Management,
• CP: Contingency Planning,
• IA: Identification and Authentication,
• IR: Incident Response,
• MA: Maintenance,
• MP: Media Protection,
• PE: Physical and Environmental Protection,
• PL: Planning,
• PM: Program Management,
• PS: Personnel Security,
• PT: Personally Identifiable Information Processing and Transparency,
• RA: Risk Assessment,
• SA: System and Services Acquisition,
• SC: System and Communications Protection,
• SI: System and Information Integrity, and
• SR: Supply Chain Risk Management.

From a practical perspective, however, if an organization needs to implement or comply with one (or more) of these standards, it is best to approach it as a set of capabilities and strategies rather than tackling each and every control within these families or categories. Our recommendations would include the following focus areas, for instance, which can be adapted and prioritized based on risk assessment and the quantification of the potential impact on the business (or any other security metrics):

1. Assets and components inventory and scanning: account for all of your assets and environment/software components, and ensure they are protected/up-to-date, and continually tested, e.g., red-teaming. This includes the organization’s code base and CI/CD pipeline.
2. Authentication and authorization: ensure that only authorized entities have access, with the least privilege control principle.
3. Malware protection and anomaly detection: relevant network and endpoint policies and protections that include behavioral analysis, and continuous monitoring capability.
4. File and communication filtering and integrity: ensure that data is not modified (at rest and in transit) and unauthorized changes and communications are detected.
5. Continuous logging and monitoring: maintaining an immutable record of events on endpoints and network activity, along with a capability to collect and analyze additional telemetry and event data if necessary, and respond in a timely manner should an incident happen.
6. Redundancy and resilience: ensure sufficient duplication of components and the system's ability to recover in the case of fault, whether intentional or unintentional.
7. The human factor: ensure that your workforce is trained and knows what to look out for to avoid falling victim to attacks, e.g., phishing.

Mapping controls to technologies

As already discussed, when a standard defines a security requirement or control, whether required or recommended; the technologies, mechanisms, or tools that implement it are almost never discussed. Endpoint solutions, for instance, can be suitable to address detection and system protection controls as well as monitoring controls identified in any given standard. The same would apply to other technologies, e.g., Firewalls, IPD/IDS, etc., which would provide visibility into assets and data on the network or the endpoint, restrict access, detect anomalies, provide resiliency, scan for misconfiguration and vulnerabilities, and so on.

In Table 1., we will give an example mapping that links the above-mentioned recommended capabilities to technologies, as well as the high-level control families or categories described in both the ISA/IEC 62443 and NIST 800-53. By providing such mapping, we aim at helping defenders identify security technologies that would implement suggested controls when carrying out threat modeling activities or if an organization finds itself needing to comply with a security standard or framework. It answers the very important question of how security technologies and mechanisms support compliance, regulatory standards, and security frameworks.

Table 1. Example mapping of security capabilities and controls to technologies.

Conclusion

The main purpose of threat modeling is to reduce design flaws and shift security testing and requirements implementation (as) left (as possible). Those security practices and requirements, whether driven by regulation or best practices, usually rely on tooling for their implementation.

In this article, we have provided possible solutions that would implement a set of recommended cybersecurity capabilities. For an organization wanting to protect the confidentiality, integrity, and availability of its system and information, and conducting threat modeling recommending the appropriate security requirements and mitigations of risks associated to its setup, the technology solutions mapping presented in this document may be put to good use.