From 2fbe163fffaae51710e487aa225b3b2ec7c428f6 Mon Sep 17 00:00:00 2001 From: Richard Kranendonk Date: Mon, 20 Apr 2026 12:15:34 +0200 Subject: [PATCH] resolved duplicity of files --- .DS_Store | Bin 8196 -> 6148 bytes ...information and other associated assets.md | 0 ...ISO_27002_2022_5.11_OT Return of assets.md | 0 ...2_5.12_OT Classification of information.md | 0 ...2_2022_5.13_OT Labelling of information.md | 0 ...27002_2022_5.14_OT Information transfer.md | 0 .../ISO_27002_2022_5.15_OT Access control.md | 0 ..._27002_2022_5.16_OT Identity management.md | 0 ...2022_5.17_OT Authentication information.md | 4 +- .../ISO_27002_2022_5.18_OT Access rights.md | 0 ...tion security in supplier relationships.md | 0 ....1_OT Policies for information security.md | 0 ...ion security within supplier agreements.md | 0 ...mation security in the ICT supply chain.md | 0 ... change management of supplier services.md | 0 ...tion security for use of cloud services.md | 0 ...ent management planning and preparation.md | 0 ...decision on information security events.md | 0 ...ponse to information security incidents.md | 0 ...ing from information security incidents.md | 0 ...002_2022_5.28_OT Collection of evidence.md | 0 ... Information security during disruption.md | 0 ...ion security roles and responsibilities.md | 0 ...T ICT readiness for business continuity.md | 0 ...regulatory and contractual requirements.md | 0 ...22_5.32_OT Intellectual property rights.md | 0 ...7002_2022_5.33_OT Protection of records.md | 0 ...2_5.34_OT Privacy and protection of PII.md | 0 ...ependent review of information security.md | 0 ... and standards for information security.md | 0 ...5.37_OT Documented operating procedures.md | 0 ...27002_2022_5.3_OT Segregation of duties.md | 0 ...2022_5.4_OT Management responsibilities.md | 3 + ...02_2022_5.5_OT Contact with authorities.md | 18 --- ...OT Contact with special interest groups.md | 1 - ...O_27002_2022_5.7_OT Threat intelligence.md | 0 ...ormation security in project management.md | 0 ...information and other associated assets.md | 0 .../ISO_27002_2022_6.1_OT Screening.md | 0 ...2_OT Terms and conditions of employment.md | 0 ...urity awareness, education and training.md | 0 ..._27002_2022_6.4_OT Disciplinary process.md | 0 ...ter termination or change of employment.md | 0 ...dentiality or non-disclosure agreements.md | 0 .../ISO_27002_2022_6.7_OT Remote working.md | 0 ...OT Information security event reporting.md | 0 .../ISO_27002_2022_7.10_OT Storage media.md | 0 ...27002_2022_7.11_OT Supporting utilities.md | 0 ...ISO_27002_2022_7.12_OT Cabling security.md | 0 ...7002_2022_7.13_OT Equipment maintenance.md | 0 ... Secure disposal or re-use of equipment.md | 0 ...022_7.1_OT Physical security perimeters.md | 0 .../ISO_27002_2022_7.2_OT Physical entry.md | 0 ... Securing offices, rooms and facilities.md | 0 ...022_7.4_OT Physical security monitoring.md | 0 ...inst physical and environmental threats.md | 0 ...002_2022_7.6_OT Working in secure areas.md | 0 ...2022_7.7_OT Clear desk and clear screen.md | 0 ..._7.8_OT Equipment siting and protection.md | 0 ..._7.9_OT Security of assets off-premises.md | 0 ...27002_2022_8.10_OT Information deletion.md | 0 .../ISO_27002_2022_8.11_OT Data masking.md | 0 ...02_2022_8.12_OT Data leakage prevention.md | 0 ...O_27002_2022_8.13_OT Information backup.md | 0 ...cy of information processing facilities.md | 0 .../ISO_27002_2022_8.15_OT Logging.md | 0 ...7002_2022_8.16_OT Monitoring activities.md | 0 ...7002_2022_8.17_OT Clock synchronization.md | 0 ...8_OT Use of privileged utility programs.md | 0 ...tion of software on operational systems.md | 0 ...27002_2022_8.1_OT User endpoint devices.md | 0 ...SO_27002_2022_8.20_OT Networks security.md | 0 ...22_8.21_OT Security of network services.md | 0 ...02_2022_8.22_OT Segregation of networks.md | 0 .../ISO_27002_2022_8.23_OT Web filtering.md | 0 ..._27002_2022_8.24_OT Use of cryptography.md | 0 ...2_8.25_OT Secure development life cycle.md | 0 ...26_OT Application security requirements.md | 0 ...architecture and engineering principles.md | 0 .../ISO_27002_2022_8.28_OT Secure coding.md | 0 ...y testing in development and acceptance.md | 0 ...02_2022_8.2_OT Privileged access rights.md | 0 ...002_2022_8.30_OT Outsourced development.md | 0 ...pment, test and production environments.md | 0 ...SO_27002_2022_8.32_OT Change management.md | 0 ...ISO_27002_2022_8.33_OT Test information.md | 0 ...nformation systems during audit testing.md | 0 ...2_8.3_OT Information access restriction.md | 0 ...27002_2022_8.4_OT Access to source code.md | 0 ...27002_2022_8.5_OT Secure authentication.md | 0 ...O_27002_2022_8.6_OT Capacity management.md | 0 ..._2022_8.7_OT Protection against malware.md | 0 ...Management of technical vulnerabilities.md | 0 ...02_2022_8.9_OT Configuration management.md | 0 ....1_OT Policies for information security.md | 74 ---------- ... change management of supplier services.md | 57 -------- ...tion security for use of cloud services.md | 53 ------- ...ent management planning and preparation.md | 66 --------- ...ing from information security incidents.md | 20 --- ...T ICT readiness for business continuity.md | 42 ------ ...22_5.32_OT Intellectual property rights.md | 48 ------- ...27002_2022_5.3_OT Segregation of duties.md | 33 ----- ...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 ------- ..._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 ------------- ..._2022_8.7_OT Protection against malware.md | 57 -------- ...Management of technical vulnerabilities.md | 130 ------------------ ...02_2022_8.9_OT Configuration management.md | 74 ---------- .../ISO27002-EN-2022/batch-2/.DS_Store | Bin 6148 -> 0 bytes ...2022_5.17_OT Authentication information.md | 74 ---------- ...tion security in supplier relationships.md | 71 ---------- ...ion security within supplier agreements.md | 72 ---------- ...mation security in the ICT supply chain.md | 58 -------- ...ion security roles and responsibilities.md | 27 ---- ...2022_5.4_OT Management responsibilities.md | 32 ----- 121 files changed, 6 insertions(+), 1531 deletions(-) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.10_OT Acceptable use of information and other associated assets.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.11_OT Return of assets.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.12_OT Classification of information.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.13_OT Labelling of information.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.14_OT Information transfer.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.15_OT Access control.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.16_OT Identity management.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.17_OT Authentication information.md (99%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.18_OT Access rights.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.19_OT Information security in supplier relationships.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_5.1_OT Policies for information security.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.20_OT Addressing information security within supplier agreements.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_5.23_OT Information security for use of cloud services.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_5.24_OT Information security incident management planning and preparation.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.25_OT Assessment and decision on information security events.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.26_OT Response to information security incidents.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_5.27_OT Learning from information security incidents.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.28_OT Collection of evidence.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.29_OT Information security during disruption.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.2_OT Information security roles and responsibilities.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_5.30_OT ICT readiness for business continuity.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.31_OT Legal, statutory, regulatory and contractual requirements.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_5.32_OT Intellectual property rights.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.33_OT Protection of records.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.34_OT Privacy and protection of PII.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.35_OT Independent review of information security.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.36_OT Compliance with policies, rules and standards for information security.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.37_OT Documented operating procedures.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_5.3_OT Segregation of duties.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.4_OT Management responsibilities.md (98%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_5.5_OT Contact with authorities.md (94%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_5.6_OT Contact with special interest groups.md (97%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_5.7_OT Threat intelligence.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_5.8_OT Information security in project management.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_5.9_OT Inventory of information and other associated assets.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_6.1_OT Screening.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_6.2_OT Terms and conditions of employment.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_6.3_OT Information security awareness, education and training.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_6.4_OT Disciplinary process.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_6.5_OT Responsibilities after termination or change of employment.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_6.6_OT Confidentiality or non-disclosure agreements.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_6.7_OT Remote working.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_6.8_OT Information security event reporting.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.10_OT Storage media.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.11_OT Supporting utilities.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.12_OT Cabling security.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.13_OT Equipment maintenance.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.14_OT Secure disposal or re-use of equipment.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.1_OT Physical security perimeters.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.2_OT Physical entry.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.3_OT Securing offices, rooms and facilities.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.4_OT Physical security monitoring.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.5_OT Protecting against physical and environmental threats.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.6_OT Working in secure areas.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.7_OT Clear desk and clear screen.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.8_OT Equipment siting and protection.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_7.9_OT Security of assets off-premises.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.10_OT Information deletion.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.11_OT Data masking.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.12_OT Data leakage prevention.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.13_OT Information backup.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.14_OT Redundancy of information processing facilities.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.15_OT Logging.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.16_OT Monitoring activities.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.17_OT Clock synchronization.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.18_OT Use of privileged utility programs.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.19_OT Installation of software on operational systems.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.1_OT User endpoint devices.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.20_OT Networks security.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.21_OT Security of network services.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.22_OT Segregation of networks.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.23_OT Web filtering.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_8.24_OT Use of cryptography.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_8.25_OT Secure development life cycle.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_8.26_OT Application security requirements.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_8.28_OT Secure coding.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.29_OT Security testing in development and acceptance.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.2_OT Privileged access rights.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.30_OT Outsourced development.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.31_OT Separation of development, test and production environments.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.32_OT Change management.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.33_OT Test information.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.34_OT Protection of information systems during audit testing.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.3_OT Information access restriction.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.4_OT Access to source code.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.5_OT Secure authentication.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-1 => }/ISO_27002_2022_8.6_OT Capacity management.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_8.7_OT Protection against malware.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md (100%) rename Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/{batch-2 => }/ISO_27002_2022_8.9_OT Configuration management.md (100%) delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.1_OT Policies for information security.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.23_OT Information security for use of cloud services.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.24_OT Information security incident management planning and preparation.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.27_OT Learning from information security incidents.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.30_OT ICT readiness for business continuity.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.32_OT Intellectual property rights.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.3_OT Segregation of duties.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.5_OT Contact with authorities.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.6_OT Contact with special interest groups.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.7_OT Threat intelligence.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.8_OT Information security in project management.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.24_OT Use of cryptography.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.25_OT Secure development life cycle.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.26_OT Application security requirements.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.28_OT Secure coding.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.7_OT Protection against malware.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.9_OT Configuration management.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/.DS_Store delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.17_OT Authentication information.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.19_OT Information security in supplier relationships.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.20_OT Addressing information security within supplier agreements.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.2_OT Information security roles and responsibilities.md delete mode 100644 Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.4_OT Management responsibilities.md diff --git a/.DS_Store b/.DS_Store index a784c66f98d3400a4884a02fdfbb24f8020fde41..bd9d599dcfb2525fe71b211667d65baff455cc70 100644 GIT binary patch delta 108 zcmZp1XfcprU|?W$DortDU=RQ@Ie-{Mvv5r;6q~50$jH4hU^g=(_hudeb*9Zp!cB}5 ui-Q)kb8rYU162Wm05_0u1!>q=_?>w&zloI(t7{F0LWrsz@j6m zytn|WV`ox9PG)h5fx$IKCT12^HlS@B+#IpN8TsYGC5a`a#ZHMu(I8$(etu3;;^aCO zdmT>Bcmc`kYGVUS9R*_p^I9E+YC{79LmdTEW5e27P7YCJee0n3?3~=Z{O-vwSmc#^ zusfqHxF|0tKM&+!#?1z7t&E%Biik5$Y~T@O200uUB-}v46%;I+1v$PmPv#f#ob1oT P!NCX#F^0|YJad=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/batch-1/ISO_27002_2022_8.25_OT Secure development life cycle.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.25_OT Secure development life cycle.md deleted file mode 100644 index ea0b64c..0000000 --- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.25_OT Secure development life cycle.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -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/batch-1/ISO_27002_2022_8.26_OT Application security requirements.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.26_OT Application security requirements.md deleted file mode 100644 index 52f134b..0000000 --- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.26_OT Application security requirements.md +++ /dev/null @@ -1,89 +0,0 @@ -#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/batch-1/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md deleted file mode 100644 index 05d7591..0000000 --- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -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/batch-1/ISO_27002_2022_8.28_OT Secure coding.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.28_OT Secure coding.md deleted file mode 100644 index e35e279..0000000 --- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.28_OT Secure coding.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -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/batch-1/ISO_27002_2022_8.7_OT Protection against malware.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.7_OT Protection against malware.md deleted file mode 100644 index d8b221b..0000000 --- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.7_OT Protection against malware.md +++ /dev/null @@ -1,57 +0,0 @@ -#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/batch-1/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md deleted file mode 100644 index 72884b4..0000000 --- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md +++ /dev/null @@ -1,130 +0,0 @@ -#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/batch-1/ISO_27002_2022_8.9_OT Configuration management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.9_OT Configuration management.md deleted file mode 100644 index 722e1a7..0000000 --- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.9_OT Configuration management.md +++ /dev/null @@ -1,74 +0,0 @@ -#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/batch-2/.DS_Store b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/.DS_Store deleted file mode 100644 index 5008ddfcf53c02e82d7eee2e57c38e5672ef89f6..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6148 zcmeH~Jr2S!425mzP>H1@V-^m;4Wg<&0T*E43hX&L&p$$qDprKhvt+--jT7}7np#A3 zem<@ulZcFPQ@L2!n>{z**++&mCkOWA81W14cNZlEfg7;MkzE(HCqgga^y>{tEnwC%0;vJ&^%eQ zLs35+`xjp>T0