From 3ea4d4fbb0e30167694f4ab5c000f9fcc4aae58f Mon Sep 17 00:00:00 2001 From: Richard Kranendonk Date: Sun, 19 Apr 2026 19:05:10 +0200 Subject: [PATCH] Took copyrighted material out of the GIS repo --- .DS_Store | Bin 8196 -> 8196 bytes Corpus/MoCs/Change management MoC.md | 12 + .../ISO 27002 Themes and Attributes.md | 56 ++ .../ISO_27001_2022_OT 0 Introduction.md | 23 + .../ISO_27001_2022_OT 1 Scope.md | 7 + ...SO_27001_2022_OT 2 Normative references.md | 5 + ...anding the organization and its context.md | 6 + ... and expectations of interested parties.md | 12 + ... information security management system.md | 14 + ... Information security management system.md | 4 + ...1_2022_OT 5.1 Leadership and commitment.md | 22 + .../ISO_27001_2022_OT 5.2 Policy.md | 18 + ...roles, responsibilities and authorities.md | 12 + ...ISO_27001_OT 10.1 Continual improvement.md | 4 + ...0.2 Nonconformity and corrective action.md | 29 + .../ISO_27001_OT 6.1.1 General.md | 18 + ....2 Information security risk assessment.md | 24 + ...1.3 Information security risk treatment.md | 29 + ...objectives and planning to achieve them.md | 34 + .../ISO_27001_OT 6.3 Planning of changes.md | 4 + .../ISO_27001_OT 7.1 Resources.md | 4 + .../ISO_27001_OT 7.2 Competence.md | 15 + .../ISO_27001_OT 7.3 Awareness.md | 11 + .../ISO_27001_OT 7.4 Communication.md | 13 + ...ISO_27001_OT 7.5 Documented information.md | 47 + ...OT 8.1 Operational planning and control.md | 12 + ....2 Information security risk assessment.md | 6 + ...8.3 Information security risk treatment.md | 9 + ...g, measurement, analysis and evaluation.md | 20 + .../ISO_27001_OT 9.2 Internal audit.md | 28 + .../ISO_27001_OT 9.3 Management review.md | 34 + .../ISO_27001_OT F Foreword.md | 22 + .../ISO_27001_OT Terms and definitions.md | 8 + .../ISO 27001 2023 ISMS op hoofdlijnen.md | 223 +++++ .../ISO 27001 2023 Processen en Artefacten.md | 51 ++ .../ISO_27001_2023_NL_Aanpassingen.md | 54 ++ ...27001_2023_NL_BT 3 Termen en definities.md | 2 + .../ISO_27001_2023_NL_Index.md | 40 + .../ISO27001-NL-2023/ISO_27001_2023_NL_PDF.md | 6 + ...information and other associated assets.md | 39 + ...ISO_27002_2022_5.11_OT Return of assets.md | 34 + ...2_5.12_OT Classification of information.md | 44 + ...2_2022_5.13_OT Labelling of information.md | 47 + ...27002_2022_5.14_OT Information transfer.md | 147 ++++ .../ISO_27002_2022_5.15_OT Access control.md | 76 ++ ..._27002_2022_5.16_OT Identity management.md | 44 + ...2022_5.17_OT Authentication information.md | 72 ++ .../ISO_27002_2022_5.18_OT Access rights.md | 63 ++ ...tion security in supplier relationships.md | 71 ++ ....1_OT Policies for information security.md | 74 ++ ...ion security within supplier agreements.md | 72 ++ ...mation security in the ICT supply chain.md | 58 ++ ... change management of supplier services.md | 57 ++ ...tion security for use of cloud services.md | 53 ++ ...ent management planning and preparation.md | 66 ++ ...decision on information security events.md | 35 + ...ponse to information security incidents.md | 35 + ...ing from information security incidents.md | 20 + ...002_2022_5.28_OT Collection of evidence.md | 38 + ... Information security during disruption.md | 30 + ...ion security roles and responsibilities.md | 27 + ...T ICT readiness for business continuity.md | 42 + ...regulatory and contractual requirements.md | 73 ++ ...22_5.32_OT Intellectual property rights.md | 48 + ...7002_2022_5.33_OT Protection of records.md | 39 + ...2_5.34_OT Privacy and protection of PII.md | 31 + ...ependent review of information security.md | 38 + ... and standards for information security.md | 31 + ...5.37_OT Documented operating procedures.md | 55 ++ ...27002_2022_5.3_OT Segregation of duties.md | 33 + ...2022_5.4_OT Management responsibilities.md | 29 + ...02_2022_5.5_OT Contact with authorities.md | 15 + ...OT Contact with special interest groups.md | 25 + ...O_27002_2022_5.7_OT Threat intelligence.md | 45 + ...ormation security in project management.md | 50 ++ ...information and other associated assets.md | 69 ++ .../ISO_27002_2022_6.1_OT Screening.md | 48 + ...2_OT Terms and conditions of employment.md | 38 + ...urity awareness, education and training.md | 75 ++ ..._27002_2022_6.4_OT Disciplinary process.md | 69 ++ ...ter termination or change of employment.md | 27 + ...dentiality or non-disclosure agreements.md | 89 ++ .../ISO_27002_2022_6.7_OT Remote working.md | 137 +++ ...OT Information security event reporting.md | 95 ++ .../ISO_27002_2022_7.10_OT Storage media.md | 123 +++ ...27002_2022_7.11_OT Supporting utilities.md | 73 ++ ...ISO_27002_2022_7.12_OT Cabling security.md | 81 ++ ...7002_2022_7.13_OT Equipment maintenance.md | 85 ++ ... Secure disposal or re-use of equipment.md | 85 ++ ...022_7.1_OT Physical security perimeters.md | 42 + .../ISO_27002_2022_7.2_OT Physical entry.md | 151 ++++ ... Securing offices, rooms and facilities.md | 53 ++ ...022_7.4_OT Physical security monitoring.md | 85 ++ ...inst physical and environmental threats.md | 73 ++ ...002_2022_7.6_OT Working in secure areas.md | 65 ++ ...2022_7.7_OT Clear desk and clear screen.md | 73 ++ ..._7.8_OT Equipment siting and protection.md | 75 ++ ..._7.9_OT Security of assets off-premises.md | 83 ++ ...27002_2022_8.10_OT Information deletion.md | 52 ++ .../ISO_27002_2022_8.11_OT Data masking.md | 58 ++ ...02_2022_8.12_OT Data leakage prevention.md | 41 + ...O_27002_2022_8.13_OT Information backup.md | 46 + ...cy of information processing facilities.md | 40 + .../ISO_27002_2022_8.15_OT Logging.md | 95 ++ ...7002_2022_8.16_OT Monitoring activities.md | 84 ++ ...7002_2022_8.17_OT Clock synchronization.md | 23 + ...8_OT Use of privileged utility programs.md | 36 + ...tion of software on operational systems.md | 46 + ...27002_2022_8.1_OT User endpoint devices.md | 73 ++ ...SO_27002_2022_8.20_OT Networks security.md | 49 ++ ...22_8.21_OT Security of network services.md | 49 ++ ...02_2022_8.22_OT Segregation of networks.md | 23 + .../ISO_27002_2022_8.23_OT Web filtering.md | 33 + ..._27002_2022_8.24_OT Use of cryptography.md | 77 ++ ...2_8.25_OT Secure development life cycle.md | 45 + ...26_OT Application security requirements.md | 89 ++ ...architecture and engineering principles.md | 84 ++ .../ISO_27002_2022_8.28_OT Secure coding.md | 93 ++ ...y testing in development and acceptance.md | 53 ++ ...02_2022_8.2_OT Privileged access rights.md | 47 + ...002_2022_8.30_OT Outsourced development.md | 39 + ...pment, test and production environments.md | 104 +++ ...SO_27002_2022_8.32_OT Change management.md | 48 + ...ISO_27002_2022_8.33_OT Test information.md | 31 + ...nformation systems during audit testing.md | 33 + ...2_8.3_OT Information access restriction.md | 53 ++ ...27002_2022_8.4_OT Access to source code.md | 32 + ...27002_2022_8.5_OT Secure authentication.md | 42 + ...O_27002_2022_8.6_OT Capacity management.md | 47 + ..._2022_8.7_OT Protection against malware.md | 57 ++ ...Management of technical vulnerabilities.md | 130 +++ ...02_2022_8.9_OT Configuration management.md | 74 ++ ...T 5.1 Policies for information security.md | 77 ++ ...2_OT 5.12 Classification of information.md | 1 + .../ISO_27002_2022_OT 5.15 Access control.md | 1 + ...2022_OT 5.17 Authentication information.md | 74 ++ ...tion security in supplier relationships.md | 71 ++ ...ion security roles and responsibilities.md | 27 + ...ion security within supplier agreements.md | 72 ++ ...mation security in the ICT supply chain.md | 58 ++ ... change management of supplier services.md | 55 ++ ...tion security for use of cloud services.md | 58 ++ ...ent management planning and preparation.md | 68 ++ ...ing from information security incidents.md | 23 + ... Information security during disruption.md | 1 + ...27002_2022_OT 5.3 Segregation of duties.md | 35 + ...0 ICT readiness for business continuity.md | 49 ++ ...22_OT 5.32 Intellectual property rights.md | 48 + ...2022_OT 5.4 Management responsibilities.md | 32 + ...02_2022_OT 5.5 Contact with authorities.md | 36 + ....6 Contact with special interest groups.md | 29 + ...O_27002_2022_OT 5.7 Threat intelligence.md | 48 + ...ormation security in project management.md | 52 ++ ...information and other associated assets.md | 1 + ...urity awareness, education and training.md | 1 + ...O_27002_2022_OT 8.13 Information backup.md | 1 + .../ISO_27002_2022_OT 8.15 Logging.md | 5 + ...7002_2022_OT 8.16 Monitoring activities.md | 3 + ...tion of software on operational systems.md | 1 + ...02_2022_OT 8.2 Privileged access rights.md | 1 + ...02_2022_OT 8.22 Segregation of networks.md | 1 + ..._27002_2022_OT 8.24 Use of cryptography.md | 184 ++++ ...2_OT 8.25 Secure development life cycle.md | 90 ++ ... 8.26 Application security requirements.md | 93 ++ ...architecture and engineering principles.md | 94 ++ .../ISO_27002_2022_OT 8.28 Secure coding.md | 99 +++ ...y testing in development and acceptance.md | 1 + ...SO_27002_2022_OT 8.32 Change management.md | 1 + ...27002_2022_OT 8.5 Secure authentication.md | 1 + ..._2022_OT 8.7 Protection against malware.md | 58 ++ ...Management of technical vulnerabilities.md | 241 ++++++ ...02_2022_OT 8.9 Configuration management.md | 79 ++ ...erms, definitions and abbreviated terms.md | 818 ++++++++++++++++++ ...O_27002_2022_NL_3.2_BT Afgekorte termen.md | 97 +++ .../ISO_27002_2022_NL_4.1_BT Hoofdstukken.md | 41 + ...02_2022_NL_4.2_BT Thema's en attributen.md | 47 + ...022_NL_4.3_BT Indeling beheersmaatregel.md | 21 + ...en andere gerelateerde bedrijfsmiddelen.md | 52 ++ ....11_BT Retourneren van bedrijfsmiddelen.md | 49 ++ ...NL_5.12_BT Classificeren van informatie.md | 54 ++ ..._2022_NL_5.13_BT Labelen van informatie.md | 63 ++ ...22_NL_5.14_BT Overdragen van informatie.md | 117 +++ ...002_2022_NL_5.15_BT Toegangsbeveiliging.md | 86 ++ ...27002_2022_NL_5.16_BT Identiteitsbeheer.md | 56 ++ ...BT Beheren van authenticatie-informatie.md | 88 ++ ...NN Beheren van authenticatie-informatie.md | 61 ++ ...O_27002_2022_NL_5.18_BT Toegangsrechten.md | 103 +++ ...atiebeveiliging in leveranciersrelaties.md | 92 ++ ...eleidsregels voor informatiebeveiliging.md | 114 +++ ...veiliging in leveranciersovereenkomsten.md | 89 ++ ...n informatiebeveiliging in de ICT-keten.md | 79 ++ ...an wijzigingen van leveranciersdiensten.md | 74 ++ ...ging voor het gebruik van clouddiensten.md | 84 ++ ...ordelijkheden bij informatiebeveiliging.md | 45 + ...CT-gereedheid voor bedrijfscontinuïteit.md | 66 ++ ...O_27002_2022_NL_5.3_BT Functiescheiding.md | 50 ++ ..._5.4_BT Managementverantwoordelijkheden.md | 50 ++ ..._5.5_BT Contact met overheidsinstanties.md | 37 + ...BT Contact met speciale belangengroepen.md | 40 + ... Informatie en analyses over dreigingen.md | 79 ++ ...ormatiebeveiliging in projectmanagement.md | 69 ++ ...en andere gerelateerde bedrijfsmiddelen.md | 79 ++ ...022_NL_8.24_BT Gebruik van cryptografie.md | 4 + ...022_NL_8.24_NN Gebruik van cryptografie.md | 35 + ...SO_27002_2022_NL_8.28_BT Veilig coderen.md | 0 ..._27002_2022_NL_8.32_BT Wijzigingsbeheer.md | 4 + .../ISO_27002_2022_NL_Index.md | 114 +++ .../ISO27002-NL-2022/ISO_27002_2022_NL_PDF.md | 8 + Corpus/Standards/ISO_27002_2022_What's_New.md | 44 + ...anding the organization and its context.md | 28 + .../MoCs/ISO_27001_2022_00_MoC Index EXT.md | 113 +++ .../MoCs/ISO_27001_2022_00_MoC Index.md | 52 ++ ...001_2022_10.1_MoC Continual improvement.md | 3 + ...MoC Nonconformity and corrective action.md | 3 + .../MoCs/ISO_27001_2022_10_MoC Improvement.md | 6 + ...anding the organization and its context.md | 20 + ... and expectations of interested parties.md | 8 + ... information security management system.md | 9 + ... Information security management system.md | 7 + ..._2022_4_MoC Context of the organization.md | 8 + ..._2022_5.1_MoC Leadership and commitment.md | 10 + .../MoCs/ISO_27001_2022_5.2_MoC Policy.md | 10 + ...roles, responsibilities and authorities.md | 15 + .../MoCs/ISO_27001_2022_5_MoC Leadership.md | 11 + .../MoCs/ISO_27001_2022_6.1.1_MoC General.md | 4 + ...oC Information security risk assessment.md | 42 + ...MoC Information security risk treatment.md | 6 + ...ions to address risks and opportunities.md | 7 + ...objectives and planning to achieve them.md | 4 + ..._27001_2022_6.3_MoC Planning of changes.md | 3 + .../MoCs/ISO_27001_2022_6_MoC Planning.md | 10 + .../MoCs/ISO_27001_2022_7.1_MoC Resources.md | 3 + .../MoCs/ISO_27001_2022_7.2_MoC Competence.md | 3 + .../MoCs/ISO_27001_2022_7.3_MoC Awareness.md | 3 + .../ISO_27001_2022_7.4_MoC Communication.md | 3 + .../MoCs/ISO_27001_2022_7.5.1_MoC General.md | 13 + ...01_2022_7.5.2_MoC Creating and updating.md | 10 + ...3_MoC Control of documented information.md | 21 + ...001_2022_7.5_MoC Documented information.md | 7 + .../MoCs/ISO_27001_2022_7_MoC Support.md | 12 + ....1_MoC Operational planning and control.md | 3 + ...oC Information security risk assessment.md | 6 + ...MoC Information security risk treatment.md | 5 + .../MoCs/ISO_27001_2022_8_MoC Operation.md | 7 + ...g, measurement, analysis and evaluation.md | 3 + .../ISO_27001_2022_9.2_MoC Internal audit.md | 5 + ...SO_27001_2022_9.3_MoC Management review.md | 5 + ...27001_2022_9_MoC Performance evaluation.md | 12 + ...27002_2022_00_Controls_enumeration_list.md | 94 ++ ...information and other associated assets.md | 5 + ...SO_27002_2022_5.11_MoC Return of assets.md | 5 + ..._5.12_MoC Classification of information.md | 5 + ..._2022_5.13_MoC Labelling of information.md | 5 + ...7002_2022_5.14_MoC Information transfer.md | 5 + .../ISO_27002_2022_5.15_MoC Access control.md | 7 + ...27002_2022_5.16_MoC Identity management.md | 9 + ...022_5.17_MoC Authentication information.md | 22 + .../ISO_27002_2022_5.18_MoC Access rights.md | 9 + ...tion security in supplier relationships.md | 5 + ...ion security within supplier agreements.md | 5 + ...mation security in the ICT supply chain.md | 5 + ... change management of supplier services.md | 5 + ...tion security for use of cloud services.md | 5 + ...ent management planning and preparation.md | 5 + ...decision on information security events.md | 5 + ...ponse to information security incidents.md | 5 + ...ing from information security incidents.md | 5 + ...02_2022_5.28_MoC Collection of evidence.md | 6 + ... Information security during disruption.md | 8 + ...ion security roles and responsibilities.md | 5 + ...C ICT readiness for business continuity.md | 12 + ...regulatory and contractual requirements.md | 3 + ...2_5.32_MoC Intellectual property rights.md | 3 + ...002_2022_5.33_MoC Protection of records.md | 9 + ..._5.34_MoC Privacy and protection of PII.md | 4 + ...ependent review of information security.md | 6 + ... and standards for information security.md | 5 + ....37_MoC Documented operating procedures.md | 6 + ...7002_2022_5.3_MoC Segregation of duties.md | 7 + ...022_5.4_MoC Management responsibilities.md | 7 + ...2_2022_5.5_MoC Contact with authorities.md | 7 + ...oC Contact with special interest groups.md | 7 + ..._27002_2022_5.7_MoC Threat intelligence.md | 8 + ...ormation security in project management.md | 5 + ...information and other associated assets.md | 10 + .../MoCs/ISO_27002_2022_6.1_MoC Screening.md | 6 + ..._MoC Terms and conditions of employment.md | 6 + ...urity awareness, education and training.md | 6 + ...27002_2022_6.4_MoC Disciplinary process.md | 3 + ...ter termination or change of employment.md | 3 + ...dentiality or non-disclosure agreements.md | 3 + .../ISO_27002_2022_6.7_MoC Remote working.md | 3 + ...oC Information security event reporting.md | 6 + .../ISO_27002_2022_7.10_MoC Storage media.md | 3 + ...7002_2022_7.11_MoC Supporting utilities.md | 7 + ...SO_27002_2022_7.12_MoC Cabling security.md | 3 + ...002_2022_7.13_MoC Equipment maintenance.md | 3 + ... Secure disposal or re-use of equipment.md | 3 + ...22_7.1_MoC Physical security perimeters.md | 7 + .../ISO_27002_2022_7.2_MoC Physical entry.md | 3 + ... Securing offices, rooms and facilities.md | 3 + ...22_7.4_MoC Physical security monitoring.md | 3 + ...inst physical and environmental threats.md | 3 + ...02_2022_7.6_MoC Working in secure areas.md | 3 + ...022_7.7_MoC Clear desk and clear screen.md | 3 + ...7.8_MoC Equipment siting and protection.md | 3 + ...7.9_MoC Security of assets off-premises.md | 3 + ...7002_2022_8.10_MoC Information deletion.md | 3 + .../ISO_27002_2022_8.11_MoC Data masking.md | 3 + ...2_2022_8.12_MoC Data leakage prevention.md | 3 + ..._27002_2022_8.13_MoC Information backup.md | 6 + ...cy of information processing facilities.md | 3 + .../MoCs/ISO_27002_2022_8.15_MoC Logging.md | 7 + ...002_2022_8.16_MoC Monitoring activities.md | 6 + ...002_2022_8.17_MoC Clock synchronization.md | 3 + ..._MoC Use of privileged utility programs.md | 3 + ...tion of software on operational systems.md | 6 + ...7002_2022_8.1_MoC User endpoint devices.md | 6 + ...O_27002_2022_8.20_MoC Networks security.md | 3 + ...2_8.21_MoC Security of network services.md | 3 + ...2_2022_8.22_MoC Segregation of networks.md | 6 + .../ISO_27002_2022_8.23_MoC Web filtering.md | 3 + ...27002_2022_8.24_MoC Use of cryptography.md | 7 + ..._8.25_MoC Secure development life cycle.md | 5 + ...6_MoC Application security requirements.md | 3 + ...architecture and engineering principles.md | 3 + .../ISO_27002_2022_8.28_MoC Secure coding.md | 3 + ...y testing in development and acceptance.md | 3 + ...2_2022_8.2_MoC Privileged access rights.md | 9 + ...02_2022_8.30_MoC Outsourced development.md | 3 + ...pment, test and production environments.md | 3 + ...O_27002_2022_8.32_MoC Change management.md | 5 + ...SO_27002_2022_8.33_MoC Test information.md | 5 + ...nformation systems during audit testing.md | 6 + .../MoCs/ISO_27002_2022_8.34_MoC.md.md | 3 + ..._8.3_MoC Information access restriction.md | 11 + ...7002_2022_8.4_MoC Access to source code.md | 7 + ...7002_2022_8.5_MoC Secure authentication.md | 7 + ..._27002_2022_8.6_MoC Capacity management.md | 6 + ...2022_8.7_MoC Protection against malware.md | 6 + ...Management of technical vulnerabilities.md | 8 + ...2_2022_8.9_MoC Configuration management.md | 6 + .../MoCs/ISO_27002_2022_Index_DEPRECIATED.md | 100 +++ ...002_2022_Vertaaltabel_Engels_Nederlands.md | 97 +++ iso27DIY-mkII-MoC.md => iso27DIY-MoC.md | 0 345 files changed, 12578 insertions(+) create mode 100644 Corpus/MoCs/Change management MoC.md create mode 100644 Corpus/Standards/ISO 27002 Themes and Attributes.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 0 Introduction.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 1 Scope.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 2 Normative references.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.1 Understanding the organization and its context.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.2 Understanding the needs and expectations of interested parties.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.3 Determining the scope of the information security management system.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.4 Information security management system.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 5.1 Leadership and commitment.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 5.2 Policy.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 5.3 Organizational roles, responsibilities and authorities.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 10.1 Continual improvement.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 10.2 Nonconformity and corrective action.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.1.1 General.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.1.2 Information security risk assessment.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.1.3 Information security risk treatment.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.2 Information security objectives and planning to achieve them.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.3 Planning of changes.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.1 Resources.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.2 Competence.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.3 Awareness.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.4 Communication.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.5 Documented information.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 8.1 Operational planning and control.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 8.2 Information security risk assessment.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 8.3 Information security risk treatment.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 9.1 Monitoring, measurement, analysis and evaluation.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 9.2 Internal audit.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 9.3 Management review.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT F Foreword.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT Terms and definitions.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO 27001 2023 ISMS op hoofdlijnen.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO 27001 2023 Processen en Artefacten.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_Aanpassingen.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_BT 3 Termen en definities.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_Index.md create mode 100644 Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_PDF.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.10_OT Acceptable use of information and other associated assets.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.11_OT Return of assets.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.12_OT Classification of information.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.13_OT Labelling of information.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.14_OT Information transfer.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.15_OT Access control.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.16_OT Identity management.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.17_OT Authentication information.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.18_OT Access rights.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.19_OT Information security in supplier relationships.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.1_OT Policies for information security.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.20_OT Addressing information security within supplier agreements.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.23_OT Information security for use of cloud services.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.24_OT Information security incident management planning and preparation.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.25_OT Assessment and decision on information security events.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.26_OT Response to information security incidents.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.27_OT Learning from information security incidents.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.28_OT Collection of evidence.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.29_OT Information security during disruption.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.2_OT Information security roles and responsibilities.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.30_OT ICT readiness for business continuity.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.31_OT Legal, statutory, regulatory and contractual requirements.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.32_OT Intellectual property rights.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.33_OT Protection of records.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.34_OT Privacy and protection of PII.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.35_OT Independent review of information security.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.36_OT Compliance with policies, rules and standards for information security.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.37_OT Documented operating procedures.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.3_OT Segregation of duties.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.4_OT Management responsibilities.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.5_OT Contact with authorities.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.6_OT Contact with special interest groups.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.7_OT Threat intelligence.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.8_OT Information security in project management.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.9_OT Inventory of information and other associated assets.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.1_OT Screening.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.2_OT Terms and conditions of employment.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.3_OT Information security awareness, education and training.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.4_OT Disciplinary process.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.5_OT Responsibilities after termination or change of employment.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.6_OT Confidentiality or non-disclosure agreements.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.7_OT Remote working.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.8_OT Information security event reporting.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.10_OT Storage media.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.11_OT Supporting utilities.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.12_OT Cabling security.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.13_OT Equipment maintenance.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.14_OT Secure disposal or re-use of equipment.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.1_OT Physical security perimeters.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.2_OT Physical entry.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.3_OT Securing offices, rooms and facilities.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.4_OT Physical security monitoring.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.5_OT Protecting against physical and environmental threats.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.6_OT Working in secure areas.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.7_OT Clear desk and clear screen.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.8_OT Equipment siting and protection.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.9_OT Security of assets off-premises.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.10_OT Information deletion.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.11_OT Data masking.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.12_OT Data leakage prevention.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.13_OT Information backup.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.14_OT Redundancy of information processing facilities.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.15_OT Logging.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.16_OT Monitoring activities.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.17_OT Clock synchronization.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.18_OT Use of privileged utility programs.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.19_OT Installation of software on operational systems.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.1_OT User endpoint devices.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.20_OT Networks security.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.21_OT Security of network services.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.22_OT Segregation of networks.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.23_OT Web filtering.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.24_OT Use of cryptography.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.25_OT Secure development life cycle.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.26_OT Application security requirements.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.28_OT Secure coding.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.29_OT Security testing in development and acceptance.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.2_OT Privileged access rights.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.30_OT Outsourced development.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.31_OT Separation of development, test and production environments.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.32_OT Change management.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.33_OT Test information.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.34_OT Protection of information systems during audit testing.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.3_OT Information access restriction.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.4_OT Access to source code.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.5_OT Secure authentication.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.6_OT Capacity management.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.7_OT Protection against malware.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.9_OT Configuration management.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.1 Policies for information security.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.12 Classification of information.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.15 Access control.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.17 Authentication information.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.19 Information security in supplier relationships.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.2 Information security roles and responsibilities.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.20 Addressing information security within supplier agreements.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.21 Managing information security in the ICT supply chain.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.22 Monitoring, review and change management of supplier services.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.23 Information security for use of cloud services.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.24 Information security incident management planning and preparation.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.27 Learning from information security incidents.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.29 Information security during disruption.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.3 Segregation of duties.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.30 ICT readiness for business continuity.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.32 Intellectual property rights.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.4 Management responsibilities.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.5 Contact with authorities.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.6 Contact with special interest groups.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.7 Threat intelligence.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.8 Information security in project management.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.9 Inventory of information and other associated assets.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 6.3 Information security awareness, education and training.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.13 Information backup.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.15 Logging.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.16 Monitoring activities.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.19 Installation of software on operational systems.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.2 Privileged access rights.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.22 Segregation of networks.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.24 Use of cryptography.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.25 Secure development life cycle.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.26 Application security requirements.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.27 Secure system architecture and engineering principles.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.28 Secure coding.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.29 Security testing in development and acceptance.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.32 Change management.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.5 Secure authentication.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.7 Protection against malware.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.8 Management of technical vulnerabilities.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.9 Configuration management.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_OT 3 Terms, definitions and abbreviated terms.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_3.2_BT Afgekorte termen.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_4.1_BT Hoofdstukken.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_4.2_BT Thema's en attributen.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_4.3_BT Indeling beheersmaatregel.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.10_BT Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.11_BT Retourneren van bedrijfsmiddelen.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.12_BT Classificeren van informatie.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.13_BT Labelen van informatie.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.14_BT Overdragen van informatie.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.15_BT Toegangsbeveiliging.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.16_BT Identiteitsbeheer.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.17_BT Beheren van authenticatie-informatie.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.17_NN Beheren van authenticatie-informatie.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.18_BT Toegangsrechten.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.19_BT Informatiebeveiliging in leveranciersrelaties.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.1_BT Beleidsregels voor informatiebeveiliging.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.20_BT Adresseren van informatiebeveiliging in leveranciersovereenkomsten.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.21_BT Beheren van informatiebeveiliging in de ICT-keten.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.22_BT Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.23_BT Informatiebeveiliging voor het gebruik van clouddiensten.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.2_BT Rollen en verantwoordelijkheden bij informatiebeveiliging.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.30_BT ICT-gereedheid voor bedrijfscontinuïteit.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.3_BT Functiescheiding.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.4_BT Managementverantwoordelijkheden.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.5_BT Contact met overheidsinstanties.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.6_BT Contact met speciale belangengroepen.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.7_BT Informatie en analyses over dreigingen.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.8_BT Informatiebeveiliging in projectmanagement.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.9_BT Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.24_BT Gebruik van cryptografie.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.24_NN Gebruik van cryptografie.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.28_BT Veilig coderen.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.32_BT Wijzigingsbeheer.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_Index.md create mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_PDF.md create mode 100644 Corpus/Standards/ISO_27002_2022_What's_New.md create mode 100644 Corpus/Standards/ISO_31000_OT 5.4.1 Understanding the organization and its context.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_00_MoC Index EXT.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_00_MoC Index.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_10.1_MoC Continual improvement.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_10.2_MoC Nonconformity and corrective action.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_10_MoC Improvement.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_4.1_MoC Understanding the organization and its context.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_4.3_MoC Determining the scope of the information security management system.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_4.4_MoC Information security management system.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_4_MoC Context of the organization.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_5.1_MoC Leadership and commitment.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_5.2_MoC Policy.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_5.3_MoC Organizational roles, responsibilities and authorities.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_5_MoC Leadership.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_6.1.1_MoC General.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_6.1.2_MoC Information security risk assessment.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_6.1.3_MoC Information security risk treatment.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_6.1_MoC Actions to address risks and opportunities.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_6.2_MoC Information security objectives and planning to achieve them.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_6.3_MoC Planning of changes.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_6_MoC Planning.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_7.1_MoC Resources.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_7.2_MoC Competence.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_7.3_MoC Awareness.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_7.4_MoC Communication.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_7.5.1_MoC General.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_7.5.2_MoC Creating and updating.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_7.5.3_MoC Control of documented information.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_7.5_MoC Documented information.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_7_MoC Support.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_8.1_MoC Operational planning and control.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_8.2_MoC Information security risk assessment.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_8.3_MoC Information security risk treatment.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_8_MoC Operation.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_9.1_MoC Monitoring, measurement, analysis and evaluation.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_9.2_MoC Internal audit.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_9.3_MoC Management review.md create mode 100644 Corpus/Standards/MoCs/ISO_27001_2022_9_MoC Performance evaluation.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_00_Controls_enumeration_list.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.10_MoC Acceptable use of information and other associated assets.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.11_MoC Return of assets.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.12_MoC Classification of information.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.13_MoC Labelling of information.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.14_MoC Information transfer.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.15_MoC Access control.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.16_MoC Identity management.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.17_MoC Authentication information.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.18_MoC Access rights.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.19_MoC Information security in supplier relationships.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.20_MoC Addressing information security within supplier agreements.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.21_MoC Managing information security in the ICT supply chain.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.22_MoC Monitoring, review and change management of supplier services.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.23_MoC Information security for use of cloud services.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.24_MoC Information security incident management planning and preparation.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.25_MoC Assessment and decision on information security events.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.26_MoC Response to information security incidents.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.27_MoC Learning from information security incidents.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.28_MoC Collection of evidence.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.29_MoC Information security during disruption.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.2_MoC Information security roles and responsibilities.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.30_MoC ICT readiness for business continuity.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.31_MoC Legal, statutory, regulatory and contractual requirements.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.32_MoC Intellectual property rights.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.33_MoC Protection of records.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.34_MoC Privacy and protection of PII.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.35_MoC Independent review of information security.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.36_MoC Compliance with policies, rules and standards for information security.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.37_MoC Documented operating procedures.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.3_MoC Segregation of duties.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.4_MoC Management responsibilities.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.5_MoC Contact with authorities.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.6_MoC Contact with special interest groups.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.7_MoC Threat intelligence.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.8_MoC Information security in project management.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_5.9_MoC Inventory of information and other associated assets.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_6.1_MoC Screening.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_6.2_MoC Terms and conditions of employment.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_6.3_MoC Information security awareness, education and training.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_6.4_MoC Disciplinary process.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_6.5_MoC Responsibilities after termination or change of employment.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_6.6_MoC Confidentiality or non-disclosure agreements.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_6.7_MoC Remote working.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_6.8_MoC Information security event reporting.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.10_MoC Storage media.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.11_MoC Supporting utilities.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.12_MoC Cabling security.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.13_MoC Equipment maintenance.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.14_MoC Secure disposal or re-use of equipment.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.1_MoC Physical security perimeters.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.2_MoC Physical entry.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.3_MoC Securing offices, rooms and facilities.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.4_MoC Physical security monitoring.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.5_MoC Protecting against physical and environmental threats.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.6_MoC Working in secure areas.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.7_MoC Clear desk and clear screen.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.8_MoC Equipment siting and protection.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_7.9_MoC Security of assets off-premises.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.10_MoC Information deletion.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.11_MoC Data masking.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.12_MoC Data leakage prevention.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.13_MoC Information backup.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.14_MoC Redundancy of information processing facilities.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.15_MoC Logging.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.16_MoC Monitoring activities.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.17_MoC Clock synchronization.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.18_MoC Use of privileged utility programs.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.19_MoC Installation of software on operational systems.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.1_MoC User endpoint devices.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.20_MoC Networks security.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.21_MoC Security of network services.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.22_MoC Segregation of networks.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.23_MoC Web filtering.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.24_MoC Use of cryptography.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.25_MoC Secure development life cycle.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.26_MoC Application security requirements.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.27_MoC Secure system architecture and engineering principles.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.28_MoC Secure coding.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.29_MoC Security testing in development and acceptance.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.2_MoC Privileged access rights.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.30_MoC Outsourced development.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.31_MoC Separation of development, test and production environments.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.32_MoC Change management.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.33_MoC Test information.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.34_MoC Protection of information systems during audit testing.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.34_MoC.md.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.3_MoC Information access restriction.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.4_MoC Access to source code.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.5_MoC Secure authentication.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.6_MoC Capacity management.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.7_MoC Protection against malware.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.8_MoC Management of technical vulnerabilities.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_8.9_MoC Configuration management.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_Index_DEPRECIATED.md create mode 100644 Corpus/Standards/MoCs/ISO_27002_2022_Vertaaltabel_Engels_Nederlands.md rename iso27DIY-mkII-MoC.md => iso27DIY-MoC.md (100%) diff --git a/.DS_Store b/.DS_Store index 19087ceabdb171543da4f2199ca916b1b1d6e788..a784c66f98d3400a4884a02fdfbb24f8020fde41 100644 GIT binary patch delta 61 zcmZp1XmQx^RZx(hA(Nq)A)mpB!JNT`!IL3!vVf32qwiz~AwwWpBy@|>ceAhXLdMN+ QWyF~$Ht=j_m-x#L0Qox+OaK4? delta 67 zcmZp1XmQx^RZv=lA(Nq)A)mpB!JNT`!IL49L6;$yAsfi@oXjSq&zL*eOvn&OW(eJ4 U%-!rPypVBYu_W_mc8S0205NP4cK`qY diff --git a/Corpus/MoCs/Change management MoC.md b/Corpus/MoCs/Change management MoC.md new file mode 100644 index 0000000..b65ee95 --- /dev/null +++ b/Corpus/MoCs/Change management MoC.md @@ -0,0 +1,12 @@ +#iso27002/2022/EN + +Change Management in ISO 27002: +- [[ISO_27002_2022_5.8_MoC Information security in project management|5.8:]] Information security in project management +- [[ISO_27002_2022_5.22_MoC Monitoring, review and change management of supplier services|5.22:]] Monitoring, review and change management of supplier services +- [[ISO_27002_2022_8.28_MoC Secure coding|8.28:]] Secure coding +- [[ISO_27002_2022_8.29_MoC Security testing in development and acceptance|8.29:]] Security testing in development and acceptance +- [[ISO_27002_2022_8.32_MoC Change management|8.32:]] Change management + +Also check the topic of risk / impact assessment. + +5796×3260 \ No newline at end of file diff --git a/Corpus/Standards/ISO 27002 Themes and Attributes.md b/Corpus/Standards/ISO 27002 Themes and Attributes.md new file mode 100644 index 0000000..e77089c --- /dev/null +++ b/Corpus/Standards/ISO 27002 Themes and Attributes.md @@ -0,0 +1,56 @@ +# ISO 27002 Themes and Attributes + +## Themes +In ISO 27002, controls are categorized into four main themes: +* **Organizational** (Clause 5) +* **People** (Clause 6) +* **Physical** (Clause 7) +* **Technological** (Clause 8) + +## Attributes +Every control is associated with five attributes, which allow organizations to view and categorize the controls from different perspectives. The attributes and their possible values are: + +**1. Control Type** +Views controls from the perspective of when and how the control modifies risk regarding the occurrence of an information security incident. +* Preventive +* Detective +* Corrective + +**2. Information Security Properties** +Views controls from the perspective of which characteristic of information the control contributes to preserving. +* Confidentiality +* Integrity +* Availability + +**3. Cybersecurity Concepts** +Views controls based on their association with the cybersecurity framework concepts defined in ISO/IEC TS 27110. +* Identify +* Protect +* Detect +* Respond +* Recover + +**4. Operational Capabilities** +Views controls from the practitioner’s perspective of information security capabilities. +* Governance +* Asset_management +* Information_protection +* Human_resource_security +* Physical_security +* System_and_network_security +* Application_security +* Secure_configuration +* Identity_and_access_management +* Threat_and_vulnerability_management +* Continuity +* Supplier_relationships_security +* Legal_and_compliance +* Information_security_event_management +* Information_security_assurance + +**5. Security Domains** +Views controls from the perspective of four high-level information security domains. +* Governance_and_Ecosystem +* Protection +* Defence +* Resilience \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 0 Introduction.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 0 Introduction.md new file mode 100644 index 0000000..8623006 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 0 Introduction.md @@ -0,0 +1,23 @@ +#iso27001/2022/EN + +# Introduction + +## 0.1 General + +This document has been prepared to provide requirements for establishing, implementing, maintaining and continually improving an information security management system. The adoption of an information security management system is a strategic decision for an organization. The establishment and implementation of an organization's information security management system is influenced by the organization's needs and objectives, security requirements, the organizational processes used and the size and structure of the organization. All of these influencing factors are expected to change over time. + +The information security management system preserves the confidentiality, integrity and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed. + +It is important that the information security management system is part of and integrated with the organization's processes and overall management structure and that information security is considered in the design of processes, information systems, and controls. It is expected that an information security management system implementation will be scaled in accordance with the needs of the organization. + +This document can be used by internal and external parties to assess the organization\'s ability to meet the organization's own information security requirements. + +The order in which requirements are presented in this document does not reflect their importance or imply the order in which they are to be implemented. The list items are enumerated for reference purpose only. + +ISO/IEC 27000 describes the overview and the vocabulary of information security management systems, referencing the information security management system family of standards (including ISO/IEC 27003, ISO/IEC 27004 and ISO/IEC 27005), with related terms and definitions. + +## 0.2 Compatibility with other management system standards + +This document applies the high-level structure, identical sub-clause titles, identical text, common terms, and core definitions defined in Annex SL of ISO/IEC Directives, Part 1, Consolidated ISO Supplement, and therefore maintains compatibility with other management system standards that have adopted the Annex SL. + +This common approach defined in the Annex SL will be useful for those organizations that choose to operate a single management system that meets the requirements of two or more management system standards. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 1 Scope.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 1 Scope.md new file mode 100644 index 0000000..81fa321 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 1 Scope.md @@ -0,0 +1,7 @@ +#iso27001/2022/EN + +# 1 Scope + +This document specifies the requirements for establishing, implementing, maintaining and continually improving an information + +security management system within the context of the organization. This document also includes requirements for the assessment and treatment of information security risks tailored to the needs of the organization. The requirements set out in this document are generic and are intended to be applicable to all organizations, regardless of type, size or nature. Excluding any of the requirements specified in Clauses 4 to 10 is not acceptable when an organization claims conformity to this document. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 2 Normative references.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 2 Normative references.md new file mode 100644 index 0000000..825801e --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 2 Normative references.md @@ -0,0 +1,5 @@ +#iso27001/2022/EN + +# 2 Normative references + +The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.1 Understanding the organization and its context.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.1 Understanding the organization and its context.md new file mode 100644 index 0000000..ea71efe --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.1 Understanding the organization and its context.md @@ -0,0 +1,6 @@ +# Clause 4.1: Understanding the organization and its context + +The organization shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its information security management system. + +NOTE Determining these issues refers to establishing the external and internal context of the organization considered in [[ISO_31000_OT 5.4.1 Understanding the organization and its context|Clause 5.4.1]] of ISO 31000:2018. + diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.2 Understanding the needs and expectations of interested parties.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.2 Understanding the needs and expectations of interested parties.md new file mode 100644 index 0000000..def5f7a --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.2 Understanding the needs and expectations of interested parties.md @@ -0,0 +1,12 @@ +#iso27001/2022/EN +# 4.2 Understanding the needs and expectations of interested parties + +The organization shall determine: + +a\) interested parties that are relevant to the information security management system; + +b\) the relevant requirements of these interested parties; + +c\) which of these requirements will be addressed through the information security management system. + +NOTE The requirements of interested parties can include legal and regulatory requirements and contractual obligations. diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.3 Determining the scope of the information security management system.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.3 Determining the scope of the information security management system.md new file mode 100644 index 0000000..6dcbd43 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.3 Determining the scope of the information security management system.md @@ -0,0 +1,14 @@ +#iso27001/2022/EN +# 4.3 Determining the scope of the information security management system + +The organization shall determine the boundaries and applicability of the information security management system to establish its scope. + +When determining this scope, the organization shall consider: + +a\) the external and internal issues referred to in [[ISO_27001_2022_OT 4.1 Understanding the organization and its context|4.1]]; + +b\) the requirements referred to in [[ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties|4.2]]; + +c\) interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations. + +The scope shall be available as documented information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.4 Information security management system.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.4 Information security management system.md new file mode 100644 index 0000000..18df68a --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 4.4 Information security management system.md @@ -0,0 +1,4 @@ +#iso27001/2022/EN +# 4.4 Information security management system + +The organization shall establish, implement, maintain and continually improve an information security management system, including the processes needed and their interactions, in accordance with the requirements of this document. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 5.1 Leadership and commitment.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 5.1 Leadership and commitment.md new file mode 100644 index 0000000..7cb915e --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 5.1 Leadership and commitment.md @@ -0,0 +1,22 @@ +#iso27001/2022/EN +## 5.1 Leadership and commitment + +Top management shall demonstrate leadership and commitment with respect to the information security management system by: + +a\) ensuring the information security policy and the information security objectives are established and are compatible with the strategic direction of the organization; + +b\) ensuring the integration of the information security management system requirements into the organization's processes; + +c\) ensuring that the resources needed for the information security management system are available; + +d\) communicating the importance of effective information security management and of conforming to the information security management system requirements; + +e\) ensuring that the information security management system achieves its intended outcome(s); + +f\) directing and supporting persons to contribute to the effectiveness of the information security management system; + +g\) promoting continual improvement; and + +h\) supporting other relevant management roles to demonstrate their leadership as it applies to their areas of responsibility. + +NOTE Reference to "business" in this document can be interpreted broadly to mean those activities that are core to the purposes of the organization's existence. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 5.2 Policy.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 5.2 Policy.md new file mode 100644 index 0000000..e8bcc7a --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 5.2 Policy.md @@ -0,0 +1,18 @@ +#iso27001/2022/EN +## 5.2 Policy + +Top management shall establish an information security policy that: + +a\) is appropriate to the purpose of the organization; + +b\) includes information security objectives (see [[ISO_27001_OT 6.2 Information security objectives and planning to achieve them|6.2]]) or provides the framework for setting information security objectives; + +c\) includes a commitment to satisfy applicable requirements related to information security; + +d\) includes a commitment to continual improvement of the information security management system. The information security policy shall: + +e\) be available as documented information; + +f\) be communicated within the organization; + +g\) be available to interested parties, as appropriate. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 5.3 Organizational roles, responsibilities and authorities.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 5.3 Organizational roles, responsibilities and authorities.md new file mode 100644 index 0000000..0c02608 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT 5.3 Organizational roles, responsibilities and authorities.md @@ -0,0 +1,12 @@ +#iso27001/2022/EN +## 5.3 Organizational roles, responsibilities and authorities + +Top management shall ensure that the responsibilities and authorities for roles relevant to information security are assigned and communicated within the organization. + +Top management shall assign the responsibility and authority for: + +a\) ensuring that the information security management system conforms to the requirements of this document; + +b\) reporting on the performance of the information security management system to top management. + +NOTE Top management can also assign responsibilities and authorities for reporting performance of the information security management system within the organization. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 10.1 Continual improvement.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 10.1 Continual improvement.md new file mode 100644 index 0000000..8dd354d --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 10.1 Continual improvement.md @@ -0,0 +1,4 @@ +#iso27001/2022/EN +## 10.1 Continual improvement + +The organization shall continually improve the suitability, adequacy and effectiveness of the information security management system. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 10.2 Nonconformity and corrective action.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 10.2 Nonconformity and corrective action.md new file mode 100644 index 0000000..3f82d30 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 10.2 Nonconformity and corrective action.md @@ -0,0 +1,29 @@ +#iso27001/2022/EN + + +## 10.2 Nonconformity and corrective action + +When a nonconformity occurs, the organization shall: + +a\) react to the nonconformity, and as applicable: + 1\) take action to control and correct it; + 2\) deal with the consequences; + +b\) evaluate the need for action to eliminate the causes of nonconformity, in order that it does not recur or occur elsewhere, by: + 1\) reviewing the nonconformity; + 2\) determining the causes of the nonconformity; and + 3\) determining if similar nonconformities exist, or could potentially occur; + +c\) implement any action needed; + +d\) review the effectiveness of any corrective action taken; and + +e\) make changes to the information security management system, if necessary. + +Corrective actions shall be appropriate to the effects of the nonconformities encountered. + +Documented information shall be available as evidence of: + +f\) the nature of the nonconformities and any subsequent actions taken, + +g\) the results of any corrective action. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.1.1 General.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.1.1 General.md new file mode 100644 index 0000000..f0456d3 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.1.1 General.md @@ -0,0 +1,18 @@ +### 6.1.1 General + +When planning for the information security management system, the organization shall consider the issues referred to in [[ISO_27001_2022_OT 4.1 Understanding the organization and its context|4.1]] and the requirements referred to in [[ISO_27001_2022_OT 4.2 Understanding the needs and expectations of interested parties|4.2]] and determine the risks and opportunities that need to be addressed to: + +a\) ensure the information security management system can achieve its intended outcome(s); + +b\) prevent, or reduce, undesired effects; + +c\) achieve continual improvement. + +The organization shall plan: + +d\) actions to address these risks and opportunities; and + +e\) how to + 1\) integrate and implement the actions into its information security management system processes; and + 2\) evaluate the effectiveness of these actions. + diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.1.2 Information security risk assessment.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.1.2 Information security risk assessment.md new file mode 100644 index 0000000..6dae621 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.1.2 Information security risk assessment.md @@ -0,0 +1,24 @@ +### 6.1.2 Information security risk assessment + +The organization shall define and apply an information security risk assessment process that: + +a\) establishes and maintains information security risk criteria that include: + 1\) the risk acceptance criteria; and + 2\) criteria for performing information security risk assessments; + +b\) ensures that repeated information security risk assessments produce consistent, valid and comparable results; + +c\) identifies the information security risks: + 1\) apply the information security risk assessment process to identify risks associated with the loss of confidentiality, integrity and availability for information within the scope of the information security management system; and + 2\) identify the risk owners; + +d\) analyses the information security risks: + 1\) assess the potential consequences that would result if the risks identified in 6.1.2 c)1) were to materialize; + 2\) assess the realistic likelihood of the occurrence of the risks identified in 6.1.2 c)1) ; and + 3\) determine the levels of risk; + +e\) evaluates the information security risks: + 1\) compare the results of risk analysis with the risk criteria established in 6.1.2 a); and + 2\) prioritize the analysed risks for risk treatment. + +The organization shall retain documented information about the information security risk assessment process. diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.1.3 Information security risk treatment.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.1.3 Information security risk treatment.md new file mode 100644 index 0000000..3d2b38e --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.1.3 Information security risk treatment.md @@ -0,0 +1,29 @@ +### 6.1.3 Information security risk treatment + +The organization shall define and apply an information security risk treatment process to: + +a\) select appropriate information security risk treatment options, taking account of the risk assessment results; + +b) determine all controls that are necessary to implement the information security risk treatment option(s) chosen; + +c\) compare the controls determined in 6.1.3b above with those in [Annex A] and verify that no necessary controls have been omitted; + +NOTE 1 Organizations can design controls as required, or identify them from any source. + +NOTE 2 [Annex A] contains a list of possible information security controls. Users of this document are directed to [Annex A] to ensure that no necessary information security controls are overlooked. + +NOTE 3 The information security controls listed in [Annex A] are not exhaustive and additional information security controls can be included if needed. + +d\) produce a Statement of Applicability that contains: +- the necessary controls (see 6.1.3 b) and c); +- justification for their inclusion; +- whether the necessary controls are implemented or not; and +- the justification for excluding any of the [Annex A] controls. + +e\) formulate an information security risk treatment plan; and + +f\) obtain risk owners' approval of the information security risk treatment plan and acceptance of the residual information security risks. + +The organization shall retain documented information about the information security risk treatment process. + +NOTE 4 The information security risk assessment and treatment process in this document aligns with the principles and generic guidelines provided in ISO 31000. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.2 Information security objectives and planning to achieve them.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.2 Information security objectives and planning to achieve them.md new file mode 100644 index 0000000..3934666 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.2 Information security objectives and planning to achieve them.md @@ -0,0 +1,34 @@ +#iso27001/2022/EN +## 6.2 Information security objectives and planning to achieve them + +The organization shall establish information security objectives at relevant functions and levels. + +The information security objectives shall: + +a\) be consistent with the information security policy; + +b\) be measurable (if practicable); + +c\) take into account applicable information security requirements, and results from risk assessment and risk treatment; + +d\) be monitored; + +e\) be communicated; + +f\) be updated as appropriate; + +g\) be available as documented information. + +The organization shall retain documented information on the information security objectives. + +When planning how to achieve its information security objectives, the organization shall determine: + +h\) what will be done; + +i\) what resources will be required; + +j\) who will be responsible; + +k\) when it will be completed; and + +l\) how the results will be evaluated. diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.3 Planning of changes.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.3 Planning of changes.md new file mode 100644 index 0000000..07b83f1 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 6.3 Planning of changes.md @@ -0,0 +1,4 @@ +#iso27001/2022/EN +## 6.3 Planning of changes + +When the organization determines the need for changes to the information security management system, the changes shall be carried out in a planned manner. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.1 Resources.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.1 Resources.md new file mode 100644 index 0000000..840b863 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.1 Resources.md @@ -0,0 +1,4 @@ +#iso27001/2022/EN +## 7.1 Resources + +The organization shall determine and provide the resources needed for the establishment, implementation, maintenance and continual improvement of the information security management system. diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.2 Competence.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.2 Competence.md new file mode 100644 index 0000000..d674099 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.2 Competence.md @@ -0,0 +1,15 @@ +#iso27001/2022/EN + +## 7.2 Competence + +The organization shall: + +a\) determine the necessary competence of person(s) doing work under its control that affects its information security performance; + +b\) ensure that these persons are competent on the basis of appropriate education, training, or experience; + +c\) where applicable, take actions to acquire the necessary competence, and evaluate the effectiveness of the actions taken; and + +d\) retain appropriate documented information as evidence of competence. + +NOTE Applicable actions can include, for example: the provision of training to, the mentoring of, or the re-assignment of current employees; or the hiring or contracting of competent persons. diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.3 Awareness.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.3 Awareness.md new file mode 100644 index 0000000..1f7e419 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.3 Awareness.md @@ -0,0 +1,11 @@ +#iso27001/2022/EN + +## 7.3 Awareness + +Persons doing work under the organization's control shall be aware of: + +a\) the information security policy; + +b\) their contribution to the effectiveness of the information security management system, including the benefits of improved information security performance; and + +c\) the implications of not conforming with the information security management system requirements. diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.4 Communication.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.4 Communication.md new file mode 100644 index 0000000..4bb908d --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.4 Communication.md @@ -0,0 +1,13 @@ +#iso27001/2022/EN + +## 7.4 Communication + +The organization shall determine the need for internal and external communications relevant to the information security management system including: + +a\) on what to communicate; + +b\) when to communicate; + +c\) with whom to communicate; + +d\) how to communicate. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.5 Documented information.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.5 Documented information.md new file mode 100644 index 0000000..bf511be --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 7.5 Documented information.md @@ -0,0 +1,47 @@ +#iso27001/2022/EN +## 7.5 Documented information + +### 7.5.1 General + +The organization's information security management system shall include: + +a\) documented information required by this document; and + +b\) documented information determined by the organization as being necessary for the effectiveness of the information security management system. + +NOTE The extent of documented information for an information security management system can differ from one organization to another due to: + 1\) the size of organization and its type of activities, processes, products and services; + 2\) the complexity of processes and their interactions; and + 3\) the competence of persons. + +### 7.5.2 Creating and updating + +When creating and updating documented information the organization shall ensure appropriate: + +a\) identification and description (e.g. a title, date, author, or reference number); + +b\) format (e.g. language, software version, graphics) and media (e.g. paper, electronic); and + +c\) review and approval for suitability and adequacy. + +### 7.5.3 Control of documented information + +Documented information required by the information security management system and by this document shall be controlled to ensure: + +a\) it is available and suitable for use, where and when it is needed; and + +b\) it is adequately protected (e.g. from loss of confidentiality, improper use, or loss of integrity). + +For the control of documented information, the organization shall address the following activities, as applicable: + +c\) distribution, access, retrieval and use; + +d\) storage and preservation, including the preservation of legibility; + +e\) control of changes (e.g. version control); and + +f\) retention and disposition. + +Documented information of external origin, determined by the organization to be necessary for the planning and operation of the information security management system, shall be identified as appropriate, and controlled. + +NOTE Access can imply a decision regarding the permission to view the documented information only, or the permission and authority to view and change the documented information, etc. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 8.1 Operational planning and control.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 8.1 Operational planning and control.md new file mode 100644 index 0000000..6793dae --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 8.1 Operational planning and control.md @@ -0,0 +1,12 @@ +#iso27001/2022/EN +## 8.1 Operational planning and control + +The organization shall plan, implement and control the processes needed to meet requirements, and to implement the actions determined in Clause 6, by: +- establishing criteria for the processes; +- implementing control of the processes in accordance with the criteria. + +Documented information shall be available to the extent necessary to have confidence that the processes have been carried out as planned. + +The organization shall control planned changes and review the consequences of unintended changes, taking action to mitigate any adverse effects, as necessary. + +The organization shall ensure that externally provided processes, products or services that are relevant to the information security management system are controlled. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 8.2 Information security risk assessment.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 8.2 Information security risk assessment.md new file mode 100644 index 0000000..c680dce --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 8.2 Information security risk assessment.md @@ -0,0 +1,6 @@ +#iso27001/2022/EN +# Clause 8.2: Information security risk assessment + +The organization shall perform information security risk assessments at planned intervals or when significant changes are proposed or occur, taking account of the criteria established in [[ISO_27001_OT 6.1.2 Information security risk assessment|6.1.2a]]. + +The organization shall retain documented information of the results of the information security risk assessments. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 8.3 Information security risk treatment.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 8.3 Information security risk treatment.md new file mode 100644 index 0000000..c0b1739 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 8.3 Information security risk treatment.md @@ -0,0 +1,9 @@ +--- +tags: + - iso27001/2022/EN +--- +# Clause 8.3 Information security risk treatment + +The organization shall implement the information security risk treatment plan. + +The organization shall retain documented information of the results of the information security risk treatment. diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 9.1 Monitoring, measurement, analysis and evaluation.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 9.1 Monitoring, measurement, analysis and evaluation.md new file mode 100644 index 0000000..5c743e5 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 9.1 Monitoring, measurement, analysis and evaluation.md @@ -0,0 +1,20 @@ +#iso27001/2022/EN +## 9.1 Monitoring, measurement, analysis and evaluation + +The organization shall determine: + +a\) what needs to be monitored and measured, including information security processes and controls; + +b\) the methods for monitoring, measurement, analysis and evaluation, as applicable, to ensure valid results. The methods selected should produce comparable and reproducible results to be considered valid; + +c\) when the monitoring and measuring shall be performed; + +d\) who shall monitor and measure; + +e\) when the results from monitoring and measurement shall be analysed and evaluated; + +f\) who shall analyse and evaluate these results. + +Documented information shall be available as evidence of the results. + +The organization shall evaluate the information security performance and the effectiveness of the information security management system. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 9.2 Internal audit.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 9.2 Internal audit.md new file mode 100644 index 0000000..ca63f44 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 9.2 Internal audit.md @@ -0,0 +1,28 @@ +#iso27001/2022/EN +## 9.2 Internal audit + +### 9.2.1 General + +The organization shall conduct internal audits at planned intervals to provide information on whether the information security management system: + +a\) conforms to + 1\) the organization's own requirements for its information security management system; + 2\) the requirements of this document; + +b\) is effectively implemented and maintained. + +### 9.2.2 Internal audit programme + +The organization shall plan, establish, implement and maintain an audit programme(s), including the frequency, methods, responsibilities, planning requirements and reporting. + +When establishing the internal audit programme(s), the organization shall consider the importance of the processes concerned and the results of previous audits. + +The organization shall: + +a\) define the audit criteria and scope for each audit; + +b\) select auditors and conduct audits that ensure objectivity and the impartiality of the audit process; + +c\) ensure that the results of the audits are reported to relevant management; + +Documented information shall be available as evidence of the implementation of the audit programme(s) and the audit results. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 9.3 Management review.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 9.3 Management review.md new file mode 100644 index 0000000..de57def --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT 9.3 Management review.md @@ -0,0 +1,34 @@ +#iso27001/2022/EN + +## 9.3 Management review +### 9.3.1 General + +Top management shall review the organization\'s information security management system at planned intervals to ensure its continuing suitability, adequacy and effectiveness. + +### 9.3.2 Management review inputs + +The management review shall include consideration of: + +a\) the status of actions from previous management reviews; + +b\) changes in external and internal issues that are relevant to the information security management system; + +c\) changes in needs and expectations of interested parties that are relevant to the information security management system; + +d\) feedback on the information security performance, including trends in: + 1\) nonconformities and corrective actions; + 2\) monitoring and measurement results; + 3\) audit results; + 4\) fulfilment of information security objectives; + +e\) feedback from interested parties; + +f\) results of risk assessment and status of risk treatment plan; + +g\) opportunities for continual improvement. + +### 9.3.3 Management review results + +The results of the management review shall include decisions related to continual improvement opportunities and any needs for changes to the information security management system. + +Documented information shall be available as evidence of the results of management reviews. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT F Foreword.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT F Foreword.md new file mode 100644 index 0000000..3415d87 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT F Foreword.md @@ -0,0 +1,22 @@ +#iso27001/2022/EN + +# Foreword + +ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. + +The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see [www.iso.org/directives] or [www.iec.ch/members_experts/refdocs]). + +Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see [www.iso.org/patents]) or the IEC list of patent declarations received (see [https://patents.iec.ch]). + +Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement. + +For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see [[www.iso.org/iso/foreword.html]](https://www.iso.org/iso/foreword.html). In the IEC, see [www.iec.ch/understanding-standards]. + +This document was prepared by Joint Technical Committee ISO/IEC JTC 1, *Information Technology*, Subcommittee SC 27, *Information security, cybersecurity and privacy protection*. + +This third edition cancels and replaces the second edition (ISO/IEC 27001:2013), which has been technically revised. It also incorporates the Technical Corrigenda ISO/IEC 27001:2013/Cor 1:2014 and ISO/IEC 27001:2013/Cor 2:2015. + +The main changes are as follows: +- the text has been aligned with the harmonized structure for management system standards and ISO/IEC 27002:2022. + +Any feedback or questions on this document should be directed to the user's national standards body. A complete listing of these bodies can be found at [www.iso.org/members.html] and [[www.iec.ch/national-committees]](https://www.iec.ch/national-committees). diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT Terms and definitions.md b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT Terms and definitions.md new file mode 100644 index 0000000..7f5c32a --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT Terms and definitions.md @@ -0,0 +1,8 @@ +#iso27001/2022/EN + +# 3 Terms and definitions + +For the purposes of this document, the terms and definitions given in +ISO/IEC 27000 apply. + +[[ISO 27000 MoC]] \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO 27001 2023 ISMS op hoofdlijnen.md b/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO 27001 2023 ISMS op hoofdlijnen.md new file mode 100644 index 0000000..3a7aad5 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO 27001 2023 ISMS op hoofdlijnen.md @@ -0,0 +1,223 @@ +#iso27001/2023/NL + +# ISMS op hoofdlijnen + +Een informatiebeveiligingsbeleid moet de hieronder genoemde punten adresseren. + +_De nummering verwijst naar de hoofdstukken/paragrafen uit ISO 27001:2023_ + +**H4              Context van de organisatie** + +H4.1         Relevante punten (intern en extern) die invloed kunnen hebben op het kunnen behalen van de doelstellingen m.b.t. informatiebeveiliging + +Voorwaarde: formuleren doelstellingen m.b.t. informatiebeveiliging + +H4.2         Relevante stakeholders en hun eisen, en welke hiervan geadresseerd zullen worden (binnen het domein informatiebeveiliging) + +H4.3         Begrenzing en toepasselijkheid van het managementsysteem voor informatiebeveiliging, rekening houdend met H4.1, H4.2 en de raakvlakken met en afhankelijkheden van andere organisaties. + +H4.4         Er moet een managementsysteem voor informatiebeveiliging worden ingericht, geïmplementeerd, onderhouden en verbeterd worden incl. benodigde processen. + +**H5              Leiderschap** + +H5.1         Het topmanagement moet leiderschap en betrokkenheid tonen door: + +a)         doelen en beleid voor informatiebeveiliging vast te stellen, dat compatibel is met de strategische richting van de organisatie +Voorwaarde: strategie moet bekend zijn +b)        integratie van het informatiebeveiligingsmanagement in de processen van de organisatie +c)         beschikbaar stellen benodigde middelen +d)        communiceren van het belang en noodzaak van informatiebeveiligingsmanagement en de daaruit volgende eisen +e)         zorgen dat de doelstellingen/resultaten behaald worden +f)           mensen aansturen en ondersteunen om hun bijdrage te leveren +g)         bevorderen van continue verbetering +h)        ondersteunen van anderen bij de invulling van hun leiderschap + +H.5.2        Het topmanagement moet een informatiebeveiligingsbeleid vaststellen dat: + +a)         passend is voor het doel van de organisatie +b)        doelstellingen bevat, of een kader om die vast te stellen (zie 6.2) +c)         zich committeren aan het voldoen aan de gedefinieerde eisen +d)        zich committeren aan continue verbetering +e)         het beleid moet beschikbaar zijn +f)          het beleid moet gecommuniceerd worden +g)         het beleid moet beschikbaar zijn voor belanghebbenden + +H5.3         Het topmanagement moet rollen, verantwoordelijkheden en bevoegdheden toekennen en communiceren, om: + +a)         het managementsysteem voor informatiebeveiliging te laten voldoen aan de vastgestelde eisen (i.e. ISO 27001) +b)        te rapporteren over de prestaties van het managementsysteem voor informatiebeveiliging aan het topmanagement + +**H6                  Planning** + +_H6.1             Risico’s en kansen_ + +H6.1.1        Risico’s en kansen moeten vastgesteld en geadresseerd worden (met overweging van de issues en eisen uit 4.1 en 4.2), om: + +a)           te zorgen dat de beoogde resultaten behaald worden (zie H51a en H5.2b) +b)           ongewenste effecten te voorkomen of te verminderen; +c)            continue verbetering te bereiken. + +Acties om die risico’s en kansen op te pakken moeten: + +d)           gepland worden +e)            volgens een beschreven proces worden geïntegreerd, geïmplementeerd, en geëvalueerd (op doeltreffendheid) + +H6.1.2        Er moet een procedure voor risicobeoordeling zijn die: + +a)        criteria voor risicoacceptatie en het uitvoeren van risicobeoordelingen bevat +b)        herhaalbaar is (consistent) +c)         risico’s voor vertrouwelijkheid, integriteit en beschikbaarheid identificeert en risico-eigenaren aanwijst +d)        van risico’s de impact, waarschijnlijkheid en risicoscore (R = P x I) beoordeelt +e)         de risico’s evalueert t.o.v. de criteria (a) en een prioriteit toekent. + +H6.1.3        Er moet een procedure zijn voor risicobehandeling om: + +a)        passende opties voor behandeling te benoemen, o.b.v. de risicobeoordeling +b)        de nodige maatregelen vast te stellen +c)         de vastgestelde maatregelen te vergelijken met de maatregelen in ISO 27001 Annex A. +d)        een _verklaring van toepasselijkheid_ op te stellen met de maatregelen uit b), de rechtvaardiging daarvan, en of deze maatregelen geïmplementeerd zijn, en een rechtvaardigen voor het niet toepassen van specifieke maatregelen uit Annex A. +e)         een plan op te stellen voor de behandeling van risico’s +f)           de goedkeuring te krijgen van de risico-eigenaren voor die behandeling en de acceptatie van de restrisico’s. + +_H6.2             Doelstellingen en planning (aanpak)_ + +Per functie en niveau moeten doelstellingen vastgesteld worden, die consistent en meetbaar zijn, en rekening houden met gestelde eisen en de resultaten van de risicobeoordeling en -behandeling. + +De doelstellingen moeten worden gemonitord, gecommuniceerd, geactualiseerd, en gedocumenteerd. + +De planningen moeten beschrijven wat er zal worden gedaan, welke middelen nodig zijn, wie verantwoordelijk is, wanneer het voltooid zal zijn, en hoe de resultaten worden geëvalueerd. + +H8 behandelt de uitvoering van deze planningen. + +_H6.3             Wijzigingen_ + +Wijzigingen in het managementsysteem moeten volgens een beschreven werkwijze worden doorgevoerd. + +**H7                  Ondersteuning** + +Vaststellen welke middelen nodig zijn voor het managementsysteem voor informatiebeveiliging, en deze beschikbaar stellen. Dit betreft de volledige cyclus van inrichten, implementeren, onderhouden en continu verbeteren. + +_H7.2             Competenties_ + +-          Vaststellen van de benodigde competenties van relevante personen +-          Zorgen dat deze personen competent zijn of worden +-          De doeltreffendheid van ondernomen acties hiervoor evalueren +-          Bewijzen van competenties bewaren. + +_H7.3             Bewustzijn_ + +Medewerkers (en ingehuurd personeel) moeten zich bewust zijn van het informatiebeveiligingsbeleid, hun bijdrage aan de doeltreffendheid daarvan en de voordelen die dat oplevert, en de gevolgen van het niet voldoen aan de gestelde eisen. + +_H7.4             Communicatie_ + +Vaststellen van de relevante interne en externe communicatie, met onderwerpen, momenten, doelgroepen en medium. + +_H7.5             Documentatie_ + +Het managementsysteem moet alle documentatie bevatten die vereist is vanuit normen, wet- en regelgeving, plus wat de organisatie zelf nodig vindt voor de doeltreffendheid van het managementsysteem (H7.5.1). + +Dit mag in verhouding zijn tot de omvang van de organisatie, de complexiteit van de processen, en de competentie van de mensen. + +Voor het creëren en actualiseren moet gezorgd worden voor (H7.5.2): + +a)        identificatie en beschrijving (bijv. een titel, datum, auteur of referentienummer); +b)        format (bijv. taal, softwareversie, afbeeldingen) en media (bijv. papier, elektronisch); en +c)         beoordeling en goedkeuring van geschiktheid en toereikendheid. + +De documentatie moet beheerd worden zodat (H7.5.3) ze beschikbaar is waar en wanneer dat nodig is, en afdoende beveiligd is. + +Dit moet ingevuld worden met activiteiten voor: +-          distributie, vindbaarheid en toegangsverlening +-          opslag en behoud van leesbaarheid +-          wijzigings- en versiebeheer +-          bewaring en vernietiging + +**H8                  Uitvoering** + +_H8.1             Operationele planning en beheersing_ + +Er moeten processen geïmplementeerd worden om te voldoen aan vastgestelde eisen, en de in H6 vastgestelde acties uit te voeren. + +Er moet voldoende documentatie zijn om vast te stellen dat die processen volgens plan zijn uitgevoerd. + +Wijzigingen in die processen moeten planmatig worden uitgevoerd, en de consequenties van onbedoelde wijzigingen (uitzonderingen) moeten beoordeeld worden. Als het nodig is, moeten er maatregelen komen om nadelige effecten tegen te gaan. + +Er moeten ook processen zijn voor de beheersing van informatiebeveiliging van extern geleverde processen, producten of diensten. + +_H8.2             Risicobeoordelingen_ moeten regelmatig worden uitgevoerd, èn bij belangrijke (interne of externe) veranderingen (volgens de criteria uit H6.1.2a). De resultaten moeten gedocumenteerd worden. + +_H8.3_             Vervolgens moet het _Risicobehandelingsplan_ (uit H6.1.3e) geimplementeerd worden. De resultaten moeten gedocumenteerd worden. + +**H9                  Evaluatie** + +_H9.1             Monitoren, meten, analyseren en evalueren_ + +De organisatie moet vaststellen wat er gemonitord en gemeten moet worden, hoe dat moet gebeuren (reproduceerbaar en vergelijkbaar), wanneer en door wie dat moet gebeuren, en wanneer en door wie de resultaten worden geanalyseerd en geëvalueerd. + +Dit geldt voor de informatiebeveiligingsmaatregelen, en het managementsysteem zelf. + +_H9.2             Interne audit_ + +De organisatie moet met geplande tussenpozen interne audits uitvoeren op het managementsysteem voor informatiebeveiliging: + +-          voldoet het aan de eigen eisen? + +-          voldoet het aan de norm? + +-          is het doeltreffend geïmplementeerd en onderhouden? + +Hiervoor moet een auditprogramma worden vastgesteld, inclusief frequentie, methoden, verantwoordelijkheden en rapportage. Resultaten van eerdere audits moeten worden meegenomen. + +Audits moeten voldoen aan gestelde criteria en hebben een bepaalde rijkwijdte. Ze moeten objectief worden uitgevoerd. De resultaten moeten aan het relevante management gerapporteerd worden. + +_H9.3             Management review_ + +Het managementsysteem moet met geplande tussenpozen door het topmanagement beoordeeld worden op geschiktheid, toereikendheid en doeltreffendheid. + +Als input dienen: + +a)        status van acties uit eerdere reviews +b)        wijzigingen in relevante issues (H4.1) +c)         wijzigingen in de behoeften en verwachtingen van de belanghebbenden (H4.2) +d)        feedback over de prestaties van de informatiebeveiliging, incl. _trends_ in afwijkingen en corrigerende maatregelen, resultaten van monitoren en meten, auditresultaten, het voldoen aan doelstellingen; +e)         feedback van belanghebbenden +f)           resultaten van risicobeoordeling en de status van het risicobehandelingsplan +g)         kansen voor continue verbetering. + +Resultaten van de review zijn o.a. beslissingen voor continue verbetering en noodzakelijke wijzigingen in het managementsysteem. + +**H10              Verbetering** + +Er moet een procedure zijn voor de omgang met afwijkingen in (de uitvoering van) het managementsysteem. + +De organisatie moet: + +a)        reageren op de afwijking: maatregelen treffen om de afwijking  te beheersen, corrigeren, en gevolgen aan te pakken; +b)        bepalen of maatregelen nodig zijn om herhaling te voorkomen (door oorzaken vast te stellen en weg te nemen) +c)         de maatregelen implementeren +d)        de doeltreffendheid daarvan te beoordelen +e)         wijzigingen in het managementsysteem aan te brengen, indien nodig +f)           de aard van de afwijkingen en maatregelen documenteren +g)         de resultaten van de maatregelen documenteren. + +VOORBLAD + +Document + +Doelgroep + +Classificatie + +Versie + +Eigenaar + +INLEIDING + +Over dit document: + +-              Doelgroep + +-              Doel + +-              Gebaseerd op ISO 27001, organisatie-eigen stukken \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO 27001 2023 Processen en Artefacten.md b/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO 27001 2023 Processen en Artefacten.md new file mode 100644 index 0000000..a92b273 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO 27001 2023 Processen en Artefacten.md @@ -0,0 +1,51 @@ +#iso27001/2023/NL +## Processen + +- Processen om het ISMS zelf te onderhouden + - contextanalyse (H4) + - Risicoanalyse (H6.1), incl. Dreigingsanalyse (A5.7) + - wijzigingen aan het ISMS (H6.3) + - risicobeoordeling en -acceptatie (H6.1.2, H8.2, H8.3) + - documentatie (H7.5) + - evaluatie van het ISMS (H9) + - afwijkingen en verbeteringen (H10) + - rollen en verantwoordelijkheden m.b.t. het ISMS (H5.3) +- Processen om de gekozen maatregelen te onderhouden + - Leveranciersmanagement (H8.1) + - Informatiebeveiliging in projecten (H5.8) + - evaluatie van maatregelen (H9) + - rollen en verantwoordelijkheden m.b.t. de maatregelen (H5.3) +## Te produceren stukken +- Beschrijving relevante issues (intern en extern) (H4.1) +- SWOT-analyse (H6.1) +- Risicoanalyse (H6.1), incl. Dreigingsanalyse (A5.7) +- Stakeholder analyse (H4.2) +- Overzicht wet- en regelgeving (H4.1, H4.2) +- Vaststellen doelen informatiebeveiliging (H5.1a) +- Informatiebeveiligingsbeleid (H5.2) +- Risicoanalyse (H6.1.2) +- Lijst maatregelen (H6.1.3) + - Toegangsbeveiliging informatiesystemen (A5.15) + - Identiteitsbeheer (A5.16) + - Toegangsrechten (A5.18) + - Maatregelen m.b.t. leveranciers (A5.19-A5.23) + - Fysieke toegangsbeveiliging (A7) + - EDM (8.1) + - Backups en redundantie (A8.13, A8.14) + - Logging en Monitoring (A8.15, A8.16) + - Update procedures (A8.19) + - Netwerkbeveiliging (A8.20-A8.23) + - Systeemarchitectuur (A8.27) + - Softwareontwikkeling (A8.25, A8.28-A8.33) +- Incidentenprocedure (A5.24-A5.29) +- Bedrijfscontinuïteitsplan (A5.30) +- Licentiebeheer (A5.32) +- Privacybeleid (A5.34) +- Voorschriften gebruik apparatuur en software (5.37) +- Planning implementatie maatregelen (H8.1) +- Communicatieplan (H7.4) +- Planning van terugkerende taken (evalueren, herzien, bijwerken) +- Asset-inventarisatie (A5.9) +- Classificatie van informatie en assets (A5.12) + + diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_Aanpassingen.md b/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_Aanpassingen.md new file mode 100644 index 0000000..a320ede --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_Aanpassingen.md @@ -0,0 +1,54 @@ +#iso27001/2023/NL +# Aanpassingen in ISO 27001:2023 + +De ISO 27001:2022 is aangepast op de nieuwe HS (Harmonized Structure). Deze wijzigingen zorgen voor een betere aansluiting bij Annex SL. + +Diverse punten in de hoofdstukken 4 t/m 10 zijn aangescherpt, toegevoegd, herschreven of gesplitst. Dit zijn de wijzigingen: + +## Aanpassingen in het ISMS +- 4.1 Context is aangescherpt +- 4.2 Belanghebbenden is aangescherpt +- 4.4 ISMS is aangescherpt +- 6.1.3 Risicobehandeling is aangescherpt +- 6.2 Doelstellingen is aangescherpt +- 6.3 Verandermanagement is toegevoegd +- 8.1 Operationele planning is herschreven +- 9.1 Monitoring is aangescherpt +- 9.2 Algemeen en Auditprogramma is gesplitst +- 9.3 Algemeen, input en output is gesplitst +- 10.1 Verbeteren en Afwijkingen & Corrigerende maatregelen is aangepast +### Aanpassing aan nieuwe Harmonized Structure + +De ISO 27001:2022 is aangepast op de nieuwe Harmonized Structure(HS). Deze HS is in 2021 gepubliceerd en is een update van de High Level Structure(HLS). HS is de basisstructuur van alle ISO managementsysteemnormen. In [dit artikel](https://www.cuccibu.eu/nieuws/de-nieuwe-high-level-structure/) lees je meer over de inhoudelijke veranderingen van HLS naar HS. De HS heeft de volgende impact op ISO 27001:   + +- **Wijzigingen in gedocumenteerde informatie**. In de HLS werd verwezen naar verschillende werkwoorden, zoals ‘onderhouden’ voor documenten en ‘bijhouden’ voor registraties. Dit zorgde vaak voor verwarring. In de HS is gekozen voor een eenduidige terminologie. Er wordt gesproken over ‘beschikbaar zijn’ van gedocumenteerde informatie.   +- **Behoeftes en verwachtingen stakeholders belangrijker.** In paragraaf 4.2 van de HLS staat dat een organisatie de relevante eisen van relevante belanghebbende moet identificeren. Hoe een organisatie omgaat met behoeftes en verwachtingen van stakeholders blijft echter onduidelijk. In de HS worden de behoeftes en verwachtingen wel opgenomen. De organisatie moet vaststellen welke belanghebbenden relevant zijn voor het managementsysteem voor informatiebeveiliging, welke eisen deze belanghebbenden stellen én welke van deze eisen zullen worden geadresseerd in het managementsysteem voor informatiebeveiliging. De eisen van belanghebbende kunnen wettelijke en regelgevende eisen, maar ook contractuele verplichtingen omvatten.  +- **Eisen aan de processen van het ISMS.** In de voorgaande versie van ISO 27001 is in paragraaf 4.4 afgeweken van de HLS. Er werden eisen gesteld voor het vaststellen, implementeren, onderhouden en continu verbeteren van het informatiebeveiligingsmanagementsysteem (ISMS). Echter ontbraken de eisen voor en de samenhang met de onderliggende processen. In de herziene versie is deze tekortkoming hersteld en wordt er weer aangesloten bij de HS. Dit bekent meer focus op processen in de ISO 27001:2022.  +- **Plannen van wijzigingen.** In hoofdstuk 6 van de HS is een nieuwe paragraaf opgenomen, namelijk 6.3. Deze paragraaf stelt dat wijzigingen aan het managementsysteem op een geplande manier moeten worden uitgevoerd. Management of change wordt hiermee expliciet onderdeel van de HS. In ISO 27001:2022 is paragraaf 6.3 ook opgenomen. +- **Van uitbesteden naar extern geleverde processen, producten en diensten.** De begrippen ‘uitbesteden’ en ‘beheersing’ van uitbestede processen worden niet meer toegepast in de HS. Voortaan worden er eisen gesteld aan de extern geleverde processen, producten en diensten die relevant zijn voor het managementsysteem. Ook de herziene ISO 27001 norm volgt deze benadering + +## Nieuwe beheersmaatregelen in Annex A +In de oude norm ISO 27001:2013 waren 114 beheersmaatregelen opgenomen. Een flinke lijst, die in ISO 27001:2022 is ingekort. Er zijn nu 93 beheersmaatregelen. ISO besloot om veel maatregelen samen te voegen waardoor de norm past bij deze tijd. Wel voegde ISO 11 nieuwe beheersmaatregelen toe. + +- 5.7 – Informatie en analyses over dreigingen: + Informatie met betrekking tot informatiebeveiliging dreigingen moet worden verzameld en geanalyseerd om informatie over dreigingen te produceren. +- 5.23 – Informatiebeveiliging voor het gebruik van clouddiensten: + Processen voor het aanschaffen, gebruiken, beheren en beëindigen van clouddiensten behoren overeenkomstig de informatiebeveiligingseisen van de organisatie te worden opgesteld. +- 5.30 – ICT-gereedheid voor bedrijfscontinuïteit: + De ICT-gereedheid behoort te worden gepland, geïmplementeerd, onderhouden en getest op basis van bedrijfscontinuïteitsdoelstellingen en ICT-continuïteitseisen. +- 7.4 – Monitoren van de fysieke beveiliging: + Het gebouw en terrein behoren voortdurend te worden gemonitord op onbevoegde fysieke toegang. +- 8.9 – Configuratiebeheer: + Configuraties, met inbegrip van beveiligingsconfiguraties, van hardware, software, diensten en netwerken behoren te worden vastgesteld, gedocumenteerd, geïmplementeerd, gemonitord en beoordeeld. +- 8.10 – Wissen van informatie: + In informatiesystemen, apparaten of andere opslagmedia opgeslagen informatie behoort te worden gewist als deze niet langer vereist is. +- 8.11 – Maskeren van gegevens: + Gegevens behoren te worden gemaskeerd overeenkomstig het onderwerp specifieke beleid inzake toegangsbeveiliging en andere gerelateerde onderwerp specifieke beleidsregels, en bedrijfseisen van de organisatie, rekening houdend met de toepasselijke wetgeving. +- 8.12 – Voorkomen van gegevenslekken: + Maatregelen om gegevenslekken te voorkomen behoren te worden toegepast in systemen, netwerken en andere apparaten waarop of waarmee gevoelige informatie wordt verwerkt, opgeslagen of getransporteerd. +- 8.16 – Monitoren van activiteiten: + Netwerken, systemen en toepassingen behoren te worden gemonitord op afwijkend gedrag en er behoren passende maatregelen te worden getroffen om potentiële informatiebeveiligingsincidenten te evalueren. +- 8.23 – Toepassen van webfilters: + De toegang tot externe websites behoort te worden beheerd om de blootstelling aan kwaadaardige inhoud te beperken. +- 8.28 – Veilig coderen: + Er behoren principes voor veilig coderen te worden toegepast op softwareontwikkeling. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_BT 3 Termen en definities.md b/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_BT 3 Termen en definities.md new file mode 100644 index 0000000..d15f984 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_BT 3 Termen en definities.md @@ -0,0 +1,2 @@ +#iso27001/2023/NL + diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_Index.md b/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_Index.md new file mode 100644 index 0000000..34d10ee --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_Index.md @@ -0,0 +1,40 @@ +#iso27001/2023/NL +Publicatiedatum: augustus 2023 + + +| 2023 ID | Onderwerp | Brontekst | Normaal | +| :------ | :------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | +| **0** | **Inleiding** | [[ISO_27001_2023_NL_BT 0 Inzicht in de organisatie en haar context \|BT]] | [[ISO_27001_2023_NL_NN 0 Inzicht in de organisatie en haar context \|NN]] | +| **1** | **Onderwerp en toepassingsgebied** | [[ISO_27001_2023_NL_BT 1 Onderwerp en toepassingsgebied \|BT]] | [[ISO_27001_2023_NL_NN 1 Onderwerp en toepassingsgebied \|NN]] | +| **2** | **Normatieve verwijzingen** | [[ISO_27001_2023_NL_BT 2 Normatieve verwijzingen \|BT]] | [[ISO_27001_2023_NL_NN 2 Normatieve verwijzingen \|NN]] | +| **3** | **Termen en definities** | [[ISO_27001_2023_NL_BT 3 Termen en definities \|BT]] | [[ISO_27001_2023_NL_NN 3 Termen en definities \|NN]] | +| **4** | **Context van de organisatie** | | | +| 4.1 | Inzicht in de organisatie en haar context | [[ISO_27001_2023_NL_BT 4.1 Inzicht in de organisatie en haar context \|BT]] | [[ISO_27001_2023_NL_NN 4.1 Inzicht in de organisatie en haar context \|NN]] | +| 4.2 | Inzicht in de behoeften en verwachtingen van belanghebbenden | [[ISO_27001_2023_NL_BT 4.2 Inzicht in de behoeften en verwachtingen van belanghebbenden \|BT]] | [[ISO_27001_2023_NL_NN 4.2 Inzicht in de behoeften en verwachtingen van belanghebbenden \|NN]] | +| 4.3 | Het toepassingsgebied van het managementsysteem voor informatiebeveiliging | [[ISO_27001_2023_NL_BT 4.3 Het toepassingsgebied van het managementsysteem voor informatiebeveiliging \|BT]] | [[ISO_27001_2023_NL_NN 4.3 Het toepassingsgebied van het managementsysteem voor informatiebeveiliging \|NN]] | +| 4.4 | Managementsysteem voor informatiebeveiliging | [[ISO_27001_2023_NL_BT 4.4 Managementsysteem voor informatiebeveiliging \|BT]] | [[ISO_27001_2023_NL_NN 4.4 Managementsysteem voor informatiebeveiliging \|NN]] | +| **5** | **Leiderschap** | | | +| 5.1 | Leiderschap en betrokkenheid | [[ISO_27001_2023_NL_BT 5.1 Leiderschap en betrokkenheid \|BT]] | [[ISO_27001_2023_NL_NN 5.1 Leiderschap en betrokkenheid \|NN]] | +| 5.2 | Beleid | [[ISO_27001_2023_NL_BT 5.2 Beleid \|BT]] | [[ISO_27001_2023_NL_NN 5.2 Beleid \|NN]] | +| 5.3 | Rollen, verantwoordelijkheden en bevoegdheden binnen de organisatie | [[ISO_27001_2023_NL_BT 5.3 Rollen, verantwoordelijkheden en bevoegdheden binnen de organisatie \|BT]] | [[ISO_27001_2023_NL_NN 5.3 Rollen, verantwoordelijkheden en bevoegdheden binnen de organisatie \|NN]] | +| **6** | **Planning** | | | +| 6.1 | Acties om risico's en kansen op te pakken | [[ISO_27001_2023_NL_BT 6.1 Acties om risico's en kansen op te pakken \|BT]] | [[ISO_27001_2023_NL_NN 6.1 Acties om risico's en kansen op te pakken \|NN]] | +| 6.2 | Informatiebeveiligingsdoelstellingen en de planning om ze te bereiken | [[ISO_27001_2023_NL_BT 6.2 Informatiebeveiligings[doelstellingen en de planning om ze te bereiken \|BT]] | [[ISO_27001_2023_NL_NN 6.2 Informatiebeveiligings[doelstellingen en de planning om ze te bereiken \|NN]] | +| 6.3 | Planning van wijzigingen | [[ISO_27001_2023_NL_BT 6.3 Planning van wijzigingen \|BT]] | [[ISO_27001_2023_NL_NN 6.3 Planning van wijzigingen \|NN]] | +| **7** | **Ondersteuning** | | | +| 7.1 | Middelen | [[ISO_27001_2023_NL_BT 7.1 Middelen \|BT]] | [[ISO_27001_2023_NL_NN N.N 7.1 Middelen \|NN]] | +| 7.2 | Competentie | [[ISO_27001_2023_NL_BT 7.2 Competentie \|BT]] | [[ISO_27001_2023_NL_NN N.N 7.2 Competentie \|NN]] | +| 7.3 | Bewustzijn | [[ISO_27001_2023_NL_BT 7.3 Bewustzijn \|BT]] | [[ISO_27001_2023_NL_NN N.N 7.3 Bewustzijn \|NN]] | +| 7.4 | Communicatie | [[ISO_27001_2023_NL_BT 7.4 Communicatie \|BT]] | [[ISO_27001_2023_NL_NN N.N 7.4 Communicatie \|NN]] | +| 7.5 | Gedocumenteerde informatie | [[ISO_27001_2023_NL_BT 7.5 Gedocumenteerde informatie \|BT]] | [[ISO_27001_2023_NL_NN N.N 7.5 Gedocumenteerde informatie \|NN]] | +| **8** | **Uitvoering** | | | +| 8.1 | Operationele planning en beheersing | [[ISO_27001_2023_NL_BT 8.1 Operationele planning en beheersing \|BT]] | [[ISO_27001_2023_NL_NN 8.1 Operationele planning en beheersing \|NN]] | +| 8.2 | Risicobeoordeling van informatiebeveiliging | [[ISO_27001_2023_NL_BT 8.2 Risicobeoordeling van informatiebeveiliging \|BT]] | [[ISO_27001_2023_NL_NN 8.2 Risicobeoordeling van informatiebeveiliging \|NN]] | +| 8.3 | Informatiebeveiligingsrisico's behandelen | [[ISO_27001_2023_NL_BT 8.3 Informatiebeveiligingsrisico's behandelen \|BT]] | [[ISO_27001_2023_NL_NN 8.3 Informatiebeveiligingsrisico's behandelen \|NN]] | +| **9** | **Evaluatie van de prestaties** | | | +| 9.1 | Monitoren, meten, analyseren en evalueren | [[ISO_27001_2023_NL_BT 9.1 Monitoren, meten, analyseren en evalueren \|BT]] | [[ISO_27001_2023_NL_NN N.N 9.1 Monitoren, meten, analyseren en evalueren \|NN]] | +| 9.2 | Interne audit | [[ISO_27001_2023_NL_BT 9.2 Interne audit \|BT]] | [[ISO_27001_2023_NL_NN N.N 9.2 Interne audit \|NN]] | +| 9.3 | Management review | [[ISO_27001_2023_NL_BT 9.3 Management review \|BT]] | [[ISO_27001_2023_NL_NN N.N 9.3 Management review \|NN]] | +| **10** | **Verbetering** | | | +| 10.1 | Continue verbetering | [[ISO_27001_2023_NL_BT 10.1 Continue verbetering \|BT]] | [[ISO_27001_2023_NL_NN N.N 10.1 Continue verbetering \|NN]] | +| 10.2 | Afwijkingen en corrigerende maatregelen | [[ISO_27001_2023_NL_BT 10.1 Afwijkingen en corrigerende maatregelen \|BT]] | [[ISO_27001_2023_NL_NN N.N 10.1 Afwijkingen en corrigerende maatregelen \|NN]] | \ No newline at end of file diff --git a/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_PDF.md b/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_PDF.md new file mode 100644 index 0000000..2bede09 --- /dev/null +++ b/Corpus/Standards/ISO-27001-OST/ISO27001-NL-2023/ISO_27001_2023_NL_PDF.md @@ -0,0 +1,6 @@ +#iso27001/2023/NL +# ISO 27001 2023 NL + +![[ISO_IEC_27001_2023_NL.pdf]] + + diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.10_OT Acceptable use of information and other associated assets.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.10_OT Acceptable use of information and other associated assets.md new file mode 100644 index 0000000..2b59e99 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.10_OT Acceptable use of information and other associated assets.md @@ -0,0 +1,39 @@ +## 5.10 Acceptable use of information and other associated assets + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ----------------------------------------- | ------------------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management #Information_protection | #Governance_and_Ecosystem #Protection | + +**Control** +Rules for the acceptable use and procedures for handling information and other associated assets should be identified, documented and implemented. + +**Purpose** +To ensure information and other associated assets are appropriately protected, used and handled. + +**Guidance** +Personnel and external party users using or having access to the organization’s information and other associated assets should be made aware of the information security requirements for protecting and handling the organization’s information and other associated assets. They should be responsible for their use of any information processing facilities. + +The organization should establish a topic-specific policy on the acceptable use of information and other associated assets and communicate it to anyone who uses or handles information and other associated assets. The topic-specific policy on acceptable use should provide clear direction on how individuals are expected to use information and other associated assets. The topic-specific policy should state: + +a\) expected and unacceptable behaviours of individuals from an information security perspective; + +b\) permitted and prohibited use of information and other associated assets; + +c\) monitoring activities being performed by the organization. + +Acceptable use procedures should be drawn up for the full information life cycle in accordance with its classification (see 5.12) and determined risks. The following items should be considered: + +a\) access restrictions supporting the protection requirements for each level of classification; + +b\) maintenance of a record of the authorized users of information and other associated assets; + +c\) protection of temporary or permanent copies of information to a level consistent with the protection of the original information; + +d\) storage of assets associated with information in accordance with manufacturers’ specifications (see 7.8); + +e\) clear marking of all copies of storage media (electronic or physical) for the attention of the authorized recipient (see 7.10); + +f\) authorization of disposal of information and other associated assets and supported deletion method(s) (see 8.10). + +**Other information** +It can be the case that the assets concerned do not directly belong to the organization, such as public cloud services. The use of such third-party assets and any assets of the organization associated with such external assets (e.g. information, software) should be identified as applicable and controlled, for example, through agreements with cloud service providers. Care should also be taken when a collaborative working environment is used. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.11_OT Return of assets.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.11_OT Return of assets.md new file mode 100644 index 0000000..d972797 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.11_OT Return of assets.md @@ -0,0 +1,34 @@ +## 5.11 Return of assets + + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------ | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management | #Protection | + +**Control** +Personnel and other interested parties as appropriate should return all the organization’s assets in their possession upon change or termination of their employment, contract or agreement. + +**Purpose** +To protect the organization’s assets as part of the process of changing or terminating employment, contract or agreement. + +**Guidance** + +The change or termination process should be formalized to include the return of all previously issued physical and electronic assets owned by or entrusted to the organization. + +In cases where personnel and other interested parties purchase the organization’s equipment or use their own personal equipment, procedures should be followed to ensure that all relevant information is traced and transferred to the organization and securely deleted from the equipment (see 7.14). + +In cases where personnel and other interested parties have knowledge that is important to ongoing operations, that information should be documented and transferred to the organization. + +During the notice period and thereafter, the organization should prevent unauthorized copying of relevant information (e.g. intellectual property) by personnel under notice of termination. + +The organization should clearly identify and document all information and other associated assets to be returned which can include: + +a\) user endpoint devices; +b\) portable storage devices; +c\) specialist equipment; +d\) authentication hardware (e.g. mechanical keys, physical tokens and smartcards) for information systems, sites and physical archives; +e\) physical copies of information. + +**Other information** +It can be difficult to return information held on assets which are not owned by the organization. In such cases, it is necessary to restrict the use of information using other information security controls such as access rights management (5.18) or use of cryptography (8.24). \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.12_OT Classification of information.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.12_OT Classification of information.md new file mode 100644 index 0000000..ac9c5ca --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.12_OT Classification of information.md @@ -0,0 +1,44 @@ +#iso27002/2022/EN + +## 5.12 Classification of information + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------ | -------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Information_protection | #Protection #Defence | + +**Control** +Information should be classified according to the information security needs of the organization based on confidentiality, integrity, availability and relevant interested party requirements. + +**Purpose** +To ensure identification and understanding of protection needs of information in accordance with its importance to the organization. + +**Guidance** +The organization should establish a topic-specific policy on information classification and communicate it to all relevant interested parties. + +The organization should take into account requirements for confidentiality, integrity and availability in the classification scheme. + +Classifications and associated protective controls for information should take account of business needs for sharing or restricting information, for protecting integrity of information and for assuring availability, as well as legal requirements concerning the confidentiality, integrity or availability of the information. Assets other than information can also be classified in compliance with classification of information, which is stored in, processed by or otherwise handled or protected by the asset. + +Owners of information should be accountable for their classification. + +The classification scheme should include conventions for classification and criteria for review of the classification over time. Results of classification should be updated in accordance with changes of the value, sensitivity and criticality of information through their life cycle. + +The scheme should be aligned to the topic-specific policy on access control (see 5.1) and should be able to address specific business needs of the organization. + +The classification can be determined by the level of impact that the information's compromise would have for the organization. Each level defined in the scheme should be given a name that makes sense in the context of the classification scheme’s application. + +The scheme should be consistent across the whole organization and included in its procedures so that everyone classifies information and applicable other associated assets in the same way. In this manner, everyone has a common understanding of protection requirements and applies appropriate protection. + +The classification scheme used within the organization can be different from the schemes used by other organizations, even if the names for levels are similar. In addition, information moving between organizations can vary in classification depending on its context in each organization, even if their classification schemes are identical. Therefore, agreements with other organizations that include information sharing should include procedures to identify the classification of that information and to interpret the classification levels from other organizations. Correspondence between different schemes can be determined by looking for equivalence in the associated handling and protection methods. + +**Other information** +Classification provides people who deal with information with a concise indication of how to handle and protect it. Creating groups of information with similar protection needs and specifying information security procedures that apply to all the information in each group facilitates this. This approach reduces the need for case-by-case risk assessment and custom design of controls. + +Information can cease to be sensitive or critical after a certain period of time. For example, when the information has been made public, it no longer has confidentiality requirements but can still require protection for its integrity and availability properties. These aspects should be taken into account, as over-classification can lead to the implementation of unnecessary controls resulting in additional expense or, on the contrary, under-classification can lead to insufficient controls to protect the information from compromise. + +As an example, an information confidentiality classification scheme can be based on four levels as follows: + +a\) disclosure causes no harm; +b\) disclosure causes minor reputational damage or minor operational impact; +c\) disclosure has a significant short-term impact on operations or business objectives; +d\) disclosure has a serious impact on long term business objectives or puts the survival of the organization at risk. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.13_OT Labelling of information.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.13_OT Labelling of information.md new file mode 100644 index 0000000..343d95a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.13_OT Labelling of information.md @@ -0,0 +1,47 @@ +## 5.13 Labelling of information + + + +**Control** +An appropriate set of procedures for information labelling should be developed and implemented in accordance with the information classification scheme adopted by the organization. + +**Purpose** +To facilitate the communication of classification of information and support automation of information processing and management. + +**Guidance** +Procedures for information labelling should cover information and other associated assets in all formats. The labelling should reflect the classification scheme established in 5.12. The labels should be easily recognizable. The procedures should give guidance on where and how labels are attached in consideration of how the information is accessed or the assets are handled depending on the types of storage media. The procedures can define: + +a\) cases where labelling is omitted (e.g. labelling of non-confidential information to reduce workloads); + +b\) how to label information sent by or stored on electronic or physical means, or any other format; + +c\) how to handle cases where labelling is not possible (e.g. due to technical restrictions). Examples of labelling techniques include: + +a\) physical labels; + +b\) headers and footers; + +c\) metadata; + +d\) watermarking; + +e\) rubber-stamps. + +Digital information should utilize metadata in order to identify, manage and control information, especially with regard to confidentiality. Metadata should also enable efficient and correct searching for information. Metadata should facilitate systems to interact and make decisions based on the associated classification labels. + +The procedures should describe how to attach metadata to information, what labels to use and how data should be handled, in line with the organization’s information model and ICT architecture. + +Relevant additional metadata should be added by systems when they process information depending on its information security properties. + +Personnel and other interested parties should be made aware of labelling procedures. All personnel should be provided with the necessary training to ensure that information is correctly labelled and handled accordingly. + +Output from systems containing information that is classified as being sensitive or critical should carry an appropriate classification label. + +**Other information** +Labelling of classified information is a key requirement for information sharing. + +Other useful metadata that can be attached to the information is which organizational process created the information and at what time. + +Labelling of information and other associated assets can sometimes have negative effects. Classified assets can be easier to identify by malicious actors for potential misuse. + +Some systems do not label individual files or database records with their classification but protect all information at the highest level of classification of any of the information that it contains or is permitted to contain. It is usual in such systems to determine and then label information when it is exported. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.14_OT Information transfer.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.14_OT Information transfer.md new file mode 100644 index 0000000..5e9c309 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.14_OT Information transfer.md @@ -0,0 +1,147 @@ +## 5.14 Information transfer + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ----------------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management #Information_protection | #Protection | + +**Control** +Information transfer rules, procedures, or agreements should be in place for all types of transfer facilities within the organization and between the organization and other parties. + +**Purpose** +To maintain the security of information transferred within an organization and with any external interested party. + +**Guidance** + +General +The organization should establish and communicate a topic-specific policy on information transfer to all relevant interested parties. Rules, procedures and agreements to protect information in transit should reflect the classification of the information involved. Where information is transferred between the organization and third parties, transfer agreements (including recipient authentication) should be established and maintained to protect information in all forms in transit (see 5.10). + +Information transfer can happen through electronic transfer, physical storage media transfer and verbal transfer. + +For all types of information transfer, rules, procedures and agreements should include: + +a\) controls designed to protect transferred information from interception, unauthorized access, copying, modification, misrouting, destruction and denial of service, including levels of access control commensurate with the classification of the information involved and any special controls that are required to protect sensitive information, such as use of cryptographic techniques (see 8.24); + +b\) controls to ensure traceability and non-repudiation, including maintaining a chain of custody for information while in transit; + +c\) identification of appropriate contacts related to the transfer including information owners, risk owners, security officers and information custodians, as applicable; + +d\) responsibilities and liabilities in the event of information security incidents, such as loss of physical storage media or data; + +e\) use of an agreed labelling system for sensitive or critical information, ensuring that the meaning of the labels is immediately understood and that the information is appropriately protected (see 5.13); + +f\) reliability and availability of the transfer service; + +g\) the topic-specific policy or guidelines on acceptable use of information transfer facilities (see 5.10); + +h\) retention and disposal guidelines for all business records, including messages; + +NOTE Local legislation and regulations can exist regarding retention and disposal of business records. + +i\) the consideration of any other relevant legal, statutory, regulatory and contractual requirements (see 5.31, 5.32, 5.33, 5.34) related to transfer of information (e.g. requirements for electronic signatures). + +Electronic transfer +Rules, procedures and agreements should also consider the following items when using electronic communication facilities for information transfer: + +a\) detection of and protection against malware that can be transmitted through the use of electronic communications (see 8.7); + +b\) protection of communicated sensitive electronic information that is in the form of an attachment; + +c\) prevention against sending documents and messages in communications to the wrong address or number; + +d\) obtaining approval prior to using external public services such as instant messaging, social networking, file sharing or cloud storage; + +e\) stronger levels of authentication when transferring information via publicly accessible networks; + +f\) restrictions associated with electronic communication facilities (e.g. preventing automatic forwarding of electronic mail to external mail addresses); + +g\) advising personnel and other interested parties not to send short message service (SMS) or instant messages with critical information since these can be read in public places (and therefore by unauthorized persons) or stored in devices not adequately protected; + + + +h\) advising personnel and other interested parties about the problems of using fax machines or services, namely: + + + +1\) unauthorized access to built-in message stores to retrieve messages; + + + +2\) deliberate or accidental programming of machines to send messages to specific numbers. + + + +Physical storage media transfer + + + +When transferring physical storage media (including paper), rules, procedures and agreements should also include: + + + +a\) responsibilities for controlling and notifying transmission, dispatch and receipt; + + + +b\) ensuring correct addressing and transportation of the message; + + + +c\) packaging that protects the contents from any physical damage likely to arise during transit and in accordance with any manufacturers’ specifications, for example protecting against any environmental factors that can reduce the effectiveness of restoring storage media such as exposure to heat, moisture or electromagnetic fields; using minimum technical standards for packaging and transmission (e.g. the use of opaque envelopes); + + + +d\) a list of authorized reliable couriers agreed by management; + + + +e\) courier identification standards; + + + +f\) depending on the classification level of the information in the storage media to be transported, use tamper evident or tamper-resistant controls (e.g. bags, containers); + + + +g\) procedures to verify the identification of couriers; + + + +h\) approved list of third parties providing transportation or courier services depending on the classification of the information; + + + +i\) keeping logs for identifying the content of the storage media, the protection applied as well as recording the list of authorised recipients, the times of transfer to the transit custodians and receipt at the destination. + + + +Verbal transfer + + + +To protect verbal transfer of information, personnel and other interested parties should be reminded that they should: + + + +a\) not have confidential verbal conversations in public places or over insecure communication channels since these can be overheard by unauthorized persons; + + + +b\) not leave messages containing confidential information on answering machines or voice messages since these can be replayed by unauthorized persons, stored on communal systems or stored incorrectly as a result of misdialling; + + + +c\) be screened to the appropriate level to listen to the conversation; + + + +d\) ensure that appropriate room controls are implemented (e.g. sound-proofing, closed door); + + + +e\) begin any sensitive conversations with a disclaimer so those present know the classification level and any handling requirements of what they are about to hear. + + + +**Other information** + +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.15_OT Access control.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.15_OT Access control.md new file mode 100644 index 0000000..f698889 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.15_OT Access control.md @@ -0,0 +1,76 @@ +#iso27002/2022/EN + +## 5.15 Access control + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | + +**Control** +Rules to control physical and logical access to information and other associated assets should be established and implemented based on business and information security requirements. + +**Purpose** +To ensure authorized access and to prevent unauthorized access to information and other associated assets. + +**Guidance** +Owners of information and other associated assets should determine information security and business requirements related to access control. A topic-specific policy on access control should be defined which takes account of these requirements and should be communicated to all relevant interested parties. + +These requirements and the topic-specific policy should consider the following: + +a\) determining which entities require which type of access to the information and other associated assets; + +b\) security of applications (see 8.26); + +c\) physical access, which needs to be supported by appropriate physical entry controls (see 7.2, 7.3, 7.4); + +d\) information dissemination and authorization (e.g. the need-to-know principle) and information security levels and classification of information (see 5.10, 5.12, 5.13); + +e\) restrictions to privileged access (see 8.2); + +f\) segregation of duties (see 5.3); + +g\) relevant legislation, regulations and any contractual obligations regarding limitation of access to data or services (see 5.31, 5.32, 5.33, 5.34, 8.3); + +h\) segregation of access control functions (e.g. access request, access authorization, access administration); + +i\) formal authorization of access requests (see 5.16and 5.18); + +j\) the management of access rights (see 5.18); + +k\) logging (see 8.15). + +Access control rules should be implemented by defining and mapping appropriate access rights and restrictions to the relevant entities (see 5.16). An entity can represent a human user as well as a technical or logical item (e.g. a machine, device or a service). To simplify the access control management, specific roles can be assigned to entity groups. + +The following should be taken into account when defining and implementing access control rules: + +a\) consistency between the access rights and information classification; + +b\) consistency between the access rights and the physical perimeter security needs and requirements; + +c\) considering all types of available connections in distributed environments so entities are only provided with access to information and other associated assets, including networks and network services, that they are authorized to use; + +d\) considering how elements or factors relevant to dynamic access control can be reflected. + +**Other information** + +There are often overarching principles used in the context of access control. Two of the most frequently used principles are: + +a\) need-to-know: an entity is only granted access to the information which that entity requires in order to perform its tasks (different tasks or roles mean different need-to-know information and hence different access profiles); + +b\) need-to-use: an entity is only assigned access to information technology infrastructure where a clear need is present. + +Care should be taken when specifying access control rules to consider: + +a\) establishing rules based on the premise of least privilege, “Everything is generally forbidden unless expressly permitted”, rather than the weaker rule, “Everything is generally permitted unless expressly forbidden”; + +b\) changes in information labels (see 5.13) that are initiated automatically by information processing facilities and those initiated at the discretion of a user; + +c\) changes in user permissions that are initiated automatically by the information system and those initiated by an administrator; + +d\) when to define and regularly review the approval. + +Access control rules should be supported by documented procedures (see 5.16, 5.17, 5.18, 8.2, 8.3, 8.4, 8.5, 8.18) and defined responsibilities (see 5.2, 5.17). + +There are several ways to implement access control, such as MAC (mandatory access control), DAC (discretionary access control), RBAC (role-based access control) and ABAC (attribute-based access control). + +Access control rules can also contain dynamic elements (e.g. a function that evaluates past accesses or specific environment values). Access control rules can be implemented in different granularity, ranging from covering whole networks or systems to specific data fields and can also consider properties such as user location or the type of network connection that is used for access. These principles and how granular access control is defined can have a significant cost impact. Stronger rules and more granularity typically lead to higher cost. Business requirements and risk considerations should be used to define which access control rules are applied and which granularity is required. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.16_OT Identity management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.16_OT Identity management.md new file mode 100644 index 0000000..9745e28 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.16_OT Identity management.md @@ -0,0 +1,44 @@ +## 5.16 Identity management + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | + +**Control** +The full life cycle of identities should be managed. + +**Purpose** +To allow for the unique identification of individuals and systems accessing the organization’s information and other associated assets and to enable appropriate assignment of access rights. + +**Guidance** +The processes used in the context of identity management should ensure that: + +a\) for identities assigned to persons, a specific identity is only linked to a single person to be able to hold the person accountable for actions performed with this specific identity; + +b\) identities assigned to multiple persons (e.g. shared identities) are only permitted where they are necessary for business or operational reasons and are subject to dedicated approval and documentation; + +c\) identities assigned to non-human entities are subject to appropriately segregated approval and independent ongoing oversight; + +d\) identities are disabled or removed in a timely fashion if they are no longer required (e.g. if their associated entities are deleted or no longer used, or if the person linked to an identity has left the organization or changed the role); + +e\) in a specific domain, a single identity is mapped to a single entity, \[i.e. mapping of multiple identities to the same entity within the same context (duplicate identities) is avoided\]; + +f\) records of all significant events concerning the use and management of user identities and of authentication information are kept. + +The organization should have a supporting process in place to handle changes to information related to user identities. These processes can include re-verification of trusted documents related to a person. + +When using identities provided or issued by third parties (e.g. social media credentials), the organization should ensure the third-party identities provide the required trust level and any associated risks are known and sufficiently treated. This can include controls related to the third parties (see 5.19) as well as controls related to associated authentication information (see 5.17). + +**Other information** +Providing or revoking access to information and other associated assets is usually a multi-step procedure: + +a\) confirming the business requirements for an identity to be established; + +b\) verifying the identity of an entity before allocating them a logical identity; + +c\) establishing an identity; + +d\) configuring and activating the identity. This also includes configuration and initial setup of related authentication services; + +e\) providing or revoking specific access rights to the identity, based on appropriate authorization or entitle ment decisions (see 5.18). + diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.17_OT Authentication information.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.17_OT Authentication information.md new file mode 100644 index 0000000..93938d3 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.17_OT Authentication information.md @@ -0,0 +1,72 @@ +#iso27002/2022/EN +## 5.17 Authentication information + +### Control +Allocation and management of authentication information should be controlled by a management process, including advising personnel on the appropriate handling of authentication information. +### Purpose +To ensure proper entity authentication and prevent failures of authentication processes. +### Guidance + +**Allocation of authentication information** + +The allocation and management process should ensure that: + +a)   personal passwords or personal identification numbers (PINs) generated automatically during enrolment processes as temporary secret authentication information are non-guessable and unique for each person, and that users are required to change them after the first use; + +b)   procedures are established to verify the identity of a user prior to providing new, replacement or temporary authentication information; + +c)   authentication  information,  including  temporary  authentication  information,  is  transmitted to users in a secure manner (e.g. over an authenticated and protected channel) and the use of unprotected (clear text) electronic mail messages for this purpose is avoided; + +d)   users acknowledge receipt of authentication information; + +e)   default authentication information as predefined or provided by vendors is changed immediately following installation of systems or software; + +f)   records of significant events concerning allocation and management of authentication information are kept and their confidentiality is granted, and that the record-keeping method is approved (e.g. by using an approved password vault tool). + +**User responsibilities** + +Any person having access to or using authentication information should be advised to ensure that: + +a)   secret  authentication  information  such  as  passwords  are  kept  confidential.  Personal  secret authentication information is not to be shared with anyone. Secret authentication information used in the context of identities linked to multiple users or linked to non-personal entities are solely shared with authorized persons; + +b)   affected or compromised authentication information is changed immediately upon notification of or any other indication of a compromise; + +c)   when passwords are used as authentication information, strong passwords according to best practice recommendations are selected, for example: +1)   passwords are not based on anything somebody else can easily guess or obtain using personrelated information (e.g. names, telephone numbers and dates of birth); +2)   passwords are not based on dictionary words or combinations thereof; +3)   use easy to remember passphrases and try to include alphanumerical and special characters; +4)   passwords have a minimum length; + +d)   the same passwords are not used across distinct services and systems; + +e)   the obligation to follow these rules is also included in terms and conditions of employment (see 6.2). + +**Password management system** + +When passwords are used as authentication information, the password management system should: + +a)   allow users to select and change their own passwords and include a confirmation procedure to address input errors; + +b)   enforce  strong  passwords  according  to  good  practice  recommendations \[see  c)  of  "User responsibilities"\]; + +c)   force users to change their passwords at first login; + +d)   enforce password changes as necessary, for example after a security incident, or upon termination or change of employment when a user has known passwords for identities that remain active (e.g. shared identities); + +e)   prevent re-use of previous passwords; + +f)   prevent  the  use  of  commonly-used  passwords  and  compromised  usernames,  password combinations from hacked systems; + +g)   not display passwords on the screen when being entered; + +h)   store and transmit passwords in protected form. + +Password  encryption  and  hashing  should  be  performed  according  to  approved  cryptographic techniques for passwords (see 8.24). + +**Other** **information** + +Passwords or passphrases are a commonly used type of authentication information and are a common means of verifying a user’s identity. Other types of authentication information are cryptographic keys, data stored on hardware tokens (e.g. smart cards) that produce authentication codes and biometric data such as iris scans or fingerprints. Additional information can be found in the ISO/IEC 24760 series. + +Requiring frequent change of passwords can be problematic because users can get annoyed by the frequent changes, forget new passwords, note them down in unsafe places, or choose unsafe passwords. Provision of single sign on (SSO) or other authentication management tools (e.g. password vaults) reduces the amount of authentication information that users are required to protect and can thereby increase the effectiveness of this control. However, these tools can also increase the impact of disclosure of authentication information. + +Some applications require user passwords to be assigned by an independent authority. In such cases, a), c) and d) of "Password management system" do not apply. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.18_OT Access rights.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.18_OT Access rights.md new file mode 100644 index 0000000..974426b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.18_OT Access rights.md @@ -0,0 +1,63 @@ +## 5.18 Access rights + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | + +**Control** +Access rights to information and other associated assets should be provisioned, reviewed, modified and removed in accordance with the organization’s topic-specific policy on and rules for access control. + +**Purpose** +To ensure access to information and other associated assets is defined and authorized according to the business requirements. + +**Guidance** + +Provision and revocation of access rights +The provisioning process for assigning or revoking physical and logical access rights granted to an entity’s authenticated identity should include: + +a\) obtaining authorization from the owner of the information and other associated assets for the use of the information and other associated assets (see 5.9). Separate approval for access rights by management can also be appropriate; + +b\) considering the business requirements and the organization’s topic-specific policy and rules on access control; + +c\) considering segregation of duties, including segregating the roles of approval and implementation of the access rights and separation of conflicting roles; + +d\) ensuring access rights are removed when someone does not need to access the information and other associated assets, in particular ensuring access rights of users who have left the organization are removed in a timely fashion; + +e\) considering giving temporary access rights for a limited time period and revoking them at the expiration date, in particular for temporary personnel or temporary access required by personnel; + +f\) verifying that the level of access granted is in accordance with the topic-specific policies on access control (see 5.15) and is consistent with other information security requirements such as segregation of duties (see 5.3); + +g\) ensuring that access rights are activated (e.g. by service providers) only after authorization procedures are successfully completed; + +h\) maintaining a central record of access rights granted to a user identifier (ID, logical or physical) to access information and other associated assets; + +i\) modifying access rights of users who have changed roles or jobs; + +j\) removing or adjusting physical and logical access rights, which can be done by removal, revocation or replacement of keys, authentication information, identification cards or subscriptions; + +k\) maintaining a record of changes to users’ logical and physical access rights. + +Review of access rights +Regular reviews of physical and logical access rights should consider the following: + +a\) users’ access rights after any change within the same organization (e.g. job change, promotion, demotion) or termination of employment (see 6.1to 6.5); + +b\) authorizations for privileged access rights. + +Consideration before change or termination of employment +A user’s access rights to information and other associated assets should be reviewed and adjusted or removed before any change or termination of employment based on the evaluation of risk factors such as: + +a\) whether the termination or change is initiated by the user or by management and the reason for termination; + +b\) the current responsibilities of the user; + +c\) the value of the assets currently accessible. + +**Other information** +Consideration should be given to establishing user access roles based on business requirements that summarize a number of access rights into typical user access profiles. Access requests and reviews of access rights are easier managed at the level of such roles than at the level of particular rights. + +Consideration should be given to including clauses in personnel contracts and service contracts that specify sanctions if unauthorized access is attempted by personnel (see 5.20, 6.2, 6.4, 6.6). + +In cases of management-initiated termination, disgruntled personnel or external party users can deliberately corrupt information or sabotage information processing facilities. In cases of persons resigning or being dismissed, they can be tempted to collect information for future use. + +Cloning is an efficient way for organizations to assign access to users. However, it should be done with care based on distinct roles identified by the organization rather than just cloning an identity with all associated access rights. Cloning has an inherent risk of resulting in excessive access rights to information and other associated assets. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.19_OT Information security in supplier relationships.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.19_OT Information security in supplier relationships.md new file mode 100644 index 0000000..11664ac --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.19_OT Information security in supplier relationships.md @@ -0,0 +1,71 @@ +#iso27002/2022/EN +## 5.19 Information security in supplier relationships + +**Control** + +Processes and procedures should be defined and implemented to manage the information security risks associated with the use of supplier’s products or services. + +**Purpose** + +To maintain an agreed level of information security in supplier relationships. + +**Guidance** + +The organization should establish and communicate a topic-specific policy on supplier relationships to all relevant interested parties. + +The organization should identify and implement processes and procedures to address security risks associated with the use of products and services provided by suppliers. This should also apply to the organization’s use of resources of cloud service providers. These processes and procedures should include those to be implemented by the organization, as well as those the organization requires the supplier to implement for the commencement of use of a supplier’s products or services or for the termination of use of a supplier’s products and services, such as: + +a\) identifying and documenting the types of suppliers (e.g. ICT services, logistics, utilities, financial services, ICT infrastructure components) which can affect the confidentiality, integrity and availability of the organization's information; + +b\) establishing how to evaluate and select suppliers according to the sensitivity of information, products and services (e.g. with market analysis, customer references, review of documents, on-site assessments, certifications); + +c\) evaluating and selecting supplier’s products or services that have adequate information security controls and reviewing them; in particular, accuracy and completeness of controls implemented by the supplier that ensure integrity of the supplier’s information and information processing and hence the organization’s information security; + +d\) defining the organization’s information, ICT services and the physical infrastructure that suppliers can access, monitor, control or use; + +e\) defining the types of ICT infrastructure components and services provided by suppliers which can affect the confidentiality, integrity and availability of the organization's information; + +f\) assessing and managing the information security risks associated with: + 1\) the suppliers’ use of the organization’s information and other associated assets, including risks originating from potential malicious supplier personnel; + 2\) malfunctioning or vulnerabilities of the products (including software components and sub-components used in these products) or services provided by the suppliers; + +g\) monitoring compliance with established information security requirements for each type of supplier and type of access, including third-party review and product validation; + +h\) mitigating non-compliance of a supplier, whether this was detected through monitoring or by other means; + +i\) handling incidents and contingencies associated with supplier products and services including responsibilities of both the organization and suppliers; + +j\) resilience and, if necessary, recovery and contingency measures to ensure the availability of the supplier’s information and information processing and hence the availability of the organization’s information; + +k\) awareness and training for the organization’s personnel interacting with supplier personnel regarding appropriate rules of engagement, topic-specific policies, processes and procedures and behaviour based on the type of supplier and the level of supplier access to the organization’s systems and information; + +l\) managing the necessary transfer of information, other associated assets and anything else that needs to be changed and ensuring that information security is maintained throughout the transfer period; + +m\) requirements to ensure a secure termination of the supplier relationship, including: + + 1\) de-provisioning of access rights; + 2\) information handling; + 3\) determining ownership of intellectual property developed during the engagement; + 4\) information portability in case of change of supplier or insourcing; + 6\) records management; + 7\) return of assets; + 8\) secure disposal of information and other associated assets; + 9\) ongoing confidentiality requirements; + +n\) level of personnel security and physical security expected from supplier's personnel and facilities. + +The procedures for continuing information processing in the event that the supplier becomes unable to supply its products or services (e.g. because of an incident, because the supplier is no longer in business, or no longer provides some components due to technology advancements) should be considered to avoid any delay in arranging replacement products or services (e.g. identifying an alternative supplier in advance or always using alternative suppliers). + +**Other information** + +In cases where it is not possible for an organization to place requirements on a supplier, the organization should: + +a\) consider the guidance given in this control in making decisions about choosing a supplier and its product or service; + +b\) implement compensating controls as necessary based on a risk assessment. + +Information can be put at risk by suppliers with inadequate information security management. Controls should be determined and applied to manage the supplier's access to information and other associated assets. For example, if there is a special need for confidentiality of the information, non-disclosure agreements or cryptographic techniques can be used. Another example is personal data protection risks when the supplier agreement involves transfer of, or access to, information across borders. The organization needs to be aware that the legal or contractual responsibility for protecting information remains with the organization. + +Risks can also be caused by inadequate controls of ICT infrastructure components or services provided by suppliers. Malfunctioning or vulnerable components or services can cause information security breaches in the organization or to another entity (e.g. they can cause malware infection, attacks or other harm on entities other than the organization). + +See ISO/IEC 27036-2 for more detail. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.1_OT Policies for information security.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.1_OT Policies for information security.md new file mode 100644 index 0000000..58aa9f2 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.1_OT Policies for information security.md @@ -0,0 +1,74 @@ +#iso27002/2022/EN +## 5.1 Policies for information security + +#### Control +Information security policy and topic-specific policies should be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur. +#### Purpose +To ensure continuing suitability, adequacy, effectiveness of management direction and support for information security in accordance with business, legal, statutory, regulatory and contractual requirements. +#### Guidance +At the highest level, the organization should define an “information security policy” which is approved by top management and which sets out the organization’s approach to managing its information security. + +The information security policy should take into consideration requirements derived from: + +a) business strategy and requirements; +b) regulations, legislation and contracts; +c) the current and projected information security risks and threats. + +The information security policy should contain statements concerning: + +a) definition of information security; +b) information security objectives or the framework for setting information security objectives; +c) principles to guide all activities relating to information security; +d) commitment to satisfy applicable requirements related to information security; +e) commitment to continual improvement of the information security management system; +f) assignment of responsibilities for information security management to defined roles; +g) procedures for handling exemptions and exceptions. + +Top management should approve any changes to the information security policy. + +At a lower level, the information security policy should be supported by topic-specific policies as needed, to further mandate the implementation of information security controls. Topic-specific policies are typically structured to address the needs of certain target groups within an organization or to cover certain security areas. Topic-specific policies should be aligned with and complementary to the information security policy of the organization. + +Examples of such topics include: + +a) access control; +b) physical and environmental security; +c) asset management; +d) information transfer; +e) secure configuration and handling of user endpoint devices; +f) networking security; +g) information security incident management; +h) backup; +i) cryptography and key management; +j) information classification and handling; +k) management of technical vulnerabilities; +l) secure development. + +The responsibility for the development, review and approval of the topic-specific policies should be allocated to relevant personnel based on their appropriate level of authority and technical competency. The review should include assessing opportunities for improvement of the organization’s information security policy and topic-specific policies and managing information security in response to changes to: + +a) the organization’s business strategy; +b) the organization’s technical environment; +c) regulations, statutes, legislation and contracts; +d) information security risks; +e) the current and projected information security threat environment; +f) lessons learned from information security events and incidents. + +The review of information security policy and topic-specific policies should take the results of management reviews and audits into account. Review and update of other related policies should be considered when one policy is changed to maintain consistency. + +The information security policy and topic-specific policies should be communicated to relevant personnel and interested parties in a form that is relevant, accessible and understandable to the intended reader. Recipients of the policies should be required to acknowledge they understand and agree to comply with the policies where applicable. The organization can determine the formats and names of these policy documents that meet the organization’s needs. In some organizations, the information security policy and topic-specific policies can be in a single document. The organization can name these topic-specific policies as standards, directives, policies or others. + +If the information security policy or any topic-specific policy is distributed outside the organization, care should be taken not to improperly disclose confidential information. + +Table 1 illustrates the differences between information security policy and topic-specific policy. + +*Table 1* | Information security policy | Topic-specific policy +------- | --------------------------- | --------------------- +Level of detail | General or high-level | Specific and detailed +Documented and formally approved by | Top management | Appropriate level of management + +#### Other information +Topic-specific policies can vary across organizations. + + +# Related +- [[ISO_27002_PE 5.1 Policies for information security]] + diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.20_OT Addressing information security within supplier agreements.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.20_OT Addressing information security within supplier agreements.md new file mode 100644 index 0000000..55e407d --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.20_OT Addressing information security within supplier agreements.md @@ -0,0 +1,72 @@ +#iso27002/2022/EN +## 5.20 Addressing information security within supplier agreements + +**Control** +Relevant information security requirements should be established and agreed with each supplier based on the type of supplier relationship. + +**Purpose** +To maintain an agreed level of information security in supplier relationships. + +**Guidance** +Supplier agreements should be established and documented to ensure that there is clear understanding between the organization and the supplier regarding both parties’ obligations to fulfil relevant information security requirements. + +The following terms can be considered for inclusion in the agreements in order to satisfy the identified information security requirements: + +a\) description of the information to be provided or accessed and methods of providing or accessing the information; + +b\) classification of information according to the organization’s classification scheme (see [[5.10]], [[5.12]], [[5.13]]) + +c\) mapping between the organization’s own classification scheme and the classification scheme of the supplier; + +d\) legal, statutory, regulatory and contractual requirements, including data protection, handling of personally identifiable information (PII), intellectual property rights and copyright and a description of how it will be ensured that they are met; + +e\) obligation of each contractual party to implement an agreed set of controls, including access control, performance review, monitoring, reporting and auditing, and the supplier’s obligations to comply with the organization’s information security requirements; + +f\) rules of acceptable use of information and other associated assets, including unacceptable use if necessary; + +g\) procedures or conditions for authorization and removal of the authorization for the use of the organization’s information and other associated assets by supplier personnel (e.g. through an explicit list of supplier personnel authorized to use the organization’s information and other associated assets); + +h\) information security requirements regarding the supplier’s ICT infrastructure; in particular, minimum information security requirements for each type of information and type of access to serve as the basis for individual supplier agreements based on the organization’s business needs and risk criteria; + +i\) indemnities and remediation for failure of contractor to meet requirements; + +j\) incident management requirements and procedures (especially notification and collaboration during incident remediation); + +k\) training and awareness requirements for specific procedures and information security requirements (e.g. for incident response, authorization procedures); + +l\) relevant provisions for sub-contracting, including the controls that need to be implemented, such as agreement on the use of sub-suppliers (e.g. requiring to have them under the same obligations of the supplier, requiring to have a list of sub-suppliers and notification before any change); + +m\) relevant contacts, including a contact person for information security issues; + +n\) any screening requirements, where legally permissible, for the supplier’s personnel, including responsibilities for conducting the screening and notification procedures if screening has not been completed or if the results give cause for doubt or concern; + +o\) the evidence and assurance mechanisms of third-party attestations for relevant information security requirements related to the supplier processes and an independent report on effectiveness of controls; + +p\) right to audit the supplier processes and controls related to the agreement; + +q\) supplier’s obligation to periodically deliver a report on the effectiveness of controls and agreement on timely correction of relevant issues raised in the report; + +r\) defect resolution and conflict resolution processes; + +s\) providing backup aligned with the organization’s needs (in terms of frequency and type and storage location); + +t\) ensuring the availability of an alternate facility (i.e. disaster recovery site) not subject to the same threats as the primary facility and considerations for fall back controls (alternate controls) in the event primary controls fail; + +u\) having a change management process that ensures advance notification to the organization and the possibility for the organization of not accepting changes; + +v\) physical security controls commensurate with the information classification; + +w\) information transfer controls to protect the information during physical transfer or logical transmission; + +x\) termination clauses upon conclusion of the agreement including records management, return of assets, secure disposal of information and other associated assets, and any ongoing confidentiality obligations; + +y\) provision of a method of securely destroying the organization’s information stored by the supplier as soon as it is no longer required; + +z\) ensuring, at the end of the contract, handover support to another supplier or to the organization itself. + +The organization should establish and maintain a register of agreements with external parties (e.g. contracts, memorandum of understanding, information-sharing agreements) to keep track of where their information is going. The organization should also regularly review, validate and update their agreements with external parties to ensure they are still required and fit for purpose with relevant information security clauses. + +**Other information** +The agreements can vary considerably for different organizations and among the different types of suppliers. Therefore, care should be taken to include all relevant requirements for addressing information security risks. + +For details on supplier agreements, see ISO/IEC 27036 series. For cloud service agreements, see ISO/IEC 19086 series. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain.md new file mode 100644 index 0000000..bed7514 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain.md @@ -0,0 +1,58 @@ +#iso27002/2022/EN +[[ISO_27002_PE 5.21 Managing information security in the ICT supply chain]] + +## 5.21 Managing information security in the ICT supply chain + +**Control** +Processes and procedures should be defined and implemented to manage the information security risks associated with the ICT products and services supply chain. + +**Purpose** +To maintain an agreed level of information security in supplier relationships. + +**Guidance** + +The following topics should be considered to address information security within ICT supply chain security in addition to the general information security requirements for supplier relationships: + +a\) defining information security requirements to apply to ICT product or service acquisition; + +b\) requiring that ICT services suppliers propagate the organization’s security requirements throughout the supply chain if they sub-contract for parts of the ICT service provided to the organization; + +c\) requiring that ICT products suppliers propagate appropriate security practices throughout the supply chain if these products include components purchased or acquired from other suppliers or other entities (e.g. sub-contracted software developers and hardware component providers); + +d\) requesting that ICT products suppliers provide information describing the software components used in products; + +e\) requesting that ICT products suppliers provide information describing the implemented security functions of their product and the configuration required for its secure operation; + +f\) implementing a monitoring process and acceptable methods for validating that delivered ICT products and services comply with stated security requirements. Examples of such supplier review methods can include penetration testing and proof or validation of third-party attestations for the supplier’s information security operations; + +g\) implementing a process for identifying and documenting product or service components that are critical for maintaining functionality and therefore require increased attention, scrutiny and further follow up required when built outside of the organization especially if the supplier outsources aspects of product or service components to other suppliers; + +h\) obtaining assurance that critical components and their origin can be traced throughout the supply chain; + +i\) obtaining assurance that the delivered ICT products are functioning as expected without any unexpected or unwanted features; + +j\) implementing processes to ensure that components from suppliers are genuine and unaltered from their specification. Example measures include anti-tamper labels, cryptographic hash verifications or digital signatures. Monitoring for out of specification performance can be an indicator of tampering or counterfeits. Prevention and detection of tampering should be implemented during multiple stages in the system development life cycle, including design, development, integration, operations and maintenance; + +k\) obtaining assurance that ICT products achieve required security levels, for example, through formal certification or an evaluation scheme such as the Common Criteria Recognition Arrangement; + +l\) defining rules for sharing of information regarding the supply chain and any potential issues and compromises among the organization and suppliers; + +m\) implementing specific processes for managing ICT component life cycle and availability and associated security risks. This includes managing the risks of components no longer being available due to suppliers no longer being in business or suppliers no longer providing these components due to technology advancements. Identification of an alternative supplier and the process to transfer software and competence to the alternative supplier should be considered. + +**Other information** + +The specific ICT supply chain risk management practices are built on top of general information security, quality, project management and system engineering practices but do not replace them. + +Organizations are advised to work with suppliers to understand the ICT supply chain and any matters that have an important effect on the products and services being provided. The organization can influence ICT supply chain information security practices by making clear in agreements with their suppliers the matters that should be addressed by other suppliers in the ICT supply chain. + +ICT should be acquired from reputable sources. The reliability of software and hardware is a matter of quality control. While it is generally not possible for an organization to inspect the quality control systems of its vendors, it can make reliable judgments based on the reputation of the vendor. + +ICT supply chain as addressed here includes cloud services. + +Examples of ICT supply chains are: + +a\) cloud services provisioning, where the cloud service provider relies on the software developers, telecommunication service providers, hardware providers; + +b\) IoT, where the service involves the device manufacturers, the cloud service providers (e.g. the IoT platform operators), the developers for mobile and web applications, the vendor of software libraries; + +c\) hosting services, where the provider relies on external service desks including first, second and third support levels. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services.md new file mode 100644 index 0000000..f123f36 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services.md @@ -0,0 +1,57 @@ +#iso27002/2022/EN + +# 5.22 Monitoring, review and change management of supplier services + +**Control** +The organization should regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery. + +**Purpose** +To maintain an agreed level of information security and service delivery in line with supplier agreements. + +**Guidance** +Monitoring, review and change management of supplier services should ensure the information security terms and conditions of the agreements are complied with, information security incidents and problems are managed properly and changes in supplier services or business status do not affect service delivery. + +This should involve a process to manage the relationship between the organization and the supplier to: + +a\) monitor service performance levels to verify compliance with the agreements; + +b) monitor changes made by suppliers including: +1) enhancements to the current services offered; +2) development of any new applications and systems; +3) modifications or updates of the supplier’s policies and procedures; +4) new or changed controls to resolve information security incidents and to improve information security; + +c) monitor changes in supplier services including: +1) changes and enhancement to networks; +2) use of new technologies; +3) adoption of new products or newer versions or releases; +4) new development tools and environments; +5) changes to physical location of service facilities; +6) change of sub-suppliers; +7) sub-contracting to another supplier; + +d\) review service reports produced by the supplier and arrange regular progress meetings as required by the agreements; + +e\) conduct audits of suppliers and sub-suppliers, in conjunction with review of independent auditor’s reports, if available and follow-up on issues identified; + +f\) provide information about information security incidents and review this information as required by the agreements and any supporting guidelines and procedures; + +g\) review supplier audit trails and records of information security events, operational problems, failures, tracing of faults and disruptions related to the service delivered; + +h\) respond to and manage any identified information security events or incidents; + +i\) identify information security vulnerabilities and manage them; + +j\) review information security aspects of the supplier’s relationships with its own suppliers; + +k\) ensure that the supplier maintains sufficient service capability together with workable plans designed to ensure that agreed service continuity levels are maintained following major service failures or disaster (see [[5.29]], [[5.30]], [[5.35]], [[5.36]], [[8.14]]; + +l\) ensure that suppliers assign responsibilities for reviewing compliance and enforcing the requirements of the agreements; + +m\) evaluate regularly that the suppliers maintain adequate information security levels. + + +The responsibility for managing supplier relationships should be assigned to a designated individual or team. Sufficient technical skills and resources should be made available to monitor that the requirements of the agreement, in particular the information security requirements, are being met. Appropriate actions should be taken when deficiencies in the service delivery are observed. + +**Other information** +See ISO/IEC 27036-3 for more detail. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.23_OT Information security for use of cloud services.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.23_OT Information security for use of cloud services.md new file mode 100644 index 0000000..f1f04c6 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.23_OT Information security for use of cloud services.md @@ -0,0 +1,53 @@ +#iso27002/2022/EN +## 5.23 Information security for use of cloud services + +#### Control +Processes for acquisition, use, management and exit from cloud services should be established in accordance with the organization’s information security requirements. +#### Purpose +To specify and manage information security for the use of cloud services. +#### Guidance +The organization should establish and communicate topic-specific policy on the use of cloud services to all relevant interested parties. + +The organization should define and communicate how it intends to manage information security risks associated with the use of cloud services. It can be an extension or part of the existing approach for how an organization manages services provided by external parties (see 5.21 and 5.22). + +The use of cloud services can involve shared responsibility for information security and collaborative effort between the cloud service provider and the organization acting as the cloud service customer. It is essential that the responsibilities for both the cloud service provider and the organization, acting as the cloud service customer, are defined and implemented appropriately. + +The organization should define: +a) all relevant information security requirements associated with the use of the cloud services; +b) cloud service selection criteria and scope of cloud service usage; +c) roles and responsibilities related to the use and management of cloud services; +d) which information security controls are managed by the cloud service provider and which are managed by the organization as the cloud service customer; +e) how to obtain and utilize information security capabilities provided by the cloud service provider; +f) how to obtain assurance on information security controls implemented by cloud service providers; +g) how to manage controls, interfaces and changes in services when an organization uses multiple cloud services, particularly from different cloud service providers; +h) procedures for handling information security incidents that occur in relation to the use of cloud services; +i) its approach for monitoring, reviewing and evaluating the ongoing use of cloud services to manage information security risks; +j) how to change or stop the use of cloud services including exit strategies for cloud services. + +Cloud service agreements are often pre-defined and not open to negotiation. For all cloud services, the organization should review cloud service agreements with the cloud service provider(s). A cloud service agreement should address the confidentiality, integrity, availability and information handling requirements of the organization, with appropriate cloud service level objectives and cloud service qualitative objectives. The organization should also undertake relevant risk assessments to identify the risks associated with using the cloud service. Any residual risks connected to the use of the cloud service should be clearly identified and accepted by the appropriate management of the organization. + +An agreement between the cloud service provider and the organization, acting as the cloud service customer, should include the following provisions for the protection of the organization’s data and availability of services: +a) providing solutions based on industry accepted standards for architecture and infrastructure; +b) managing access controls of the cloud service to meet the requirements of the organization; +c) implementing malware monitoring and protection solutions; +d) processing and storing the organization’s sensitive information in approved locations (e.g. particular country or region) or within or subject to a particular jurisdiction; +e) providing dedicated support in the event of an information security incident in the cloud service environment; +f) ensuring that the organization’s information security requirements are met in the event of cloud services being further sub-contracted to an external supplier (or prohibiting cloud services from being sub-contracted); +g) supporting the organization in gathering digital evidence, taking into consideration laws and regulations for digital evidence across different jurisdictions; +h) providing appropriate support and availability of services for an appropriate time frame when the organization wants to exit from the cloud service; +i) providing required backup of data and configuration information and securely managing backups as applicable, based on the capabilities of the cloud service provider used by the organization, acting as the cloud service customer; +j) providing and returning information such as configuration files, source code and data that are owned by the organization, acting as the cloud service customer, when requested during the service provision or at termination of service. + +The organization, acting as the cloud service customer, should consider whether the agreement should require cloud service providers to provide advance notification prior to any substantive customer impacting changes being made to the way the service is delivered to the organization, including: +a) changes to the technical infrastructure (e.g. relocation, reconfiguration, or changes in hardware or software) that affect or change the cloud service offering; +b) processing or storing information in a new geographical or legal jurisdiction; +c) use of peer cloud service providers or other sub-contractors (including changing existing or using new parties). + +The organization using cloud services should maintain close contact with its cloud service providers. These contacts enable mutual exchange of information about information security for the use of the cloud services including a mechanism for both cloud service provider and the organization, acting as the cloud service customer, to monitor each service characteristic and report failures to the commitments contained in the agreements. + +#### Other information +This control considers cloud security from the perspective of the cloud service customer. + +Additional information relating to cloud services can be found in ISO/IEC 17788, ISO/IEC 17789 and ISO/IEC 22123-1. Specifics related to cloud portability in support of exit strategies can be found in ISO/IEC 19941. Specifics related to information security and public cloud services are described in ISO/IEC 27017. Specifics related to PII protection in public clouds acting as PII processor are described in ISO/IEC 27018. Supplier relationships for cloud services are covered by ISO/IEC 27036-4 and cloud service agreements and their contents are dealt with in the ISO/IEC 19086 series, with security and privacy specifically covered by ISO/IEC 19086-4. +# Related: +- [[ISO_27002_PE 5.23 Information security for use of cloud services]] \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.24_OT Information security incident management planning and preparation.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.24_OT Information security incident management planning and preparation.md new file mode 100644 index 0000000..439768d --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.24_OT Information security incident management planning and preparation.md @@ -0,0 +1,66 @@ +#iso27002/2022/EN +## 5.24 Information security incident management planning and preparation + +#### Control +The organization should plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities. +#### Purpose +To ensure quick, effective, consistent and orderly response to information security incidents, including communication on information security events. +#### Guidance + +**Roles and responsibilities** + +The organization should establish appropriate information security incident management processes. Roles and responsibilities to carry out the incident management procedures should be determined and effectively communicated to the relevant internal and external interested parties. + +The following should be considered: + +a\) establishing a common method for reporting information security events including point of contact (see [[ISO_27002_OT n.n Title\|6.8]]); + +b\) establishing an incident management process to provide the organization with capability for managing information security incidents including administration, documentation, detection, triage, prioritization, analysis, communication and coordinating interested parties; + +c\) establishing an incident response process to provide the organization with capability for assessing, responding to and learning from information security incidents; + +d\) only allowing competent personnel to handle the issues related to information security incidents within the organization. Such personnel should be provided with procedure documentation and periodic training; + +e\) establishing a process to identify required training, certification and ongoing professional development for incident response personnel. + +**Incident management procedures** + +The objectives for information security incident management should be agreed with management and it should be ensured that those responsible for information security incident management understand the organization’s priorities for handling information security incidents, including resolution time frame based on potential consequences and severity. Incident management procedures should be implemented to meet these objectives and priorities. + +Management should ensure that an information security incident management plan is created considering different scenarios and procedures are developed and implemented for the following activities: + +a\) evaluation of information security events according to criteria for what constitutes an information security incident; + +b\) monitoring (see [[ISO_27002_OT n.n Title\|8.15]] and [[ISO_27002_OT n.n Title\|8.16]]), detecting (see [[ISO_27002_OT n.n Title\|8.16]]), classifying (see [[ISO_27002_OT n.n Title\|5.25]]), analysing and reporting (see [[ISO_27002_OT n.n Title\|6.8]]) of information security events and incidents (by human or automatic means); + +c\) managing information security incidents to conclusion, including response and escalation (see [[ISO_27002_OT n.n Title\|5.26]]), according to the type and the category of the incident, possible activation of crisis management and activation of continuity plans, controlled recovery from an incident and communication to internal and external interested parties; + +d\) coordination with internal and external interested parties such as authorities, external interest groups and forums, suppliers and clients (see [[ISO_27002_OT 5.5 Contact with authorities|5.5]] and [[ISO_27002_OT 5.6 Contact with special interest groups\|5.6]]); + +e\) logging incident management activities; + +f\) handling of evidence (see [[ISO_27002_OT n.n Title\|5.28]]); + +g\) root cause analysis or post-mortem procedures; + +h\) identification of lessons learned and any improvements to the incident management procedures or information security controls in general that are required. + +**Reporting procedures** + +Reporting procedures should include: + +a\) actions to be taken in case of an information security event (e.g. noting all pertinent details immediately such as malfunction occurring and messages on screen, immediately reporting to the point of contact and only taking coordinated actions); + +b\) use of incident forms to support personnel to perform all necessary actions when reporting information security incidents; + +c\) suitable feedback processes to ensure that those persons reporting information security events are notified, to the extent possible, of outcomes after the issue has been addressed and closed; + +d\) creation of incident reports. + +Any external requirements on reporting of incidents to relevant interested parties within the defined time frame (e.g. breach notification requirements to regulators) should be considered when implementing incident management procedures. + +**Other information** + +Information security incidents can transcend organizational and national boundaries. To respond to such incidents, it is beneficial to coordinate response and share information about these incidents with external organizations as appropriate. + +Detailed guidance on information security incident management is provided in the ISO/IEC 27035 series. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.25_OT Assessment and decision on information security events.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.25_OT Assessment and decision on information security events.md new file mode 100644 index 0000000..827c3ad --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.25_OT Assessment and decision on information security events.md @@ -0,0 +1,35 @@ +## 5.25 Assessment and decision on information security events + + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------- | ---------------- | +| #Detective | #Confidentiality #Integrity #Availability | #Detect #Respond | #Information_security_event_management | #Defence | + + + +**Control** +The organization should assess information security events and decide if they are to be categorized as information security incidents. + + + +**Purpose** + + + +To ensure effective categorization and prioritization of information security events. + + + +**Guidance** + + + +A categorization and prioritization scheme of information security incidents should be agreed for the identification of the consequences and priority of an incident. The scheme should include the criteria to categorize events as information security incidents. The point of contact should assess each information security event using the agreed scheme. + +Personnel responsible for coordinating and responding to information security incidents should perform the assessment and make a decision on information security events. + +Results of the assessment and decision should be recorded in detail for the purpose of future reference and verification. + +**Other information** +The ISO/IEC 27035 series provides further guidance on incident management. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.26_OT Response to information security incidents.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.26_OT Response to information security incidents.md new file mode 100644 index 0000000..49e177a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.26_OT Response to information security incidents.md @@ -0,0 +1,35 @@ +## 5.26 Response to information security incidents + + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------- | ---------------- | +| #Corrective | #Confidentiality #Integrity #Availability | #Respond #Recover | #Information_security_event_management | #Defence | + + +**Control** +Information security incidents should be responded to in accordance with the documented procedures. + +**Purpose** +To ensure efficient and effective response to information security incidents. + +**Guidance** +The organization should establish and communicate procedures on information security incident response to all relevant interested parties. + +Information security incidents should be responded to by a designated team with the required competency (see 5.24). + +The response should include the following: + +a\) containing, if the consequences of the incident can spread, the systems affected by the incident; +b\) collecting evidence (see 5.28) as soon as possible after the occurrence; +c\) escalation, as required including crisis management activities and possibly invoking business continuity plans (see 5.29and 5.30); +d\) ensuring that all involved response activities are properly logged for later analysis; +e\) communicating the existence of the information security incident or any relevant details thereof to all relevant internal and external interested parties following the need-to-know principle; +f\) coordinating with internal and external parties such as authorities, external interest groups and forums, suppliers and clients to improve response effectiveness and help to minimize consequences for other organizations; +g\) once the incident has been successfully addressed, formally closing and recording it; +h\) conducting information security forensic analysis, as required (see 5.28); +i\) performing post-incident analysis to identify root cause. Ensure it is documented and communicated according to defined procedures (see 5.27); +j\) identifying and managing information security vulnerabilities and weaknesses including those related to controls which have caused, contributed to or failed to prevent the incident. + +**Other information** +The ISO/IEC 27035 series provides further guidance on incident management. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.27_OT Learning from information security incidents.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.27_OT Learning from information security incidents.md new file mode 100644 index 0000000..0eb3532 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.27_OT Learning from information security incidents.md @@ -0,0 +1,20 @@ +#iso27002/2022/EN +## 5.27 Learning from information security incidents + +#### Control +Knowledge gained from information security incidents should be used to strengthen and improve the information security controls. +#### Purpose +To reduce the likelihood or consequences of future incidents. +#### Guidance +The organization should establish procedures to quantify and monitor the types, volumes and costs of information security incidents. + +The information gained from the evaluation of information security incidents should be used to: + +a\) enhance the incident management plan including incident scenarios and procedures (see [[ISO_27002_OT 5.24 Information security incident management planning and preparation|5.24]]); + +b\) identify recurring or serious incidents and their causes to update the organization’s information security risk assessment and determine and implement necessary additional controls to reduce the likelihood or consequences of future similar incidents. Mechanisms to enable that include collecting, quantifying and monitoring information about incident types, volumes and costs; + +c\) enhance user awareness and training (see [[ISO_27002_OT 6.3 Information security awareness, education and training|6.3]]) by providing examples of what can happen, how to respond to such incidents and how to avoid them in the future. +#### Other information + +The ISO/IEC 27035 series provides further guidance. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.28_OT Collection of evidence.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.28_OT Collection of evidence.md new file mode 100644 index 0000000..d4b3cff --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.28_OT Collection of evidence.md @@ -0,0 +1,38 @@ +## 5.28 Collection of evidence + + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------- | ---------------- | +| #Corrective | #Confidentiality #Integrity #Availability | #Detect #Respond | #Information_security_event_management | #Defence | + + + +**Control** +The organization should establish and implement procedures for the identification, collection, acquisition and preservation of evidence related to information security events. + +**Purpose** +To ensure a consistent and effective management of evidence related to information security incidents for the purposes of disciplinary and legal actions. + +**Guidance** +Internal procedures should be developed and followed when dealing with evidence related to information security events for the purposes of disciplinary and legal actions. The requirements of different jurisdictions should be considered to maximize chances of admission across the relevant jurisdictions. + +In general, these procedures for the management of evidence should provide instructions for the identification, collection, acquisition and preservation of evidence in accordance with different types of storage media, devices and status of devices (i.e. powered on or off). Evidence typically needs to be collected in a manner that is admissible in the appropriate national courts of law or another disciplinary forum. It should be possible to show that: + +a\) records are complete and have not been tampered with in any way; + +b\) copies of electronic evidence are probably identical to the originals; + +c\) any information system from which evidence has been gathered was operating correctly at the time the evidence was recorded. + +Where available, certification or other relevant means of qualification of personnel and tools should be sought, so as to strengthen the value of the preserved evidence. + +Digital evidence can transcend organizational or jurisdictional boundaries. In such cases, it should be ensured that the organization is entitled to collect the required information as digital evidence. + +**Other information** + +When an information security event is first detected, it is not always obvious whether or not the event will result in court action. Therefore, the danger exists that necessary evidence is destroyed intentionally or accidentally before the seriousness of the incident is realized. It is advisable to involve legal advice or law enforcement early in any contemplated legal action and take advice on the evidence required. + +ISO/IEC 27037 provides definitions and guidelines for identification, collection, acquisition and preservation of digital evidence. + +The ISO/IEC 27050 series deals with electronic discovery, which involves the processing of electronically stored information as evidence. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.29_OT Information security during disruption.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.29_OT Information security during disruption.md new file mode 100644 index 0000000..c37ffcf --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.29_OT Information security during disruption.md @@ -0,0 +1,30 @@ +#iso27002/2022/EN +## 5.29 Information security during disruption + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ----------------------- | ----------------------------------------- | ---------------------- | ------------------------ | ----------------------- | +| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Protect #Respond | #Continuity | #Protection #Resilience | + +**Control** +The organization should plan how to maintain information security at an appropriate level during disruption. + +**Purpose** +To protect information and other associated assets during disruption. + +**Guidance** +The organization should determine its requirements for adapting information security controls during disruption. Information security requirements should be included in the business continuity management processes. + +Plans should be developed, implemented, tested, reviewed and evaluated to maintain or restore the security of information of critical business processes following interruption or failure. Security of information should be restored at the required level and in the required time frames. + +The organization should implement and maintain: + +a\) information security controls, supporting systems and tools within business continuity and ICT continuity plans; + +b\) processes to maintain existing information security controls during disruption; + +c\) compensating controls for information security controls that cannot be maintained during disruption. + +**Other information** +In the context of business continuity and ICT continuity planning, it can be necessary to adapt the information security requirements depending on the type of disruption, compared to normal operational conditions. As part of the business impact analysis and risk assessment performed within business continuity management, the consequences of loss of confidentiality and integrity of information should be considered and prioritized in addition to the need for maintaining availability. + +Information on business continuity management systems can be found in ISO 22301 and ISO 22313. Further guidance on business impact analysis (BIA) can be found in ISO/TS 22317. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.2_OT Information security roles and responsibilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.2_OT Information security roles and responsibilities.md new file mode 100644 index 0000000..de3c53a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.2_OT Information security roles and responsibilities.md @@ -0,0 +1,27 @@ +#iso27002/2022/EN +## 5.2 Information security roles and responsibilities + +### Control +Information security roles and responsibilities should be defined and allocated according to the organization needs. + +### Purpose +To establish a defined, approved and understood structure for the implementation, operation and management of information security within the organization. + +### Guidance +Allocation of information security roles and responsibilities should be done in accordance with the information security policy and topic-specific policies (see [[ISO_27002_OT 5.1 Policies for information security\|5.1]]). The organization should define and manage responsibilities for: + +a)   protection of information and other associated assets; +b)   carrying out specific information security processes; +c)   information security risk management activities and in particular acceptance of residual risks (e.g. to risk owners); +d)   all personnel using an organization’s information and other associated assets. + +These responsibilities should be supplemented, where necessary, with more detailed guidance for specific sites and information processing facilities. Individuals with allocated information security responsibilities can assign security tasks to others. However, they remain accountable and should determine that any delegated tasks have been correctly performed. + +Each  security  area  for  which  individuals  are  responsible  should  be  defined,  documented  and communicated. Authorization levels should be defined and documented. Individuals who take on a specific information security role should be competent in the knowledge and skills required by the role and should be supported to keep up to date with developments related to the role and required in order to fulfil the responsibilities of the role. + +### Other information +Many organizations appoint an information security manager to take overall responsibility for the development and implementation of information security and to support the identification of risks and mitigating controls. + +However, responsibility for resourcing and implementing the controls often remains with individual managers. One common practice is to appoint an owner for each asset who then becomes responsible for its day-to-day protection. + +Depending on the size and resourcing of an organization, information security can be covered by dedicated roles or duties carried out in addition to existing roles. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.30_OT ICT readiness for business continuity.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.30_OT ICT readiness for business continuity.md new file mode 100644 index 0000000..551ee75 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.30_OT ICT readiness for business continuity.md @@ -0,0 +1,42 @@ +#iso27002/2022/EN +# **5.30** **ICT** **readiness** **for** **business** continuity + +## Purpose +To ensure the availability of the organization’s information and other associated assets during disruption. +## Guidance +ICT readiness for business continuity is an important component in business continuity management and information security management to ensure that the organization’s objectives can continue to be met during disruption. + +The ICT continuity requirements are the outcome of the business impact analysis (BIA). The BIA process should use impact types and criteria to assess the impacts over time resulting from the disruption of business activities that deliver products and services. The magnitude and duration of the resulting impact should be used to identify prioritized activities which should be assigned a recovery time objective (RTO). The BIA should then determine which resources are needed to support prioritized activities. An RTO should also be specified for these resources. A subset of these resources should include ICT services. + +The BIA involving ICT services can be expanded to define performance and capacity requirements of ICT systems and recovery point objectives (RPO) of information required to support activities during disruption. + +Based on the outputs from the BIA and risk assessment involving ICT services, the organization should identify and select ICT continuity strategies that consider options for before, during and after disruption. The business continuity strategies can comprise one or more solutions. Based on the strategies, plans should be developed, implemented and tested to meet the required availability level of ICT services and in the required time frames following interruption to, or failure of, critical processes. + +The organization should ensure that: + +a)   an adequate organizational structure is in place to prepare for, mitigate and respond to a disruption supported by personnel with the necessary responsibility, authority and competence; + +b)   ICT continuity plans, including response and recovery procedures detailing how the organization is planning to manage an ICT service disruption, are: + +1)   regularly evaluated through exercises and tests; +2)   approved by management; + +c)   ICT continuity plans include the following ICT continuity information: + +1)   performance and capacity specifications to meet the business continuity requirements and objectives as specified in the BIA; +2)   RTO of each prioritized ICT service and the procedures for restoring those components; +3)   RPO of the prioritized ICT resources defined as information and the procedures for restoring the information. + +## Other **information** + +Managing ICT continuity forms a key part of business continuity requirements concerning availability to be able to: + +a)   respond and recover from disruption to ICT services regardless of the cause; + +b)   ensure continuity of prioritized activities are supported by the required ICT services; + +c)   respond before a disruption to ICT services occurs, and upon detection of at least one incident that can result in a disruption to ICT services. + +Further guidance on ICT readiness for business continuity can be found in ISO/IEC 27031. + +Further guidance on business continuity management systems can be found in ISO 22301 and ISO 22313. Further guidance on BIA can be found in ISO/TS 22317. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.31_OT Legal, statutory, regulatory and contractual requirements.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.31_OT Legal, statutory, regulatory and contractual requirements.md new file mode 100644 index 0000000..347fe93 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.31_OT Legal, statutory, regulatory and contractual requirements.md @@ -0,0 +1,73 @@ +## 5.31 Legal, statutory, regulatory and contractual requirements + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------ | ------------------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Legal_and_compliance | #Governance_and_Ecosystem #Protection | + +**Control** +Legal, statutory, regulatory and contractual requirements relevant to information security and the organization’s approach to meet these requirements should be identified, documented and kept up to date. + +**Purpose** +To ensure compliance with legal, statutory, regulatory and contractual requirements related to information security. + +**Guidance** + +General +External requirements including legal, statutory, regulatory or contractual requirements should be taken into consideration when: + +a\) developing information security policies and procedures; + +b\) designing, implementing or changing information security controls; + +c\) classifying information and other associated assets as part of the process for setting information security requirements for internal needs or for supplier agreements; + +d\) performing information security risk assessments and determining information security risk treatment activities; + +e\) determining processes along with related roles and responsibilities relating to information security; + +f\) determining suppliers’ contractual requirements relevant to the organization and the scope of supply of products and services. + +Legislation and regulations + +The organization should: + +a\) identify all legislation and regulations relevant to the organization’s information security in order to be aware of the requirements for their type of business; + +b\) take into consideration compliance in all relevant countries, if the organization: + +— conducts business in other countries; + +— uses products and services from other countries where laws and regulations can affect the organization; + +— transfers information across jurisdictional borders where laws and regulations can affect the organization; + +c\) review the identified legislation and regulation regularly in order to keep up to date with the changes and identify new legislation; + +d\) define and document the specific processes and individual responsibilities to meet these requirements. + +Cryptography +Cryptography is an area that often has specific legal requirements. Compliance with the relevant agreements, laws and regulations relating to the following items should be taken into consideration: + +a\) restrictions on import or export of computer hardware and software for performing cryptographic functions; + +b\) restrictions on import or export of computer hardware and software which is designed to have cryptographic functions added to it; + +c\) restrictions on the usage of cryptography; + +d\) mandatory or discretionary methods of access by the countries’ authorities to encrypted information; + +e\) validity of digital signatures, seals and certificates. + +It is recommended to seek legal advice when ensuring compliance with relevant legislation and regulations, especially when encrypted information or cryptography tools are moved across jurisdictional borders. + +Contracts + +Contractual requirements related to information security should include those stated in: + +a\) contracts with clients; + +b\) contracts with suppliers (see 5.20); + +c\) insurance contracts. **Other information** + +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.32_OT Intellectual property rights.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.32_OT Intellectual property rights.md new file mode 100644 index 0000000..c5a2f9a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.32_OT Intellectual property rights.md @@ -0,0 +1,48 @@ +#iso27002/2022/EN +## 5.32 Intellectual property rights + +**Control** +The organization should implement appropriate procedures to protect intellectual property rights. + +**Purpose** +To ensure compliance with legal, statutory, regulatory and contractual requirements related to intellectual property rights and use of proprietary products. + +The following guidelines should be considered to protect any material that can be considered intellectual property: + +a\) defining and communicating a topic-specific policy on protection of intellectual property rights; + +b\) publishing procedures for intellectual property rights compliance that define compliant use of software and information products; + +c\) acquiring software only through known and reputable sources, to ensure that copyright is not infringed upon; + +d\) maintaining appropriate asset registers and identifying all assets with requirements to protect intellectual property rights; + +e\) maintaining proof and evidence of ownership of licenses, manuals, etc.; + +f\) ensuring that any maximum number of users or resources \[e.g. central processing units (CPUs)\] permitted within the license is not exceeded; + +g\) carrying out reviews to ensure that only authorized software and licensed products are installed; + +h\) providing procedures for maintaining appropriate license conditions; + +i\) providing procedures for disposing of or transferring software to others; + +j\) complying with terms and conditions for software and information obtained from public networks and outside sources; + +k\) not duplicating, converting to another format or extracting from commercial recordings (video, audio) other than permitted by copyright law or the applicable licences; + +l\) not copying, in full or in part, standards (e.g. ISO/IEC International Standards), books, articles, reports or other documents, other than permitted by copyright law or the applicable licences. + +**Other information** + +Intellectual property rights include software or document copyright, design rights, trademarks, patents and source code licenses. + +Proprietary software products are usually supplied under a license agreement that specifies licence terms and conditions, for example, limiting the use of the products to specified machines or limiting copying to the creation of backup copies only. See the ISO/IEC 19770 series for details about IT asset management. + +Data can be acquired from outside sources. It is generally the case that such data is obtained under the terms of a data sharing agreement or similar legal instrument. Such data sharing agreements should make it clear what processing is permitted for the acquired data. It is also advisable that the provenance of the data is clearly stated. See ISO/IEC 23751:—1) for details about data sharing agreements. + +Legal, statutory, regulatory and contractual requirements can place restrictions on the copying of proprietary material. In particular, they can require that only material that is developed by the organization or that is licensed or provided by the developer to the organization, can be used. Copyright infringement can lead to legal action, which can involve fines and criminal proceedings. + +Aside from the organization needing to comply with its obligations towards third party intellectual property rights, the risks of personnel and third parties failing to uphold the organization’s own intellectual property rights should also be managed. + +1\) Under preparation. Stage at the time of publication: ISO/IEC PRF 23751:2022. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.33_OT Protection of records.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.33_OT Protection of records.md new file mode 100644 index 0000000..c7799c9 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.33_OT Protection of records.md @@ -0,0 +1,39 @@ +## 5.33 Protection of records + + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | --------------------------------------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Legal_and_compliance #Asset_management #Information_protection | #Defence | + + +**Control** +Records should be protected from loss, destruction, falsification, unauthorized access and unauthorized release. + +**Purpose** +To ensure compliance with legal, statutory, regulatory and contractual requirements, as well as community or societal expectations related to the protection and availability of records. + +**Guidance** +The organization should take the following steps to protect the authenticity, reliability, integrity and usability of records, as their business context and requirements for their management change over time: + +a\) issue guidelines on the storage, handling chain of custody and disposal of records, which includes prevention of manipulation of records. These guidelines should be aligned with the organization’s topic-specific policy on records management and other records requirements; + +b\) draw up a retention schedule defining records and the period of time for which they should be retained. + +The system of storage and handling should ensure identification of records and of their retention period taking into consideration national or regional legislation or regulations, as well as community or societal expectations, if applicable. This system should permit appropriate destruction of records after that period if they are not needed by the organization. + +When deciding on protection of specific organizational records, their corresponding information security classification, based on the organization’s classification scheme, should be considered. Records should be categorized into record types (e.g. accounting records, business transaction records, personnel records, legal records), each with details of retention periods and type of allowable storage media which can be physical or electronic. + +Data storage systems should be chosen such that required records can be retrieved in an acceptable time frame and format, depending on the requirements to be fulfilled. + +Where electronic storage media are chosen, procedures to ensure the ability to access records (both storage media and format readability) throughout the retention period should be established to safeguard against loss due to future technology change. Any related cryptographic keys and programs associated with encrypted archives or digital signatures, should also be retained to enable decryption of the records for the length of time the records are retained (see 8.24). + +Storage and handling procedures should be implemented in accordance with recommendations provided by manufacturers of storage media. Consideration should be given to the possibility of deterioration of media used for storage of records. + +**Other information** + +Records document individual events or transactions or can form aggregations that have been designed to document work processes, activities or functions. They are both evidence of business activity and information assets. Any set of information, regardless of its structure or form, can be managed as a record. This includes information in the form of a document, a collection of data or other types of digital or analogue information which are created, captured and managed in the course of business. + +In the management of records, metadata is data describing the context, content and structure of records, as well as their management over time. Metadata is an essential component of any record. + +It can be necessary to retain some records securely to meet legal, statutory, regulatory or contractual requirements, as well as to support essential business activities. National law or regulation can set the time period and data content for information retention. Further information about records management can be found in ISO 15489. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.34_OT Privacy and protection of PII.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.34_OT Privacy and protection of PII.md new file mode 100644 index 0000000..cf279bd --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.34_OT Privacy and protection of PII.md @@ -0,0 +1,31 @@ +## 5.34 Privacy and protection of PII + + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | --------------------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Information_protection #Legal_and_compliance | #Protection | + +**Control** +The organization should identify and meet the requirements regarding the preservation of privacy and protection of PII according to applicable laws and regulations and contractual requirements. + +**Purpose** +To ensure compliance with legal, statutory, regulatory and contractual requirements related to the information security aspects of the protection of PII. + +**Guidance** +The organization should establish and communicate a topic-specific policy on privacy and protection of PII to all relevant interested parties. + +The organization should develop and implement procedures for the preservation of privacy and protection of PII. These procedures should be communicated to all relevant interested parties involved in the processing of personally identifiable information. + +Compliance with these procedures and all relevant legislation and regulations concerning the preservation of privacy and protection of PII requires appropriate roles, responsibilities and controls. Often this is best achieved by the appointment of a person responsible, such as a privacy officer, who should provide guidance to personnel, service providers and other interested parties on their individual responsibilities and the specific procedures that should be followed. + +Responsibility for handling PII should be dealt with taking into consideration relevant legislation and regulations. + +Appropriate technical and organizational measures to protect PII should be implemented. + +**Other information** +A number of countries have introduced legislation placing controls on the collection, processing, transmission and deletion of PII. Depending on the respective national legislation, such controls can impose duties on those collecting, processing and disseminating PII and can also restrict the authority to transfer PII to other countries. + +ISO/IEC 29100 provides a high-level framework for the protection of PII within ICT systems. Further information on privacy information management systems can be found in ISO/IEC 27701. Specific information regarding privacy information management for public clouds acting as PII processors can be found in ISO/IEC 27018. + +ISO/IEC 29134 provides guidelines for privacy impact assessment (PIA) and gives an example of the structure and content of a PIA report. Compared with ISO/IEC 27005, this is focused on PII processing and relevant to those organizations that process PII. This can help identify privacy risks and possible mitigations to reduce these risks to acceptable levels. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.35_OT Independent review of information security.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.35_OT Independent review of information security.md new file mode 100644 index 0000000..7ad256c --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.35_OT Independent review of information security.md @@ -0,0 +1,38 @@ +## 5.35 Independent review of information security + + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ----------------------- | ----------------------------------------- | ---------------------- | ------------------------------- | ------------------------- | +| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Identify #Protect | #Information_security_assurance | #Governance_and_Ecosystem | + +**Control** +The organization’s approach to managing information security and its implementation including people, processes and technologies should be reviewed independently at planned intervals, or when significant changes occur. + +**Purpose** +To ensure the continuing suitability, adequacy and effectiveness of the organization’s approach to managing information security. + +**Guidance** +The organization should have processes to conduct independent reviews. + +Management should plan and initiate periodic independent reviews. The reviews should include assessing opportunities for improvement and the need for changes to the approach to information security, including the information security policy, topic-specific policies and other controls. + +Such reviews should be carried out by individuals independent of the area under review (e.g. the internal audit function, an independent manager or an external party organization specializing in such reviews). Individuals carrying out these reviews should have the appropriate competence. The person conducting the reviews should not be in the line of authority to ensure they have the independence to make an assessment. + +The results of the independent reviews should be reported to the management who initiated the reviews and, if appropriate, to top management. These records should be maintained. + +If the independent reviews identify that the organization’s approach and implementation to managing information security is inadequate \[e.g. documented objectives and requirements are not met or are not compliant with the direction for information security stated in the information security policy and topic-specific policies (see 5.1)\], management should initiate corrective actions. + +In addition to the periodic independent reviews, the organization should consider conducting independent reviews when: + +a\) laws and regulations which affect the organization change; + +b\) significant incidents occur; + +c\) the organization starts a new business or changes a current business; + +d\) the organization starts to use a new product or service, or changes the use of a current product or service; + +e\) the organization changes the information security controls and procedures significantly. + +ISO/IEC 27007 and ISO/IEC TS 27008 provide guidance for carrying out independent reviews. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.36_OT Compliance with policies, rules and standards for information security.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.36_OT Compliance with policies, rules and standards for information security.md new file mode 100644 index 0000000..145ceb7 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.36_OT Compliance with policies, rules and standards for information security.md @@ -0,0 +1,31 @@ +## 5.36 Compliance with policies, rules and standards for information security + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ----------------------------------------------------- | ------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Legal_and_compliance #Information_security_assurance | #Governance_and_Ecosystem | + +**Control** +Compliance with the organization’s information security policy, topic-specific policies, rules and standards should be regularly reviewed. + +**Purpose** +To ensure that information security is implemented and operated in accordance with the organization’s information security policy, topic-specific policies, rules and standards. + +**Guidance** +Managers, service, product or information owners should identify how to review that information security requirements defined in the information security policy, topic-specific policies, rules, standards and other applicable regulations are met. Automatic measurement and reporting tools should be considered for efficient regular review. + +If any non-compliance is found as a result of the review, managers should: + +a\) identify the causes of the non-compliance; + +b\) evaluate the need for corrective actions to achieve compliance; + +c\) implement appropriate corrective actions; + +d\) review corrective actions taken to verify its effectiveness and identify any deficiencies or weaknesses. + +Results of reviews and corrective actions carried out by managers, service, product or information owners should be recorded and these records should be maintained. Managers should report the results to the persons carrying out independent reviews (see 5.35) when an independent review takes place in the area of their responsibility. + +Corrective actions should be completed in a timely manner as appropriate to the risk. If not completed by the next scheduled review, progress should at least be addressed at that review. + +**Other information** +Operational monitoring of system use is covered in 8.15, 8.16, 8.17. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.37_OT Documented operating procedures.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.37_OT Documented operating procedures.md new file mode 100644 index 0000000..ac95962 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.37_OT Documented operating procedures.md @@ -0,0 +1,55 @@ + + +## 5.37 Documented operating procedures + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ----------------------- | ----------------------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- | +| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Protect #Recover | #Asset_management #Physical_security #System_and_network_security #Application_security #Secure_configuration #Identity_and_access_management #Threat_and_vulnerability_management #Continuity #Information_security_event_management | #Governance_and_Ecosystem #Protection #Defence | + +**Control** +Operating procedures for information processing facilities should be documented and made available to personnel who need them. + +**Purpose** +To ensure the correct and secure operation of information processing facilities. + +**Guidance** +Documented procedures should be prepared for the organization’s operational activities associated with information security, for example: + +a\) when the activity needs to be performed in the same way by many people; + +b\) when the activity is performed rarely and when next performed the procedure is likely to have been forgotten; + +c\) when the activity is new and presents a risk if not performed correctly; + +d\) prior to handing over the activity to new personnel. + +The operating procedures should specify: + +a\) the responsible individuals; + +b\) the secure installation and configuration of systems; + +c\) processing and handling of information, both automated and manual; + +d\) backup (see 8.13) and resilience; + +e\) scheduling requirements, including interdependencies with other systems; + +f\) instructions for handling errors or other exceptional conditions \[e.g. restrictions on the use of utility programs (see 8.18)\], which can arise during job execution; + +g\) support and escalation contacts including external support contacts in the event of unexpected operational or technical difficulties; + +h\) storage media handling instructions (see 7.10 and 7.14); + +i\) system restart and recovery procedures for use in the event of system failure; + +j\) the management of audit trail and system log information (see 8.15 and 8.17) and video monitoring systems (see 7.4); + +k\) monitoring procedures such as capacity, performance and security (see 8.6 and 8.16); + +l\) maintenance instructions. + +Documented operating procedures should be reviewed and updated when needed. Changes to documented operating procedures should be authorized. Where technically feasible, information systems should be managed consistently, using the same procedures, tools and utilities. + +**Other information** +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.3_OT Segregation of duties.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.3_OT Segregation of duties.md new file mode 100644 index 0000000..e668c88 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.3_OT Segregation of duties.md @@ -0,0 +1,33 @@ +#iso27002/2022/EN +## 5.3 Segregation of duties + +### Control +Conflicting duties and conflicting areas of responsibility should be segregated. +### Purpose +To reduce the risk of fraud, error and bypassing of information security controls. +### Guidance +Segregation of duties and areas of responsibility aims to separate conflicting duties between different individuals in order to prevent one individual from executing potential conflicting duties on their own. + +The organization should determine which duties and areas of responsibility need to be segregated. The following are examples of activities that can require segregation: + +a)   initiating, approving and executing a change; + +b)   requesting, approving and implementing access rights; + +c)   designing, implementing and reviewing code; + +d)   developing software and administering production systems; + +e)   using and administering applications; + +f)   using applications and administering databases; + +g)   designing, auditing and assuring information security controls. + + +The  possibility of collusion should be considered in designing the segregation controls. Small organizations can find segregation of duties difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls should be considered, such as monitoring of activities, audit trails and management supervision. + +Care should be taken when using role-based access control systems to ensure that persons are not granted conflicting roles. When there is a large number of roles, the organization should consider using automated tools to identify conflicts and facilitate their removal. Roles should be carefully defined and provisioned to minimize access problems if a role is removed or reassigned. + +### Other **information** +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.4_OT Management responsibilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.4_OT Management responsibilities.md new file mode 100644 index 0000000..a0ec231 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.4_OT Management responsibilities.md @@ -0,0 +1,29 @@ +#iso27002/2022/EN +## 5.4 Management responsibilities + +#### Control +Management should require all personnel to apply information security in accordance with the established information security policy, topic-specific policies and procedures of the organization. +#### Purpose +To ensure management understand their role in information security and undertake actions aiming to ensure all personnel are aware of and fulfill their information security responsibilities. +#### Guidance +Management should demonstrate support of the information security policy, topic-specific policies, procedures and information security controls. + +Management responsibilities should include ensuring that personnel: + +a)   are properly briefed on their information security roles and responsibilities prior to being granted access to the organization’s information and other associated assets; + +b)   are provided with guidelines which state the information security expectations of their role within the organization; + +c)   are mandated to fulfill the information security policy and topic-specific policies of the organization; + +d)   achieve a level of awareness of information security relevant to their roles and responsibilities within the organization (see 6.3); + +e)   compliance with the terms and conditions of employment, contract or agreement, including the organization’s information security policy and appropriate methods of working; + +f)   continue to have the appropriate information security skills and qualifications through ongoing professional education; + +g)   where practicable, are provided with a confidential channel for reporting violations of information security policy, topic-specific policies or procedures for information security (“whistleblowing”). This can allow for anonymous reporting, or have provisions to ensure that knowledge of the identity of the reporter is known only to those who need to deal with such reports; + +h)   are provided with adequate resources and project planning time for implementing the organization’s security-related processes and controls. +#### Other information +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.5_OT Contact with authorities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.5_OT Contact with authorities.md new file mode 100644 index 0000000..8528be3 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.5_OT Contact with authorities.md @@ -0,0 +1,15 @@ +#iso27002/2022/EN +## 5.5 Contact with authorities + +#### Control +The organization should establish and maintain contact with relevant authorities. +#### Purpose +To ensure appropriate flow of information takes place with respect to information security between the organization and relevant legal, regulatory and supervisory authorities. +#### Guidance +The organization should specify when and by whom authorities (e.g. law enforcement, regulatory bodies, supervisory authorities) should be contacted and how identified information security incidents should be reported in a timely manner. + +Contacts with authorities should also be used to facilitate the understanding about the current and upcoming expectations of these authorities (e.g. applicable information security regulations). +#### Other information +Organizations under attack can request authorities to take action against the attack source. + +Maintaining such contacts can be a requirement to support information security incident management (see 5.24 to 5.28) or the contingency planning and business continuity processes (see 5.29 and 5.30). Contacts with regulatory bodies are also useful to anticipate and prepare for upcoming changes in relevant laws or regulations that affect the organization. Contacts with other authorities include utilities, emergency services, electricity suppliers and health and safety \[e.g. fire departments (in connection with business continuity), telecommunication providers (in connection with line routing and availability) and water suppliers (in connection with cooling facilities for equipment)\]. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.6_OT Contact with special interest groups.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.6_OT Contact with special interest groups.md new file mode 100644 index 0000000..04453d4 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.6_OT Contact with special interest groups.md @@ -0,0 +1,25 @@ +#iso27002/2022/EN +## 5.6 Contact with special interest groups + +#### Control +The organization should establish and maintain contact with special interest groups or other specialist security forums and professional associations. +#### Purpose +To ensure appropriate flow of information takes place with respect to information security. +#### Guidance + +Membership of special interest groups or forums should be considered as a means to: + +a)   improve knowledge about best practices and stay up to date with relevant security information; + +b)   ensure the understanding of the information security environment is current; + +c)   receive early warnings of alerts, advisories and patches pertaining to attacks and vulnerabilities; + +d)   gain access to specialist information security advice; + +e)   share  and  exchange  information  about  new  technologies,  products,  services,  threats  or vulnerabilities; + +f)   provide suitable liaison points when dealing with information security incidents (see 5.24 to 5.28). + +#### Other information +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.7_OT Threat intelligence.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.7_OT Threat intelligence.md new file mode 100644 index 0000000..c0ae98e --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.7_OT Threat intelligence.md @@ -0,0 +1,45 @@ +#iso27002/2022/EN +## 5.7 Threat intelligence + +#### Control +Information relating to information security threats should be collected and analysed to produce threat intelligence. +#### Purpose +To provide awareness of the organization’s threat environment so that the appropriate mitigation actions can be taken. +#### Guidance +Information about existing or emerging threats is collected and analysed in order to: + +a)  facilitate informed actions to prevent the threats from causing harm to the organization; +b)  reduce the impact of such threats. + +Threat intelligence can be divided into three layers, which should all be considered: + +a)  strategic threat intelligence: exchange of high-level information about the changing threat landscape (e.g. types of attackers or types of attacks); +b)  tactical threat intelligence: information about attacker methodologies, tools and technologies involved; +c)  operational threat intelligence: details about specific attacks, including technical indicators. + +Threat intelligence should be: + +a)  relevant (i.e. related to the protection of the organization); +b)  insightful (i.e. providing the organization with an accurate and detailed understanding of the threat landscape); +c)  contextual, to provide situational awareness (i.e. adding context to the information based on the time of events, where they occur, previous experiences and prevalence in similar organizations); +d)  actionable (i.e. the organization can act on information quickly and effectively). + +Threat intelligence activities should include: + +a)  establishing objectives for threat intelligence production; +b)  identifying, vetting and selecting internal and external information sources that are necessary and appropriate to provide information required for the production of threat intelligence; +c)  collecting information from selected sources, which can be internal and external; +d)  processing information collected to prepare it for analysis (e.g. by translating, formatting or corroborating information); +e)  analysing information to understand how it relates and is meaningful to the organization; +f)  communicating and sharing it to relevant individuals in a format that can be understood. + +Threat intelligence should be analysed and later used: + +a)  by implementing processes to include information gathered from threat intelligence sources into the organization’s information security risk management processes; +b)  as additional input to technical preventive and detective controls like firewalls, intrusion detection system, or anti malware solutions; +c)  as input to the information security test processes and techniques. + +The organization should share threat intelligence with other organizations on a mutual basis in order to improve overall threat intelligence. +# Related: +- [[Threat Intelligence]] +- [[ISO_27002_PE 5.7 Threat intelligence]] diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.8_OT Information security in project management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.8_OT Information security in project management.md new file mode 100644 index 0000000..9154593 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.8_OT Information security in project management.md @@ -0,0 +1,50 @@ +#iso27002/2022/EN +## 5.8 Information security in project management + +#### Control +Information security should be integrated into project management. +#### Purpose +To ensure information security risks related to projects and deliverables are effectively addressed in project management throughout the project life cycle. +#### Guidance +Information security should be integrated into project management to ensure information security risks are addressed as part of the project management. This can be applied to any type of project regardless of its complexity, size, duration, discipline or application area (e.g. a project for a core business process, ICT, facility management or other supporting processes). + +The project management in use should require that: + +a)   information security risks are assessed and treated at an early stage and periodically as part of project risks throughout the project life cycle; + +b)   information security requirements \[e.g. application security requirements ([[ISO_27002_OT 8.26 Application security requirements|8.26]]), requirements for complying with intellectual property rights ([[ISO_27002_OT 5.32 Intellectual property rights|5.32]]), etc.] are addressed in the early stages of projects; + +c)   information security risks associated with the execution of projects, such as security of internal and external communication aspects are considered and treated throughout the project life cycle; + +d)   progress on information security risk treatment is reviewed and effectiveness of the treatment is evaluated and tested. + +The appropriateness of the information security considerations and activities should be followed up at predefined stages by suitable persons or governance bodies, such as the project steering committee. + +Responsibilities and authorities for information security relevant to the project should be defined and allocated to specified roles. + +Information security requirements for products or services to be delivered by the project should be determined using various methods, including deriving compliance requirements from information security policy, topic-specific policies and regulations. Further information security requirements can be derived from activities such as threat modelling, incident reviews, use of vulnerability thresholds or contingency planning, thus ensuring that the architecture and design of information systems are protected against known threats based on the operational environment. + +Information security requirements should be determined for all types of projects, not only ICT development projects. The following should also be considered when determining these requirements: + +a)   what information is involved (information determination), what are the corresponding information security needs (classification; see [[ISO_27002_OT 5.12 Classification of information\|5.12]]) and the potential negative business impact which can result from lack of adequate security; + +b)   the required protection needs of information and other associated assets involved, particularly in terms of confidentiality, integrity and availability; + +c)   the level of confidence or assurance required towards the claimed identity of entities in order to derive the authentication requirements; + +d)   access provisioning and authorization processes, for customers and other potential business users as well as for privileged or technical users such as relevant project members, potential operation staff or external suppliers; + +e)   informing users of their duties and responsibilities; + +f)   requirements derived from business processes, such as transaction logging and monitoring, non-repudiation requirements; + +g)   requirements mandated by other information security controls (e.g. interfaces to logging and monitoring or data leakage detection systems); + +h)   compliance with the legal, statutory, regulatory and contractual environment in which the organization operates; + +i) level of confidence or assurance required for third parties to meet the organization’s information security policy and topic-specific policies including relevant security clauses in any agreements or contracts. + +#### Other information +The project development approach, such as waterfall life cycle or agile life cycle, should support information security in a structured way that can be adapted to suit the assessed severity of the information security risks, based on the character of the project. Early consideration of information security requirements for the product or service (e.g. at the planning and design stages), can lead to more effective and cost-efficient solutions for quality and information security. ISO 21500 and ISO 21502 provide guidance on concepts and processes of project management that are important for the performance of projects. + +ISO/IEC 27005 provides guidance on the use of risk management processes to identify controls to meet information security requirements. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.9_OT Inventory of information and other associated assets.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.9_OT Inventory of information and other associated assets.md new file mode 100644 index 0000000..645fb25 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.9_OT Inventory of information and other associated assets.md @@ -0,0 +1,69 @@ +#iso27002/2022/EN + +## 5.9 Inventory of information and other associated assets + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-------------------------|-----------------------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Asset_management | #Governance_and_Ecosystem #Protection | + +**Control** +An inventory of information and other associated assets, including owners, should be developed and maintained. + +**Purpose** +To identify the organization’s information and other associated assets in order to preserve their information security and assign appropriate ownership. + +**Guidance** + +Inventory +The organization should identify its information and other associated assets and determine their importance in terms of information security. Documentation should be maintained in dedicated or existing inventories as appropriate. + +The inventory of information and other associated assets should be accurate, up to date, consistent and aligned with other inventories. Options for ensuring accuracy of an inventory of information and other associated assets include: + + a\) conducting regular reviews of identified information and other associated assets against the asset inventory; + + b\) automatically enforcing an inventory update in the process of installing, changing or removing an asset. + +The location of an asset should be included in the inventory as appropriate. + +The inventory does not need to be a single list of information and other associated assets. Considering that the inventory should be maintained by the relevant functions, it can be seen as a set of dynamic inventories, such as inventories for information assets, hardware, software, virtual machines (VMs), facilities, personnel, competence, capabilities and records. + +Each asset should be classified in accordance with the classification of the information (see 5.12) associated to that asset. + +The granularity of the inventory of information and other associated assets should be at a level appropriate for the needs of the organization. Sometimes specific instances of assets in the information life cycle are not feasible to be documented due to the nature of the asset. An example of a short-lived asset is a VM instance whose life cycle can be of short duration. + +Ownership +For the identified information and other associated assets, ownership of the asset should be assigned to an individual or a group and the classification should be identified (see 5.12, 5.13). A process to ensure timely assignment of asset ownership should be implemented. Ownership should be assigned when assets are created or when assets are transferred to the organization. Asset ownership should be reassigned as necessary when current asset owners leave or change job roles. + +Owner duties +The asset owner should be responsible for the proper management of an asset over the whole asset life cycle, ensuring that: + +a\) information and other associated assets are inventoried; + +b\) information and other associated assets are appropriately classified and protected; + +c\) the classification is reviewed periodically; + +d\) components supporting technology assets are listed and linked, such as database, storage, software components and sub-components; + +e\) requirements for the acceptable use of information and other associated assets (see 5.10) are established; + +f\) access restrictions correspond with the classification and that they are effective and are reviewed periodically; + +g\) information and other associated assets, when deleted or disposed, are handled in a secure manner and removed from the inventory; + +h\) they are involved in the identification and management of risks associated with their asset(s); + +i\) they support personnel who have the roles and responsibilities of managing their information. + +**Other information** +Inventories of information and other associated assets are often necessary to ensure the effective protection of information and can be required for other purposes, such as health and safety, insurance or financial reasons. Inventories of information and other associated assets also support risk management, audit activities, vulnerability management, incident response and recovery planning. + +Tasks and responsibilities can be delegated (e.g. to a custodian looking after the assets on a daily basis), but the person or group who delegated them remains accountable. + + + +It can be useful to designate groups of information and other associated assets which act together to provide a particular service. In this case, the owner of this service is accountable for the delivery of the service, including the operation of its assets. + + + +See ISO/IEC 19770-1 for additional information on information technology (IT) asset management. See ISO 55001 for additional information on asset management. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.1_OT Screening.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.1_OT Screening.md new file mode 100644 index 0000000..640bc60 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.1_OT Screening.md @@ -0,0 +1,48 @@ +# Control 6.1 Screening + + + +## 6.1 Screening + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +| ---------------- | ----------------------------------------- | -------------------------- | ---------------------------- | ------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Human_resource_security | #Governance_and_Ecosystem | + +**Control** +Background verification checks on all candidates to become personnel should be carried out prior to joining the organization and on an ongoing basis taking into consideration applicable laws, regulations and ethics and be proportional to the business requirements, the classification of the information to be accessed and the perceived risks. + +**Purpose** +To ensure all personnel are eligible and suitable for the roles for which they are considered and remain eligible and suitable during their employment. + +**Guidance** +A screening process should be performed for all personnel including full-time, part-time and temporary staff. Where these individuals are contracted through suppliers of services, screening requirements should be included in the contractual agreements between the organization and the suppliers. + +Information on all candidates being considered for positions within the organization should be collected and handled taking into consideration any appropriate legislation existing in the relevant jurisdiction. In some jurisdictions, the organization can be legally required to inform the candidates beforehand about the screening activities. + +Verification should take into consideration all relevant privacy, PII protection and employment-based legislation and should, where permitted, include the following: + +a\) availability of satisfactory references (e.g. business and personal references); +b\) a verification (for completeness and accuracy) of the applicant’s curriculum vitae; +c\) confirmation of claimed academic and professional qualifications; +d\) independent identity verification (e.g. passport or other acceptable document issued by appropriate authorities); +e\) more detailed verification, such as credit review or review of criminal records if the candidate takes on a critical role. + +When an individual is hired for a specific information security role, the organization should make sure the candidate: +a\) has the necessary competence to perform the security role; +b\) can be trusted to take on the role, especially if the role is critical for the organization. + +Where a job, either on initial appointment or on promotion, involves the person having access to information processing facilities and, in particular, if these involve handling confidential information (e.g. financial information, personal information or health care information) the organization should also consider further, more detailed verifications. + +Procedures should define criteria and limitations for verification reviews (e.g. who is eligible to screen people and how, when and why verification reviews are carried out). + +In situations where verification cannot be completed in a timely manner, mitigating controls should be implemented until the review has been finished, for example: + +a\) delayed onboarding; +b\) delayed deployment of corporate assets; +c\) onboarding with reduced access; +d\) termination of employment. + +Verification checks should be repeated periodically to confirm ongoing suitability of personnel, depending on the criticality of a person’s role. + +**Other information** +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.2_OT Terms and conditions of employment.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.2_OT Terms and conditions of employment.md new file mode 100644 index 0000000..0503d57 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.2_OT Terms and conditions of employment.md @@ -0,0 +1,38 @@ +## 6.2 Terms and conditions of employment + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +| ---------------- | ----------------------------------------- | -------------------------- | ---------------------------- | ------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Human_resource_security | #Governance_and_Ecosystem | + +**Control** +The employment contractual agreements should state the personnel’s and the organization’s responsibilities for information security. + +**Purpose** +To ensure personnel understand their information security responsibilities for the roles for which they are considered. + +**Guidance** +The contractual obligations for personnel should take into consideration the organization’s information security policy and relevant topic-specific policies. In addition, the following points can be clarified and stated: + +a\) confidentiality or non-disclosure agreements that personnel who are given access to confidential information should sign prior to being given access to information and other associated assets (see 6.6); + +b\) legal responsibilities and rights \[e.g. regarding copyright laws or data protection legislation (see 5.32 and 5.34)\]; + +c\) responsibilities for the classification of information and management of the organization’s information and other associated assets, information processing facilities and information services handled by the personnel (see 5.9to 5.13); + +d\) responsibilities for the handling of information received from interested parties; + +e\) actions to be taken if personnel disregard the organization’s security requirements (see 6.4). + +Information security roles and responsibilities should be communicated to candidates during the pre- employment process. + +The organization should ensure that personnel agree to terms and conditions concerning information security. These terms and conditions should be appropriate to the nature and extent of access they will have to the organization’s assets associated with information systems and services. The terms and conditions concerning information security should be reviewed when laws, regulations, the information security policy or topic-specific policies change. + +Where appropriate, responsibilities contained within the terms and conditions of employment should continue for a defined period after the end of the employment (see 6.5). + +**Other information** + +A code of conduct can be used to state personnel’s information security responsibilities regarding confidentiality, PII protection, ethics, appropriate use of the organization’s information and other associated assets, as well as reputable practices expected by the organization. + +An external party, with which supplier personnel are associated, can be required to enter into contractual agreements on behalf of the contracted individual. + +If the organization is not a legal entity and does not have employees, the equivalent of contractual agreement and terms and conditions can be considered in line with the guidance of this control. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.3_OT Information security awareness, education and training.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.3_OT Information security awareness, education and training.md new file mode 100644 index 0000000..5994f8f --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.3_OT Information security awareness, education and training.md @@ -0,0 +1,75 @@ +#iso27002/2022/EN + +## 6.3 Information security awareness, education and training + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +| ---------------- | ----------------------------------------- | -------------------------- | ---------------------------- | ------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Human_resource_security | #Governance_and_Ecosystem | + + + +**Control** +Personnel of the organization and relevant interested parties should receive appropriate information security awareness, education and training and regular updates of the organization's information security policy, topic-specific policies and procedures, as relevant for their job function. + +**Purpose** +To ensure personnel and relevant interested parties are aware of and fullfil their information security responsibilities. + +**Guidance** + +General +An information security awareness, education and training programme should be established in line with the organization’s information security policy, topic-specific policies and relevant procedures on information security, taking into consideration the organization’s information to be protected and the information security controls that have been implemented to protect the information. + +Information security awareness, education and training should take place periodically. Initial awareness, education and training can apply to new personnel and to those who transfer to new positions or roles with substantially different information security requirements. + +Personnel’s understanding should be assessed at the end of an awareness, education or training activity to test knowledge transfer and the effectiveness of the awareness, education and training programme. + +Awareness +An information security awareness programme should aim to make personnel aware of their responsibilities for information security and the means by which those responsibilities are discharged. + +The awareness programme should be planned taking into consideration the roles of personnel in the organization, including internal and external personnel (e.g. external consultants, supplier personnel). The activities in the awareness programme should be scheduled over time, preferably regularly, so that the activities are repeated and cover new personnel. It should also be built on lessons learnt from information security incidents. + +The awareness programme should include a number of awareness-raising activities via appropriate physical or virtual channels such as campaigns, booklets, posters, newsletters, websites, information sessions, briefings, e-learning modules and e-mails. + +Information security awareness should cover general aspects such as: + + + +a\) management’s commitment to information security throughout the organization; + + + +b\) familiarity and compliance needs concerning applicable information security rules and obligations, taking into account information security policy and topic-specific policies, standards, laws, statutes, regulations, contracts and agreements; + + + +c\) personal accountability for one’s own actions and inactions, and general responsibilities towards securing or protecting information belonging to the organization and interested parties; + + + +d\) basic information security procedures \[e.g. information security event reporting (6.8)\] and baseline controls \[e.g. password security (5.17)\]; + + + +e\) contact points and resources for additional information and advice on information security matters, including further information security awareness materials. + + + +Education and training + + + +The organization should identify, prepare and implement an appropriate training plan for technical teams whose roles require specific skill sets and expertise. Technical teams should have the skills for configuring and maintaining the required security level for devices, systems, applications and services. If there are missing skills, the organization should take action and acquire them. + + + +The education and training programme should consider different forms \[e.g. lectures or self-studies, being mentored by expert staff or consultants (on-the-job training), rotating staff members to follow different activities, recruiting already skilled people and hiring consultants\]. It can use different means of delivery including classroom-based, distance learning, web-based, self-paced and others. Technical personnel should keep their knowledge up to date by subscribing to newsletters and magazines or by attending conferences and events aimed at technical and professional improvement. + + + +**Other information** + +When composing an awareness programme, it is important not only to focus on the ’what’ and ’how’, but also the ’why’, when possible. It is important that personnel understand the aim of information security and the potential effect, positive and negativ e, on the organization of their own behaviour. + + + +Information security awareness, education and training can be part of, or conducted in collaboration with, other activities, for exa mple general information management, ICT, security, privacy or safety training. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.4_OT Disciplinary process.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.4_OT Disciplinary process.md new file mode 100644 index 0000000..c00bf65 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.4_OT Disciplinary process.md @@ -0,0 +1,69 @@ +## 6.4 Disciplinary process + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|----------------------------|-----------------------------------------|---------------------------|-------------------------------|-----------------------------| + +| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Protect #Respond | #Human_resource_security | #Governance_and_Ecosystem | + + + +**Control** + + + +A disciplinary process should be formalized and communicated to take actions against personnel and other relevant interested parties who have committed an information security policy violation. + + + +**Purpose** + + + +To ensure personnel and other relevant interested parties understand the consequences of information security policy violation, to deter and appropriately deal with personnel and other relevant interested parties who committed the violation. + + + +**Guidance** + + + +The disciplinary process should not be initiated without prior verification that an information security policy violation has occurred (see 5.28). + + + +The formal disciplinary process should provide for a graduated response that takes into consideration factors such as: + + + +a\) the nature (who, what, when, how) and gravity of the breach and its consequences; + + + +b\) whether the offence was intentional (malicious) or unintentional (accidental); + + + +c\) whether or not this is a first or repeated offence; + + + +d\) whether or not the violator was properly trained. + + + +The response should take into consideration relevant legal, statutory, regulatory contractual and business requirements as well as other factors as required. The disciplinary process should also be used as a deterrent to prevent personnel and other relevant interested parties from violating the information security policy, topic-specific policies and procedures for information security. Deliberate information security policy violations can require immediate actions. + + + +**Other information** + + + +Where possible, the identity of individuals subject to disciplinary action should be protected in line with applicable requirements. + + + +When individuals demonstrate excellent behaviour with regard to information security, they can be rewarded to promote information security and encourage good behaviour. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.5_OT Responsibilities after termination or change of employment.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.5_OT Responsibilities after termination or change of employment.md new file mode 100644 index 0000000..c73609a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.5_OT Responsibilities after termination or change of employment.md @@ -0,0 +1,27 @@ + + +## 6.5 Responsibilities after termination or change of employment + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +| ---------------- | ----------------------------------------- | -------------------------- | ---------------------------- | -------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | | | | + +**Control** +Information security responsibilities and duties that remain valid after termination or change of employment should be defined, enforced and communicated to relevant personnel and other interested parties. + +**Purpose** +To protect the organization’s interests as part of the process of changing or terminating employment or contracts. + +**Guidance** +The process for managing termination or change of employment should define which information security responsibilities and duties should remain valid after termination or change. This can include confidentiality of information, intellectual property and other knowledge obtained, as well as responsibilities contained within any other confidentiality agreement (see 6.6). Responsibilities and duties still valid after termination of employment or contract should be contained in the individual’s terms and conditions of employment (see 6.2), contract or agreement. Other contracts or agreements that continue for a defined period after the end of the individual’s employment can also contain information security responsibilities. + +Changes of responsibility or employment should be managed as the termination of the current responsibility or employment combined with the initiation of the new responsibility or employment. + +Information security roles and responsibilities held by any individual who leaves or changes job roles should be identified and transferred to another individual. + +A process should be established for the communication of the changes and of operating procedures to personnel, other interested parties and relevant contact persons (e.g. to customers and suppliers). + +The process for the termination or change of employment should also be applied to external personnel (i.e. suppliers) when a termination occurs of personnel, the contract or the job with the organization, or when there is a change of the job within the organization. + +**Other information** +In many organizations, the human resources function is generally responsible for the overall termination process and works together with the supervising manager of the person transitioning to manage the information security aspects of the relevant procedures. In the case of personnel provided through an external party (e.g. through a supplier), this termination process is undertaken by the external party in accordance with the contract between the organization and the external party. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.6_OT Confidentiality or non-disclosure agreements.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.6_OT Confidentiality or non-disclosure agreements.md new file mode 100644 index 0000000..e3543d4 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.6_OT Confidentiality or non-disclosure agreements.md @@ -0,0 +1,89 @@ + + +## 6.6 Confidentiality or non-disclosure agreements + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|------------------------------------|---------------------------|-------------------------------------------------------------|-------------------------------| + +| #Preventive | #Confidentiality | #Protect | #Human_resource_security #Information_protection #Supplier_relationships | #Governance_and_Ecosystem | + + + +**Control** + +Confidentiality or non-disclosure agreements reflecting the organization’s needs for the protection of information should be identified, documented, regularly reviewed and signed by personnel and other relevant interested parties. + + + +**Purpose** + + + +To maintain confidentiality of information accessible by personnel or external parties. + + + +**Guidance** + + + +Confidentiality or non-disclosure agreements should address the requirement to protect confidential information using legally enforceable terms. Confidentiality or non-disclosure agreements are applicable to interested parties and personnel of the organization. Based on an organization’s information security requirements, the terms in the agreements should be determined by taking into consideration the type of information that will be handled, its classification level, its use and the permissible access by the other party. To identify requirements for confidentiality or non-disclosure agreements, the following elements should be considered: + + + +a\) a definition of the information to be protected (e.g. confidential information); + + + +b\) the expected duration of an agreement, including cases where it can be necessary to maintain confidentiality indefinitely or until the information becomes publicly available; + + + +c\) the required actions when an agreement is terminated; + + + +d\) the responsibilities and actions of signatories to avoid unauthorized information disclosure; + + + +e\) the ownership of information, trade secrets and intellectual property, and how this relates to the protection of confidential information; + + + +f\) the permitted use of confidential information and rights of the signatory to use the information; + + + +g\) the right to audit and monitor activities that involve confidential information for highly sensitive circumstances; + + + +h\) the process for notification and reporting of unauthorized disclosure or confidential information leakage; + + + +i\) the terms for information to be returned or destroyed at agreement termination; + + + +j\) the expected actions to be taken in the case of non-compliance with the agreement. + + + +The organization should take into consideration the compliance with confidentiality and non-disclosure agreements for the jurisdiction to which they apply (see 5.31, 5.32, 5.33, 5.34). + + + +Requirements for confidentiality and non-disclosure agreements should be reviewed periodically and when changes occur that influence these requirements. + + + +**Other information** + + + +Confidentiality and non-disclosure agreements protect the organization's information and inform signatories of their responsibility to protect, use and disclose information in a responsible and authorized manner. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.7_OT Remote working.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.7_OT Remote working.md new file mode 100644 index 0000000..564e177 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.7_OT Remote working.md @@ -0,0 +1,137 @@ +## 6.7 Remote working + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|-----------------------------------------|---------------------------|--------------------------------------------------------------------------------|---------------------| + +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management #Information_protection #Physical_security #System_and_network_security | #Protection | + + + +**Control** + + + +Security measures should be implemented when personnel are working remotely to protect information accessed, processed or stored outside the organization’s premises. + + + +**Purpose** + + + +To ensure the security of information when personnel are working remotely. + + + +**Guidance** + + + +Remote working occurs whenever personnel of the organization work from a location outside of the organization’s premises, accessing information whether in hardcopy or electronically via ICT equipment. Remote working environments include those referred to as “teleworking”, “telecommuting”, “flexible workplace”, “virtual work environments" and “remote maintenance”. + + + +NOTE It is possible that not all the recommendations in this guidance can be applied due to local legislation and regulations in different jurisdictions. + + + +Organizations allowing remote working activities should issue a topic-specific policy on remote working that defines the relevant conditions and restrictions. Where deemed applicable, the following matters should be considered: + + + +a\) the existing or proposed physical security of the remote working site, taking into account the physical security of the location and the local environment, including the different jurisdictions where personnel are located; + + + +b\) rules and security mechanisms for the remote physical environment such as lockable filing cabinets, secure transportation between locations and rules for remote access, clear desk, printing and disposal of information and other associated assets, and information security event reporting (see 6.8); + + + +c\) the expected physical remote working environments; + + + +d\) the communications security requirements, taking into account the need for remote access to the organization’s systems, the sensitivity of the information to be accessed and passed over the communication link and the sensitivity of the systems and applications; + + + +e\) the use of remote access such as virtual desktop access that supports processing and storage of information on privately owned equipment; + + + +f\) the threat of unauthorized access to information or resources from other persons at the remote working site (e.g. family and friends); + + + +g\) the threat of unauthorized access to information or resources from other persons in public places; + + + +h\) the use of home networks and public networks, and requirements or restrictions on the configuration of wireless network services; + + + +i\) use of security measures, such as firewalls and protection against malware; + + + +j\) secure mechanisms for deploying and initializing systems remotely; + + + +k\) sec ure mechanisms for authentication and enablement of access privileges taking into consideration the vulnerability of single-factor authentication mechanisms where remote access to the organization’s network is allowed. + + + +The guidelines and measures to be considered should include: + + + +a\) the provision of suitable equipment and storage furniture for the remote working activities, where the use of privately-owned equipment that is not under the control of the organization is not allowed; + + + +b\) a definition of the work permitted, the classification of information that can be held and the internal systems and services that the remote worker is authorized to access; + + + +c\) the provision of training for those working remotely and those providing support. This should include how to conduct business in a secure manner while working remotely; + + + +d\) the provision of suitable communication equipment, including methods for securing remote access, such as requirements on device screen locks and inactivity timers; the enabling of device location tracking; installation of remote wipe capabilities; + + + +e\) physical security; + + + +f\) rules and guidance on family and visitor access to equipment and information; + + + +g\) the provision of hardware and software support and maintenance; + + + +h\) the provision of insurance; + + + +i\) the procedures for backup and business continuity; + + + +j\) audit and security monitoring; + + + +k\) revocation of authority and access rights and the return of equipment when the remote working activities are terminated. + + + +**Other information** No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.8_OT Information security event reporting.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.8_OT Information security event reporting.md new file mode 100644 index 0000000..0b00a6c --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.8_OT Information security event reporting.md @@ -0,0 +1,95 @@ + + +## 6.8 Information security event reporting + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|-----------------------------------------|---------------------------|---------------------------------------------|---------------------| + +| #Detective | #Confidentiality #Integrity #Availability | #Detect | #Information_security_event_management | #Defence | + + + +**Control** + + + +The organization should provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner. + + + +**Purpose** + + + +To support timely, consistent and effective reporting of information security events that can be identified by personnel. + + + +**Guidance** + + + +All personnel and users should be made aware of their responsibility to report information security events as quickly as possible in order to prevent or minimize the effect of information security incidents. + + + +They should also be aware of the procedure for reporting information security events and the point of contact to which the events should be reported. The reporting mechanism should be as easy, accessible and available as possible. Information security events include incidents, breaches and vulnerabilities. + + + +Situations to be considered for information security event reporting include: + + + +a\) ineffective information security controls; + + + +b\) breach of information confidentiality, integrity or availability expectations; + + + +c\) human errors; + + + +d\) non-compliance with the information security policy, topic-specific policies or applicable standards; + + + +e\) breaches of physical security measures; + + + +f\) system changes that have not gone through the change management process; + + + +g\) malfunctions or other anomalous system behaviour of software or hardware; + + + +h\) access violations; + + + +i\) vulnerabilities; + + + +j\) suspected malware infection. + + + +Personnel and users should be advised not to attempt to prove suspected information security vulnerabilities. Testing vulnerabilities can be interpreted as a potential misuse of the system and can also cause damage to the information system or service, and it can corrupt or obscure digital evidence. Ultimately, this can result in legal liability for the individual performing the testing. + + + +**Other information** + + + +See the ISO/IEC 27035 series for additional information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.10_OT Storage media.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.10_OT Storage media.md new file mode 100644 index 0000000..98c49c1 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.10_OT Storage media.md @@ -0,0 +1,123 @@ +## 7.10 Storage media + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|-----------------------------------------|---------------------------|---------------------------------------------|---------------------| + +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Asset_management | #Protection | + + + +**Control** + + + +Storage media should be managed through their life cycle of acquisition, use, transportation and disposal in accordance with the organization’s classification scheme and handling requirements. + + + +**Purpose** + + + +To ensure only authorized disclosure, modification, removal or destruction of information on storage media. + + + +**Guidance** + + + +Removable storage media + + + +The following guidelines for the management of removable storage media should be considered: + + + +a\) establishing a topic-specific policy on the management of removable storage media and communicating such topic-specific policy to anyone who uses or handles removable storage media; + + + +b\) where necessary and practical, requiring authorization for storage media to be removed from the organization and keeping a record of such removals in order to maintain an audit trail; + + + +c\) storing all storage media in a safe, secure environment according to their information classification and protecting them against environmental threats (such as heat, moisture, humidity, electronic field or ageing), in accordance with manufacturers’ specifications; + + + +d\) if information confidentiality or integrity are important considerations, using cryptographic techniques to protect information on removable storage media; + + + +e\) to mitigate the risk of storage media degrading while stored information is still needed, transferring the information to fresh storage media before becoming unreadable; + + + +f\) storing multiple copies of valuable information on separate storage media to further reduce the risk of coincidental information damage or loss; + + + +g\) considering the registration of removable storage media to limit the chance for information loss; + + + +h\) only enabling removable storage media ports \[e.g. secure digital (SD) card slots and universal serial bus (USB) ports\] if there is an organizational reason for their use; + + + +i\) where there is a need to use removable storage media, monitoring the transfer of information to such storage media; + + + +j\) information can be vulnerable to unauthorized access, misuse or corruption during physical transport, for instance when sending storage media via the postal service or via courier. + + + +In this control, media includes paper documents. When transferring physical storage media, apply security measures in 5.14. + + + +Secure reuse or disposal + + + +Procedures for the secure reuse or disposal of storage media should be established to minimize the risk of confidential information leakage to unauthorized persons. The procedures for secure reuse or disposal of storage media containing confidential information should be proportional to the sensitivity of that information. The following items should be considered: + + + +a\) if storage media containing confidential information need to be reused within the organization, securely deleting data or formatting the storage media before reuse (see 8.10); + + + +b\) disposing of storage media containing confidential information securely when not needed anymore (e.g. by destroying, shredding or securely deleting the content); + + + +c\) having procedures in place to identify the items that can require secure disposal; + + + +d\) many organizations offer collection and disposal services for storage media. Care should be taken in selecting a suitable external party supplier with adequate controls and experience; + + + +e\) logging the disposal of sensitive items in order to maintain an audit trail; + + + +f\) when accumulating storage media for disposal, giving consideration to the aggregation effect, which can cause a large quantity of non-sensitive information to become sensitive. + + + +A risk assessment should be performed on damaged devices containing sensitive data to determine whether the items should be physically destroyed rather than sent for repair or discarded (see 7.14). + + + +**Other information** + +When confidential information on storage media is not encrypted, additional physical protection of the storage media should be considered. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.11_OT Supporting utilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.11_OT Supporting utilities.md new file mode 100644 index 0000000..3ee2bd9 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.11_OT Supporting utilities.md @@ -0,0 +1,73 @@ +## 7.11 Supporting utilities + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|-----------------------|------------------------------------|---------------------------|-----------------------------|----------------------| + +| #Preventive
#Detective | #Integrity
#Availability | #Protect #Detect | #Physical_security | #Protection | + + + +**Control** + + + +Information processing facilities should be protected from power failures and other disruptions caused by failures in supporting utilities. + + + +**Purpose** + + + +To prevent loss, damage or compromise of information and other associated assets, or interruption to the organization’s operations due to failure and disruption of supporting utilities. + + + +**Guidance** + + + +Organizations depend on utilities (e.g. electricity, telecommunications, water supply, gas, sewage, ventilation and air conditioning) to support their information processing facilities. Therefore, the organization should: + + + +a\) ensure equipment supporting the utilities is configured, operated and maintained in accordance with the relevant manufacturer’s specifications; + + + +b\) ensure utilities are appraised regularly for their capacity to meet business growth and interactions with other supporting utilities; + + + +c\) ensure equipment supporting the utilities is inspected and tested regularly to ensure their proper functioning; + + + +d\) if necessary, raise alarms to detect utilities malfunctions; + + + +e\) if necessary, ensure utilities have multiple feeds with diverse physical routing; + + + +f\) ensure equipment supporting the utilities is on a separate network from the information processing facilities if connected to a network; + + + +g\) ensure equipment supporting the utilities is connected to the internet only when needed and only in a secure manner. + + + +Emergency lighting and communications should be provided. Emergency switches and valves to cut off power, water, gas or other utilities should be located near emergency exits or equipment rooms. Emergency contact details should be recorded and available to personnel in the event of an outage. + + + +**Other information** + + + +Additional redundancy for network connectivity can be obtained by means of multiple routes from more than one utility provider. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.12_OT Cabling security.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.12_OT Cabling security.md new file mode 100644 index 0000000..26f7384 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.12_OT Cabling security.md @@ -0,0 +1,81 @@ +## 7.12 Cabling security + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|------------------------------------|---------------------------|-----------------------------|----------------------| + +| #Preventive | #Confidentiality #Availability | #Protect | #Physical_security | #Protection | + + + +**Control** + + + +Cables carrying power, data or supporting information services should be protected from interception, interference or damage. + + + +**Purpose** + + + +To prevent loss, damage, theft or compromise of information and other associated assets and interruption to the organization’s operations related to power and communications cabling. + + + +**Guidance** + + + +The following guidelines for cabling security should be considered: + + + +a\) power and telecommunications lines into information processing facilities being underground where possible, or subject to adequate alternative protection, such as floor cable protector and utility pole; if cables are underground, protecting them from accidental cuts (e.g. with armoured conduits or signals of presence); + + + +b\) segregating power cables from communications cables to prevent interference; + + + +c\) for sensitive or critical systems, further controls to consider include: + + + +1\) installation of armoured conduit and locked rooms or boxes and alarms at inspection and termination points; + + + +2\) use of electromagnetic shielding to protect the cables; + + + +3\) periodical technical sweeps and physical inspections to detect unauthorized devices being attached to the cables; + + + +4\) controlled access to patch panels and cable rooms (e.g. with mechanical keys or PINs); + + + +5\) use of fibre-optic cables; + + + +d\) labelling cables at each end with sufficient source and destination details to enable the physical identification and inspection of the cable. + + + +Specialist advice should be sought on how to manage risks arising from cabling incidents or malfunctions. + + + +**Other information** + + + +Sometimes power and telecommunications cabling are shared resources for more than one organization occupying co-located premises. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.13_OT Equipment maintenance.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.13_OT Equipment maintenance.md new file mode 100644 index 0000000..ef82bdb --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.13_OT Equipment maintenance.md @@ -0,0 +1,85 @@ +## 7.13 Equipment maintenance + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|-----------------------------------------|---------------------------|----------------------------------------|---------------------------| + +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Asset_management | #Protection #Resilience | + + + +**Control** + + + +Equipment should be maintained correctly to ensure availability, integrity and confidentiality of information. + + + +**Purpose** + + + +To prevent loss, damage, theft or compromise of information and other associated assets and interruption to the organization’s operations caused by lack of maintenance. + + + +**Guidance** + + + +The following guidelines for equipment maintenance should be considered: + + + +a\) maintaining equipment in accordance with the supplier’s recommended service frequency and specifications; + + + +b\) implementing and monitoring of a maintenance programme by the organization; + + + +c\) only authorized maintenance personnel carrying out repairs and maintenance on equipment; + + + +d\) keeping records of all suspected or actual faults, and of all preventive and corrective maintenance; + + + +e\) implementing appropriate controls when equipment is scheduled for maintenance, taking into account whether this maintenance is performed by personnel on site or external to the organization; subjecting the maintenance personnel to a suitable confidentiality agreement; + + + +f\) supervising maintenance personnel when carrying out maintenance on site; + + + +g\) authorizing and controlling access for remote maintenance; + + + +h\) applying security measures for assets off-premises (see 7.9) if equipment containing information is taken off premises for maintenance; + + + +i\) complying with all maintenance requirements imposed by insurance; + + + +j\) before putting equipment back into operation after maintenance, inspecting it to ensure that the equipment has not been tampered with and is functioning properly; + + + +k\) applying measures for secure disposal or re-use of equipment (see 7.14) if it is determined that equipment is to be disposed of. + + + +**Other information** + + + +Equipment includes technical components of information processing facilities, uninterruptible power supply (UPS) and batteries, power generators, power alternators and converters, physical intrusion detection systems and alarms, smoke detectors, fire extinguishers, air conditioning and lifts. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.14_OT Secure disposal or re-use of equipment.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.14_OT Secure disposal or re-use of equipment.md new file mode 100644 index 0000000..c3867ad --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.14_OT Secure disposal or re-use of equipment.md @@ -0,0 +1,85 @@ +## 7.14 Secure disposal or re-use of equipment + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|------------------------------------|---------------------------|----------------------------------------|---------------------------| + +| #Preventive | #Confidentiality | #Protect | #Physical_security #Asset_management | #Protection | + + + +**Control** + + + +Items of equipment containing storage media should be verified to ensure that any sensitive data and licensed software has been removed or securely overwritten prior to disposal or re-use. + + + +**Purpose** + + + +To prevent leakage of information from equipment to be disposed or re-used. **Guidance** + + + +Equipment should be verified to ensure whether or not storage media is contained prior to disposal or re-use. + + + +Storage media containing confidential or copyrighted information should be physically destroyed or the information should be destroyed, deleted or overwritten using techniques to make the original information non-retrievable rather than using the standard delete function. See 7.10for detailed guidance on secure disposal of storage media and 8.10for guidance on information deletion. + + + +Labels and markings identifying the organization or indicating the classification, owner, system or network, should be removed prior to disposal, including reselling or donating to charity. + + + +The organization should consider the removal of security controls such as access controls or surveillance equipment at the end of lease or when moving out of premises. This depends on factors such as: + + + +a\) its lease agreement to return the facility to original condition; + + + +b\) minimizing the risk of leaving systems with sensitive information on them for the next tenant (e.g. user access lists, video or image files); + + + +c\) the ability to reuse the controls at the next facility. + + + +**Other information** + + + +Damaged equipment containing storage media can require a risk assessment to determine whether the items should be physically destroyed rather than sent for repair or discarded. Information can be compromised through careless disposal or re-use of equipment. + + + +In addition to secure disk deletion, full-disk encryption reduces the risk of disclosure of confidential information when equipment is disposed of or redeployed, provided that: + + + +a\) the encryption process is sufficiently strong and covers the entire disk (including slack space, swap files); + + + +b\) the cryptographic keys are long enough to resist brute force attacks; + + + +c\) the cryptographic keys are themselves kept confidential (e.g. never stored on the same disk). For further advice on cryptography, see 8.24. + + + +Techniques for securely overwriting storage media differ according to the storage media technology and the classification level of the information on the storage media. Overwriting tools should be reviewed to make sure that they are applicable to the technology of the storage media. + + + +See ISO/IEC 27040 for detail on methods for sanitizing storage media. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.1_OT Physical security perimeters.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.1_OT Physical security perimeters.md new file mode 100644 index 0000000..216097e --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.1_OT Physical security perimeters.md @@ -0,0 +1,42 @@ + + +## 7.1 Physical security perimeters + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|-----------------------------------|---------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security | + +**Control** +Security perimeters should be defined and used to protect areas that contain information and other associated assets. + + + +**Purpose** +To prevent unauthorized physical access, damage and interference to the organization’s information and other associated assets. + + + +**Guidance** + + + +The following guidelines should be considered and implemented where appropriate for physical security perimeters: + + + +a\) defining security perimeters and the siting and strength of each of the perimeters in accordance with the information security requirements related to the assets within the perimeter; + + + +b\) having physically sound perimeters for a building or site containing information processing facilities (i.e. there should be no gaps in the perimeter or areas where a break-in can easily occur). The exterior roofs, walls, ceilings and flooring of the sit e should be of solid construction and all external doors should be suitably protected against unauthorized access with control mechanisms (e.g. bars, alarms, locks). Doors and windows should be locked when unattended and external protection should be considered for windows, particularly at ground level; ventilation points should also be considered; + + + +c\) alarming, monitoring and testing all fire doors on a security perimeter in conjunction with the walls to establish the required level of resistance in accordance with suitable standards. They should operate in a failsafe manner. + + + +**Other information** +Physical protection can be achieved by creating one or more physical barriers around the organization’s premises and information processing facilities. + +A secure area can be a lockable office or several rooms surrounded by a continuous internal physical security barrier. Additional barriers and perimeters to control physical access can be necessary between areas with different security requirements inside the security perimeter. The organization should consider having physical security measures that can be strengthened during increased threat situations. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.2_OT Physical entry.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.2_OT Physical entry.md new file mode 100644 index 0000000..dd0f9cc --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.2_OT Physical entry.md @@ -0,0 +1,151 @@ +## 7.2 Physical entry + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|-----------------------------------------|---------------------------|-----------------------------------------------------|---------------------| + +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Identity_and_Access + + + +**Control** + + + +Secure areas should be protected by appropriate entry controls and access points. + + + +**Purpose** + + + +To ensure only authorized physical access to the organization’s information and other associated assets occurs. + + + +**Guidance** + + + +General + + + +Access points such as delivery and loading areas and other points where unauthorized persons can enter the premises should be controlled and, if possible, isolated from information processing facilities to avoid unauthorized access. + + + +The following guidelines should be considered: + + + +a\) restricting access to sites and buildings to authorized personnel only. The process for the management of access rights to physical areas should include the provision, periodical review, update and revocation of authorizations (see 5.18); + + + +b\) securely maintaining and monitoring a physical logbook or electronic audit trail of all access and protecting all logs (see 5.33) and sensitive authentication information; + + + +c\) establishing and implementing a process and technical mechanisms for the management of access to areas where information is processed or stored. Authentication mechanisms include the use of access cards, biometrics or two-factor authentication such as an access card and secret PIN. Double security doors should be considered for access to sensitive areas; + + + +d\) setting up a reception area monitored by personnel, or other means to control physical access to the site or building; + + + +e\) inspecting and examining personal belongings of personnel and interested parties upon entry and exit; + + + +NOTE Local legislation and regulations can exist regarding the possibility of inspecting personal belongings. + + + +f\) requiring all personnel and interested parties to wear some form of visible identification and to immediately notify security personnel if they encounter unescorted visitors and anyone not wearing visible identification. Easily distinguishable badges should be considered to better identify permanent employees, suppliers and visitors; + + + +g\) granting supplier personnel restricted access to secure areas or information processing facilities only when required. This access should be authorized and monitored; + + + +h\) giving special attention to physical access security in the case of buildings holding assets for multiple organizations; + + + +i\) designing physical security measures so that they can be strengthened when the likelihood of physical incidents increases; + + + +j\) securing other entry points such as emergency exits from unauthorized access; + + + +k\) setting up a key management process to ensure the management of the physical keys or authentication information (e.g. lock codes, combination locks to offices, rooms and facilities such as key cabinets) and to ensure a log book or annual key audit and that access to physical keys or authentication information is controlled (see 5.17for further guidance on authentication information). + + + +Visitors + + + +The following guidelines should be considered: + + + +a\) authenticating the identity of visitors by an appropriate means; + + + +b\) recording the date and time of entry and departure of visitors; + + + +c\) only granting access for visitors for specific, authorized purposes and with instructions on the security requirements of the area and on emergency procedures; + + + +d\) supervising all visitors, unless an explicit exception is granted. Delivery and loading areas and incoming material + + + +The following guidelines should be considered: + + + +a\) restricting access to delivery and loading areas from outside of the building to identified and authorized personnel; + + + +b\) designing the delivery and loading areas so that deliveries can be loaded and unloaded without delivery personnel gaining unauthorized access to other parts of the building; + + + +c\) securing the external doors of delivery and loading areas when doors to restricted areas are opened; + + + +d\) inspecting and examining incoming deliveries for explosives, chemicals or other hazardous materials before they are moved from delivery and loading areas; + + + +e\) registering incoming deliveries in accordance with asset management procedures (see 5.9 and 7.10) on entry to the site; + + + +f\) physically segregating incoming and outgoing shipments, where possible; + + + +g\) inspecting incoming deliveries for evidence of tampering on the way. If tampering is discovered, it should be immediately reported to security personnel. + + + +**Other information** + +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.3_OT Securing offices, rooms and facilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.3_OT Securing offices, rooms and facilities.md new file mode 100644 index 0000000..3868b43 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.3_OT Securing offices, rooms and facilities.md @@ -0,0 +1,53 @@ + + +## 7.3 Securing offices, rooms and facilities + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|-----------------------------------------|---------------------------|--------------------------------------|---------------------| + +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security
#Asset_management | #Protection | + + + +**Control** + + + +Physical security for offices, rooms and facilities should be designed and implemented. **Purpose** + + + +To prevent unauthorized physical access, damage and interference to the organization’s information and other associated assets in offices, rooms and facilities. + + + +**Guidance** + + + +The following guidelines should be considered to secure offices, rooms and facilities: + + + +a\) siting critical facilities to avoid access by the public; + + + +b\) where applicable, ensuring buildings are unobtrusive and give minimum indication of their purpose, with no obvious signs, outside or inside the building, identifying the presence of information processing activities; + + + +c\) configuring facilities to prevent confidential information or activities from being visible and audible from the outside. Electromagnetic shielding should also be considered as appropriate; + + + +d\) not making directories, internal telephone books and online accessible maps identifying locations of confidential information processing facilities readily available to any unauthorized person. + + + +**Other information** + +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.4_OT Physical security monitoring.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.4_OT Physical security monitoring.md new file mode 100644 index 0000000..bec1efd --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.4_OT Physical security monitoring.md @@ -0,0 +1,85 @@ + + +## 7.4 Physical security monitoring + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|----------------------------|-----------------------------------------|---------------------------|-----------------------------|---------------------------| + +| #Preventive #Detective | #Confidentiality #Integrity #Availability | #Protect #Detect | #Physical_security | #Protection #Defence | + + + +**Control** + + + +Premises should be continuously monitored for unauthorized physical access. + + + +**Purpose** + + + +To detect and deter unauthorized physical access. + + + +**Guidance** + + + +Physical premises should be monitored by surveillance systems, which can include guards, intruder alarms, video monitoring systems such as closed-circuit television and physical security information management software either managed internally or by a monitoring service provider. + + + +Access to buildings that house critical systems should be continuously monitored to detect unauthorized access or suspicious behaviour by: + + + +a\) installing video monitoring systems such as closed-circuit television to view and record access to sensitive areas within and outside an organization’s premises; + + + +b\) installing, according to relevant applicable standards, and periodically testing contact, sound or motion detectors to trigger an intruder alarm such as: + + + +1\) installing contact detectors that trigger an alarm when a contact is made or broken in any place where a contact can be made or broken (such as windows and doors and underneath objects) to be used as a panic alarm; + + + +2\) motion detectors based on infra-red technology which trigger an alarm when an object passes through their field of view; + + + +3\) installing sensors sensitive to the sound of breaking glass which can be used to trigger an alarm to alert security personnel; + + + +c\) using those alarms to cover all external doors and accessible windows. Unoccupied areas should be alarmed at all times; cover should also be provided for other areas (e.g. computer or communications rooms). + + + +The design of monitoring systems should be kept confidential because disclosure can facilitate undetected break-ins. + + + +Monitoring systems should be protected from unauthorized access in order to prevent surveillance information, such as video feeds, from being accessed by unauthorized persons or systems being disabled remotely. + + + +The alarm system control panel should be placed in an alarmed zone and, for safety alarms, in a place that allows an easy exit route for the person who sets the alarm. The control panel and the detectors should have tamperproof mechanisms. The system should regularly be tested to ensure that it is working as intended, particularly if its components are battery powered. + + + +Any monitoring and recording mechanism should be used taking into consideration local laws and regulations including data protection and PII protection legislation, especially regarding the monitoring of personnel and recorded video retention periods. + + + +**Other information** + +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.5_OT Protecting against physical and environmental threats.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.5_OT Protecting against physical and environmental threats.md new file mode 100644 index 0000000..b20093b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.5_OT Protecting against physical and environmental threats.md @@ -0,0 +1,73 @@ +## 7.5 Protecting against physical and environmental threats + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|-----------------------------------------|---------------------------|-----------------------------|----------------------| + +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security | #Protection | + + + +**Control** + + + +Protection against physical and environmental threats, such as natural disasters and other intentional or unintentional physical threats to infrastructure should be designed and implemented. + + + +**Purpose** + + + +To prevent or reduce the consequences of events originating from physical and environmental threats. **Guidance** + + + +Risk as sessments to identify the potential consequences of physical and environmental threats should be performed prior to beginning critical operations at a physical site, and at regular intervals. Necessary safeguards should be implemented and changes to threats should be monitored. Specialist advice should be obtained on how to manage risks arising from physical and environ mental threats such as fire, flood, earthquake, explosion, civil unrest, toxic waste, environmental emissions and other forms of natural disaster or disaster caused by human beings. + + + +Physical premises location and construction should take account of: + + + +a\) local topography, such as appropriate elevation, bodies of water and tectonic fault lines; + + + +b\) urban threats, such as locations with a high profile for attracting political unrest, criminal activity or terrorist attacks. + + + +Based on risk assessment results, relevant physical and environmental threats should be identified and appropriate controls considered in the following contexts as examples: + + + +a\) fire: installing and configuring systems able to detect fires at an early stage to send alarms or trigger fire suppression systems in order to prevent fire damage to storage media and to related information processing systems. Fire suppression should be performed using the most appropriate substance with regard to the surrounding environment (e.g. gas in confined spaces); + + + +b\) flooding: installing systems able to detect flooding at an early stage under the floors of areas containing storage media or information processing systems. Water pumps or equivalent means should be readily made available in case flooding occurs; + + + +c\) electrical surges: adopting systems able to protect both server and client information systems against electrical surges or similar events to minimize the consequences of such events; + + + +d\) explosives and weapons: performing random inspections for the presence of explosives or weapons on personnel, vehicles or goods entering sensitive information processing facilities. + + + +**Other information** + + + +Safes or other forms of secure storage facilities can protect information stored therein against disasters such as a fire, earthquake, flood or explosion. + + + +Organizations can consider the concepts of crime prevention through environmental design when designing the controls to secure their environment and reduce urban threats. For example, instead of using bollards, statues or water features can serve as both a feature and a physical barrier. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.6_OT Working in secure areas.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.6_OT Working in secure areas.md new file mode 100644 index 0000000..4cc388d --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.6_OT Working in secure areas.md @@ -0,0 +1,65 @@ +## 7.6 Working in secure areas + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|-----------------------------------------|---------------------------|-----------------------------|----------------------| + +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security | #Protection | + + + +**Control** + + + +Security measures for working in secure areas should be designed and implemented. + +**Purpose** + + + +To protect information and other associated assets in secure areas from damage and unauthorized interference by personnel working in these areas. + + + +**Guidance** + + + +The security measures for working in secure areas should apply to all personnel and cover all activities taking place in the secure area. + + + +The following guidelines should be considered: + + + +a\) making personnel aware only of the existence of, or activities within, a secure area on a need-to-know basis; + + + +b\) avoiding unsupervised work in secure areas both for safety reasons and to reduce chances for malicious activities; + + + +c\) physically locking and periodically inspecting vacant secure areas; + + + +d\) not allowing photographic, video, audio or other recording equipment, such as cameras in user endpoint devices, unless authorized; + + + +e\) appropriately controlling the carrying and use of user endpoint devices in secure areas; + + + +f\) posting emergency procedures in a readily visible or accessible manner. + + + +**Other information** + +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.7_OT Clear desk and clear screen.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.7_OT Clear desk and clear screen.md new file mode 100644 index 0000000..04aa36a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.7_OT Clear desk and clear screen.md @@ -0,0 +1,73 @@ +## 7.7 Clear desk and clear screen + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|------------------------------------|---------------------------|-----------------------------|----------------------| + +| #Preventive | #Confidentiality | #Protect | #Physical_security | #Protection | + +**Control** + + + +Clear desk rules for papers and removable storage media and clear screen rules for information processing facilities should be defined and appropriately enforced. + + + +**Purpose** + + + +To reduce the risks of unauthorized access, loss of and damage to information on desks, screens and in other accessible locations during and outside normal working hours. + + + +**Guidance** + + + +The organization should establish and communicate a topic-specific policy on clear desk and clear screen to all relevant interested parties. + + + +The following guidelines should be considered: + + + +a\) locking away sensitive or critical business information (e.g. on paper or on electronic storage media) (ideally in a safe, cabinet or other form of security furniture) when not required, especially when the office is vacated; + + + +b\) protecting user endpoint devices by key locks or other security means when not in use or unattended; + + + +c\) leaving user endpoint devices logged off or protected with a screen and keyboard locking mechanism controlled by a user authentication mechanism when unattended. All computers and systems should be configured with a timeout or automatic logout feature ; + + + +d\) making the originator collect outputs from printers or multi-function devices immediately. The use of printers with an authent ication function, so the originators are the only ones who can get their printouts and only when standing next to the printer; + + + +e\) securely storing documents and removable storage media containing sensitive information and, when no longer required, discarding them using secure disposal mechanisms; + + + +f\) establishing and communicating rules and guidance for the configuration of pop-ups on screens (e.g. turning off the new email and messaging pop-ups, if possible, during presentations, screen sharing or in a public area); + + + +g\) clearing sensitive or critical information on whiteboards and other types of display when no longer required. + + + +The organization should have procedures in place when vacating facilities including conducting a final sweep prior to leaving to ensure the organization’s assets are not left behind (e.g. documents fallen behind drawers or furniture). + + + +**Other information** + +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.8_OT Equipment siting and protection.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.8_OT Equipment siting and protection.md new file mode 100644 index 0000000..0f5874a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.8_OT Equipment siting and protection.md @@ -0,0 +1,75 @@ +## 7.8 Equipment siting and protection + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|-----------------------------------------|---------------------------|----------------------------------------|---------------------| + +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Asset_management | #Protection | + + + +**Control** + + + +Equipment should be sited securely and protected. + + + +**Purpose** + + + +To reduce the risks from physical and environmental threats, and from unauthorized access and damage. + + + +**Guidance** + + + +The following guidelines should be considered to protect equipment: + + + +a\) siting equipment to minimize unnecessary access into work areas and to avoid unauthorized access; + + + +b\) carefully positioning information processing facilities handling sensitive data to reduce the risk of information being viewed by unauthorized persons during their use; + + + +c\) adopting controls to minimize the risk of potential physical and environmental threats \[e.g. theft, fire, explosives, smoke, water (or water supply failure), dust, vibration, chemical effects, electrical supply interference, communications interference, electromagnetic radiation and vandalism\]; + + + +d\) establishing guidelines for eating, drinking and smoking in proximity to information processing facilities; + + + +e\) monitoring environmental conditions, such as temperature and humidity, for conditions which can adversely affect the operation of information processing facilities; + + + +f\) applying lightning protection to all buildings and fitting lightning protection filters to all incoming power and communications lines; + + + +g\) considering the use of special protection methods, such as keyboard membranes, for equipment in industrial environments; + + + +h\) protecting equipment processing confidential information to minimize the risk of information leakage due to electromagnetic emanation; + + + +i\) physically separating information processing facilities managed by the organization from those not managed by the organization. + + + +**Other information** + +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.9_OT Security of assets off-premises.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.9_OT Security of assets off-premises.md new file mode 100644 index 0000000..8b12d69 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.9_OT Security of assets off-premises.md @@ -0,0 +1,83 @@ +## 7.9 Security of assets off-premises + + + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | + +|------------------|-----------------------------------------|---------------------------|----------------------------------------|---------------------| + +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Asset_management | #Protection | + +**Control** + + + +Off-site assets should be protected. **Purpose** + + + +To prevent loss, damage, theft or compromise of off-site devices and interruption to the organization’s operations. + + + +**Guidance** + + + +Any device used outside the organization’s premises which stores or processes information (e.g. mobile device), including devices owned by the organization and devices owned privately and used on behalf of the organization \[bring your own device (BYOD)\] needs protection. The use of these devices should be authorized by management. + + + +The following guidelines should be considered for the protection of devices which store or process information outside the organization’s premises: + + + +a\) not leaving equipment and storage media taken off premises unattended in public and unsecured places; + + + +b\) observing manufacturers’ instructions for protecting equipment at all times (e.g. protection against exposure to strong electromagnetic fields, water, heat, humidity, dust); + + + +c\) when off-premises equipment is transferred among different individuals or interested parties, maintaining a log that defines the chain of custody for the equipment including at least names and organizations of those who are responsible for the equipment. Information that does not need to be transferred with the asset should be securely deleted before the transfer; + + + +d\) where necessary and practical, requiring authorization for equipment and media to be removed from the organization’s premises and keeping a record of such removals in order to maintain an audit trail (see 5.14); + + + +e\) protecting against viewing information on a device (e.g. mobile or laptop) on public transport, and the risks associated with shoulder surfing; + + + +f\) implementing location tracking and ability for remote wiping of devices. + + + +Permanent installation of equipment outside the organization’s premises \[such as antennas and automated teller machines (ATMs)\] can be subject to higher risk of damage, theft or eavesdropping. These risks can vary considerably between locations and should be taken into account in determining the most appropriate measures. The following guidelines should be considered when siting this equipment outside of the organization’s premises: + + + +a\) physical security monitoring (see 7.4); + + + +b\) protecting against physical and environmental threats (see 7.5); + + + +c\) physical access and tamper proofing controls; + + + +d\) logical access controls. + + + +**Other information** + + + +More information about other aspects of protecting information storing and processing equipment and user endpoint devices can be found in 8.1and 6.7. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.10_OT Information deletion.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.10_OT Information deletion.md new file mode 100644 index 0000000..edf72c5 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.10_OT Information deletion.md @@ -0,0 +1,52 @@ +## 8.10 Information deletion + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +| ---------------- | ----------------------------------- | -------------------------- | --------------------------------------------- | -------------------- | +| #Preventive | #Confidentiality | #Protect | #Information_protection #Legal_and_compliance | #Protection | + +**Control** +Information stored in information systems, devices or in any other storage media should be deleted when no longer required. + +**Purpose** +To prevent unnecessary exposure of sensitive information and to comply with legal, statutory, regulatory and contractual requirements for information deletion. + +**Guidance** + +General +Sensitive information should not be kept for longer than it is required to reduce the risk of undesirable disclosure. + +When deleting information on systems, applications and services, the following should be considered: + +a\) selecting a deletion method (e.g. electronic overwriting or cryptographic erasure) in accordance with business requirements and taking into consideration relevant laws and regulations; + +b\) recording the results of deletion as evidence; + +c\) when using service suppliers of information deletion, obtaining evidence of information deletion from them. + +Where third parties store the organization’s information on its behalf, the organization should consider the inclusion of requirements on information deletion into the third-party agreements to enforce it during and upon termination of such services. + +Deletion methods +In accordance with the organization’s topic-specific policy on data retention and taking into consideration relevant legislation and regulations, sensitive information should be deleted when no longer required, by: + +a\) configuring systems to securely destroy information when no longer required (e.g. after a defined period subject to the topic-specific policy on data retention or by subject access request); + +b\) deleting obsolete versions, copies and temporary files wherever they are located; + +c\) using approved, secure deletion software to permanently delete information to help ensure information cannot be recovered by using specialist recovery or forensic tools; + +d\) using approved, certified providers of secure disposal services; + +e\) using disposal mechanisms appropriate for the type of storage media being disposed of (e.g. degaussing hard disk drives and other magnetic storage media). + +Where cloud services are used, the organization should verify if the deletion method provided by the cloud service provider is acceptable, and if it is the case, the organization should use it, or request that the cloud service provider delete the information. These deletion processes should be automated in accordance with topic-specific policies, when available and applicable. Depending on the sensitivity of information deleted, logs can track or verify that these deletion processes have happened. + +To avoid the unintentional exposure of sensitive information when equipment is being sent back to vendors, sensitive information should be protected by removing auxiliary storages (e.g. hard disk drives) and memory before equipment leaves the organization’s premises. + +Considering that the secure deletion of some devices (e.g. smartphones) can only be achieved through destruction or using the functions embedded in these devices (e.g. “restore factory settings”), the organization should choose the appropriate method according to the classification of information handled by such devices. + +Control measures described in 7.14 should be applied to physically destroy the storage device and simultaneously delete the information it contains. + +An official record of information deletion is useful when analysing the cause of a possible information leakage event. + +**Other information** +Information on user data deletion in cloud services can be found in ISO/IEC 27017. Information on deletion of PII can be found in ISO/IEC 27555. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.11_OT Data masking.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.11_OT Data masking.md new file mode 100644 index 0000000..a09772a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.11_OT Data masking.md @@ -0,0 +1,58 @@ +## 8.11 Data masking + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +| ---------------- | ----------------------------------- | -------------------------- | ---------------------------- | -------------------- | +| #Preventive | #Confidentiality | #Protect | #Information_protection | #Protection | + +**Control** +Data masking should be used in accordance with the organization’s topic-specific policy on access control and other related topic-specific policies, and business requirements, taking applicable legislation into consideration. + +**Purpose** +To limit the exposure of sensitive data including PII, and to comply with legal, statutory, regulatory and contractual requirements. + +**Guidance** +Where the protection of sensitive data (e.g. PII) is a concern, the organization should consider hiding such data by using techniques such as data masking, pseudonymization or anonymization. + +Pseudonymization or anonymization techniques can hide PII, disguise the true identity of PII principals or other sensitive information, and disconnect the link between PII and the identity of the PII principal or the link between other sensitive information. + +When using pseudonymization or anonymization techniques, it should be verified that data has been adequately pseudonymized or anonymized. Data anonymization should consider all the elements of the sensitive information to be effective. As an example, if not considered properly, a person can be identified even if the data that can directly identify that person is anonymised, by the presence of further data which allows the person to be identified indirectly. + +Additional techniques for data masking include: + +a\) encryption (requiring authorized users to have a key); +b\) nulling or deleting characters (preventing unauthorized users from seeing full messages); +c\) varying numbers and dates; +d\) substitution (changing one value for another to hide sensitive data); +e\) replacing values with their hash. + +The following should be considered when implementing data masking techniques: + +a\) not granting all users access to all data, therefore designing queries and masks in order to show only the minimum required data to the user; +b\) there are cases where some data should not be visible to the user for some records out of a set of data; in this case, designing and implementing a mechanism for obfuscation of data (e.g. if a patient does not want hospital staff to be able to see all of their records, even in case of emergency, then the hospital staff are presented with partially obfuscated data and data can only be accessed by staff with specific roles if it contains useful information for appropriate treatment); +c\) when data are obfuscated, giving the PII principal the possibility to require that users cannot see if the data are obfuscated (obfuscation of the obfuscation; this is used in health facilities, for example if the patient does not want personnel to see that sensitive information such as pregnancies or results of blood exams has been obfuscated); +d\) any legal or regulatory requirements (e.g. requiring the masking of payment cards' information during processing or storage). + +The following should be considered when using data masking, pseudonymization or anonymization: + +a\) level of strength of data masking, pseudonymization or anonymization according to the usage of the processed data; +b\) access controls to the processed data; +c\) agreements or restrictions on usage of the processed data; +d\) prohibiting collating the processed data with other information in order to identify the PII principal; +e\) keeping track of providing and receiving the processed data. + +**Other information** +Anonymization irreversibly alters PII in such a way that the PII principal can no longer be identified directly or indirectly. + +Pseudonymization replaces the identifying information with an alias. Knowledge of the algorithm (sometimes referred to as the “additional information”) used to perform the pseudonymization allows for at least some form of identification of the PII principal. Such “additional information” should therefore be kept separate and protected. + +While pseudonymization is therefore weaker than anonymization, pseudonymized datasets can be more useful in statistical research. + +Data masking is a set of techniques to conceal, substitute or obfuscate sensitive data items. Data masking can be static (when data items are masked in the original database), dynamic (using automation and rules to secure data in real-time) or on-the-fly (with data masked in an application’s memory). + +Hash functions can be used in order to anonymize PII. In order to prevent enumeration attacks, they should always be combined with a salt function. + +PII in resource identifiers and their attributes \[e.g. file names, uniform resource locators (URLs)\] should be either avoided or appropriately anonymized. + +Additional controls concerning the protection of PII in public clouds are given in ISO/IEC 27018. + +Additional information on de-identification techniques is available in ISO/IEC 20889. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.12_OT Data leakage prevention.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.12_OT Data leakage prevention.md new file mode 100644 index 0000000..ec2d2c2 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.12_OT Data leakage prevention.md @@ -0,0 +1,41 @@ +## 8.12 Data leakage prevention + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +| ---------------------- | ----------------------------------- | -------------------------- | ---------------------------- | -------------------- | +| #Preventive #Detective | #Confidentiality | #Protect #Detect | #Information_protection | #Protection #Defence | + +**Control** +Data leakage prevention measures should be applied to systems, networks and any other devices that process, store or transmit sensitive information. + +**Purpose** +To detect and prevent the unauthorized disclosure and extraction of information by individuals or systems. + +**Guidance** +The organization should consider the following to reduce the risk of data leakage: + +a\) identifying and classifying information to protect against leakage (e.g. personal information, pricing models and product designs); +b\) monitoring channels of data leakage (e.g. email, file transfers, mobile devices and portable storage devices); +c\) acting to prevent information from leaking (e.g. quarantine emails containing sensitive information). + +Data leakage prevention tools should be used to: + +a\) identify and monitor sensitive information at risk of unauthorized disclosure (e.g. in unstructured data on a user’s system); +b\) detect the disclosure of sensitive information (e.g. when information is uploaded to untrusted third-party cloud services or sent via email); +c\) block user actions or network transmissions that expose sensitive information (e.g. preventing the copying of database entries into a spreadsheet). + +The organization should determine if it is necessary to restrict a user’s ability to copy and paste or upload data to services, devices and storage media outside of the organization. If that is the case, the organization should implement technology such as data leakage prevention tools or the configuration of existing tools that allow users to view and manipulate data held remotely but prevent copy and paste outside of the organization’s control. + +If data export is required, the data owner should be allowed to approve the export and hold users accountable for their actions. + +Taking screenshots or photographs of the screen should be addressed through terms and conditions of use, training and auditing. + +Where data is backed up, care should be taken to ensure sensitive information is protected using measures such as encryption, access control and physical protection of the storage media holding the backup. + +Data leakage prevention should also be considered to protect against the intelligence actions of an adversary from obtaining confidential or secret information (geopolitical, human, financial, commercial, scientific or any other) which can be of interest for espionage or can be critical for the community. The data le akage prevention actions should be oriented to confuse the adversary’s decisions for example by replacing authentic information with false information, either as an independent action or as response to the adversary’s intelligence actions. Examples of these kinds of actions are reverse social engineering or the use of honeypots to attract attackers. + +**Other information** +Data leakage prevention tools are designed to identify data, monitor data usage and movement, and take actions to prevent data from leaking (e.g. alerting users to their risky behaviour and blocking the transfer of data to portable storage devices). + +Data leakage prevention inherently involves monitoring personnel’s communications and online activities, and by extension external party messages, which raises legal concerns that should be considered prior to deploying data leakage prevention tools. There is a variety of legislation relating to privacy, data protection, employment, interception of data and telecommunications that is applicable to monitoring and data processing in the context of data leakage prevention. + +Data leakage prevention can be supported by standard security controls, such as topic-specific policies on access control and secure document management (see >5.12 and >5.15>). \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.13_OT Information backup.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.13_OT Information backup.md new file mode 100644 index 0000000..32ffcac --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.13_OT Information backup.md @@ -0,0 +1,46 @@ +#iso27002/2022/EN +## 8.13 Information backup + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ------------------------------- | ---------------------- | ------------------------ | ---------------- | +| #Corrective | #Integrity #Availability | #Recover | #Continuity | #Protection | + +**Control** +Backup copies of information, software and systems should be maintained and regularly tested in accordance with the agreed topic-specific policy on backup. + +**Purpose** +To enable recovery from loss of data or systems. + +**Guidance** +A topic-specific policy on backup should be established to address the organization’s data retention and information security requirements. + +Adequate backup facilities should be provided to ensure that all essential information and software can be recovered following an incident or failure or loss of storage media. + +Plans should be developed and implemented for how the organization will back up information, software and systems, to address the topic-specific policy on backup. + +When designing a backup plan, the following items should be taken into consideration: + +a\) producing accurate and complete records of the backup copies and documented restoration procedures; + +b\) reflecting the business requirements of the organization (e.g. the recovery point objective, see >5.30>), the security requirements of the information involved and the criticality of the information to the continued operation of the organization in the extent (e.g. full or differential backup) and frequency of backups; + +c\) storing the backups in a safe and secure remote location, at a sufficient distance to escape any damage from a disaster at the main site; + +d\) giving backup information an appropriate level of physical and environmental protection (see >Clause 7and >8.1>) consistent with the standards applied at the main site; + +e\) regularly testing backup media to ensure that they can be relied on for emergency use when necessary. Testing the ability to restore backed-up data onto a test system, not by overwriting the original storage media in case the backup or restoration process fails and causes irreparable data damage or loss; + +f\) protecting backups by means of encryption according to the identified risks (e.g. in situations where confidentiality is of importance); + +g\) taking care to ensure that inadvertent data loss is detected before backup is taken. + +Operational procedures should monitor the execution of backups and address failures of scheduled backups to ensure completeness of backups according to the topic-specific policy on backups. + +Backup measures for individual systems and services should be regularly tested to ensure that they meet the objectives of incident response and business continuity plans (see 5.30). This should be combined with a test of the restoration procedures and checked against the restoration time required by the business continuity plan. In the case of critical systems and services, backup measures should cover all systems information, applications and data necessary to recover the complete system in the event of a disaster. + +When the organization uses a cloud service, backup copies of the organization’s information, applications and systems in the cloud service environment should be taken. The organization should determine if and how requirements for backup are fulfilled when using the information backup service provided as part of the cloud service. + +The retention period for essential business information should be determined, taking into account any requirement for retention of archive copies. The organization should consider the deletion of information (see 8.10) in storage media used for backup once the information’s retention period expires and should take into consideration legislation and regulations. + +**Other information** +For further information on storage security including retention consideration, see ISO/IEC 27040. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.14_OT Redundancy of information processing facilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.14_OT Redundancy of information processing facilities.md new file mode 100644 index 0000000..51c3d76 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.14_OT Redundancy of information processing facilities.md @@ -0,0 +1,40 @@ +## 8.14 Redundancy of information processing facilities + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ------------------------------- | ---------------------- | ----------------------------- | ----------------------- | +| #Preventive | #Availability | #Protect | #Continuity #Asset_management | #Protection #Resilience | + +**Control** +Information processing facilities should be implemented with redundancy sufficient to meet availability requirements. + +**Purpose** +To ensure the continuous operation of information processing facilities. + +**Guidance** +The organization should identify requirements for the availability of business services and information systems. The organization should design and implement systems architecture with appropriate redundancy to meet these requirements. + +Redundancy can be introduced by duplicating information processing facilities in part or in their entirety (i.e. spare components or having two of everything). The organization should plan and implement procedures for the activation of the redundant components and processing facilities. The procedures should establish if the redundant components and processing activities are always activated, or in case of emergency, automatically or manually activated. The redundant components and information processing facilities should ensure the same security level as the primary ones. + +Mechanisms should be in place to alert the organization to any failure in the information processing facilities, enable executing the planned procedure and allow continued availability while the information processing facilities are repaired or replaced. + +The organization should consider the following when implementing redundant systems: + +a\) contracting with two or more suppliers of network and critical information processing facilities such as internet service providers; +b\) using redundant networks; +c\) using two geographically separate data centres with mirrored systems; +d\) using physically redundant power supplies or sources; +e\) using multiple parallel instances of software components, with automatic load balancing between them (between instances in the same data centre or in different data centres); +f\) having duplicated components in systems (e.g. CPU, hard disks, memories) or in networks (e.g. firewalls, routers, switches). + +Where applicable, preferably in production mode, redundant information systems should be tested to ensure the failover from one component to another component works as intended. + +**Other information** +There is a strong relationship between redundancy and ICT readiness for business continuity (see 5.30) especially if short recovery times are required. Many of the redundancy measures can be part of the ICT continuity strategies and solutions. + +The implementation of redundancies can introduce risks to the integrity (e.g. processes of copying data to duplicated components can introduce errors) or confidentiality (e.g. weak security control of duplicated components can lead to compromise) of information and information systems, which need to be considered when designing information systems. + +Redundancy in information processing facilities does not usually address application unavailability due to faults within an application. + +With the use of public cloud computing, it is possible to have multiple live versions of information processing facilities, existing in multiple separate physical locations with automatic failover and load balancing between them. + +Some of the technologies and techniques for providing redundancy and automatic fail-over in the context of cloud services are discussed in ISO/IEC TS 23167. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.15_OT Logging.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.15_OT Logging.md new file mode 100644 index 0000000..1aded33 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.15_OT Logging.md @@ -0,0 +1,95 @@ +#iso27002/2022/EN + +## 8.15 Logging + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +| ---------------- | ----------------------------------------- | -------------------------- | -------------------------------------- | -------------------- | +| #Detective | #Confidentiality #Integrity #Availability | #Detect | #Information_security_event_management | #Protection #Defence | + +**Control** +Logs that record activities, exceptions, faults and other relevant events should be produced, stored, protected and analysed. + +**Purpose** +To record events, generate evidence, ensure the integrity of log information, prevent against unauthorized access, identify information security events that can lead to an information security incident and to support investigations. + +**Guidance** + +General + +The organization should determine the purpose for which logs are created, what data is collected and logged, and any log-specific requirements for protecting and handling the log data. This should be documented in a topic-specific policy on logging. + +Event logs should include for each event, as applicable: +a\) user IDs; +b\) system activities; +c\) dates, times and details of relevant events (e.g. log-on and log-off); +d\) device identity, system identifier and location; +e\) network addresses and protocols. + +The following events should be considered for logging: + +a\) successful and rejected system access attempts; +b\) successful and rejected data and other resource access attempts; +c\) changes to system configuration; +d\) use of privileges; +e\) use of utility programs and applications; +f\) files accessed and the type of access, including deletion of important data files; +g\) alarms raised by the access control system; +h\) activation and de-activation of security systems, such as anti-virus systems and intrusion detection systems; +i\) creation, modification or deletion of identities; +j\) transactions executed by users in applications. In some cases, the applications are a service or product provided or run by a third party. + +It is important for all systems to have synchronized time sources (see 8.17) as this allows for correlation of logs between systems for analysis, alerting and investigation of an incident. + +Protection of logs + +Users, including those with privileged access rights, should not have permission to delete or de-activate logs of their own activities. They can potentially manipulate the logs on information processing facilities under their direct control. Therefore, it is necessary to protect and review the logs to maintain accountability for the privileged users. + +Controls should aim to protect against unauthorized changes to log information and operational problems with the logging facility including: + +a\) alterations to the message types that are recorded; +b\) log files being edited or deleted; +c\) failure to record events or over-writing of past recorded events if the storage media holding a log file is exceeded. + +For protection of logs, the use of the following techniques should be considered: cryptographic hashing, recording in an append-only and read-only file, recording in a public transparency file. + +Some audit logs can be required to be archived because of requirements on data retention or requirements to collect and retain evidence (see 5.28). + +Where the organization needs to send system or application logs to a vendor to assist with debugging or troubleshooting errors, logs should be de-identified where possible using data masking techniques (see 8.11) for information such as usernames, internet protocol (IP) addresses, hostnames or organization name, before sending to the vendor. + +Event logs can contain sensitive data and personally identifiable information. Appropriate privacy protection measures should be taken (see 5.34). + +Log analysis + +Log analysis should cover the analysis and interpretation of information security events, to help identify unusual activity or anomalous behaviour, which can represent indicators of compromise. + +Analysis of events should be performed by taking into account: + +a\) the necessary skills for the experts performing the analysis; +b\) determining the procedure of log analysis; +c\) the required attributes of each security-related event; +d\) exceptions identified through the use of predetermined rules \[e.g. security information and event management (SIEM) or firewall rules, and intrusion detection systems (IDSs) or malware signatures\]; +e\) known behaviour patterns and standard network traffic compared to anomalous activity and behaviour \[user and entity behaviour analytics (UEBA)\]; +f\) results of trend or pattern analysis (e.g. as a result of using data analytics, big data techniques and specialized analysis tools); +g\) available threat intelligence. + +Log analysis should be supported by specific monitoring activities to help identify and analyse anomalous behaviour, which includes: + +a\) reviewing successful and unsuccessful attempts to access protected resources \[e.g. domain name system (DNS) servers, web portals and file shares\]; +b\) checking DNS logs to identify outbound network connections to malicious servers, such as those associated with botnet command and control servers; +c\) examining usage reports from service providers (e.g. invoices or service reports) for unusual activity within systems and networks (e.g. by reviewing patterns of activity); +d\) including event logs of physical monitoring such as entrance and exit to ensure more accurate detection and incident analysis; +e\) correlating logs to enable efficient and highly accurate analysis. + +Suspected and actual information security incidents should be identified (e.g. malware infection or probing of firewalls) and be subject to further investigation (e.g. as part of an information security incident management process, see >5.25>). + +**Other information** + +System logs often contain a large volume of information, much of which is extraneous to information security monitoring. To help identify significant events for information security monitoring purposes, the use of suitable utility programs or audit tools to perform file interrogation can be considered. + +Event logging sets the foundation for automated monitoring systems (see 8.16) which are capable of generating consolidated reports and alerts on system security. + +A SIEM tool or equivalent service can be used to store, correlate, normalize and analyse log information, and to generate alerts. SIEMs tend to require careful configuration to optimize their benefits. Configurations to consider include identification and selection of appropriate log sources, tuning and testing of rules and development of use cases. + +Public transparency files for the recording of logs are used, for example, in certificate transparency systems. Such files can provide an additional detection mechanism useful for guarding against log tampering. + +In cloud environments, log management responsibilities can be shared between the cloud service customer and the cloud service provider. Responsibilities vary depending on the type of cloud service being used. Further guidance can be found in ISO/IEC 27017. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.16_OT Monitoring activities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.16_OT Monitoring activities.md new file mode 100644 index 0000000..7652657 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.16_OT Monitoring activities.md @@ -0,0 +1,84 @@ +#iso27002/2022/EN +## 8.16 Monitoring activities + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +| ---------------------- | ----------------------------------------- | -------------------------- | -------------------------------------- | -------------------- | +| #Detective #Corrective | #Confidentiality #Integrity #Availability | #Detect #Respond | #Information_security_event_management | #Defence | + + +**Control** +Networks, systems and applications should be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents. + +**Purpose** +To detect anomalous behaviour and potential information security incidents. + +**Guidance** +The monitoring scope and level should be determined in accordance with business and information security requirements and taking into consideration relevant laws and regulations. Monitoring records should be maintained for defined retention periods. + +The following should be considered for inclusion within the monitoring system: + +a\) outbound and inbound network, system and application traffic; + +b\) access to systems, servers, networking equipment, monitoring system, critical applications, etc.; + +c\) critical or admin level system and network configuration files; + +d\) logs from security tools \[e.g. antivirus, IDS, intrusion prevention system (IPS), web filters, firewalls, data leakage prevention\]; + +e\) event logs relating to system and network activity; + +f\) checking that the code being executed is authorized to run in the system and that it has not been tampered with (e.g. by recompilation to add additional unwanted code); + +g\) use of the resources (e.g. CPU, hard disks, memory, bandwidth) and their performance. + +The organization should establish a baseline of normal behaviour and monitor against this baseline for anomalies. When establishing a baseline, the following should be considered: + +a\) reviewing utilization of systems at normal and peak periods; + +b\) usual time of access, location of access, frequency of access for each user or group of users. + +The monitoring system should be configured against the established baseline to identify anomalous behaviour, such as: + +a\) unplanned termination of processes or applications; + +b\) activity typically associated with malware or traffic originating from known malicious IP addresses or network domains (e.g. those associated with botnet command and control servers); + +c\) known attack characteristics (e.g. denial of service and buffer overflows); + +d\) unusual system behaviour (e.g. keystroke logging, process injection and deviations in use of standard protocols); + +e\) bottlenecks and overloads (e.g. network queuing, latency levels and network jitter); + +f\) unauthorized access (actual or attempted) to systems or information; + +g\) unauthorized scanning of business applications, systems and networks; + +h\) successful and unsuccessful attempts to access protected resources (e.g. DNS servers, web portals and file systems); + +i\) unusual user and system behaviour in relation to expected behaviour. + +Continuous monitoring via a monitoring tool should be used. Monitoring should be done in real time or in periodic intervals, subject to organizational need and capabilities. Monitoring tools should include the ability to handle large amounts of data, adapt to a constantly changing threat landscape, and allow for real-time notification. The tools should also be able to recognize specific signatures and data or network or application behaviour patterns. + +Automated monitoring software should be configured to generate alerts (e.g. via management consoles, email messages or instant messaging systems) based on predefined thresholds. The alerting system should be tuned and trained on the organization’s baseline to minimize false positives. Personnel should be dedicated to respond to alerts and should be properly trained to accurately interpret potential incidents. There should be redundant systems and processes in place to receive and respond to alert notifications. + +Abnormal events should be communicated to relevant parties in order to improve the following activities: auditing, security evaluation, vulnerability scanning and monitoring (see 5.25). Procedures should be in place to respond to positive indicators from the monitoring system in a timely manner, in order to minimize the effect of adverse events (see 5.26) on information security. Procedures should also be established to identify and address false positives including tuning the monitoring software to reduce the number of future false positives. + + **Other information** + +Security monitoring can be enhanced by: + +a\) leveraging threat intelligence systems (see 5.7); + +b\) leveraging machine learning and artificial intelligence capabilities; + +c\) using blocklists or allowlists; + +d\) undertaking a range of technical security assessments (e.g. vulnerability assessments, penetration testing, cyber-attack simulations and cyber response exercises), and using the results of these assessments to help determine baselines or acceptable behaviour; + +e\) using performance monitoring systems to help establish and detect anomalous behaviour; + +f\) leveraging logs in combination with monitoring systems. + +Monitoring activities are often conducted using specialist software, such as intrusion detection systems. These can be configured to a baseline of normal, acceptable and expected system and network activities. + +Monitoring for anomalous communications helps in the identification of botnets (i.e. set of devices under the malicious control of the botnet owner, usually used for mounting distributed denial of service attacks on other computers of other organizations). If the computer is being controlled by an external device, there is a communication between the infected device and the controller. The organization should therefore employ technologies to monitor for anomalous communications and take such action as necessary. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.17_OT Clock synchronization.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.17_OT Clock synchronization.md new file mode 100644 index 0000000..7b5e866 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.17_OT Clock synchronization.md @@ -0,0 +1,23 @@ +## 8.17 Clock synchronization + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +| ---------------- | ----------------------------------- | -------------------------- | -------------------------------------- | -------------------- | +| #Detective | #Integrity | #Protect #Detect | #Information_security_event_management | #Protection #Defence | + +**Control** +The clocks of information processing systems used by the organization should be synchronized to approved time sources. + +**Purpose** +To enable the correlation and analysis of security-related events and other recorded data, and to support investigations into information security incidents. + +**Guidance** +External and internal requirements for time representation, reliable synchronization and accuracy should be documented and implemented. Such requirements can be from legal, statutory, regulatory, contractual, standards and internal monitoring needs. A standard reference time for use within the organization should be defined and considered for all systems, including building management systems, entry and exit systems and others that can be used to aid investigations. + +A clock linked to a radio time broadcast from a national atomic clock or global positioning system (GPS) should be used as the reference clock for logging systems; a consistent, trusted date and time source to ensure accurate time-stamps. Protocols such as network time protocol (NTP) or precision time protocol (PTP) should be used to keep all networked systems in synchronization with a reference clock. + +The organization can use two external time sources at the same time in order to improve the reliability of external clocks, and appropriately manage any variance. + +Clock synchronization can be difficult when using multiple cloud services or when using both cloud and on-premises services. In this case, the clock of each service should be monitored and the difference recorded in order to mitigate risks arising from discrepancies. + +**Other information** +The correct setting of computer clocks is important to ensure the accuracy of event logs, which can be required for investi gations or as evidence in legal and disciplinary cases. Inaccurate audit logs can hinder such investigations and damage the credibility of such evidence. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.18_OT Use of privileged utility programs.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.18_OT Use of privileged utility programs.md new file mode 100644 index 0000000..133d7d1 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.18_OT Use of privileged utility programs.md @@ -0,0 +1,36 @@ +## 8.18 Use of privileged utility programs + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------------------------------------------------------ | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security #Secure_configuration #Application_security | #Protection | + +**Control** +The use of utility programs that can be capable of overriding system and application controls should be restricted and tightly controlled. + +**Purpose** +To ensure the use of utility programs does not harm system and application controls for information security. + +**Guidance** +The following guidelines for the use of utility programs that can be capable of overriding system and application controls should be considered: + +a\) limitation of the use of utility programs to the minimum practical number of trusted, authorized users (see 8.2); + +b\) use of identification, authentication and authorization procedures for utility programs, including unique identification of the person who uses the utility program; + +c\) defining and documenting of authorization levels for utility programs; + +d\) authorization for ad hoc use of utility programs; + +e\) not making utility programs available to users who have access to applications on systems where segregation of duties is required; + +f\) removing or disabling all unnecessary utility programs; + +g\) at a minimum, logical segregation of utility programs from application software. Where practical, segregating network communications for such programs from application traffic; + +h\) limitation of the availability of utility programs (e.g. for the duration of an authorized change); + +i\) logging of all use of utility programs. + +**Other information** + +Most information systems have one or more utility programs that can be capable of overriding system and application controls, for example diagnostics, patching, antivirus, disk defragmenters, debuggers, backup and network tools. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.19_OT Installation of software on operational systems.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.19_OT Installation of software on operational systems.md new file mode 100644 index 0000000..ab42190 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.19_OT Installation of software on operational systems.md @@ -0,0 +1,46 @@ +#iso27002/2022/EN +## 8.19 Installation of software on operational systems + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Secure_configuration #Application_security | #Protection | + +**Control** +Procedures and measures should be implemented to securely manage software installation on operational systems. + +**Purpose** +To ensure the integrity of operational systems and prevent exploitation of technical vulnerabilities. + +**Guidance** +The following guidelines should be considered to securely manage changes and installation of software on operational systems: + +a\) performing updates of operational software only by trained administrators upon appropriate management authorization (see 8.5); + +b\) ensuring that only approved executable code and no development code or compilers is installed on operational systems; + +c\) only installing and updating software after extensive and successful testing (see >8.29 and >8.31>); + +d\) updating all corresponding program source libraries; + +e\) using a configuration control system to keep control of all operational software as well as the system documentation; + +f\) defining a rollback strategy before changes are implemented; + +g\) maintaining an audit log of all updates to operational software; + +h\) archiving old versions of software, together with all required information and parameters, procedures, configuration details and supporting software as a contingency measure, and for as long as the software is required to read or process archived data. + +Any decision to upgrade to a new release should take into account the business requirements for the change and the security of the release (e.g. the introduction of new information security functionality or the number and severity of information security vulnerabilities affecting the current version). Software patches should be applied when they can help to remove or reduce information security vulnerabilities (see >8.8and >8.19>). + +Computer software can rely on externally supplied software and packages (e.g. software programs using modules which are hosted on external sites), which should be monitored and controlled to avoid unauthorized changes, because they can introduce information security vulnerabilities. + +Vendor supplied software used in operational systems should be maintained at a level supported by the supplier. Over time, software vendors will cease to support older versions of software. The organization should consider the risks of relying on unsupported software. Open source software used in operational systems should be maintained to the latest appropriate release of the software. Over time, open source code can cease to be maintained but is still available in an open source software repository. The organization should also consider the risks of relying on unmaintained open source software when used in operational systems. + +When suppliers are involved in installing or updating software, physical or logical access should only be given when necessary and with appropriate authorization. The supplier’s activities should be monitored (see 5.22). + +The organization should define and enforce strict rules on which types of software users can install. + +The principle of least privilege should be applied to software installation on operational systems. The organization should identify what types of software installations are permitted (e.g. updates and security patches to existing software) and what types of installations are prohibited (e.g. software that is only for personal use and software whose pedigree with regard to being potentially malicious is unknown or suspect). These privileges should be granted based on the roles of the users concerned. + +**Other information** +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.1_OT User endpoint devices.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.1_OT User endpoint devices.md new file mode 100644 index 0000000..d6208b3 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.1_OT User endpoint devices.md @@ -0,0 +1,73 @@ +## 8.1 User endpoint devices + + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ----------------------------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management
#Information_protection | #Protection | + +**Control** +Information stored on, processed by or accessible via user endpoint devices should be protected. + +**Purpose** +To protect information against the risks introduced by using user endpoint devices. + +**Guidance** + +General + +The organization should establish a topic-specific policy on secure configuration and handling of user endpoint devices. The topic-specific policy should be communicated to all relevant personnel and consider the following: + +a\) the type of information and the classification level that the user endpoint devices can handle, process, store or support; +b\) registration of user endpoint devices; +c\) requirements for physical protection; +d\) restriction of software installation (e.g. remotely controlled by system administrators); +e\) requirements for user endpoint device software (including software versions) and for applying updates (e.g. active automatic updating); +f\) rules for connection to information services, public networks or any other network off premises (e.g. requiring the use of personal firewall); +g\) access controls; +h\) storage device encryption; +i\) protection against malware; +j\) remote disabling, deletion or lockout; +k\) backups; +l\) usage of web services and web applications; +m\) end user behaviour analytics (see 8.16); +n\) the use of removable devices, including removable memory devices, and the possibility of disabling physical ports (e.g. USB ports); +o\) the use of partitioning capabilities, if supported by the user endpoint device, which can securely separate the organization's information and other associated assets (e.g. software) from other information and other associated assets on the device. + +Consideration should be given as to whether certain information is so sensitive that it can only be accessed via user endpoint devices, but not stored on such devices. In such cases, additional technical safeguards can be required on the device. For example, ensuring that downloading files for offline working is disabled and that local storage such as SD card is disabled. + +As far as possible, the recommendations on this control should be enforced through configuration management (see 8.9) or automated tools. + +User responsibility + +All users should be made aware of the security requirements and procedures for protecting user endpoint devices, as well as of their responsibilities for implementing such security measures. Users should be advised to: + +a\) log-off active sessions and terminate services when no longer needed; +b\) protect user endpoint devices from unauthorized use with a physical control (e.g. key lock or special locks) and logical control (e.g. password access) when not in use; not leave devices carrying important, sensitive or critical business information unattended; +c\) use devices with special care in public places, open offices, meeting places and other unprotected areas (e.g. avoid reading confidential information if people can read from the back, use privacy screen filters); +d\) physically protect user endpoint devices against theft (e.g. in cars and other forms of transport, hotel rooms, conference centres and meeting places). + +A specific procedure taking into account legal, statutory, regulatory, contractual (including insurance) and other security requirements of the organization should be established for cases of theft or loss of user endpoint devices. + +Use of personal devices + +Where the organization allows the use of personal devices (sometimes known as BYOD), in addition to the guidance given in this control, the following should be considered: + +a\) separation of personal and business use of the devices, including using software to support such separation and protect business data on a private device; +b\) providing access to business information only after users have acknowledged their duties (physical protection, software updating, etc.), waiving ownership of business data, allowing remote wiping of data by the organization in case of theft or loss of the device or when no longer authorized to use the service. In such cases, PII protection legislation should be considered; +c\) topic-specific policies and procedures to prevent disputes concerning rights to intellectual property developed on privately owned equipment; +e\) software licensing agreements that are such that organizations can become liable for licensing for client software on user endpoint devices owned privately by personnel or external party users. + +Wireless connections + +The organization should establish procedures for: + +a\) the configuration of wireless connections on devices (e.g. disabling vulnerable protocols); +b\) using wireless or wired connections with appropriate bandwidth in accordance with relevant topic-specific policies (e.g. because backups or software updates are needed). + +**Other information** +Controls to protect information on user endpoint devices depend on whether the user endpoint device is used only inside of the organization's secured premises and network connections, or whether it is exposed to increased physical and network related threats outside of the organization. + +The wireless connections for user endpoint devices are similar to other types of network connections but have important differences that should be considered when identifying controls. In particular, back-up of information stored on user endpoint devices can sometimes fail because of limited network bandwidth or because user endpoint devices are not connected at the times when backups are scheduled. + +For some USB ports, such as USB-C, disabling the USB port is not possible because it is used for other purposes (e.g. power delivery and display output). diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.20_OT Networks security.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.20_OT Networks security.md new file mode 100644 index 0000000..4fcdbb3 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.20_OT Networks security.md @@ -0,0 +1,49 @@ +## 8.20 Networks security + + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ---------------------- | ----------------------------------------- | ---------------------- | ---------------------------- | ---------------- | +| #Preventive #Detective | #Confidentiality #Integrity #Availability | #Protect #Detect | #System_and_network_security | #Protection | + +**Control** +Networks and network devices should be secured, managed and controlled to protect information in systems and applications. + +**Purpose** +To protect information in networks and its supporting information processing facilities from compromise via the network. + +**Guidance** +Controls should be implemented to ensure the security of information in networks and to protect connected services from unauthorized access. In particular, the following items should be considered: + +a\) the type and classification level of information that the network can support; + +b\) establishing responsibilities and procedures for the management of networking equipment and devices; + +c\) maintaining up to date documentation including network diagrams and configuration files of devices (e.g. routers, switches); + +d\) separating operational responsibility for networks from ICT system operations where appropriate (see 5.3); + +e\) establishing controls to safeguard the confidentiality and integrity of data passing over public networks, third-party networks or over wireless networks and to protect the connected systems and applications (see >5.22>, >8.24>, >5.14and >6.6>). Additional controls can also be required to maintain the availability of the network services and computers connected to the network; + +f\) appropriately logging and monitoring to enable recording and detection of actions that can affect, or are relevant to, information security (see >8.16and >8.15>); + +g\) closely coordinating network management activities both to optimize the service to the organization and to ensure that controls are consistently applied across the information processing infrastructure; + +h\) authenticating systems on the network; + +i\) restricting and filtering systems connection to the network (e.g. using firewalls); + +j\) detecting, restricting and authenticating the connection of equipment and devices to the network; + +k\) hardening of network devices; + +l\) segregating network administration channels from other network traffic; + +m\) temporarily isolating critical subnetworks (e.g. with drawbridges) if the network is under attack; + +n\) disabling vulnerable network protocols. + +The organization should ensure that appropriate security controls are applied to the use of virtualized networks. Virtualized networks also cover software-defined networking (SDN, SD-WAN). Virtualized networks can be desirable from a security viewpoint, since they can permit logical separation of communication taking place over physical networks, particularly for systems and applications that are implemented using distributed computing. + +**Other information** +Additional information on network security can be found in the ISO/IEC 27033 series. More information concerning virtualized networks can be found in ISO/IEC TS 23167. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.21_OT Security of network services.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.21_OT Security of network services.md new file mode 100644 index 0000000..9ec3b9f --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.21_OT Security of network services.md @@ -0,0 +1,49 @@ + + +## 8.21 Security of network services + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ---------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security | #Protection | + +**Control** +Security mechanisms, service levels and service requirements of network services should be identified, implemented and monitored. + +**Purpose** +To ensure security in the use of network services. + +**Guidance** +The security measures necessary for particular services, such as security features, service levels and service requirements, should be identified and implemented (by internal or external network service providers). The organization should ensure that network service providers implement these measures. + +The ability of the network service provider to manage agreed services in a secure way should be determined and regularly monitored. The right to audit should be agreed between the organization and the provider. The organization should also consider third-party attestations provided by service providers to demonstrate they maintain appropriate security measures. + +Rules on the use of networks and network services should be formulated and implemented to cover: + +a\) the networks and network services which are allowed to be accessed; + +b\) authentication requirements for accessing various network services; + +c\) authorization procedures for determining who is allowed to access which networks and networked services; + +d\) network management and technological controls and procedures to protect access to network connections and network services; + +e\) the means used to access networks and network services \[e.g. use of virtual private network (VPN) or wireless network\]; + +f\) time, location and other attributes of the user at the time of the access; + +g\) monitoring of the use of network services. + +The following security features of network services should be considered: + +a\) technology applied for security of network services, such as authentication, encryption and network connection controls; + +b\) technical parameters required for secured connection with the network services in accordance with the security and network connection rules; + +c\) caching (e.g. in a content delivery network) and its parameters that allow users to choose the use of caching in accordance with performance, availability and confidentiality requirements; + +d\) procedures for the network service usage to restrict access to network services or applications, where necessary. + +**Other information** +Network services include the provision of connections, private network services and managed network security solutions such as firewalls and intrusion detection systems. These services can range from simple unmanaged bandwidth to complex value-added offerings. + +More guidance on a framework for access management is given in ISO/IEC 29146. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.22_OT Segregation of networks.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.22_OT Segregation of networks.md new file mode 100644 index 0000000..51b8a53 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.22_OT Segregation of networks.md @@ -0,0 +1,23 @@ +#iso27002/2022/EN + +## 8.22 Segregation of networks + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ---------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security | #Protection | + +**Control** +Groups of information services, users and information systems should be segregated in the organization’s networks. + +**Purpose** +To split the network in security boundaries and to control traffic between them based on business needs. + +**Guidance** +The organization should consider managing the security of large networks by dividing them into separate network domains and separating them from the public network (i.e. internet). The domains can be chosen based on levels of trust, criticality and sensitivity (e.g. public access domain, desktop domain, server domain, low- and high-risk systems), along organizational units (e.g. human resources, finance, marketing) or some combination (e.g. server domain connecting to multiple organizational units). The segregation can be done using either physically different networks or by using different logical networks. + +The perimeter of each domain should be well-defined. If access between network domains is allowed, it should be controlled at the perimeter using a gateway (e.g. firewall, filtering router). The criteria for segregation of networks into domains, and the access allowed through the gateways, should be based on an assessment of the security requirements of each domain. The assessment should be in accordance with the topic-specific policy on access control (see 5.15), access requirements, value and classification of information processed and take account of the relative cost and performance impact of incorporating suitable gateway technology. + +Wireless networks require special treatment due to the poorly-defined network perimeter. Radio coverage adjustment should be considered for segregation of wireless networks. For sensitive environments, consideration should be made to treat all wireless access as external connections and to segregate this access from internal networks until the access has passed through a gateway in accordance with network controls (see 8.20) before granting access to internal systems. Wireless access network for guests should be segregated from those for personnel if personnel only use controlled user endpoint devices compliant to the organization’s topic-specific policies. WiFi for guests should have at least the same restrictions as WiFi for personnel, in order to discourage the use of guest WiFi by personnel. + +**Other information** +Networks often extend beyond organizational boundaries, as business partnerships are formed that require the interconnection or sharing of information processing and networking facilities. Such extensions can increase the risk of unauthorized access to the organization’s information systems that use the network, some of which require protection from other network users because of their sensitivity or criticality. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.23_OT Web filtering.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.23_OT Web filtering.md new file mode 100644 index 0000000..b2624a2 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.23_OT Web filtering.md @@ -0,0 +1,33 @@ +## 8.23 Web filtering + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ---------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security | #Protection | + +**Control** +Access to external websites should be managed to reduce exposure to malicious content. + +**Purpose** +To protect systems from being compromised by malware and to prevent access to unauthorized web resources. + +**Guidance** +The organization should reduce the risks of its personnel accessing websites that contain illegal information or are known to contain viruses or phishing material. A technique for achieving this works by blocking the IP address or domain of the website(s) concerned. Some browsers and anti-malware technologies do this automatically or can be configured to do so. + +The organization should identify the types of websites to which personnel should or should not have access. The organization should consider blocking access to the following types of websites: + +a\) websites that have an information upload function unless permitted for valid business reasons; + +b\) known or suspected malicious websites (e.g. those distributing malware or phishing contents); + +c\) command and control servers; + +d\) malicious website acquired from threat intelligence (see 5.7); + +e\) websites sharing illegal content. + +Prior to deploying this control, the organization should establish rules for safe and appropriate use of online resources, including any restriction to undesirable or inappropriate websites and web-based applications. The rules should be kept up-to-date. + +Training should be given to personnel on the secure and appropriate use of online resources including access to the web. The training should include the organization’s rules, contact point for raising security concerns, and exception process when restricted web resources need to be accessed for legitimate business reasons. Training should also be given to personnel to ensure that they do not overrule any browser advisory that reports that a website is not secure but allows the user to proceed. + +**Other information** +Web filtering can include a range of techniques including signatures, heuristics, list of acceptable websites or domains, list of prohibited websites or domains and bespoke configuration to help prevent malicious software and other malicious activity from attacking the organization’s network and systems. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.24_OT Use of cryptography.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.24_OT Use of cryptography.md new file mode 100644 index 0000000..4ce2b18 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.24_OT Use of cryptography.md @@ -0,0 +1,77 @@ +--- +tags: + - iso27001/2022/EN +--- +## 8.24 Use of cryptography + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------ | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Secure_configuration | #Protection | + +**Control** +Rules for the effective use of cryptography, including cryptographic key management, should be defined and implemented. + +**Purpose** +To ensure proper and effective use of cryptography to protect the confidentiality, authenticity or integrity of information according to business and information security requirements, and taking into consideration legal, statutory, regulatory and contractual requirements related to cryptography. + +**Guidance** + +General +When using cryptography, the following should be considered: + +a\) the topic-specific policy on cryptography defined by the organization, including the general principles for the protection of information. A topic-specific policy on the use of cryptography is necessary to maximize the benefits and minimize the risks of using cryptographic techniques and to avoid inappropriate or incorrect use; + +b\) identifying the required level of protection and the classification of the information andconsequently establishing the type, strength and quality of the cryptographic algorithms required; + +c\) the use of cryptography for protection of information held on mobile user endpoint devices or storage media and transmitted over networks to such devices or storage media; + +d\) the approach to key management, including methods to deal with the generation and protection of cryptographic keys and the recovery of encrypted information in the case of lost, compromised or damaged keys; + +e\) roles and responsibilities for: + + 1\) the implementation of the rules for the effective use of cryptography; + 2\) the key management, including key generation (see 8.24); + +f\) the standards to be adopted, as well as cryptographic algorithms, cipher strength, cryptographic solutions and usage practices that are approved or required for use in the organization; + +g\) the impact of using encrypted information on controls that rely on content inspection (e.g. malware detection or content filtering). + +When implementing the organization’s rules for effective use of cryptography, the regulations and national restrictions that can apply to the use of cryptographic techniques in different parts of the world should be taken into consideration as well as the issues of trans-border flow of encrypted information (see 5.31). + +The contents of service level agreements or contracts with external suppliers of cryptographic services (e.g. with a certification authority) should cover issues of liability, reliability of services and response times for the provision of services (see 5.22). + +Key management + +Appropriate key management requires secure processes for generating, storing, archiving, retrieving, distributing, retiring and destroying cryptographic keys. + +A key management system should be based on an agreed set of standards, procedures and secure methods for: + + a\) generating keys for different cryptographic systems and different applications; + b\) issuing and obtaining public key certificates; + c\) distributing keys to intended entities, including how to activate keys when received; + d\) storing keys, including how authorized users obtain access to keys; + e\) changing or updating keys including rules on when to change keys and how this will be done; + f\) dealing with compromised keys; + g\) revoking keys including how to withdraw or deactivate keys \[e.g. when keys have been compromised or when a user leaves an organization (in which case keys should also be archived)\]; + h\) recovering keys that are lost or corrupted; + i\) backing up or archiving keys; + j\) destroying keys; + k\) logging and auditing of key management related activities; + l\) setting activation and deactivation dates for keys so that the keys can only be used for the period of time according to the organization's rules on key management; + m\) handling legal requests for access to cryptographic keys (e.g. encrypted information can be required to be made available in an unencrypted form as evidence in a court case). + +All cryptographic keys should be protected against modification and loss. In addition, secret and private keys need protection against unauthorized use as well as disclosure. Equipment used to generate, store and archive keys should be physically protected. + +In addition to integrity, for many use cases, the authenticity of public keys should also be considered. + +**Other information** +The authenticity of public keys is usually addressed by public key management processes using certificate authorities and public key certificates, but it is also possible to address it by using technologies such as applying manual processes for small number keys. + +Cryptography can be used to achieve different information security objectives, for example: + +a\) confidentiality: using encryption of information to protect sensitive or critical information, either stored or transmitted; +b\) integrity or authenticity: using digital signatures or message authentication codes to verify the authenticity or integrity of stored or transmitted sensitive or critical information. Using algorithms for the purpose of file integrity checking; +c\) non-repudiation: using cryptographic techniques to provide evidence of the occurrence or non-occurrence of an event or action; +d\) authentication: using cryptographic techniques to authenticate users and other system entities requesting access to or transacting with system users, entities and resources. + +The ISO/IEC 11770 series provides further information on key management. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.25_OT Secure development life cycle.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.25_OT Secure development life cycle.md new file mode 100644 index 0000000..ea0b64c --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.25_OT Secure development life cycle.md @@ -0,0 +1,45 @@ +--- +tags: + - iso27001/2022/EN +--- +## 8.25 Secure development life cycle + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | + +**Control** +Rules for the secure development of software and systems should be established and applied. + +**Purpose** +To ensure information security is designed and implemented within the secure development life cycle of software and systems. + +**Guidance** +Secure development is a requirement to build up a secure service, architecture, software and system. To achieve this, the following aspects should be considered: + +a\) separation of development, test and production environments (see [[ISO_27002_2022_8.31_OT Separation of development, test and production environments|8.31]]); + +b\) guidance on the security in the software development life cycle: + 1\) security in the software development methodology (see [[ISO_27002_2022_8.28_OT Secure coding|8.28]] and [[ISO_27002_2022_8.27_OT Secure system architecture and engineering principles|8.27]]); + 2\) secure coding guidelines for each programming language used (see [[ISO_27002_2022_8.28_OT Secure coding|8.28]]); + +c\) security requirements in the specification and design phase (see [[ISO_27002_2022_5.8_OT Information security in project management|5.8]]); + +d\) security checkpoints in projects (see [[ISO_27002_2022_5.8_OT Information security in project management|5.8]]); + +e\) system and security testing, such as regression testing, code scan and penetration tests (see [[ISO_27002_2022_8.29_OT Security testing in development and acceptance|8.29]]); + +f\) secure repositories for source code and configuration (see [[ISO_27002_2022_8.4_OT Access to source code|8.4]] and [[ISO_27002_2022_8.9_OT Configuration management|8.9]]); + +g\) security in the version control (see [[ISO_27002_2022_8.32_OT Change management|8.32]]); + +h\) required application security knowledge and training (see [[ISO_27002_2022_8.28_OT Secure coding|8.28]]); + +i\) developers’ capability for preventing, finding and fixing vulnerabilities (see [[ISO_27002_2022_8.28_OT Secure coding|8.28]]); + +j\) licensing requirements and alternatives to ensure cost-effective solutions while avoiding future licensing issues (See [[ISO_27002_2022_5.32_OT Intellectual property rights|5.32]]). + +If development is outsourced, the organization should obtain assurance that the supplier complies with the organization’s rules for secure development (see [[ISO_27002_2022_8.30_OT Outsourced development|8.30]]). + +**Other information** +Development can also take place inside applications, such as office applications, scripting, browsers and databases. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.26_OT Application security requirements.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.26_OT Application security requirements.md new file mode 100644 index 0000000..52f134b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.26_OT Application security requirements.md @@ -0,0 +1,89 @@ +#iso27002/2022/EN +## 8.26 Application security requirements + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | -------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection #Defence | +#### Control +Information security requirements should be identified, specified and approved when developing or acquiring applications. +#### Purpose +To ensure all information security requirements are identified and addressed when developing or acquiring applications. +#### Guidance + +General + +Application security requirements should be identified and specified. These requirements are usually determined through a risk assessment. The requirements should be developed with the support of information security specialists. + +Application security requirements can cover a wide range of topics, depending on the purpose of the application. + +Application security requirements should include, as applicable: + +a\) level of trust in identity of entities \[e.g. through authentication (see [[ISO_27002_OT 5.17 Authentication information|5.17]], [[ISO_27002_OT 8.2 Privileged access rights\|8.2]] and [[ISO_27002_OT 8.5 Secure authentication|8.5]])]; + +b\) identifying the type of information and classification level to be processed by the application; + +c\) need for segregation of access and level of access to data and functions in the application; + +d\) resilience against malicious attacks or unintentional disruptions \[e.g. protection against buffer overflow or structured query language (SQL) injections\]; + +e\) legal, statutory and regulatory requirements in the jurisdiction where the transaction is generated, processed, completed or stored; + +f\) need for privacy associated with all parties involved; + +g\) the protection requirements of any confidential information; + +h\) protection of data while being processed, in transit and at rest; + +i\) need to securely encrypt communications between all involved parties; + +j\) input controls, including integrity checks and input validation; + +k\) automated controls (e.g. approval limits or dual approvals); + +l\) output controls, also considering who can access outputs and its authorization; + +m\) restrictions around content of "free-text" fields, as these can lead to uncontrolled storage of confidential data (e.g. personal data); + +n\) requirements derived from the business process, such as transaction logging and monitoring, nonrepudiation requirements; + +o\) requirements mandated by other security controls (e.g. interfaces to logging and monitoring or data leakage detection systems); + +p) error message handling. + +Transactional services + +Additionally, for applications offering transactional services between the organization and a partner, the following should be considered when identifying information security requirements: + +a\) the level of trust each party requires in each other’s claimed identity; + +b\) the level of trust required in the integrity of information exchanged or processed and the mechanisms for identification of lack of integrity (e.g. cyclic redundancy check, hashing, digital signatures); + +c\) authorization processes associated with who can approve contents of, issue or sign key transactional documents; + +d\) confidentiality, integrity, proof of dispatch and receipt of key documents and the non-repudiation (e.g. contracts associated with tendering and contract processes); + +e\) the confidentiality and integrity of any transactions (e.g. orders, delivery address details and confirmation of receipts); + +f\) requirements on how long to maintain a transaction confidential; + +g\) insurance and other contractual requirements. + +Electronic ordering and payment applications + +Additionally, for applications involving electronic ordering and payment, the following should be considered: + +a\) requirements for maintaining the confidentiality and integrity of order information; + +b\) the degree of verification appropriate to verify payment information supplied by a customer; + +c\) avoidance of loss or duplication of transaction information; + +d\) storing transaction details outside of any publicly accessible environment (e.g. on a storage platform existing on the organizational intranet, and not retained and exposed on electronic storage media directly accessible from the internet); + +e\) where a trusted authority is used (e.g. for the purposes of issuing and maintaining digital signatures or digital certificates) security is integrated and embedded throughout the entire end-to-end certificate or signature management process. + +Several of the above considerations can be addressed by the application of cryptography (see [[8.24]]), taking into consideration legal requirements (see [[5.31]], [[5.36]], especially see [[5.31]] for cryptography legislation). + +**Other information** + +Applications accessible via networks are subject to a range of network related threats, such as fraudulent activities, contract disputes or disclosure of information to the public; incomplete transmission, mis- routing, unauthorized message alteration, duplication or replay. Therefore, detailed risk assessments and careful determination of controls are indispensable. Controls required often include cryptographic methods for authentication and securing data transfer. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md new file mode 100644 index 0000000..05d7591 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md @@ -0,0 +1,84 @@ +--- +tags: + - iso27001/2022/EN +--- +## 8.27 Secure system architecture and engineering principles + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | + +**Control** +Principles for engineering secure systems should be established, documented, maintained and applied to any information system development activities. + +**Purpose** +To ensure information systems are securely designed, implemented and operated within the development life cycle. + +**Guidance** +Security engineering principles should be established, documented and applied to information system engineering activities. Security should be designed into all architecture layers (business, data, applications and technology). New technology should be analysed for security risks and the design should be reviewed against known attack patterns. + +Secure engineering principles provide guidance on user authentication techniques, secure session control and data validation and sanitisation. + +Secure system engineering principles should include analysis of: + +a\) the full range of security controls required to protect information and systems against identified threats; + +b\) the capabilities of security controls to prevent, detect or respond to security events; + +c\) specific security controls required by particular business processes (e.g. encryption of sensitive information, integrity checking and digitally signing information); + +d\) where and how security controls are to be applied (e.g. by integrating with a security architecture and the technical infrastructure); + +e\) how individual security controls (manual and automated) work together to produce an integrated set of controls. + +Security engineering principles should take account of: + +a\) the need to integrate with a security architecture; + +b\) technical security infrastructure \[e.g. public key infrastructure (PKI), identity and access management (IAM), data leakage prevention and dynamic access management\]; + +c\) capability of the organization to develop and support the chosen technology; + +d\) cost, time and complexity of meeting security requirements; + +e\) current good practices. + +Secure system engineering should involve: + +a\) the use of security architecture principles, such as “security by design”, “defense in depth”, “security by default”, “default deny”, “fail securely”, “distrust input from external applications”, “security in deployment”, “assume breach”, "least privilege", “usability and manageability” and “least functionality”; + +b\) a security-oriented design review to help identify information security vulnerabilities, ensure security controls are specified and meet security requirements; + +c\) documentation and formal acknowledgement of security controls that do not fully meet requirements (e.g. due to overriding safety requirements); + +d\) hardening of systems. + +The organization should consider "zero trust" principles such as: + +a\) assuming the organization’s information systems are already breached and thus not be reliant on network perimeter security alone; + +b\) employing a “never trust and always verify” approach for access to information systems; + +c\) ensuring that requests to information systems are encrypted end-to-end; + +d\) verifying each request to an information system as if it originated from an open, external network, even if these requests originated internal to the organization (i.e. not automatically trusting anything inside or outside its perimeters); + +e\) using "least privilege" and dynamic access control techniques (see 5.15, 5.18and 8.2). This includes authenticating and authorizing requests for information or to systems based on contextual information such as authentication information (see 5.17), user identities (see 5.16), data about the user endpoint device, and data classification (see >5.12>); + +f\) always authenticating requesters and always validating authorization requests to information systems based on information including authentication information (see >5.17>) and user identities (>5.16>), data about the user endpoint device, and data classification (see >5.12>), for example enforcing strong authentication (e.g. multi-factor, see >8.5>). + +The established security engineering principles should be applied, where applicable, to outsourced development of information systems through the contracts and other binding agreements between the organization and the supplier to whom the organization outsources. The organization should ensure that suppliers’ security engineering practices align with the organization’s needs. + +The security engineering principles and the established engineering procedures should be regularly reviewed to ensure that they are effectively contributing to enhanced standards of security within the engineering process. They should also be regularly reviewed to ensure that they remain up-to- date in terms of combatting any new potential threats and in remaining applicable to advances in the technologies and solutions being applied. + +**Other information** + +Secure engineering principles can be applied to the design or configuration of a range of techniques, such as: + +- fault tolerance and other resilience techniques; +- segregation (e.g. through virtualization or containerization); +- tamper resistance. + +Secure virtualization techniques can be used to prevent interference between applications running on the same physical device. If a virtual instance of an application is compromised by an attacker, only that instance is affected. The attack has no effect on any other application or data. + +Tamper resistance techniques can be used to detect tampering of information containers, whether physical (e.g. a burglar alarm) or logical (e.g. a data file). A characteristic of such techniques is that there is a record of the attempt to tamper with the container. In addition, the control can prevent the successful extraction of data through its destruction (e.g. device memory can be deleted). \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.28_OT Secure coding.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.28_OT Secure coding.md new file mode 100644 index 0000000..e35e279 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.28_OT Secure coding.md @@ -0,0 +1,93 @@ +--- +tags: + - iso27001/2022/EN +--- + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | + +## 8.28 Secure coding + +#### Control +Secure coding principles should be applied to software development. +#### Purpose +To ensure software is written securely thereby reducing the number of potential information security vulnerabilities in the software. +#### Guidance + +**General** + +The organization should establish organization-wide processes to provide good governance for secure coding. A minimum secure baseline should be established and applied. Additionally, such processes and governance should be extended to cover software components from third parties and open source software. + +The organization should monitor real world threats and up-to-date advice and information on software vulnerabilities to guide the organization’s secure coding principles through continual improvement and learning. This can help with ensuring effective secure coding practices are implemented to combat the fast-changing threat landscape. + +**Planning and before coding** + +Secure coding principles should be used both for new developments and in reuse scenarios. These principles should be applied to development activities both within the organization and for products and services supplied by the organization to others. + +Planning and prerequisites before coding should include: + +a) organization-specific expectations and approved principles for secure coding to be used for both in-house and outsourced code developments; +b) common and historical coding practices and defects that lead to information security vulnerabilities; +c) configuring development tools, such as integrated development environments (IDE), to help enforce the creation of secure code; +d) following guidance issued by the providers of development tools and execution environments as applicable; +e) maintenance and use of updated development tools (e.g. compilers); +f) qualification of developers in writing secure code; +g) secure design and architecture, including threat modeling; +h) secure coding standards and where relevant mandating their use; +i) use of controlled environments for development. + +**During coding** + +Considerations during coding should include: + +a) secure coding practices specific to the programming languages and techniques being used; +b) using secure programming techniques, such as pair programming, refactoring, peer review, security iterations and test-driven development; +c) using structured programming techniques; +d) documenting code and removing programming defects, which can allow information security vulnerabilities to be exploited; +e) prohibiting the use of insecure design techniques (e.g. the use of hard-coded passwords, unapproved code samples and unauthenticated web services). + +Testing should be conducted during and after development (see [[ISO_27002_OT 8.29 Security testing in development and acceptance|8.29]]). Static application security testing (SAST) processes can identify security vulnerabilities in software. + +Before software is made operational, the following should be evaluated: +a) attack surface and the principle of least privilege; +b) conducting an analysis of the most common programming errors and documenting that these have been mitigated. + +**Review and maintenance** + +After code has been made operational: + +a) updates should be securely packaged and deployed; +b) reported information security vulnerabilities should be handled (see [[ISO_27002_OT 8.8 Management of technical vulnerabilities|8.8]]); +c) errors and suspected attacks should be logged and logs regularly reviewed to make adjustments to the code as necessary; +d) source code should be protected against unauthorized access and tampering (e.g. by using configuration management tools, which typically provide features such as access control and version control). + +If using external tools and libraries, the organization should consider: + +a) ensuring that external libraries are managed (e.g. by maintaining an inventory of libraries used and their versions) and regularly updated with release cycles; +b) selection, authorization and reuse of well-vetted components, particularly authentication and cryptographic components; +c) the licence, security and history of external components; +d) ensuring that software is maintainable, tracked and originates from proven, reputable sources; +e) sufficiently long-term availability of development resources and artefacts. + +Where a software package needs to be modified the following points should be considered: + +a) the risk of built-in controls and integrity processes being compromised; +b) whether to obtain the consent of the vendor; +c) the possibility of obtaining the required changes from the vendor as standard program updates; +d) the impact if the organization becomes responsible for the future maintenance of the software as a result of changes; +e) compatibility with other software in use. + +**Other** **information** + +A guiding principle is to ensure security-relevant code is invoked when necessary and is tamper- resistant. Programs installed from compiled binary code also have these properties but only for data held within the application. For interpreted languages, the concept only works when the code is executed on a server that is otherwise inaccessible by the users and processes that use it, and that its data is held in a similarly protected database. For example, the interpreted code can be run on a cloud service where access to the code itself requires administrator privileges. Such administrator access should be protected by security mechanisms such as just-in-time administration principles and strong authentication. If the application owner can access scripts by direct remote access to the server, so in principle can an attacker. Webservers should be configured to prevent directory browsing in such cases. + +Application code is best designed on the assumption that it is always subject to attack, through error or malicious action. In addition, critical applications can be designed to be tolerant of internal faults. For example, the output from a complex algorithm can be checked to ensure that it lies within safe bounds before the data is used in an application such as a safety or financial critical application. The code that performs the boundary checks is simple and therefore much easier to prove correctness. + +Some web applications are susceptible to a variety of vulnerabilities that are introduced by poor design and coding, such as database injection and cross-site scripting attacks. In these attacks, requests can be manipulated to abuse the webserver functionality. + +More information on ICT security evaluation can be found in the ISO/IEC 15408 series. +# Related: +- [[ISO_27002_PE 8.28 Secure coding]] +- [[ISO_27002_OT 8.29 Security testing in development and acceptance]] +- [[ISO_27002_OT 8.8 Management of technical vulnerabilities]] diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.29_OT Security testing in development and acceptance.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.29_OT Security testing in development and acceptance.md new file mode 100644 index 0000000..8a0f5a5 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.29_OT Security testing in development and acceptance.md @@ -0,0 +1,53 @@ +#iso27002/2022/EN + +## 8.29 Security testing in development and acceptance + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ---------------------------------------------------------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Application_security #Information_security_assurance #System_and_network_security | #Protection | + +**Control** +Security testing processes should be defined and implemented in the development life cycle. + +**Purpose** +To validate if information security requirements are met when applications or code are deployed to the production environment. + +**Guidance** +New information systems, upgrades and new versions should be thoroughly tested and verified during the development processes. Security testing should be an integral part of the testing for systems or components. + +Security testing should be conducted against a set of requirements, which can be expressed as functional or non-functional. Security testing should include testing of: + +a\) security functions \[e.g. user authentication (see 8.5), access restriction (see 8.3) and use of cryptography (see 8.24)\]; + +b\) secure coding (see 8.28); + +c\) secure configurations (see >8.9>, >8.20and >8.22>) including that of operating systems, firewalls and other security components. + +Test plans should be determined using a set of criteria. The extent of testing should be in proportion to the importance, nature of the system and the potential impact of the change being introduced. The test plan should include: + +a\) detailed schedule of activities and tests; + +b\) inputs and expected outputs under a range of conditions; + +c\) criteria to evaluate the results; + +d\) decision for further actions as necessary. + +The organization can leverage automated tools, such as code analysis tools or vulnerability scanners, and should verify the remediation of security related defects. + +For in-house developments, such tests should initially be performed by the development team. Independent acceptance testing should then be undertaken to ensure that the system works as expected and only as expected (see 5.8). The following should be considered: + +a\) performing code review activities as a relevant element for testing for security flaws, including unanticipated inputs and conditions; + +b\) performing vulnerability scanning to identify insecure configurations and system vulnerabilities; + +c\) performing penetration testing to identify insecure code and design. + +For outsourced development and purchasing components, an acquisition process should be followed. Contracts with the supplier should address the identified security requirements (see 5.20). Products and services should be evaluated against these criteria before acquisition. + +Testing should be performed in a test environment that matches the target production environment as closely as possible to ensure that the system does not introduce vulnerabilities to the organization’s environment and that the tests are reliable (see 8.31). + +**Other information** +Multiple test environments can be established, which can be used for different kinds of testing (e.g. functional and performance testing). These different environments can be virtual, with individual configurations to simulate a variety of operating environments. + +Testing and monitoring of test environments, tools and technologies also needs to be considered to ensure effective testing. The same considerations apply to monitoring of the monitoring systems deployed in development, test and production settings. Judgeme nt is needed, guided by the sensitivity of the systems and data, to determine how many layers of meta-testing are useful. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.2_OT Privileged access rights.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.2_OT Privileged access rights.md new file mode 100644 index 0000000..59015fc --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.2_OT Privileged access rights.md @@ -0,0 +1,47 @@ +#iso27002/2022/EN + +## 8.2 Privileged access rights + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | + +**Control** +The allocation and use of privileged access rights should be restricted and managed. + +**Purpose** +To ensure only authorized users, software components and services are provided with privileged access rights. + +**Guidance** +The allocation of privileged access rights should be controlled through an authorization process in accordance with the relevant topic-specific policy on access control (see 5.15). The following should be considered: + +a\) identifying users who need privileged access rights for each system or process (e.g. operating systems, database management systems and applications); + +b\) allocating privileged access rights to users as needed and on an event-by-event basis in line with the topic-specific policy on access control (see 5.15) (i.e. only to individuals with the necessary competence to carry out activities that require privileged access and based on the minimum requirement for their functional roles); + +c\) maintaining an authorization process (i.e. determining who can approve privileged access rights, or not granting privileged access rights until the authorization process is complete) and a record of all privileges allocated; + +d\) defining and implementing requirements for expiry of privileged access rights; + +e\) taking measures to ensure that users are aware of their privileged access rights and when they are in privileged access mode. Possible measures include using specific user identities, user interface settings or even specific equipment; + +f\) authentication requirements for privileged access rights can be higher than the requirements for normal access rights. Re-authentication or authentication step-up can be necessary before doing work with privileged access rights; + +g\) regularly, and after any organizational change, reviewing users working with privileged access rights in order to verify if their duties, roles, responsibilities and competence still qualify them for working with privileged access rights (see 5.18); + +h\) establishing specific rules in order to avoid the use of generic administration user IDs (such as “root”), depending on systems’ configuration capabilities. Managing and protecting authentication information of such identities (see 5.17); + +i\) granting temporary privileged access just for the time window necessary to implement approved changes or activities (e.g. for maintenance activities or some critical changes), rather than permanently granting privileged access rights. This is often referred as break glass procedure, and often automated by privilege access management technologies; + +j\) logging all privileged access to systems for audit purposes; + +k\) not sharing or linking identities with privileged access rights to multiple persons, assigning each person a separate identity which allows assigning specific privileged access rights. Identities can be grouped (e.g. by defining an administrator group) in order to simplify the management of privileged access rights; + +l\) only using identities with privileged access rights for undertaking administrative tasks and not for day-to-day general tasks \[i.e. checking email, accessing the web (users should have a separate normal network identity for these activities)\]. + +**Other information** +Privileged access rights are access rights provided to an identity, a role or a process that allows the performance of activities that typical users or processes cannot perform. System administrator roles typically require privileged access rights. + +Inappropriate use of system administrator privileges (any feature or facility of an information system that enables the user to override system or application controls) is a major contributory factor to failures or breaches of systems. + +More information related to access management and the secure management of access to information and information and communications technologies resources can be found in ISO/IEC 29146. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.30_OT Outsourced development.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.30_OT Outsourced development.md new file mode 100644 index 0000000..aad305b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.30_OT Outsourced development.md @@ -0,0 +1,39 @@ +## 8.30 Outsourced development + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| :--------------------- | :------------------------------------------- | :---------------------------- | :---------------------------------------------------------------------------------- | :------------------------------------ | +| #Preventive #Detective | #Confidentiality
#Integrity #Availability | #Identify #Protect
#Detect | #System_and_network_security #Application_security #Supplier_relationships_security | #Governance_and_Ecosystem #Protection | + +**Control** +The organization should direct, monitor and review the activities related to outsourced system development. + +**Purpose** +To ensure information security measures required by the organization are implemented in outsourced system development. + +**Guidance** +Where system development is outsourced, the organization should communicate and agree requirements and expectations, and continually monitor and review whether the delivery of outsourced work meets these expectations. The following points should be considered across the organization’s entire external supply chain: + +a\) licensing agreements, code ownership and intellectual property rights related to the outsourced content (see 5.32); + +b\) contractual requirements for secure design, coding and testing practices (see 8.25 to 8.29 ); + +c\) provision of the threat model to consider by external developers; + +d\) acceptance testing for the quality and accuracy of the deliverables (see 8.29); + +e\) provision of evidence that minimum acceptable levels of security and privacy capabilities are established (e.g. assurance reports); + +f\) provision of evidence that sufficient testing has been applied to guard against the presence of malicious content (both intentional and unintentional) upon delivery; + +g\) provision of evidence that sufficient testing has been applied to guard against the presence of known vulnerabilities; + +h\) escrow agreements for the software source code (e.g. if the supplier goes out of business); + +i\) contractual right to audit development processes and controls; + +j\) security requirements for the development environment (see 8.31); + +k\) taking consideration of applicable legislation (e.g. on protection of personal data). + +**Other information** +Further information on supplier relationships can be found in the ISO/IEC 27036 series. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.31_OT Separation of development, test and production environments.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.31_OT Separation of development, test and production environments.md new file mode 100644 index 0000000..5b35e6e --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.31_OT Separation of development, test and production environments.md @@ -0,0 +1,104 @@ +## 8.31 Separation of development, test and production environments + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| --- | --- | --- | --- | --- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | + +**Control** +Development, testing and production environments should be separated and secured. + +**Purpose** +To protect the production environment and data from compromise by development and test activities. + +**Guidance** +The level of separation between production, testing and development environments that is necessary to prevent production problems should be identified and implemented. + + + +The following items should be considered: + + + +a\) adequately separating development and production systems and operating them in different domains (e.g. in separate virtual or physical environments); + + + +b\) defining, documenting and implementing rules and authorization for the deployment of software from development to production status; + + + +c\) testing changes to production systems and applications in a testing or staging environment prior to being applied to production systems (see 8.29); + + + +d\) not testing in production environments except in circumstances that have been defined and approved; + + + +e\) compilers, editors and other development tools or utility programs not being accessible from production systems when not required; + + + +f\) displaying appropriate environment identification labels in menus to reduce the risk of error; + + + +g\) not copying sensitive information into the development and testing system environments unless equivalent controls are provided for the development and testing systems. + + + +In all cases, development and testing environments should be protected considering: + + + +a\) patching and updating of all the development, integration and testing tools (including builders, integrators, compilers, configuration systems and libraries); + + + +b\) secure configuration of systems and software; + + + +c\) control of access to the environments; + + + +d\) monitoring of change to the environment and code stored therein; + + + +e\) secure monitoring of the environments; + + + +f\) taking backups of the environments. + + + +A single person should not have the ability to make changes to both development and production without prior review and approval. This can be achieved for example through segregation of access rights or through rules that are monitored. In exceptional situations, additional measures such as detailed logging and real-time monitoring should be implemented in order to detect and act on unauthorized changes. + + + +**Other information** + +Without adequate measures and procedures, developers and testers having access to production systems can introduce significant risks (e.g. unwanted modification of files or system environment, system failure, running unauthorized and untested code in product ion systems, disclosure of confidential data, data integrity and availability issues). There is a need to maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access to the production environment. + + + +Measures and procedures include carefully designed roles in conjunction with implementing segregation of duty requirements and having adequate monitoring processes in place. + + + +Development and testing personnel also pose a threat to the confidentiality of production information. Development and testing activities can cause unintended changes to software or information if they share the same computing environment. Separating development, testing and production environments is therefore desirable to reduce the risk of accidental change or unauthorized access to production software and business data (see >8.33for the protection of test information). + + + +In some cases, the distinction between development, test and production environments can be deliberately blurred and testing can be carried out in a development environment or through controlled rollouts to live users or servers (e.g. small population of pilot users). In some cases, product testing can occur through live use of the product inside the organization. Furthermore, to reduce downtime of live deployments, two identical production environments can be supported where only one is live at any one time. + + + +Supporting processes for the use of production data in development and testing environments (>8.33>) are necessary. + + + +Organizations can also consider the guidance provided in this section for training environments when conducting end user training. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.32_OT Change management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.32_OT Change management.md new file mode 100644 index 0000000..879a22a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.32_OT Change management.md @@ -0,0 +1,48 @@ +#iso27002/2022/EN +## 8.32 Change management + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | + +**Control** +Changes to information processing facilities and information systems should be subject to change management procedures. + +**Purpose** +To preserve information security when executing changes. + +**Guidance** +Introduction of new systems and major changes to existing systems should follow agreed rules and a formal process of documentation, specification, testing, quality control and managed implementation. Management responsibilities and procedures should be in place to ensure satisfactory control of all changes. + +Change control procedures should be documented and enforced to ensure the confidentiality, integrity and availability of information in information processing facilities and information systems, for the entire system development life cycle from the early design stages through all subsequent maintenance efforts. + +Wherever practicable, change control procedures for ICT infrastructure and software should be integrated. + +The change control procedures should include: + +a\) planning and assessing the potential impact of changes considering all dependencies; + +b\) authorization of changes; + +c\) communicating changes to relevant interested parties; + +d\) tests and acceptance of tests for the changes (see 8.29); + +e\) implementation of changes including deployment plans; + +f\) emergency and contingency considerations including fall-back procedures; + +g\) maintaining records of changes that include all of the above; + +h\) ensuring that operating documentation (see 5.37) and user procedures are changed as necessary to remain appropriate; + +i\) ensuring that ICT continuity plans and response and recovery procedures (see 5.30) are changed as necessary to remain appropriate. + +**Other information** +Inadequate control of changes to information processing facilities and information systems is a common cause of system or security failures. Changes to the production environment, especially when transferring software from development to operational environment, can impact on the integrity and availability of applications. + +Changing software can impact the production environment and vice versa. + +Good practice includes the testing of ICT components in an environment segregated from both the production and development environments (see 8.31). This provides a means of having control over new software and allowing additional protection of operational information that is used for testing purposes. This should include patches, service packs and other updates. + +Production environment includes operating systems, databases and middleware platforms. The control should be applied for changes of applications and infrastructures. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.33_OT Test information.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.33_OT Test information.md new file mode 100644 index 0000000..29031e5 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.33_OT Test information.md @@ -0,0 +1,31 @@ +## 8.33 Test information + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ------------------------------- | ---------------------- | ------------------------ | ---------------- | +| #Preventive | #Confidentiality #Integrity | #Protect | #Information_protection | #Protection | + +**Control** +Test information should be appropriately selected, protected and managed. + +**Purpose** +To ensure relevance of testing and protection of operational information used for testing. + +**Guidance** +Test information should be selected to ensure the reliability of tests results and the confidentiality of the relevant operational information. Sensitive information (including personally identifiable information) should not be copied into the development and testing environments (see 8.31). + +The following guidelines should be applied to protect the copies of operational information, when used for testing purposes, whether the test environment is built in-house or on a cloud service: + +a\) applying the same access control procedures to test environments as those applied to operational environments; + +b\) having a separate authorization each time operational information is copied to a test environment; + +c\) logging the copying and use of operational information to provide an audit trail; + +d\) protecting sensitive information by removal or masking (see 8.11) if used for testing; + +e\) properly deleting (see 8.10) operational information from a test environment immediately after the testing is complete to prevent unauthorized use of test information. + +Test information should be securely stored (to prevent tampering, which can otherwise lead to invalid results) and only used for testing purposes. + +**Other information** +System and acceptance testing can require substantial volumes of test information that are as close as possible to operational information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.34_OT Protection of information systems during audit testing.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.34_OT Protection of information systems during audit testing.md new file mode 100644 index 0000000..6e209fe --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.34_OT Protection of information systems during audit testing.md @@ -0,0 +1,33 @@ +## 8.34 Protection of information systems during audit testing + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| --- | --- | --- | --- | --- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security #Information_protection | #Governance_and_Ecosystem #Protection | + +**Control** +Audit tests and other assurance activities involving assessment of operational systems should be planned and agreed between the tester and appropriate management. + +**Purpose** +To minimize the impact of audit and other assurance activities on operational systems and business processes. + +**Guidance** +The following guidelines should be observed: + +a\) agreeing audit requests for access to systems and data with appropriate management; + +b\) agreeing and controlling the scope of technical audit tests; + +c\) limiting audit tests to read-only access to software and data. If read-only access is not available to obtain the necessary information, executing the test by an experienced administrator who has the necessary access rights on behalf of the auditor; + +d\) if access is granted, establishing and verifying the security requirements (e.g. antivirus and patching) of the devices used for accessing the systems (e.g. laptops or tablets) before allowing the access; + +e\) only allowing access other than read-only for isolated copies of system files, deleting them when the audit is completed, or giving them appropriate protection if there is an obligation to keep such files under audit documentation requirements; + +f\) identifying and agreeing on requests for special or additional processing, such as running audit tools; + +g\) running audit tests that can affect system availability outside business hours; + +h\) monitoring and logging all access for audit and test purposes. + +**Other information** +Audit tests and other assurance activities can also happen on development and test systems, where such tests can impact for example the integrity of code or lead to disclosure of any sensitive information held in such environments. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.3_OT Information access restriction.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.3_OT Information access restriction.md new file mode 100644 index 0000000..1ef746b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.3_OT Information access restriction.md @@ -0,0 +1,53 @@ +## 8.3 Information access restriction + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | + +**Control** +Access to information and other associated assets should be restricted in accordance with the established topic-specific policy on access control. + +**Purpose** +To ensure only authorized access and to prevent unauthorized access to information and other associated assets. + +**Guidance** +Access to information and other associated assets should be restricted in accordance with the established topic-specific policies. The following should be considered in order to support access restriction requirements: + +a\) not allowing access to sensitive information by unknown user identities or anonymously. Public or anonymous access should only be granted to storage locations that do not contain any sensitive information; +b\) providing configuration mechanisms to control access to information in systems, applications and services; +c\) controlling which data can be accessed by a particular user; +d\) controlling which identities or group of identities have which access, such as read, write, delete and execute; +e\) providing physical or logical access controls for the isolation of sensitive applications, application data, or systems. + +Further, dynamic access management techniques and processes to protect sensitive information that has high value to the organization should be considered when the organization: + +a\) needs granular control over who can access such information during what period and in what way; +b\) wants to share such information with people outside the organization and maintain control over who can access it; +c\) wants to dynamically manage, in real-time, the use and distribution of such information; +d\) wants to protect such information against unauthorized changes, copying and distribution (including printing); +e\) wants to monitor the use of the information; +f\) wants to record any changes to such information that take place in case a future investigation is required. + +Dynamic access management techniques should protect information throughout its life cycle (i.e. creation, processing, storage, transmission and disposal), including: + +a\) establishing rules on the management of dynamic access based on specific use cases considering: +1\) granting access permissions based on identity, device, location or application; +2\) leveraging the classification scheme in order to determine what information needs to be protected with dynamic access management techniques; + +b\) establishing operational, monitoring and reporting processes and supporting technical infrastructure. + +Dynamic access management systems should protect information by: + +a\) requiring authentication, appropriate credentials or a certificate to access information; +b\) restricting access, for example to a specified time frame (e.g. after a given date or until a particular date); +c\) using encryption to protect information; +d\) defining the printing permissions for the information; +e\) recording who accesses the information and how the information is used; +f\) raising alerts if attempts to misuse the information are detected. + +**Other information** +Dynamic access management techniques and other dynamic information protection technologies can support the protection of information even when data is shared beyond the originating organization, where traditional access controls cannot be enforced. It can be applied to documents, emails or other files containing information to limit who can access the content and in what way. It can be at a granular level and be adapted over the life cycle of the information. + +Dynamic access management techniques do not replace classical access management \[e.g. using access control lists (ACLs)\], but can add more factors for conditionality, real-time evaluation, just-in-time data reduction and other enhancements that can be useful for the most sensitive information. It offers a way to control access outside the organization’s environment. Incident response can be supported by dynamic access management techniques as permissions can be modified or revoked at any time. + +Additional information on a framework for access management is provided in ISO/IEC 29146. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.4_OT Access to source code.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.4_OT Access to source code.md new file mode 100644 index 0000000..7beb0cb --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.4_OT Access to source code.md @@ -0,0 +1,32 @@ +## 8.4 Access to source code + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | --------------------------------------------------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management #Application_security #Secure_configuration | #Protection | + +**Control** +Read and write access to source code, development tools and software libraries should be appropriately managed. + +**Purpose** +To prevent the introduction of unauthorized functionality, avoid unintentional or malicious changes and to maintain the confidentiality of valuable intellectual property. + +**Guidance** +Access to source code and associated items (such as designs, specifications, verification plans and validation plans) and development tools (e.g. compilers, builders, integration tools, test platforms and environments) should be strictly controlled. + +For source code, this can be achieved by controlling central storage of such code, preferably in source code management system. + +Read access and write access to source code can differ based on the personnel’s role. For example, read access to source code can be broadly provided inside the organization, but write access to source code is only made available to privileged personnel or designated owners. Where code components are used by several developers within an organization, read access to a centralized code repository should be implemented. Furthermore, if open-source code or third-party code components are used inside an organization, read access to such external code repositories can be broadly provide d. However, write access should still be restricted. + +The following guidelines should be considered to control access to program source libraries in order to reduce the potential for corruption of computer programs: + +a\) managing the access to program source code and the program source libraries according to established procedures; +b\) granting read and write access to source code based on business needs and managed to address risks of alteration or misuse and according to established procedures; +c\) updating of source code and associated items and granting of access to source code in accordance with change control procedures (see 8.32) and only performing it after appropriate authorization has been received; +d\) not granting developers direct access to the source code repository, but through developer tools that control activities and authorizations on the source code; +e\) holding program listings in a secure environment, where read and write access should be appropriately managed and assigned; +f\) maintaining an audit log of all accesses and of all changes to source code. + +If the program source code is intended to be published, additional controls to provide assurance on its integrity (e.g. digital signature) should be considered. + +**Other information** +If access to source code is not properly controlled, source code can be modified or some data in the development environment (e.g. copies of production data, configuration details) can be retrieved by unauthorized persons. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.5_OT Secure authentication.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.5_OT Secure authentication.md new file mode 100644 index 0000000..6355aa3 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.5_OT Secure authentication.md @@ -0,0 +1,42 @@ +#iso27002/2022/EN + +## 8.5 Secure authentication + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | + +**Control** +Secure authentication technologies and procedures should be implemented based on information access restrictions and the topic-specific policy on access control. + +**Purpose** +To ensure a user or an entity is securely authenticated, when access to systems, applications and services is granted. + +**Guidance** +A suitable authentication technique should be chosen to substantiate the claimed identity of a user, software, messages and other entities. + +The strength of authentication should be appropriate for the classification of the information to be accessed. Where strong authentication and identity verification is required, authentication methods alternative to passwords, such as digital certificates, smart cards, tokens or biometric means, should be used. + +Authentication information should be accompanied by additional authentication factors for accessing critical information systems (also known as multi-factor authentication). Using a combination of multiple authentication factors, such as what you know, what you have and what you are, reduces the possibilities for unauthorized accesses. Multi-factor authentication can be combine d with other techniques to require additional factors under specific circumstances, based on predefined rules and patterns, such as access from an unusual location, from an unusual device or at an unusual time. + +Biometric authentication information should be invalidated if it is ever compromised. Biometric authentication can be unavailable depending on the conditions of use (e.g. moisture or aging). To prepare for these issues, biometric authentication should be accompanied with at least one alternative authentication technique. + +The procedure for logging into a system or application should be designed to minimize the risk of unauthorized access. Log-on procedures and technologies should be implemented considering the following: + +a\) not displaying sensitive system or application information until the log-on process has been successfully completed in order to avoid providing an unauthorized user with any unnecessary assistance; +b\) displaying a general notice warning that the system or the application or the service should only be accessed by authorized users; +c\) not providing help messages during the log-on procedure that would aid an unauthorized user (e.g. if an error condition arises, the system should not indicate which part of the data is correct or incorrect); +d\) validating the log-on information only on completion of all input data; +e\) protecting against brute force log-on attempts on usernames and passwords \[e.g. using completely automated public Turing test to tell computers and humans apart (CAPTCHA), requiring password reset after a predefined number of failed attempts or blocking the user after a maximum number of errors\]; +f\) logging unsuccessful and successful attempts; +g\) raising a security event if a potential attempted or successful breach of log-on controls is detected (e.g. sending an alert to the user and the organization’s system administrators when a certain number of wrong password attempts has been reached); +h\) displaying or sending the following information on a separate channel on completion of a successful log-on: + 1\) date and time of the previous successful log-on; + 2\) details of any unsuccessful log-on attempts since the last successful log-on; +i\) not displaying a password in clear text when it is being entered; in some cases, it can be required to de-activate this functionality in order to facilitate user log-on (e.g. for accessibility reasons or to avoid blocking users because of repeated errors); +j\) not transmitting passwords in clear text over a network to avoid being captured by a network "sniffer” program; +k\) terminating inactive sessions after a defined period of inactivity, especially in high risk locations such as public or external areas outside the organization’s security management or on user endpoint devices; +l\) restricting connection duration times to provide additional security for high-risk applications and reduce the window of opportunity for unauthorized access. + +**Other information** +Additional information on entity authentication assurance can be found is ISO/IEC 29115. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.6_OT Capacity management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.6_OT Capacity management.md new file mode 100644 index 0000000..516cb86 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.6_OT Capacity management.md @@ -0,0 +1,47 @@ +## 8.6 Capacity management + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ---------------------- | ------------------------------- | -------------------------- | ------------------------ | ------------------------------------- | +| #Preventive #Detective | #Integrity #Availability | #Identify #Protect #Detect | #Continuity | #Governance_and_Ecosystem #Protection | + +**Control** +The use of resources should be monitored and adjusted in line with current and expected capacity requirements. + +**Purpose** +To ensure the required capacity of information processing facilities, human resources, offices and other facilities. + +**Guidance** +Capacity requirements for information processing facilities, human resources, offices and other facilities should be identified, taking into account the business criticality of the concerned systems and processes. + +System tuning and monitoring should be applied to ensure and, where necessary, improve the availability and efficiency of systems. + +The organization should perform stress-tests of systems and services to confirm that sufficient system capacity is available to meet peak performance requirements. + +Detective controls should be put in place to indicate problems in due time. + +Projections of future capacity requirements should take account of new business and system requirements and current and projected trends in the organization’s information processing capabilities. + +Particular attention should be paid to any resources with long procurement lead times or high costs. Therefore, managers, service or product owners should monitor the utilization of key system resources. + +Managers should use capacity information to identify and avoid potential resource limitations and dependency on key personnel which can present a threat to system security or services and plan appropriate action. + +Providing sufficient capacity can be achieved by increasing capacity or by reducing demand. The following should be considered to increase capacity: + +a\) hiring new personnel; +b\) obtaining new facilities or space; +c\) acquiring more powerful processing systems, memory and storage; +d\) making use of cloud computing, which has inherent characteristics that directly address issues of capacity. Cloud computing has elasticity and scalability which enable on-demand rapid expansion and reduction in resources available to particular applications and services. + +The following should be considered to reduce demand on the organization’s resources: + +a\) deletion of obsolete data (disk space); +b\) disposal of hardcopy records that have met their retention period (free up shelving space); +c\) decommissioning of applications, systems, databases or environments; +d\) optimizing batch processes and schedules; +e\) optimizing application code or database queries; +f\) denying or restricting bandwidth for resource-consuming services if these are not critical (e.g. video streaming). + +A documented capacity management plan should be considered for mission critical systems. + +**Other information** +For more detail on the elasticity and scalability of cloud computing, see ISO/IEC TS 23167. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.7_OT Protection against malware.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.7_OT Protection against malware.md new file mode 100644 index 0000000..d8b221b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.7_OT Protection against malware.md @@ -0,0 +1,57 @@ +#iso27002/2022/EN + +# 8.7  Protection against malware + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ---------------------------------- | ----------------------------------------- | ---------------------- | ---------------------------------------------------- | -------------------- | +| #Preventive #Detective #Corrective | #Confidentiality #Integrity #Availability | #Protect #Detect | #System_and_network_security #Information_protection | #Protection #Defence | +## Control +Protection against malware should be implemented and supported by appropriate user awareness. +## Purpose +To ensure information and other associated assets are protected against malware. +## Guidance +Protection against malware should be based on malware detection and repair software, information security awareness, appropriate system access and change management controls. Use of malware detection and repair software alone is not usually adequate. The following guidance should be considered: + +a)   implementing rules and controls that prevent or detect the use of unauthorized software \[e.g. application allowlisting (i.e. using a list providing allowed applications)] (see [[ISO_27002_OT 8.19 Installation of software on operational systems|8.19]] and [[ISO_27002_OT 8.32 Change management|8.32]]) + +b)   implementing controls that prevent or detect the use of known or suspected malicious websites (e.g. blocklisting); + +c)   reducing vulnerabilities that can be exploited by malware \[e.g. through technical vulnerability management (see [[ISO_27002_OT 8.8 Management of technical vulnerabilities|8.8]] and [[ISO_27002_OT 8.19 Installation of software on operational systems|8.19]])]; + +d)   conducting regular automated validation of the software and data content of systems, especially for systems supporting critical business processes; investigating the presence of any unapproved files or unauthorized amendments; + +e)   establishing protective measures against risks associated with obtaining files and software either from or via external networks or on any other medium; + +f)   installing and regularly updating malware detection and repair software to scan computers and electronic storage media. Carrying out regular scans that include: + +1)   scanning any data received over networks or via any form of electronic storage media, for malware before use; + +2)   scanning email and instant messaging attachments and downloads for malware before use. Carrying out this scan at different places (e.g. at email servers, desktop computers) and when entering the network of the organization; + +3)   scanning webpages for malware when accessed; + +g)   determining the placement and configuration of malware detection and repair tools based on risk assessment outcomes and considering: + +1)   defence in depth principles where they would be most effective. For example, this can lead to malware detection in a network gateway (in various application protocols such as email, file transfer and web) as well as user endpoint devices and servers; +2)   the evasive techniques of attackers (e.g. the use of encrypted files) to deliver malware or the use of encryption protocols to transmit malware; + +h)   taking care to protect against the introduction of malware during maintenance and emergency procedures, which can bypass normal controls against malware; + +i) implementing a process to authorize temporarily or permanently disable some or all measures against malware, including exception approval authorities, documented justification and review date. This can be necessary when the protection against malware causes disruption to normal operations; + +j) preparing appropriate business continuity plans for recovering from malware attacks, including +all necessary data and software backup (including both online and offline backup) and recovery measures (see [[ISO_27002_OT 8.13 Information backup|8.13]]); + +k)   isolating environments where catastrophic consequences can occur; + +l) defining procedures and responsibilities to deal with protection against malware on systems, including training in their use, reporting and recovering from malware attacks; + +m)  providing awareness or training (see [[ISO_27002_OT 6.3 Information security awareness, education and training|6.3]]) to all users on how to identify and potentially mitigate the receipt, sending or installation of malware infected emails, files or programs \[the information collected in n) and o) can be used to ensure awareness and training are kept up-to-date]; + +n)   implementing procedures to regularly collect information about new malware, such as subscribing to mailing lists or reviewing relevant websites; + +o)   verifying that information relating to malware, such as warning bulletins, comes from qualified and reputable sources (e.g. reliable internet sites or suppliers of malware detection software) and is accurate and informative. + +## Other **information** + +It is not always possible to install software that protects against malware on some systems (e.g. some industrial control systems). Some forms of malware infect computer operating systems and computer firmware such that common malware controls cannot clean the system and a full reimaging of the operating system software and sometimes the computer firmware is necessary to return to a secure state. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md new file mode 100644 index 0000000..72884b4 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md @@ -0,0 +1,130 @@ +#iso27002/2022/EN +## 8.8 Management of technical vulnerabilities + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------------------ | ---------------------------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Threat_and_vulnerability_management | #Governance_and_Ecosystem #Protection #Defence | + +**Control** +Information about technical vulnerabilities of information systems in use should be obtained, the organization’s exposure to such vulnerabilities should be evaluated and appropriate measures should be taken. + +**Purpose** +To prevent exploitation of technical vulnerabilities. + +**Guidance** + +Identifying technical vulnerabilities + +The organization should have an accurate inventory of assets (see 5.9 to 5.14) as a prerequisite for effective technical vulnerability management; the inventory should include the software vendor, software name, version numbers, current state of deployment (e.g. what software is installed on what systems) and the person(s) within the organization responsible for the software. + +To identify technical vulnerabilities, the organization should consider: + +a\) defining and establishing the roles and responsibilities associated with technical vulnerability management, including vulnerability monitoring, vulnerability risk assessment, updating, asset tracking and any coordination responsibilities required; +b\) for software and other technologies (based on the asset inventory list, see 5.9), identifying information resources that will be used for identifying relevant technical vulnerabilities and maintaining awareness about them. Updating the list of information resources based on changes in the inventory or when other new or useful resources are found; +c\) requiring suppliers of information system (including their components) to ensure vulnerability reporting, handling and disclosure, including the requirements in applicable contracts (see 5.20); +d\) using vulnerability scanning tools suitable for the technologies in use to identify vulnerabilities and to verify whether the patching of vulnerabilities was successful; +e\) conducting planned, documented and repeatable penetration tests or vulnerability assessments by competent and authorized persons to support the identification of vulnerabilities. Exercising caution as such activities can lead to a compromise of the security of the system; +f\) tracking the usage of third-party libraries and source code for vulnerabilities. This should be included in secure coding (see 8.28). + +The organization should develop procedures and capabilities to: + +a\) detect the existence of vulnerabilities in its products and services including any external component used in these; +b\) receive vulnerability reports from internal or external sources. + +The organization should provide a public point of contact as part of a topic-specific policy on vulnerability disclosure so that researchers and others are able to report issues. The organization should establish vulnerability reporting procedures, online reporting forms and making use of appropriate threat intelligence or information sharing forums. The organization should also consider bug bounty programs where rewards are offered as an incentive to assist organizations in identifying vulnerabilities in order to appropriately remediate them. The organization should also share information with competent industry bodies or other interested parties. + +Evaluating technical vulnerabilities + +To evaluate identified technical vulnerabilities, the following guidance should be considered: + +a\) analyse and verify reports to determine what response and remediation activity is needed; +b\) once a potential technical vulnerability has been identified, identifying the associated risks and the actions to be taken. Such actions can involve updating vulnerable systems or applying other controls. + +Taking appropriate measures to address technical vulnerabilities + +A software update management process should be implemented to ensure the most up-to-date approved patches and application updates are installed for all authorized software. If changes are necessary, the original software should be retained and the changes applied to a designated copy. All changes should be fully tested and documented, so that they can be reapplied, if necessary, to future software upgrades. If required, the modifications should be tested and validated by an independent evaluation body. + +The following guidance should be considered to address technical vulnerabilities: + +a\) taking appropriate and timely action in response to the identification of potential technical vulnerabilities; defining a timeline to react to notifications of potentially relevant technical vulnerabilities; +b\) depending on how urgently a technical vulnerability needs to be addressed, carrying out the action according to the controls related to change management (see 8.32) or by following information security incident response procedures (see 5.26); +c\) only using updates from legitimate sources (which can be internal or external to the organization); +d\) testing and evaluating updates before they are installed to ensure they are effective and do not result in side effects that cannot be tolerated \[i.e. if an update is available, assessing the risks associated with installing the update (the risks posed by the vulnerability should be compared with the risk of installing the update)\]; +e\) addressing systems at high risk first; +f\) develop remediation (typically software updates or patches); +g\) test to confirm if the remediation or mitigation is effective; +h\) provide mechanisms to verify the authenticity of remediation; + +i\) if no update is available or the update cannot be installed, considering other controls, such as: +1\) applying any workaround suggested by the software vendor or other relevant sources; +2\) turning off services or capabilities related to the vulnerability; +3\) adapting or adding access controls (e.g. firewalls) at network borders (see 8.20to 8.22); +4\) shielding vulnerable systems, devices or applications from attack through deployment of suitable traffic filters (sometimes called virtual patching); +5\) increasing monitoring to detect actual attacks; +6\) raising awareness of the vulnerability. + +For acquired software, if the vendors regularly release information about security updates for their software and provide a facility to install such updates automatically, the organization should decide whether to use the automatic update or not. + + + +Other considerations + + + +An audit log should be kept for all steps undertaken in technical vulnerability management. + + + +The technical vulnerability management process should be regularly monitored and evaluated in order to ensure its effectiveness and efficiency. + + + +An effective technical vulnerability management process should be aligned with incident management activities, to communicate data on vulnerabilities to the incident response function and provide technical procedures to be carried out in case an incident occurs. + + + +Where the organization uses a cloud service supplied by a third-party cloud service provider, technical vulnerability management of cloud service provider resources should be ensured by the cloud service provider. The cloud service provider’s responsibilities for technical vulnerability management should be part of the cloud service agreement and this should include processes for reporting the cloud service provider's actions relating to technical vulnerabilities (see 5.23). For some cloud services, there are respective responsibilities for the cloud service provider and the cloud service customer. For example, the cloud service customer is responsible for vulnerability management of its own assets used for the cloud services. + + + +**Other information** + + + +Technical vulnerability management can be viewed as a sub-function of change management and as such can take advantage of the change management processes and procedures (see 8.32). + + + +There is a possibility that an update does not address the problem adequately and has negative side effects. Also, in some cases, uninstalling an update cannot be easily achieved once the update has been applied. + + + +If adequate testing of the updates is not possible (e.g. because of costs or lack of resources) a delay in updating can be considered to evaluate the associated risks, based on the experience reported by other users. The use of ISO/IEC 27031 can be beneficial. + + + +Where software patches or updates are produced, the organization can consider providing an automated update process where these updates are installed on affected systems or products without the need for intervention by the customer or the user. If an automated update process is offered, it can allow the customer or user to choose an option to turn off the automatic update or control the timing of the installation of the update. + + + +Where the vendor provides an automated update process and the updates can be installed on affected systems or products without the need for intervention, the organization determines if it applies the automated process or not. One reason for not electing for automated update is to retain control over when the update is performed. For example, a software used for a business operation cannot be updated until the operation has completed. + + + +A weakness with vulnerability scanning is that it is possible it does not fully account for defence in depth: two countermeasures that are always invoked in sequence can have vulnerabilities that are masked by strengths in the other. The composite countermeasure is not vulnerable, whereas a vulnerability scanner can report that both components are vulnerable. The organization should therefore take care in reviewing and acting on vulnerability reports. + + + +Many organizations supply software, systems, products and services not only within the organization but also to interested parties such as customers, partners or other users. These software, systems, products and services can have information security vulnerabilities that affect the security of users. + + + +Organizations can release remediation and disclose information about vulnerabilities to users (typically through a public advisory) and provide appropriate information for software vulnerability database services. + + + +For mor e information relating to the management of technical vulnerabilities when using cloud computing, see the ISO/IEC 19086 series and ISO/IEC 27017. + + + +ISO/IEC 29147 provides detailed information on receiving vulnerability reports and publishing vulnerability advisories. ISO/IEC 30111 provides detailed information about handling and resolving reported vulnerabilities. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.9_OT Configuration management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.9_OT Configuration management.md new file mode 100644 index 0000000..722e1a7 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.9_OT Configuration management.md @@ -0,0 +1,74 @@ +#iso27002/2022/EN +## 8.9 Configuration management +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | ------------------------ | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Secure_configuration | #Protection | +### Control +Configurations, including security configurations, of hardware, software, services and networks should be established, documented, implemented, monitored and reviewed. +### Purpose +To ensure hardware, software, services and networks function correctly with required security settings, and configuration is not altered by unauthorized or incorrect changes. +### Guidance + +#### General +The organization should define and implement processes and tools to enforce the defined configurations (including security configurations) for hardware, software, services (e.g. cloud services) and networks, for newly installed systems as well as for operational systems over their lifetime. + +Roles, responsibilities and procedures should be in place to ensure satisfactory control of all configuration changes. +#### Standard templates + +Standard templates for the secure configuration of hardware, software, services and networks should be defined: + +a) using publicly available guidance (e.g. pre-defined templates from vendors and from independent security organizations); + +b) considering the level of protection needed in order to determine a sufficient level of security; + +c) supporting the organization’s information security policy, topic-specific policies, standards and other security requirements; + +d) considering the feasibility and applicability of security configurations in the organization’s context. + +The templates should be reviewed periodically and updated when new threats or vulnerabilities need to be addressed, or when new software or hardware versions are introduced. + +The following should be considered for establishing standard templates for the secure configuration of hardware, software, services and networks: + +a) minimizing the number of identities with privileged or administrator level access rights; + +b) disabling unnecessary, unused or insecure identities; + +c) disabling or restricting unnecessary functions and services; + +d) restricting access to powerful utility programs and host parameter settings; + +e) synchronizing clocks; + +f) changing vendor default authentication information such as default passwords immediately after installation and reviewing other important default security-related parameters; + +g) invoking time-out facilities that automatically log off computing devices after a predetermined period of inactivity; + +h) verifying that license requirements have been met (see 5.32). +#### Managing configurations +Established configurations of hardware, software, services and networks should be recorded and a log should be maintained of all configuration changes. These records should be securely stored. This can be achieved in various ways, such as configuration databases or configuration templates. + +Changes to configurations should follow the change management process (see 8.32). + +Configuration records can contain as relevant: + +a) up-to-date owner or point of contact information for the asset; + +b) date of the last change of configuration; + +c) version of configuration template; + +d) relation to configurations of other assets. +#### Monitoring configurations +Configurations should be monitored with a comprehensive set of system management tools (e.g. maintenance utilities, remote support, enterprise management tools, backup and restore software) and should be reviewed on a regular basis to verify configuration settings, evaluate password strengths and assess activities performed. Actual configurations can be compared with the defined target templates. Any deviations should be addressed, either by automatic enforcement of the defined target configuration or by manual analysis of the deviation followed by corrective actions. +### Other information +Documentation for systems often records details about the configuration of both hardware and software. + +System hardening is a typical part of configuration management. + +Configuration management can be integrated with asset management processes and associated tooling. + +Automation is usually more effective to manage security configuration (e.g. using infrastructure as code). + +Configuration templates and targets can be confidential information and should be protected from unauthorized access accordingly. +# Related: +- [[ISO_27002_2022_8.9_MoC Configuration management|8.9 Configuration management]] diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.1 Policies for information security.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.1 Policies for information security.md new file mode 100644 index 0000000..c16d528 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.1 Policies for information security.md @@ -0,0 +1,77 @@ +#iso27002/2022/EN +## 5.1 Policies for information security + +#### Control +Information security policy and topic-specific policies should be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur. + +#### Purpose +To ensure continuing suitability, adequacy, effectiveness of management direction and support for information security in accordance with business, legal, statutory, regulatory and contractual requirements. + +#### Guidance +At the highest level, the organization should define an “information security policy” which is approved by top management and which sets out the organization’s approach to managing its information security. + +The information security policy should take into consideration requirements derived from: + +a) business strategy and requirements; +b) regulations, legislation and contracts; +c) the current and projected information security risks and threats. + +The information security policy should contain statements concerning: + +a) definition of information security; +b) information security objectives or the framework for setting information security objectives; +c) principles to guide all activities relating to information security; +d) commitment to satisfy applicable requirements related to information security; +e) commitment to continual improvement of the information security management system; +f) assignment of responsibilities for information security management to defined roles; +g) procedures for handling exemptions and exceptions. + +Top management should approve any changes to the information security policy. + +At a lower level, the information security policy should be supported by topic-specific policies as needed, to further mandate the implementation of information security controls. Topic-specific policies are typically structured to address the needs of certain target groups within an organization or to cover certain security areas. Topic-specific policies should be aligned with and complementary to the information security policy of the organization. + +Examples of such topics include: + +a) access control; +b) physical and environmental security; +c) asset management; +d) information transfer; +e) secure configuration and handling of user endpoint devices; +f) networking security; +g) information security incident management; +h) backup; +i) cryptography and key management; +j) information classification and handling; +k) management of technical vulnerabilities; +l) secure development. + +The responsibility for the development, review and approval of the topic-specific policies should be allocated to relevant personnel based on their appropriate level of authority and technical competency. The review should include assessing opportunities for improvement of the organization’s information security policy and topic-specific policies and managing information security in response to changes to: + +a) the organization’s business strategy; +b) the organization’s technical environment; +c) regulations, statutes, legislation and contracts; +d) information security risks; +e) the current and projected information security threat environment; +f) lessons learned from information security events and incidents. + +The review of information security policy and topic-specific policies should take the results of management reviews and audits into account. Review and update of other related policies should be considered when one policy is changed to maintain consistency. + +The information security policy and topic-specific policies should be communicated to relevant personnel and interested parties in a form that is relevant, accessible and understandable to the intended reader. Recipients of the policies should be required to acknowledge they understand and agree to comply with the policies where applicable. The organization can determine the formats and names of these policy documents that meet the organization’s needs. In some organizations, the information security policy and topic-specific policies can be in a single document. The organization can name these topic-specific policies as standards, directives, policies or others. + +If the information security policy or any topic-specific policy is distributed outside the organization, care should be taken not to improperly disclose confidential information. + +Table 1 illustrates the differences between information security policy and topic-specific policy. + +*Table 1* | Information security policy | Topic-specific policy +------- | --------------------------- | --------------------- +Level of detail | General or high-level | Specific and detailed +Documented and formally approved by | Top management | Appropriate level of management + + +#### Other information +Topic-specific policies can vary across organizations. + + +# Related +- [[ISO_27002_PE 5.1 Policies for information security]] + diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.12 Classification of information.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.12 Classification of information.md new file mode 100644 index 0000000..345523b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.12 Classification of information.md @@ -0,0 +1 @@ +#iso27002/2022/EN diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.15 Access control.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.15 Access control.md new file mode 100644 index 0000000..345523b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.15 Access control.md @@ -0,0 +1 @@ +#iso27002/2022/EN diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.17 Authentication information.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.17 Authentication information.md new file mode 100644 index 0000000..2c0bb5a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.17 Authentication information.md @@ -0,0 +1,74 @@ +#iso27002/2022/EN +## 5.17 Authentication information + +### Control +Allocation and management of authentication information should be controlled by a management process, including advising personnel on the appropriate handling of authentication information. + +### Purpose +To ensure proper entity authentication and prevent failures of authentication processes. + +### Guidance + +**Allocation of authentication information** + +The allocation and management process should ensure that: + +a)   personal passwords or personal identification numbers (PINs) generated automatically during enrolment processes as temporary secret authentication information are non-guessable and unique for each person, and that users are required to change them after the first use; + +b)   procedures are established to verify the identity of a user prior to providing new, replacement or temporary authentication information; + +c)   authentication  information,  including  temporary  authentication  information,  is  transmitted to users in a secure manner (e.g. over an authenticated and protected channel) and the use of unprotected (clear text) electronic mail messages for this purpose is avoided; + +d)   users acknowledge receipt of authentication information; + +e)   default authentication information as predefined or provided by vendors is changed immediately following installation of systems or software; + +f)   records of significant events concerning allocation and management of authentication information are kept and their confidentiality is granted, and that the record-keeping method is approved (e.g. by using an approved password vault tool). + +**User responsibilities** + +Any person having access to or using authentication information should be advised to ensure that: + +a)   secret  authentication  information  such  as  passwords  are  kept  confidential.  Personal  secret authentication information is not to be shared with anyone. Secret authentication information used in the context of identities linked to multiple users or linked to non-personal entities are solely shared with authorized persons; + +b)   affected or compromised authentication information is changed immediately upon notification of or any other indication of a compromise; + +c)   when passwords are used as authentication information, strong passwords according to best practice recommendations are selected, for example: +1)   passwords are not based on anything somebody else can easily guess or obtain using personrelated information (e.g. names, telephone numbers and dates of birth); +2)   passwords are not based on dictionary words or combinations thereof; +3)   use easy to remember passphrases and try to include alphanumerical and special characters; +4)   passwords have a minimum length; + +d)   the same passwords are not used across distinct services and systems; + +e)   the obligation to follow these rules is also included in terms and conditions of employment (see 6.2). + +**Password management system** + +When passwords are used as authentication information, the password management system should: + +a)   allow users to select and change their own passwords and include a confirmation procedure to address input errors; + +b)   enforce  strong  passwords  according  to  good  practice  recommendations \[see  c)  of  "User responsibilities"\]; + +c)   force users to change their passwords at first login; + +d)   enforce password changes as necessary, for example after a security incident, or upon termination or change of employment when a user has known passwords for identities that remain active (e.g. shared identities); + +e)   prevent re-use of previous passwords; + +f)   prevent  the  use  of  commonly-used  passwords  and  compromised  usernames,  password combinations from hacked systems; + +g)   not display passwords on the screen when being entered; + +h)   store and transmit passwords in protected form. + +Password  encryption  and  hashing  should  be  performed  according  to  approved  cryptographic techniques for passwords (see 8.24). + +**Other** **information** + +Passwords or passphrases are a commonly used type of authentication information and are a common means of verifying a user’s identity. Other types of authentication information are cryptographic keys, data stored on hardware tokens (e.g. smart cards) that produce authentication codes and biometric data such as iris scans or fingerprints. Additional information can be found in the ISO/IEC 24760 series. + +Requiring frequent change of passwords can be problematic because users can get annoyed by the frequent changes, forget new passwords, note them down in unsafe places, or choose unsafe passwords. Provision of single sign on (SSO) or other authentication management tools (e.g. password vaults) reduces the amount of authentication information that users are required to protect and can thereby increase the effectiveness of this control. However, these tools can also increase the impact of disclosure of authentication information. + +Some applications require user passwords to be assigned by an independent authority. In such cases, a), c) and d) of "Password management system" do not apply. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.19 Information security in supplier relationships.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.19 Information security in supplier relationships.md new file mode 100644 index 0000000..11664ac --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.19 Information security in supplier relationships.md @@ -0,0 +1,71 @@ +#iso27002/2022/EN +## 5.19 Information security in supplier relationships + +**Control** + +Processes and procedures should be defined and implemented to manage the information security risks associated with the use of supplier’s products or services. + +**Purpose** + +To maintain an agreed level of information security in supplier relationships. + +**Guidance** + +The organization should establish and communicate a topic-specific policy on supplier relationships to all relevant interested parties. + +The organization should identify and implement processes and procedures to address security risks associated with the use of products and services provided by suppliers. This should also apply to the organization’s use of resources of cloud service providers. These processes and procedures should include those to be implemented by the organization, as well as those the organization requires the supplier to implement for the commencement of use of a supplier’s products or services or for the termination of use of a supplier’s products and services, such as: + +a\) identifying and documenting the types of suppliers (e.g. ICT services, logistics, utilities, financial services, ICT infrastructure components) which can affect the confidentiality, integrity and availability of the organization's information; + +b\) establishing how to evaluate and select suppliers according to the sensitivity of information, products and services (e.g. with market analysis, customer references, review of documents, on-site assessments, certifications); + +c\) evaluating and selecting supplier’s products or services that have adequate information security controls and reviewing them; in particular, accuracy and completeness of controls implemented by the supplier that ensure integrity of the supplier’s information and information processing and hence the organization’s information security; + +d\) defining the organization’s information, ICT services and the physical infrastructure that suppliers can access, monitor, control or use; + +e\) defining the types of ICT infrastructure components and services provided by suppliers which can affect the confidentiality, integrity and availability of the organization's information; + +f\) assessing and managing the information security risks associated with: + 1\) the suppliers’ use of the organization’s information and other associated assets, including risks originating from potential malicious supplier personnel; + 2\) malfunctioning or vulnerabilities of the products (including software components and sub-components used in these products) or services provided by the suppliers; + +g\) monitoring compliance with established information security requirements for each type of supplier and type of access, including third-party review and product validation; + +h\) mitigating non-compliance of a supplier, whether this was detected through monitoring or by other means; + +i\) handling incidents and contingencies associated with supplier products and services including responsibilities of both the organization and suppliers; + +j\) resilience and, if necessary, recovery and contingency measures to ensure the availability of the supplier’s information and information processing and hence the availability of the organization’s information; + +k\) awareness and training for the organization’s personnel interacting with supplier personnel regarding appropriate rules of engagement, topic-specific policies, processes and procedures and behaviour based on the type of supplier and the level of supplier access to the organization’s systems and information; + +l\) managing the necessary transfer of information, other associated assets and anything else that needs to be changed and ensuring that information security is maintained throughout the transfer period; + +m\) requirements to ensure a secure termination of the supplier relationship, including: + + 1\) de-provisioning of access rights; + 2\) information handling; + 3\) determining ownership of intellectual property developed during the engagement; + 4\) information portability in case of change of supplier or insourcing; + 6\) records management; + 7\) return of assets; + 8\) secure disposal of information and other associated assets; + 9\) ongoing confidentiality requirements; + +n\) level of personnel security and physical security expected from supplier's personnel and facilities. + +The procedures for continuing information processing in the event that the supplier becomes unable to supply its products or services (e.g. because of an incident, because the supplier is no longer in business, or no longer provides some components due to technology advancements) should be considered to avoid any delay in arranging replacement products or services (e.g. identifying an alternative supplier in advance or always using alternative suppliers). + +**Other information** + +In cases where it is not possible for an organization to place requirements on a supplier, the organization should: + +a\) consider the guidance given in this control in making decisions about choosing a supplier and its product or service; + +b\) implement compensating controls as necessary based on a risk assessment. + +Information can be put at risk by suppliers with inadequate information security management. Controls should be determined and applied to manage the supplier's access to information and other associated assets. For example, if there is a special need for confidentiality of the information, non-disclosure agreements or cryptographic techniques can be used. Another example is personal data protection risks when the supplier agreement involves transfer of, or access to, information across borders. The organization needs to be aware that the legal or contractual responsibility for protecting information remains with the organization. + +Risks can also be caused by inadequate controls of ICT infrastructure components or services provided by suppliers. Malfunctioning or vulnerable components or services can cause information security breaches in the organization or to another entity (e.g. they can cause malware infection, attacks or other harm on entities other than the organization). + +See ISO/IEC 27036-2 for more detail. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.2 Information security roles and responsibilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.2 Information security roles and responsibilities.md new file mode 100644 index 0000000..de3c53a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.2 Information security roles and responsibilities.md @@ -0,0 +1,27 @@ +#iso27002/2022/EN +## 5.2 Information security roles and responsibilities + +### Control +Information security roles and responsibilities should be defined and allocated according to the organization needs. + +### Purpose +To establish a defined, approved and understood structure for the implementation, operation and management of information security within the organization. + +### Guidance +Allocation of information security roles and responsibilities should be done in accordance with the information security policy and topic-specific policies (see [[ISO_27002_OT 5.1 Policies for information security\|5.1]]). The organization should define and manage responsibilities for: + +a)   protection of information and other associated assets; +b)   carrying out specific information security processes; +c)   information security risk management activities and in particular acceptance of residual risks (e.g. to risk owners); +d)   all personnel using an organization’s information and other associated assets. + +These responsibilities should be supplemented, where necessary, with more detailed guidance for specific sites and information processing facilities. Individuals with allocated information security responsibilities can assign security tasks to others. However, they remain accountable and should determine that any delegated tasks have been correctly performed. + +Each  security  area  for  which  individuals  are  responsible  should  be  defined,  documented  and communicated. Authorization levels should be defined and documented. Individuals who take on a specific information security role should be competent in the knowledge and skills required by the role and should be supported to keep up to date with developments related to the role and required in order to fulfil the responsibilities of the role. + +### Other information +Many organizations appoint an information security manager to take overall responsibility for the development and implementation of information security and to support the identification of risks and mitigating controls. + +However, responsibility for resourcing and implementing the controls often remains with individual managers. One common practice is to appoint an owner for each asset who then becomes responsible for its day-to-day protection. + +Depending on the size and resourcing of an organization, information security can be covered by dedicated roles or duties carried out in addition to existing roles. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.20 Addressing information security within supplier agreements.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.20 Addressing information security within supplier agreements.md new file mode 100644 index 0000000..55e407d --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.20 Addressing information security within supplier agreements.md @@ -0,0 +1,72 @@ +#iso27002/2022/EN +## 5.20 Addressing information security within supplier agreements + +**Control** +Relevant information security requirements should be established and agreed with each supplier based on the type of supplier relationship. + +**Purpose** +To maintain an agreed level of information security in supplier relationships. + +**Guidance** +Supplier agreements should be established and documented to ensure that there is clear understanding between the organization and the supplier regarding both parties’ obligations to fulfil relevant information security requirements. + +The following terms can be considered for inclusion in the agreements in order to satisfy the identified information security requirements: + +a\) description of the information to be provided or accessed and methods of providing or accessing the information; + +b\) classification of information according to the organization’s classification scheme (see [[5.10]], [[5.12]], [[5.13]]) + +c\) mapping between the organization’s own classification scheme and the classification scheme of the supplier; + +d\) legal, statutory, regulatory and contractual requirements, including data protection, handling of personally identifiable information (PII), intellectual property rights and copyright and a description of how it will be ensured that they are met; + +e\) obligation of each contractual party to implement an agreed set of controls, including access control, performance review, monitoring, reporting and auditing, and the supplier’s obligations to comply with the organization’s information security requirements; + +f\) rules of acceptable use of information and other associated assets, including unacceptable use if necessary; + +g\) procedures or conditions for authorization and removal of the authorization for the use of the organization’s information and other associated assets by supplier personnel (e.g. through an explicit list of supplier personnel authorized to use the organization’s information and other associated assets); + +h\) information security requirements regarding the supplier’s ICT infrastructure; in particular, minimum information security requirements for each type of information and type of access to serve as the basis for individual supplier agreements based on the organization’s business needs and risk criteria; + +i\) indemnities and remediation for failure of contractor to meet requirements; + +j\) incident management requirements and procedures (especially notification and collaboration during incident remediation); + +k\) training and awareness requirements for specific procedures and information security requirements (e.g. for incident response, authorization procedures); + +l\) relevant provisions for sub-contracting, including the controls that need to be implemented, such as agreement on the use of sub-suppliers (e.g. requiring to have them under the same obligations of the supplier, requiring to have a list of sub-suppliers and notification before any change); + +m\) relevant contacts, including a contact person for information security issues; + +n\) any screening requirements, where legally permissible, for the supplier’s personnel, including responsibilities for conducting the screening and notification procedures if screening has not been completed or if the results give cause for doubt or concern; + +o\) the evidence and assurance mechanisms of third-party attestations for relevant information security requirements related to the supplier processes and an independent report on effectiveness of controls; + +p\) right to audit the supplier processes and controls related to the agreement; + +q\) supplier’s obligation to periodically deliver a report on the effectiveness of controls and agreement on timely correction of relevant issues raised in the report; + +r\) defect resolution and conflict resolution processes; + +s\) providing backup aligned with the organization’s needs (in terms of frequency and type and storage location); + +t\) ensuring the availability of an alternate facility (i.e. disaster recovery site) not subject to the same threats as the primary facility and considerations for fall back controls (alternate controls) in the event primary controls fail; + +u\) having a change management process that ensures advance notification to the organization and the possibility for the organization of not accepting changes; + +v\) physical security controls commensurate with the information classification; + +w\) information transfer controls to protect the information during physical transfer or logical transmission; + +x\) termination clauses upon conclusion of the agreement including records management, return of assets, secure disposal of information and other associated assets, and any ongoing confidentiality obligations; + +y\) provision of a method of securely destroying the organization’s information stored by the supplier as soon as it is no longer required; + +z\) ensuring, at the end of the contract, handover support to another supplier or to the organization itself. + +The organization should establish and maintain a register of agreements with external parties (e.g. contracts, memorandum of understanding, information-sharing agreements) to keep track of where their information is going. The organization should also regularly review, validate and update their agreements with external parties to ensure they are still required and fit for purpose with relevant information security clauses. + +**Other information** +The agreements can vary considerably for different organizations and among the different types of suppliers. Therefore, care should be taken to include all relevant requirements for addressing information security risks. + +For details on supplier agreements, see ISO/IEC 27036 series. For cloud service agreements, see ISO/IEC 19086 series. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.21 Managing information security in the ICT supply chain.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.21 Managing information security in the ICT supply chain.md new file mode 100644 index 0000000..bed7514 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.21 Managing information security in the ICT supply chain.md @@ -0,0 +1,58 @@ +#iso27002/2022/EN +[[ISO_27002_PE 5.21 Managing information security in the ICT supply chain]] + +## 5.21 Managing information security in the ICT supply chain + +**Control** +Processes and procedures should be defined and implemented to manage the information security risks associated with the ICT products and services supply chain. + +**Purpose** +To maintain an agreed level of information security in supplier relationships. + +**Guidance** + +The following topics should be considered to address information security within ICT supply chain security in addition to the general information security requirements for supplier relationships: + +a\) defining information security requirements to apply to ICT product or service acquisition; + +b\) requiring that ICT services suppliers propagate the organization’s security requirements throughout the supply chain if they sub-contract for parts of the ICT service provided to the organization; + +c\) requiring that ICT products suppliers propagate appropriate security practices throughout the supply chain if these products include components purchased or acquired from other suppliers or other entities (e.g. sub-contracted software developers and hardware component providers); + +d\) requesting that ICT products suppliers provide information describing the software components used in products; + +e\) requesting that ICT products suppliers provide information describing the implemented security functions of their product and the configuration required for its secure operation; + +f\) implementing a monitoring process and acceptable methods for validating that delivered ICT products and services comply with stated security requirements. Examples of such supplier review methods can include penetration testing and proof or validation of third-party attestations for the supplier’s information security operations; + +g\) implementing a process for identifying and documenting product or service components that are critical for maintaining functionality and therefore require increased attention, scrutiny and further follow up required when built outside of the organization especially if the supplier outsources aspects of product or service components to other suppliers; + +h\) obtaining assurance that critical components and their origin can be traced throughout the supply chain; + +i\) obtaining assurance that the delivered ICT products are functioning as expected without any unexpected or unwanted features; + +j\) implementing processes to ensure that components from suppliers are genuine and unaltered from their specification. Example measures include anti-tamper labels, cryptographic hash verifications or digital signatures. Monitoring for out of specification performance can be an indicator of tampering or counterfeits. Prevention and detection of tampering should be implemented during multiple stages in the system development life cycle, including design, development, integration, operations and maintenance; + +k\) obtaining assurance that ICT products achieve required security levels, for example, through formal certification or an evaluation scheme such as the Common Criteria Recognition Arrangement; + +l\) defining rules for sharing of information regarding the supply chain and any potential issues and compromises among the organization and suppliers; + +m\) implementing specific processes for managing ICT component life cycle and availability and associated security risks. This includes managing the risks of components no longer being available due to suppliers no longer being in business or suppliers no longer providing these components due to technology advancements. Identification of an alternative supplier and the process to transfer software and competence to the alternative supplier should be considered. + +**Other information** + +The specific ICT supply chain risk management practices are built on top of general information security, quality, project management and system engineering practices but do not replace them. + +Organizations are advised to work with suppliers to understand the ICT supply chain and any matters that have an important effect on the products and services being provided. The organization can influence ICT supply chain information security practices by making clear in agreements with their suppliers the matters that should be addressed by other suppliers in the ICT supply chain. + +ICT should be acquired from reputable sources. The reliability of software and hardware is a matter of quality control. While it is generally not possible for an organization to inspect the quality control systems of its vendors, it can make reliable judgments based on the reputation of the vendor. + +ICT supply chain as addressed here includes cloud services. + +Examples of ICT supply chains are: + +a\) cloud services provisioning, where the cloud service provider relies on the software developers, telecommunication service providers, hardware providers; + +b\) IoT, where the service involves the device manufacturers, the cloud service providers (e.g. the IoT platform operators), the developers for mobile and web applications, the vendor of software libraries; + +c\) hosting services, where the provider relies on external service desks including first, second and third support levels. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.22 Monitoring, review and change management of supplier services.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.22 Monitoring, review and change management of supplier services.md new file mode 100644 index 0000000..6f842b7 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.22 Monitoring, review and change management of supplier services.md @@ -0,0 +1,55 @@ +#iso27002/2022/EN + +**Control** +The organization should regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery. + +**Purpose** +To maintain an agreed level of information security and service delivery in line with supplier agreements. + +**Guidance** +Monitoring, review and change management of supplier services should ensure the information security terms and conditions of the agreements are complied with, information security incidents and problems are managed properly and changes in supplier services or business status do not affect service delivery. + +This should involve a process to manage the relationship between the organization and the supplier to: + +a\) monitor service performance levels to verify compliance with the agreements; + +b) monitor changes made by suppliers including: +1) enhancements to the current services offered; +2) development of any new applications and systems; +3) modifications or updates of the supplier’s policies and procedures; +4) new or changed controls to resolve information security incidents and to improve information security; + +c) monitor changes in supplier services including: +1) changes and enhancement to networks; +2) use of new technologies; +3) adoption of new products or newer versions or releases; +4) new development tools and environments; +5) changes to physical location of service facilities; +6) change of sub-suppliers; +7) sub-contracting to another supplier; + +d\) review service reports produced by the supplier and arrange regular progress meetings as required by the agreements; + +e\) conduct audits of suppliers and sub-suppliers, in conjunction with review of independent auditor’s reports, if available and follow-up on issues identified; + +f\) provide information about information security incidents and review this information as required by the agreements and any supporting guidelines and procedures; + +g\) review supplier audit trails and records of information security events, operational problems, failures, tracing of faults and disruptions related to the service delivered; + +h\) respond to and manage any identified information security events or incidents; + +i\) identify information security vulnerabilities and manage them; + +j\) review information security aspects of the supplier’s relationships with its own suppliers; + +k\) ensure that the supplier maintains sufficient service capability together with workable plans designed to ensure that agreed service continuity levels are maintained following major service failures or disaster (see [[5.29]], [[5.30]], [[5.35]], [[5.36]], [[8.14]]; + +l\) ensure that suppliers assign responsibilities for reviewing compliance and enforcing the requirements of the agreements; + +m\) evaluate regularly that the suppliers maintain adequate information security levels. + + +The responsibility for managing supplier relationships should be assigned to a designated individual or team. Sufficient technical skills and resources should be made available to monitor that the requirements of the agreement, in particular the information security requirements, are being met. Appropriate actions should be taken when deficiencies in the service delivery are observed. + +**Other information** +See ISO/IEC 27036-3 for more detail. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.23 Information security for use of cloud services.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.23 Information security for use of cloud services.md new file mode 100644 index 0000000..33b858d --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.23 Information security for use of cloud services.md @@ -0,0 +1,58 @@ +#iso27002/2022/EN +## 5.23 Information security for use of cloud services + +#### Control +Processes for acquisition, use, management and exit from cloud services should be established in accordance with the organization’s information security requirements. + +#### Purpose +To specify and manage information security for the use of cloud services. + +#### Guidance +The organization should establish and communicate topic-specific policy on the use of cloud services to all relevant interested parties. + +The organization should define and communicate how it intends to manage information security risks associated with the use of cloud services. It can be an extension or part of the existing approach for how an organization manages services provided by external parties (see 5.21 and 5.22). + +The use of cloud services can involve shared responsibility for information security and collaborative effort between the cloud service provider and the organization acting as the cloud service customer. It is essential that the responsibilities for both the cloud service provider and the organization, acting as the cloud service customer, are defined and implemented appropriately. + +The organization should define: +a) all relevant information security requirements associated with the use of the cloud services; +b) cloud service selection criteria and scope of cloud service usage; +c) roles and responsibilities related to the use and management of cloud services; +d) which information security controls are managed by the cloud service provider and which are managed by the organization as the cloud service customer; +e) how to obtain and utilize information security capabilities provided by the cloud service provider; +f) how to obtain assurance on information security controls implemented by cloud service providers; +g) how to manage controls, interfaces and changes in services when an organization uses multiple cloud services, particularly from different cloud service providers; +h) procedures for handling information security incidents that occur in relation to the use of cloud services; +i) its approach for monitoring, reviewing and evaluating the ongoing use of cloud services to manage information security risks; +j) how to change or stop the use of cloud services including exit strategies for cloud services. + +Cloud service agreements are often pre-defined and not open to negotiation. For all cloud services, the organization should review cloud service agreements with the cloud service provider(s). A cloud service agreement should address the confidentiality, integrity, availability and information handling requirements of the organization, with appropriate cloud service level objectives and cloud service qualitative objectives. The organization should also undertake relevant risk assessments to identify the risks associated with using the cloud service. Any residual risks connected to the use of the cloud service should be clearly identified and accepted by the appropriate management of the organization. + +An agreement between the cloud service provider and the organization, acting as the cloud service customer, should include the following provisions for the protection of the organization’s data and availability of services: +a) providing solutions based on industry accepted standards for architecture and infrastructure; +b) managing access controls of the cloud service to meet the requirements of the organization; +c) implementing malware monitoring and protection solutions; +d) processing and storing the organization’s sensitive information in approved locations (e.g. particular country or region) or within or subject to a particular jurisdiction; +e) providing dedicated support in the event of an information security incident in the cloud service environment; +f) ensuring that the organization’s information security requirements are met in the event of cloud services being further sub-contracted to an external supplier (or prohibiting cloud services from being sub-contracted); +g) supporting the organization in gathering digital evidence, taking into consideration laws and regulations for digital evidence across different jurisdictions; +h) providing appropriate support and availability of services for an appropriate time frame when the organization wants to exit from the cloud service; +i) providing required backup of data and configuration information and securely managing backups as applicable, based on the capabilities of the cloud service provider used by the organization, acting as the cloud service customer; +j) providing and returning information such as configuration files, source code and data that are owned by the organization, acting as the cloud service customer, when requested during the service provision or at termination of service. + +The organization, acting as the cloud service customer, should consider whether the agreement should require cloud service providers to provide advance notification prior to any substantive customer impacting changes being made to the way the service is delivered to the organization, including: +a) changes to the technical infrastructure (e.g. relocation, reconfiguration, or changes in hardware or software) that affect or change the cloud service offering; +b) processing or storing information in a new geographical or legal jurisdiction; +c) use of peer cloud service providers or other sub-contractors (including changing existing or using new parties). + +The organization using cloud services should maintain close contact with its cloud service providers. These contacts enable mutual exchange of information about information security for the use of the cloud services including a mechanism for both cloud service provider and the organization, acting as the cloud service customer, to monitor each service characteristic and report failures to the commitments contained in the agreements. + + +#### Other information +This control considers cloud security from the perspective of the cloud service customer. + +Additional information relating to cloud services can be found in ISO/IEC 17788, ISO/IEC 17789 and ISO/IEC 22123-1. Specifics related to cloud portability in support of exit strategies can be found in ISO/IEC 19941. Specifics related to information security and public cloud services are described in ISO/IEC 27017. Specifics related to PII protection in public clouds acting as PII processor are described in ISO/IEC 27018. Supplier relationships for cloud services are covered by ISO/IEC 27036-4 and cloud service agreements and their contents are dealt with in the ISO/IEC 19086 series, with security and privacy specifically covered by ISO/IEC 19086-4. + + +# Related: +- [[ISO_27002_PE 5.23 Information security for use of cloud services]] \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.24 Information security incident management planning and preparation.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.24 Information security incident management planning and preparation.md new file mode 100644 index 0000000..fc94677 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.24 Information security incident management planning and preparation.md @@ -0,0 +1,68 @@ +#iso27002/2022/EN +## 5.24 Information security incident management planning and preparation + +#### Control +The organization should plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities. + +#### Purpose +To ensure quick, effective, consistent and orderly response to information security incidents, including communication on information security events. + +#### Guidance + +**Roles and responsibilities** + +The organization should establish appropriate information security incident management processes. Roles and responsibilities to carry out the incident management procedures should be determined and effectively communicated to the relevant internal and external interested parties. + +The following should be considered: + +a\) establishing a common method for reporting information security events including point of contact (see [[ISO_27002_OT n.n Title\|6.8]]); + +b\) establishing an incident management process to provide the organization with capability for managing information security incidents including administration, documentation, detection, triage, prioritization, analysis, communication and coordinating interested parties; + +c\) establishing an incident response process to provide the organization with capability for assessing, responding to and learning from information security incidents; + +d\) only allowing competent personnel to handle the issues related to information security incidents within the organization. Such personnel should be provided with procedure documentation and periodic training; + +e\) establishing a process to identify required training, certification and ongoing professional development for incident response personnel. + +**Incident management procedures** + +The objectives for information security incident management should be agreed with management and it should be ensured that those responsible for information security incident management understand the organization’s priorities for handling information security incidents, including resolution time frame based on potential consequences and severity. Incident management procedures should be implemented to meet these objectives and priorities. + +Management should ensure that an information security incident management plan is created considering different scenarios and procedures are developed and implemented for the following activities: + +a\) evaluation of information security events according to criteria for what constitutes an information security incident; + +b\) monitoring (see [[ISO_27002_OT n.n Title\|8.15]] and [[ISO_27002_OT n.n Title\|8.16]]), detecting (see [[ISO_27002_OT n.n Title\|8.16]]), classifying (see [[ISO_27002_OT n.n Title\|5.25]]), analysing and reporting (see [[ISO_27002_OT n.n Title\|6.8]]) of information security events and incidents (by human or automatic means); + +c\) managing information security incidents to conclusion, including response and escalation (see [[ISO_27002_OT n.n Title\|5.26]]), according to the type and the category of the incident, possible activation of crisis management and activation of continuity plans, controlled recovery from an incident and communication to internal and external interested parties; + +d\) coordination with internal and external interested parties such as authorities, external interest groups and forums, suppliers and clients (see [[ISO_27002_OT 5.5 Contact with authorities|5.5]] and [[ISO_27002_OT 5.6 Contact with special interest groups\|5.6]]); + +e\) logging incident management activities; + +f\) handling of evidence (see [[ISO_27002_OT n.n Title\|5.28]]); + +g\) root cause analysis or post-mortem procedures; + +h\) identification of lessons learned and any improvements to the incident management procedures or information security controls in general that are required. + +**Reporting procedures** + +Reporting procedures should include: + +a\) actions to be taken in case of an information security event (e.g. noting all pertinent details immediately such as malfunction occurring and messages on screen, immediately reporting to the point of contact and only taking coordinated actions); + +b\) use of incident forms to support personnel to perform all necessary actions when reporting information security incidents; + +c\) suitable feedback processes to ensure that those persons reporting information security events are notified, to the extent possible, of outcomes after the issue has been addressed and closed; + +d\) creation of incident reports. + +Any external requirements on reporting of incidents to relevant interested parties within the defined time frame (e.g. breach notification requirements to regulators) should be considered when implementing incident management procedures. + +**Other information** + +Information security incidents can transcend organizational and national boundaries. To respond to such incidents, it is beneficial to coordinate response and share information about these incidents with external organizations as appropriate. + +Detailed guidance on information security incident management is provided in the ISO/IEC 27035 series. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.27 Learning from information security incidents.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.27 Learning from information security incidents.md new file mode 100644 index 0000000..5bc8073 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.27 Learning from information security incidents.md @@ -0,0 +1,23 @@ +#iso27002/2022/EN +## 5.27 Learning from information security incidents + +#### Control +Knowledge gained from information security incidents should be used to strengthen and improve the information security controls. + +#### Purpose +To reduce the likelihood or consequences of future incidents. + +#### Guidance +The organization should establish procedures to quantify and monitor the types, volumes and costs of information security incidents. + +The information gained from the evaluation of information security incidents should be used to: + +a\) enhance the incident management plan including incident scenarios and procedures (see [[ISO_27002_OT 5.24 Information security incident management planning and preparation|5.24]]); + +b\) identify recurring or serious incidents and their causes to update the organization’s information security risk assessment and determine and implement necessary additional controls to reduce the likelihood or consequences of future similar incidents. Mechanisms to enable that include collecting, quantifying and monitoring information about incident types, volumes and costs; + +c\) enhance user awareness and training (see [[ISO_27002_OT 6.3 Information security awareness, education and training|6.3]]) by providing examples of what can happen, how to respond to such incidents and how to avoid them in the future. + +#### Other information + +The ISO/IEC 27035 series provides further guidance. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.29 Information security during disruption.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.29 Information security during disruption.md new file mode 100644 index 0000000..345523b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.29 Information security during disruption.md @@ -0,0 +1 @@ +#iso27002/2022/EN diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.3 Segregation of duties.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.3 Segregation of duties.md new file mode 100644 index 0000000..9895400 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.3 Segregation of duties.md @@ -0,0 +1,35 @@ +#iso27002/2022/EN +## 5.3 Segregation of duties + +### Control +Conflicting duties and conflicting areas of responsibility should be segregated. + +### Purpose +To reduce the risk of fraud, error and bypassing of information security controls. + +### Guidance +Segregation of duties and areas of responsibility aims to separate conflicting duties between different individuals in order to prevent one individual from executing potential conflicting duties on their own. + +The organization should determine which duties and areas of responsibility need to be segregated. The following are examples of activities that can require segregation: + +a)   initiating, approving and executing a change; + +b)   requesting, approving and implementing access rights; + +c)   designing, implementing and reviewing code; + +d)   developing software and administering production systems; + +e)   using and administering applications; + +f)   using applications and administering databases; + +g)   designing, auditing and assuring information security controls. + + +The  possibility of collusion should be considered in designing the segregation controls. Small organizations can find segregation of duties difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls should be considered, such as monitoring of activities, audit trails and management supervision. + +Care should be taken when using role-based access control systems to ensure that persons are not granted conflicting roles. When there is a large number of roles, the organization should consider using automated tools to identify conflicts and facilitate their removal. Roles should be carefully defined and provisioned to minimize access problems if a role is removed or reassigned. + +### Other **information** +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.30 ICT readiness for business continuity.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.30 ICT readiness for business continuity.md new file mode 100644 index 0000000..5f4f4c2 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.30 ICT readiness for business continuity.md @@ -0,0 +1,49 @@ +#iso27002/2022/EN +See also: +- [[BCP_Bedrijfscontinuïteitsplanning]] +- [[Disaster Recovery Planning]] + +# **5.30** **ICT** **readiness** **for** **business** continuity + +## Purpose + +To ensure the availability of the organization’s information and other associated assets during disruption. + +## Guidance + +ICT readiness for business continuity is an important component in business continuity management and information security management to ensure that the organization’s objectives can continue to be met during disruption. + +The ICT continuity requirements are the outcome of the business impact analysis (BIA). The BIA process should use impact types and criteria to assess the impacts over time resulting from the disruption of business activities that deliver products and services. The magnitude and duration of the resulting impact should be used to identify prioritized activities which should be assigned a recovery time objective (RTO). The BIA should then determine which resources are needed to support prioritized activities. An RTO should also be specified for these resources. A subset of these resources should include ICT services. + +The BIA involving ICT services can be expanded to define performance and capacity requirements of ICT systems and recovery point objectives (RPO) of information required to support activities during disruption. + +Based on the outputs from the BIA and risk assessment involving ICT services, the organization should identify and select ICT continuity strategies that consider options for before, during and after disruption. The business continuity strategies can comprise one or more solutions. Based on the strategies, plans should be developed, implemented and tested to meet the required availability level of ICT services and in the required time frames following interruption to, or failure of, critical processes. + +The organization should ensure that: + +a)   an adequate organizational structure is in place to prepare for, mitigate and respond to a disruption supported by personnel with the necessary responsibility, authority and competence; + +b)   ICT continuity plans, including response and recovery procedures detailing how the organization is planning to manage an ICT service disruption, are: + +1)   regularly evaluated through exercises and tests; +2)   approved by management; + +c)   ICT continuity plans include the following ICT continuity information: + +1)   performance and capacity specifications to meet the business continuity requirements and objectives as specified in the BIA; +2)   RTO of each prioritized ICT service and the procedures for restoring those components; +3)   RPO of the prioritized ICT resources defined as information and the procedures for restoring the information. + +## Other **information** + +Managing ICT continuity forms a key part of business continuity requirements concerning availability to be able to: + +a)   respond and recover from disruption to ICT services regardless of the cause; + +b)   ensure continuity of prioritized activities are supported by the required ICT services; + +c)   respond before a disruption to ICT services occurs, and upon detection of at least one incident that can result in a disruption to ICT services. + +Further guidance on ICT readiness for business continuity can be found in ISO/IEC 27031. + +Further guidance on business continuity management systems can be found in ISO 22301 and ISO 22313. Further guidance on BIA can be found in ISO/TS 22317. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.32 Intellectual property rights.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.32 Intellectual property rights.md new file mode 100644 index 0000000..74e38b0 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.32 Intellectual property rights.md @@ -0,0 +1,48 @@ +#iso27002/2022/EN +## 5.32 Intellectual property rights + +**Control** +The organization should implement appropriate procedures to protect intellectual property rights. + +**Purpose** +To ensure compliance with legal, statutory, regulatory and contractual requirements related to intellectual property rights and use of proprietary products. + +The following guidelines should be considered to protect any material that can be considered intellectual property: + +a\) defining and communicating a topic-specific policy on protection of intellectual property rights; + +b\) publishing procedures for intellectual property rights compliance that define compliant use of software and information products; + +c\) acquiring software only through known and reputable sources, to ensure that copyright is not infringed upon; + +d\) maintaining appropriate asset registers and identifying all assets with requirements to protect intellectual property rights; + +e\) maintaining proof and evidence of ownership of licences, manuals, etc.; + +f\) ensuring that any maximum number of users or resources \[e.g. central processing units (CPUs)\] permitted within the licence is not exceeded; + +g\) carrying out reviews to ensure that only authorized software and licensed products are installed; + +h\) providing procedures for maintaining appropriate licence conditions; + +i\) providing procedures for disposing of or transferring software to others; + +j\) complying with terms and conditions for software and information obtained from public networks and outside sources; + +k\) not duplicating, converting to another format or extracting from commercial recordings (video, audio) other than permitted by copyright law or the applicable licences; + +l\) not copying, in full or in part, standards (e.g. ISO/IEC International Standards), books, articles, reports or other documents, other than permitted by copyright law or the applicable licences. + +**Other information** + +Intellectual property rights include software or document copyright, design rights, trademarks, patents and source code licences. + +Proprietary software products are usually supplied under a licence agreement that specifies licence terms and conditions, for example, limiting the use of the products to specified machines or limiting copying to the creation of backup copies only. See the ISO/IEC 19770 series for details about IT asset management. + +Data can be acquired from outside sources. It is generally the case that such data is obtained under the terms of a data sharing agreement or similar legal instrument. Such data sharing agreements should make it clear what processing is permitted for the acquired data. It is also advisable that the provenance of the data is clearly stated. See ISO/IEC 23751:—1) for details about data sharing agreements. + +Legal, statutory, regulatory and contractual requirements can place restrictions on the copying of proprietary material. In particular, they can require that only material that is developed by the organization or that is licensed or provided by the developer to the organization, can be used. Copyright infringement can lead to legal action, which can involve fines and criminal proceedings. + +Aside from the organization needing to comply with its obligations towards third party intellectual property rights, the risks of personnel and third parties failing to uphold the organization’s own intellectual property rights should also be managed. + +1\) Under preparation. Stage at the time of publication: ISO/IEC PRF 23751:2022. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.4 Management responsibilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.4 Management responsibilities.md new file mode 100644 index 0000000..e3e225a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.4 Management responsibilities.md @@ -0,0 +1,32 @@ +#iso27002/2022/EN +## 5.4 Management responsibilities + +#### Control +Management should require all personnel to apply information security in accordance with the established information security policy, topic-specific policies and procedures of the organization. + +#### Purpose +To ensure management understand their role in information security and undertake actions aiming to ensure all personnel are aware of and fulfil their information security responsibilities. + +#### Guidance +Management should demonstrate support of the information security policy, topic-specific policies, procedures and information security controls. + +Management responsibilities should include ensuring that personnel: + +a)   are properly briefed on their information security roles and responsibilities prior to being granted access to the organization’s information and other associated assets; + +b)   are provided with guidelines which state the information security expectations of their role within the organization; + +c)   are mandated to fulfil the information security policy and topic-specific policies of the organization; + +d)   achieve a level of awareness of information security relevant to their roles and responsibilities within the organization (see 6.3); + +e)   compliance with the terms and conditions of employment, contract or agreement, including the organization’s information security policy and appropriate methods of working; + +f)   continue to have the appropriate information security skills and qualifications through ongoing professional education; + +g)   where practicable, are provided with a confidential channel for reporting violations of information security policy, topic-specific policies or procedures for information security (“whistleblowing”). This can allow for anonymous reporting, or have provisions to ensure that knowledge of the identity of the reporter is known only to those who need to deal with such reports; + +h)   are provided with adequate resources and project planning time for implementing the organization’s security-related processes and controls. + +#### Other information +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.5 Contact with authorities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.5 Contact with authorities.md new file mode 100644 index 0000000..321b677 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.5 Contact with authorities.md @@ -0,0 +1,36 @@ +#iso27002/2022/EN +## 5.5 Contact with authorities + +#### Control + + + +The organization should establish and maintain contact with relevant authorities. + +#### Purpose + +To ensure appropriate flow of information takes place with respect to information security between the organization and relevant legal, regulatory and supervisory authorities. + + + +#### Guidance + + + +The organization should specify when and by whom authorities (e.g. law enforcement, regulatory bodies, supervisory authorities) should be contacted and how identified information security incidents should be reported in a timely manner. + + + +Contacts with authorities should also be used to facilitate the understanding about the current and upcoming expectations of these authorities (e.g. applicable information security regulations). + + + +#### Other information + + + +Organizations under attack can request authorities to take action against the attack source. + + + +Maintaining such contacts can be a requirement to support information security incident management (see 5.24 to 5.28) or the contingency planning and business continuity processes (see 5.29 and 5.30). Contacts with regulatory bodies are also useful to anticipate and prepare for upcoming changes in relevant laws or regulations that affect the organization. Contacts with other authorities include utilities, emergency services, electricity suppliers and health and safety [e.g. fire departments (in connection with business continuity), telecommunication providers (in connection with line routing and availability) and water suppliers (in connection with cooling facilities for equipment)]. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.6 Contact with special interest groups.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.6 Contact with special interest groups.md new file mode 100644 index 0000000..198388e --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.6 Contact with special interest groups.md @@ -0,0 +1,29 @@ +#iso27002/2022/EN +## 5.6 Contact with special interest groups + +#### Control +The organization should establish and maintain contact with special interest groups or other specialist security forums and professional associations. + +#### Purpose +To ensure appropriate flow of information takes place with respect to information security. + +#### Guidance + +Membership of special interest groups or forums should be considered as a means to: + +a)   improve knowledge about best practices and stay up to date with relevant security information; + +b)   ensure the understanding of the information security environment is current; + +c)   receive early warnings of alerts, advisories and patches pertaining to attacks and vulnerabilities; + +d)   gain access to specialist information security advice; + +e)   share  and  exchange  information  about  new  technologies,  products,  services,  threats  or vulnerabilities; + +f)   provide suitable liaison points when dealing with information security incidents (see 5.24 to 5.28). + + + +#### Other information +No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.7 Threat intelligence.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.7 Threat intelligence.md new file mode 100644 index 0000000..ff075dc --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.7 Threat intelligence.md @@ -0,0 +1,48 @@ +#iso27002/2022/EN +## 5.7 Threat intelligence + +#### Control +Information relating to information security threats should be collected and analysed to produce threat intelligence. + +#### Purpose +To provide awareness of the organization’s threat environment so that the appropriate mitigation actions can be taken. + +#### Guidance +Information about existing or emerging threats is collected and analysed in order to: + +a)  facilitate informed actions to prevent the threats from causing harm to the organization; +b)  reduce the impact of such threats. + +Threat intelligence can be divided into three layers, which should all be considered: + +a)  strategic threat intelligence: exchange of high-level information about the changing threat landscape (e.g. types of attackers or types of attacks); +b)  tactical threat intelligence: information about attacker methodologies, tools and technologies involved; +c)  operational threat intelligence: details about specific attacks, including technical indicators. + +Threat intelligence should be: + +a)  relevant (i.e. related to the protection of the organization); +b)  insightful (i.e. providing the organization with an accurate and detailed understanding of the threat landscape); +c)  contextual, to provide situational awareness (i.e. adding context to the information based on the time of events, where they occur, previous experiences and prevalence in similar organizations); +d)  actionable (i.e. the organization can act on information quickly and effectively). + +Threat intelligence activities should include: + +a)  establishing objectives for threat intelligence production; +b)  identifying, vetting and selecting internal and external information sources that are necessary and appropriate to provide information required for the production of threat intelligence; +c)  collecting information from selected sources, which can be internal and external; +d)  processing information collected to prepare it for analysis (e.g. by translating, formatting or corroborating information); +e)  analysing information to understand how it relates and is meaningful to the organization; +f)  communicating and sharing it to relevant individuals in a format that can be understood. + +Threat intelligence should be analysed and later used: + +a)  by implementing processes to include information gathered from threat intelligence sources into the organization’s information security risk management processes; +b)  as additional input to technical preventive and detective controls like firewalls, intrusion detection system, or anti malware solutions; +c)  as input to the information security test processes and techniques. + +The organization should share threat intelligence with other organizations on a mutual basis in order to improve overall threat intelligence. + +# Related: +- [[Threat Intelligence]] +- [[ISO_27002_PE 5.7 Threat intelligence]] diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.8 Information security in project management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.8 Information security in project management.md new file mode 100644 index 0000000..4904035 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.8 Information security in project management.md @@ -0,0 +1,52 @@ +#iso27002/2022/EN +## 5.8 Information security in project management + +#### Control +Information security should be integrated into project management. + +#### Purpose +To ensure information security risks related to projects and deliverables are effectively addressed in project management throughout the project life cycle. + +#### Guidance +Information security should be integrated into project management to ensure information security risks are addressed as part of the project management. This can be applied to any type of project regardless of its complexity, size, duration, discipline or application area (e.g. a project for a core business process, ICT, facility management or other supporting processes). + +The project management in use should require that: + +a)   information security risks are assessed and treated at an early stage and periodically as part of project risks throughout the project life cycle; + +b)   information security requirements \[e.g. application security requirements ([[ISO_27002_OT 8.26 Application security requirements|8.26]]), requirements for complying with intellectual property rights ([[ISO_27002_OT 5.32 Intellectual property rights|5.32]]), etc.] are addressed in the early stages of projects; + +c)   information security risks associated with the execution of projects, such as security of internal and external communication aspects are considered and treated throughout the project life cycle; + +d)   progress on information security risk treatment is reviewed and effectiveness of the treatment is evaluated and tested. + +The appropriateness of the information security considerations and activities should be followed up at predefined stages by suitable persons or governance bodies, such as the project steering committee. + +Responsibilities and authorities for information security relevant to the project should be defined and allocated to specified roles. + +Information security requirements for products or services to be delivered by the project should be determined using various methods, including deriving compliance requirements from information security policy, topic-specific policies and regulations. Further information security requirements can be derived from activities such as threat modelling, incident reviews, use of vulnerability thresholds or contingency planning, thus ensuring that the architecture and design of information systems are protected against known threats based on the operational environment. + +Information security requirements should be determined for all types of projects, not only ICT development projects. The following should also be considered when determining these requirements: + +a)   what information is involved (information determination), what are the corresponding information security needs (classification; see [[ISO_27002_OT 5.12 Classification of information\|5.12]]) and the potential negative business impact which can result from lack of adequate security; + +b)   the required protection needs of information and other associated assets involved, particularly in terms of confidentiality, integrity and availability; + +c)   the level of confidence or assurance required towards the claimed identity of entities in order to derive the authentication requirements; + +d)   access provisioning and authorization processes, for customers and other potential business users as well as for privileged or technical users such as relevant project members, potential operation staff or external suppliers; + +e)   informing users of their duties and responsibilities; + +f)   requirements derived from business processes, such as transaction logging and monitoring, non-repudiation requirements; + +g)   requirements mandated by other information security controls (e.g. interfaces to logging and monitoring or data leakage detection systems); + +h)   compliance with the legal, statutory, regulatory and contractual environment in which the organization operates; + +i) level of confidence or assurance required for third parties to meet the organization’s information security policy and topic-specific policies including relevant security clauses in any agreements or contracts. + +#### Other information +The project development approach, such as waterfall life cycle or agile life cycle, should support information security in a structured way that can be adapted to suit the assessed severity of the information security risks, based on the character of the project. Early consideration of information security requirements for the product or service (e.g. at the planning and design stages), can lead to more effective and cost-efficient solutions for quality and information security. ISO 21500 and ISO 21502 provide guidance on concepts and processes of project management that are important for the performance of projects. + +ISO/IEC 27005 provides guidance on the use of risk management processes to identify controls to meet information security requirements. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.9 Inventory of information and other associated assets.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.9 Inventory of information and other associated assets.md new file mode 100644 index 0000000..345523b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 5.9 Inventory of information and other associated assets.md @@ -0,0 +1 @@ +#iso27002/2022/EN diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 6.3 Information security awareness, education and training.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 6.3 Information security awareness, education and training.md new file mode 100644 index 0000000..345523b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 6.3 Information security awareness, education and training.md @@ -0,0 +1 @@ +#iso27002/2022/EN diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.13 Information backup.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.13 Information backup.md new file mode 100644 index 0000000..345523b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.13 Information backup.md @@ -0,0 +1 @@ +#iso27002/2022/EN diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.15 Logging.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.15 Logging.md new file mode 100644 index 0000000..5aba600 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.15 Logging.md @@ -0,0 +1,5 @@ +#iso27002/2022/EN +Oud: +12.4.1, 12.4.2, 12.4.3 + +[[ISO 27001 A 12.4.1 Event logging\|12.4.1]], [[ISO 27001 A 12.4.2 Protection of log information\|12.4.2]], [[ISO 27001 A 12.4.3 Administrator and operator logs\|12.4.3]] diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.16 Monitoring activities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.16 Monitoring activities.md new file mode 100644 index 0000000..7811c2b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.16 Monitoring activities.md @@ -0,0 +1,3 @@ +#iso27002/2022/EN +## 8.16 Monitoring activities + diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.19 Installation of software on operational systems.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.19 Installation of software on operational systems.md new file mode 100644 index 0000000..345523b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.19 Installation of software on operational systems.md @@ -0,0 +1 @@ +#iso27002/2022/EN diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.2 Privileged access rights.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.2 Privileged access rights.md new file mode 100644 index 0000000..345523b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.2 Privileged access rights.md @@ -0,0 +1 @@ +#iso27002/2022/EN diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.22 Segregation of networks.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.22 Segregation of networks.md new file mode 100644 index 0000000..345523b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.22 Segregation of networks.md @@ -0,0 +1 @@ +#iso27002/2022/EN diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.24 Use of cryptography.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.24 Use of cryptography.md new file mode 100644 index 0000000..cee177a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.24 Use of cryptography.md @@ -0,0 +1,184 @@ +--- +tags: + - iso27001/2022/EN +--- + + +## 8.24 Use of cryptography + + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains +| -------------- | ---------------------------------------- | --------------------- | ------------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Secure_configuration | #Protection | + + +**Control** + +Rules for the effective use of cryptography, including cryptographic key management, should be defined and implemented. + +**Purpose** + + + +To ensure proper and effective use of cryptography to protect the confidentiality, authenticity or integrity of information according to business and information security requirements, and taking into consideration legal, statutory, regulatory and contractual requirements related to cryptography. + + + +**Guidance** + + + +General + + + +When using cryptography, the following should be considered: + + + +a\) the topic-specific policy on cryptography defined by the organization, including the general principles for the protection of information. A topic-specific policy on the use of cryptography is necessary to maximize the benefits and minimize the risks of using cryptographic techniques and to avoid inappropriate or incorrect use; + + + +b\) identifying the required level of protection and the classification of the information andconsequently establishing the type, strength and quality of the cryptographic algorithms required; + + + +c\) the use of cryptography for protection of information held on mobile user endpoint devices or storage media and transmitted over networks to such devices or storage media; + + + +d\) the approach to key management, including methods to deal with the generation and protection of cryptographic keys and the recovery of encrypted information in the case of lost, compromised or damaged keys; + + + +e\) roles and responsibilities for: + + + +1\) the implementation of the rules for the effective use of cryptography; + +2\) the key management, including key generation (see 8.24); + + + +f\) the standards to be adopted, as well as cryptographic algorithms, cipher strength, cryptographic solutions and usage practices that are approved or required for use in the organization; + + + +g\) the impact of using encrypted information on controls that rely on content inspection (e.g. malware detection or content filtering). + + + +When implementing the organization’s rules for effective use of cryptography, the regulations and national restrictions that can apply to the use of cryptographic techniques in different parts of the world should be taken into consideration as well as the issues of trans-border flow of encrypted information (see 5.31). + + + +The contents of service level agreements or contracts with external suppliers of cryptographic services (e.g. with a certification authority) should cover issues of liability, reliability of services and response times for the provision of services (see 5.22). + + + + +Key management + + + +Appropriate key management requires secure processes for generating, storing, archiving, retrieving, distributing, retiring and destroying cryptographic keys. + + + +A key management system should be based on an agreed set of standards, procedures and secure methods for: + + + +a\) generating keys for different cryptographic systems and different applications; + + + +b\) issuing and obtaining public key certificates; + + + +c\) distributing keys to intended entities, including how to activate keys when received; + + + +d\) storing keys, including how authorized users obtain access to keys; + + + +e\) changing or updating keys including rules on when to change keys and how this will be done; + + + +f\) dealing with compromised keys; + + + +g\) revoking keys including how to withdraw or deactivate keys \[e.g. when keys have been compromised or when a user leaves an organization (in which case keys should also be archived)\]; + + + +h\) recovering keys that are lost or corrupted; + + + +i\) backing up or archiving keys; + + + +j\) destroying keys; + + + +k\) logging and auditing of key management related activities; + + + +l\) setting activation and deactivation dates for keys so that the keys can only be used for the period of time according to the organization's rules on key management; + + + +m\) handling legal requests for access to cryptographic keys (e.g. encrypted information can be required to be made available in an unencrypted form as evidence in a court case). + + + +All cryptographic keys should be protected against modification and loss. In addition, secret and private keys need protection against unauthorized use as well as disclosure. Equipment used to generate, store and archive keys should be physically protected. + + + +In addition to integrity, for many use cases, the authenticity of public keys should also be considered. + + + + +**Other information** + + + +The authenticity of public keys is usually addressed by public key management processes using certificate authorities and public key certificates, but it is also possible to address it by using technologies such as applying manual processes for small number keys. + + + +Cryptography can be used to achieve different information security objectives, for example: + + + +a\) confidentiality: using encryption of information to protect sensitive or critical information, either stored or transmitted; + + + +b\) integrity or authenticity: using digital signatures or message authentication codes to verify the authenticity or integrity of stored or transmitted sensitive or critical information. Using algorithms for the purpose of file integrity checking; + + + +c\) non-repudiation: using cryptographic techniques to provide evidence of the occurrence or non-occurrence of an event or action; + + + +d\) authentication: using cryptographic techniques to authenticate users and other system entities requesting access to or transacting with system users, entities and resources. + + + +The ISO/IEC 11770 series provides further information on key management. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.25 Secure development life cycle.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.25 Secure development life cycle.md new file mode 100644 index 0000000..661a1a2 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.25 Secure development life cycle.md @@ -0,0 +1,90 @@ +--- +tags: + - iso27001/2022/EN +--- + +## 8.25 Secure development life cycle + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | + + + +**Control** + + + +Rules for the secure development of software and systems should be established and applied. **Purpose** + + + +To ensure information security is designed and implemented within the secure development life cycle of software and systems. + + + +**Guidance** + + + +Secure development is a requirement to build up a secure service, architecture, software and system. To achieve this, the following aspects should be considered: + + + +a\) separation of development, test and production environments (see >8.31>); + + + +b\) guidance on the security in the software development life cycle: + + + +1\) security in the software development methodology (see >8.28and >8.27>); + + + +2\) secure coding guidelines for each programming language used (see >8.28>); + + + +c\) security requirements in the specification and design phase (see >5.8>); + + + +d\) security checkpoints in projects (see >5.8>); + + + +e\) system and security testing, such as regression testing, code scan and penetration tests (see >8.29>); + + + +f\) secure repositories for source code and configuration (see >8.4and >8.9>); + + + +g\) security in the version control (see >8.32>); + + + +h\) required application security knowledge and training (see >8.28>); + + + +i\) dev elopers’ capability for preventing, finding and fixing vulnerabilities (see >8.28>); + + + +j\) licensing requirements and alternatives to ensure cost-effective solutions while avoiding future licensing issues (See >5.32>). + + + +If development is outsourced, the organization should obtain assurance that the supplier complies with the organization’s rules for secure development (see >8.30>). + + + +**Other information** + + + +Development can also take place inside applications, such as office applications, scripting, browsers and databases. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.26 Application security requirements.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.26 Application security requirements.md new file mode 100644 index 0000000..55812a9 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.26 Application security requirements.md @@ -0,0 +1,93 @@ +#iso27002/2022/EN +## 8.26 Application security requirements + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | -------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection #Defence | + + +#### Control +Information security requirements should be identified, specified and approved when developing or acquiring applications. + +#### Purpose +To ensure all information security requirements are identified and addressed when developing or acquiring applications. + +#### Guidance + +General + +Application security requirements should be identified and specified. These requirements are usually determined through a risk assessment. The requirements should be developed with the support of information security specialists. + +Application security requirements can cover a wide range of topics, depending on the purpose of the application. + +Application security requirements should include, as applicable: + +a\) level of trust in identity of entities \[e.g. through authentication (see [[ISO_27002_OT 5.17 Authentication information|5.17]], [[ISO_27002_OT 8.2 Privileged access rights\|8.2]] and [[ISO_27002_OT 8.5 Secure authentication|8.5]])]; + +b\) identifying the type of information and classification level to be processed by the application; + +c\) need for segregation of access and level of access to data and functions in the application; + +d\) resilience against malicious attacks or unintentional disruptions \[e.g. protection against buffer overflow or structured query language (SQL) injections\]; + +e\) legal, statutory and regulatory requirements in the jurisdiction where the transaction is generated, processed, completed or stored; + +f\) need for privacy associated with all parties involved; + +g\) the protection requirements of any confidential information; + +h\) protection of data while being processed, in transit and at rest; + +i\) need to securely encrypt communications between all involved parties; + +j\) input controls, including integrity checks and input validation; + +k\) automated controls (e.g. approval limits or dual approvals); + +l\) output controls, also considering who can access outputs and its authorization; + +m\) restrictions around content of "free-text" fields, as these can lead to uncontrolled storage of confidential data (e.g. personal data); + +n\) requirements derived from the business process, such as transaction logging and monitoring, nonrepudiation requirements; + +o\) requirements mandated by other security controls (e.g. interfaces to logging and monitoring or data leakage detection systems); + +p) error message handling. + +Transactional services + +Additionally, for applications offering transactional services between the organization and a partner, the following should be considered when identifying information security requirements: + +a\) the level of trust each party requires in each other’s claimed identity; + +b\) the level of trust required in the integrity of information exchanged or processed and the mechanisms for identification of lack of integrity (e.g. cyclic redundancy check, hashing, digital signatures); + +c\) authorization processes associated with who can approve contents of, issue or sign key transactional documents; + +d\) confidentiality, integrity, proof of dispatch and receipt of key documents and the non-repudiation (e.g. contracts associated with tendering and contract processes); + +e\) the confidentiality and integrity of any transactions (e.g. orders, delivery address details and confirmation of receipts); + +f\) requirements on how long to maintain a transaction confidential; + +g\) insurance and other contractual requirements. + +Electronic ordering and payment applications + +Additionally, for applications involving electronic ordering and payment, the following should be considered: + +a\) requirements for maintaining the confidentiality and integrity of order information; + +b\) the degree of verification appropriate to verify payment information supplied by a customer; + +c\) avoidance of loss or duplication of transaction information; + +d\) storing transaction details outside of any publicly accessible environment (e.g. on a storage platform existing on the organizational intranet, and not retained and exposed on electronic storage media directly accessible from the internet); + +e\) where a trusted authority is used (e.g. for the purposes of issuing and maintaining digital signatures or digital certificates) security is integrated and embedded throughout the entire end-to-end certificate or signature management process. + +Several of the above considerations can be addressed by the application of cryptography (see [[8.24]]), taking into consideration legal requirements (see [[5.31]], [[5.36]], especially see [[5.31]] for cryptography legislation). + +**Other information** + +Applications accessible via networks are subject to a range of network related threats, such as fraudulent activities, contract disputes or disclosure of information to the public; incomplete transmission, mis- routing, unauthorized message alteration, duplication or replay. Therefore, detailed risk assessments and careful determination of controls are indispensable. Controls required often include cryptographic methods for authentication and securing data transfer. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.27 Secure system architecture and engineering principles.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.27 Secure system architecture and engineering principles.md new file mode 100644 index 0000000..130b1a0 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.27 Secure system architecture and engineering principles.md @@ -0,0 +1,94 @@ +--- +tags: + - iso27001/2022/EN +--- + +## 8.27 Secure system architecture and engineering principles + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | + +**Control** + +Principles for engineering secure systems should be established, documented, maintained and applied to any information system development activities. + +**Purpose** + +To ensure information systems are securely designed, implemented and operated within the development life cycle. + +**Guidance** + +Security engineering principles should be established, documented and applied to information system engineering activities. Security should be designed into all architecture layers (business, data, applications and technology). New technology should be analysed for security risks and the design should be reviewed against known attack patterns. + +Secure engineering principles provide guidance on user authentication techniques, secure session control and data validation and sanitisation. + +Secure system engineering principles should include analysis of: + +a\) the full range of security controls required to protect information and systems against identified threats; + +b\) the capabilities of security controls to prevent, detect or respond to security events; + +c\) specific security controls required by particular business processes (e.g. encryption of sensitive information, integrity checking and digitally signing information); + +d\) where and how security controls are to be applied (e.g. by integrating with a security architecture and the technical infrastructure); + +e\) how individual security controls (manual and automated) work together to produce an integrated set of controls. + + + +Security engineering principles should take account of: + +a\) the need to integrate with a security architecture; + +b\) tec hnical security infrastructure \[e.g. public key infrastructure (PKI), identity and access management (IAM), data leakage prevention and dynamic access management\]; + +c\) capability of the organization to develop and support the chosen technology; + +d\) cost, time and complexity of meeting security requirements; + +e\) current good practices. + + +Secure system engineering should involve: + +a\) the use of security architecture principles, such as “security by design”, “defence in depth”, “security by default”, “default deny”, “fail securely”, “distrust input from external applications”, “security in deployment”, “assume breach”, "least privilege", “usability and manageability” and “least functionality”; + +b\) a security-oriented design review to help identify information security vulnerabilities, ensure security controls are specified and meet security requirements; + +c\) documentation and formal acknowledgement of security controls that do not fully meet requirements (e.g. due to overriding safety requirements); + +d\) hardening of systems. + + +The organization should consider "zero trust" principles such as: + +a\) assuming the organization’s information systems are already breached and thus not be reliant on network perimeter security alone; + +b\) employing a “never trust and always verify” approach for access to information systems; + +c\) ensuring that requests to information systems are encrypted end-to-end; + +d\) verifying each request to an information system as if it originated from an open, external network, even if these requests originated internal to the organization (i.e. not automatically trusting anything inside or outside its perimeters); + +e\) using "least privilege" and dynamic access control techniques (see >5.15>, >5.18and >8.2>). This includes authenticating and authorizing requests for information or to systems based on contextual information such as authentication information (see >5.17>), user identities (see >5.16>), data about the user endpoint device, and data classification (see >5.12>); + +f\) always authenticating requesters and always validating authorization requests to information systems based on information including authentication information (see >5.17>) and user identities (>5.16>), data about the user endpoint device, and data classification (see >5.12>), for example enforcing strong authentication (e.g. multi-factor, see >8.5>). + + +The established security engineering principles should be applied, where applicable, to outsourced development of information systems through the contracts and other binding agreements between the organization and the supplier to whom the organization outsources. The organization should ensure that suppliers’ security engineering practices align with the organization’s needs. + +The security engineering principles and the established engineering procedures should be regularly reviewed to ensure that they are effectively contributing to enhanced standards of security within the engineering process. They should also be regularly reviewed to ensure that they remain up-to- date in terms of combatting any new potential threats and in remaining applicable to advances in the technologies and solutions being applied. + + +**Other information** + +Secure engineering principles can be applied to the design or configuration of a range of techniques, such as: + +- fault tolerance and other resilience techniques; +- segregation (e.g. through virtualization or containerization); +- tamper resistance. + +Secure virtualization techniques can be used to prevent interference between applications running on the same physical device. If a virtual instance of an application is compromised by an attacker, only that instance is affected. The attack has no effect on any other application or data. + +Tamper resistance techniques can be used to detect tampering of information containers, whether physical (e.g. a burglar alarm) or logical (e.g. a data file). A characteristic of such techniques is that there is a record of the attempt to tamper with the container. In addition, the control can prevent the successful extraction of data through its destruction (e.g. device memory can be deleted). \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.28 Secure coding.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.28 Secure coding.md new file mode 100644 index 0000000..0ee0c60 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.28 Secure coding.md @@ -0,0 +1,99 @@ +--- +tags: + - iso27001/2022/EN +--- + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | + + +## 8.28 Secure coding + +#### Control +Secure coding principles should be applied to software development. + +#### Purpose +To ensure software is written securely thereby reducing the number of potential information security vulnerabilities in the software. + +#### Guidance + +**General** + +The organization should establish organization-wide processes to provide good governance for secure coding. A minimum secure baseline should be established and applied. Additionally, such processes and governance should be extended to cover software components from third parties and open source software. + +The organization should monitor real world threats and up-to-date advice and information on software vulnerabilities to guide the organization’s secure coding principles through continual improvement and learning. This can help with ensuring effective secure coding practices are implemented to combat the fast-changing threat landscape. + +**Planning and before coding** + +Secure coding principles should be used both for new developments and in reuse scenarios. These principles should be applied to development activities both within the organization and for products and services supplied by the organization to others. + +Planning and prerequisites before coding should include: + +a) organization-specific expectations and approved principles for secure coding to be used for both in-house and outsourced code developments; +b) common and historical coding practices and defects that lead to information security vulnerabilities; +c) configuring development tools, such as integrated development environments (IDE), to help enforce the creation of secure code; +d) following guidance issued by the providers of development tools and execution environments as applicable; +e) maintenance and use of updated development tools (e.g. compilers); +f) qualification of developers in writing secure code; +g) secure design and architecture, including threat modeling; +h) secure coding standards and where relevant mandating their use; +i) use of controlled environments for development. + +**During coding** + +Considerations during coding should include: + +a) secure coding practices specific to the programming languages and techniques being used; +b) using secure programming techniques, such as pair programming, refactoring, peer review, security iterations and test-driven development; +c) using structured programming techniques; +d) documenting code and removing programming defects, which can allow information security vulnerabilities to be exploited; +e) prohibiting the use of insecure design techniques (e.g. the use of hard-coded passwords, unapproved code samples and unauthenticated web services). + +Testing should be conducted during and after development (see [[ISO_27002_OT 8.29 Security testing in development and acceptance|8.29]]). Static application security testing (SAST) processes can identify security vulnerabilities in software. + +Before software is made operational, the following should be evaluated: +a) attack surface and the principle of least privilege; +b) conducting an analysis of the most common programming errors and documenting that these have been mitigated. + +**Review and maintenance** + +After code has been made operational: + +a) updates should be securely packaged and deployed; +b) reported information security vulnerabilities should be handled (see [[ISO_27002_OT 8.8 Management of technical vulnerabilities|8.8]]); +c) errors and suspected attacks should be logged and logs regularly reviewed to make adjustments to the code as necessary; +d) source code should be protected against unauthorized access and tampering (e.g. by using configuration management tools, which typically provide features such as access control and version control). + +If using external tools and libraries, the organization should consider: + +a) ensuring that external libraries are managed (e.g. by maintaining an inventory of libraries used and their versions) and regularly updated with release cycles; +b) selection, authorization and reuse of well-vetted components, particularly authentication and cryptographic components; +c) the licence, security and history of external components; +d) ensuring that software is maintainable, tracked and originates from proven, reputable sources; +e) sufficiently long-term availability of development resources and artefacts. + +Where a software package needs to be modified the following points should be considered: + +a) the risk of built-in controls and integrity processes being compromised; +b) whether to obtain the consent of the vendor; +c) the possibility of obtaining the required changes from the vendor as standard program updates; +d) the impact if the organization becomes responsible for the future maintenance of the software as a result of changes; +e) compatibility with other software in use. + +**Other** **information** + +A guiding principle is to ensure security-relevant code is invoked when necessary and is tamper- resistant. Programs installed from compiled binary code also have these properties but only for data held within the application. For interpreted languages, the concept only works when the code is executed on a server that is otherwise inaccessible by the users and processes that use it, and that its data is held in a similarly protected database. For example, the interpreted code can be run on a cloud service where access to the code itself requires administrator privileges. Such administrator access should be protected by security mechanisms such as just-in-time administration principles and strong authentication. If the application owner can access scripts by direct remote access to the server, so in principle can an attacker. Webservers should be configured to prevent directory browsing in such cases. + +Application code is best designed on the assumption that it is always subject to attack, through error or malicious action. In addition, critical applications can be designed to be tolerant of internal faults. For example, the output from a complex algorithm can be checked to ensure that it lies within safe bounds before the data is used in an application such as a safety or financial critical application. The code that performs the boundary checks is simple and therefore much easier to prove correctness. + +Some web applications are susceptible to a variety of vulnerabilities that are introduced by poor design and coding, such as database injection and cross-site scripting attacks. In these attacks, requests can be manipulated to abuse the webserver functionality. + +More information on ICT security evaluation can be found in the ISO/IEC 15408 series. + + +# Related: +- [[ISO_27002_PE 8.28 Secure coding]] +- [[ISO_27002_OT 8.29 Security testing in development and acceptance]] +- [[ISO_27002_OT 8.8 Management of technical vulnerabilities]] diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.29 Security testing in development and acceptance.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.29 Security testing in development and acceptance.md new file mode 100644 index 0000000..345523b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.29 Security testing in development and acceptance.md @@ -0,0 +1 @@ +#iso27002/2022/EN diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.32 Change management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.32 Change management.md new file mode 100644 index 0000000..345523b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.32 Change management.md @@ -0,0 +1 @@ +#iso27002/2022/EN diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.5 Secure authentication.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.5 Secure authentication.md new file mode 100644 index 0000000..345523b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.5 Secure authentication.md @@ -0,0 +1 @@ +#iso27002/2022/EN diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.7 Protection against malware.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.7 Protection against malware.md new file mode 100644 index 0000000..b2c1464 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.7 Protection against malware.md @@ -0,0 +1,58 @@ +#iso27002/2022/EN + +# 8.7  **Protection** **against** **malware** + +## Control +Protection against malware should be implemented and supported by appropriate user awareness. + +## Purpose + +To ensure information and other associated assets are protected against malware. + +## Guidance + +Protection against malware should be based on malware detection and repair software, information security awareness, appropriate system access and change management controls. Use of malware detection and repair software alone is not usually adequate. The following guidance should be considered: + +a)   implementing rules and controls that prevent or detect the use of unauthorized software \[e.g. application allowlisting (i.e. using a list providing allowed applications)] (see [[ISO_27002_OT 8.19 Installation of software on operational systems|8.19]] and [[ISO_27002_OT 8.32 Change management|8.32]]) + +b)   implementing controls that prevent or detect the use of known or suspected malicious websites (e.g. blocklisting); + +c)   reducing vulnerabilities that can be exploited by malware \[e.g. through technical vulnerability management (see [[ISO_27002_OT 8.8 Management of technical vulnerabilities|8.8]] and [[ISO_27002_OT 8.19 Installation of software on operational systems|8.19]])]; + +d)   conducting regular automated validation of the software and data content of systems, especially for systems supporting critical business processes; investigating the presence of any unapproved files or unauthorized amendments; + +e)   establishing protective measures against risks associated with obtaining files and software either from or via external networks or on any other medium; + +f)   installing and regularly updating malware detection and repair software to scan computers and electronic storage media. Carrying out regular scans that include: + +1)   scanning any data received over networks or via any form of electronic storage media, for malware before use; + +2)   scanning email and instant messaging attachments and downloads for malware before use. Carrying out this scan at different places (e.g. at email servers, desktop computers) and when entering the network of the organization; + +3)   scanning webpages for malware when accessed; + +g)   determining the placement and configuration of malware detection and repair tools based on risk assessment outcomes and considering: + +1)   defence in depth principles where they would be most effective. For example, this can lead to malware detection in a network gateway (in various application protocols such as email, file transfer and web) as well as user endpoint devices and servers; +2)   the evasive techniques of attackers (e.g. the use of encrypted files) to deliver malware or the use of encryption protocols to transmit malware; + +h)   taking care to protect against the introduction of malware during maintenance and emergency procedures, which can bypass normal controls against malware; + +i) implementing a process to authorize temporarily or permanently disable some or all measures against malware, including exception approval authorities, documented justification and review date. This can be necessary when the protection against malware causes disruption to normal operations; + +j) preparing appropriate business continuity plans for recovering from malware attacks, including +all necessary data and software backup (including both online and offline backup) and recovery measures (see [[ISO_27002_OT 8.13 Information backup|8.13]]); + +k)   isolating environments where catastrophic consequences can occur; + +l) defining procedures and responsibilities to deal with protection against malware on systems, including training in their use, reporting and recovering from malware attacks; + +m)  providing awareness or training (see [[ISO_27002_OT 6.3 Information security awareness, education and training|6.3]]) to all users on how to identify and potentially mitigate the receipt, sending or installation of malware infected emails, files or programs \[the information collected in n) and o) can be used to ensure awareness and training are kept up-to-date]; + +n)   implementing procedures to regularly collect information about new malware, such as subscribing to mailing lists or reviewing relevant websites; + +o)   verifying that information relating to malware, such as warning bulletins, comes from qualified and reputable sources (e.g. reliable internet sites or suppliers of malware detection software) and is accurate and informative. + +## Other **information** + +It is not always possible to install software that protects against malware on some systems (e.g. some industrial control systems). Some forms of malware infect computer operating systems and computer firmware such that common malware controls cannot clean the system and a full reimaging of the operating system software and sometimes the computer firmware is necessary to return to a secure state. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.8 Management of technical vulnerabilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.8 Management of technical vulnerabilities.md new file mode 100644 index 0000000..23212c3 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.8 Management of technical vulnerabilities.md @@ -0,0 +1,241 @@ +#iso27002/2022/EN +x +## 8.8 Management of technical vulnerabilities + + + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | + +| -------------- | ---------------------------------------- | --------------------- | ------------------------------- | ------------------------------- | + +| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Threat_and_vulnerability_management | #Governance_and_Ecosystem #Protection #Defence | + + + +**Control** + + + +Information about technical vulnerabilities of information systems in use should be obtained, the organization’s exposure to such vulnerabilities should be evaluated and appropriate measures should be taken. + + + +**Purpose** + + + +To prevent exploitation of technical vulnerabilities. + + + +**Guidance** + + + +Identifying technical vulnerabilities + + + +The organization should have an accurate inventory of assets (see 5.9to 5.14) as a prerequisite for effective technical vulnerability management; the inventory should include the software vendor, software name, version numbers, current state of deployment (e.g. what software is installed on what systems) and the person(s) within the organization responsible for the software. + + + +To identify technical vulnerabilities, the organization should consider: + + + +a\) defining and establishing the roles and responsibilities associated with technical vulnerability management, including vulnerability monitoring, vulnerability risk assessment, updating, asset tracking and any coordination responsibilities required; + + + +b\) for software and other technologies (based on the asset inventory list, see 5.9), identifying information resources that will be used for identifying relevant technical vulnerabilities and maintaining awareness about them. Updating the list of information resources based on changes in the inventory or when other new or useful resources are found; + + + +c\) requiring suppliers of information system (including their components) to ensure vulnerability reporting, handling and disclosure, including the requirements in applicable contracts (see 5.20); + + + +d\) using vulnerability scanning tools suitable for the technologies in use to identify vulnerabilities and to verify whether the patching of vulnerabilities was successful; + + + +e\) conducting planned, documented and repeatable penetration tests or vulnerability assessments by competent and authorized persons to support the identification of vulnerabilities. Exercising caution as such activities can lead to a compromise of the security of the system; + + + +f\) tracking the usage of third-party libraries and source code for vulnerabilities. This should be included in secure coding (see 8.28). + + + +The organization should develop procedures and capabilities to: + + + +a\) detect the existence of vulnerabilities in its products and services including any external component used in these; + + + +b\) receive vulnerability reports from internal or external sources. + + + +The organization should provide a public point of contact as part of a topic-specific policy on vulnerability disclosure so that researchers and others are able to report issues. The organization should establish vulnerability reporting procedures, online reporting forms and making use of appropriate threat intelligence or information sharing forums. The organization should also consider bug bounty programs where rewards are offered as an incentive to assist organizations in identifying vulnerabilities in order to appropriately remediate them. The organization should also share information with competent industry bodies or other interested parties. + + + +Evaluating technical vulnerabilities + + + +To evaluate identified technical vulnerabilities, the following guidance should be considered: + + + +a\) analyse and verify reports to determine what response and remediation activity is needed; + + + +b\) once a potential technical vulnerability has been identified, identifying the associated risks and the actions to be taken. Such actions can involve updating vulnerable systems or applying other controls. + + + +Taking appropriate measures to address technical vulnerabilities + + + +A software update management process should be implemented to ensure the most up-to-date approved patches and application updates are installed for all authorized software. If changes are necessary, the original software should be retained and the changes applied to a designated copy. All changes should be fully tested and documented, so that they can be reapplied, if necessary, to future software upgrades. If required, the modifications should be tested and validated by an independent evaluation body. + + + +The following guidance should be considered to address technical vulnerabilities: + + + +a\) taking appropriate and timely action in response to the identification of potential technical vulnerabilities; defining a timeline to react to notifications of potentially relevant technical vulnerabilities; + + + +b\) depending on how urgently a technical vulnerability needs to be addressed, carrying out the action according to the controls related to change management (see 8.32) or by following information security incident response procedures (see 5.26); + + + +c\) only using updates from legitimate sources (which can be internal or external to the organization); + + + +d\) testing and evaluating updates before they are installed to ensure they are effective and do not result in side effects that cannot be tolerated \[i.e. if an update is available, assessing the risks associated with installing the update (the risks posed by the vulnerability should be compared with the risk of installing the update)\]; + + + +e\) addressing systems at high risk first; + + + +f\) develop remediation (typically software updates or patches); + + + +g\) test to confirm if the remediation or mitigation is effective; + + + +h\) provide mechanisms to verify the authenticity of remediation; + + + +i\) if no update is available or the update cannot be installed, considering other controls, such as: + + + +1\) applying any workaround suggested by the software vendor or other relevant sources; + + + +2\) turning off services or capabilities related to the vulnerability; + + + +3\) adapting or adding access controls (e.g. firewalls) at network borders (see 8.20to 8.22); + + + +4\) shielding vulnerable systems, devices or applications from attack through deployment of suitable traffic filters (sometimes called virtual patching); + + + +5\) increasing monitoring to detect actual attacks; + + + +6\) raising awareness of the vulnerability. + + + + +For acquired software, if the vendors regularly release information about security updates for their software and provide a facility to install such updates automatically, the organization should decide whether to use the automatic update or not. + + + +Other considerations + + + +An audit log should be kept for all steps undertaken in technical vulnerability management. + + + +The technical vulnerability management process should be regularly monitored and evaluated in order to ensure its effectiveness and efficiency. + + + +An effective technical vulnerability management process should be aligned with incident management activities, to communicate data on vulnerabilities to the incident response function and provide technical procedures to be carried out in case an incident occurs. + + + +Where the organization uses a cloud service supplied by a third-party cloud service provider, technical vulnerability management of cloud service provider resources should be ensured by the cloud service provider. The cloud service provider’s responsibilities for technical vulnerability management should be part of the cloud service agreement and this should include processes for reporting the cloud service provider's actions relating to technical vulnerabilities (see 5.23). For some cloud services, there are respective responsibilities for the cloud service provider and the cloud service customer. For example, the cloud service customer is responsible for vulnerability management of its own assets used for the cloud services. + + + +**Other information** + + + +Technical vulnerability management can be viewed as a sub-function of change management and as such can take advantage of the change management processes and procedures (see 8.32). + + + +There is a possibility that an update does not address the problem adequately and has negative side effects. Also, in some cases, uninstalling an update cannot be easily achieved once the update has been applied. + + + +If adequate testing of the updates is not possible (e.g. because of costs or lack of resources) a delay in updating can be considered to evaluate the associated risks, based on the experience reported by other users. The use of ISO/IEC 27031 can be beneficial. + + + +Where software patches or updates are produced, the organization can consider providing an automated update process where these updates are installed on affected systems or products without the need for intervention by the customer or the user. If an automated update process is offered, it can allow the customer or user to choose an option to turn off the automatic update or control the timing of the installation of the update. + + + +Where the vendor provides an automated update process and the updates can be installed on affected systems or products without the need for intervention, the organization determines if it applies the automated process or not. One reason for not electing for automated update is to retain control over when the update is performed. For example, a software used for a business operation cannot be updated until the operation has completed. + + + +A weakness with vulnerability scanning is that it is possible it does not fully account for defence in depth: two countermeasures that are always invoked in sequence can have vulnerabilities that are masked by strengths in the other. The composite countermeasure is not vulnerable, whereas a vulnerability scanner can report that both components are vulnerable. The organization should therefore take care in reviewing and acting on vulnerability reports. + + + +Many organizations supply software, systems, products and services not only within the organization but also to interested parties such as customers, partners or other users. These software, systems, products and services can have information security vulnerabilities that affect the security of users. + + + +Organizations can release remediation and disclose information about vulnerabilities to users (typically through a public advisory) and provide appropriate information for software vulnerability database services. + + + +For mor e information relating to the management of technical vulnerabilities when using cloud computing, see the ISO/IEC 19086 series and ISO/IEC 27017. + + + +ISO/IEC 29147 provides detailed information on receiving vulnerability reports and publishing vulnerability advisories. ISO/IEC 30111 provides detailed information about handling and resolving reported vulnerabilities. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.9 Configuration management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.9 Configuration management.md new file mode 100644 index 0000000..7e62fd5 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_OT 8.9 Configuration management.md @@ -0,0 +1,79 @@ +#iso27002/2022/EN +## 8.9 Configuration management + +### Control +Configurations, including security configurations, of hardware, software, services and networks should be established, documented, implemented, monitored and reviewed. + +### Purpose +To ensure hardware, software, services and networks function correctly with required security settings, and configuration is not altered by unauthorized or incorrect changes. + +### Guidance + +#### General +The organization should define and implement processes and tools to enforce the defined configurations (including security configurations) for hardware, software, services (e.g. cloud services) and networks, for newly installed systems as well as for operational systems over their lifetime. + +Roles, responsibilities and procedures should be in place to ensure satisfactory control of all configuration changes. + +#### Standard templates + +Standard templates for the secure configuration of hardware, software, services and networks should be defined: + +a) using publicly available guidance (e.g. pre-defined templates from vendors and from independent security organizations); + +b) considering the level of protection needed in order to determine a sufficient level of security; + +c) supporting the organization’s information security policy, topic-specific policies, standards and other security requirements; + +d) considering the feasibility and applicability of security configurations in the organization’s context. + +The templates should be reviewed periodically and updated when new threats or vulnerabilities need to be addressed, or when new software or hardware versions are introduced. + +The following should be considered for establishing standard templates for the secure configuration of hardware, software, services and networks: + +a) minimizing the number of identities with privileged or administrator level access rights; + +b) disabling unnecessary, unused or insecure identities; + +c) disabling or restricting unnecessary functions and services; + +d) restricting access to powerful utility programs and host parameter settings; + +e) synchronizing clocks; + +f) changing vendor default authentication information such as default passwords immediately after installation and reviewing other important default security-related parameters; + +g) invoking time-out facilities that automatically log off computing devices after a predetermined period of inactivity; + +h) verifying that licence requirements have been met (see 5.32). + +#### Managing configurations +Established configurations of hardware, software, services and networks should be recorded and a log should be maintained of all configuration changes. These records should be securely stored. This can be achieved in various ways, such as configuration databases or configuration templates. + +Changes to configurations should follow the change management process (see 8.32). + +Configuration records can contain as relevant: + +a) up-to-date owner or point of contact information for the asset; + +b) date of the last change of configuration; + +c) version of configuration template; + +d) relation to configurations of other assets. + +#### Monitoring configurations +Configurations should be monitored with a comprehensive set of system management tools (e.g. maintenance utilities, remote support, enterprise management tools, backup and restore software) and should be reviewed on a regular basis to verify configuration settings, evaluate password strengths and assess activities performed. Actual configurations can be compared with the defined target templates. Any deviations should be addressed, either by automatic enforcement of the defined target configuration or by manual analysis of the deviation followed by corrective actions. + +### Other information +Documentation for systems often records details about the configuration of both hardware and software. + +System hardening is a typical part of configuration management. + +Configuration management can be integrated with asset management processes and associated tooling. + +Automation is usually more effective to manage security configuration (e.g. using infrastructure as code). + +Configuration templates and targets can be confidential information and should be protected from unauthorized access accordingly. + +# Related: +- [[ISO_27002_PE 8.9 Configuration management]] \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_OT 3 Terms, definitions and abbreviated terms.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_OT 3 Terms, definitions and abbreviated terms.md new file mode 100644 index 0000000..4ac17cb --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_OT 3 Terms, definitions and abbreviated terms.md @@ -0,0 +1,818 @@ +#iso27002/2022/EN + + +**3.1** **Terms** **and** **definitions** + + + +For the purposes of this document, the following terms and definitions apply. + + + +ISO and IEC maintain terminology databases for use in standardization at the following addresses: — ISO Online browsing platform: available at https://www.iso.org/obp + +— IEC Electropedia: available at https://www.electropedia.org/ + + + +**3.****1.1** + +**access** **control** + +means to ensure that physical and logical access to _assets_ (3.1.2) is authorized and restricted based on business and information security requirements + + + +**3.****1.2** + +**ass****et** + +anything that has value to the organization + + + +Note 1 to entry: In the context of information security, two kinds of assets can be distinguished: + + + +— the primary assets: — information; + +— business _processes_ (3.1.27) and activities; + + + +— the supporting assets (on which the primary assets rely) of all types, for example: — hardware; + +— software; — network; + +— _personnel_ (3.1.20); + + + + + +© ISO/IEC 2022 – All rights reserved **1** + + + + + + + +**ISO/IEC 27002:2022(E)** + + + + + + + +— site; + +Licensed to ISO27DIY / Richard Kranendonk (rkranendonk@mac.com) + +ISO Store Order: OP-582678 / Downloaded: 2022-02-17 Single user licence only, copying and networking prohibited. + + + +— organization’s structure. + + + +**3.****1.3** + +**attack** + +successful or unsuccessful unauthorized attempt to destroy, alter, disable, gain access to an _asset_ (3.1.2) or any attempt to expose, steal, or make unauthorized use of an _asset_ (3.1.2) + + + +**3.1.4** + +**aut****hentication** + +provision of assurance that a claimed characteristic of an _entity_ (3.1.11) is correct + + + +**3****.1.5** + +**au****thenticity** + +property that an _entity_ (3.1.11) is what it claims to be + + + +**3.1.6** + +**chain** **of** **custody** + +demonstrable possession, movement, handling and location of material from one point in time until another + + + +Note 1 to entry: Material includes information and other associated _assets_ (3.1.2) in the context of ISO/IEC 27002. + + + +[SOURCE: ISO/IEC 27050-1:2019, 3.1, modified — “Note 1 to entry” added] + + + +**3.****1.7** + +**confidential** **information** + +information that is not intended to be made available or disclosed to unauthorized individuals, _entities_ (3.1.11) or _processes_ (3.1.27) + + + +**3****.1.8** + +**control** + +measure that maintains and/or modifies risk + + + +Note 1 to entry: Controls include, but are not limited to, any _process_ (3.1.27), _policy_ (3.1.24), device, practice or other conditions and/or actions which maintain and/or modify risk. + + + +Note 2 to entry: Controls may not always exert the intended or assumed modifying effect. + + + +[SOURCE: ISO 31000:2018, 3.8] + + + +**3.****1.9** + +**disrupti****on** + +incident, whether anticipated or unanticipated, that causes an unplanned, negative deviation from the expected delivery of products and services according to an organization’s objectives + + + +[SOURCE: ISO 22301:2019, 3.10] + + + +**3.1****.10** + +**endpoint** **device** + +network connected information and communication technology (ICT) hardware device + + + +Note 1 to entry: Endpoint device can refer to desktop computers, laptops, smart phones, tablets, thin clients, printers or other specialized hardware including smart meters and Internet of things (IoT) devices. + + + +**3.1.11** + +**entity** + +item relevant for the purpose of operation of a domain that has recognizably distinct existence + + + +Note 1 to entry: An entity can have a physical or a logical embodiment. + + + + + + + +**2** © ISO/IEC 2022 – All rights reserved + + + + + + + + + + + + + + + + + +EXAMPLE + +Licensed to ISO27DIY / Richard Kranendonk (rkranendonk@mac.com) + +ISO Store Order: OP-582678 / Downloaded: 2022-02-17 + +Single user licence only, copying and networking prohibited. + +**ISO/IEC 27002:2022(E)** + + + + + + + +A person, an organization, a device, a group of such items, a human subscriber to a telecom + +service, a SIM card, a passport, a network interface card, a software application, a service or a website. + + + +[SOURCE: ISO/IEC 24760-1:2019, 3.1.1] + + + +**3.****1.12** + +**information** **processing** **facility** + +any information processing system, service or infrastructure, or the physical location housing it [SOURCE: ISO/IEC 27000:2018, 3.27, modified — "facilities" has been replaced with facility.] **3****.1.13** + +**information** **security** **breach** + +compromise of information security that leads to the undesired destruction, loss, alteration, disclosure of, or access to, protected information transmitted, stored or otherwise processed + + + +**3.1****.14** + +**information** **security** **event** + +occurrence indicating a possible _information_ _security_ _breach_ (3.1.13) or failure of _controls_ (3.1.8) + + + +[SOURCE: ISO/IEC 27035-1:2016, 3.3, modified — “breach of information security” has been replaced with “information security breach”] + + + +**3.1****.15** + +**information** **security incident** + +one or multiple related and identified _information_ _security_ _events_ (3.1.14) that can harm an organization’s _assets_ (3.1.2) or compromise its operations + + + +[SOURCE: ISO/IEC 27035-1:2016, 3.4] + + + +**3.1.16** + +**information** **security** **incident** **management** + +exercise of a consistent and effective approach to the handling of _information_ _security_ _incidents_ (3.1.15) [SOURCE: ISO/IEC 27035-1:2016, 3.5] + +**3****.1.17** + +**information** **system** + +set of applications, services, information technology _assets_ (3.1.2), or other information-handling components + + + +[SOURCE: ISO/IEC 27000:2018, 3.35] + + + +**3.1.18** + +**interested** **party** stakeholder + +person or organization that can affect, be affected by, or perceive itself to be affected by a decision or activity + + + +[SOURCE: ISO/IEC 27000:2018, 3.37] + + + +**3.****1.19** + +**non-repudiation** + +ability to prove the occurrence of a claimed event or action and its originating _entities_ (3.1.11) + + + +**3.1.20** + +**pers****onnel** + +persons doing work under the organization’s direction + + + +Note 1 to entry: The concept of personnel includes the organization’s members, such as the governing body, top management, employees, temporary staff, contractors and volunteers. + + + + + + + +© ISO/IEC 2022 – All rights reserved **3** + + + + + + + +**ISO/IEC 27002:2022(E)** + + + + + + + +**3.1****.21** + +Licensed to ISO27DIY / Richard Kranendonk (rkranendonk@mac.com) + +ISO Store Order: OP-582678 / Downloaded: 2022-02-17 Single user licence only, copying and networking prohibited. + +**personally identifiable** **information** + +**PII** + +any information that (a) can be used to establish a link between the information and the natural person to whom such information relates, or (b) is or can be directly or indirectly linked to a natural person. + + + +Note 1 to entry: The “natural person” in the definition is the _PII_ _principal_ (3.1.22). To determine whether a PII principal is identifiable, account should be taken of all the means which can reasonably be used by the privacy stakeholder holding the data, or by any other party, to establish the link between the set of PII and the natural person. + + + +[SOURCE: ISO/IEC 29100:2011/Amd.1:2018, 2.9] + + + +**3.1.22** + +**PII** **principal** + +natural person to whom the _personally identifiable_ _information_ _(PII)_ (3.1.21) relates + + + +Note 1 to entry: Depending on the jurisdiction and the particular data protection and privacy legislation, the synonym “data subject” can also be used instead of the term “PII principal”. + + + +[SOURCE: ISO/IEC 29100:2011, 2.11] + + + +**3.1.23** + +**PII** **processor** + +privacy stakeholder that processes _personally_ _identifiable_ _information_ _(PII)_ (3.1.21) on behalf of and in accordance with the instructions of a PII controller + + + +[SOURCE: ISO/IEC 29100:2011, 2.12] + + + +**3.1****.24** + +**policy** + +intentions and direction of an organization, as formally expressed by its top management [SOURCE: ISO/IEC 27000:2018, 3.53] + +**3.1.25** + +**privacy** **impact** **assessment** **PIA** + +overall _process_ (3.1.27) of identifying, analysing, evaluating, consulting, communicating and planning the treatment of potential privacy impacts with regard to the processing of _personally_ _identifiable_ _information_ _(PII)_ (3.1.21), framed within an organization’s broader risk management framework + + + +[SOURCE: ISO/IEC 29134:2017, 3.7, modified — Note 1 to entry removed.] + + + +**3.1.26** + +**procedure** + +specified way to carry out an activity or a _process_ (3.1.27) + + + +[SOURCE: ISO 30000:2009, 3.12] + + + +**3.1.27** + +**proce****ss** + +set of interrelated or interacting activities that uses or transforms inputs to deliver a result + + + +[SOURCE: ISO 9000:2015, 3.4.1, modified— Notes to entry removed.] + + + +**3.1****.28** + +**re****cord** + +information created, received and maintained as evidence and as an _asset_ (3.1.2) by an organization or person, in pursuit of legal obligations or in the transaction of business + + + + + + + + + +**4** © ISO/IEC 2022 – All rights reserved + +Licensed to ISO27DIY / Richard Kranendonk (rkranendonk@mac.com) + +ISO Store Order: OP-582678 / Downloaded: 2022-02-17 Single user licence only, copying and networking prohibited. + + + + + + + +**ISO/IEC 27002:2022(E)** + + + + + + + +Note 1 to entry: Legal obligations in this context include all legal, statutory, regulatory and contractual requirements. + + + +[SOURCE: ISO 15489-1:2016, 3.14, modified— “Note 1 to entry” added.] + + + +**3.1.29** + +**recovery** **point** **objective** + +**RPO** + +point in time to which data are to be recovered after a _disruption_ (3.1.9) has occurred [SOURCE: ISO/IEC 27031:2011, 3.12, modified — "must" replaced by "are to be".] **3.1.30** + +**recovery** **time** **objective** **RTO** + +period of time within which minimum levels of services and/or products and the supporting systems, applications, or functions are to be recovered after a _disruption_ (3.1.9) has occurred + + + +[SOURCE: ISO/IEC 27031:2011, 3.13, modified — "must" replaced by "are to be".] + + + +**3.1****.31** + +**reliability** + +property of consistent intended behaviour and results + + + +**3.1.32** + +**rule** + +accepted principle or instruction that states the organization’s expectations on what is required to be done, what is allowed or not allowed + + + +Note 1 to entry: Rules can be formally expressed in _topic-specific policies_ (3.1.35) and in other types of documents. + + + +**3.1.33** + +**sensitive** **information** + +information that needs to be protected from unavailability, unauthorized access, modification or public disclosure because of potential adverse effects on an individual, organization, national security or public safety + + + +**3****.1.34** + +**thr****eat** + +potential cause of an unwanted incident, which can result in harm to a system or organization [SOURCE: ISO/IEC 27000:2018, 3.74] + +**3.1.35** + +**topic-specific** **policy** + +intentions and direction on a specific subject or topic, as formally expressed by the appropriate level of management + + + +Note 1 to entry: Topic-specific policies can formally express _rules_ (3.1.32) or organization standards. Note 2 to entry: Some organizations use other terms for these topic-specific policies. + +Note 3 to entry: The topic-specific policies referred to in this document are related to information security. + + + +EXAMPLE Topic-specific policy on _access_ _control_ (3.1.1), topic-specific policy on clear desk and clear screen. + + + +**3.1.36** + +**u****ser** + +_interested_ _party_ (3.1.18) with access to the organization’s _information_ _systems_ (3.1.17) + + + +EXAMPLE _Personnel_ (3.1.20), customers, suppliers. + + + + + + + + + +© ISO/IEC 2022 – All rights reserved + + + + + + + + + + + +**5** + + + + + + + +**ISO/IEC 27002:2022(E)** + + + + + + + +**3.1.37** + +**user** **endpoint** **device** + +Licensed to ISO27DIY / Richard Kranendonk (rkranendonk@mac.com) + +ISO Store Order: OP-582678 / Downloaded: 2022-02-17 Single user licence only, copying and networking prohibited. + +_endpoint_ _device_ (3.1.10) used by users to access information processing services + + + +Note 1 to entry: User endpoint device can refer to desktop computers, laptops, smart phones, tablets, thin clients, etc. + + + +**3.1****.38** + +**vu****lnerability** + +weakness of an _asset_ (3.1.2) or _control_ (3.1.8) that can be exploited by one or more _threats_ (3.1.34) [SOURCE: ISO/IEC 27000:2018, 3.77] + + + +**3.2** **Abbreviated** **terms** + + + +ABAC attribute-based access control + + + +ACL access control list + + + +BIA business impact analysis + + + +BYOD bring your own device + + + +CAPTCHA completely automated public Turing test to tell computers and humans apart + + + +CPU central processing unit + + + +DAC discretionary access control + + + +DNS domain name system + + + +GPS global positioning system + + + +IAM identity and access management + + + +ICT information and communication technology + + + +ID identifier + + + +IDE integrated development environment + + + +IDS intrusion detection system + + + +IoT internet of things + + + +IP internet protocol + + + +IPS intrusion prevention system + + + +IT information technology + + + +ISMS information security management system + + + +MAC mandatory access control + + + +NTP network time protocol + + + +PIA privacy impact assessment + + + +PII personally identifiable information + + + + + + + +**6** © ISO/IEC 2022 – All rights reserved + +Licensed to ISO27DIY / Richard Kranendonk (rkranendonk@mac.com) + +ISO Store Order: OP-582678 / Downloaded: 2022-02-17 Single user licence only, copying and networking prohibited. + + + + + + + +**ISO/IEC 27002:2022(E)** + + + + + + + +PIN personal identification number + + + +PKI public key infrastructure + + + +PTP precision time protocol + + + +RBAC role-based access control + + + +RPO recovery point objective + + + +RTO recovery time objective + + + +SAST static application security testing + + + +SD secure digital + + + +SDN software-defined networking + + + +SD-WAN software-defined wide area networking + + + +SIEM security information and event management + + + +SMS short message service + + + +SQL structured query language + + + +SSO single sign on + + + +SWID software identification + + + +UEBA user and entity behaviour analytics + + + +UPS uninterruptible power supply + + + +URL uniform resource locator + + + +USB universal serial bus + + + +VM virtual machine + + + +VPN virtual private network + + + +WiFi wireless fidelity \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_3.2_BT Afgekorte termen.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_3.2_BT Afgekorte termen.md new file mode 100644 index 0000000..1cf1bc9 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_3.2_BT Afgekorte termen.md @@ -0,0 +1,97 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 3.2 Afgekorte termen + + + +ABAC attribute-based access control + +ACL access control list + +BIA business impact analysis + +BYOD bring your own device + +CAPTCHA completely automated public Turing test to tell computers and humans apart + +CPU central processing unit + +DAC discretionary access control + +DNS domain name system + +gps global positioning system + +IAM identity and access management + +ICT information and communication technology + +ID identifier + +IDE integrated development environment + +IDS intrusion detection system + +IoT internet of things + +IP internetprotocol + +IPS intrusion prevention system + +IT information technology + +ISMS information security management system + +MAC mandatory access control + +NTP network time protocol + +PIA privacy impact assessment + +PII personally identifiable information + +pin personal identification number + +PKI public key infrastructure + +PTP precision time protocol + +RBAC role-based access control + +RPO recovery point objective + +RTO recovery time objective + +SAST static application security testing + +SD secure digital + +SDN software-defined networking + +SD-WAN software-defined wide area networking + +SIEM security information and event management + +sms short message service + +SQL structured query language + +SSO single sign on + +SWID software identification + +UEBA user and entity behaviour analytics + +UPS uninterruptible power supply + +URL uniform resource locator + +USB universal serial bus + +VM virtual machine + +VPN virtual private network + +wifi wireless fidelity \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_4.1_BT Hoofdstukken.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_4.1_BT Hoofdstukken.md new file mode 100644 index 0000000..8973f49 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_4.1_BT Hoofdstukken.md @@ -0,0 +1,41 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 4.1 Hoofdstukken + + + +Dit document is als volgt ingedeeld: + + + +a) Organisatorische beheersmaatregelen (hoofdstuk 5) + + + +b) Mensgerichte beheersmaatregelen (hoofdstuk 6) + + + +c) Fysieke beheersmaatregelen (hoofdstuk 7) + + + +d) Technologische beheersmaatregelen (hoofdstuk 8) Er zijn 2 informatieve bijlagen: + + + +--- Bijlage A -- Attributen gebruiken + + + +--- Bijlage B -- Overeenstemming met ISO/IEC 27002:2013 + + + +In bijlage A wordt uitgelegd hoe een organisatie attributen (zie 4 kan gebruiken om haar eigen overzichten aan te maken op basis van de in dit document gedefinieerde of zelfbedachte attributen voor beheersmaatregelen. + + + +Bijlage B laat zien hoe de beheersmaatregelen in deze editie van ISO/IEC 27002 overeenstemmen met de vorige editie uit 2013. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_4.2_BT Thema's en attributen.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_4.2_BT Thema's en attributen.md new file mode 100644 index 0000000..16a2856 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_4.2_BT Thema's en attributen.md @@ -0,0 +1,47 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 4.2 Thema's en attributen + +De categorieën waarin beheersmaatregelen kunnen worden ingedeeld volgens de hoofdstukken 5 t/m 8 worden aangeduid als thema's. + +Beheersmaatregelen worden ingedeeld in de categorieën: + +a) mensgericht, als ze betrekking hebben op individuele personen; + +b) fysiek, als ze betrekking hebben op fysieke objecten; + +c) technologisch, als ze betrekking hebben op technologie; + +d) organisatorisch, in de overige gevallen. + +De organisatie kan attributen gebruiken om verschillende overzichten te creëren. Dit zijn verschillende indelingen in categorieën van beheersmaatregelen, gezien vanuit een ander perspectief op de thema's. Attributen kunnen worden gebruikt om beheersmaatregelen in verschillende overzichten te filteren, sorteren of presenteren voor verschillende doelgroepen. In bijlage A wordt uitgelegd hoe dit kan worden bereikt en wordt een voorbeeld van een overzicht gegeven. + +Bij wijze van voorbeeld is elke beheersmaatregel in dit document gerelateerd aan vijf attributen met bijbehorende attribuutwaarden (voorafgegaan door '#' om ze opzoekbaar te maken) \*). Dit is als volgt opgebouwd: + +\*) Nederlandse voetnoot: In deze vertaling zijn ook in 4.2 de attribuutwaarden van een '#' voorzien. + +a) Type beheersmaatregel + +Type beheersmaatregel is een attribuut om beheersmaatregelen te bezien vanuit het oogpunt van wanneer en hoe de beheersmaatregel tot veranderingen van het risico leidt met betrekking tot het zich voordoen van een informatiebeveiligingsincidente attribuutwaarden bestaan uit #Preventief (de beheersmaatregel is ervoor bedoeld te voorkomen dat er zich een informatiebeveiligingsincident voordoet), #Detectief (de beheersmaatregel treedt in werking wanneer er zich een informatiebeveiligingsincident voordoet) en #Corrigerend (de beheersmaatregel treedt in werking nadat er zich een informatiebeveiligingsincident heeft voorgedaan). + +b) Informatiebeveiligingseigenschappen + +Informatiebeveiligingseigenschappen is een attribuut om beheersmaatregelen te bezien vanuit het oogpunt: aan het behoud van welk kenmerk van informatie draagt de beheersmaatregel bij? De attribuutwaarden bestaan uit #Vertrouwelijkheid, #Integriteit en #Beschikbaarheid. + +c) Cybersecurityconcepten + +Cybersecurityconcepten is een attribuut om beheersmaatregelen te bekijken vanuit het oogpunt van het verband tussen beheersmaatregelen en de in het in ISO/IEC TS 27110 beschreven cybersecuritykader gedefinieerde cybersecurityconcepteneze attribuutwaarden bestaan uit #Identificeren, #Beschermen, #Detecteren, #Reageren en #Herstellen. + +d) Operationele capaciteiten + +Operationele capaciteiten is een attribuut om beheersmaatregelen te bekijken vanuit het perspectief van beroepsbeoefenaren op informatiebeveiligingscapaciteitene attribuutwaarden bestaan uit #Governance, #Beheer_van_bedrijfsmiddelen, #Informatiebescherming, #Personeelsbeveiliging, #Fysieke_beveiliging, #Systeem-_en_netwerkbeveiliging, #Toepassingsbeveiliging, #Veilige_configuratie, #Identiteits-_en_toegangsbeheer, #Beheer_van_dreigingen_en_kwetsbaarheden, #Continuïteit, #Beveiliging_in_leveranciersrelaties, #Juridisch_en_compliance, #Beheer_van_informatiebeveiligingsgebeurtenissen en #Borging_van_informatiebeveiliging. + +e) Beveiligingsdomeinen + +Beveiligingsdomeinen is een attribuut om beheersmaatregelen te bekijken vanuit het oogpunt van vier informatiebeveiligingsdomeinen: 'Governance_en_Ecosysteem' omvat 'Information System Security Governance & Risk Management' en 'Ecosystem cybersecurity management' (inclusief interne en externe belanghebbenden); 'Bescherming' omvat 'IT-beveiligingsarchitectuur', 'IT- beveiligingsbeheer', 'Identiteits- en toegangsbeheer', 'IT-beveiligingsonderhoud' en 'Fysieke en omgevingsbeveiliging'; 'Verdediging' omvat 'Detectie' en 'Computer Security Incident Management'; onder 'Veerkracht' (Resilience) wordt verstaan 'Continuïteit van de bedrijfsvoering' en 'Crisisbeheersing'e attribuutwaarden bestaan uit #Governance_en_Ecosysteem, #Bescherming, #Verdediging en #Veerkracht. + +De in dit document vermelde attributen zijn gekozen op basis van het feit dat ze als generiek genoeg worden beschouwd om door verschillende soorten organisaties te worden gebruiktrganisaties kunnen ervoor kiezen een of meer van de in dit document vermelde attributen buiten beschouwing te latene kunnen ook zelf attributen (met de bijbehorende attribuutwaarden) aanmaken om hun eigen organisatieoverzichten te maken. Hoofdstuk A.2 bevat voorbeelden van dergelijke attributen. + +Zie ook: [[ISO_27002_NL_Template_Attribuuttabel]] \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_4.3_BT Indeling beheersmaatregel.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_4.3_BT Indeling beheersmaatregel.md new file mode 100644 index 0000000..e640229 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_4.3_BT Indeling beheersmaatregel.md @@ -0,0 +1,21 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 4.3 Indeling beheersmaatregel + +De indeling van elke beheersmaatregel bevat het volgende: + +--- **Titel van de beheersmaatregel:** Korte naam van de beheersmaatregel; + +--- **Attribuuttabel**: Een tabel toont de waarde(n) van elk attribuut voor de beheersmaatregel in kwestie; + +--- **Beheersmaatregel:** Wat de beheersmaatregel is; + +--- **Doel**: Waarom de beheersmaatregel behoort te worden geïmplementeerd; + +--- **Richtlijn:** Hoe de beheersmaatregel behoort te worden geïmplementeerd; + +--- **Overige informatie:** Tekst met uitleg of verwijzingen naar andere gerelateerde documenten. + +Omwille van de leesbaarheid zijn lange richtlijnteksten die op meer onderwerpen ingaan, soms onderverdeelde titels van deze secties zijn onderstreept. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.10_BT Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.10_BT Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen.md new file mode 100644 index 0000000..74dbfd6 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.10_BT Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen.md @@ -0,0 +1,52 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.10 Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen + + +| Attribuut | Waarde | +| :----------------------------------- | :----------------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Beschermen | +| Operationele capaciteiten: | #Beheer_van_bedrijfsmiddelen #Informatiebescherming | +| Beveiligingsdomeinen: | #Governance_en_Ecosysteem #Bescherming | + +**Beheersmaatregel** + +Regels voor het aanvaardbaar gebruik van en procedures voor het omgaan met informatie en andere gerelateerde bedrijfsmiddelen behoren te worden vastgesteld, gedocumenteerd en geïmplementeerd. + +**Doel** + +Waarborgen dat informatie en andere gerelateerde bedrijfsmiddelen passend worden beschermd, gebruikt en behandeld. + +**Richtlijn** + +Personeel en externe gebruikers die informatie en andere gerelateerde bedrijfsmiddelen van de organisatie gebruiken of er toegang toe hebben, behoren bewust te worden gemaakt van de informatiebeveiligingseisen voor het beschermen van en omgaan met de informatie van de organisatie en andere gerelateerde bedrijfsmiddelenij behoren verantwoordelijk te zijn voor het gebruik dat zij maken van informatieverwerkende faciliteiten. + +De organisatie behoort onderwerpspecifiek beleid inzake het aanvaardbare gebruik van informatie en andere gerelateerde bedrijfsmiddelen vast te stellen en dit mee te delen aan iedereen die informatie en andere gerelateerde bedrijfsmiddelen gebruikt of hanteertet onderwerpspecifieke beleid inzake aanvaardbaar gebruik behoort duidelijk aan te geven hoe van personen wordt verwacht dat ze informatie en andere gerelateerde bedrijfsmiddelen gebruikenn het onderwerpspecifieke beleid behoort het volgende te worden opgenomen: + +a) verwacht en onaanvaardbaar gedrag van personen vanuit het oogpunt van informatiebeveiliging; + +b) wat wordt beschouwd als toegestaan en verboden gebruik van informatie en andere gerelateerde bedrijfsmiddelen; + +c) welke monitoringactiviteiten de organisatie uitvoert. + +Er behoren procedures voor aanvaardbaar gebruik te worden opgesteld voor de volledige levenscyclus van de informatie overeenkomstig de classificatie ervan (zie 5.12) en de vastgestelde risico\'s. Met de volgende aspecten behoort rekening te worden gehouden: + +a) toegangsbeperkingen die de beschermingseisen van elk classificatieniveau ondersteunen; + +b) onderhoud van een registratie van de bevoegde gebruikers van informatie en andere gerelateerde bedrijfsmiddelen; + +c) bescherming van tijdelijke of permanente kopieën van de informatie tot een niveau dat consistent is met de bescherming van de originele informatie; + +d) opslag van bedrijfsmiddelen die samenhangen met informatie in overeenstemming met de voorschriften van de fabrikant (zie 7.8); + +e) duidelijke markering van alle kopieën van (elektronische of fysieke) opslagmedia ter attentie van de bevoegde ontvanger (zie 7.10); + +f) autorisatie van het verwijderen van informatie en andere gerelateerde bedrijfsmiddelen en ondersteunde wismethode(n) (zie 8.10). + +**Overige informatie** + +Het is mogelijk dat de desbetreffende bedrijfsmiddelen niet direct tot de organisatie behoren, zoals openbare clouddienstenet gebruik van zulke bedrijfsmiddelen van derden en van bedrijfsmiddelen van de organisatie in verband met zulke externe bedrijfsmiddelen (bijv. informatie, software) behoort te worden geïdentificeerd al naargelang de situatie en beheerst, bijvoor middel van overeenkomsten met aanbieders van clouddienstenndien er gebruik wordt gemaakt van een op samenwerking gerichte werkomgeving, behoort er ook zorgvuldig te worden gehandeld. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.11_BT Retourneren van bedrijfsmiddelen.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.11_BT Retourneren van bedrijfsmiddelen.md new file mode 100644 index 0000000..b8694e1 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.11_BT Retourneren van bedrijfsmiddelen.md @@ -0,0 +1,49 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.11 Retourneren van bedrijfsmiddelen + + +| Attribuut | Waarde | +| :----------------------------------- | :----------------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Beschermen | +| Operationele capaciteiten: | #Beheer_van_bedrijfsmiddelen | +| Beveiligingsdomeinen: | #Bescherming | + + +**Beheersmaatregel** + +Personeel en andere belanghebbenden, al naargelang de situatie, behoren alle bedrijfsmiddelen van de organisatie die ze in hun bezit hebben bij beëindiging van hun dienstverband, contract of overeenkomst te retourneren. + +**Doel** + +De bedrijfsmiddelen van de organisatie beschermen als onderdeel van de procedure voor het wijzigen of beëindigen van het dienstverband, het contract of de overeenkomst. + +**Richtlijn** + +In de wijzigings- of beëindigingsprocedure behoort formeel het retourneren van alle eerder verstrekte fysieke en elektronische bedrijfsmiddelen die het eigendom zijn van of toevertrouwd zijn aan de organisatie, te worden opgenomen. + +Ingeval personeel en andere belanghebbenden apparatuur van de organisatie kopen of eigen persoonlijke apparatuur gebruiken, behoren procedures te worden gevolgd om ervoor te zorgen dat alle relevante informatie wordt getraceerd en aan de organisatie wordt overgedragen en nauwkeurig van de apparatuur wordt verwijderd (zie 7.14). + +Indien personeel en andere belanghebbenden beschikken over kennis die belangrijk is voor de lopende bedrijfsvoering, behoort die informatie te worden gedocumenteerd en aan de organisatie te worden overgedragen. + +Tijdens de opzegtermijn en daarna behoort de organisatie het onbevoegd kopiëren van relevante informatie (bijv. intellectuele eigendom) door personeel van wie het dienstverband is opgezegd, te voorkomen. + +De organisatie behoort alle te retourneren informatie en andere gerelateerde bedrijfsmiddelen duidelijk te identificeren en documentereneze informatie en bedrijfsmiddelen kunnen onder andere zijn: + +a) 'endpoint devices' van gebruikers; + +b) draagbare opslagapparatuur; + +c) specialistische apparatuur; + +d) authenticatiehardware (bijv. mechanische sleutels, fysieke tokens en chipkaarten) voor informatiesystemen, locaties en fysieke archieven; + +e) fysieke kopieën van informatie. + +**Overige informatie** + +Het kan lastig zijn informatie te retourneren die zich bevindt op bedrijfsmiddelen die geen eigendom zijn van de organisatien dergelijke gevallen is het nodig het gebruik van informatie door middel van andere beheersmaatregelen voor informatiebeveiliging, zoals het beheer van toegangsrechten (5.18) of het gebruik van cryptografie (8.24) te beperken. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.12_BT Classificeren van informatie.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.12_BT Classificeren van informatie.md new file mode 100644 index 0000000..9d04e79 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.12_BT Classificeren van informatie.md @@ -0,0 +1,54 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.12 Classificeren van informatie + +| Attribuut | Waarde | +| :----------------------------------- | :----------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Identificeren | +| Operationele capaciteiten: | #Informatiebescherming | +| Beveiligingsdomeinen: | #Bescherming #Verdediging | + +**Beheersmaatregel** + +Informatie behoort te worden geclassificeerd volgens de informatiebeveiligingsbehoeften van de organisatie, op basis van de eisen voor vertrouwelijkheid, integriteit, beschikbaarheid en relevante belanghebbenden. + +**Doel** + +Bewerkstelligen dat het identificeren van en het inzicht in de beschermingsbehoeften voor informatie in overeenstemming zijn met het belang ervan voor de organisatie. + +**Richtlijn** + +De organisatie behoort een onderwerpspecifiek beleid inzake het classificeren van informatie vast te stellen en aan alle relevante belanghebbenden mee te delen. + +De organisatie behoort in het classificatieschema rekening te houden met eisen voor vertrouwelijkheid, integriteit en beschikbaarheid. + +Classificaties en gerelateerde beschermende beheersmaatregelen voor informatie behoren rekening te houden met de bedrijfsbehoeften ten aanzien van het delen of beperken van informatie, het beschermen van de integriteit van informatie en het waarborgen van beschikbaarheid, alsmede wettelijke eisen met betrekking tot de vertrouwelijkheid, integriteit of beschikbaarheid van de informatie. Andere bedrijfsmiddelen dan informatie kunnen ook worden geclassificeerd in overeenstemming met de classificatie van informatie die is opgeslagen in, verwerkt door of anderszins behandeld of beschermd door het bedrijfsmiddel. + +Eigenaren van informatie behoren verantwoordelijk te zijn voor de classificatie ervan. + +Het classificatieschema behoort regels voor het classificeren te bevatten en criteria voor het na verloop van tijd opnieuw beoordelen van de classificatie. Resultaten van classificatie behoren te worden geactualiseerd in overeenstemming met wijzigingen in de waarde, gevoeligheid en het belang van informatie in de loop van de levenscyclus. + +Het schema behoort te worden afgestemd op het onderwerpspecifieke beleid inzake toegangsbeveiliging (zie [[ISO_27002_2022_NL_BT 5.1 Beleidsregels voor informatiebeveiliging|5.1]]) en het behoort te kunnen ingaan op specifieke bedrijfsbehoeften van de organisatie. + +De classificatie kan worden vastgesteld aan de hand van de mate van effect die compromittering van de informatie zou hebben op de organisatielk in het schema gedefinieerd niveau behoort een naam te krijgen die betekenis heeft in de context van de toepassing van het classificatieschema. + +Het schema behoort organisatiebreed consistent te zijn en te zijn opgenomen in de procedures van de organisatie zodat iedereen informatie en relevante andere gerelateerde bedrijfsmiddelen op dezelfde manier classificeert. Op deze manier heeft iedereen een gemeenschappelijk begrip van beschermingseisen en past iedereen de passende bescherming toe. + +Het binnen de organisatie gebruikte classificatieschema kan verschillen van de schema's die andere organisaties gebruiken, zelf als de namen voor niveaus op elkaar lijkenovendien kan de classificatie van informatie die tussen organisaties wordt getransporteerd verschillen, afhankelijk van de context ervan binnen elke organisatie, zelfs als de organisaties dezelfde classificatieschema's gebruiken. Daarom behoren overeenkomsten met andere organisaties waarin het delen van informatie voorkomt, procedures te bevatten voor het identificeren van de classificatie van die informatie en voor het interpreteren van de classificatieniveaus van andere organisaties. De overeenstemming tussen verschillende schema's kan worden vastgesteld door te zoeken naar gelijkwaardigheid in de gerelateerde methoden voor hantering en bescherming. + +**Overige informatie** + +Classificatie biedt personen die met informatie omgaan, een beknopte indicatie van hoe deze te behandelen en te beschermen. Het aanmaken van informatiegroepen met gelijksoortige beschermingsbehoeften en het specificeren van informatiebeveiligingsprocedures die gelden voor alle informatie in elke groep, vergemakkelijken diteze aanpak vermindert de behoefte aan afzonderlijke risicobeoordeling en speciaal ontworpen beheersmaatregelen. + +Het is mogelijk dat informatie na verloop van tijd niet meer gevoelig of essentieel is. Als de informatie bijvoorbeeld openbaar is gemaakt, gelden er niet langer vertrouwelijkheidseisen voor, maar kan het nog steeds nodig zijn deze vanwege de integriteits- en beschikbaarheidseigenschappen ervan te beschermen. Met deze aspecten behoort rekening te worden gehouden omdat overclassificatie kan leiden tot het implementeren van onnodige beheersmaatregelen, wat resulteert in extra kosten, terwijl onderclassificatie kan leiden tot onvoldoende beheersmaatregelen om de informatie tegen compromittering te beschermen. + +Bij wijze van voorbeeld kan een classificatieschema betreffende de vertrouwelijkheid van informatie worden gebaseerd op de volgende vier niveaus: + +a) openbaarmaking veroorzaakt geen schade; +b) openbaarmaking veroorzaakt geringe reputatieschade of een geringe operationele impact; +c) openbaarmaking heeft een kortdurende significante impact op de operationele of bedrijfsdoelstellingen; +d) openbaarmaking heeft een ernstige impact op de langetermijnbedrijfsdoelstellingen of brengt het voortbestaan van de organisatie in gevaar. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.13_BT Labelen van informatie.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.13_BT Labelen van informatie.md new file mode 100644 index 0000000..cdafd81 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.13_BT Labelen van informatie.md @@ -0,0 +1,63 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.13 Labelen van informatie + +| Attribuut | Waarde | +| :----------------------------------- | :----------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Beschermen | +| Operationele capaciteiten: | #Informatiebescherming | +| Beveiligingsdomeinen: | #Verdediging #Bescherming | + +**Beheersmaatregel** + +Om informatie te labelen behoort een passende reeks procedures te worden vastgesteld en geïmplementeerd in overeenstemming met het informatieclassificatieschema dat is vastgesteld door de organisatie. + +**Doel** + +Het communiceren van de classificatie van informatie mogelijk maken en het automatiseren van informatieverwerking en -beheer ondersteunen. + +**Richtlijn** + +Procedures voor het labelen van informatie behoren te gaan over informatie en andere gerelateerde bedrijfsmiddelen in alle formatene labeling behoort in overeenstemming te zijn met het classificatieschema vastgesteld in 5e labels behoren gemakkelijk herkenbaar te zijne procedures behoren richtlijnen te geven over waar en hoe labels zijn bevestigd, rekening houdend met hoe de informatie wordt bereikt of hoe de bedrijfsmiddelen worden gehanteerd afhankelijk van de soorten opslagmediae procedures kunnen het volgende definiëren: + +a) gevallen waarin labelen niet wordt toegepast (bijvij niet-vertrouwelijke informatie, om de werklast te verminderen); + +b) de manier van labelen van informatie die wordt verzonden door of opgeslagen op elektronische of fysieke middelen, of een ander formaat; + +c) hoe om te gaan met gevallen waarin labelen niet mogelijk is (bijvanwege technische beperkingen). + +Voorbeelden van labeltechnieken zijn: + +a) fysieke labels; + +b) kop- en voetteksten; + +c) metagegevens; + +d) watermerken; + +e) rubberen stempels. + +Digitale informatie behoort gebruik te maken van metagegevens om informatie te identificeren, beheren en beheersen, met name wat betreft vertrouwelijkheid. Metagegevens behoren ook het doelmatig en correct zoeken naar informatie mogelijk te maken. Metagegevens behoren mogelijk te maken dat systemen interactie met elkaar hebben en op basis van de toegekende classificatielabels besluiten nemen. + +De procedures behoren te beschrijven hoe metagegevens aan informatie worden gekoppeld, welke labels behoren te worden gebruikt en hoe gegevens behoren te worden gehanteerd, in overeenstemming met het informatiemodel en de ICT-architectuur van de organisatie. + +Relevante aanvullende metagegevens behoren te worden toegevoegd door systemen wanneer ze informatie verwerken, afhankelijk van de informatiebeveiligingseigenschappen ervan. + +Personeel en andere belanghebbenden behoren op de hoogte te worden gebracht van de labelprocedures. Al het personeel behoort de benodigde training te krijgen om te waarborgen dat informatie juist wordt gelabeld en dienovereenkomstig wordt behandeld. + +Output van systemen die informatie bevatten die is geclassificeerd als gevoelig of essentieel, behoort een passend classificatielabel te dragen. + +**Overige informatie** + +Het labelen van geclassificeerde informatie is een belangrijke eis voor het delen van informatie. + +Andere nuttige metagegevens die aan de informatie kunnen worden gekoppeld, zijn welk proces van de organisatie de informatie heeft aangemaakt, en op welk tijdstip. + +Het labelen van informatie en andere gerelateerde bedrijfsmiddelen kan soms negatieve effecten hebben. Geclassificeerde bedrijfsmiddelen zijn gemakkelijker te identificeren door kwaadwillenden, die daarvan mogelijk misbruik maken. + +Bepaalde systemen voorzien individuele bestanden of registraties in databases niet van labels met de classificatie, maar beschermen alle informatie op het hoogste classificatieniveau van de informatie die erin vervat is of mag zijnet is gebruikelijk in dergelijke systemen dat informatie wordt geïdentificeerd en vervolgens gelabeld op het moment van exporteren. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.14_BT Overdragen van informatie.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.14_BT Overdragen van informatie.md new file mode 100644 index 0000000..bdd181a --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.14_BT Overdragen van informatie.md @@ -0,0 +1,117 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.14 Overdragen van informatie + +| Attribuut | Waarde | +| :----------------------------------- | :-------------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Beschermen | +| Operationele capaciteiten: | #Beheer_van_bedrijfsmiddelen #Informatiebescherming | +| Beveiligingsdomeinen: | #Bescherming | + + +**Beheersmaatregel** + +Er behoren regels, procedures of overeenkomsten voor informatieoverdracht te zijn vastgesteld voor alle soorten van overdracht binnen de organisatie en tussen de organisatie en andere partijen. + +**Doel** + +Handhaven van de beveiliging van informatie die wordt uitgewisseld binnen een organisatie en met een externe belanghebbende. + +**Richtlijn** + +Algemeen + +De organisatie behoort een onderwerpspecifiek beleid inzake de overdracht van informatie vast te stellen en aan alle relevante belanghebbenden mee te delenegels, procedures en overeenkomsten om informatie die wordt overgedragen te beschermen, behoren de classificatie van de desbetreffende informatie te weerspiegelenanneer informatie wordt overgedragen tussen de organisatie en derden, behoren transportovereenkomsten (met inbegrip van authenticatie van de ontvanger) te worden vastgesteld en gehandhaafd om informatie in alle vormen tijdens overdracht te beschermen (zie 5.10). + +Informatie kan worden overgedragen via elektronische overdracht, door fysieke opslagmedia over te dragen en via mondelinge overdracht. + +Voor alle soorten van overdracht van informatie behoren de regels, procedures en overeenkomsten het volgende te omvatten: + +a) beheersmaatregelen die ervoor zijn ontworpen om overgedragen informatie te beschermen tegen interceptie, toegang door onbevoegden, kopiëren, wijziging, foutieve routering, vernietiging en 'denial of service', met inbegrip van toegangsbeveiligingsniveaus die passend zijn bij de classificatie van de desbetreffende informatie en eventuele speciale beheersmaatregelen die vereist zijn om gevoelige informatie te beschermen, zoals het gebruik van cryptografische technieken (zie 8.24); + +b) beheersmaatregelen om de traceerbaarheid en onweerlegbaarheid te waarborgen, met inbegrip van het in stand houden van een bewakingsketen voor informatie tijdens het overdragen; + +c) identificatie van passende contactpersonen met betrekking tot het overdragen, met inbegrip van de eigenaren van de informatie, risico-eigenaren, beveiligingsfunctionarissen en beheerders van informatie, voor zover van toepassing; + +d) verantwoordelijkheden en aansprakelijkheden in geval van informatiebeveiligingsincidenten, zoals verlies van fysieke opslagmedia of gegevens; + +e) gebruik van een afgesproken labelsysteem voor gevoelige of essentiële informatie dat waarborgt dat de betekenis van de labels meteen duidelijk is en dat de informatie passend is beschermd (zie 5.13); + +f) betrouwbaarheid en beschikbaarheid van de overdrachtdienst; + +g) het onderwerpspecifieke beleid of richtlijnen over aanvaardbaar gebruik van overdragen van informatiefaciliteiten (zie 5.10); + +h) richtlijnen voor het bewaren en verwijderen van alle bedrijfsregistraties, met inbegrip van berichten; + +OPMERKING Er kan lokale wet- en regelgeving bestaan inzake het bewaren en verwijderen van bedrijfsregistraties. + +i) aandacht voor andere relevante eisen van wet- en regelgeving, statutaire en contractuele eisen (zie 5.31, 5.32, 5.33, 5.34) in verband met het overdragen van informatie (bijv. eisen voor elektronische handtekeningen). + + +Elektronisch transport + +In regels, procedures en overeenkomsten behoort ook rekening te worden gehouden met de volgende punten bij het gebruik van elektronische communicatiefaciliteiten voor het overdragen van informatie: + +a) het detecteren van en beschermen tegen malware die kan worden overgebracht door het gebruik van elektronische communicatie (zie 8.7); + +b) bescherming van als bijlage gecommuniceerde gevoelige elektronische informatie; + +c) het voorkómen dat documenten en berichten in mededelingen naar het verkeerde adres of nummer worden gestuurd; + +d) het verkrijgen van toestemming voorafgaand aan het gebruiken van externe openbare diensten zoals instant messaging, sociale netwerken, het delen van bestanden of opslag in de cloud; + +e) sterkere authenticatieniveaus bij het overdragen van informatie via openbaar toegankelijke netwerken; + +f) beperkingen die samenhangen met het gebruik van elektronische communicatiefaciliteiten (bijv. het geautomatiseerd doorsturen van e-mail naar externe e-mailadressen voorkomen); + +g) personeel en andere belanghebbenden adviseren geen berichten met essentiële informatie via sms of andere vormen van instant messaging te verzenden, aangezien deze op openbare plekken (en derhalve door onbevoegden) kunnen worden gelezen of kunnen worden opgeslagen op apparaten die niet afdoende zijn beschermd; + +h) personeel en andere belanghebbenden informeren over problemen in verband met het gebruiken van faxapparatuur of -diensten, namelijk: + +1) onbevoegde toegang tot ingebouwde berichtenboxen om berichten op te vragen; + +2) opzettelijk of onbedoeld programmeren van machines, waardoor berichten naar bepaalde nummers worden gestuurd. + +Fysiek overdragen van opslagmedia + +Bij het overdragen van fysieke opslagmedia, waaronder papier, behoort in de regels, procedures en overeenkomsten ook te zijn voorzien in: + +a) verantwoordelijkheden voor het beheersen en notificeren van overdracht, verzending en ontvangst; + +b) het garanderen van correcte adressering en overdracht van het bericht; + +c) verpakking die de inhoud beschermt tegen fysieke schade waarvan aannemelijk is dat deze zich kan voordoen tijdens het overdragen en overeenkomstig de specificaties van fabrikanten, bijv. verpakking die bescherming biedt tegen omgevingsfactoren die de doeltreffendheid kunnen verminderen van het herstellen van opslagmedia, zoals blootstelling aan warmte, vocht of elektromagnetische velden; met gebruikmaking van de minimale technische normen voor verpakking en verzending (bijv. het gebruik van ondoorzichtige enveloppen); + +d) een door het management goedgekeurde lijst van goedgekeurde betrouwbare koeriers; + +e) koeriersidentificatienormen; + +f) afhankelijk van het classificatieniveau van de informatie in of op de over te dragen opslagmedia, de toepassing van beheersmaatregelen waardoor manipulatie duidelijk wordt aangetoond of die tegen manipulatie bestendig zijn (bijv. tassen, containers); + +g) procedures om de identificatie van koeriers te verifiëren; + +h) een goedgekeurde lijst van derden die vervoers- of koeriersdiensten verlenen, afhankelijk van de classificatie van de informatie; + +i) het bijhouden van registraties die de inhoud van de opslagmedia en de toegepaste bescherming identificeren, een lijst bevatten van bevoegde ontvangers waarin ook wordt vastgelegd hoe vaak de media zijn overgedragen naar de beheerder en in ontvangst zijn genomen op de plaats van bestemming. + +Mondelinge overdracht + +Om de mondelinge overdracht van informatie te beschermen, behoren personeel en andere belanghebbenden eraan te worden herinnerd dat zij: + +a) geen vertrouwelijke mondelinge gesprekken behoren te voeren op openbare plekken of via onveilige communicatiekanalen, aangezien deze door onbevoegden kunnen worden afgeluisterd; + +b) geen berichten die vertrouwelijke informatie bevatten, behoren achter te laten op antwoordapparaten of als spraakbericht, omdat deze kunnen worden afgespeeld door onbevoegde personen, op gemeenschappelijke systemen kunnen worden opgeslagen of onjuist kunnen worden opgeslagen als gevolg van foutieve nummerkeuze; + +c) op het juiste niveau behoren te zijn gescreend om naar het gesprek te mogen luisteren; + +d) behoren te waarborgen dat passende beheersmaatregelen voor de ruimte zijn geïmplementeerd (bijv. geluidsdichtheid, dichte deur); + +e) gevoelige gesprekken altijd behoren te beginnen met een disclaimer zodat de aanwezigen het classificatieniveau kennen van wat ze gaan horen en eventuele eisen met betrekking tot de omgang ermee. + + +**Overige informatie** +Geen overige informatie. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.15_BT Toegangsbeveiliging.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.15_BT Toegangsbeveiliging.md new file mode 100644 index 0000000..65d1cda --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.15_BT Toegangsbeveiliging.md @@ -0,0 +1,86 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.15 Toegangsbeveiliging + +| Attribuut | Waarde | +| :----------------------------------- | :----------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Beschermen | +| Operationele capaciteiten: | #Identiteits-_en_toegangsbeheer | +| Beveiligingsdomeinen: | #Bescherming | + + +**Beheersmaatregel** + +Er behoren regels op basis van bedrijfs- en informatiebeveiligingseisen te worden vastgesteld en geïmplementeerd om de fysieke en logische toegang tot informatie en andere gerelateerde bedrijfsmiddelen te beheersen. + +**Doel** + +Toegang voor bevoegden bewerkstelligen en toegang voor onbevoegden tot informatie en andere gerelateerde bedrijfsmiddelen voorkomen. + +**Richtlijn** + +Eigenaren van informatie en andere gerelateerde bedrijfsmiddelen behoren informatiebeveiligings- en bedrijfseisen met betrekking tot toegangsbeveiliging vast te stellen. Er behoort onderwerpspecifiek beleid inzake toegangsbeveiliging te worden gedefinieerd waarin rekening wordt gehouden met deze eisen en dit behoort naar alle desbetreffende belanghebbenden te worden gecommuniceerd. + +Bij deze eisen en het onderwerpspecifieke beleid behoort rekening te worden gehouden met het volgende: + +a) vaststellen voor welke entiteiten welke soort toegang tot de informatie en andere gerelateerde bedrijfsmiddelen vereist is; + +b) beveiliging van toepassingen (zie 8.26); + +c) fysieke toegang waarvoor ondersteuning door passende fysieke toegangsbeveiliging nodig is (zie 7.2, 7.3, 7.4); + +d) regels voor informatieverspreiding en -autorisatie (bijvet 'need-to-know'-principe), informatiebeveiligingsniveaus en -classificatie (zie 5.10, 5.12, 5.13); + +e) beperkingen op speciale toegangsrechten (zie 8.2); + +f) functiescheiding (zie 5.3); + +g) relevante wet- en regelgeving en contractuele verplichtingen met betrekking tot het beperken van de toegang tot gegevens of diensten (zie 5.31, 5.32, 5.33, 5.34, 8.3); + +h) scheiding van toegangsbeveiligingsfuncties (bijvoegangsverzoek, -autorisatie, -administratie); + +i) formele autorisatie voor verzoeken om toegang (zie 5.16 en 5.18); + +j) het beheer van toegangsrechten (zie 5.18); + +k) registratie (zie 8.15). + +Er behoren regels voor toegangsbeveiliging te worden geïmplementeerd door passende toegangsrechten en -beperkingen voor de desbetreffende entiteiten te definiëren en toe te wijzen (zie 5.16). Een entiteit kan zowel staan voor een menselijke gebruiker, als voor een technisch of logisch object (bijven machine, apparaat of dienst)m het toegangsbeveiligingsbeheer te vereenvoudigen, kunnen er specifieke rollen aan groepen entiteiten worden toegewezen. + +Bij het definiëren en implementeren van regels voor toegangsbeveiliging behoort rekening te worden gehouden met het volgende: + +a) consistentie tussen de toegangsrechten en de informatieclassificatie; + +b) consistentie tussen de toegangsrechten en de behoeften en eisen met betrekking tot de fysieke beveiliging van de buitengrenzen; + +c) het in aanmerking nemen van alle soorten beschikbare verbindingen in gedistribueerde omgevingen zodat entiteiten alleen toegang krijgen tot informatie en andere gerelateerde bedrijfsmiddelen, waaronder netwerken en netwerkdiensten waarvoor zij als gebruiker bevoegd zijn; + +d) het overwegen hoe elementen of factoren die relevant zijn voor dynamische toegangsbeveiliging kunnen worden weergegeven. + +**Overige informatie** + +Er worden vaak overkoepelende principes gebruikt in de toegangsbeveiligingscontext. Twee van de meest gebruikte principes zijn: + +a) 'need-to-know': een entiteit krijgt alleen toegang tot de informatie die de entiteit in kwestie nodig heeft voor het uitvoeren van zijn functies (verschillende functies of rollen betekenen verschillende 'need-to-know'-informatie en daardoor verschillende toegangsprofielen); + +b) noodzaak tot gebruik ('need-to-use'): een entiteit krijgt alleen toegang tot de informatietechnologie-infrastructuur indien daarvoor een duidelijke noodzaak bestaat. + +Bij het opstellen van regels voor toegangsbeveiliging behoort aandacht te worden besteed aan het volgende: + +a) het vaststellen van regels gebaseerd op de vooronderstelling van het 'least privilege' (minste rechten): 'Alles is in principe verboden tenzij het uitdrukkelijk is toegelaten', in plaats van de zwakkere regel 'Alles is in principe toegelaten tenzij het uitdrukkelijk is verboden'; + +b) wijzigingen in informatielabels (zie 5.13) die automatisch door informatieverwerkende faciliteiten worden aangebracht, en wijzigingen die naar keuze van de gebruiker worden aangebracht; + +c) wijzigingen in toegangsrechten voor gebruikers die automatisch door het informatiesysteem worden aangebracht, en wijzigingen die door een beheerder worden aangebracht; + +d) de momenten van het definiëren en regelmatig beoordelen van de goedkeuring. + +Regels voor toegangsbeveiliging behoren te worden ondersteund door formele procedures (zie 5.17, 5.18, 8.2, 8.3, 8.4, 8.5, 8.18) en gedefinieerde verantwoordelijkheden (zie 5.2, 5.17). + +Er zijn diverse manieren om toegangsbeveiliging te implementeren, waaronder MAC ('mandatory access control' - verplichte toegangsbeveiliging), DAC ('discretionary access control' - discretionaire toegangsbeveiliging), RBAC ('role-based access control' - op rollen gebaseerde toegangsbeveiliging) en ABAC ('attribute-based access control' - op attributen gebaseerde toegangsbeveiliging). + +Regels voor toegangsbeveiliging kunnen ook dynamische elementen bevatten (bijv. een functie die toegangsinstanties uit het verleden of specifieke omgevingswaarden beoordeelt). Regels voor toegangsbeveiliging kunnen met verschillende granulariteit worden geïmplementeerd, uiteenlopend van het afdekken van volledige netwerken of systemen tot specifieke gegevensvelden, en hierbij kunnen ook eigenschappen zoals de locatie van de gebruiker of het soort netwerkverbinding dat voor de toegang wordt gebruikt, in aanmerking worden genomeneze principes, evenals de wijze waarop granulaire toegangsbeveiliging wordt gedefinieerd, kunnen een aanmerkelijk kosteneffect hebbentrengere regels en meer granulariteit leiden doorgaans tot hogere kostenan de hand van bedrijfseisen en risico-overwegingen behoort te worden gedefinieerd welke regels voor toegangsbeveiliging worden toegepast en welke granulariteit vereist is. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.16_BT Identiteitsbeheer.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.16_BT Identiteitsbeheer.md new file mode 100644 index 0000000..f6a7bd2 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.16_BT Identiteitsbeheer.md @@ -0,0 +1,56 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.16 Identiteitsbeheer + +| Attribuut | Waarde | +| :----------------------------------- | :----------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Beschermen | +| Operationele capaciteiten: | #Identiteits-_en_toegangsbeheer | +| Beveiligingsdomeinen: | #Bescherming | + + +**Beheersmaatregel** + +De volledige levenscyclus van identiteiten behoort te worden beheerd. + +**Doel** + +De unieke identificatie van personen en systemen die toegang hebben tot de informatie en andere gerelateerde bedrijfsmiddelen van de organisatie, en een juiste toewijzing van toegangsrechten mogelijk maken. + +**Richtlijn** + +De processen die worden gebruikt in de context van identiteitsbeheer, behoren te bewerkstelligen dat: + +a) indien identiteiten aan personen zijn toegewezen, een specifieke identiteit slechts aan één persoon wordt gekoppeld zodat de persoon ertoe kan worden gehouden rekenschap af te leggen voor met deze specifieke identiteit verrichte handelingen; + +b) aan meer personen toegewezen identiteiten (bijvedeelde identiteiten) alleen zijn toegestaan wanneer ze om zakelijke of operationele redenen nodig zijn en ze aan speciale goedkeuring en documentatie worden onderworpen; + +c) naar behoren gescheiden goedkeuring en onafhankelijk lopend toezicht wordt uitgeoefend indien identiteiten aan niet-menselijke entiteiten zijn toegewezen; + +d) identiteiten tijdig gedeactiveerd of verwijderd worden als ze niet meer nodig zijn (bijv. als de gerelateerde entiteiten worden verwijderd of niet langer worden gebruikt of als de aan een identiteit gekoppelde persoon de organisatie heeft verlaten of van rol is veranderd); + +e) in een specifiek domein één enkele identiteit aan één enkele entiteit wordt gekoppeld \[d.w.z dat wordt vermeden dat meerdere identiteiten binnen dezelfde context aan dezelfde entiteit worden gekoppeld (dubbele identiteiten)\]; + +f) registraties worden bijgehouden van alle belangrijke gebeurtenissen betreffende het gebruik en het beheer van gebruikersidentiteiten en authenticatie-informatie. + +De organisatie behoort een ondersteunend proces te hebben ingesteld voor het omgaan met veranderingen aan informatie met betrekking tot gebruikersidentiteiten. Deze processen kunnen het opnieuw verifiëren van vertrouwde documenten met betrekking tot een persoon omvatten. + +Wanneer gebruik wordt gemaakt van door derden verstrekte of uitgegeven identiteiten (bijvoegangsgegevens voor sociale media), behoort de organisatie te bewerkstelligen dat deze identiteiten van derden de vereiste mate van vertrouwen bieden en dat eventueel daarmee samenhangende risico's bekend zijn en voldoende worden behandeldit kan beheersmaatregelen in verband met de derden (zie 5.19) alsmede beheersmaatregelen in verband met gerelateerde authenticatie-informatie (zie 5.17) omvatten. + +**Overige informatie** + +Het verlenen of intrekken van toegang tot informatie en andere gerelateerde bedrijfsmiddelen is doorgaans een meerstapsprocedure: + +a) het bevestigen van de zakelijke eisen voor het vaststellen van een identiteit; + +b) het verifiëren van de identiteit van een entiteit alvorens deze een logische identiteit toe te kennen; + +c) het vaststellen van een identiteit; + +d) het configureren en activeren van de identiteitit omvat ook het configureren en initieel instellen van gerelateerde authenticatiediensten; + +e) het verlenen of intrekken van specifieke toegangsrechten aan de identiteit, op basis van passende beslissingen over autorisatie of rechten (zie 5.18). \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.17_BT Beheren van authenticatie-informatie.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.17_BT Beheren van authenticatie-informatie.md new file mode 100644 index 0000000..78c7bc7 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.17_BT Beheren van authenticatie-informatie.md @@ -0,0 +1,88 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.17 Beheren van authenticatie-informatie + +| Attribuut | Waarde | +| :----------------------------------- | :----------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Beschermen | +| Operationele capaciteiten: | #Identiteits-_en_toegangsbeheer | +| Beveiligingsdomeinen: | #Bescherming | + +### Beheersmaatregel +De toewijzing en het beheer van authenticatie-informatie behoort te worden beheerst door middel van een beheerproces waarvan het informeren van het personeel over de juiste manier van omgaan met authenticatie-informatie deel uitmaakt. +### Doel +Goede authenticatie bewerkstelligen en fouten van authenticatieprocessen voorkomen. + +### Richtlijn + +**Toewijzing van authenticatie-informatie** + +Het toewijzings- en beheerproces behoort te bewerkstelligen dat: + +a) tijdens inschrijfprocessen automatisch gegenereerde persoonlijke wachtwoorden of pincodes als tijdelijke geheime authenticatie informatie niet geraden kunnen worden en gebruikers deze na het eerste gebruik moeten wijzigen; + +b) er procedures worden vastgesteld om de identiteit van een gebruiker vast te stellen voordat nieuwe, vervangende of tijdelijke authenticatie-informatie wordt verstrekt; + +c) authenticatie-informatie, met inbegrip van tijdelijke authenticatie-informatie, op een beveiligde manier aan de gebruikers wordt verzonden (bijv. via een geauthenticeerd en beschermd kanaal) en het gebruik van onbeschermde (onversleutelde) e-mailberichten voor dit doel wordt vermeden; + +d) gebruikers de ontvangst van authenticatie-informatie bevestigen; + +e) standaard authenticatie-informatie zoals vooraf gedefinieerd of door verkopers verstrekt onmiddellijk na het installeren van systemen of software wordt gewijzigd; + +f) registraties van belangrijke gebeurtenissen in verband met de toewijzing en het beheer van authenticatie-informatie worden bewaard en de vertrouwelijkheid ervan gewaarborgd is, en dat de registratiemethode is goedgekeurd (bijv. met behulp van een goedgekeurd wachtwoordkluisinstrument). + +**Verantwoordelijkheden van gebruikers** + +Elke persoon die toegang heeft tot of gebruikmaakt van authenticatie-informatie, behoort erop te worden gewezen ervoor te zorgen dat: + +a) geheime authenticatie-informatie zoals wachtwoorden geheim wordt gehouden. Persoonlijke geheime authenticatie-informatie mag niet met anderen worden gedeeld. Geheime authenticatie-informatie die wordt gebruikt in de context van identiteiten die zijn gekoppeld aan meer gebruikers of aan niet-persoonlijke entiteiten, wordt uitsluitend gedeeld met bevoegden. + +b) aangetaste of gecompromitteerde authenticatie-informatie wordt gewijzigd onmiddellijk na kennisgeving ervan of na andere aanwijzingen dat deze is gecompromitteerd; + +c) wanneer wachtwoorden als authenticatie-informatie worden gebruikt, er sterke wachtwoorden volgens aanbevelingen aan de hand van 'best practices' worden gekozen, bijvoorbeeld: + +1) wachtwoorden worden niet gebaseerd op gegevens die iemand anders gemakkelijk met behulp van persoonsgerelateerde informatie (zoals namen, telefoonnummers en geboortedata) kan raden of achterhalen; + +2) wachtwoorden worden niet gebaseerd op woordenboekwoorden of combinaties daarvan; + +3) gebruik gemakkelijk te onthouden wachtzinnen en probeer daarin alfanumerieke en speciale tekens te gebruiken; + +4) wachtwoorden hebben een minimumlengte; + +d) een en hetzelfde wachtwoord niet voor verschillende diensten en op verschillende systemen wordt gebruikt; + +e) de verplichting om deze regels na te leven ook wordt opgenomen in de arbeidsovereenkomst (zie 6.2); + +**Systeem voor wachtwoordbeheer** + +Wanneer wachtwoorden worden gebruikt als authenticatie-informatie, behoort het wachtwoordbeheersysteem: + +a) gebruikers de mogelijkheid te bieden hun eigen wachtwoord te kiezen en te wijzigen, en een bevestigingsprocedure te bevatten om foutieve invoer te adresseren; + +b) sterke wachtwoorden af te dwingen volgens aanbevelingen aan de hand van 'best practices' (zie c) van 'Verantwoordelijkheden van gebruikers'); + +c) gebruikers te dwingen hun wachtwoord bij het eerste inloggen te wijzigen; + +d) af te dwingen dat wachtwoorden worden gewijzigd wanneer dat nodig is, bijv. na een beveiligingsincident of bij beëindiging of wijziging van dienstverband wanneer een gebruiker beschikt over bekende wachtwoorden voor identiteiten die actief blijven (bijv. gedeelde identiteiten); + +e) het hergebruik van eerdere wachtwoorden te voorkomen; + +f) het gebruik van veelgebruikte wachtwoorden en gecompromitteerde gebruikersnamen wachtwoordcombinaties uit gehackte systemen te voorkomen; + +g) wachtwoorden niet op het scherm te tonen als ze worden ingevoerd; + +h) wachtwoorden in beschermde vorm op te slaan en te versturen. + +Wachtwoordversleuteling en hashing behoren te worden uitgevoerd volgens goedgekeurde cryptografische technieken voor wachtwoorden (zie 8.24). + +### Overige informatie + +Wachtwoorden of wachtzinnen zijn een algemeen gebruikt type authenticatie-informatie en zijn een gebruikelijk middel om de identiteit van een gebruiker te verifiëren. Andere typen authenticatie-informatie zijn cryptografische sleutels en andere gegevens die zijn opgeslagen op hardware tokens (bijv. chipkaarten) die authenticatiecodes produceren, en biometrische gegevens zoals irisscans of vingerafdrukken. Aanvullende informatie is te vinden in de ISO/IEC 24760-reeks. + +Verplichten dat wachtwoorden vaak worden gewijzigd kan een probleem zijn, aangezien gebruikers geïrriteerd kunnen raken door de frequente wijzigingen, nieuwe wachtwoorden kunnen vergeten, ze op onveilige plaatsen kunnen noteren, of onveilige wachtwoorden kunnen kiezen. Als 'Single Sign On' (SSO) of andere authenticatiebeheerinstrumenten (bijv. wachtwoordkluizen) beschikbaar worden gesteld, vermindert dat de hoeveelheid authenticatie-informatie die gebruikers moeten beschermen, waardoor de doeltreffendheid van deze beheersmaatregel kan toenemen. Echter, deze instrumenten kunnen ook de impact van openbaarmaking van authenticatie-informatie vergroten. + +Bepaalde toepassingen vereisen dat wachtwoorden voor gebruikers door een onafhankelijke instantie worden toegewezen. In dergelijke gevallen zijn de punten a), c) en d) van 'Systeem voor wachtwoordbeheer' niet van toepassing. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.17_NN Beheren van authenticatie-informatie.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.17_NN Beheren van authenticatie-informatie.md new file mode 100644 index 0000000..061a9a3 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.17_NN Beheren van authenticatie-informatie.md @@ -0,0 +1,61 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +# 5.17 Beheren van authenticatie-informatie +ISO 27002:2022 [[ISO_27002_2022_NL_BT 5.17 Beheren van authenticatie-informatie|Brontekst]] + +#### Wat +Er moet een proces zijn voor toewijzing en beheer van authenticatie-informatie, met aandacht voor de communicatie naar medewerkers hierover. +#### Waarom +Zorgen voor passende authenticatie en voorkomen van fouten in het proces. +#### Hoe + +##### Verstrekking en wijziging +- tijdelijke wachtwoorden of pincodes die bij inschrijving verstrekt worden, mogen niet gemakkelijk te raden zijn, en moeten na het eerste gebruik verplicht gewijzigd worden; +- gebruikers moeten hun eigen wachtwoord mogen kiezen – daarbij hoort een bevestigingsprocedure om invoerfouten te voorkómen en moeten 'sterke' wachtwoorden worden afgedwongen (zie 'Verantwoordelijkheden van gebruikers'); +- bij invoer mag het wachtwoord niet op het scherm getoond worden (om 'afkijken' te voorkomen); +- Hergebruik van wachtwoorden moet worden voorkomen; +- bij nieuwe, vervangende of tijdelijke authenticatie-informatie moet eerst de identiteit van een gebruiker worden vastgesteld; +- authenticatie-informatie moet altijd versleuteld worden opgeslagen en verzonden (dus niet in onversleutelde mails)[^1]; +- gebruikers moeten ontvangst van authenticatie-informatie bevestigen; +- acties rond het verstrekken en wijzigen van authenticatie-informatie moeten geregistreerd worden (bijv. in beveiligde logfiles of in een wachtwoordkluis) +- bij de installatie van software en systemen moet altijd direct de standaard authenticatie-informatie worden gewijzigd – dit geldt ook voor bijv. wachtwoorden die door verkopers/consultants verstrekt worden. +- Na een beveiligingsincident moeten wachtwoordwijzigingen worden afgedwongen. +- Wachtwoorden van groepsaccounts moeten gewijzigd worden bij uitdiensttredingen en functiewijzigingen. +- Veelgebruikte en gecompromitteerde wachtwoorden moeten gewijzigd worden – dit kan gesignaleerd worden met security scans en 'hacking alerts' zoals voorzien in de meeste wachtwoordkluizen. + +##### Verantwoordelijkheden van gebruikers +- Wachtwoorden moeten 'sterk' zijn: + - gebruik 'wachtzinnen' die makkelijk te onthouden zijn en gebruik daarin nummers, leestekens en speciale tekens; + - zorg voor een minimale lengte; + - gebruik géén persoonlijke informatie als namen, telefoonnummers, adressen en geboortedata; + - gebruik géén woordenboekwoorden of combinaties daarvan; +- Authenticatie-informatie mag niet met anderen worden gedeeld. Bij niet-persoonlijke accounts (bijv. groepsaccounts) mag de informatie alleen met bevoegde personen (bijv. leden van die groep) gedeeld worden. +- Als authenticatie-informatie gelekt is ('gecompromitteerd'), moet die onmiddellijk gewijzigd worden. +- Gebruik nooit hetzelfde wachtwoord voor verschillende systemen of diensten; +- Zorg dat deze regels als verplichting worden opgenomen in de arbeidsovereenkomst (zie [[ISO_27002_2022_NL_NN 6.2 Arbeidsovereenkomst|6.2]]); + +#### Overige informatie +- Het frequent afdwingen van wachtwoordwijzigingen kan contra-productief zijn: het zorgt voor irritatie bij gebruikers, nieuwe wachtwoorden worden gemakkelijk vergeten en op onveilige plekken worden genoteerd, en gebruikers kiezen sneller voor gemakkelijk te onthouden (en te raden) wachtwoorden. +- Het gebruik van 'Single Sign On' (SSO) en wachtwoordkluizen kan dit risico verminderen, maar aan de andere kant kan het lekken van een wachtwoord hiervan ook weer een grotere impact hebben. +- In plaats van wachtwoorden of wachtzinnen kunnen ook andere authenticatie-middelen gebruikt worden, zoals cryptografische sleutels, hardware tokens, en biometrische gegevens (multi-factor authenticatie). + +#### Bewijs +Auditors kijken naar bewijzen van de implementatie van het proces. Dit kan bijvoorbeeld de volgende vorm aannemen: + +| Omschrijving van bewijs | ISO27DIY artefact | +| ----------------------- | ----------------- | +| Omschrijving 1 | Artefact 1 | + +#### Gerelateerd +Naar deze maatregel wordt verwezen in: +- [ ] Andere beheersmaatregelen binnen dezelfde norm die verwijzen naar deze maatregel + +Andere gerelateerde ISO 27x beheersmaatregelen: +- [ ] Gerelateerde ISO 27x beheersmaatregelen die *niet* letterlijk in de brontekst genoemd worden. + + + +[^1]: Gebruik voor versleuteling en hashing goedgekeurde technieken (zie [[ISO_27002_2022_NL_NN 8.24 Gebruik van cryptografie|8.24]]). + diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.18_BT Toegangsrechten.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.18_BT Toegangsrechten.md new file mode 100644 index 0000000..92ac8c9 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.18_BT Toegangsrechten.md @@ -0,0 +1,103 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- + +## 5.18 Toegangsrechten + +| Attribuut | Waarde | +| :----------------------------------- | :----------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Beschermen | +| Operationele capaciteiten: | #Identiteits-_en_toegangsbeheer | +| Beveiligingsdomeinen: | #Bescherming | + + +**Beheersmaatregel** + +Toegangsrechten met betrekking tot informatie en andere gerelateerde bedrijfsmiddelen behoren te worden verstrekt, beoordeeld, aangepast en verwijderd overeenkomstig het onderwerpspecifieke beleid en de regels inzake toegangsbeveiliging van de organisatie. + +**Doel** + +Bewerkstelligen dat de toegang tot informatie en andere gerelateerde bedrijfsmiddelen wordt vastgesteld en goedgekeurd overeenkomstig de bedrijfseisen. + +**Richtlijn** + +Verlenen en intrekken van toegangsrechten + +De procedure voor het toewijzen of intrekken van fysieke en logische toegangsrechten aan de geauthenticeerde identiteit van een entiteit behoort te omvatten: + +a) autorisatie van de eigenaar van de informatie en andere gerelateerde bedrijfsmiddelen verkrijgen voor het gebruik van de informatie en andere gerelateerde bedrijfsmiddelen (zie 5e verlening van aparte goedkeuring voor toegangsrechten door het management kan ook passend zijn; + +b) de bedrijfseisen en het onderwerpspecifieke beleid en de regels inzake toegangsbeveiliging van de organisatie in overweging nemen; + +c) overwegen functies te scheiden, waaronder het scheiden van de rollen van goedkeuring en implementatie van de toegangsrechten en het scheiden van conflicterende rollen; + +d) bewerkstelligen dat toegangsrechten worden ingetrokken wanneer iemand geen toegang meer nodig heeft tot de informatie en andere gerelateerde bedrijfsmiddelen, en met name bewerkstelligen dat toegangsrechten van gebruikers die de organisatie hebben verlaten, tijdig worden ingetrokken; + +e) overwegen tijdelijke toegangsrechten voor beperkte duur te verlenen en deze op de afloopdatum in te trekken, met name voor tijdelijk personeel of indien slechts tijdelijk toegang vereist is voor het personeel; + +f) verifiëren dat het toegekende toegangsniveau in overeenstemming is met de onderwerpspecifieke beleidsregels inzake toegangsbeveiliging (zie 5.15) en aansluit op andere informatiebeveiligingseisen zoals functiescheiding (zie 5.3); + +g) waarborgen dat toegangsrechten pas worden geactiveerd (bijvoor dienstverleners) nadat de autorisatieprocedures succesvol zijn afgerond; + +h) een centraal overzicht bijhouden van toegangsrechten die aan een (logische of fysieke) gebruikersidentificatie zijn toegekend om toegang te verkrijgen tot informatie en andere gerelateerde bedrijfsmiddelen; + +i) de toegangsrechten aanpassen van gebruikers die van rol of functie zijn veranderd; + +j) fysieke en logische toegangsrechten verwijderen of aanpassen, hetgeen kan worden gedaan door sleutels, authenticatie-informatie, ID-kaarten of abonnementen te verwijderen, in te trekken, te herroepen of te vervangen; + +k) een registratie bijhouden van wijzigingen in de logische en fysieke toegangsrechten van gebruikers. + +Beoordeling van toegangsrechten + +Bij het regelmatig beoordelen van fysieke en logische toegangsrechten behoren de volgende aspecten in overweging te worden genomen: + + + +a) de toegangsrechten van gebruikers na een verandering binnen dezelfde organisatie (bijv. verandering van functie, promotie, demotie) of beëindiging van het dienstverband (zie 6.1 t/m 6.5); + + + +b) autorisaties voor speciale toegangsrechten. + + + +Overweging voorafgaand aan een wijziging of beëindiging van het dienstverband + + + +De toegangsrechten van een gebruiker tot informatie en gerelateerde bedrijfsmiddelen behoren te worden beoordeeld en aangepast of ingetrokken voorafgaand aan een wijziging aan of beëindiging van het dienstverband, op basis van de evaluatie van risicofactoren zoals: + + + +a) of de beëindiging of wijziging is geïnitieerd door de gebruiker of door het management en de reden voor de beëindiging; + + + +b) de actuele verantwoordelijkheden van de gebruiker; + + + +c) de waarde van de bedrijfsmiddelen die op dat moment toegankelijk zijn. + + + +**Overige informatie** + + + +Er behoort op te worden gelet dat gebruikerstoegangsrollen worden vastgesteld op basis van bedrijfseisen die een aantal toegangsrechten samenvatten in specifieke gebruikerstoegangsprofielen. Toegangsverzoeken en beoordelingen van toegangsrechten zijn gemakkelijker te beheren op het niveau van dergelijke rollen dan op het niveau van bijzondere rechten. + + + +Er behoort op te worden gelet dat in personeels- en dienstencontracten bepalingen worden opgenomen die sancties noemen voor personeel dat onbevoegde toegang probeert te verkrijgen (zie 5.20, 6.2, 6.4, 6.6). + + + +Ingeval het management de beëindiging van het dienstverband heeft geïnitieerd, bestaat het risico dat ontevreden personeel of externe gebruikers opzettelijk informatie corrumperen of informatieverwerkende faciliteiten saboterenersonen die ontslag nemen of worden ontslagen, kunnen in de verleiding komen informatie te verzamelen voor toekomstig gebruik. + + + +Klonen is een doelmatige manier waarop organisaties toegang aan gebruikers kunnen toewijzenit behoort echter met zorg te gebeuren, op basis van door de organisatie vastgestelde onderscheiden rollen, in plaats van een identiteit met alle gerelateerde toegangsrechten zomaar te klonenan het klonen is het inherente risico verbonden dat het leidt tot buitensporige toegangsrechten tot informatie en andere gerelateerde bedrijfsmiddelen. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.19_BT Informatiebeveiliging in leveranciersrelaties.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.19_BT Informatiebeveiliging in leveranciersrelaties.md new file mode 100644 index 0000000..db1bd16 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.19_BT Informatiebeveiliging in leveranciersrelaties.md @@ -0,0 +1,92 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- + +| Attribuut | Waarde | +| :----------------------------------- | :----------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Identificeren | +| Operationele capaciteiten: | #Beveiliging_in_leveranciersrelaties | +| Beveiligingsdomeinen: | #Governance_en_Eco-systeem #Bescherming | + + +## 5.19 Informatiebeveiliging in leveranciersrelaties + +**Beheersmaatregel** + +Er behoren processen en procedures te worden vastgesteld en geïmplementeerd om de informatiebeveiligingsrisico's in verband met het gebruik van producten of diensten van de leverancier te beheren. + +**Doel** + +Een overeengekomen niveau van informatiebeveiliging in leveranciersrelaties in stand houden. + +**Richtlijn** + +De organisatie behoort een onderwerpspecifiek beleid inzake leveranciersrelaties vast te stellen en aan alle relevante belanghebbenden mee te delen. + +De organisatie behoort processen en procedures te identificeren en te implementeren om de beveiligingsrisico\'s in verband met het gebruik van door leveranciers geleverde producten en diensten op te pakken. Dit behoort ook van toepassing te zijn op het gebruik door de organisatie van middelen van aanbieders van clouddiensten. Deze processen en procedures behoren de door de organisatie te implementeren processen en procedures te omvatten, alsmede de processen en procedures waarvan de organisatie vereist dat de leverancier ze implementeert om te starten met het gebruik van de producten of diensten van een leverancier of voor de beëindiging van het gebruik van de producten en diensten van een leverancier, zoals: + +a) het vaststellen en documenteren van de soorten leveranciers, bijv. ICT-diensten, logistieke voorzieningen, financiële diensten, ICT-infrastructuurcomponenten die gevolgen kunnen hebben voor de vertrouwelijkheid, integriteit en beschikbaarheid van de informatie van de organisatie; + +b) het vaststellen hoe leveranciers worden geëvalueerd en geselecteerd op basis van de gevoeligheid van informatie, producten en diensten (bijvet marktanalyse, referenties van klanten, beoordeling van documenten, beoordelingen op locatie, certificeringen); + +c) het evalueren en selecteren van producten of diensten van een leverancier met toereikende beheersmaatregelen voor informatiebeveiliging en deze beoordelen; met name de juistheid en volledigheid van de door de leverancier geïmplementeerde beheersmaatregelen die de integriteit van de informatie van, en de informatieverwerking door, de leverancier en daarmee de informatiebeveiliging van de organisatie garanderen; + +d) het definiëren van de informatie, ICT-diensten en fysieke infrastructuur van de organisatie waartoe leveranciers toegang hebben en die ze kunnen monitoren, beheersen of gebruiken; + +e) het definiëren van de door leveranciers geleverde soorten ICT-infrastructuurcomponenten en -diensten die van invloed kunnen zijn op de vertrouwelijkheid, integriteit en beschikbaarheid van de informatie van de organisatie + +f) het beoordelen en beheren van de informatiebeveiligingsrisico's in verband met: + +1) het gebruik door leveranciers van de informatie en andere gerelateerde bedrijfsmiddelen van de organisatie, met inbegrip van risico\'s die uitgaan van mogelijk kwaadwillig personeel van de leverancier; + +2) storingen of kwetsbaarheden van de door de leveranciers geleverde producten (met inbegrip van softwarecomponenten en subcomponenten die in deze producten worden gebruikt) of diensten; + +g) het monitoren van het voldoen aan vastgestelde informatiebeveiligingseisen voor elke soort leverancier en elke soort toegang, met inbegrip van beoordeling van derden en productvalidatie; + +h) het beperken van het niet voldoen door een leverancier ongeacht of dit is opgemerkt door monitoring of door andere middelen; + +i) het omgaan met incidenten en noodsituaties die verband houden met producten en diensten van leveranciers, met inbegrip van verantwoordelijkheden van zowel de organisatie als van de leveranciers; + +j) veerkracht- en, indien nodig, herstel- en calamiteitenmaatregelen om de beschikbaarheid te bewerkstelligen van de informatie van, en de informatieverwerking door, de leverancier en als gevolg daarvan de beschikbaarheid van de informatie van de organisatie; + +k) bewustwording en training voor het personeel van de organisatie dat contacten onderhoudt met personeel van de leverancier betreffende passende regels van betrokkenheid, onderwerpspecifieke beleidsregels, processen en procedures en gedrag, gebaseerd op het type leverancier en het soort toegang dat de leverancier heeft tot systemen en informatie van de organisatie; + +l) het beheren van het nodige transport van informatie, gerelateerde bedrijfsmiddelen en al het andere dat moet worden veranderd, en waarborgen dat informatiebeveiliging tijdens de gehele transportperiode wordt gehandhaafd; + +m) eisen om veilige beëindiging van de leveranciersrelatie te bewerkstelligen, met inbegrip van: + +3) het intrekken van toegangsrechten; +4) het omgaan met informatie; +5) het vaststellen van de eigendom van intellectuele eigendom die tijdens de verbintenis is ontwikkeld; +6) de overdraagbaarheid van informatie in geval van verandering van leverancier of 'insourcing'; +7) beheer van registraties; +8) het retourneren van bedrijfsmiddelen; +9) beveiligde verwijdering van informatie en andere gerelateerde bedrijfsmiddelen; +10) voortdurende geheimhoudingseisen; + +n) het niveau van beveiliging van personeel en fysieke beveiliging dat wordt verwacht van personeel en faciliteiten van de leverancier. + +Er behoort te worden nagedacht over de procedures voor het voortzetten van de verwerking van informatie indien de leverancier zijn producten of diensten niet meer kan leveren (bijvls gevolg van een incident, omdat de leverancier zijn bedrijf heeft gestaakt, of bepaalde onderdelen niet meer levert als gevolg van technologische ontwikkelingen) om vertraging bij het regelen van vervangende producten of diensten te voorkomen (bijvoor van tevoren een alternatieve leverancier aan te wijzen of altijd gebruik te maken van alternatieve leveranciers). + + +**Overige informatie** + +In gevallen waarin het voor een organisatie niet mogelijk is eisen te stellen aan een leverancier, behoort de organisatie: + +a) de in deze beheersmaatregel gegeven richtlijnen in aanmerking te nemen bij het nemen van beslissingen over de keuze van een leverancier en zijn product of dienst; + +b) op basis van een risicobeoordeling benodigde compenserende beheersmaatregelen te implementeren. + +Informatie kan in gevaar worden gebracht door leveranciers met een ontoereikend informatiebeveiligingsbeheer. Om de toegang tot informatie en andere gerelateerde bedrijfsmiddelen door de leverancier te beheren, behoren beheersmaatregelen te worden vastgesteld en toegepast. + +Indien er bijvoorbeeld een speciale noodzaak is om de informatie vertrouwelijk te houden, kunnen geheimhoudingsovereenkomsten of cryptografische technieken worden gebruikten. + +Ander voorbeeld vormen risico\'s voor de bescherming van persoonlijke gegevens als de leveranciersovereenkomst betrekking heeft op de overdracht van, of toegang tot informatie over de grens. De organisatie behoort zich ervan bewust te zijn dat de wettelijke of contractuele verantwoordelijkheid voor het beschermen van de informatie bij de organisatie ligt. + +Risico\'s kunnen ook worden veroorzaakt door ontoereikende beheersmaatregelen van door leveranciers geleverde ICT-infrastructuurcomponenten of -dienstenomponenten of diensten met storingen of kwetsbaarheden kunnen inbreuken op de informatiebeveiliging in de organisatie of voor een andere entiteit veroorzaken. Ze kunnen bijvoorbeeld besmetting met malware, aanvallen of andere schade aan andere entiteiten dan de organisatie veroorzaken. + + +Zie ISO/IEC 27036-2 voor nadere details. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.1_BT Beleidsregels voor informatiebeveiliging.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.1_BT Beleidsregels voor informatiebeveiliging.md new file mode 100644 index 0000000..82702c4 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.1_BT Beleidsregels voor informatiebeveiliging.md @@ -0,0 +1,114 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.1 Beleidsregels voor informatiebeveiliging + +| Attribuut | Waarde | +| :----------------------------------- | :----------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Identificeren | +| Operationele capaciteiten: | #Governance | +| Beveiligingsdomeinen: | #Governance_en_Eco-systeem #Veerkracht | + +**Beheersmaatregel** + +Informatiebeveiligingsbeleid en onderwerpspecifieke beleidsregels behoren te worden gedefinieerd, goedgekeurd door het management, gepubliceerd, gecommuniceerd aan en erkend door relevant personeel en relevante belanghebbenden en met geplande tussenpozen of zodra zich belangrijke veranderingen voordoen, te worden beoordeeld. + +**Doel** + +De voortdurende geschiktheid, toereikendheid, doeltreffendheid van de sturing en ondersteuning door het management overeenkomstig de bedrijfseisen en de eisen van wet- en regelgeving, statutaire en contractuele eisen bewerkstelligen. + +**Richtlijn** + +De organisatie behoort op het hoogste niveau een 'informatiebeveiligingsbeleid' te definiëren dat is goedgekeurd door de directie en dat de aanpak van de organisatie beschrijft om haar informatiebeveiliging te bereiken. + +Het informatiebeveiligingsbeleid behoort eisen in aanmerking te nemen die zijn ontleend aan: + +a) bedrijfsstrategie en -eisen; + +b) wet- en regelgeving en contracten; + +c) de huidige en verwachte risico\'s en dreigingen inzake informatiebeveiliging. + +Het informatiebeveiligingsbeleid behoort uiteenzettingen te bevatten betreffende: + +a) de definitie van informatiebeveiliging; + +b) informatiebeveiligingsdoelstellingen of het kader voor het vaststellen van informatiebeveiligingsdoelstellingen; + +c) principes die als leidraad dienen voor alle activiteiten in verband met informatiebeveiliging; + +d) een verbintenis om te voldoen aan van toepassing zijnde eisen in verband met informatiebeveiliging; + +e) een verbintenis tot continue verbetering van het managementsysteem voor informatiebeveiliging; + +f) toekenning van verantwoordelijkheden voor informatiebeveiligingsbeheer aan gedefinieerde rollen; + +g) procedures voor het behandelen van vrijgestelde situaties en uitzonderingen. + +Eventuele wijzigingen aan het informatiebeveiligingsbeleid behoren ter goedkeuring aan de directie te worden voorgelegd. + +Op een lager niveau behoort het informatiebeveiligingsbeleid te worden ondersteund door onderwerpspecifieke beleidsregels naarmate nodig is, om de implementatie van beheersmaatregelen voor informatiebeveiliging verder verplicht te stellene typische structuur van onderwerpspecifieke beleidsregels is dusdanig dat ze ingaan op de behoeften van bepaalde doelgroepen binnen een organisatie of dat ze bepaalde beveiligingsgebieden bestrijkennderwerpspecifieke beleidsregels behoren te worden afgestemd op het informatiebeveiligingsbeleid van de organisatie en dit aan te vullen. + +Voorbeelden van dergelijke onderwerpen zijn: + +a) toegangsbeveiliging; + +b) fysieke beveiliging en beveiliging van de omgeving; + +c) beheer van bedrijfsmiddelen; + +d) overdragen van informatie; + +e) beveiligde configuratie van en omgang met 'endpoint devices' van gebruikers; + +f) netwerkbeveiliging; + +g) beheer van informatiebeveiligingsincidenten; + +h) back-up; + +i) cryptografie en sleutelbeheer; + +j) classificatie van en omgaan met informatie; + +k) beheer van technische kwetsbaarheden; + +l) veilig ontwikkelen. + + +De verantwoordelijkheid voor het ontwikkelen, beoordelen en goedkeuren van de onderwerpspecifieke beleidsregels behoort te worden toegewezen aan relevant personeel, op basis van passend bevoegdheidsniveau en technische bekwaamheide beoordeling behoort mede het beoordelen te omvatten van mogelijkheden voor het verbeteren van het informatiebeveiligingsbeleid en onderwerpspecifieke beleidsregels en het informatiebeveiligingsbeheer van de organisatie als antwoord op veranderingen in: + +a) de bedrijfsstrategie van de organisatie; + +b) de technische omgeving van de organisatie; + +c) wet- en regelgeving en contracten; + +d) informatiebeveiligingsrisico\'s; + +e) huidige en verwachte dreigingen inzake informatiebeveiliging; + +f) lering die wordt getrokken uit informatiebeveiligingsgebeurtenissen en -incidenten. + +Bij de beoordeling van informatiebeveiligingsbeleid en onderwerpspecifieke beleidsregels behoort rekening te worden gehouden met de resultaten van directiebeoordelingen en auditsndien er één beleidsregel wordt gewijzigd, behoort, met het oog op de consistentie, te worden overwogen ook andere gerelateerde beleidsregels te beoordelen en bij te werken. + +Het informatiebeveiligingsbeleid en de onderwerpspecifieke beleidsregels behoren in een vorm die relevant, toegankelijk en begrijpelijk is voor de beoogde lezer te worden gecommuniceerd aan relevant personeel en relevante belanghebbendenan ontvangers van de beleidsregels behoort te worden verlangd dat ze bevestigen dat ze de beleidsregels, indien van toepassing, begrijpen en zich eraan zullen houdene organisatie kan voor deze beleidsdocumenten formaten en namen vaststellen die aan de behoeften van de organisatie voldoenn bepaalde organisaties kunnen het informatiebeveiligingsbeleid en de onderwerpspecifieke beleidsregels in een en hetzelfde document worden opgenomene organisatie kan deze onderwerpspecifieke beleidsregels aanduiden als normen, richtlijnen, beleidsregels enz. + +Als het informatiebeveiligingsbeleid of een onderwerpspecifieke beleidsregel buiten de organisatie wordt verspreid, behoort erop te worden gelet dat geen vertrouwelijke informatie openbaar wordt gemaakt. + +Tabel 1 illustreert de verschillen tussen informatiebeveiligingsbeleid en onderwerpspecifiek beleid. + +**Tabel 1 --- Verschillen tussen informatiebeveiligingsbeleid en onderwerpspecifiek beleid** + + +| | **Informatiebeveiligingsbeleid** | **Onderwerpspecifiek beleid** | +| :--------------------------------------------- | :------------------------------- | :---------------------------- | +| **Detailniveau** | Algemeen of op hoofdlijnen | Specifiek en gedetailleerd | +| **Gedocumenteerd en formeel goedgekeurd door** | De directie | Het passende managementniveau | + +**Overige informatie** + +Onderwerpspecifieke beleidsregels kunnen van organisatie tot organisatie verschillen. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.20_BT Adresseren van informatiebeveiliging in leveranciersovereenkomsten.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.20_BT Adresseren van informatiebeveiliging in leveranciersovereenkomsten.md new file mode 100644 index 0000000..7266e07 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.20_BT Adresseren van informatiebeveiliging in leveranciersovereenkomsten.md @@ -0,0 +1,89 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- + +## 5.20 Adresseren van informatiebeveiliging in leveranciersovereenkomsten + +| Attribuut | Waarde | +| :----------------------------------- | :----------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Identificeren | +| Operationele capaciteiten: | #Beveiliging_in_leveranciersrelaties | +| Beveiligingsdomeinen: | #Governance_en_Eco-systeem #Bescherming | + +**Beheersmaatregel** + +Relevante informatiebeveiligingseisen behoren te worden vastgesteld en met elke leverancier op basis van het type leveranciersrelatie te worden overeengekomen. + +**Doel** + +Een overeengekomen niveau van informatiebeveiliging in leveranciersrelaties in stand houden. + +**Richtlijn** + +Leveranciersovereenkomsten behoren te worden vastgesteld en gedocumenteerd om te waarborgen dat er tussen de organisatie en de leverancier duidelijkheid bestaat ten aanzien van de verplichtingen van beide partijen om te voldoen aan relevante informatiebeveiligingseisen. + +Om aan de vastgestelde informatiebeveiligingseisen te voldoen kan worden overwogen de volgende voorwaarden in de overeenkomsten op te nemen: + +a) omschrijving van de te verstrekken of te benaderen informatie en methoden om de informatie te verschaffen of toegankelijk te maken; + +b) classificatie van de informatie in overeenstemming met het classificatieschema van de organisatie (zie 5.10, 5.12, 5.13); + +c) mapping tussen het eigen classificatieschema van de organisatie en het classificatieschema van de leverancier; + +d) eisen van wet- en regelgeving, statutaire en contractuele eisen, met inbegrip van gegevensbescherming, het omgaan met persoonsgegevens, rechten van intellectuele eigendom en auteursrecht, en een beschrijving van hoe wordt gewaarborgd dat eraan wordt voldaan; + +e) de verplichting van elke contractpartij om overeengekomen beheersmaatregelen te implementeren, met inbegrip van toegangsbeveiliging, prestatiebeoordeling, monitoren, melden, rapportage en auditen en de verplichtingen van de leverancier om te voldoen aan de informatiebeveiligingseisen van de organisatie; + +f) de regels van aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen, met inbegrip van onaanvaardbaar gebruik indien noodzakelijk; + +g) procedures of voorwaarden voor autorisatie en voor het intrekken van de autorisatie voor het gebruik van de informatie en andere gerelateerde bedrijfsmiddelen van de organisatie door personeel van de leverancier (bijvan de hand van een specifieke lijst van personeel van leveranciers dat bevoegd is om de informatie en andere gerelateerde bedrijfsmiddelen van de organisatie te gebruiken); + +h) informatiebeveiligingseisen met betrekking tot de ICT-infrastructuur van de leverancier; met name minimale informatiebeveiligingseisen voor elk type informatie en elk type toegang, te gebruiken als basis voor individuele overeenkomsten met leveranciers op basis van de bedrijfsbehoeften en risicocriteria van de organisatie; + +i) schadeloosstellingen en herstel indien de contractant niet aan de eisen voldoet; + +j) eisen voor incidentbeheer en -procedures (in het bijzonder notificatie en samenwerking tijdens herstel van het incident); + +k) trainings- en bewustwordingseisen voor specifieke procedures en informatiebeveiligingseisen (bijv. voor incidentresponsprocedures, autorisatieprocedures); + +l) relevante voorzieningen voor uitbesteding, met inbegrip van de te implementeren beheersmaatregelen, zoals een overeenkomst over de inzet van onderleveranciers (bijvisen dat voor hen dezelfde verplichtingen gelden als voor de leverancier, eisen dat er een lijst van onderleveranciers wordt verstrekt en kennisgeving telkens voordat er iets verandert); + +m) relevante contacten, met inbegrip van een contactpersoon voor aangelegenheden betreffende informatiebeveiliging; + +n) screeningeisen, indien wettelijk toegestaan, voor het personeel van leveranciers, met inbegrip van verantwoordelijkheden voor het uitvoeren van de screening en kennisgevingsprocedures indien de screening niet is voltooid of de resultaten aanleiding geven tot twijfel of bezorgdheid; + +o) de bewijs- en borgingsmechanismen van attesten van derden voor relevante informatiebeveiligingseisen met betrekking tot de processen van leveranciers en een onafhankelijk rapport over de doeltreffendheid van beheersmaatregelen; + +p) het recht om de processen en beheersmaatregelen van de leverancier in verband met de overeenkomst te auditen; + +q) verplichting van de leverancier om periodiek een rapport te verstrekken over de doeltreffendheid van beheersmaatregelen, en overeenkomst over tijdige correctie van relevante kwesties die in het rapport aan de orde worden gesteld; + +r) procedures voor het oplossen van defecten en conflicten; + +s) voorzien in back-up die is afgestemd op de behoeften van de organisatie (wat betreft frequentie en type en opslaglocatie); + +t) het bewerkstelligen van de beschikbaarheid van een alternatieve faciliteit (dzoodherstellocatie) waarvoor niet dezelfde dreigingen gelden als voor de primaire faciliteit en overwegingen met betrekking tot alternatieve beheersmaatregelen waarop wordt teruggevallen indien de primaire beheersmaatregelen falen; + +u) de beschikking over een proces voor wijzigingsbeheer dat bewerkstelligt dat de organisatie vooraf op de hoogte wordt gebracht en de mogelijkheid heeft om wijzigingen niet te aanvaarden; + +v) fysieke beveiligingsbeheersmaatregelen die passen bij de classificatie van de informatie; + +w) beheersmaatregelen voor overdragen van informatie om de informatie te beschermen tijdens fysiek transport of tijdens logische overdracht; + +x) beëindigingsclausules bij het afsluiten van de overeenkomst, met inbegrip van beheer van registraties, het retourneren van bedrijfsmiddelen, beveiligde verwijdering van informatie en andere gerelateerde bedrijfsmiddelen en eventuele doorlopende geheimhoudingsverplichtingen; + +y) het voorzien in een methode om de door de leverancier opgeslagen informatie van de organisatie op beveiligde wijze te vernietigen zodra die informatie niet meer nodig is; + +z) het bewerkstelligen van ondersteuning bij de overdracht aan een andere leverancier of aan de organisatie zelf bij het einde van de overeenkomst. + +De organisatie behoort een register van afspraken met externe partijen (bijv. contracten, een memorandum van overeenstemming, overeenkomsten voor het delen van informatie) op te stellen en te onderhouden om bij te houden waar haar informatie naartoe gaate organisatie behoort ook haar overeenkomsten met externe partijen regelmatig te beoordelen, te valideren en bij te werken om te garanderen dat ze nog steeds vereist zijn en geschikt zijn voor het doel en dat ze relevante clausules over informatiebeveiliging bevatten. + +**Overige informatie** + +De overeenkomsten kunnen voor de verschillende organisaties en de verschillende soorten leveranciers aanzienlijk variërenerhalve behoort erop te worden toegezien dat alle relevante eisen voor het oppakken van informatiebeveiligingsrisico's erin worden opgenomen. + +Voor gegevens over overeenkomsten met leveranciers, zie de ISO/IEC 27036-reeks. Voor gegevens over overeenkomsten voor clouddiensten, zie de ISO/IEC 19086-reeks. + diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.21_BT Beheren van informatiebeveiliging in de ICT-keten.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.21_BT Beheren van informatiebeveiliging in de ICT-keten.md new file mode 100644 index 0000000..fdecb94 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.21_BT Beheren van informatiebeveiliging in de ICT-keten.md @@ -0,0 +1,79 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- + + +| Attribuut | Waarde | +| :----------------------------------- | :----------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Identificeren | +| Operationele capaciteiten: | #Beveiliging_in_leveranciersrelaties | +| Beveiligingsdomeinen: | #Governance_en_Eco-systeem #Bescherming | + + + + +## 5.21 Beheren van informatiebeveiliging in de ICT-keten + + +**Beheersmaatregel** + +Er behoren processen en procedures te worden vastgesteld en geïmplementeerd om de informatiebeveiligingsrisico's in verband met de toeleveringsketen van ICT-producten en -diensten te beheren. + +**Doel** + +Een overeengekomen niveau van informatiebeveiliging in leveranciersrelaties in stand houden. + +**Richtlijn** + +In aanvulling op de algemene informatiebeveiligingseisen voor leveranciersrelaties behoren de volgende informatiebeveiligingsonderwerpen in aanmerking te worden genomen binnen de beveiliging van de ITC-toeleveringsketen: + +a) informatiebeveiligingseisen definiëren die van toepassing zijn op het verwerven van ICT-producten of -diensten; + +b) eisen dat leveranciers de beveiligingseisen van de organisatie in de gehele toeleveringsketen bekendmaken indien zij delen van de ICT-dienst die zij aan de organisatie leveren, uitbesteden; + +c) eisen dat de leveranciers van ICT-producten passende beveiligingspraktijken in de gehele toeleveringsketen bekendmaken indien deze producten componenten bevatten die worden ingekocht bij of verkregen van andere leveranciers of andere entiteiten (bijv. softwareontwikkelaars en leveranciers van hardwarecomponenten die op basis van onderaanneming werken); + +d) verzoeken dat de leveranciers van ICT-producten informatie verstrekken waarin de in producten gebruikte softwarecomponenten worden beschreven; + +e) verzoeken dat de leveranciers van ICT-producten informatie verstrekken waarin de geïmplementeerde beveiligingsfuncties van hun product en de voor het veilige gebruik ervan vereiste configuratie worden beschreven; + +f) een monitoringproces en aanvaardbare methoden voor het valideren dat de geleverde ICT-producten en -diensten voldoen aan de gestelde beveiligingseisen, implementeren. Voorbeelden van zulke methoden voor het beoordelen van leveranciers zijn penetratietests en bewijs of validatie van attesten van derden voor de informatiebeveiligingsactiviteiten van de leverancier; + +g) een proces implementeren voor het vaststellen en documenteren van componenten van producten of diensten die essentieel zijn voor het handhaven van de functionaliteit en daarom verhoogde aandacht, toezicht en verdere opvolging vereisen als deze buiten de organisatie worden gebouwd, in het bijzonder indien de leverancier delen van componenten van producten of diensten aan andere leveranciers uitbesteedt; + +h) zekerheid verkrijgen dat essentiële componenten en de herkomst ervan in de toeleveringsketen kunnen worden getraceerd; + +i) zekerheid verkrijgen dat de geleverde ICT-producten functioneren zoals voorzien zonder onverwachte of ongewenste verschijnselen; + +j) processen implementeren om te garanderen dat componenten van leveranciers echt zijn en ongewijzigd zijn ten opzichte van de specificatiesoorbeeldmaatregelen zijn labels tegen manipulatie, cryptografische hashverificaties of digitale handtekeningenonitoren op prestaties die niet aan de specificaties voldoen, kan een manier zijn om manipulatie of namaak aan te tonen. + +Er behoort preventie en detectie van manipulatie te worden geïmplementeerd tijdens verschillende fasen van de levenscyclus van systeemontwikkeling, met inbegrip van de ontwerp-, ontwikkel-, integratie-, operationele en onderhoudsfasen; + +k) waarborgen dat ICT-producten de vereiste beveiligingsniveaus halen, bijvoor middel van een formele certificerings- of beoordelingsregeling, zoals de Common Criteria Recognition Arrangement; + +l) regels definiëren voor het delen van informatie met betrekking tot de toeleveringsketen en potentiële kwesties en compromissen tussen de organisatie en leveranciers; + +m) specifieke processen implementeren voor het beheren van de levenscyclus en beschikbaarheid van ICT-componenten en gerelateerde beveiligingsrisico\'s. Dit omvat het beheren van de risico\'s dat onderdelen niet langer beschikbaar zijn omdat leveranciers hun bedrijf hebben gestaakt of deze onderdelen als gevolg van technologische ontwikkelingen niet meer aanbieden. Het identificeren van een alternatieve leverancier en het proces om software en competentie naar de alternatieve leverancier over te brengen behoren te worden overwogen. + +**Overige informatie** + +De specifieke risicobeheerpraktijken betreffende de ICT-toeleveringsketen komen boven op de algemene praktijken van informatiebeveiliging, kwaliteit, projectmanagement en systeemengineering, maar vervangen deze niet. + +Organisaties wordt geadviseerd om samen te werken met leveranciers voor een goed begrip van de ICT-toeleveringsketen en de aangelegenheden die een belangrijke uitwerking hebben op de producten en diensten die worden geleverde organisatie kan informatiebeveiligingspraktijken van de ICT- toeleveringsketen beïnvloeden door in overeenkomsten met leveranciers de aangelegenheden bekend te maken waaraan door andere leveranciers in de ICT-toeleveringsketen invulling behoort te worden gegeven. + +ICT behoort te worden verkregen van bronnen met een goede reputatiee betrouwbaarheid van software en hardware is een kwestie van kwaliteitscontroleoewel het voor een organisatie over het algemeen niet mogelijk is om de kwaliteitscontrolesystemen van haar leveranciers te inspecteren, kan zij wel een betrouwbaar oordeel vellen op basis van de reputatie van de leverancier. + +De ICT-toeleveringsketen zoals hier bedoeld omvat ook clouddienstenoorbeelden van ICT-toeleveringsketens zijn: + +a) 'cloud services provisioning', waar de aanbieder van de clouddienst afhankelijk is van de softwareontwikkelaars, aanbieders van telecommunicatiediensten, hardware-aanbieders; + +b) internet of things (IoT), waarbij de dienst ook de fabrikanten van apparatuur, de aanbieders van de clouddienst (bijve exploitanten van het IoT-platform), de ontwikkelaars voor mobiele en internettoepassingen en de leverancier van softwarebibliotheken betreft; + +c) hostingdiensten, waar de aanbieder op externe servicebalies vertrouwt, met inbegrip van eerste, tweede en derde niveaus van ondersteuning. + +Zie ISO/IEC 27036-3 voor nadere details met inbegrip van richtlijnen voor risicobeoordeling. + +Software-identificatietags (SWID) kunnen ook bijdragen aan betere informatiebeveiliging in de toeleveringsketen, door informatie te geven over de herkomst van software. Zie ISO/IEC 19770-2 voor nadere details. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.22_BT Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.22_BT Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten.md new file mode 100644 index 0000000..3873a91 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.22_BT Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten.md @@ -0,0 +1,74 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- + + +| Attribuut | Waarde | +| :----------------------------------- | :---------------------------------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Identificeren | +| Operationele capaciteiten: | #Beveiliging_in_leveranciersrelaties #Borging_van_informatiebeveiliging | +| Beveiligingsdomeinen: | #Governance_en_Eco-systeem #Bescherming #Verdediging | + + +**Beheersmaatregel** + +De organisatie behoort de informatiebeveiligingspraktijken en de leveranciersdiensten regelmatig te monitoren, beoordelen, evalueren en veranderingen daaraan te beheren. + +**Doel** + +Een overeengekomen niveau van informatiebeveiliging en dienstverlening in overeenstemming met de leveranciersovereenkomsten handhaven. + +**Richtlijn** + +Het monitoren en beoordelen van, en het beheren van veranderingen aan, leveranciersdiensten behoort te bewerkstelligen dat aan de informatiebeveiligingsvoorwaarden van de overeenkomsten wordt voldaan, informatiebeveiligingsincidenten en -problemen naar behoren worden beheerd en veranderingen in leveranciersdiensten of de bedrijfsstatus niet van invloed zijn op de dienstverlening. + +Hiertoe behoort een proces voor het beheer van de relatie tussen de organisatie en de leverancier te bestaan om: + +a) de prestatieniveaus van de dienstverlening te monitoren om de naleving van de overeenkomsten te verifiëren; + +b) door leveranciers aangebrachte veranderingen te monitoren, waaronder: + +1) verbeteringen van de huidige aangeboden dienstverlening; +2) ontwikkelingen van nieuwe toepassingen en systemen; +3) wijzigingen in of updates van beleid en procedures van de leverancier; +4) nieuwe of gewijzigde beheersmaatregelen om informatiebeveiligingsincidenten op te lossen en om de informatiebeveiliging te verbeteren; + +c) veranderingen in leveranciersdiensten te monitoren, waaronder: + +1) veranderingen en verbeteringen van netwerken; +2) gebruik van nieuwe technologieën; +3) aanvaarding van nieuwe producten of nieuwere versies of uitgaven; +4) nieuwe ontwikkelinstrumenten en omgevingen; +5) veranderingen in fysieke locatie van dienstverleningsfaciliteiten; +6) verandering van onderleveranciers; +7) uitbesteding aan een andere leverancier; + +d) de rapporten over de dienstverlening die zijn opgesteld door de leverancier, te beoordelen en regelmatig voortgangsbesprekingen te regelen voor zover door de overeenkomsten vereist; + +e) audits van leveranciers en onderleveranciers uit te voeren, in samenhang met de beoordeling van rapporten van onafhankelijke auditoren, indien beschikbaar, en vastgestelde kwesties op te volgen; + +f) informatie te verstrekken over informatiebeveiligingsincidenten en deze informatie te beoordelen voor zover vereist door de overeenkomsten en ondersteunende richtlijnen en procedures; + +g) audittrajecten van leveranciers en registraties van informatiebeveiligingsgebeurtenissen, operationele problemen, weigeringen, opsporing van storingen en onderbrekingen in verband met de geleverde dienst te beoordelen; + +h) te reageren op geïdentificeerde informatiebeveiligingsgebeurtenissen of -incidenten en deze te beheren; + +i) kwetsbaarheden in de informatiebeveiliging te identificeren en beheren; + +j) informatiebeveiligingsaspecten van de relaties van de leverancier met zijn eigen leveranciers te beoordelen; + +k) te bewerkstelligen dat de leverancier voldoende capaciteit voor de diensten onderhoudt samen met werkbare plannen die zijn ontworpen om te waarborgen dat de overeengekomen continuïteitsniveaus van de dienstverlening na grote storingen of calamiteiten in de dienstverlening worden onderhouden (zie 5, 5, 5, 5, 8); + +l) ervoor te zorgen dat leveranciers verantwoordelijkheden toewijzen voor het beoordelen van naleving en voor het dwingend uitvoeren van de eisen van de overeenkomsten; + +m)regelmatig te evalueren of de leveranciers afdoende informatiebeveiligingsniveaus in stand houden. + +De verantwoordelijkheid voor het beheer van leveranciersrelaties behoort te worden toegekend aan een daarvoor aangewezen persoon of teamm te monitoren dat de eisen van de overeenkomst, in het bijzonder de informatiebeveiligingseisen, worden nagekomen, behoren voldoende technische vaardigheden en middelen beschikbaar te worden gesteldls tekortkomingen in de dienstverlening worden waargenomen behoren passende maatregelen te worden getroffen. + + +**Overige informatie** + +Zie ISO/IEC 27036-3 voor nadere details. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.23_BT Informatiebeveiliging voor het gebruik van clouddiensten.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.23_BT Informatiebeveiliging voor het gebruik van clouddiensten.md new file mode 100644 index 0000000..c7faa4c --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.23_BT Informatiebeveiliging voor het gebruik van clouddiensten.md @@ -0,0 +1,84 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- + +**Beheersmaatregel** + +Processen voor het aanschaffen, gebruiken, beheren en beëindigen van clouddiensten behoren overeenkomstig de informatiebeveiligingseisen van de organisatie te worden opgesteld. + +**Doel** + +Informatiebeveiliging voor het gebruik van clouddiensten specificeren en beheren. + +**Richtlijn** + +De organisatie behoort een onderwerpspecifiek beleid inzake het gebruik van clouddiensten vast te stellen en aan alle relevante belanghebbenden mee te delen. + +De organisatie behoort te definiëren en te communiceren hoe zij voornemens is informatiebeveili- gingsrisico\'s in verband met het gebruik van clouddiensten te beheren. Dit kan een uitbreiding zijn of deel uitmaken van de bestaande aanpak voor de manier waarop een organisatie door externe partijen geleverde diensten beheert (zie 5 en 5). + +Het gebruik van clouddiensten kan gepaard gaan met een gedeelde verantwoordelijkheid voor informatiebeveiliging en samenwerking tussen de aanbieder van de clouddienst en de organisatie die als afnemer van de clouddienst optreedt. Het is essentieel dat de verantwoordelijkheden voor zowel de aanbieder als de organisatie, handelend als afnemer van de clouddienst, op de juiste wijze worden gedefinieerd en geïmplementeerd. + +De organisatie behoort het volgende te definiëren: + +a) alle relevante informatiebeveiligingseisen in verband met het gebruik van de clouddiensten; + +b) selectiecriteria voor clouddiensten en de reikwijdte van het gebruik van clouddiensten; + +c) rollen en verantwoordelijkheden met betrekking tot het gebruik en beheer van clouddiensten; + +d) welke beheersmaatregelen voor informatiebeveiliging door de aanbieder van de clouddienst en welke door de organisatie als afnemer van de clouddienst worden beheerd; + +e) hoe door de aanbieder van de clouddienst verstrekte informatiebeveiligingscapaciteiten kunnen worden verkregen en gebruikt; + +f) hoe zekerheid kan worden verkregen over de door aanbieders van clouddiensten geïmplementeerde beheersmaatregelen voor informatiebeveiliging; + +g) hoe beheersmaatregelen, interfaces en wijzigingen aan diensten behoren te worden beheerd wanneer een organisatie gebruikmaakt van meerdere clouddiensten, met name van verschillende aanbieders van clouddiensten; + +h) procedures voor het omgaan met informatiebeveiligingsincidenten die zich voordoen met betrekking tot het gebruik van clouddiensten; + +i) haar aanpak voor het monitoren, beoordelen en evalueren van het doorlopend gebruik van clouddiensten om informatiebeveiligingsrisico's te beheren; + +j) hoe het gebruik van clouddiensten met inbegrip van exitstrategieën voor clouddiensten kan worden gewijzigd of beëindigd. + +Overeenkomsten voor clouddiensten zijn vaak vooraf gedefinieerd zonder dat het mogelijk is erover te onderhandelen. Voor alle clouddiensten behoort de organisatie overeenkomsten voor clouddiensten met de aanbieder(s) van clouddiensten te beoordelen. Een overeenkomst voor clouddiensten behoort in te gaan op de eisen van de organisatie ten aanzien van vertrouwelijkheid, integriteit, beschikbaarheid en het omgaan met persoonsgegevens, met passende doelstellingen voor het niveau van dienstverlening van de clouddienst en kwalitatieve doelstellingen voor de clouddienst. De organisatie behoort ook relevante risicobeoordelingen uit te voeren om de risico\'s in verband met het gebruik van de clouddienst te identificeren. Eventuele overblijvende risico\'s in verband met het gebruik van de clouddienst behoren duidelijk te worden geïdentificeerd en aanvaard door het passende management van de organisatie. + +Een overeenkomst tussen de aanbieder van een clouddienst en de organisatie, in haar rol van afnemer van de clouddienst, behoort de volgende bepalingen te bevatten voor de bescherming van de gegevens van de organisatie en de beschikbaarheid van diensten: + +a) het leveren van oplossingen op basis van door de industrie aanvaarde normen voor architectuur en infrastructuur; + +b) het beheren van toegangsbeveiligingsmaatregelen van de clouddienst conform de eisen van de organisatie; + +c) het implementeren van oplossingen voor het monitoren van en beschermen tegen malware; + +d) het verwerken en op goedgekeurde locaties (bijven bepaald land of bepaalde regio) of binnen een bepaald rechtsgebied of krachtens een bepaalde rechtsbevoegdheid opslaan van gevoelige informatie van de organisatie; + +e) het bieden van gerichte steun indien er zich een informatiebeveiligingsincident voordoet in de cloudomgeving; + +f) het bewerkstelligen dat aan de informatiebeveiligingseisen van de organisatie wordt voldaan indien clouddiensten verder worden uitbesteed aan een externe leverancier (of verbieden dat clouddiensten worden uitbesteed); + +g) het ondersteunen van de organisatie bij het verzamelen van digitaal bewijsmateriaal, met inachtneming van wet- en regelgeving inzake digitaal bewijsmateriaal in verschillende rechtsgebieden; + +h) het voorzien in passende ondersteuning en beschikbaarheid van diensten gedurende een passend tijdsbestek wanneer de organisatie niet langer gebruik wil maken van de clouddienst; + +i) het voorzien in de vereiste back-ups van gegevens en configuratie-informatie en het veilig beheren van back-ups voor zover van toepassing, op basis van de capaciteiten van de leverancier van de clouddienst die wordt ingezet door de organisatie in haar rol als afnemer van de clouddienst; + +j) het verstrekken en retourneren van informatie zoals configuratiebestanden, broncode en gegevens die eigendom zijn van de organisatie in haar rol van afnemer van de clouddienst op verzoek of bij beëindiging van de dienst. + +In haar rol van afnemer van de clouddienst behoort de organisatie te overwegen of de overeenkomst behoort te vereisen dat de aanbieders van clouddiensten vooraf kennis geven van wezenlijke wijzigingen aan hoe de dienst aan de organisatie wordt geleverd die gevolgen hebben voor de afnemer, waaronder: + +a) wijzigingen aan de technische infrastructuur (bijverhuizing, herconfiguratie of wijzigingen in hardware of software) die van invloed zijn op, of tot veranderingen leiden in, de aangeboden clouddienst; + +b) het verwerken of opslaan van informatie in een nieuw geografisch of juridisch rechtsgebied; + +c) het gebruik van collega-aanbieders van clouddiensten of andere onderaannemers (met inbegrip van het wijzigen van bestaande of het gebruik van nieuwe partijen). + + +De organisatie die clouddiensten gebruikt, behoort nauw contact te onderhouden met haar aanbieders van de clouddiensteneze contacten maken wederzijdse uitwisseling mogelijk van informatie over informatiebeveiliging voor het gebruik van de clouddiensten, met inbegrip van een mechanisme voor zowel de aanbieder als de organisatie, in haar rol van afnemer van de clouddiensten, om elk kenmerk van de diensten te monitoren en tekortkomingen ten opzichte van de in de overeenkomsten opgenomen verbintenissen te melden. + +**Overige informatie** + +Deze beheersmaatregel bekijkt cloudbeveiliging vanuit het oogpunt van de afnemer van de clouddienst(en). + +Aanvullende informatie met betrekking tot clouddiensten is te vinden in ISO/IEC 17788, ISO/IEC 17789 en ISO/IEC 22123-1. Specifieke informatie met betrekking tot clouds en overdraagbaarheid bij exitstrategieën is te vinden in ISO/IEC 19941. Specifieke informatie met betrekking tot informatiebeveiliging en publieke clouddiensten wordt beschreven in ISO/IEC 27017. Specifieke informatie met betrekking tot de bescherming van persoonsgegevens in publieke clouds die als verwerker van persoonsgegevens fungeren, wordt beschreven in ISO/IEC 27018. Leveranciers- relaties voor clouddiensten worden behandeld in ISO/IEC 27036-4 en clouddienstovereenkomsten en de inhoud ervan worden behandeld in de ISO/IEC 19086-reeks, waarbij ISO/IEC 19086-4 specifiek ingaat op beveiliging en privacy. + diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.2_BT Rollen en verantwoordelijkheden bij informatiebeveiliging.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.2_BT Rollen en verantwoordelijkheden bij informatiebeveiliging.md new file mode 100644 index 0000000..f0d91b2 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.2_BT Rollen en verantwoordelijkheden bij informatiebeveiliging.md @@ -0,0 +1,45 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.2 Rollen en verantwoordelijkheden bij informatiebeveiliging + +| Attribuut | Waarde | +| :----------------------------------- | :------------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Identificeren | +| Operationele capaciteiten: | #Governance | +| Beveiligingsdomeinen: | #Governance_en_Ecosysteem #Bescherming #Veerkracht | + +**Beheersmaatregel** + +Rollen en verantwoordelijkheden bij informatiebeveiliging behoren te worden gedefinieerd en toegewezen overeenkomstig de behoeften van de organisatie. + +**Doel** + +Een gedefinieerde, goedgekeurde en duidelijk te begrijpen structuur voor de implementatie, uitvoering en het beheer van informatiebeveiliging binnen de organisatie inrichten. + +**Richtlijn** + +Het toewijzen van de rollen en verantwoordelijkheden die bij informatiebeveiliging horen, behoort te worden gedaan in overeenstemming met het beleid voor informatiebeveiliging en onderwerpspecifieke beleidsregels (zie 5.1). De organisatie behoort verantwoordelijkheden te definiëren en te beheren voor: + +a) de bescherming van informatie en andere gerelateerde bedrijfsmiddelen; + +b) het uitvoeren van specifieke informatiebeveiligingsprocessen; + +c) beheeractiviteiten met betrekking tot informatiebeveiligingsrisico's en in het bijzonder voor het accepteren van de overblijvende risico's (bijv. voor de eigenaren van risico\'s); + +d) al het personeel dat gebruikmaakt van informatie en andere gerelateerde bedrijfsmiddelen van een organisatie. + +Deze verantwoordelijkheden behoren waar nodig te worden aangevuld met meer gedetailleerde richtlijnen voor specifieke locaties en informatieverwerkende faciliteitenersonen aan wie verantwoordelijkheden inzake informatiebeveiliging zijn toegekend, kunnen beveiligingstaken aan anderen toewijzenij blijven echter verantwoordelijk en behoren vast te stellen of gedelegeerde taken correct zijn verricht. + +Elk beveiligingsgebied waarvoor personen verantwoordelijk zijn, behoort te worden gedefinieerd, gedocumenteerd en gecommuniceerdutorisatieniveaus behoren te worden gedefinieerd en gedocumenteerdersonen die een specifieke rol op het gebied van informatiebeveiliging op zich nemen, behoren competent te zijn wat betreft de kennis en vaardigheden die de rol vereist en behoren te worden ondersteund bij het op de hoogte blijven van de ontwikkelingen die verband houden met de rol en die vereist zijn om aan de verantwoordelijkheden van de rol te kunnen voldoen. + +**Overige informatie** + +Veel organisaties benoemen een manager informatiebeveiliging die de algehele verantwoordelijkheid draagt voor de ontwikkeling en implementatie van informatiebeveiliging en om de identificatie van risico\'s en beperkende beheersmaatregelen te ondersteunen. + +Echter, de verantwoordelijkheid voor het verzorgen en implementeren van de beheersmaatregelen blijft vaak een taak van individuele managersen gangbare praktijk is om voor elk bedrijfsmiddel een eigenaar te benoemen die verantwoordelijk wordt voor de dagelijkse bescherming ervan. + +Afhankelijk van de omvang en de middelen van een organisatie kan informatiebeveiliging door speciale rollen of door functies die naast bestaande rollen worden uitgevoerd, worden afgedekt. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.30_BT ICT-gereedheid voor bedrijfscontinuïteit.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.30_BT ICT-gereedheid voor bedrijfscontinuïteit.md new file mode 100644 index 0000000..d1596bd --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.30_BT ICT-gereedheid voor bedrijfscontinuïteit.md @@ -0,0 +1,66 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- + + +| Attribuut | Waarde | +| :----------------------------------- | :--------------- | +| Type beheersmaatregel: | #Corrigerend | +| Informatiebeveiligingseigenschappen: | #Beschikbaarheid | +| Cybersecurityconcepten: | #Reageren | +| Operationele capaciteiten: | #Continuïteit | +| Beveiligingsdomeinen: | #Veerkracht | + + +**Beheersmaatregel** + +De ICT-gereedheid behoort te worden gepland, geïmplementeerd, onderhouden en getest op basis van bedrijfscontinuïteitsdoelstellingen en ICT-continuïteitseisen. + +**Doel** + +De beschikbaarheid van de informatie en andere gerelateerde bedrijfsmiddelen van de organisatie tijdens een verstoring waarborgen. + +**Richtlijn** + +De ICT-gereedheid voor bedrijfscontinuïteit is een belangrijk onderdeel van bedrijfscontinuïteitsbeheer en informatiebeveiligingsbeheer om te bewerkstelligen dat ook tijdens een verstoring aan de doelstellingen van de organisatie kan blijven worden voldaan. + +De ICT-continuïteitseisen zijn het resultaat van de bedrijfsimpactanalyse (BIA). Het BIA-proces behoort gebruik te maken van impactsoorten en -criteria om de impact in de tijd als gevolg van de verstoring van bedrijfsactiviteiten die producten en diensten leveren te beoordelen. De omvang en de duur van de daaruit voortvloeiende gevolgen behoren te worden gebruikt om geprioriteerde activiteiten waaraan een hersteltijddoelstelling (RTO) behoort te worden toegekend te identificeren. De BIA behoort vervolgens vast te stellen welke middelen nodig zijn om geprioriteerde activiteiten te ondersteunenr behoort ook een RTO te worden gespecificeerd voor deze middelenen deel van deze middelen behoort ICT-diensten te omvatten. + +De BIA waarbij ICT-diensten worden betrokken, kan worden uitgebreid om de prestatie- en capaciteitseisen van ICT-systemen en de RPO's van informatie die nodig is om activiteiten te ondersteunen tijdens een verstoring, te definiëren. + +Op basis van de output van de BIA en risicobeoordeling waarbij ICT-diensten worden betrokken, behoort de organisatie strategieën voor ICT-continuïteit te identificeren en selecteren waarin opties voor voorafgaand aan, tijdens en na een verstoring in overweging worden genomen. De strategieën voor bedrijfscontinuïteit kunnen uit een of meer oplossingen bestaan. Op basis van de strategieën behoren plannen te worden opgesteld, geïmplementeerd en getest om na een (ver)storing van essentiële processen het vereiste beschikbaarheidsniveau van ICT-diensten binnen de vereiste tijdsbestekken te halen. + +De organisatie behoort ervoor te zorgen dat: + +a) er een adequate organisatiestructuur is die is voorbereid op een verstoring, deze verzacht en erop reageert, ondersteund door personeel met de nodige verantwoordelijkheid, autoriteit en competentie; + +b) ICT-continuïteitsplannen, met inbegrip van respons- en herstelprocedures waarin wordt beschreven hoe de organisatie gepland heeft een verstoring van de ICT-diensten te beheren: + +1) regelmatig door middel van oefeningen en tests worden geëvalueerd; + +2) door het management worden goedgekeurd; + +c) ICT-continuïteitsplannen de volgende ICT-continuïteitsinformatie omvatten: + +1) prestatie- en capaciteitsspecificaties om te voldoen aan de bedrijfscontinuïteitseisen en -doelstellingen zoals gespecificeerd in de BIA; + +2) de RTO van elke geprioriteerde ICT-dienst en de procedures voor het herstel van die componenten; + +3) de RPO van de als informatie gedefinieerde geprioriteerde ICT-middelen en de procedures om de informatie te herstellen. + +**Overige informatie** + +Het beheer van de ICT-continuïteit vormt een essentieel onderdeel van de bedrijfscontinuïteitseisen met betrekking tot beschikbaarheid om in staat te zijn: + +a) te reageren op en te herstellen van verstoringen van ICT-diensten ongeacht de oorzaak; + +b) te bewerkstelligen dat de continuïteit van geprioriteerde activiteiten door de vereiste ICT-diensten wordt ondersteund; + +c) te reageren voordat er zich een verstoring van de ICT-diensten voordoet en zodra er ten minste één incident is waargenomen dat kan leiden tot een verstoring van de ICT-diensten. + +Verdere richtlijnen over de ICT-gereedheid voor bedrijfscontinuïteit zijn te vinden in ISO/IEC 27031. + +Verdere richtlijnen over een systeem voor bedrijfscontinuïteitsbeheer zijn te vinden in ISO 22301 en ISO 22313. + +Verdere richtlijnen over BIA zijn te vinden in ISO/TS 22317. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.3_BT Functiescheiding.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.3_BT Functiescheiding.md new file mode 100644 index 0000000..591c33b --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.3_BT Functiescheiding.md @@ -0,0 +1,50 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.3 Functiescheiding + +| Attribuut | Waarde | +| :----------------------------------- | :------------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Beschermen | +| Operationele capaciteiten: | #Governance #Identiteits-_en_toegangsbeheer | +| Beveiligingsdomeinen: | #Governance_en_Ecosysteem | + + +**Beheersmaatregel** + +Conflicterende taken en conflicterende verantwoordelijkheden behoren te worden gescheiden. + +**Doel** + +Het risico op fraude, fouten en het omzeilen van beheersmaatregelen voor informatiebeveiliging verminderen. + +**Richtlijn** + +De functiescheiding en verantwoordelijkheidszones hebben tot doel conflicterende functies te scheiden en onder verschillende personen te verdelen om te voorkomen dat mogelijk conflicterende functies door één persoon alleen worden uitgevoerd. + +De organisatie behoort vast te stellen voor welke functies en verantwoordelijkheidszones het nodig is dat ze worden gesegmenteerdieronder volgen voorbeelden van activiteiten waarvoor segmentatie nodig kan zijn: + +a) het initiëren, goedkeuren en uitvoeren van een verandering; + +b) het verzoeken om, goedkeuren en implementeren van toegangsrechten; + +c) het ontwerpen, implementeren en beoordelen van code; + +d) het ontwikkelen van software en het beheren van productiesystemen; + +e) het gebruiken en beheren van toepassingen; + +f) het gebruiken van toepassingen en het beheren van databases; + +g) het ontwerpen, auditen en borgen van beheersmaatregelen voor informatiebeveiliging. + +Bij het ontwerpen van beheersmaatregelen met het oog op scheiding behoort rekening te worden gehouden met de mogelijkheid van samenzweringoor kleine organisaties kan het moeilijk zijn om functies te scheiden, maar het principe behoort te worden toegepast voor zover dit mogelijk en haalbaar isanneer het moeilijk is om functies te scheiden, behoren andere beheersmaatregelen te worden overwogen, zoals het monitoren van activiteiten, audittrajecten en supervisie door het management. + +Bij het gebruik van op functies gebaseerde toegangsbeveiligingssystemen behoort ervoor te worden gezorgd dat aan personen geen conflicterende functies worden toegekendanneer er een groot aantal functies is, behoort de organisatie te overwegen geautomatiseerde hulpmiddelen te gebruiken om conflicten te identificeren en de verwijdering ervan mogelijk te makenuncties behoren zorgvuldig te worden gedefinieerd en ingesteld zodat toegangsproblemen tot een minimum kunnen worden beperkt indien een functie wordt verwijderd of opnieuw wordt toegewezen. + +**Overige informatie** + +Geen overige informatie. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.4_BT Managementverantwoordelijkheden.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.4_BT Managementverantwoordelijkheden.md new file mode 100644 index 0000000..4d09750 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.4_BT Managementverantwoordelijkheden.md @@ -0,0 +1,50 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.4 Managementverantwoordelijkheden + + +| Attribuut | Waarde | +| :----------------------------------- | :------------------------------------------------ | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Identificeren | +| Operationele capaciteiten: | #Governance | +| Beveiligingsdomeinen: | #Governance_en_Ecosysteem | + +**Beheersmaatregel** + +Het management behoort van al het personeel te eisen dat ze informatiebeveiliging toepassen overeenkomstig het vastgestelde informatiebeveiligingsbeleid, de onderwerpspecifieke beleidsregels en procedures van de organisatie. + +**Doel** + +Bewerkstelligen dat het management zijn rol bij informatiebeveiliging begrijpt en maatregelen neemt om ervoor te zorgen dat al het personeel zich bewust is van zijn verantwoordelijkheden op het gebied van informatiebeveiliging en deze ook nakomt. + +**Richtlijn** + +Het management behoort er blijk van te geven dat het het informatiebeveiligingsbeleid, onderwerpspecifieke beleidsregels, procedures en beheersmaatregelen voor informatiebeveiliging ondersteunt. + +Het management behoort ervoor te zorgen dat personeelsleden: + +a) op de juiste manier worden geïnstrueerd over hun informatiebeveiligingsrollen en -verantwoordelijkheden voordat zij toegang krijgen tot informatie en andere gerelateerde bedrijfsmiddelen van de organisatie; + +b) richtlijnen ontvangen die de verwachtingen met betrekking tot hun informatiebeveiligingsrol binnen de organisatie aangeven; + +c) verplicht worden te voldoen aan het informatiebeveiligingsbeleid en de onderwerpspecifieke beleidsregels van de organisatie; + +d) een niveau van bewustwording van informatiebeveiliging bereiken dat relevant is voor hun rollen en verantwoordelijkheden binnen de organisatie (zie 6.3); + +e) de arbeids- of contractvoorwaarden en de voorwaarden van overeenkomsten, met inbegrip van het informatiebeveiligingsbeleid en passende werkmethoden, naleven [\*)]; + +f) de passende vaardigheden en kwalificaties op het gebied van informatiebeveiliging blijven houden door voortdurende bijscholing; + +g) waar mogelijk, een vertrouwelijk kanaal krijgen om overtredingen van het informatiebeveiligings- beleid, onderwerpspecifiek beleid of procedures voor informatiebeveiliging te melden ('klokkenluiden')it kan anonieme meldingen mogelijk maken, of bepalingen bevatten die ervoor zorgen dat de identiteit van de melder alleen bekend is bij degenen die dergelijke meldingen moeten behandelen; + +h) voldoende middelen en tijd voor projectplanning krijgen voor het implementeren van de beveiligingsgerelateerde processen en beheersmaatregelen van de organisatie. + +**Overige informatie** + +Geen overige informatie. + +\*) Nederlandse voetnoot: Anders geformuleerd dan in de brontekst, diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.5_BT Contact met overheidsinstanties.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.5_BT Contact met overheidsinstanties.md new file mode 100644 index 0000000..c097114 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.5_BT Contact met overheidsinstanties.md @@ -0,0 +1,37 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.5 Contact met overheidsinstanties + +| Attribuut | Waarde | +| :----------------------------------- | :------------------------------------------------- | +| Type beheersmaatregel: | #Preventief #Corrigerend | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Identificeren #Beschermen #Reageren #Herstellen | +| Operationele capaciteiten: | #Governance | +| Beveiligingsdomeinen: | #Verdediging #Veerkracht | + +**Beheersmaatregel** + +De organisatie behoort contact met de relevante instanties te leggen en te onderhouden. + +**Doel** + +Een passende stroom van informatie met betrekking tot informatiebeveiliging tussen de organisatie en relevante juridische, regelgevende en toezichthoudende instanties bewerkstelligen. + + +**27** + + +**Richtlijn** + +De organisatie behoort aan te geven wanneer en door wie contact behoort te worden opgenomen met overheidsinstanties (bijvolitie, regelgevende organen, toezichthouders) en hoe geïdentificeerde informatiebeveiligingsincidenten tijdig behoren te worden gemeld. + +Contacten met overheidsinstanties behoren ook te worden gebruikt om inzicht mogelijk te maken in de bestaande en toekomstige verwachtingen van deze instanties (bijvoepasselijke regelgeving met betrekking tot informatiebeveiliging). + +**Overige informatie** + +Organisaties die worden aangevallen, kunnen instanties verzoeken om actie te ondernemen tegen de aanvaller. + +Het onderhouden van dergelijke contacten kan een eis zijn voor het ondersteunen van het beheer van informatiebeveiligingsincidenten (zie 5.24 t/m 5.28) of de noodplan- en bedrijfscontinuïteitsprocessen (zie 5.29 en 5.30). Contacten met regelgevende organen zijn ook nuttig om te anticiperen op en voorbereidingen te treffen voor komende veranderingen in relevante wet- en regelgeving die op de organisatie van invloed zijn. Contacten met andere instanties omvatten contacten met nutsbedrijven, eerstehulpdiensten, elektriciteitsleveranciers en gezondheids- en veiligheidsinstanties [bijv. de brandweer (in verband met de bedrijfscontinuïteit), telecommunicatiebedrijven (in verband met verbindingen en beschikbaarheid) en waterleidingbedrijven (in verband met koelvoorzieningen voor apparatuur)]. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.6_BT Contact met speciale belangengroepen.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.6_BT Contact met speciale belangengroepen.md new file mode 100644 index 0000000..6e096d8 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.6_BT Contact met speciale belangengroepen.md @@ -0,0 +1,40 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.6 Contact met speciale belangengroepen + +| Attribuut | Waarde | +| :----------------------------------- | :------------------------------------------------- | +| Type beheersmaatregel: | #Preventief #Corrigerend | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Beschermen #Reageren #Herstellen | +| Operationele capaciteiten: | #Governance | +| Beveiligingsdomeinen: | #Verdediging | + +**Beheersmaatregel** + +De organisatie behoort contacten met speciale belangengroepen of andere gespecialiseerde beveiligingsfora en beroepsverenigingen te leggen en te onderhouden. + +**Doel** + +Een passende stroom van informatie met betrekking tot informatiebeveiliging bewerkstelligen. + +**Richtlijn** + +Lidmaatschap van speciale belangengroepen of fora behoort te worden overwogen als middel om: + +a) kennis te verbeteren over 'best practices' en op de hoogte te blijven van relevante beveiligingsinformatie; + +b) ervoor te zorgen dat de kennis van informatiebeveiliging actueel is; + +c) vroegtijdige waarschuwingen te ontvangen inzake alarm, adviezen en patches die verband houden met aanvallen en kwetsbaarheden; + +d) toegang te krijgen tot gespecialiseerd advies over informatiebeveiliging; + +e) informatie over nieuwe technologieën, producten, diensten, dreigingen of kwetsbaarheden te delen en uit te wisselen; + +f) geschikte contactpunten te verkrijgen als er informatiebeveiligingsincidenten aan de orde zijn (zie 5.24 t/m 5.28). + +**Overige informatie** +Geen overige informatie. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.7_BT Informatie en analyses over dreigingen.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.7_BT Informatie en analyses over dreigingen.md new file mode 100644 index 0000000..b2f2116 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.7_BT Informatie en analyses over dreigingen.md @@ -0,0 +1,79 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.7 Informatie en analyses over dreigingen + +| Attribuut | Waarde | +| :----------------------------------- | :------------------------------------------------- | +| Type beheersmaatregel: | #Preventief #Detectief #Corrigerend | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Identificeren #Detecteren #Reageren | +| Operationele capaciteiten: | #Beheer_van_dreigingen_en_kwetsbaarheden | +| Beveiligingsdomeinen: | #Veerkracht | + +**Beheersmaatregel** + +Informatie met betrekking tot informatiebeveiligingsdreigingen behoort te worden verzameld en geanalyseerd om informatie en analyses over dreigingen te produceren. + +**Doel** + +Bewustwording bieden van de mogelijke dreigingen voor de organisatie zodat de passende mitigerende maatregelen kunnen worden getroffen. + +**Richtlijn** + +Informatie over bestaande of opkomende dreigingen wordt verzameld en geanalyseerd teneinde: + +a) weloverwogen maatregelen mogelijk te maken om te voorkomen dat de dreigingen schade aan de organisatie toebrengen; + +b) de impact van dergelijke dreigingen te beperken. + +Informatie en analyses over dreigingen kunnen in drie lagen worden opgedeeld die alle drie in aanmerking behoren te worden genomen: + +a) informatie over strategische dreigingen: uitwisseling van informatie op hoofdlijnen over het veranderende dreigingslandschap (bijvoorten aanvallers of soorten aanvallen); + +b) informatie en analyses over tactische dreigingen: informatie over de desbetreffende methodieken, instrumenten en technologieën waarvan aanvallers zich bedienen; + +c) informatie en analyses over operationele dreigingen: details over specifieke aanvallen, met inbegrip van technische indicatoren. + +Informatie en analyses over dreigingen behoren: + +a) relevant te zijn (dzerband te houden met de bescherming van de organisatie); + +b) inzicht te bieden (dze organisatie een nauwkeurig en gedetailleerd inzicht te verschaffen in het dreigingslandschap); + +c) contextueel te zijn om situationeel bewustwording te bieden (dzoor context toe te voegen aan de informatie op basis van het tijdstip van de gebeurtenissen, waar zij zich voordoen, eerdere ervaringen en prevalentie in soortgelijke organisaties); + +d) bruikbaar te zijn (dzat de organisatie snel en doeltreffend kan handelen op basis van de informatie). + +Activiteiten op het gebied van informatie en analyses over dreigingen behoren het volgende te omvatten: + +a) het vaststellen van doelstellingen voor het produceren van informatie en analyses over dreigingen; + +b) het identificeren, doorlichten en selecteren van interne en externe informatiebronnen die nodig en geschikt zijn om te voorzien in informatie die vereist is om de gewenste informatie en analyses over dreigingen te produceren; + +c) het verzamelen van informatie uit geselecteerde interne en externe bronnen; + +d) het verwerken van verzamelde informatie om deze voor te bereiden op analyse (bijv. door informatie te vertalen, op te maken of te bevestigen); + +e) het analyseren van informatie om inzicht te krijgen in hoe deze verband houdt met de organisatie en de betekenis ervan voor de organisatie; + +f) het in een begrijpelijke vorm meedelen ervan aan en delen met relevante personen. + +Informatie over dreigingen behoort te worden geanalyseerd en later te worden gebruikt: + +a) door processen te implementeren om uit bronnen van informatie en analyses over dreigingen verzamelde informatie op te nemen in de beheerprocessen voor informatiebeveiligingsrisico's van de organisatie; + +b) als aanvullende input voor technische preventieve en detectieve beheersmaatregelen, zoals firewalls, inbraakdetectiesystemen of antimalwareoplossingen; + +c) als input voor de processen en technieken voor het testen van de informatiebeveiliging. + +De organisatie behoort informatie en analyses over dreigingen op wederzijdse basis met andere organisaties te delen om de algemene informatie en analyses over dreigingen te verbeteren. + +**Overige informatie** + +Organisaties kunnen informatie en analyses over dreigingen gebruiken om dreigingen te voorkomen, detecteren of erop te reagerenrganisaties kunnen zelf informatie en analyses over dreigingen produceren, maar het is gebruikelijker dat ze informatie en analyses over dreigingen ontvangen en gebruiken die door andere bronnen wordt geproduceerd. + +Informatie en analyses over dreigingen worden vaak verstrekt door onafhankelijke aanbieders of adviseurs, overheidsinstanties of groepen die gezamenlijk informatie over dreigingen verzamelen en analyseren. + +De doeltreffendheid van beheersmaatregelen zoals 5.25, 8.7, 8.16 of 8.23 is afhankelijk van de kwaliteit van de beschikbare informatie en analyses over dreigingen. \ No newline at end of file diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.8_BT Informatiebeveiliging in projectmanagement.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.8_BT Informatiebeveiliging in projectmanagement.md new file mode 100644 index 0000000..84b5a26 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.8_BT Informatiebeveiliging in projectmanagement.md @@ -0,0 +1,69 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.8 Informatiebeveiliging in projectmanagement + +| Attribuut | Waarde | +| :----------------------------------- | :------------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Identificeren #Beschermen | +| Operationele capaciteiten: | #Governance | +| Beveiligingsdomeinen: | #Governance_en_Ecosysteem #Bescherming | + +**Beheersmaatregel** + +Informatiebeveiliging behoort te worden geïntegreerd in projectmanagement. + +**Doel** + +Ervoor zorgen dat informatiebeveiligingsrisico's binnen projecten en te leveren producten en diensten gedurende de gehele levenscyclus van het project op doeltreffende wijze binnen het projectmanagement worden aangepakt. + +**Richtlijn** + +Informatiebeveiliging behoort te worden geïntegreerd in projectmanagement om ervoor te zorgen dat informatiebeveiligingsrisico\'s in het kader van projectmanagement worden aangepaktit kan worden toegepast op elk type project ongeacht de complexiteit, omvang, duur, discipline of het toepassingsgebied (bijv. een project voor een proces voor kernactiviteiten, IT, 'facility management' of andere ondersteunende processen). + +Het projectmanagement dat wordt toegepast, behoort te vereisen dat: + +a) informatiebeveiligingsrisico's tijdens een vroeg stadium en periodiek gedurende de volledige + +levenscyclus van het project als onderdeel van de projectrisico\'s worden beoordeeld en behandeld; + +b) informatiebeveiligingseisen \[bijv. beveiligingseisen voor toepassingen (8.26), eisen inzake de naleving van intellectuele-eigendomsrechten (5.32) enz.\] in de vroege stadia van projecten worden aangepakt; + +c) informatiebeveiligingsrisico's in verband met de uitvoering van projecten, zoals de beveiliging van interne en externe communicatieaspecten, gedurende de gehele levenscyclus van het project in aanmerking worden genomen en behandeld; + +d) de vorderingen met betrekking tot de behandeling van informatiebeveiligingsrisico's worden beoordeeld en de doeltreffendheid van de behandeling wordt beoordeeld en beproefd. + +De passendheid van de informatiebeveiligingsoverwegingen en -activiteiten behoort in vooraf bepaalde stadia te worden gecontroleerd door geschikte personen of governance-instanties, zoals de projectstuurgroep. + +Verantwoordelijkheden en bevoegdheden voor informatiebeveiliging relevant voor het project behoren te worden gedefinieerd en te worden toegewezen aan gespecificeerde rollen. + +Informatiebeveiligingseisen voor door het project te leveren producten of diensten behoren te worden vastgesteld met gebruikmaking van verschillende methoden zoals het afleiden van nalevingseisen uit informatiebeveiligingsbeleid, onderwerpspecifieke beleidsregels en regelgevingerdere informatiebeveiligingseisen kunnen worden ontleend aan activiteiten zoals dreigingsmodellering, beoordelingen van incidenten, het gebruik van kwetsbaarheidsdrempels of het opstellen van noodplannen om zo te bewerkstelligen dat de architectuur en het ontwerp van informatiesystemen worden beschermd tegen bekende dreigingen die gebaseerd zijn op de operationele omgeving. + +Er behoren informatiebeveiligingseisen te worden vastgesteld voor alle soorten projecten, niet alleen voor ICT-ontwikkelprojectenij het vaststellen van deze eisen behoort ook het volgende in aanmerking te worden genomen: + +a) welke informatie het betreft (vaststelling van de informatie), wat de bijbehorende informatiebeveiligingsbehoeften zijn (classificatie; zie 5.12) en de mogelijke negatieve bedrijfsimpact die het gevolg kan zijn van ontoereikende beveiliging; + +b) de noodzaak om de desbetreffende informatie en andere gerelateerde bedrijfsmiddelen te beschermen, met name wat betreft vertrouwelijkheid, integriteit en beschikbaarheid; + +c) de vereiste mate van betrouwbaarheid of zekerheid ten opzichte van de beweerde identiteit van entiteiten om de authenticatie-eisen af te leiden; + +d) processen voor het verlenen van toegang en autorisatie, voor klanten en andere zakelijke gebruikers en voor bevoorrechte of technische gebruikers, zoals relevante projectleden, mogelijk operationeel personeel of externe leveranciers; + +e) het informeren van gebruikers over hun plichten en verantwoordelijkheden; + +f) eisen die zijn afgeleid van bedrijfsprocessen, zoals registreren en monitoren van transacties, eisen voor onweerlegbaarheid; + +g) eisen die verplicht zijn gesteld door andere beheersmaatregelen met betrekking tot informatiebeveiliging (bijv. interfaces voor het registreren en monitoren of systemen voor het detecteren van lekken van gegevens); + +h) naleving van de wettelijke, statutaire, regelgevende en contractuele omgeving waarin de organisatie actief is; + +i) het vereiste niveau van vertrouwen of zekerheid dat derden zullen voldoen aan het informatiebeveiligingsbeleid en de onderwerpspecifieke beleidsregels van de organisatie, met inbegrip van relevante beveiligingsclausules in overeenkomsten of contracten. + +**Overige informatie** + +De projectontwikkelaanpak, zoals de Waterfall-levenscyclus of de Agile-levenscyclus, behoort gestructureerde informatiebeveiliging te ondersteunen die kan worden aangepast aan de volgens een beoordeling vastgestelde informatiebeveiligingsrisico's, aansluitend bij het karakter van het projectet vroegtijdig nadenken over informatiebeveiligingseisen voor het product of de dienst (bijvijdens de plannings- en ontwerpfasen) kan leiden tot doeltreffender en kostenefficiëntere oplossingen voor kwaliteits- en informatiebeveiliging. ISO 21500 en ISO 21502 geven richtlijnen voor projectmanagementconcepten en -processen die belangrijk zijn voor de prestaties van projecten. + +ISO/IEC 27005 geeft richtlijnen voor het gebruik van risicobeheerprocessen om beheersmaatregelen te identificeren die aan informatiebeveiligingseisen voldoen. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.9_BT Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.9_BT Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen.md new file mode 100644 index 0000000..c1d2715 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_5.9_BT Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen.md @@ -0,0 +1,79 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 5.9 Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen + + +| Attribuut | Waarde | +| :----------------------------------- | :----------------------------------------------- | +| Type beheersmaatregel: | #Preventief | +| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | +| Cybersecurityconcepten: | #Identificeren | +| Operationele capaciteiten: | #Beheer_van_bedrijfsmiddelen | +| Beveiligingsdomeinen: | #Governance_en_Ecosysteem #Bescherming | + + +**Beheersmaatregel** + +Er behoort een inventarislijst van informatie en andere gerelateerde bedrijfsmiddelen, met inbegrip van de eigenaren, te worden opgesteld en onderhouden. + +**Doel** + +De informatie en andere gerelateerde bedrijfsmiddelen van de organisatie identificeren om de informatiebeveiliging ervan te behouden en passend eigenaarschap toe te wijzen. + +**Richtlijn** + +[Inventarislijst] + +De organisatie behoort haar informatie en andere gerelateerde bedrijfsmiddelen te identificeren en het belang ervan wat betreft informatiebeveiliging vast te stellenocumentatie behoort te worden onderhouden in speciale of bestaande inventarislijsten indien van toepassing. + +De inventarislijst van informatie en andere gerelateerde bedrijfsmiddelen behoort nauwkeurig, actueel, consistent en in overeenstemming met andere inventarisoverzichten te zijnpties om de nauwkeurigheid van een inventarislijst van informatie en andere gerelateerde bedrijfsmiddelen te bewerkstelligen zijn onder andere: + +a) regelmatig beoordelingen van geïdentificeerde informatie en andere gerelateerde bedrijfsmiddelen aan de hand van de inventarislijst van bedrijfsmiddelen uitvoeren; + +b) de inventarislijst automatisch laten bijwerken als er een bedrijfsmiddel wordt geïnstalleerd, gewijzigd of verwijderd. + +De locatie van een bedrijfsmiddel behoort al naargelang de situatie in de inventarislijst te worden opgenomen. + +De inventarislijst hoeft niet één lijst te zijn van informatie en andere gerelateerde bedrijfsmiddelenangezien de inventarislijst van bedrijfsmiddelen door de relevante functies behoort te worden onderhouden, kan deze worden beschouwd als een verzameling dynamische inventarislijsten, zoals inventarislijsten voor informatiebedrijfsmiddelen, hardware, software, virtuele machines (VM\'s), faciliteiten, personeel, competenties, capaciteiten en registraties. + +Elk bedrijfsmiddel behoort te worden geclassificeerd overeenkomstig de classificatie van de met dat bedrijfsmiddel gerelateerde informatie (zie 5.12). + +Het niveau van granulariteit van de inventarislijst van informatie en andere gerelateerde bedrijfsmiddelen behoort te passen bij de behoeften van de organisatieoms is het vanwege de aard van het bedrijfsmiddel niet praktisch uitvoerbaar om specifieke instanties van bedrijfsmiddelen in de informatielevenscyclus te documenterenen voorbeeld van een bedrijfsmiddel met een korte levensduur is een instantie van een VM die van korte duur kan zijn. + +[Eigendom] + +Voor de geïdentificeerde informatie- en andere gerelateerde bedrijfsmiddelen behoort de eigendom van het bedrijfsmiddel te worden toegewezen aan een persoon of een groep en behoort de classificatie te worden geïdentificeerd (zie 5.12, 5.13). Er behoort een procedure te worden geïmplementeerd die ervoor zorgt dat de benoeming van de eigenaar van bedrijfsmiddelen tijdig plaatsvindtet eigenaarschap behoort te worden toegekend als bedrijfsmiddelen worden aangemaakt of als bedrijfsmiddelen naar de organisatie worden overgebrachtet eigenaarschap van een bedrijfsmiddel behoort naarmate nodig is opnieuw te worden toegekend wanneer de huidige eigenaren van een bedrijfsmiddel vertrekken of een andere functie krijgen. + +[Taken van de eigenaar] + +De eigenaar van het bedrijfsmiddel behoort verantwoordelijk te zijn voor het juiste beheer ervan voor de gehele levenscyclus van het bedrijfsmiddel en behoort ervoor te zorgen dat: + +a) informatie en andere gerelateerde bedrijfsmiddelen worden geïnventariseerd; + +b) informatie en andere gerelateerde bedrijfsmiddelen passend worden geclassificeerd en beschermd; + +c) de classificatie periodiek wordt beoordeeld; + +d) er een lijst wordt opgesteld van de componenten die technologische bedrijfsmiddelen ondersteunen, zoals database-, opslag-, softwarecomponenten en -subcomponenten, en deze worden gekoppeld; + +e) eisen voor het aanvaardbare gebruik van informatie en andere gerelateerde bedrijfsmiddelen (zie 5.10) worden vastgesteld; + +f) de toegangsbeperkingen overeenstemmen met de classificatie, doeltreffend zijn en periodiek worden beoordeeld; + +g) informatie en andere gerelateerde bedrijfsmiddelen die worden gewist of verwijderd, veilig worden behandeld en uit de inventarislijst worden verwijderd; + +h) hij betrokken is bij het identificeren en het beheer van de risico\'s in verband met zijn bedrijfsmiddel(en); + +i) hij het personeel ondersteunt dat de rollen en de verantwoordelijkheden heeft voor het beheren van zijn informatie. + +**Overige informatie** + +Inventarislijsten van informatie en andere gerelateerde bedrijfsmiddelen zijn vaak nodig om de doeltreffende bescherming van informatie zeker te stellen en kunnen voor andere doeleinden vereist zijn, zoals om gezondheids- en veiligheids-, verzekerings- of financiële redenennventarislijsten van informatie en andere gerelateerde bedrijfsmiddelen ondersteunen ook risicobeheer, auditactiviteiten, kwetsbaarhedenbeheer, incidentrespons- en herstelplanning. + +Taken en verantwoordelijkheden kunnen worden gedelegeerd (bijvan een beheerder die de dagelijkse zorg heeft over de bedrijfsmiddelen), maar de persoon of groep die ze heeft gedelegeerd blijft verantwoordelijk. + +Het kan nuttig zijn om groepen van informatie en andere gerelateerde bedrijfsmiddelen aan te wijzen die samen een bepaalde dienst verlenenn dat geval is de eigenaar van deze dienst verantwoordelijk voor het leveren van de dienst, met inbegrip van de werking van de bedrijfsmiddelen die de dienst verzorgen. + +Zie ISO/IEC 19770-1 voor aanvullende informatie over het beheer van IT-bedrijfsmiddelenie ISO 55001 voor aanvullende informatie over het beheer van bedrijfsmiddelen. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.24_BT Gebruik van cryptografie.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.24_BT Gebruik van cryptografie.md new file mode 100644 index 0000000..6fc1f23 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.24_BT Gebruik van cryptografie.md @@ -0,0 +1,4 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.24_NN Gebruik van cryptografie.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.24_NN Gebruik van cryptografie.md new file mode 100644 index 0000000..5220d3d --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.24_NN Gebruik van cryptografie.md @@ -0,0 +1,35 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +## 8.24 Gebruik van cryptografie +ISO 27002:2022 [[ISO_27002_2022_NL_BT 8.24 Gebruik van cryptografie|Brontekst]] + +#### Wat +Beschrijving van de beheersmaatrege;l + +#### Waarom +Doel van de maatregel + +#### Hoe +- Lijst van uit te voeren activiteiten + +##### Sub van Hoe +Eisen aan de structuur en inhoud van artefacten, en andere aanwijzingen. + +#### Overige informatie +- lijst + +#### Bewijs +Auditors kijken naar bewijzen van de implementatie van het proces. Dit kan bijvoorbeeld de volgende vorm aannemen: + +| Omschrijving van bewijs | ISO27DIY artefact | +| ----------------------- | ----------------- | +| Omschrijving 1 | Artefact 1 | + +#### Gerelateerd +Naar deze maatregel wordt verwezen in: +- [ ] Andere beheersmaatregelen binnen dezelfde norm die verwijzen naar deze maatregel + +Andere gerelateerde ISO 27x beheersmaatregelen: +- [ ] Gerelateerde ISO 27x beheersmaatregelen die *niet* letterlijk in de brontekst genoemd worden. diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.28_BT Veilig coderen.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.28_BT Veilig coderen.md new file mode 100644 index 0000000..e69de29 diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.32_BT Wijzigingsbeheer.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.32_BT Wijzigingsbeheer.md new file mode 100644 index 0000000..6fc1f23 --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_8.32_BT Wijzigingsbeheer.md @@ -0,0 +1,4 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_Index.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_Index.md new file mode 100644 index 0000000..841bc4c --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_Index.md @@ -0,0 +1,114 @@ +#iso27002/2022/NL +# ISO 27002:2022 NL Index + + +| 2022 ID | Maatregel | Brontekst | Normaal | +| :------ | :---------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | +| **3** | **Termen, definities en afgekorte termen** | | | +| 3.1 | Termen en definities | [[ISO_27002_2022_NL_3.1_BT Termen en definities \|BT]] | [[ISO_27002_2022_NL_NN 3.1 Termen en definities \|NN]] | +| 3.2 | Afgekorte termen | [[ISO_27002_2022_NL_3.2_BT Afgekorte termen \|BT]] | [[ISO_27002_2022_NL_NN 3.2 Afgekorte termen \|NN]] | +| **4** | **Structuur van dit document** | _ | | +| 4.1 | Hoofdstukken | [[ISO_27002_2022_NL_4.1_BT Hoofdstukken \|BT]] | [[ISO_27002_2022_NL_NN 4.1 Hoofdstukken \|NN]] | +| 4.2 | Thema's en attributen | [[ISO_27002_2022_NL_4.2_BT Thema's en attributen \|BT]] | [[ISO_27002_2022_NL_NN 4.2 Thema's en attributen \|NN]] | +| 4.3 | Indeling beheersmaatregel | [[ISO_27002_2022_NL_4.3_BT Indeling beheersmaatregel \|BT]] | [[ISO_27002_2022_NL_NN 4.3 Indeling beheersmaatregel \|NN]] | +| **5** | **Organisatorische beheersmaatregelen** | _ | | +| 5.1 | Beleidsregels voor informatiebeveiliging | [[ISO_27002_2022_NL_5.1_BT Beleidsregels voor informatiebeveiliging \|BT]] | [[ISO_27002_2022_NL_NN 5.1 Beleidsregels voor informatiebeveiliging \|NN]] | +| 5.2 | Rollen en verantwoordelijkheden bij informatiebeveiliging | [[ISO_27002_2022_NL_5.2_BT Rollen en verantwoordelijkheden bij informatiebeveiliging \|BT]] | [[ISO_27002_2022_NL_NN 5.2 Rollen en verantwoordelijkheden bij informatiebeveiliging \|NN]] | +| 5.3 | Functiescheiding | [[ISO_27002_2022_NL_5.3_BT Functiescheiding \|BT]] | [[ISO_27002_2022_NL_NN 5.3 Functiescheiding \|NN]] | +| 5.4 | Managementverantwoordelijkheden | [[ISO_27002_2022_NL_5.4_BT Managementverantwoordelijkheden \|BT]] | [[ISO_27002_2022_NL_NN 5.4 Managementverantwoordelijkheden \|NN]] | +| 5.5 | Contact met overheidsinstanties | [[ISO_27002_2022_NL_5.5_BT Contact met overheidsinstanties \|BT]] | [[ISO_27002_2022_NL_NN 5.5 Contact met overheidsinstanties \|NN]] | +| 5.6 | Contact met speciale belangengroepen | [[ISO_27002_2022_NL_5.6_BT Contact met speciale belangengroepen \|BT]] | [[ISO_27002_2022_NL_NN 5.6 Contact met speciale belangengroepen \|NN]] | +| 5.7 | Informatie en analyses over dreigingen | [[ISO_27002_2022_NL_5.7_BT Informatie en analyses over dreigingen \|BT]] | [[ISO_27002_2022_NL_NN 5.7 Informatie en analyses over dreigingen \|NN]] | +| 5.8 | Informatiebeveiliging in projectmanagement | [[ISO_27002_2022_NL_5.8_BT Informatiebeveiliging in projectmanagement \|BT]] | [[ISO_27002_2022_NL_NN 5.8 Informatiebeveiliging in projectmanagement \|NN]] | +| 5.9 | Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen | [[ISO_27002_2022_NL_5.9_BT Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen \|BT]] | [[ISO_27002_2022_NL_NN 5.9 Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen \|NN]] | +| 5.10 | Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen | [[ISO_27002_2022_NL_5.10_BT Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen \|BT]] | [[ISO_27002_2022_NL_NN 5.10 Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen \|NN]] | +| 5.11 | Retourneren van bedrijfsmiddelen | [[ISO_27002_2022_NL_5.11_BT Retourneren van bedrijfsmiddelen \|BT]] | [[ISO_27002_2022_NL_NN 5.11 Retourneren van bedrijfsmiddelen \|NN]] | +| 5.12 | Classificeren van informatie | [[ISO_27002_2022_NL_5.12_BT Classificeren van informatie \|BT]] | [[ISO_27002_2022_NL_NN 5.12 Classificeren van informatie \|NN]] | +| 5.13 | Labelen van informatie | [[ISO_27002_2022_NL_5.13_BT Labelen van informatie \|BT]] | [[ISO_27002_2022_NL_NN 5.13 Labelen van informatie \|NN]] | +| 5.14 | Overdragen van informatie | [[ISO_27002_2022_NL_5.14_BT Overdragen van informatie \|BT]] | [[ISO_27002_2022_NL_NN 5.14 Overdragen van informatie \|NN]] | +| 5.15 | Toegangsbeveiliging | [[ISO_27002_2022_NL_5.15_BT Toegangsbeveiliging \|BT]] | [[ISO_27002_2022_NL_NN 5.15 Toegangsbeveiliging \|NN]] | +| 5.16 | Identiteitsbeheer | [[ISO_27002_2022_NL_5.16_BT Identiteitsbeheer \|BT]] | [[ISO_27002_2022_NL_NN 5.16 Identiteitsbeheer \|NN]] | +| 5.17 | Beheren van authenticatie-informatie | [[ISO_27002_2022_NL_5.17_BT Beheren van authenticatie-informatie \|BT]] | [[ISO_27002_2022_NL_NN 5.17 Beheren van authenticatie-informatie \|NN]] | +| 5.18 | Toegangsrechten | [[ISO_27002_2022_NL_5.18_BT Toegangsrechten \|BT]] | [[ISO_27002_2022_NL_NN 5.18 Toegangsrechten \|NN]] | +| 5.19 | Informatiebeveiliging in leveranciersrelaties | [[ISO_27002_2022_NL_5.19_BT Informatiebeveiliging in leveranciersrelaties \|BT]] | [[ISO_27002_2022_NL_NN 5.19 Informatiebeveiliging in leveranciersrelaties \|NN]] | +| 5.20 | Adresseren van informatiebeveiliging in leveranciersovereenkomsten | [[ISO_27002_2022_NL_5.20_BT Adresseren van informatiebeveiliging in leveranciersovereenkomsten \|BT]] | [[ISO_27002_2022_NL_NN 5.20 Adresseren van informatiebeveiliging in leveranciersovereenkomsten \|NN]] | +| 5.21 | Beheren van informatiebeveiliging in de ICT-keten | [[ISO_27002_2022_NL_5.21_BT Beheren van informatiebeveiliging in de ICT-keten \|BT]] | [[ISO_27002_2022_NL_NN 5.21 Beheren van informatiebeveiliging in de ICT-keten \|NN]] | +| 5.22 | Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten | [[ISO_27002_2022_NL_5.22_BT Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten \|BT]] | [[ISO_27002_2022_NL_NN 5.22 Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten \|NN]] | +| 5.23 | Informatiebeveiliging voor het gebruik van clouddiensten | [[ISO_27002_2022_NL_5.23_BT Informatiebeveiliging voor het gebruik van clouddiensten \|BT]] | [[ISO_27002_2022_NL_NN 5.23 Informatiebeveiliging voor het gebruik van clouddiensten \|NN]] | +| 5.24 | Plannen en voorbereiden van het beheer van informatiebeveiligingsincidenten | [[ISO_27002_2022_NL_5.24_BT Plannen en voorbereiden van het beheer van informatiebeveiligingsincidenten \|BT]] | [[ISO_27002_2022_NL_NN 5.24 Plannen en voorbereiden van het beheer van informatiebeveiligingsincidenten \|NN]] | +| 5.25 | Beoordelen van en besluiten over informatiebeveiligingsgebeurtenissen | [[ISO_27002_2022_NL_5.25_BT Beoordelen van en besluiten over informatiebeveiligingsgebeurtenissen \|BT]] | [[ISO_27002_2022_NL_NN 5.25 Beoordelen van en besluiten over informatiebeveiligingsgebeurtenissen \|NN]] | +| 5.26 | Reageren op informatiebeveiligingsincidenten | [[ISO_27002_2022_NL_5.26_BT Reageren op informatiebeveiligingsincidenten \|BT]] | [[ISO_27002_2022_NL_NN 5.26 Reageren op informatiebeveiligingsincidenten \|NN]] | +| 5.27 | Leren van informatiebeveiligingsincidenten | [[ISO_27002_2022_NL_5.27_BT Leren van informatiebeveiligingsincidenten \|BT]] | [[ISO_27002_2022_NL_NN 5.27 Leren van informatiebeveiligingsincidenten \|NN]] | +| 5.28 | Verzamelen van bewijsmateriaal | [[ISO_27002_2022_NL_5.28_BT Verzamelen van bewijsmateriaal \|BT]] | [[ISO_27002_2022_NL_NN 5.28 Verzamelen van bewijsmateriaal \|NN]] | +| 5.29 | Informatiebeveiliging tijdens een verstoring | [[ISO_27002_2022_NL_5.29_BT Informatiebeveiliging tijdens een verstoring \|BT]] | [[ISO_27002_2022_NL_NN 5.29 Informatiebeveiliging tijdens een verstoring \|NN]] | +| 5.30 | ICT-gereedheid voor bedrijfscontinuïteit | [[ISO_27002_2022_NL_5.30_BT ICT-gereedheid voor bedrijfscontinuïteit \|BT]] | [[ISO_27002_2022_NL_NN 5.30 ICT-gereedheid voor bedrijfscontinuïteit \|NN]] | +| 5.31 | Wettelijke, statutaire, regelgevende en contractuele eisen | [[ISO_27002_2022_NL_5.31_BT Wettelijke, statutaire, regelgevende en contractuele eisen \|BT]] | [[ISO_27002_2022_NL_NN 5.31 Wettelijke, statutaire, regelgevende en contractuele eisen \|NN]] | +| 5.32 | Intellectuele-eigendomsrechten | [[ISO_27002_2022_NL_5.32_BT Intellectuele-eigendomsrechten \|BT]] | [[ISO_27002_2022_NL_NN 5.32 Intellectuele-eigendomsrechten \|NN]] | +| 5.33 | Beschermen van registraties | [[ISO_27002_2022_NL_5.33_BT Beschermen van registraties \|BT]] | [[ISO_27002_2022_NL_NN 5.33 Beschermen van registraties \|NN]] | +| 5.34 | Privacy en bescherming van persoonsgegevens | [[ISO_27002_2022_NL_5.34_BT Privacy en bescherming van persoonsgegevens \|BT]] | [[ISO_27002_2022_NL_NN 5.34 Privacy en bescherming van persoonsgegevens \|NN]] | +| 5.35 | Onafhankelijke beoordeling van informatiebeveiliging | [[ISO_27002_2022_NL_5.35_BT Onafhankelijke beoordeling van informatiebeveiliging \|BT]] | [[ISO_27002_2022_NL_NN 5.35 Onafhankelijke beoordeling van informatiebeveiliging \|NN]] | +| 5.36 | Naleving van beleid, regels en normen voor informatiebeveiliging | [[ISO_27002_2022_NL_5.36_BT Naleving van beleid, regels en normen voor informatiebeveiliging \|BT]] | [[ISO_27002_2022_NL_NN 5.36 Naleving van beleid, regels en normen voor informatiebeveiliging \|NN]] | +| 5.37 | Gedocumenteerde bedieningsprocedures | [[ISO_27002_2022_NL_5.37_BT Gedocumenteerde bedieningsprocedures \|BT]] | [[ISO_27002_2022_NL_NN 5.37 Gedocumenteerde bedieningsprocedures \|NN]] | +| | | | | +| **6** | **Mensgerichte beheersmaatregelen** | | | +| 6.1 | Screening | [[ISO_27002_2022_NL_6.1_BT Screening \|BT]] | [[ISO_27002_2022_NL_NN 6.1 Screening \|NN]] | +| 6.2 | Arbeidsovereenkomst | [[ISO_27002_2022_NL_6.2_BT Arbeidsovereenkomst \|BT]] | [[ISO_27002_2022_NL_NN 6.2 Arbeidsovereenkomst \|NN]] | +| 6.3 | Bewustwording van, opleiding en training in informatiebeveiliging | [[ISO_27002_2022_NL_6.3_BT Bewustwording van, opleiding en training in informatiebeveiliging \|BT]] | [[ISO_27002_2022_NL_NN 6.3 Bewustwording van, opleiding en training in informatiebeveiliging \|NN]] | +| 6.4 | Disciplinaire procedure | [[ISO_27002_2022_NL_6.4_BT Disciplinaire procedure \|BT]] | [[ISO_27002_2022_NL_NN 6.4 Disciplinaire procedure \|NN]] | +| 6.5 | Verantwoordelijkheden na beëindiging of wijziging van het dienstverband | [[ISO_27002_2022_NL_6.5_BT Verantwoordelijkheden na beëindiging of wijziging van het dienstverband \|BT]] | [[ISO_27002_2022_NL_NN 6.5 Verantwoordelijkheden na beëindiging of wijziging van het dienstverband \|NN]] | +| 6.6 | Vertrouwelijkheids- of geheimhoudingsovereenkomsten | [[ISO_27002_2022_NL_6.6_BT Vertrouwelijkheids- of geheimhoudingsovereenkomsten \|BT]] | [[ISO_27002_2022_NL_NN 6.6 Vertrouwelijkheids- of geheimhoudingsovereenkomsten \|NN]] | +| 6.7 | Werken op afstand | [[ISO_27002_2022_NL_6.7_BT Werken op afstand \|BT]] | [[ISO_27002_2022_NL_NN 6.7 Werken op afstand \|NN]] | +| 6.8 | Melden van informatiebeveiligingsgebeurtenissen | [[ISO_27002_2022_NL_6.8_BT Melden van informatiebeveiligingsgebeurtenissen \|BT]] | [[ISO_27002_2022_NL_NN 6.8 Melden van informatiebeveiligingsgebeurtenissen \|NN]] | +| | | | | +| **7** | **Fysieke beheersmaatregelen** | | | +| 7.1 | Fysieke beveiligingszones | [[ISO_27002_2022_NL_7.1_BT Fysieke beveiligingszones \|BT]] | [[ISO_27002_2022_NL_NN 7.1 Fysieke beveiligingszones \|NN]] | +| 7.2 | Fysieke toegangsbeveiliging | [[ISO_27002_2022_NL_7.2_BT Fysieke toegangsbeveiliging \|BT]] | [[ISO_27002_2022_NL_NN 7.2 Fysieke toegangsbeveiliging \|NN]] | +| 7.3 | Beveiligen van kantoren, ruimten en faciliteiten | [[ISO_27002_2022_NL_7.3_BT Beveiligen van kantoren, ruimten en faciliteiten \|BT]] | [[ISO_27002_2022_NL_NN 7.3 Beveiligen van kantoren, ruimten en faciliteiten \|NN]] | +| 7.4 | Monitoren van de fysieke beveiliging | [[ISO_27002_2022_NL_7.4_BT Monitoren van de fysieke beveiliging \|BT]] | [[ISO_27002_2022_NL_NN 7.4 Monitoren van de fysieke beveiliging \|NN]] | +| 7.5 | Beschermen tegen fysieke en omgevingsdreigingen | [[ISO_27002_2022_NL_7.5_BT Beschermen tegen fysieke en omgevingsdreigingen \|BT]] | [[ISO_27002_2022_NL_NN 7.5 Beschermen tegen fysieke en omgevingsdreigingen \|NN]] | +| 7.6 | Werken in beveiligde zones | [[ISO_27002_2022_NL_7.6_BT Werken in beveiligde zones \|BT]] | [[ISO_27002_2022_NL_NN 7.6 Werken in beveiligde zones \|NN]] | +| 7.7 | ‘Clear desk’ en ‘clear screen’ | [[ISO_27002_2022_NL_7.7_BT ‘Clear desk’ en ‘clear screen’ \|BT]] | [[ISO_27002_2022_NL_NN 7.7 ‘Clear desk’ en ‘clear screen’ \|NN]] | +| 7.8 | Plaatsen en beschermen van apparatuur | [[ISO_27002_2022_NL_7.8_BT Plaatsen en beschermen van apparatuur \|BT]] | [[ISO_27002_2022_NL_NN 7.8 Plaatsen en beschermen van apparatuur \|NN]] | +| 7.9 | Beveiligen van bedrijfsmiddelen buiten het terrein | [[ISO_27002_2022_NL_7.9_BT Beveiligen van bedrijfsmiddelen buiten het terrein \|BT]] | [[ISO_27002_2022_NL_NN 7.9 Beveiligen van bedrijfsmiddelen buiten het terrein \|NN]] | +| 7.10 | Opslagmedia | [[ISO_27002_2022_NL_7.10_BT Opslagmedia \|BT]] | [[ISO_27002_2022_NL_NN 7.10 Opslagmedia \|NN]] | +| 7.11 | Nutsvoorzieningen | [[ISO_27002_2022_NL_7.11_BT Nutsvoorzieningen \|BT]] | [[ISO_27002_2022_NL_NN 7.11 Nutsvoorzieningen \|NN]] | +| 7.12 | Beveiligen van bekabeling | [[ISO_27002_2022_NL_7.12_BT Beveiligen van bekabeling \|BT]] | [[ISO_27002_2022_NL_NN 7.12 Beveiligen van bekabeling \|NN]] | +| 7.13 | Onderhoud van apparatuur | [[ISO_27002_2022_NL_7.13_BT Onderhoud van apparatuur \|BT]] | [[ISO_27002_2022_NL_NN 7.13 Onderhoud van apparatuur \|NN]] | +| 7.14 | Veilig verwijderen of hergebruiken van apparatuur | [[ISO_27002_2022_NL_7.14_BT Veilig verwijderen of hergebruiken van apparatuur \|BT]] | [[ISO_27002_2022_NL_NN 7.14 Veilig verwijderen of hergebruiken van apparatuur \|NN]] | +| | | | | +| **8** | **Technologische beheersmaatregelen** | | | +| 8.1 | ‘User endpoint devices’ | [[ISO_27002_2022_NL_8.1_BT ‘User endpoint devices’ \|BT]] | [[ISO_27002_2022_NL_NN 8.1 ‘User endpoint devices’ \|NN]] | +| 8.2 | Speciale toegangsrechten | [[ISO_27002_2022_NL_8.2_BT Speciale toegangsrechten \|BT]] | [[ISO_27002_2022_NL_NN 8.2 Speciale toegangsrechten \|NN]] | +| 8.3 | Beperking toegang tot informatie | [[ISO_27002_2022_NL_8.3_BT Beperking toegang tot informatie \|BT]] | [[ISO_27002_2022_NL_NN 8.3 Beperking toegang tot informatie \|NN]] | +| 8.4 | Toegangsbeveiliging op broncode | [[ISO_27002_2022_NL_8.4_BT Toegangsbeveiliging op broncode \|BT]] | [[ISO_27002_2022_NL_NN 8.4 Toegangsbeveiliging op broncode \|NN]] | +| 8.5 | Beveiligde authenticatie | [[ISO_27002_2022_NL_8.5_BT Beveiligde authenticatie \|BT]] | [[ISO_27002_2022_NL_NN 8.5 Beveiligde authenticatie \|NN]] | +| 8.6 | Capaciteitsbeheer | [[ISO_27002_2022_NL_8.6_BT Capaciteitsbeheer \|BT]] | [[ISO_27002_2022_NL_NN 8.6 Capaciteitsbeheer \|NN]] | +| 8.7 | Bescherming tegen malware | [[ISO_27002_2022_NL_8.7_BT Bescherming tegen malware \|BT]] | [[ISO_27002_2022_NL_NN 8.7 Bescherming tegen malware \|NN]] | +| 8.8 | Beheer van technische kwetsbaarheden | [[ISO_27002_2022_NL_8.8_BT Beheer van technische kwetsbaarheden \|BT]] | [[ISO_27002_2022_NL_NN 8.8 Beheer van technische kwetsbaarheden \|NN]] | +| 8.9 | Configuratiebeheer | [[ISO_27002_2022_NL_8.9_BT Configuratiebeheer \|BT]] | [[ISO_27002_2022_NL_NN 8.9 Configuratiebeheer \|NN]] | +| 8.10 | Wissen van informatie | [[ISO_27002_2022_NL_8.10_BT Wissen van informatie \|BT]] | [[ISO_27002_2022_NL_NN 8.10 Wissen van informatie \|NN]] | +| 8.11 | Maskeren van gegevens | [[ISO_27002_2022_NL_8.11_BT Maskeren van gegevens \|BT]] | [[ISO_27002_2022_NL_NN 8.11 Maskeren van gegevens \|NN]] | +| 8.12 | Voorkomen van gegevenslekken (Data leakage prevention) | [[ISO_27002_2022_NL_8.12_BT Voorkomen van gegevenslekken (Data leakage prevention) \|BT]] | [[ISO_27002_2022_NL_NN 8.12 Voorkomen van gegevenslekken (Data leakage prevention) \|NN]] | +| 8.13 | Back-up van informatie | [[ISO_27002_2022_NL_8.13_BT Back-up van informatie \|BT]] | [[ISO_27002_2022_NL_NN 8.13 Back-up van informatie \|NN]] | +| 8.14 | Redundantie van informatieverwerkende faciliteiten | [[ISO_27002_2022_NL_8.14_BT Redundantie van informatieverwerkende faciliteiten \|BT]] | [[ISO_27002_2022_NL_NN 8.14 Redundantie van informatieverwerkende faciliteiten \|NN]] | +| 8.15 | Logging | [[ISO_27002_2022_NL_8.15_BT Logging \|BT]] | [[ISO_27002_2022_NL_NN 8.15 Logging \|NN]] | +| 8.16 | Monitoren van activiteiten | [[ISO_27002_2022_NL_8.16_BT Monitoren van activiteiten \|BT]] | [[ISO_27002_2022_NL_NN 8.16 Monitoren van activiteiten \|NN]] | +| 8.17 | Kloksynchronisatie | [[ISO_27002_2022_NL_8.17_BT Kloksynchronisatie \|BT]] | [[ISO_27002_2022_NL_NN 8.17 Kloksynchronisatie \|NN]] | +| 8.18 | Gebruik van speciale systeemhulpmiddelen | [[ISO_27002_2022_NL_8.18_BT Gebruik van speciale systeemhulpmiddelen \|BT]] | [[ISO_27002_2022_NL_NN 8.18 Gebruik van speciale systeemhulpmiddelen \|NN]] | +| 8.19 | Installeren van software op operationele systemen | [[ISO_27002_2022_NL_8.19_BT Installeren van software op operationele systemen \|BT]] | [[ISO_27002_2022_NL_NN 8.19 Installeren van software op operationele systemen \|NN]] | +| 8.20 | Beveiliging netwerkcomponenten | [[ISO_27002_2022_NL_8.20_BT Beveiliging netwerkcomponenten \|BT]] | [[ISO_27002_2022_NL_NN 8.20 Beveiliging netwerkcomponenten \|NN]] | +| 8.21 | Beveiliging van netwerkdiensten | [[ISO_27002_2022_NL_8.21_BT Beveiliging van netwerkdiensten \|BT]] | [[ISO_27002_2022_NL_NN 8.21 Beveiliging van netwerkdiensten \|NN]] | +| 8.22 | Netwerksegmentatie | [[ISO_27002_2022_NL_8.22_BT Netwerksegmentatie \|BT]] | [[ISO_27002_2022_NL_NN 8.22 Netwerksegmentatie \|NN]] | +| 8.23 | Toepassen van webfilters | [[ISO_27002_2022_NL_8.23_BT Toepassen van webfilters \|BT]] | [[ISO_27002_2022_NL_NN 8.23 Toepassen van webfilters \|NN]] | +| 8.24 | Gebruik van cryptografie | [[ISO_27002_2022_NL_8.24_BT Gebruik van cryptografie \|BT]] | [[ISO_27002_2022_NL_NN 8.24 Gebruik van cryptografie \|NN]] | +| 8.25 | Beveiligen tijdens de ontwikkelcyclus | [[ISO_27002_2022_NL_8.25_BT Beveiligen tijdens de ontwikkelcyclus \|BT]] | [[ISO_27002_2022_NL_NN 8.25 Beveiligen tijdens de ontwikkelcyclus \|NN]] | +| 8.26 | Toepassingsbeveiligingseisen | [[ISO_27002_2022_NL_8.26_BT Toepassingsbeveiligingseisen \|BT]] | [[ISO_27002_2022_NL_NN 8.26 Toepassingsbeveiligingseisen \|NN]] | +| 8.27 | Veilige systeemarchitectuur en technische uitgangspunten | [[ISO_27002_2022_NL_8.27_BT Veilige systeemarchitectuur en technische uitgangspunten \|BT]] | [[ISO_27002_2022_NL_NN 8.27 Veilige systeemarchitectuur en technische uitgangspunten \|NN]] | +| 8.28 | Veilig coderen | [[ISO_27002_2022_NL_8.28_BT Veilig coderen \|BT]] | [[ISO_27002_2022_NL_NN 8.28 Veilig coderen \|NN]] | +| 8.29 | Testen van de beveiliging tijdens ontwikkeling en acceptatie | [[ISO_27002_2022_NL_8.29_BT Testen van de beveiliging tijdens ontwikkeling en acceptatie \|BT]] | [[ISO_27002_2022_NL_NN 8.29 Testen van de beveiliging tijdens ontwikkeling en acceptatie \|NN]] | +| 8.30 | Uitbestede systeemontwikkeling | [[ISO_27002_2022_NL_8.30_BT Uitbestede systeemontwikkeling \|BT]] | [[ISO_27002_2022_NL_NN 8.30 Uitbestede systeemontwikkeling \|NN]] | +| 8.31 | Scheiding van ontwikkel-, test- en productieomgevingen | [[ISO_27002_2022_NL_8.31_BT Scheiding van ontwikkel-, test- en productieomgevingen \|BT]] | [[ISO_27002_2022_NL_NN 8.31 Scheiding van ontwikkel-, test- en productieomgevingen \|NN]] | +| 8.32 | Wijzigingsbeheer | [[ISO_27002_2022_NL_8.32_BT Wijzigingsbeheer \|BT]] | [[ISO_27002_2022_NL_NN 8.32 Wijzigingsbeheer \|NN]] | +| 8.33 | Testgegevens | [[ISO_27002_2022_NL_8.33_BT Testgegevens \|BT]] | [[ISO_27002_2022_NL_NN 8.33 Testgegevens \|NN]] | +| 8.34 | Bescherming van informatiesystemen tijdens audits | [[ISO_27002_2022_NL_8.34_BT Bescherming van informatiesystemen tijdens audits \|BT]] | [[ISO_27002_2022_NL_NN 8.34 Bescherming van informatiesystemen tijdens audits \|NN]] | + diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_PDF.md b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_PDF.md new file mode 100644 index 0000000..94f268e --- /dev/null +++ b/Corpus/Standards/ISO-27002-OST/ISO27002-NL-2022/ISO_27002_2022_NL_PDF.md @@ -0,0 +1,8 @@ +#iso27002/2022/NL +--- +Standard: ISO 27002:2022 NL +--- +# ISO 27002 2022 NL + +![[ISO_IEC 27002_2022_NL.pdf]] + diff --git a/Corpus/Standards/ISO_27002_2022_What's_New.md b/Corpus/Standards/ISO_27002_2022_What's_New.md new file mode 100644 index 0000000..0707ea4 --- /dev/null +++ b/Corpus/Standards/ISO_27002_2022_What's_New.md @@ -0,0 +1,44 @@ +#iso27002/2022/EN +Source:[ Wentz Wu](https://wentzwu.com/2022/02/16/iso-iec-270022022-controls/) +Publishing date February 16, 2022 +Retrieved February 17, 2022 + +ISO 27001:2013 had 114 controls in Annex A, ISO/IEC 27002:2022 introduces 93 controls. + +https://ictinstitute.nl/iso270022022-what-is-new/ +See also [[ICT Institute's ISO 27002 2022 in plain English]] + +Wentz Wu has created a 'control taxonomy' in [[ISO-27002-2022-Controls-categorized.pdf]]: + +- Control type: Preventive, Detective, and Corrective. +- Information security properties: Confidentiality, Integrity and Availability. +- Cybersecurity concepts: Identify, Protect, Detect, Respond and Recover. +- Security domains: Governance_and_Ecosystem, Protection, Defence and Resilience +- Operational capabilities: see below. + +Operational capabilities: +1. Governance +2. Asset_management +3. Information_protection +4. Human_resource_security +5. Physical_security +6. System_and_network_security +7. Application_security +8. Secure_configuration +9. Identity_and_access_management +10. Threat_and_vulnerability_management +11. Continuity +12. Supplier_relationships_security +13. Legal_and_compliance +14. Information_security_event_management +15. **Information_security_assurance** + +The norm categorizes the controls in 4 sections: +- people controls (i.e. individuals) +- physical controls +- technological controls +- organizational controls + +![[ISO_IEC-27002_2022-Controls_I.jpg]] + +![[ISO_IEC-27002_2022-Controls_II.jpg]] \ No newline at end of file diff --git a/Corpus/Standards/ISO_31000_OT 5.4.1 Understanding the organization and its context.md b/Corpus/Standards/ISO_31000_OT 5.4.1 Understanding the organization and its context.md new file mode 100644 index 0000000..c264717 --- /dev/null +++ b/Corpus/Standards/ISO_31000_OT 5.4.1 Understanding the organization and its context.md @@ -0,0 +1,28 @@ +#iso31000/2018 + +### 5.4.1   Understanding the organization and its context +From ISO 31000:2018 + +When designing the framework for managing risk, the organization should examine and understand its external and internal context. + +Examining the organization’s **external context** may include, but is not limited to: + +- the social, cultural, political, legal, regulatory, financial, technological, economic and environmental factors, whether international, national, regional or local; +- key drivers and trends affecting the objectives of the organization; +- external stakeholders’ relationships, perceptions, values, needs and expectations; +- contractual relationships and commitments; +- the complexity of networks and dependencies. + + +Examining the organization’s **internal context** may include, but is not limited to: + +- vision, mission and values; +- governance, organizational structure, roles and accountabilities; +- strategy, objectives and policies; +- the organization’s culture; +- standards, guidelines and models adopted by the organization; +- capabilities, understood in terms of resources and knowledge (e.g. capital, time, people, intellectual property, processes, systems and technologies); +- data, information systems and information flows; +- relationships with internal stakeholders, taking into account their perceptions and values; +- contractual relationships and commitments; +- interdependencies and interconnections. \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_00_MoC Index EXT.md b/Corpus/Standards/MoCs/ISO_27001_2022_00_MoC Index EXT.md new file mode 100644 index 0000000..445b5b0 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_00_MoC Index EXT.md @@ -0,0 +1,113 @@ +#iso27002/2022/EN +# ISO 27002:2022 EN Index + +| 2022 ID | Control title | 2013 | +| ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | +| **F** | **[[ISO_27002_OT_F Foreword \|Foreword]]** | | +| **0** | **[[ISO_27002_OT_0 Introduction \|Introduction]]** | | +| **1** | **[[ISO_27002_OT_1 Scope \|Scope]]** | | +| **2** | **[[ISO_27002_OT_2 Normative references\|Normative references]]** | | +| **3** | **Terms, definitions and abbreviated terms** | | +| 3.1 | **[[ISO_27002_OT_3.1 Terms and definitions\|Terms and definitions]]** | | +| 3.2 | **[[ISO_27002_OT_3.2 Abbreviated terms\|Abbreviated terms]]** | | +| **4** | **Structure of this document** | | +| 4.1 | [[ISO_27002_OT_4.1 Clauses \| Clauses ]] | | +| 4.2 | [[ISO_27002_OT_4.2 Themes and attributes \| Themes and attributes ]] | | +| 4.3 | [[ISO_27002_OT_4.3 Control layout \| Control layout ]] | | +| **5** | **Organizational controls** | | +| 5.1 | [[ISO_27002_2022_5.1_MoC Policies for information security \|Policies for information security ]] | 05.1.1, 05.1.2 | +| 5.2 | [[ISO_27002_2022_5.2_MoC Information security roles and responsibilities \|Information security roles and responsibilities ]] | 06.1.1 | +| 5.3 | [[ISO_27002_2022_5.3_MoC Segregation of duties \|Segregation of duties ]] | 06.1.2 | +| 5.4 | [[ISO_27002_2022_5.4_MoC Management responsibilities \|Management responsibilities ]] | 07.2.1 | +| 5.5 | [[ISO_27002_2022_5.5_MoC Contact with authorities \|Contact with authorities ]] | 06.1.3 | +| 5.6 | [[ISO_27002_2022_5.6_MoC Contact with special interest groups \|Contact with special interest groups ]] | 06.1.4 | +| 5.7 | [[ISO_27002_2022_5.7_MoC Threat intelligence \|Threat intelligence ]] | New | +| 5.8 | [[ISO_27002_2022_5.8_MoC Information security in project management \|Information security in project management ]] | 06.1.5, 14.1.1 | +| 5.9 | [[ISO_27002_2022_5.9_MoC Inventory of information and other associated assets \|Inventory of information and other associated assets ]] | 08.1.1, 08.1.2 | +| 5.10 | [[ISO_27002_2022_5.10_MoC Acceptable use of information and other associated assets \|Acceptable use of information and other associated assets ]] | 08.1.3, 08.2.3 | +| 5.11 | [[ISO_27002_2022_5.11_MoC Return of assets \|Return of assets ]] | 08.1.4 | +| 5.12 | [[ISO_27002_2022_5.12_MoC Classification of information \|Classification of information ]] | 08.2.1 | +| 5.13 | [[ISO_27002_2022_5.13_MoC Labelling of information \|Labelling of information ]] | 08.2.2 | +| 5.14 | [[ISO_27002_2022_5.14_MoC Information transfer \|Information transfer ]] | 13.2.1, 13.2.2, 13.2.3 | +| 5.15 | [[ISO_27002_2022_5.15_MoC Access control \|Access control ]] | 09.1.1, 09.1.2 | +| 5.16 | [[ISO_27002_2022_5.16_MoC Identity management \|Identity management ]] | 09.2.1 | +| 5.17 | [[ISO_27002_2022_5.17_MoC Authentication information \|Authentication information ]] | 09.2.4, 09.3.1, 09.4.3 | +| 5.18 | [[ISO_27002_2022_5.18_MoC Access rights \|Access rights ]] | 09.2.2, 09.2.5, 09.2.6 | +| 5.19 | [[ISO_27002_2022_5.19_MoC Information security in supplier relationships \|Information security in supplier relationships ]] | 15.1.1 | +| 5.20 | [[ISO_27002_2022_5.20_MoC Addressing information security within supplier agreements \|Addressing information security within supplier agreements ]] | 15.1.2 | +| 5.21 | [[ISO_27002_2022_5.21_MoC Managing information security in the ICT supply chain \|Managing information security in the ICT supply chain ]] | 15.1.3 | +| 5.22 | [[ISO_27002_2022_5.22_MoC Monitoring, review and change management of supplier services \|Monitoring, review and change management of supplier services ]] | 15.2.1, 15.2.2 | +| 5.23 | [[ISO_27002_2022_5.23_MoC Information security for use of cloud services \|Information security for use of cloud services ]] | New | +| 5.24 | [[ISO_27002_2022_5.24_MoC Information security incident management planning and preparation \|Information security incident management planning and preparation ]] | 16.1.1 | +| 5.25 | [[ISO_27002_2022_5.25_MoC Assessment and decision on information security events \|Assessment and decision on information security events ]] | 16.1.4 | +| 5.26 | [[ISO_27002_2022_5.26_MoC Response to information security incidents \|Response to information security incidents ]] | 16.1.5 | +| 5.27 | [[ISO_27002_2022_5.27_MoC Learning from information security incidents \|Learning from information security incidents ]] | 16.1.6 | +| 5.28 | [[ISO_27002_2022_5.28_MoC Collection of evidence \|Collection of evidence ]] | 16.1.7 | +| 5.29 | [[ISO_27002_2022_5.29_MoC Information security during disruption \|Information security during disruption ]] | 17.1.1, 17.1.2, 17.1.3 | +| 5.30 | [[ISO_27002_2022_5.30_MoC ICT readiness for business continuity \|ICT readiness for business continuity ]] | New | +| 5.31 | [[ISO_27002_2022_5.31_MoC Legal, statutory, regulatory and contractual requirements \|Legal, statutory, regulatory and contractual requirements ]] | 18.1.1, 18.1.5 | +| 5.32 | [[ISO_27002_2022_5.32_MoC Intellectual property rights \|Intellectual property rights ]] | 18.1.2 | +| 5.33 | [[ISO_27002_2022_5.33_MoC Protection of records \|Protection of records ]] | 18.1.3 | +| 5.34 | [[ISO_27002_2022_5.34_MoC Privacy and protection of PII \|Privacy and protection of PII ]] | 18.1.4 | +| 5.35 | [[ISO_27002_2022_5.35_MoC Independent review of information security \|Independent review of information security ]] | 18.2.1 | +| 5.36 | [[ISO_27002_2022_5.36_MoC Compliance with policies, rules and standards for information security \|Compliance with policies, rules and standards for information security]] | 18.2.2, 18.2.3 | +| 5.37 | [[ISO_27002_2022_5.37_MoC Documented operating procedures \|Documented operating procedures ]] | 12.1.1 | +| **6** | **People controls** | | +| 6.1 | [[ISO_27002_2022_6.1_MoC Screening \|Screening ]] | 07.1.1 | +| 6.2 | [[ISO_27002_2022_6.2_MoC Terms and conditions of employment \|Terms and conditions of employment ]] | 07.1.2 | +| 6.3 | [[ISO_27002_2022_6.3_MoC Information security awareness, education and training \|Information security awareness, education and training ]] | 07.2.2 | +| 6.4 | [[ISO_27002_2022_6.4_MoC Disciplinary process \|Disciplinary process ]] | 07.2.3 | +| 6.5 | [[ISO_27002_2022_6.5_MoC Responsibilities after termination or change of employment \|Responsibilities after termination or change of employment ]] | 07.3.1 | +| 6.6 | [[ISO_27002_2022_6.6_MoC Confidentiality or non-disclosure agreements \|Confidentiality or non-disclosure agreements ]] | 13.2.4 | +| 6.7 | [[ISO_27002_2022_6.7_MoC Remote working \|Remote working ]] | 06.2.2 | +| 6.8 | [[ISO_27002_2022_6.8_MoC Information security event reporting \|Information security event reporting ]] | 16.1.2, 16.1.3 | +| **7** | **Physical controls** | | +| 7.1 | [[ISO_27002_2022_7.1_MoC Physical security perimeters \|Physical security perimeters ]] | 11.1.1 | +| 7.2 | [[ISO_27002_2022_7.2_MoC Physical entry \|Physical entry ]] | 11.1.2, 11.1.6 | +| 7.3 | [[ISO_27002_2022_7.3_MoC Securing offices, rooms and facilities \|Securing offices, rooms and facilities ]] | 11.1.3 | +| 7.4 | [[ISO_27002_2022_7.4_MoC Physical security monitoring \|Physical security monitoring ]] | New | +| 7.5 | [[ISO_27002_2022_7.5_MoC Protecting against physical and environmental threats \|Protecting against physical and environmental threats ]] | 11.1.4 | +| 7.6 | [[ISO_27002_2022_7.6_MoC Working in secure areas \|Working in secure areas ]] | 11.1.5 | +| 7.7 | [[ISO_27002_2022_7.7_MoC Clear desk and clear screen \|Clear desk and clear screen ]] | 11.2.9 | +| 7.8 | [[ISO_27002_2022_7.8_MoC Equipment siting and protection \|Equipment siting and protection ]] | 11.2.1 | +| 7.9 | [[ISO_27002_2022_7.9_MoC Security of assets off-premises \|Security of assets off-premises ]] | 11.2.6 | +| 7.10 | [[ISO_27002_2022_7.10_MoC Storage media \|Storage media ]] | 08.3.1, 08.3.2, 08.3.3, 11.2.5 | +| 7.11 | [[ISO_27002_2022_7.11_MoC Supporting utilities \|Supporting utilities ]] | 11.2.2 | +| 7.12 | [[ISO_27002_2022_7.12_MoC Cabling security \|Cabling security ]] | 11.2.3 | +| 7.13 | [[ISO_27002_2022_7.13_MoC Equipment maintenance \|Equipment maintenance ]] | 11.2.4 | +| 7.14 | [[ISO_27002_2022_7.14_MoC Secure disposal or re-use of equipment \|Secure disposal or re-use of equipment ]] | 11.2.7 | +| **8** | **Technological controls** | | +| 8.1 | [[ISO_27002_2022_8.1_MoC User endpoint devices \|User endpoint devices ]] | 06.2.1, 11.2.8 | +| 8.2 | [[ISO_27002_2022_8.2_MoC Privileged access rights \|Privileged access rights ]] | 09.2.3 | +| 8.3 | [[ISO_27002_2022_8.3_MoC Information access restriction \|Information access restriction ]] | 09.4.1 | +| 8.4 | [[ISO_27002_2022_8.4_MoC Access to source code \|Access to source code ]] | 09.4.5 | +| 8.5 | [[ISO_27002_2022_8.5_MoC Secure authentication \|Secure authentication ]] | 09.4.2 | +| 8.6 | [[ISO_27002_2022_8.6_MoC Capacity management \|Capacity management ]] | 12.1.3 | +| 8.7 | [[ISO_27002_2022_8.7_MoC Protection against malware \|Protection against malware ]] | 12.2.1 | +| 8.8 | [[ISO_27002_2022_8.8_MoC Management of technical vulnerabilities \|Management of technical vulnerabilities ]] | 12.6.1, 18.2.3 | +| 8.9 | [[ISO_27002_2022_8.9_MoC Configuration management \|Configuration management ]] | New | +| 8.10 | [[ISO_27002_2022_8.10_MoC Information deletion \|Information deletion ]] | New | +| 8.11 | [[ISO_27002_2022_8.11_MoC Data masking \|Data masking ]] | New | +| 8.12 | [[ISO_27002_2022_8.12_MoC Data leakage prevention \|Data leakage prevention ]] | New | +| 8.13 | [[ISO_27002_2022_8.13_MoC Information backup \|Information backup ]] | 12.3.1 | +| 8.14 | [[ISO_27002_2022_8.14_MoC Redundancy of information processing facilities \|Redundancy of information processing facilities ]] | 17.2.1 | +| 8.15 | [[ISO_27002_2022_8.15_MoC Logging \|Logging ]] | 12.4.1, 12.4.2, 12.4.3 | +| 8.16 | [[ISO_27002_2022_8.16_MoC Monitoring activities \|Monitoring activities ]] | New | +| 8.17 | [[ISO_27002_2022_8.17_MoC Clock synchronization \|Clock synchronization ]] | 12.4.4 | +| 8.18 | [[ISO_27002_2022_8.18_MoC Use of privileged utility programs \|Use of privileged utility programs ]] | 09.4.4 | +| 8.19 | [[ISO_27002_2022_8.19_MoC Installation of software on operational systems \|Installation of software on operational systems ]] | 12.5.1, 12.6.2 | +| 8.20 | [[ISO_27002_2022_8.20_MoC Networks security \|Networks security ]] | 13.1.1 | +| 8.21 | [[ISO_27002_2022_8.21_MoC Security of network services \|Security of network services ]] | 13.1.2 | +| 8.22 | [[ISO_27002_2022_8.22_MoC Segregation of networks \|Segregation of networks ]] | 13.1.3 | +| 8.23 | [[ISO_27002_2022_8.23_MoC Web filtering \|Web filtering ]] | New | +| 8.24 | [[ISO_27002_2022_8.24_MoC Use of cryptography \|Use of cryptography ]] | 10.1.1, 10.1.2 | +| 8.25 | [[ISO_27002_2022_8.25_MoC Secure development life cycle \|Secure development life cycle ]] | 14.2.1 | +| 8.26 | [[ISO_27002_2022_8.26_MoC Application security requirements \|Application security requirements ]] | 14.1.2, 14.1.3 | +| 8.27 | [[ISO_27002_2022_8.27_MoC Secure system architecture and engineering principles \|Secure system architecture and engineering principles ]] | 14.2.5 | +| 8.28 | [[ISO_27002_2022_8.28_MoC Secure coding \|Secure coding ]] | New | +| 8.29 | [[ISO_27002_2022_8.29_MoC Security testing in development and acceptance \|Security testing in development and acceptance ]] | 14.2.8, 14.2.9 | +| 8.30 | [[ISO_27002_2022_8.30_MoC Outsourced development \|Outsourced development ]] | 14.2.7 | +| 8.31 | [[ISO_27002_2022_8.31_MoC Separation of development, test and production environments \|Separation of development, test and production environments ]] | 12.1.4, 14.2.6 | +| 8.32 | [[ISO_27002_2022_8.32_MoC Change management \|Change management ]] | 12.1.2, 14.2.2, 14.2.3, 14.2.4 | +| 8.33 | [[ISO_27002_2022_8.33_MoC Test information \|Test information ]] | 14.3.1 | +| 8.34 | [[ISO_27002_2022_8.34_MoC Protection of information systems during audit testing \|Protection of information systems during audit testing ]] | 12.7.1 | diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_00_MoC Index.md b/Corpus/Standards/MoCs/ISO_27001_2022_00_MoC Index.md new file mode 100644 index 0000000..d4c3fe5 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_00_MoC Index.md @@ -0,0 +1,52 @@ +#iso27001/2022/EN +# ISO 27001:2022 EN Index + +| Clause | Title | +| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| **F** | **[[ISO_27001_OT F Foreword\|Foreword]]** | +| **0** | **[[ISO_27001_2022_OT 0 Introduction\|Introduction]]** | +| **1** | **[[ISO_27001_2022_OT 1 Scope\|Scope]]** | +| **2** | **[[ISO_27001_2022_OT 2 Normative references\|Normative references]]** | +| **3** | **[[ISO_27001_OT Terms and definitions\|Terms and definitions]]** | +| **4** | **[[ISO_27001_2022_4_MoC Context of the organization\|Context of the organization]]** | +| 4.1 | [[ISO_27001_2022_4.1_MoC Understanding the organization and its context \|Understanding the organization and its context ]] | +| 4.2 | [[ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties \|Understanding the needs and expectations of interested parties ]] | +| 4.3 | [[ISO_27001_2022_4.3_MoC Determining the scope of the information security management system \|Determining the scope of the information security management system ]] | +| 4.4 | [[ISO_27001_2022_4.4_MoC Information security management system \|Information security management system ]] | +| **5** | **[[ISO_27001_2022_5_MoC Leadership\|Leadership]]** | +| 5.1 | [[ISO_27001_2022_5.1_MoC Leadership and commitment \|Leadership and commitment ]] | +| 5.2 | [[ISO_27001_2022_5.2_MoC Policy \|Policy ]] | +| 5.3 | [[ISO_27001_2022_5.3_MoC Organizational roles, responsibilities and authorities \|Organizational roles, responsibilities and authorities ]] | +| **6** | **[[ISO_27001_2022_6_MoC Planning\|Planning]]** | +| 6.1 | [[ISO_27001_2022_6.1_MoC Actions to address risks and opportunities \|Actions to address risks and opportunities ]] | +| 6.1.1 | [[ISO_27001_2022_6.1.1_MoC General\|General ]] | +| 6.1.2 | [[ISO_27001_2022_6.1.2_MoC Information security risk assessment\|Information security risk assessment ]] | +| 6.1.3 | [[ISO_27001_2022_6.1.3_MoC Information security risk treatment\|Information security risk treatment ]] | +| 6.2 | [[ISO_27001_2022_6.2_MoC Information security objectives and planning to achieve them \|Information security objectives and planning to achieve them ]] | +| 6.3 | [[ISO_27001_2022_6.3_MoC Planning of changes \|Planning of changes ]] | +| **7** | **[[ISO_27001_2022_7_MoC Support\|Support]]** | +| 7.1 | [[ISO_27001_2022_7.1_MoC Resources \| Resources ]] | +| 7.2 | [[ISO_27001_2022_7.2_MoC Competence \| Competence ]] | +| 7.3 | [[ISO_27001_2022_7.3_MoC Awareness \| Awareness ]] | +| 7.4 | [[ISO_27001_2022_7.4_MoC Communication \| Communication ]] | +| 7.5 | [[ISO_27001_2022_7.5_MoC Documented information \| Documented information ]] | +| 7.5.1 | General ↑ | +| 7.5.2 | Creating and updating ↑ | +| 7.5.3 | Control of documented information ↑ | +| **8** | **[[ISO_27001_2022_8_MoC Operation\|Operation]]** | +| 8.1 | [[ISO_27001_2022_8.1_MoC Operational planning and control \|Operational planning and control ]] | +| 8.2 | [[ISO_27001_2022_8.2_MoC Information security risk assessment \|Information security risk assessment ]] | +| 8.3 | [[ISO_27001_2022_8.3_MoC Information security risk treatment \|Information security risk treatment ]] | +| **9** | **[[ISO_27001_2022_9_MoC Performance evaluation\|Performance evaluation]]** | +| 9.1 | [[ISO_27001_2022_9.1_MoC Monitoring, measurement, analysis and evaluation \|Monitoring, measurement, analysis and evaluation ]] | +| 9.2 | [[ISO_27001_2022_9.2_MoC Internal audit \|Internal audit ]] | +| 9.2.1 | General ↑ | +| 9.2.2 | Internal audit programme ↑ | +| 9.3 | [[ISO_27001_2022_9.3_MoC Management review \|Management review ]] | +| 9.3.1 | General ↑ | +| 9.3.2 | Management review inputs ↑ | +| 9.3.3 | Management review results ↑ | +| **10** | **[[ISO_27001_2022_10_MoC Improvement\|Improvement]]** | +| 10.1 | [[ISO_27001_2022_10.1_MoC Continual improvement \|Continual improvement ]] | +| 10.2 | [[ISO_27001_2022_10.2_MoC Nonconformity and corrective action \|Nonconformity and corrective action ]] | +| **[[ISO_27001_2022_00_MoC Index EXT\|Annex A]]** | **Information security controls reference** | diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_10.1_MoC Continual improvement.md b/Corpus/Standards/MoCs/ISO_27001_2022_10.1_MoC Continual improvement.md new file mode 100644 index 0000000..eadbba7 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_10.1_MoC Continual improvement.md @@ -0,0 +1,3 @@ +[[ISO_27001_OT 10.1 Continual improvement\|Original Text]] + +[[ISO_27001_PE 10.1 Continual improvement\|Plain English]] diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_10.2_MoC Nonconformity and corrective action.md b/Corpus/Standards/MoCs/ISO_27001_2022_10.2_MoC Nonconformity and corrective action.md new file mode 100644 index 0000000..705ecdc --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_10.2_MoC Nonconformity and corrective action.md @@ -0,0 +1,3 @@ +[[ISO_27001_OT 10.2 Nonconformity and corrective action\|Original Text]] + +[[ISO_27001_PE 10.2 Nonconformity and corrective action\|Plain English]] diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_10_MoC Improvement.md b/Corpus/Standards/MoCs/ISO_27001_2022_10_MoC Improvement.md new file mode 100644 index 0000000..7b82459 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_10_MoC Improvement.md @@ -0,0 +1,6 @@ +# Chapter 10: Improvement + +| **10** | **[[ISO_27001_2022_10_MoC Improvement\|Improvement]]** | +| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 10.1 | [[ISO_27001_2022_10.1_MoC Continual improvement \|Continual improvement ]] | +| 10.2 | [[ISO_27001_2022_10.2_MoC Nonconformity and corrective action \|Nonconformity and corrective action ]] | diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_4.1_MoC Understanding the organization and its context.md b/Corpus/Standards/MoCs/ISO_27001_2022_4.1_MoC Understanding the organization and its context.md new file mode 100644 index 0000000..1a501da --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_4.1_MoC Understanding the organization and its context.md @@ -0,0 +1,20 @@ +# About C4.1: Understanding the organization and its context +From ISO 27001:2022 + +[[ISO_27001_2022_OT 4.1 Understanding the organization and its context\|Original Text]] + +[[ISO_27001_2022_PE 4.1 Understanding the organization and its context\|Plain English]] translation + + + + + + + + + + + + + + diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties.md b/Corpus/Standards/MoCs/ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties.md new file mode 100644 index 0000000..2b7697c --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties.md @@ -0,0 +1,8 @@ +# About C4.2: Understanding the needs and expectations of interested parties + +[[ISO_27001_2022_OT 4.2 Understanding the needs and expectations of interested parties\|Original Text]] + +[[ISO_27001_PE 4.2 Understanding the needs and expectations of interested parties\|Plain English]] + + +[[PECB 27001 LA S05 E01a - Context of the organization|PECB Auditor training: Context of the organization]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_4.3_MoC Determining the scope of the information security management system.md b/Corpus/Standards/MoCs/ISO_27001_2022_4.3_MoC Determining the scope of the information security management system.md new file mode 100644 index 0000000..9034cf7 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_4.3_MoC Determining the scope of the information security management system.md @@ -0,0 +1,9 @@ +# About C4.3 Determining the scope of the information security management system + +[[ISO_27001_2022_OT 4.3 Determining the scope of the information security management system\|Original Text]] + +[[ISO_27001_PE 4.3 Determining the scope of the information security management system\|Plain English]] + +[[About the Statement of Applicability]] + +[[PECB 27001 LA S05 E01a - Context of the organization|PECB Auditor training: Context of the organization]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_4.4_MoC Information security management system.md b/Corpus/Standards/MoCs/ISO_27001_2022_4.4_MoC Information security management system.md new file mode 100644 index 0000000..87cdef7 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_4.4_MoC Information security management system.md @@ -0,0 +1,7 @@ +# About C4.4: Information security management system + +[[ISO_27001_2022_OT 4.4 Information security management system\|Original Text]] + +[[ISO_27001_PE 4.4 Information security management system\|Plain English]] + +[[PECB 27001 LA S05 E01a - Context of the organization|PECB Auditor training: Context of the organization]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_4_MoC Context of the organization.md b/Corpus/Standards/MoCs/ISO_27001_2022_4_MoC Context of the organization.md new file mode 100644 index 0000000..cff60ef --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_4_MoC Context of the organization.md @@ -0,0 +1,8 @@ +# Chapter 4: Context of the organization + +| **4** | **Context of the organization** | +| ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 4.1 | [[ISO_27001_2022_4.1_MoC Understanding the organization and its context \|Understanding the organization and its context ]] | +| 4.2 | [[ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties \|Understanding the needs and expectations of interested parties ]] | +| 4.3 | [[ISO_27001_2022_4.3_MoC Determining the scope of the information security management system \|Determining the scope of the information security management system ]] | +| 4.4 | [[ISO_27001_2022_4.4_MoC Information security management system \|Information security management system ]] | diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_5.1_MoC Leadership and commitment.md b/Corpus/Standards/MoCs/ISO_27001_2022_5.1_MoC Leadership and commitment.md new file mode 100644 index 0000000..4a81bda --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_5.1_MoC Leadership and commitment.md @@ -0,0 +1,10 @@ +# About Clause 5.1: Leadership and commitment + +Describes the responsibilities of 'Top management' with regards to the ISMS. + +[[ISO_27001_2022_OT 5.1 Leadership and commitment\|Original Text]] + +[[ISO_27001_PE 5.1 Leadership and commitment\|Plain English]] + +Related: +- [[ISO_27001_2022_9.3_MoC Management review|Clause 9.3]], Management review diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_5.2_MoC Policy.md b/Corpus/Standards/MoCs/ISO_27001_2022_5.2_MoC Policy.md new file mode 100644 index 0000000..10224b7 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_5.2_MoC Policy.md @@ -0,0 +1,10 @@ +# About Clause 5.2: Policy + +The information security policy as established by top management + +[[ISO_27001_2022_OT 5.2 Policy\|Original Text]] + +[[ISO_27001_PE 5.2 Policy\|Plain English]] + +[[PECB 27001 LA S05 E01b - Leadership|PECB Auditor training: Leadership]] + diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_5.3_MoC Organizational roles, responsibilities and authorities.md b/Corpus/Standards/MoCs/ISO_27001_2022_5.3_MoC Organizational roles, responsibilities and authorities.md new file mode 100644 index 0000000..3e4692e --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_5.3_MoC Organizational roles, responsibilities and authorities.md @@ -0,0 +1,15 @@ +# About Clause 5.3: Organizational roles, responsibilities and authorities + +Top management must make sure that responsibilities and authorities for information security roles are assigned and communicated within the organization. + +Top management specifically needs to assign responsibility and authority for ensuring the ISMS's compliance with the standard, and for reporting[^1] on it's performance (apparently, assigning *other* responsibilities and authorities need *not* be a top management concern). + +[[ISO_27001_2022_OT 5.3 Organizational roles, responsibilities and authorities\|Original Text]] + +[[ISO_27001_PE 5.3 Organizational roles, responsibilities and authorities\|Plain English]] + +[[PECB 27001 LA S05 E01b - Leadership|PECB Auditor training: Leadership]] + + + +[^1]: Note that 'reporting' (5.3b) means carrying responsibility and being accountable (for the performance of the ISMS), not just giving information. diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_5_MoC Leadership.md b/Corpus/Standards/MoCs/ISO_27001_2022_5_MoC Leadership.md new file mode 100644 index 0000000..daae68b --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_5_MoC Leadership.md @@ -0,0 +1,11 @@ +# Chapter 5: Leadership + +| **5** | **[[ISO_27001_2022_5_MoC Leadership\|Leadership]]** | +| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 5.1 | [[ISO_27001_2022_5.1_MoC Leadership and commitment \|Leadership and commitment ]] | +| 5.2 | [[ISO_27001_2022_5.2_MoC Policy \|Policy ]] | +| 5.3 | [[ISO_27001_2022_5.3_MoC Organizational roles, responsibilities and authorities \|Organizational roles, responsibilities and authorities ]] | + +[[PECB 27001 LA S05 E01a - Context of the organization|Context of the organization]] from the PECB Auditor training +[[PECB 27001 LA S05 E01b - Leadership|Leadership]] from the PECB Auditor training + diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_6.1.1_MoC General.md b/Corpus/Standards/MoCs/ISO_27001_2022_6.1.1_MoC General.md new file mode 100644 index 0000000..3396b97 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_6.1.1_MoC General.md @@ -0,0 +1,4 @@ +### 6.1.1 General + +- [[ISO_27001_OT 6.1.1 General\|Original Text]] +- [[ISO_27001_PE 6.1.1 General\|Plain English]] diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_6.1.2_MoC Information security risk assessment.md b/Corpus/Standards/MoCs/ISO_27001_2022_6.1.2_MoC Information security risk assessment.md new file mode 100644 index 0000000..348bbcf --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_6.1.2_MoC Information security risk assessment.md @@ -0,0 +1,42 @@ +# About Clause 6.1.2: I| **6** | **[[ISO_27001_2022_6_MoC Planning\|Planning]]** | +| ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 6.1 | [[ISO_27001_2022_6.1_MoC Actions to address risks and opportunities \|Actions to address risks and opportunities ]] | +| 6.1.1 | [[ISO_27001_2022_6.1.1_MoC General\|General ]] | +| 6.1.2 | [[ISO_27001_2022_6.1.2_MoC Information security risk assessment\|Information security risk assessment ]] | +| 6.1.3 | [[ISO_27001_2022_6.1.3_MoC Information security risk treatment\|Information security risk treatment ]] | +| 6.2 | [[ISO_27001_2022_6.2_MoC Information security objectives and planning to achieve them \|Information security objectives and planning to achieve them ]] | +| 6.3 | [[ISO_27001_2022_6.3_MoC Planning of changes \|Planning of changes ]] |rity investments will deliver the most value. This is in line with the ISO 31000 standard for Risk Management #research title? , which recommends categorizing risks based on your organization’s context and objectives. + +Different organizations worry about different kinds of risks, based on their mission, industry, and stakeholder expectations. An engineering firm may worry about their designs being stolen (protection of intellectual property) and construction errors due to incorrect data or calculations (integrity of information). A hospital will worry about continuity (availability of information) and patient confidentiality. A social media advertising platform, may care less about compliance with privacy regulations, but place great emphasis on uptime of systems. + +To help in this dialogue about risks and risk tolerance, we can use the concept of 'Impact Categories'. +## Impact Categories +Impact Categories are the types of business consequences that matter most to an organization's leadership, because they affect the organization's ability to achieve its objectives. + +Below is a list of examples of Impact Categories: + +- **Operational**: Disruption of day-to-day processes, workforce capability, system functionality, and the organization's ability to deliver products or services +- **Financial**: Direct financial losses, increased costs, reduced revenue, market value decline, or threats to financial stability +- **Strategic**: Inability to achieve long-level organizational goals, loss of competitive position, or forced changes to business direction +- **Compliance**: Legal penalties, regulatory sanctions, loss of licenses or certifications, or mandatory remediation costs +- **Reputational**: Loss of customer trust, damage to brand value, negative media attention, or erosion of stakeholder confidence +- **Health and Safety**: Physical harm to employees, customers, or the public, or creation of unsafe conditions +- **Environmental**: Environmental damage, pollution incidents, or failure to meet sustainability commitments +- **Competitive Advantage**: Loss of proprietary knowledge, patents, trade secrets, or strategic business intelligence +- **National Security**: Consequences for critical infrastructure, public safety, or national interests + +You can expand and adapt this list as you see fit. Engage your management in a dialogue about areas of impact, and aim to establish the categories that are most important to them. This will help in weighing priorities later on. + +## qualifying or quantifying risks? + +**Qualifying risks** (qualitative risk assessment) involves describing and categorizing risks using descriptive scales or labels—such as rating likelihood as "low, medium, high" and impact as "minor, moderate, severe"—focusing on understanding the nature and relative severity of risks without precise numerical values. + +**Quantifying risks** (quantitative risk assessment) involves measuring risks using specific numerical values—such as calculating the probability as a percentage (e.g., 15% chance per year) and impact in monetary terms (e.g., €50,000 loss)—providing precise, measurable data that can be used for detailed cost-benefit analysis and statistical modeling. + +Clause 6.1.2 writes we should "assess the potential consequences" and "realistic likelihood" of risks occurring, but the standard doesn't say anything about *how* these should be established (just that that the chosen method must produce "consistent, valid and comparable results"). + +The core _requirements_ in ISO/IEC 27001 remain method-agnostic as long as the steps above are met and results are consistent and comparable. + +The organization must set its own criteria for determining risk levels and risk acceptance criteria. The organization defines these elements based on its specific needs, size, structure, objectives, and risks. + +The standard does not say anything about if qualitative or quantitative risk assessment should be applied. diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_6.1.3_MoC Information security risk treatment.md b/Corpus/Standards/MoCs/ISO_27001_2022_6.1.3_MoC Information security risk treatment.md new file mode 100644 index 0000000..8a036cc --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_6.1.3_MoC Information security risk treatment.md @@ -0,0 +1,6 @@ +# 6.1.3 Information security risk treatment + +- [[ISO_27001_OT 6.1.3 Information security risk treatment\|Original Text]] +- [[ISO_27001_PE 6.1.3 Information security risk treatment\|Plain English]] + +[[About the Statement of Applicability]] diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_6.1_MoC Actions to address risks and opportunities.md b/Corpus/Standards/MoCs/ISO_27001_2022_6.1_MoC Actions to address risks and opportunities.md new file mode 100644 index 0000000..3c64afe --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_6.1_MoC Actions to address risks and opportunities.md @@ -0,0 +1,7 @@ +## 6.1 Actions to address risks and opportunities + +- [[ISO_27001_2022_6.1.1_MoC General|6.1.1 General]] +- [[ISO_27001_2022_6.1.2_MoC Information security risk assessment|6.1.2 Information security risk assessment]] +- [[ISO_27001_2022_6.1.3_MoC Information security risk treatment|6.1.3 Information security risk treatment]] + + diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_6.2_MoC Information security objectives and planning to achieve them.md b/Corpus/Standards/MoCs/ISO_27001_2022_6.2_MoC Information security objectives and planning to achieve them.md new file mode 100644 index 0000000..0788bdc --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_6.2_MoC Information security objectives and planning to achieve them.md @@ -0,0 +1,4 @@ +# About Chapter 6.2: Information security objectives and planning to achieve them +[[ISO_27001_OT 6.2 Information security objectives and planning to achieve them\|Original Text]] + +[[ISO_27001_PE 6.2 Information security objectives and planning to achieve them\|Plain English]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_6.3_MoC Planning of changes.md b/Corpus/Standards/MoCs/ISO_27001_2022_6.3_MoC Planning of changes.md new file mode 100644 index 0000000..384cb63 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_6.3_MoC Planning of changes.md @@ -0,0 +1,3 @@ +[[ISO_27001_OT 6.3 Planning of changes\|Original Text]] + +[[ISO_27001_PE 6.3 Planning of changes\|Plain English]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_6_MoC Planning.md b/Corpus/Standards/MoCs/ISO_27001_2022_6_MoC Planning.md new file mode 100644 index 0000000..4c1d529 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_6_MoC Planning.md @@ -0,0 +1,10 @@ +# Chapter 6: Planning + +| **6** | **[[ISO_27001_2022_6_MoC Planning\|Planning]]** | +| ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 6.1 | [[ISO_27001_2022_6.1_MoC Actions to address risks and opportunities \|Actions to address risks and opportunities ]] | +| 6.1.1 | [[ISO_27001_2022_6.1.1_MoC General\|General ]] | +| 6.1.2 | [[ISO_27001_2022_6.1.2_MoC Information security risk assessment\|Information security risk assessment ]] | +| 6.1.3 | [[ISO_27001_2022_6.1.3_MoC Information security risk treatment\|Information security risk treatment ]] | +| 6.2 | [[ISO_27001_2022_6.2_MoC Information security objectives and planning to achieve them \|Information security objectives and planning to achieve them ]] | +| 6.3 | [[ISO_27001_2022_6.3_MoC Planning of changes \|Planning of changes ]] | \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_7.1_MoC Resources.md b/Corpus/Standards/MoCs/ISO_27001_2022_7.1_MoC Resources.md new file mode 100644 index 0000000..b15b508 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_7.1_MoC Resources.md @@ -0,0 +1,3 @@ +[[ISO_27001_OT 7.1 Resources\|Original Text]] + +[[ISO_27001_PE 7.1 Resources\|Plain English]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_7.2_MoC Competence.md b/Corpus/Standards/MoCs/ISO_27001_2022_7.2_MoC Competence.md new file mode 100644 index 0000000..b3cd554 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_7.2_MoC Competence.md @@ -0,0 +1,3 @@ +[[ISO_27001_OT 7.2 Competence\|Original Text]] + +[[ISO_27001_PE 7.2 Competence\|Plain English]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_7.3_MoC Awareness.md b/Corpus/Standards/MoCs/ISO_27001_2022_7.3_MoC Awareness.md new file mode 100644 index 0000000..f1a3e8a --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_7.3_MoC Awareness.md @@ -0,0 +1,3 @@ +[[ISO_27001_OT 7.3 Awareness\|Original Text]] + +[[ISO_27001_PE 7.3 Awareness\|Plain English]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_7.4_MoC Communication.md b/Corpus/Standards/MoCs/ISO_27001_2022_7.4_MoC Communication.md new file mode 100644 index 0000000..e1a493c --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_7.4_MoC Communication.md @@ -0,0 +1,3 @@ +[[ISO_27001_OT 7.4 Communication\|Original Text]] + +[[ISO_27001_PE 7.4 Communication\|Plain English]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_7.5.1_MoC General.md b/Corpus/Standards/MoCs/ISO_27001_2022_7.5.1_MoC General.md new file mode 100644 index 0000000..0a1a2b5 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_7.5.1_MoC General.md @@ -0,0 +1,13 @@ +### 7.5.1 General + +The organization's information security management system shall include: + +a\) documented information required by this document; and + +b\) documented information determined by the organization as being necessary for the effectiveness of the information security management system. + +NOTE The extent of documented information for an information security management system can differ from one organization to another due to: + 1\) the size of organization and its type of activities, processes, products and services; + 2\) the complexity of processes and their interactions; and + 3\) the competence of persons. + diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_7.5.2_MoC Creating and updating.md b/Corpus/Standards/MoCs/ISO_27001_2022_7.5.2_MoC Creating and updating.md new file mode 100644 index 0000000..ed7ad11 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_7.5.2_MoC Creating and updating.md @@ -0,0 +1,10 @@ +### 7.5.2 Creating and updating + +When creating and updating documented information the organization shall ensure appropriate: + +a\) identification and description (e.g. a title, date, author, or reference number); + +b\) format (e.g. language, software version, graphics) and media (e.g. paper, electronic); and + +c\) review and approval for suitability and adequacy. + diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_7.5.3_MoC Control of documented information.md b/Corpus/Standards/MoCs/ISO_27001_2022_7.5.3_MoC Control of documented information.md new file mode 100644 index 0000000..9cb117a --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_7.5.3_MoC Control of documented information.md @@ -0,0 +1,21 @@ +### 7.5.3 Control of documented information + +Documented information required by the information security management system and by this document shall be controlled to ensure: + +a\) it is available and suitable for use, where and when it is needed; and + +b\) it is adequately protected (e.g. from loss of confidentiality, improper use, or loss of integrity). + +For the control of documented information, the organization shall address the following activities, as applicable: + +c\) distribution, access, retrieval and use; + +d\) storage and preservation, including the preservation of legibility; + +e\) control of changes (e.g. version control); and + +f\) retention and disposition. + +Documented information of external origin, determined by the organization to be necessary for the planning and operation of the information security management system, shall be identified as appropriate, and controlled. + +NOTE Access can imply a decision regarding the permission to view the documented information only, or the permission and authority to view and change the documented information, etc. \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_7.5_MoC Documented information.md b/Corpus/Standards/MoCs/ISO_27001_2022_7.5_MoC Documented information.md new file mode 100644 index 0000000..984cdda --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_7.5_MoC Documented information.md @@ -0,0 +1,7 @@ +[[ISO_27001_OT 7.5 Documented information\|Original Text]] + +[[ISO_27001_PE 7.5 Documented information\|Plain English]] + +- [[ISO_27001_2022_7.5.1_MoC General|7.5.1 General]] +- [[ISO_27001_2022_7.5.2_MoC Creating and updating|7.5.2 Creating and updating]] +- [[ISO_27001_2022_7.5.3_MoC Control of documented information|7.5.3 Control of documented information]] diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_7_MoC Support.md b/Corpus/Standards/MoCs/ISO_27001_2022_7_MoC Support.md new file mode 100644 index 0000000..1358b10 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_7_MoC Support.md @@ -0,0 +1,12 @@ +# Chapter 7: Support + +| **7** | **[[ISO_27001_2022_7_MoC Support\|Support]]** | +| ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 7.1 | [[ISO_27001_2022_7.1_MoC Resources \| Resources ]] | +| 7.2 | [[ISO_27001_2022_7.2_MoC Competence \| Competence ]] | +| 7.3 | [[ISO_27001_2022_7.3_MoC Awareness \| Awareness ]] | +| 7.4 | [[ISO_27001_2022_7.4_MoC Communication \| Communication ]] | +| 7.5 | [[ISO_27001_2022_7.5_MoC Documented information \| Documented information ]] | +| 7.5.1 | General ↑ | +| 7.5.2 | Creating and updating ↑ | +| 7.5.3 | Control of documented information ↑ | \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_8.1_MoC Operational planning and control.md b/Corpus/Standards/MoCs/ISO_27001_2022_8.1_MoC Operational planning and control.md new file mode 100644 index 0000000..ee1fb4c --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_8.1_MoC Operational planning and control.md @@ -0,0 +1,3 @@ +[[ISO_27001_OT 8.1 Operational planning and control\|Original Text]] + +[[ISO_27001_PE 8.1 Operational planning and control\|Plain English]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_8.2_MoC Information security risk assessment.md b/Corpus/Standards/MoCs/ISO_27001_2022_8.2_MoC Information security risk assessment.md new file mode 100644 index 0000000..b5fc580 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_8.2_MoC Information security risk assessment.md @@ -0,0 +1,6 @@ +# About Clause 8.2: Information security risk assessment + + +[[ISO_27001_OT 8.2 Information security risk assessment\|Original Text]] + +[[ISO_27001_PE 8.2 Information security risk assessment\|Plain English]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_8.3_MoC Information security risk treatment.md b/Corpus/Standards/MoCs/ISO_27001_2022_8.3_MoC Information security risk treatment.md new file mode 100644 index 0000000..c4fcaf1 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_8.3_MoC Information security risk treatment.md @@ -0,0 +1,5 @@ +# About Clause 8.3: Information security risk treatment + +[[ISO_27001_OT 8.3 Information security risk treatment\|Original Text]] + +[[ISO_27001_PE 8.3 Information security risk treatment\|Plain English]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_8_MoC Operation.md b/Corpus/Standards/MoCs/ISO_27001_2022_8_MoC Operation.md new file mode 100644 index 0000000..3dbc80e --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_8_MoC Operation.md @@ -0,0 +1,7 @@ +# Chapter 8: Operation + +| **8** | **[[ISO_27001_2022_8_MoC Operation\|Operation]]** | +| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 8.1 | [[ISO_27001_2022_8.1_MoC Operational planning and control \|Operational planning and control ]] | +| 8.2 | [[ISO_27001_2022_8.2_MoC Information security risk assessment \|Information security risk assessment ]] | +| 8.3 | [[ISO_27001_2022_8.3_MoC Information security risk treatment \|Information security risk treatment ]] | diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_9.1_MoC Monitoring, measurement, analysis and evaluation.md b/Corpus/Standards/MoCs/ISO_27001_2022_9.1_MoC Monitoring, measurement, analysis and evaluation.md new file mode 100644 index 0000000..64d2751 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_9.1_MoC Monitoring, measurement, analysis and evaluation.md @@ -0,0 +1,3 @@ +[[ISO_27001_OT 9.1 Monitoring, measurement, analysis and evaluation\|Original Text]] + +[[ISO_27001_PE 9.1 Monitoring, measurement, analysis and evaluation\|Plain English]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_9.2_MoC Internal audit.md b/Corpus/Standards/MoCs/ISO_27001_2022_9.2_MoC Internal audit.md new file mode 100644 index 0000000..d6bde92 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_9.2_MoC Internal audit.md @@ -0,0 +1,5 @@ +# About Clause 9.2: Internal audit + +[[ISO_27001_OT 9.2 Internal audit\|Original Text]] +[[ISO_27001_PE 9.2 Internal audit\|Plain English]] + diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_9.3_MoC Management review.md b/Corpus/Standards/MoCs/ISO_27001_2022_9.3_MoC Management review.md new file mode 100644 index 0000000..fc87a4e --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_9.3_MoC Management review.md @@ -0,0 +1,5 @@ +# 9.3 Management review + +[[ISO_27001_OT 9.3 Management review\|Original Text]] +[[ISO_27001_PE 9.3 Management review\|Plain English]] + diff --git a/Corpus/Standards/MoCs/ISO_27001_2022_9_MoC Performance evaluation.md b/Corpus/Standards/MoCs/ISO_27001_2022_9_MoC Performance evaluation.md new file mode 100644 index 0000000..9f83640 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27001_2022_9_MoC Performance evaluation.md @@ -0,0 +1,12 @@ +# Chapter 9: Performance evaluation + +| **9** | **[[ISO_27001_2022_9_MoC Performance evaluation\|Performance evaluation]]** | +| ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 9.1 | [[ISO_27001_2022_9.1_MoC Monitoring, measurement, analysis and evaluation \|Monitoring, measurement, analysis and evaluation ]] | +| 9.2 | [[ISO_27001_2022_9.2_MoC Internal audit \|Internal audit ]] | +| 9.2.1 | General ↑ | +| 9.2.2 | Internal audit programme ↑ | +| 9.3 | [[ISO_27001_2022_9.3_MoC Management review \|Management review ]] | +| 9.3.1 | General ↑ | +| 9.3.2 | Management review inputs ↑ | +| 9.3.3 | Management review results ↑ | \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_00_Controls_enumeration_list.md b/Corpus/Standards/MoCs/ISO_27002_2022_00_Controls_enumeration_list.md new file mode 100644 index 0000000..5792e80 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_00_Controls_enumeration_list.md @@ -0,0 +1,94 @@ +#iso27002/2022/EN +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 +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 +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 +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 backup +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 \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.10_MoC Acceptable use of information and other associated assets.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.10_MoC Acceptable use of information and other associated assets.md new file mode 100644 index 0000000..4f5d685 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.10_MoC Acceptable use of information and other associated assets.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_5.10_OT Acceptable use of information and other associated assets \|Original Text]] +[[ISO_27002_2022_5.10_PE Acceptable use of information and other associated assets \|Plain English]] +ISO 27002:2013: 08.1.3, 08.2.3 + +[[ISO_27002_2022_NL_5.10_BT Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.11_MoC Return of assets.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.11_MoC Return of assets.md new file mode 100644 index 0000000..d035712 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.11_MoC Return of assets.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_5.11_OT Return of assets \|Original Text]] +[[ISO_27002_2022_5.11_PE Return of assets \|Plain English]] +ISO 27002:2013: 08.1.4 + +[[ISO_27002_2022_NL_5.11_BT Retourneren van bedrijfsmiddelen \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.12_MoC Classification of information.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.12_MoC Classification of information.md new file mode 100644 index 0000000..4750c9b --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.12_MoC Classification of information.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_5.12_OT Classification of information \|Original Text]] +[[ISO_27002_2022_5.12_PE Classification of information \|Plain English]] +ISO 27002:2013: 08.2.1 + +[[ISO_27002_2022_NL_5.12_BT Classificeren van informatie \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.13_MoC Labelling of information.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.13_MoC Labelling of information.md new file mode 100644 index 0000000..bd0ef9c --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.13_MoC Labelling of information.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_5.13_OT Labelling of information \|Original Text]] +[[ISO_27002_2022_5.13_PE Labelling of information \|Plain English]] +ISO 27002:2013: 08.2.2 + +[[ISO_27002_2022_NL_5.13_BT Labelen van informatie \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.14_MoC Information transfer.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.14_MoC Information transfer.md new file mode 100644 index 0000000..3f138b2 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.14_MoC Information transfer.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_5.14_OT Information transfer \|Original Text]] +[[ISO_27002_2022_5.14_PE Information transfer \|Plain English]] +ISO 27002:2013: 13.2.1, 13.2.2, 13.2.3 + +[[ISO_27002_2022_NL_5.14_BT Overdragen van informatie \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.15_MoC Access control.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.15_MoC Access control.md new file mode 100644 index 0000000..319ad8e --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.15_MoC Access control.md @@ -0,0 +1,7 @@ +# About Control 5.15: Access control + +Foundational rules and principles to control access to information assets, in line with business and information security requirements. + +[[ISO_27002_2022_5.15_OT Access control \|Original Text]] +[[ISO_27002_2022_5.15_PE Access control \|Plain English]] +ISO 27002:2013: 09.1.1, 09.1.2 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.16_MoC Identity management.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.16_MoC Identity management.md new file mode 100644 index 0000000..76eba10 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.16_MoC Identity management.md @@ -0,0 +1,9 @@ +# About Control 5.16: Identity management + +Identity life cycle management. + +[[ISO_27002_2022_5.16_OT Identity management \|Original Text]] +[[ISO_27002_2022_5.16_PE Identity management \|Plain English]] +ISO 27002:2013: 09.2.1 + +[[ISO_27002_2022_NL_5.16_BT Identiteitsbeheer \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.17_MoC Authentication information.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.17_MoC Authentication information.md new file mode 100644 index 0000000..dbeb373 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.17_MoC Authentication information.md @@ -0,0 +1,22 @@ +# About Control 5.17: Authentication information + +Managing authentication information, including advising personnel on how to handle authentication information. + +[[ISO_27002_2022_5.17_OT Authentication information \|Original Text]] +[[ISO_27002_2022_5.17_PE Authentication information \|Plain English]] +ISO 27002:2013: 09.2.4, 09.3.1, 09.4.3 + +[[ISO_27002_2022_NL_5.17_BT Beheren van authenticatie-informatie \|Brontekst]] +[[ISO_27002_2022_NL_5.17_NN Beheren van authenticatie-informatie \|Normaal Nederlands]] + + + +[[Sterke wachtwoorden in 2024]] + +**NCSC over authenticeren** +- [Authenticatie als onderdeel van Digitale Weerbaarheid](https://www.ncsc.nl/wat-kun-je-zelf-doen/weerbaarheid/beschermen/authenticatie) +- [[NCSC Infosheet Volwassen Authenticeren]] +- [[NCSC_Factsheet_Volwassen_Authenticeren]] +- [[NCSC Factsheet Gebruik Tweefactorauthenticatie]] +- [Choosing the right type](https://www.ncsc.gov.uk/guidance/authentication-methods-choosing-the-right-type) + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.18_MoC Access rights.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.18_MoC Access rights.md new file mode 100644 index 0000000..a84e486 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.18_MoC Access rights.md @@ -0,0 +1,9 @@ +# About Control 5.18: Access rights + +Access rights management procedures (provisioning, review, modification and removal) in line with business rules for access control (from [[ISO_27002_2022_5.15_MoC Access control|A5.15]]). + +[[ISO_27002_2022_5.18_OT Access rights \|Original Text]] +[[ISO_27002_2022_5.18_PE Access rights \|Plain English]] +ISO 27002:2013: 09.2.2, 09.2.5, 09.2.6 + +[[ISO_27002_2022_NL_5.18_BT Toegangsrechten \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.19_MoC Information security in supplier relationships.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.19_MoC Information security in supplier relationships.md new file mode 100644 index 0000000..0adf6d9 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.19_MoC Information security in supplier relationships.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_5.19_OT Information security in supplier relationships \|Original Text]] +[[ISO_27002_2022_5.19_PE Information security in supplier relationships \|Plain English]] +ISO 27002:2013: 15.1.1 + +[[ISO_27002_2022_NL_5.19_BT Informatiebeveiliging in leveranciersrelaties \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.20_MoC Addressing information security within supplier agreements.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.20_MoC Addressing information security within supplier agreements.md new file mode 100644 index 0000000..57eabcd --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.20_MoC Addressing information security within supplier agreements.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_5.20_OT Addressing information security within supplier agreements \|Original Text]] +[[ISO_27002_2022_5.20_PE Addressing information security within supplier agreements \|Plain English]] +ISO 27002:2013: 15.1.2 + +[[ISO_27002_2022_NL_5.20_BT Adresseren van informatiebeveiliging in leveranciersovereenkomsten \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.21_MoC Managing information security in the ICT supply chain.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.21_MoC Managing information security in the ICT supply chain.md new file mode 100644 index 0000000..1114e47 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.21_MoC Managing information security in the ICT supply chain.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain \|Original Text]] +[[ISO_27002_2022_5.21_PE Managing information security in the ICT supply chain \|Plain English]] +ISO 27002:2013: 15.1.3 + +[[ISO_27002_2022_NL_5.21_BT Beheren van informatiebeveiliging in de ICT-keten \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.22_MoC Monitoring, review and change management of supplier services.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.22_MoC Monitoring, review and change management of supplier services.md new file mode 100644 index 0000000..9531f58 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.22_MoC Monitoring, review and change management of supplier services.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services \|Original Text]] +[[ISO_27002_2022_5.22_PE Monitoring, review and change management of supplier services \|Plain English]] +ISO 27002:2013: 15.2.1, 15.2.2 + +[[ISO_27002_2022_NL_5.22_BT Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.23_MoC Information security for use of cloud services.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.23_MoC Information security for use of cloud services.md new file mode 100644 index 0000000..fb02bc9 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.23_MoC Information security for use of cloud services.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_5.23_OT Information security for use of cloud services \|Original Text]] +[[ISO_27002_2022_5.23_PE Information security for use of cloud services \|Plain English]] +ISO 27002:2013: n/a + +[[ISO_27002_2022_NL_5.23_BT Informatiebeveiliging voor het gebruik van clouddiensten \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.24_MoC Information security incident management planning and preparation.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.24_MoC Information security incident management planning and preparation.md new file mode 100644 index 0000000..a3c2723 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.24_MoC Information security incident management planning and preparation.md @@ -0,0 +1,5 @@ +# About Control 5.24: Information security incident management planning and preparation + +[[ISO_27002_2022_5.24_OT Information security incident management planning and preparation \|Original Text]] +[[ISO_27002_2022_5.24_PE Information security incident management planning and preparation \|Plain English]] +ISO 27002:2013: 16.1.1 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.25_MoC Assessment and decision on information security events.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.25_MoC Assessment and decision on information security events.md new file mode 100644 index 0000000..a5219c0 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.25_MoC Assessment and decision on information security events.md @@ -0,0 +1,5 @@ +# About Control 5.25: Assessment and decision on information security events + +[[ISO_27002_2022_5.25_OT Assessment and decision on information security events |Original Text]] +[[ISO_27002_2022_5.25_PE Assessment and decision on information security events \|Plain English]] +ISO 27002:2013: 16.1.4 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.26_MoC Response to information security incidents.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.26_MoC Response to information security incidents.md new file mode 100644 index 0000000..f72cd0b --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.26_MoC Response to information security incidents.md @@ -0,0 +1,5 @@ +# About Control 5.26: Response to information security incidents + +[[ISO_27002_2022_5.26_OT Response to information security incidents \|Original Text]] +[[ISO_27002_2022_5.26_PE Response to information security incidents \|Plain English]] +ISO 27002:2013: 16.1.5 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.27_MoC Learning from information security incidents.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.27_MoC Learning from information security incidents.md new file mode 100644 index 0000000..b38faa6 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.27_MoC Learning from information security incidents.md @@ -0,0 +1,5 @@ +# About Control 5.27: Learning from information security incidents + +[[ISO_27002_2022_5.27_OT Learning from information security incidents \|Original Text]] +[[ISO_27002_2022_5.27_PE Learning from information security incidents \|Plain English]] +ISO 27002:2013: 16.1.6 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.28_MoC Collection of evidence.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.28_MoC Collection of evidence.md new file mode 100644 index 0000000..c1fef48 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.28_MoC Collection of evidence.md @@ -0,0 +1,6 @@ +# About Control 5.28: Collection of evidence + +[[ISO_27002_2022_5.28_OT Collection of evidence \|Original Text]] +[[ISO_27002_2022_5.28_PE Collection of evidence \|Plain English]] +ISO 27002:2013: 16.1.7 + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.29_MoC Information security during disruption.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.29_MoC Information security during disruption.md new file mode 100644 index 0000000..cdd2c93 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.29_MoC Information security during disruption.md @@ -0,0 +1,8 @@ +# About Control 5.29: Information security during disruption + +[[ISO_27002_2022_5.29_OT Information security during disruption \|Original Text]] +[[ISO_27002_2022_5.29_PE Information security during disruption \|Plain English]] +ISO 27002:2013: 17.1.1, 17.1.2, 17.1.3 + +[[Business Impact Analysis (BIA)]] + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.2_MoC Information security roles and responsibilities.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.2_MoC Information security roles and responsibilities.md new file mode 100644 index 0000000..8342bb6 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.2_MoC Information security roles and responsibilities.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_5.2_OT Information security roles and responsibilities \|Original Text]] +[[ISO_27002_2022_5.2_PE Information security roles and responsibilities \|Plain English]] +ISO 27002:2013: 06.1.1 + +[[ISO_27002_2022_NL_5.2_BT Rollen en verantwoordelijkheden bij informatiebeveiliging \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.30_MoC ICT readiness for business continuity.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.30_MoC ICT readiness for business continuity.md new file mode 100644 index 0000000..3173e51 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.30_MoC ICT readiness for business continuity.md @@ -0,0 +1,12 @@ +[[ISO_27002_2022_5.30_OT ICT readiness for business continuity \|Original Text]] +[[ISO_27002_2022_5.30_PE ICT readiness for business continuity \|Plain English]] +ISO 27002:2013: n/a + +[[ISO_27002_2022_NL_5.30_BT ICT-gereedheid voor bedrijfscontinuïteit \|Brontekst]] + + +See also: +- [[BCP_Bedrijfscontinuïteitsplanning]] +- [[Business Impact Analysis (BIA)]] +- [[Disaster Recovery Planning]] + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.31_MoC Legal, statutory, regulatory and contractual requirements.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.31_MoC Legal, statutory, regulatory and contractual requirements.md new file mode 100644 index 0000000..98d4d90 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.31_MoC Legal, statutory, regulatory and contractual requirements.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_5.31_OT Legal, statutory, regulatory and contractual requirements \|Original Text]] +[[ISO_27002_2022_5.31_PE Legal, statutory, regulatory and contractual requirements \|Plain English]] +ISO 27002:2013: 18.1.1, 18.1.5 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.32_MoC Intellectual property rights.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.32_MoC Intellectual property rights.md new file mode 100644 index 0000000..03993d7 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.32_MoC Intellectual property rights.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_5.32_OT Intellectual property rights \|Original Text]] +[[ISO_27002_2022_5.32_PE Intellectual property rights \|Plain English]] +ISO 27002:2013: 18.1.2 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.33_MoC Protection of records.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.33_MoC Protection of records.md new file mode 100644 index 0000000..3d59d27 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.33_MoC Protection of records.md @@ -0,0 +1,9 @@ +# About 5.33: Protection of records + +This Control is about the **control, purpose, and guidance for managing and protecting organizational records** to ensure their authenticity, integrity, availability, and compliance with various requirements over time. + +I would say: record keeping procedures, in line with legal and other requirements. + +[[ISO_27002_2022_5.33_OT Protection of records \|Original Text]] +[[ISO_27002_2022_5.33_PE Protection of records \|Plain English]] +ISO 27002:2013: 18.1.3 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.34_MoC Privacy and protection of PII.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.34_MoC Privacy and protection of PII.md new file mode 100644 index 0000000..f6ee070 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.34_MoC Privacy and protection of PII.md @@ -0,0 +1,4 @@ + +[[ISO_27002_2022_5.34_OT Privacy and protection of PII \|Original Text]] +[[ISO_27002_2022_5.34_PE Privacy and protection of PII \|Plain English]] +ISO 27002:2013: 18.1.4 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.35_MoC Independent review of information security.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.35_MoC Independent review of information security.md new file mode 100644 index 0000000..b24815f --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.35_MoC Independent review of information security.md @@ -0,0 +1,6 @@ +# About Control 5.35: Independent review of information security + +[[ISO_27002_2022_5.35_OT Independent review of information security \|Original Text]] +[[ISO_27002_2022_5.35_PE Independent review of information security \|Plain English]] + +ISO 27002:2013: 18.2.1 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.36_MoC Compliance with policies, rules and standards for information security.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.36_MoC Compliance with policies, rules and standards for information security.md new file mode 100644 index 0000000..8dacff1 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.36_MoC Compliance with policies, rules and standards for information security.md @@ -0,0 +1,5 @@ +# About Control 5.36: Compliance with policies, rules and standards for information security + +[[ISO_27002_2022_5.36_OT Compliance with policies, rules and standards for information security \|Original Text]] +[[ISO_27002_2022_5.36_PE Compliance with policies, rules and standards for information security \|Plain English]] +ISO 27002:2013: 18.2.2, 18.2.3 \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.37_MoC Documented operating procedures.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.37_MoC Documented operating procedures.md new file mode 100644 index 0000000..51170bd --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.37_MoC Documented operating procedures.md @@ -0,0 +1,6 @@ +[[ISO_27002_2022_5.37_OT Documented operating procedures \|Original Text]] +  +[[ISO_27002_2022_5.37_PE Documented operating procedures \|Plain English]] +ISO 27002:2013: 12.1.1 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.3_MoC Segregation of duties.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.3_MoC Segregation of duties.md new file mode 100644 index 0000000..858050e --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.3_MoC Segregation of duties.md @@ -0,0 +1,7 @@ +# About Control 5.3: Segregation of duties + +[[ISO_27002_2022_5.3_OT Segregation of duties \|Original Text]] +[[ISO_27002_2022_5.3_PE Segregation of duties \|Plain English]] +ISO 27002:2013: 06.1.2 + +[[ISO_27002_2022_NL_5.3_BT Functiescheiding \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.4_MoC Management responsibilities.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.4_MoC Management responsibilities.md new file mode 100644 index 0000000..ee5cc33 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.4_MoC Management responsibilities.md @@ -0,0 +1,7 @@ +# About Control 5.4: Management responsibilities + +[[ISO_27002_2022_5.4_OT Management responsibilities \|Original Text]] +[[ISO_27002_2022_5.4_PE Management responsibilities \|Plain English]] +ISO 27002:2013: 07.2.1 + +[[ISO_27002_2022_NL_5.4_BT Managementverantwoordelijkheden \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.5_MoC Contact with authorities.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.5_MoC Contact with authorities.md new file mode 100644 index 0000000..e183cf8 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.5_MoC Contact with authorities.md @@ -0,0 +1,7 @@ +# About Control 5.5: Contact with authorities + +[[ISO_27002_2022_5.5_OT Contact with authorities \|Original Text]] +[[ISO_27002_2022_5.5_PE Contact with authorities \|Plain English]] +ISO 27002:2013: 06.1.3 + +[[ISO_27002_2022_NL_5.5_BT Contact met overheidsinstanties \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.6_MoC Contact with special interest groups.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.6_MoC Contact with special interest groups.md new file mode 100644 index 0000000..1138991 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.6_MoC Contact with special interest groups.md @@ -0,0 +1,7 @@ +# About Control 5.6: Contact with special interest groups + +[[ISO_27002_2022_5.6_OT Contact with special interest groups \|Original Text]] +[[ISO_27002_2022_5.6_PE Contact with special interest groups \|Plain English]] +ISO 27002:2013: 6.1.4 + +[[ISO_27002_2022_NL_5.6_BT Contact met speciale belangengroepen \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.7_MoC Threat intelligence.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.7_MoC Threat intelligence.md new file mode 100644 index 0000000..9e9ac2b --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.7_MoC Threat intelligence.md @@ -0,0 +1,8 @@ +# About control 5.7: Threat intelligence + +[[ISO_27002_2022_5.7_OT Threat intelligence \|Original Text]] +[[ISO_27002_2022_5.7_PE Threat intelligence \|Plain English]] + +ISO 27002:2013: n/a + +[[ISO_27002_2022_NL_5.7_BT Informatie en analyses over dreigingen \|NL Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.8_MoC Information security in project management.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.8_MoC Information security in project management.md new file mode 100644 index 0000000..d5ad925 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.8_MoC Information security in project management.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_5.8_OT Information security in project management \|Original Text]] +[[ISO_27002_2022_5.8_PE Information security in project management \|Plain English]] +ISO 27002:2013: 06.1.5, 14.1.1 + +[[ISO_27002_2022_NL_5.8_BT Informatiebeveiliging in projectmanagement \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_5.9_MoC Inventory of information and other associated assets.md b/Corpus/Standards/MoCs/ISO_27002_2022_5.9_MoC Inventory of information and other associated assets.md new file mode 100644 index 0000000..cc23306 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_5.9_MoC Inventory of information and other associated assets.md @@ -0,0 +1,10 @@ +# Control 5.9 Inventory of information and other associated assets + +[[ISO_27002_2022_5.9_OT Inventory of information and other associated assets \|Original Text]] +[[ISO_27002_2022_5.9_PE Inventory of information and other associated assets \|Plain English]] +ISO 27002:2013: 08.1.1, 08.1.2 + +[[ISO_27002_2022_NL_5.9_BT Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen \|Brontekst]] + +The inventory serves as input for the [[Business Impact Analysis (BIA)]] +[[ISO_27001_2022_00_MoC Index EXT]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_6.1_MoC Screening.md b/Corpus/Standards/MoCs/ISO_27002_2022_6.1_MoC Screening.md new file mode 100644 index 0000000..1940a06 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_6.1_MoC Screening.md @@ -0,0 +1,6 @@ +[[ISO_27002_2022_6.1_OT Screening \|Original Text]] +  +[[ISO_27002_2022_6.1_PE Screening \|Plain English]] +ISO 27002:2013: 07.1.1 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_6.2_MoC Terms and conditions of employment.md b/Corpus/Standards/MoCs/ISO_27002_2022_6.2_MoC Terms and conditions of employment.md new file mode 100644 index 0000000..61de944 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_6.2_MoC Terms and conditions of employment.md @@ -0,0 +1,6 @@ +[[ISO_27002_2022_6.2_OT Terms and conditions of employment \|Original Text]] +  +[[ISO_27002_2022_6.2_PE Terms and conditions of employment \|Plain English]] +ISO 27002:2013: 07.1.2 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_6.3_MoC Information security awareness, education and training.md b/Corpus/Standards/MoCs/ISO_27002_2022_6.3_MoC Information security awareness, education and training.md new file mode 100644 index 0000000..a6b6065 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_6.3_MoC Information security awareness, education and training.md @@ -0,0 +1,6 @@ +[[ISO_27002_2022_6.3_OT Information security awareness, education and training \|Original Text]] +  +[[ISO_27002_2022_6.3_PE Information security awareness, education and training \|Plain English]] +ISO 27002:2013: 07.2.2 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_6.4_MoC Disciplinary process.md b/Corpus/Standards/MoCs/ISO_27002_2022_6.4_MoC Disciplinary process.md new file mode 100644 index 0000000..ed620f2 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_6.4_MoC Disciplinary process.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_6.4_OT Disciplinary process \|Original Text]] +[[ISO_27002_2022_6.4_PE Disciplinary process \|Plain English]] +ISO 27002:2013: 07.2.3 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_6.5_MoC Responsibilities after termination or change of employment.md b/Corpus/Standards/MoCs/ISO_27002_2022_6.5_MoC Responsibilities after termination or change of employment.md new file mode 100644 index 0000000..b8ebef2 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_6.5_MoC Responsibilities after termination or change of employment.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_6.5_OT Responsibilities after termination or change of employment \|Original Text]] +[[ISO_27002_2022_6.5_PE Responsibilities after termination or change of employment \|Plain English]] +ISO 27002:2013: 07.3.1 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_6.6_MoC Confidentiality or non-disclosure agreements.md b/Corpus/Standards/MoCs/ISO_27002_2022_6.6_MoC Confidentiality or non-disclosure agreements.md new file mode 100644 index 0000000..901e44d --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_6.6_MoC Confidentiality or non-disclosure agreements.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_6.6_OT Confidentiality or non-disclosure agreements \|Original Text]] +[[ISO_27002_2022_6.6_PE Confidentiality or non-disclosure agreements \|Plain English]] +ISO 27002:2013: 13.2.4 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_6.7_MoC Remote working.md b/Corpus/Standards/MoCs/ISO_27002_2022_6.7_MoC Remote working.md new file mode 100644 index 0000000..0089ac0 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_6.7_MoC Remote working.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_6.7_OT Remote working \|Original Text]] +[[ISO_27002_2022_6.7_PE Remote working \|Plain English]] +ISO 27002:2013: 06.2.2 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_6.8_MoC Information security event reporting.md b/Corpus/Standards/MoCs/ISO_27002_2022_6.8_MoC Information security event reporting.md new file mode 100644 index 0000000..7cfeee2 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_6.8_MoC Information security event reporting.md @@ -0,0 +1,6 @@ +[[ISO_27002_2022_6.8_OT Information security event reporting \|Original Text]] +  +[[ISO_27002_2022_6.8_PE Information security event reporting \|Plain English]] +ISO 27002:2013: 16.1.2, 16.1.3 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.10_MoC Storage media.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.10_MoC Storage media.md new file mode 100644 index 0000000..bf20b5c --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.10_MoC Storage media.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_7.10_OT Storage media \|Original Text]] +[[ISO_27002_2022_7.10_PE Storage media \|Plain English]] +ISO 27002:2013: 08.3.1, 08.3.2, 08.3.3, 11.2.5 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.11_MoC Supporting utilities.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.11_MoC Supporting utilities.md new file mode 100644 index 0000000..c6f3da1 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.11_MoC Supporting utilities.md @@ -0,0 +1,7 @@ +# About Control 7.11: Supporting utilities + +Protecting information processing facilities from power failures and other utilities disruptions. + +[[ISO_27002_2022_7.11_OT Supporting utilities \|Original Text]] +[[ISO_27002_2022_7.11_PE Supporting utilities \|Plain English]] +ISO 27002:2013: 11.2.2 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.12_MoC Cabling security.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.12_MoC Cabling security.md new file mode 100644 index 0000000..45641d9 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.12_MoC Cabling security.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_7.12_OT Cabling security \|Original Text]] +[[ISO_27002_2022_7.12_PE Cabling security \|Plain English]] +ISO 27002:2013: 11.2.3 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.13_MoC Equipment maintenance.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.13_MoC Equipment maintenance.md new file mode 100644 index 0000000..11604dd --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.13_MoC Equipment maintenance.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_7.13_OT Equipment maintenance \|Original Text]] +[[ISO_27002_2022_7.13_PE Equipment maintenance \|Plain English]] +ISO 27002:2013: 11.2.4 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.14_MoC Secure disposal or re-use of equipment.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.14_MoC Secure disposal or re-use of equipment.md new file mode 100644 index 0000000..d10a862 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.14_MoC Secure disposal or re-use of equipment.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_7.14_OT Secure disposal or re-use of equipment \|Original Text]] +[[ISO_27002_2022_7.14_PE Secure disposal or re-use of equipment \|Plain English]] +ISO 27002:2013: 11.2.7 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.1_MoC Physical security perimeters.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.1_MoC Physical security perimeters.md new file mode 100644 index 0000000..fb0699b --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.1_MoC Physical security perimeters.md @@ -0,0 +1,7 @@ +# About control 7.1: Physical security perimeters + +[[ISO_27002_2022_7.1_OT Physical security perimeters \|Original Text]] +[[ISO_27002_2022_7.1_PE Physical security perimeters \|Plain English]] +ISO 27002:2013: 11.1.1 + +[[Physical security in ISO 27001]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.2_MoC Physical entry.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.2_MoC Physical entry.md new file mode 100644 index 0000000..d0484be --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.2_MoC Physical entry.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_7.2_OT Physical entry \|Original Text]] +[[ISO_27002_2022_7.2_PE Physical entry \|Plain English]] +ISO 27002:2013: 11.1.2, 11.1.6 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.3_MoC Securing offices, rooms and facilities.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.3_MoC Securing offices, rooms and facilities.md new file mode 100644 index 0000000..a40bb33 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.3_MoC Securing offices, rooms and facilities.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_7.3_OT Securing offices, rooms and facilities \|Original Text]] +[[ISO_27002_2022_7.3_PE Securing offices, rooms and facilities \|Plain English]] +ISO 27002:2013: 11.1.3 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.4_MoC Physical security monitoring.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.4_MoC Physical security monitoring.md new file mode 100644 index 0000000..ed098a1 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.4_MoC Physical security monitoring.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_7.4_OT Physical security monitoring \|Original Text]] +[[ISO_27002_2022_7.4_PE Physical security monitoring \|Plain English]] +ISO 27002:2013: n/a diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.5_MoC Protecting against physical and environmental threats.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.5_MoC Protecting against physical and environmental threats.md new file mode 100644 index 0000000..16d076f --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.5_MoC Protecting against physical and environmental threats.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_7.5_OT Protecting against physical and environmental threats \|Original Text]] +[[ISO_27002_2022_7.5_PE Protecting against physical and environmental threats \|Plain English]] +ISO 27002:2013: 11.1.4 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.6_MoC Working in secure areas.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.6_MoC Working in secure areas.md new file mode 100644 index 0000000..2c66b54 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.6_MoC Working in secure areas.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_7.6_OT Working in secure areas \|Original Text]] +[[ISO_27002_2022_7.6_PE Working in secure areas \|Plain English]] +ISO 27002:2013: 11.1.5 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.7_MoC Clear desk and clear screen.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.7_MoC Clear desk and clear screen.md new file mode 100644 index 0000000..1500b89 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.7_MoC Clear desk and clear screen.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_7.7_OT Clear desk and clear screen \|Original Text]] +[[ISO_27002_2022_7.7_PE Clear desk and clear screen \|Plain English]] +ISO 27002:2013: 11.2.9 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.8_MoC Equipment siting and protection.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.8_MoC Equipment siting and protection.md new file mode 100644 index 0000000..92eb79a --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.8_MoC Equipment siting and protection.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_7.8_OT Equipment siting and protection \|Original Text]] +[[ISO_27002_2022_7.8_PE Equipment siting and protection \|Plain English]] +ISO 27002:2013: 11.2.1 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_7.9_MoC Security of assets off-premises.md b/Corpus/Standards/MoCs/ISO_27002_2022_7.9_MoC Security of assets off-premises.md new file mode 100644 index 0000000..783ce7b --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_7.9_MoC Security of assets off-premises.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_7.9_OT Security of assets off-premises \|Original Text]] +[[ISO_27002_2022_7.9_PE Security of assets off-premises \|Plain English]] +ISO 27002:2013: 11.2.6 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.10_MoC Information deletion.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.10_MoC Information deletion.md new file mode 100644 index 0000000..9839056 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.10_MoC Information deletion.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.10_OT Information deletion \|Original Text]] +[[ISO_27002_2022_8.10_PE Information deletion \|Plain English]] +ISO 27002:2013: n/a diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.11_MoC Data masking.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.11_MoC Data masking.md new file mode 100644 index 0000000..b1597fb --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.11_MoC Data masking.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.11_OT Data masking \|Original Text]] +[[ISO_27002_2022_8.11_PE Data masking \|Plain English]] +ISO 27002:2013: n/a diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.12_MoC Data leakage prevention.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.12_MoC Data leakage prevention.md new file mode 100644 index 0000000..b5633ef --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.12_MoC Data leakage prevention.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.12_OT Data leakage prevention \|Original Text]] +[[ISO_27002_2022_8.12_PE Data leakage prevention \|Plain English]] +ISO 27002:2013: n/a diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.13_MoC Information backup.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.13_MoC Information backup.md new file mode 100644 index 0000000..6e9ee86 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.13_MoC Information backup.md @@ -0,0 +1,6 @@ +[[ISO_27002_2022_8.13_OT Information backup \|Original Text]] +  +[[ISO_27002_2022_8.13_PE Information backup \|Plain English]] +ISO 27002:2013: 12.3.1 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.14_MoC Redundancy of information processing facilities.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.14_MoC Redundancy of information processing facilities.md new file mode 100644 index 0000000..ecce640 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.14_MoC Redundancy of information processing facilities.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.14_OT Redundancy of information processing facilities \|Original Text]] +[[ISO_27002_2022_8.14_PE Redundancy of information processing facilities \|Plain English]] +ISO 27002:2013: 17.2.1 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.15_MoC Logging.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.15_MoC Logging.md new file mode 100644 index 0000000..eaa0bf5 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.15_MoC Logging.md @@ -0,0 +1,7 @@ +[[ISO_27002_2022_8.15_OT Logging\|Original Text]] +[[ISO_27002_2022_8.15_PE Logging\|Plain English]] + +ISO 27002:2013: +- [[ISO 27001 A 12.4.1 Event logging\|12.4.1]] +- [[ISO 27001 A 12.4.2 Protection of log information\|12.4.2]] +- [[ISO 27001 A 12.4.3 Administrator and operator logs\|12.4.3]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.16_MoC Monitoring activities.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.16_MoC Monitoring activities.md new file mode 100644 index 0000000..b5e4a1c --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.16_MoC Monitoring activities.md @@ -0,0 +1,6 @@ +[[ISO_27002_2022_8.16_OT Monitoring activities \|Original Text]] +  +[[ISO_27002_2022_8.16_PE Monitoring activities \|Plain English]] +ISO 27002:2013: n/a + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.17_MoC Clock synchronization.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.17_MoC Clock synchronization.md new file mode 100644 index 0000000..5e3369b --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.17_MoC Clock synchronization.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.17_OT Clock synchronization \|Original Text]] +[[ISO_27002_2022_8.17_PE Clock synchronization \|Plain English]] +ISO 27002:2013: 12.4.4 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.18_MoC Use of privileged utility programs.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.18_MoC Use of privileged utility programs.md new file mode 100644 index 0000000..1d82c47 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.18_MoC Use of privileged utility programs.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.18_OT Use of privileged utility programs \|Original Text]] +[[ISO_27002_2022_8.18_PE Use of privileged utility programs \|Plain English]] +ISO 27002:2013: 09.4.4 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.19_MoC Installation of software on operational systems.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.19_MoC Installation of software on operational systems.md new file mode 100644 index 0000000..5468c12 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.19_MoC Installation of software on operational systems.md @@ -0,0 +1,6 @@ +[[ISO_27002_2022_8.19_OT Installation of software on operational systems \|Original Text]] +  +[[ISO_27002_2022_8.19_PE Installation of software on operational systems \|Plain English]] +ISO 27002:2013: 12.5.1, 12.6.2 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.1_MoC User endpoint devices.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.1_MoC User endpoint devices.md new file mode 100644 index 0000000..64e3989 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.1_MoC User endpoint devices.md @@ -0,0 +1,6 @@ +[[ISO_27002_2022_8.1_OT User endpoint devices \|Original Text]] +  +[[ISO_27002_2022_8.1_PE User endpoint devices \|Plain English]] +ISO 27002:2013: 06.2.1, 11.2.8 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.20_MoC Networks security.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.20_MoC Networks security.md new file mode 100644 index 0000000..3842792 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.20_MoC Networks security.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.20_OT Networks security \|Original Text]] +[[ISO_27002_2022_8.20_PE Networks security \|Plain English]] +ISO 27002:2013: 13.1.1 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.21_MoC Security of network services.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.21_MoC Security of network services.md new file mode 100644 index 0000000..2c10082 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.21_MoC Security of network services.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.21_OT Security of network services \|Original Text]] +[[ISO_27002_2022_8.21_PE Security of network services \|Plain English]] +ISO 27002:2013: 13.1.2 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.22_MoC Segregation of networks.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.22_MoC Segregation of networks.md new file mode 100644 index 0000000..a186f22 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.22_MoC Segregation of networks.md @@ -0,0 +1,6 @@ +[[ISO_27002_2022_8.22_OT Segregation of networks \|Original Text]] +  +[[ISO_27002_2022_8.22_PE Segregation of networks \|Plain English]] +ISO 27002:2013: 13.1.3 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.23_MoC Web filtering.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.23_MoC Web filtering.md new file mode 100644 index 0000000..ac05bbc --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.23_MoC Web filtering.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.23_OT Web filtering \|Original Text]] +[[ISO_27002_2022_8.23_PE Web filtering \|Plain English]] +ISO 27002:2013: n/a diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.24_MoC Use of cryptography.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.24_MoC Use of cryptography.md new file mode 100644 index 0000000..0679c42 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.24_MoC Use of cryptography.md @@ -0,0 +1,7 @@ +[[ISO_27002_2022_8.24_OT Use of cryptography \|Original Text]] +  +[[ISO_27002_2022_8.24_PE Use of cryptography \|Plain English]] +ISO 27002:2013: 10.1.1, 10.1.2 + +[[ISO_27002_2022_NL_8.24_BT Gebruik van cryptografie \|Brontekst]] +[[ISO_27002_2022_NL_8.24_NN Gebruik van cryptografie \|Normaal Nederlands]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.25_MoC Secure development life cycle.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.25_MoC Secure development life cycle.md new file mode 100644 index 0000000..8d5227f --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.25_MoC Secure development life cycle.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_8.25_OT Secure development life cycle \|Original Text]] +[[ISO_27002_2022_8.25_PE Secure development life cycle \|Plain English]] +ISO 27002:2013: 14.2.1 + +![[ci-cd-pipeline-security-best-practices.pdf]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.26_MoC Application security requirements.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.26_MoC Application security requirements.md new file mode 100644 index 0000000..3553dbd --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.26_MoC Application security requirements.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.26_OT Application security requirements \|Original Text]] +[[ISO_27002_2022_8.26_PE Application security requirements \|Plain English]] +ISO 27002:2013: 14.1.2, 14.1.3 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.27_MoC Secure system architecture and engineering principles.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.27_MoC Secure system architecture and engineering principles.md new file mode 100644 index 0000000..23f5c5b --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.27_MoC Secure system architecture and engineering principles.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.27_OT Secure system architecture and engineering principles \|Original Text]] +[[ISO_27002_2022_8.27_PE Secure system architecture and engineering principles \|Plain English]] +ISO 27002:2013: 14.2.5 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.28_MoC Secure coding.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.28_MoC Secure coding.md new file mode 100644 index 0000000..d90f16f --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.28_MoC Secure coding.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.28_OT Secure coding \|Original Text]] +[[ISO_27002_2022_8.28_PE Secure coding \|Plain English]] +ISO 27002:2013: n/a diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.29_MoC Security testing in development and acceptance.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.29_MoC Security testing in development and acceptance.md new file mode 100644 index 0000000..f9e2261 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.29_MoC Security testing in development and acceptance.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.29_OT Security testing in development and acceptance \|Original Text]] +[[ISO_27002_2022_8.29_PE Security testing in development and acceptance \|Plain English]] +ISO 27002:2013: 14.2.8, 14.2.9 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.2_MoC Privileged access rights.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.2_MoC Privileged access rights.md new file mode 100644 index 0000000..49edac6 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.2_MoC Privileged access rights.md @@ -0,0 +1,9 @@ +# About Control 8.2: Privileged access rights + +Managing privileged access rights. + +[[ISO_27002_2022_8.2_OT Privileged access rights \|Original Text]] +[[ISO_27002_2022_8.2_PE Privileged access rights \|Plain English]] +ISO 27002:2013: 09.2.3 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.30_MoC Outsourced development.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.30_MoC Outsourced development.md new file mode 100644 index 0000000..c790721 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.30_MoC Outsourced development.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.30_OT Outsourced development \|Original Text]] +[[ISO_27002_2022_8.30_PE Outsourced development \|Plain English]] +ISO 27002:2013: 14.2.7 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.31_MoC Separation of development, test and production environments.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.31_MoC Separation of development, test and production environments.md new file mode 100644 index 0000000..f9d968c --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.31_MoC Separation of development, test and production environments.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.31_OT Separation of development, test and production environments \|Original Text]] +[[ISO_27002_2022_8.31_PE Separation of development, test and production environments \|Plain English]] +ISO 27002:2013: 12.1.4, 14.2.6 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.32_MoC Change management.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.32_MoC Change management.md new file mode 100644 index 0000000..699d21c --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.32_MoC Change management.md @@ -0,0 +1,5 @@ +[[ISO_27002_2022_8.32_OT Change management \|Original Text]] +[[ISO_27002_2022_8.32_PE Change management \|Plain English]] +ISO 27002:2013: 12.1.2, 14.2.2, 14.2.3, 14.2.4 + +[[ISO_27002_2022_NL_8.32_BT Wijzigingsbeheer \|Brontekst]] diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.33_MoC Test information.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.33_MoC Test information.md new file mode 100644 index 0000000..696b093 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.33_MoC Test information.md @@ -0,0 +1,5 @@ +# About Control 8.33: Test information + +[[ISO_27002_2022_8.33_OT Test information \|Original Text]] +[[ISO_27002_2022_8.33_PE Test information \|Plain English]] +ISO 27002:2013: 14.3.1 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.34_MoC Protection of information systems during audit testing.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.34_MoC Protection of information systems during audit testing.md new file mode 100644 index 0000000..b32e3a0 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.34_MoC Protection of information systems during audit testing.md @@ -0,0 +1,6 @@ +# About control 8.34: Protection of information systems during audit testing + +[[ISO_27002_2022_8.34_OT Protection of information systems during audit testing|Original Text]] +Plain English + +ISO 27002:2013: 12.7.1 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.34_MoC.md.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.34_MoC.md.md new file mode 100644 index 0000000..dccb835 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.34_MoC.md.md @@ -0,0 +1,3 @@ +[[ISO_27002_2022_8.34_OT Protection of information systems during audit testing \|Original Text]] +[[ISO_27002_2022_8.34_PE Protection of information systems during audit testing \|Plain English]] +ISO 27002:2013: 12.7.1 diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.3_MoC Information access restriction.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.3_MoC Information access restriction.md new file mode 100644 index 0000000..ffb223e --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.3_MoC Information access restriction.md @@ -0,0 +1,11 @@ +# About Control 8.3: Information access restriction + +Restricting access to information assets in line with the access control policy. + +Control 8.3 operationalizes the foundational rules set in [[ISO_27002_2022_5.15_OT Access control|A5.15]] by implementing detailed technical measures. + +[[ISO_27002_2022_8.3_OT Information access restriction|Original Text]] +[[ISO_27002_2022_8.3_PE Title \|Plain English]] +ISO 27002:2013: 09.4.1 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.4_MoC Access to source code.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.4_MoC Access to source code.md new file mode 100644 index 0000000..19bb973 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.4_MoC Access to source code.md @@ -0,0 +1,7 @@ +# About Control 8.4: Access to source code + +[[ISO_27002_2022_8.4_OT Title \|Original Text]] +[[ISO_27002_2022_8.4_PE Title \|Plain English]] +ISO 27002:2013: 09.4.5 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.5_MoC Secure authentication.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.5_MoC Secure authentication.md new file mode 100644 index 0000000..5b5bf78 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.5_MoC Secure authentication.md @@ -0,0 +1,7 @@ +# About Control 8.5: Secure authentication + +[[ISO_27002_2022_8.5_OT Secure authentication \|Original Text]] +[[ISO_27002_2022_8.5_PE Secure authentication \|Plain English]] +ISO 27002:2013: 09.4.2 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.6_MoC Capacity management.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.6_MoC Capacity management.md new file mode 100644 index 0000000..439cad3 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.6_MoC Capacity management.md @@ -0,0 +1,6 @@ + +[[ISO_27002_2022_8.6_OT Capacity management\|Original Text]] +[[ISO_27002_2022_8.6_PE Title \|Plain English]] +ISO 27002:2013: 12.1.3 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.7_MoC Protection against malware.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.7_MoC Protection against malware.md new file mode 100644 index 0000000..6ba2c58 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.7_MoC Protection against malware.md @@ -0,0 +1,6 @@ +[[ISO_27002_2022_8.7_OT Protection against malware \|Original Text]] +  +[[ISO_27002_2022_8.7_PE Protection against malware \|Plain English]] +ISO 27002:2013: 12.2.1 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.8_MoC Management of technical vulnerabilities.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.8_MoC Management of technical vulnerabilities.md new file mode 100644 index 0000000..a682758 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.8_MoC Management of technical vulnerabilities.md @@ -0,0 +1,8 @@ +# About Control 8.8: Management of technical vulnerabilities + +[[ISO_27002_2022_8.8_OT Management of technical vulnerabilities \|Original Text]] +  +[[ISO_27002_2022_8.8_PE Management of technical vulnerabilities \|Plain English]] +ISO 27002:2013: 12.6.1, 18.2.3 + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.9_MoC Configuration management.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.9_MoC Configuration management.md new file mode 100644 index 0000000..83a5da3 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_8.9_MoC Configuration management.md @@ -0,0 +1,6 @@ +[[ISO_27002_2022_8.9_OT Configuration management \|Original Text]] +  +[[ISO_27002_2022_8.9_PE Configuration management \|Plain English]] +ISO 27002:2013: n/a + + diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_Index_DEPRECIATED.md b/Corpus/Standards/MoCs/ISO_27002_2022_Index_DEPRECIATED.md new file mode 100644 index 0000000..57037a5 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_Index_DEPRECIATED.md @@ -0,0 +1,100 @@ +#iso27002/2022/EN +**DEPRECIATED – now [[ISO_27001_2022_00_MoC Index EXT]]** + +2022 ID | Control title | Original | Plain English +------- | ------------- | -------- | ------------- +5.1 | Policies for information security | [[ISO_27002_OT 5.1 Policies for information security\|OT]] | [[ISO_27002_PE 5.1 Policies for information security\|PE]] +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 | [[ISO_27002_OT 5.7 Threat intelligence\|OT]] | [[ISO_27002_PE 5.7 Threat intelligence\|PE]] +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 | [[ISO_27002_OT 5.23 Information security for use of cloud services\|OT]] | [[ISO_27002_PE 5.23 Information security for use of cloud services\|PE]] +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 +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 +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 +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 | [[ISO_27002_OT 8.8 Management of technical vulnerabilities\|OT]] +8.9 | Configuration management | [[ISO_27002_OT 8.9 Configuration management\|OT]]|[[ISO_27002_PE 8.9 Configuration management\|PE]] +8.10 | Information deletion +8.11 | Data masking +8.12 | Data leakage prevention +8.13 | Information backup +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 | [[ISO_27002_OT 8.28 Secure coding\|OT]] | [[ISO_27002_PE 8.28 Secure coding\|PE]] +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 + +See also [[ISO 27002 2022 Controls enumeration list]] \ No newline at end of file diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_Vertaaltabel_Engels_Nederlands.md b/Corpus/Standards/MoCs/ISO_27002_2022_Vertaaltabel_Engels_Nederlands.md new file mode 100644 index 0000000..3157279 --- /dev/null +++ b/Corpus/Standards/MoCs/ISO_27002_2022_Vertaaltabel_Engels_Nederlands.md @@ -0,0 +1,97 @@ +#iso27002/2022/EN + +| 2022 ID | Control title | Maatregel | +| :------ | :--------------------------------------------------------------------- | :---------------------------------------------------------------------------- | +| 5.1 | Policies for information security | Beleidsregels voor informatiebeveiliging | +| 5.2 | Information security roles and responsibilities | Rollen en verantwoordelijkheden bij informatiebeveiliging | +| 5.3 | Segregation of duties | Functiescheiding | +| 5.4 | Management responsibilities | Managementverantwoordelijkheden | +| 5.5 | Contact with authorities | Contact met overheidsinstanties | +| 5.6 | Contact with special interest groups | Contact met speciale belangengroepen | +| 5.7 | Threat intelligence | Informatie en analyses over dreigingen | +| 5.8 | Information security in project management | Informatiebeveiliging in projectmanagement | +| 5.9 | Inventory of information and other associated assets | Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen | +| 5.10 | Acceptable use of information and other associated assets | Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen | +| 5.11 | Return of assets | Retourneren van bedrijfsmiddelen | +| 5.12 | Classification of information | Classificeren van informatie | +| 5.13 | Labelling of information | Labelen van informatie | +| 5.14 | Information transfer | Overdragen van informatie | +| 5.15 | Access control | Toegangsbeveiliging | +| 5.16 | Identity management | Identiteitsbeheer | +| 5.17 | Authentication information | Beheren van authenticatie-informatie | +| 5.18 | Access rights | Toegangsrechten | +| 5.19 | Information security in supplier relationships | Informatiebeveiliging in leveranciersrelaties | +| 5.20 | Addressing information security within supplier agreements | Adresseren van informatiebeveiliging in leveranciersovereenkomsten | +| 5.21 | Managing information security in the ICT supply chain | Beheren van informatiebeveiliging in de ICT-keten | +| 5.22 | Monitoring, review and change management of supplier services | Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten | +| 5.23 | Information security for use of cloud services | Informatiebeveiliging voor het gebruik van clouddiensten | +| 5.24 | Information security incident management planning and preparation | Plannen en voorbereiden van het beheer van informatiebeveiligingsincidenten | +| 5.25 | Assessment and decision on information security events | Beoordelen van en besluiten over informatiebeveiligingsgebeurtenissen | +| 5.26 | Response to information security incidents | Reageren op informatiebeveiligingsincidenten | +| 5.27 | Learning from information security incidents | Leren van informatiebeveiligingsincidenten | +| 5.28 | Collection of evidence | Verzamelen van bewijsmateriaal | +| 5.29 | Information security during disruption | Informatiebeveiliging tijdens een verstoring | +| 5.30 | ICT readiness for business continuity | ICT-gereedheid voor bedrijfscontinuïteit | +| 5.31 | Legal, statutory, regulatory and contractual requirements | Wettelijke, statutaire, regelgevende en contractuele eisen | +| 5.32 | Intellectual property rights | Intellectuele-eigendomsrechten | +| 5.33 | Protection of records | Beschermen van registraties | +| 5.34 | Privacy and protection of PII | Privacy en bescherming van persoonsgegevens | +| 5.35 | Independent review of information security | Onafhankelijke beoordeling van informatiebeveiliging | +| 5.36 | Compliance with policies, rules and standards for information security | Naleving van beleid, regels en normen voor informatiebeveiliging | +| 5.37 | Documented operating procedures | Gedocumenteerde bedieningsprocedures | +| 6.1 | Screening | Screening | +| 6.2 | Terms and conditions of employment | Arbeidsovereenkomst | +| 6.3 | Information security awareness, education and training | Bewustwording van, opleiding en training in informatiebeveiliging | +| 6.4 | Disciplinary process | Disciplinaire procedure | +| 6.5 | Responsibilities after termination or change of employment | Verantwoordelijkheden na beëindiging of wijziging van het dienstverband | +| 6.6 | Confidentiality or non-disclosure agreements | Vertrouwelijkheids- of geheimhoudingsovereenkomsten | +| 6.7 | Remote working | Werken op afstand | +| 6.8 | Information security event reporting | Melden van informatiebeveiligingsgebeurtenissen | +| 7.1 | Physical security perimeters | Fysieke beveiligingszones | +| 7.2 | Physical entry | Fysieke toegangsbeveiliging | +| 7.3 | Securing offices, rooms and facilities | Beveiligen van kantoren, ruimten en faciliteiten | +| 7.4 | Physical security monitoring | Monitoren van de fysieke beveiliging | +| 7.5 | Protecting against physical and environmental threats | Beschermen tegen fysieke en omgevingsdreigingen | +| 7.6 | Working in secure areas | Werken in beveiligde zones | +| 7.7 | Clear desk and clear screen | ‘Clear desk’ en ‘clear screen’ | +| 7.8 | Equipment siting and protection | Plaatsen en beschermen van apparatuur | +| 7.9 | Security of assets off-premises | Beveiligen van bedrijfsmiddelen buiten het terrein | +| 7.10 | Storage media | Opslagmedia | +| 7.11 | Supporting utilities | Nutsvoorzieningen | +| 7.12 | Cabling security | Beveiligen van bekabeling | +| 7.13 | Equipment maintenance | Onderhoud van apparatuur | +| 7.14 | Secure disposal or re-use of equipment | Veilig verwijderen of hergebruiken van apparatuur | +| 8.1 | User endpoint devices | ‘User endpoint devices’ | +| 8.2 | Privileged access rights | Speciale toegangsrechten | +| 8.3 | Information access restriction | Beperking toegang tot informatie | +| 8.4 | Access to source code | Toegangsbeveiliging op broncode | +| 8.5 | Secure authentication | Beveiligde authenticatie | +| 8.6 | Capacity management | Capaciteitsbeheer | +| 8.7 | Protection against malware | Bescherming tegen malware | +| 8.8 | Management of technical vulnerabilities | Beheer van technische kwetsbaarheden | +| 8.9 | Configuration management | Configuratiebeheer | +| 8.10 | Information deletion | Wissen van informatie | +| 8.11 | Data masking | Maskeren van gegevens | +| 8.12 | Data leakage prevention | Voorkomen van gegevenslekken (Data leakage prevention) | +| 8.13 | Information backup | Back-up van informatie | +| 8.14 | Redundancy of information processing facilities | Redundantie van informatieverwerkende faciliteiten | +| 8.15 | Logging | Logging | +| 8.16 | Monitoring activities | Monitoren van activiteiten | +| 8.17 | Clock synchronization | Kloksynchronisatie | +| 8.18 | Use of privileged utility programs | Gebruik van speciale systeemhulpmiddelen | +| 8.19 | Installation of software on operational systems | Installeren van software op operationele systemen | +| 8.20 | Networks security | Beveiliging netwerkcomponenten | +| 8.21 | Security of network services | Beveiliging van netwerkdiensten | +| 8.22 | Segregation of networks | Netwerksegmentatie | +| 8.23 | Web filtering | Toepassen van webfilters | +| 8.24 | Use of cryptography | Gebruik van cryptografie | +| 8.25 | Secure development life cycle | Beveiligen tijdens de ontwikkelcyclus | +| 8.26 | Application security requirements | Toepassingsbeveiligingseisen | +| 8.27 | Secure system architecture and engineering principles | Veilige systeemarchitectuur en technische uitgangspunten | +| 8.28 | Secure coding | Veilig coderen | +| 8.29 | Security testing in development and acceptance | Testen van de beveiliging tijdens ontwikkeling en acceptatie | +| 8.30 | Outsourced development | Uitbestede systeemontwikkeling | +| 8.31 | Separation of development, test and production environments | Scheiding van ontwikkel-, test- en productieomgevingen | +| 8.32 | Change management | Wijzigingsbeheer | +| 8.33 | Test information | Testgegevens | +| 8.34 | Protection of information systems during audit testing | Bescherming van informatiesystemen tijdens audits | diff --git a/iso27DIY-mkII-MoC.md b/iso27DIY-MoC.md similarity index 100% rename from iso27DIY-mkII-MoC.md rename to iso27DIY-MoC.md