Implementing controls • Purpose: Where there are risks that cannot be accepted, controls need to be selected and implemented with the aim of lowering probability, vulnerability and/or impact. • How: Controls should always follow from the risk assessment. For inspiration, a standard baseline best-practice set of controls such as ISO/IEC 27002 can be used to select those controls that mitigate the risk. • Guidelines: Whether controls mitigate a risk requires expertise in technical, legal, procedural, physical/facility aspects. Ensure the expert view on all these aspects is available. 051
Remarks Use the available controls in ISO/IEC 27001 (Annex A) and ISO/IEC 27002 for further guidance or inspiration for risk mitigation activities A.5 Information security policies Organisation of information security Human resource security Asset management A.6 A.7 A.8 ... 052
Statement of Applicability (SoA) • The SoA is a document that must be produced as a result of the risk assessment process. • The document can be a matrix, by listing the used information security controls (to mitigate and/or minimize the risks), the treatment options, and often also the person(s) accountable for them. • This document is required during auditing activities to provide an overview of which controls were implemented as part of the ISMS scope. • Internal audit: The internal audit will be performed by the internal auditors of the organization. They also have the responsibility of checking the compliance of the organization (according to the ISMS scope) with the information security policy. • External audit: The external audit will be performed by an independent third party. They will also assess the documentation, processes and policies. This includes the SoA. SoA 053
2.3. Residual risks
Understand and mitigate the new risks of the controls • Purpose: Determine whether the controls that have been selected to mitigate the unacceptable risks introduce new risks themselves. • How: Discuss the implications of the selected controls with suitable experts. Decide on mitigation strategies if new risks are found. • Guidelines: An example might be key management. Physical locks or electronic keys (passwords/certificates) introduce all sorts of new problems (key management, key loss, revoking keys etc.) that need to be understood and mitigated. 055
Accept any residual risks and repeat • Purpose: Formally accept the residual risks and embed this process. • How: Have the organization’s management document the fact that residual risks do exist but that these can or should be accepted. Embed this risk management process within the management system, perhaps based on ISO/IEC 27001 or even ISO 9001 (quality) or ISO/IEC 20000 (service management). • Guidelines: This risk management process should be linked to the incident management process and the change management process. This guarantees that new threats will be considered and mitigated when required. Residual risk acceptance 056
Control PDCA • ISO/IEC 27001 and other standards for management systems (ISO 9001 and COBIT for instance) describe information security risk management in terms of the plan-do-check-act (Deming) cycle. • Think thoroughly about what is required taking into account policy, risk assessment and management (e.g. plan). Then implement what is required (procedures, controls etc.) and measure performance (e.g. do) and periodically – as often as required to assure risks are mitigated – audit/review it all (e.g. check). Lastly all possible improvements should again be considered (e.g. act) and lead to new plans. • Information security often adds up the Control function on the PDCA model. Plan Do Act Check Control 057
3. Information security controls
Strategies for controls • Therefore, there are a number of options (strategies) for information security improvement: • Focus on ‘plan’ (describing the planned controls); • Focus on ‘do’; • Focus on ‘check/act’ (continuous improvement). Information security can only be improved by implementing controls, i.e. the Plan-activities of the PDCA cycle are the most important ones. Nevertheless, implementing the right controls is crucial and testing whether these actually work (i.e. mitigate risk) is even more important. 059 Plan Do Act Check
A good mix of controls • Mitigates the relevant CIA aspects • On all three hierarchical levels • Takes into account both logical (ICT) as well as physical protection • Is embedded and documented • Important remarks: • Top management reviews the ISMS on a regular basis. Input is the performance of the ISMS. Output is decisions on improvement and change. • The commitment of management and tactical control are the most important aspects. • Operational controls actually improve security. • If a risk can be mitigated by a physical control this is preferred above logical (physical controls can be audited a lot more easily). • If a risk can be mitigated by a logical control this is preferred above procedural (people make mistakes, a logical control then acts as a safety net). 060
Protecting confidentiality Group R W DL_SALES DL_OPS DL_ADM • Preventing leakage of confidential information relies on preventing access to the information. When this fails, or cannot be guaranteed (on public networks for instance), encryption is required. • Preventing access to information means user identification and authorization is critical. Subsequent access should be based on access control lists (ACL) that describe what kind of access the user has; read, write, execute, create, delete etc. • A good access control covers the three categories: technical controls, programs, and policies. • Encryption of information comes down to scrambling the information in such a way that legitimate users can easily descramble it but an adversary cannot. This requires some sort of digital key and a one-way decryption method that will not allow descrambling data without the key. 061
ISO/IEC 27002:2022 • This standard contains 93 controls. • Grouped into 4 themes: • People (8 controls) • Physical (14 controls) • Technological (34 controls) • Organizational (37 controls) • Each control has a number of attributes in five categories: • Control type • InfoSec properties • Cybersecurity concepts • Operational capabilities • Security domains ISO/IEC 27002:2022 062
Control type • Preventive • Detective • Corrective Attributes in controls 063 Security domains • Governance_and_ Ecosystem • Protection • Defense • Resilience Operational capabilities • Governance • Asset_management • Information_protection • Human_resource_security • Physical_security • System_and_network_securi ty • Application_security • Secure_configuration • Identity_and_access_manag ement • Threat_and_vulnerability_m anagement • Continuity • Supplier_relationships_secu rity, • Legal_and_Compliance • Information_security_event_ management • Information_security_assura nce Cybersecurity concepts • Identify • Protect • Detect • Respond • Recover Information security properties • Confidentiality • Integrity • Availability
ISO/IEC 27002 themes ISO/IEC 27002:2022 5. Organizational controls 6. People controls 7. Physical controls 8. Technological controls 064
Organizational controls Organizational 065 Organizational 5.1 Policies for information security 5.2 Information security roles and responsibilities 5.3 Segregation of duties 5.4 Management responsibilities 5.5 Contact with authorities 5.6 Contact with special interest groups 5.7 Threat intelligence 5.8 Information security in project management 5.9 Inventory of information and other associated assets 5.10 Acceptable use of information and other associated assets 5.11 Return of assets 5.12 Classification of information 5.13 Labelling of information 5.14 Information transfer 5.15 Access control 5.16 Identity management 5.17 Authentication information 5.18 Access rights 5.19 Information security in supplier relationships 5.20 Addressing information security within supplier agreements 5.21 Managing information security in the ICT supply chain 5.22 Monitoring, review and change management of supplier services 5.23 Information security for use of cloud services 5.24 Information security incident management planning and preparation 5.25 Assessment and decision on information security events 5.26 Response to information security incidents 5.27 Learning from information security incidents 5.28 Collection of evidence 5.29 Information security during disruption 5.30 ICT readiness for business continuity 5.31 Legal, statutory, regulatory and contractual requirements 5.32 Intellectual property rights 5.33 Protection of records 5.34 Privacy and protection of PII 5.35 Independent review of information security 5.36 Compliance with policies, rules and standards for information security 5.37 Documented operating procedures
People controls People 066 6.1 Screening 6.2 Terms and conditions of employment 6.3 Information security awareness, education and training 6.4 Disciplinary process 6.5 Responsibilities after termination or change of employment 6.6 Confidentiality or non-disclosure agreements 6.7 Remote working 6.8 Information security event reporting
Physical controls Physical 067 7.1 Physical security perimeters 7.2 Physical entry 7.3 Securing offices, rooms and facilities 7.4 Physical security monitoring 7.5 Protecting against physical and environmental threats 7.6 Working in secure areas 7.7 Clear desk and clear screen 7.8 Equipment siting and protection 7.9 Security of assets off-premises 7.10 Storage media 7.11 Supporting utilities 7.12 Cabling security 7.13 Equipment maintenance 7.14 Secure disposal or re-use of equipment
Technological controls Technological 068 Technological 8.1 User endpoint devices 8.2 Privileged access rights 8.3 Information access restriction 8.4 Access to source code 8.5 Secure authentication 8.6 Capacity management 8.7 Protection against malware 8.8 Management of technical vulnerabilities 8.9 Configuration management 8.10 Information deletion 8.11 Data masking 8.12 Data leakage prevention 8.13 Information back-up 8.14 Redundancy of information processing facilities 8.15 Logging 8.16 Monitoring activities 8.17 Clock synchronization 8.18 Use of privileged utility programs 8.19 Installation of software on operational systems 8.20 Networks security 8.21 Security of network services 8.22 Segregation of networks 8.23 Web filtering 8.24 Use of cryptography 8.25 Secure development life cycle 8.26 Application security requirements 8.27 Secure system architecture and engineering principles 8.28 Secure coding 8.29 Security testing in development and acceptance 8.30 Outsourced development 8.31 Separation of development, test and production environments 8.32 Change management 8.33 Test information 8.34 Protection of information systems during audit testing
3.1. Organizational controls
Examples of organizational controls Policies for information security A document that helps all employees to understand why information security is important and what their role is. 5.1 5.7 5.9 - 5.11 5.12 5.37 5.19 - 5.21 Threat intelligence Describes the security organization, confidentiality agreements and how to deal with relevant parties. Asset management Procedures for the inventory, ownership and use of assets. Classification of information Procedures for the classification of types of information and correct handling of these various types. Documented operating procedures All day-to-day procedures for information management, procedures for separation of duties and development, test and operation. Information security in supplier relationships Identification of risks when dealing with external parties (suppliers, customers etc.) and including these in contracts. Note: not all ISO/IEC 27002 controls are included; this list is not exhaustive, the numbers refer to ISO/IEC 27002:2022. 070
5.1 Policies for information security Information security policy and its review process 071
5.37 Documented operating procedures Information security policy and its review process Management commitment Asset management including classification of assets/information Change management procedures Separation of duties Access control program & policy and its review process Incident management procedures Identification of applicable legislation Protection of intellectual property rights Protection of personal information Internal Public … 072
Procedure and process (definition from ISO 9001) Specified way to carry out an activity or a process. Procedures can be documented or not. When a procedure is documented, the term “written procedure” or “documented procedure” is frequently used. The document that contains a procedure can be called a procedure document. A set of interrelated or interacting activities which transforms inputs to outputs. A B C Procedure Process 073
5.12 Classification of information Scope Labelling Asset owners Controls/Policy • Only secure what is required (according to the ISMS’ scope). • Consider: How to consistently add a label to printed documents, for instance to a printed e-mail message? • Add a corresponding label to the information, for instance: highly confidential, confidential, or public. • Classified documents can only be accessed by persons cleared for that level or higher. • Let the asset owners classify information based on the impact of loss, damage and/or disclosure. • Have rules to deal with these labels, for instance confidential information should be encrypted or transported by registered mail. Internal public … 074
5.7 Threat intelligence 075 Strategic Tactical Operational Threat intelligence should be • Relevant • Insightful • Contextual • Actionable Sources of threat intelligence - Verizon Data Breach Investigation Report - CrowdStrike Global Threat Report - Hardware and software vendors Threat intelligence program 1. Create a plan 2. Know who needs the information 3. Involve the right people 4. Implement the right tools, techniques and procedures 5. Understand the difference between threat data and threat intelligence 6. Integrate with your organization’s information security program 7. Communicate
5.9, 5.10, 5.11 Asset management 076 5.9 Inventory of information and other associated assets 5.10 Acceptable use of information and other associated assets 5.11 Return of assets Asset Management DB Acceptable Use Policy Return
5.19-5.21 Information security in supplier management 077 Suppliers come in various forms • Software (desktop, server, database, network) • Hardware (desktop, server, network) • Facilities (air conditioning, buildings, physical security) • Business process outsourcing (BPO) Level of access to information Low High Supplier T&Cs Contractual Agreement 5.19 Information security in supplier relationships 5.20 Addressing information security within supplier agreements 5.21 Managing information security in the ICT supply chain
Continuity/availability Confidentiality Integrity Availability Information security deals with the triad. ISO/IEC 27002 control 5.29 is called “Information security during disruption” and deals with aspects of business continuity management (BCM). The BCM process within an organization is of course much broader than just information security incident management. From an information security perspective, the term continuity should be interpreted as: • continuity of security when an organization faces a business continuity problem; • availability of security systems, procedures and services during normal operation. 078
Business continuity planning Periodic exercise Organizational change Any BCP should be exercised periodically. It should lead to fully restore the services within the recovery time objective (RTO) and recovery point objective (RPO) requirements. All personnel involved should be knowledgeable in their roles and activities. Any change to the organization should lead to changes to the BCP. This requires a strong interface with any change management process within the organization. 079
Continuity controls 5.29 Information security during disruption This is the main control related to how to protect information security during disruptive events when a business continuity plan is invoked. Note: not all ISO/IEC 27002 controls are included; this list is not exhaustive, the numbers refer to ISO/IEC 27002:2022. 5.30 ICT readiness for business continuity This control focuses on the redundancy of ICT services, such as servers, network and applications. 080
ICT business continuity planning When a severe incident has led to substantial damage to information processing and related services, there is one important constraint: time! The maximum allowable downtime (if longer the organization will not be able to recover) should have been translated into recovery time objective (RTO) and recovery point objective (RPO). RTO RPO RTO specifies the duration of time and a service level within which a service must be restored after a disaster or disruption. RPO is the maximum amount of data that might be lost from a service due to a disruption. A disaster recovery plan must cover both RTO and RPO: 081
ICT business continuity planning RPO heavily depends on the business risks an organization faces when transactions are lost. It dictates the service level target required. Examples of RPOs and required IT infrastructure: 1 – 2 days: daily backup using network or cloud replication 1 – 2 minutes: mirrored disks 082
Guidance for information back-up and restore • It should be understood, at every level within the organization, that ‘back-up’ is not a problem. • The problem is being able to restore all relevant information whatever the threat to data loss is, under all circumstances, within the required timeframe. • When it is properly understood that ‘restore’ is the problem, it will be clear that ‘back-up’ is only part of the solution. • For proper restore a large number of other requirements exist, such as: • Understand what the timeframe for restore is. • Understand the order in which systems should be restored. • Availability of systems to restore on. • Personnel knowledgeable in restore activities. • Software required to do the restore. • Restore procedures describing the activities required. • Test procedures after a restore to decide whether production can restart. 083
ICT business continuity planning RTO dictates whether cold standby, hot standby or mirrored data processing is required. Since time is the only constraint, RTOs expressed in hours dictate that all activities detecting, escalating and mitigating the incident are documented and sufficiently trained. The document describing this is the business continuity plan (BCP) or IT continuity plan. During a business continuity incident the personnel involved in solving the situation might be different than during normal operation. This requires that the BCP describes critical activities in large detail. Drafting a BCP is done by assembling knowledgeable experts who during normal operation are responsible for ICT or business processes. They define the actions, lead times and required facilities/services to be able to perform those actions. Subsequently these actions are put into a Gantt chart. 084
Guidance for procedures Incident management procedures These describe how incidents are managed, i.e. escalation paths, who is responsible, how incidents are resolved, who should be informed and how the organization learns from incidents. Change management procedures These describe how (ICT) changes are defined, how risks are mitigated, who approves and how changes are controlled. Continuity management procedures These describe the actions, responsibilities and escalation paths of major incidents (that might lead to a crisis situation) that are required to keep the organization from failing in business-in-unusual circumstances. 085
3.2. Physical controls
Examples of physical controls 7.1 Physical security perimeters Dividing the physical area(s) into zones and clearly marking these zones. 7.2 Physical entry Locks, keys, electronic entry systems controlled by keys, badges, biometrics etc. Public area Restricted area Note: not all ISO/IEC 27002 controls are included; this list is not exhaustive, the numbers refer to ISO/IEC 27002:2022. 087
Examples of physical controls 7.6 Working in secure areas Procedures that describe the conditions for working in protected areas. For instance specifying that in such areas nobody may work alone. 7.11 Supporting utilities Protection against loss of utilities (cooling, power, gas, water). Describes the need for uninterruptible power supplies and no-break systems. Note: not all ISO/IEC 27002 controls are included; this list is not exhaustive, the numbers refer to ISO27002:2022. 7.14 Secure disposal or re-use of equipment Procedures and technical tooling for the secure disposal of media (paper, disks) containing classified information. 088
7.1 Perimeter protection Some examples of perimeter protection Landscaping Fences Gates Bollards Perimeter IDS CCTV 089
7.2 Physical access control & biometrics Identification (who are you) • Someone professes to have a certain identity • Uses user ID, badge or biometrics Authorization (what rights do you have) • Based on the identity and access control lists (ACL) your access will be controlled Biometrics • False negative (type I) • False positive (type II) Access control Biometrics 090 Authentication (what rights do you have) • Something you have (badge, key…) • Something you know (pin, password…) • Something you are (fingerprint, iris scan…)
Guidance for physical controls Check legislation when surveillance cameras and other privacy sensitive equipment is to be installed. Access rights management needs a tight interface with the human resource department when personnel is hired, fired or when someone’s position within the organization changes. Zoning helps to decide which parts of the organization need strict physical entry controls. For example a policy for a loading/unloading area. General entry Datacenter Operations Physical controls are often managed by the organization’s facilities management department. To optimize these controls for the protection of information the security officer/manager, the ICT manager and the facility manager should closely work together on this subject. 091
Guidance for physical controls A thorough environmental risk assessment should dictate what kind of physical entry controls are required. IT systems are very vulnerable to electrical power problems. A backup power supply (uninterruptible power supply – UPS – for short outages and no-break systems – generators – for longer outages) is always required. Building management systems – controlling power, lighting, access, temperature etc. – are computer systems themselves. These need the same protection as other computer systems within the organization. Physical barriers should not obstruct personnel leaving the premises in case of an emergency. 092
3.3. People controls
Examples of people controls Note: not all ISO/IEC 27002 controls are included; this list is not exhaustive, the numbers refer to ISO/IEC 27002:2022. 6.6 Confidentiality or non-disclosure agreements Clarifies the legal responsibilities of personnel for the protection of information confidentiality. 6.1 Screening Procedures for the screening of personnel in those positions where special risks could occur, for instance in financial positions or in positions where confidentiality requirements are high. In case of fraud to investigate the employee’s workstation might be the only legal possibility. 6.3 Information security awareness, education, and training Procedures and all activities the organization takes to train employees in information security in general and the organization’s policies in particular. 094 6.8 Information security event reporting Clarifies the legal responsibilities of personnel for the protection of information confidentiality.
Awareness, training • Aspects: • Knowledge (understanding the rules) • Attitude (willingness to cooperate) • Behavior (obeying the rules) • The awareness program must be established in alignment with the target group and led by the information security management. • The level of awareness of the target group should be measured. The actual mindset of employees towards information security can for example be observed in a walkabout after office hours. • Behavioral change will only happen when the target group has obtained all required knowledge and understands why security controls are required. • Tools: class-based training, e-learning, one-to-one talks, discussion, gaming. Information security 095
Social engineering Employees should be trained to identify social engineering and know how to identify who may have access to what asset(s). Most humans are willing to help. Adversaries use this to their advantage by building trust with an employee. After gaining their trust, the adversary uses the employee to obtain information that helps them to get access to the organization’s assets. With the success of social media an enormous amount of personal information is publicly available. Employees should understand and follow company policies what they can and cannot disclose on social media about the organization they work for. 096
Guidance for people controls Special care should be given to those functions where high risks occur. Especially in situations where access privileges are granted. If needed, duties should be separated to reduce risk. For instance administrators should only be allowed to use admin rights when another administrator is present (“four-eye principle”). Defining roles and responsibilities is of the utmost importance. It is also vital to make sure that employees understand their responsibilities and any that disciplinary steps are taken if they abuse them. All access rights should be reviewed periodically, especially when employees change roles within the organization. This requires action from the HR department and the relevant managers. System administrator System administrator Business analyst 097
3.4. Technological controls
Examples of technological controls Note: not all ISO/IEC 27002 controls are included; this list is not exhaustive, the numbers refer to ISO/IEC 27002:2022. 8.7 Protection against malware Malware is abundant. Antivirus software and procedures for prevention are mandatory. 8.15 Logging Especially high-risk activities should be logged to media were an adversary has no access to. This facilitates detection of incidents. Logging also facilitates demonstrating the effectiveness of security controls. 8.20-8.22 Networks security, security of network services, segregation of networks A layered security approach means that the organization’s network must be divided into zones with special attention to those zones that have external connections. 8.24 Use of cryptography The use of electronic keys and certificates should be controlled. 8.8 Separation of development, test and production environments System development needs to be done without risking disrupting a production environment and impacting users. The development and test environments should therefore be separate from the production environment. 99 8.19 Installation of software on operational systems End users may be able to download software from the Internet which contains malware or other security vulnerabilities. The use of software should be controlled to prevent vulnerabilities to be introduced.
8.15 Logging 100 Event management • Collects information from systems, applications and network elements • Correlates this information to determine if there is an incident, such as an outage or a security incident • Is, in part, dependent on logging of events on the systems themselves (syslogs) or on logging servers Information security events that should be logged • Unauthorized access attempts • Changes to configuration or data • Privileged access attempts • Creation, modification or deletion of user IDs • Alarms generated by the system Not all events lead to an incident, but all events should be analyzed to verify if an incident actually took place. All logs should be protected to preserve their confidentiality, integrity and availability in order to analyze the information in them.