From 4cc658dfdb99d0de7ba086e718f3080b0d248b62 Mon Sep 17 00:00:00 2001 From: Andre Baumeier Date: Thu, 3 Sep 2020 16:09:08 +0200 Subject: [PATCH] Adding mapping to ISO 27001 controls. --- data/BuildandDeployment.yml | 72 +++++++++++++++ data/CultureandOrg.yml | 90 +++++++++++++++++-- data/Informationgathering.yml | 51 +++++++++++ data/Infrastructure.yml | 55 ++++++++++++ data/TestandVerification.yml | 162 +++++++++++++++++++++++++++++++++- detail.php | 11 ++- 6 files changed, 434 insertions(+), 7 deletions(-) diff --git a/data/BuildandDeployment.yml b/data/BuildandDeployment.yml index 4f0669cd2..7bc7d988b 100755 --- a/data/BuildandDeployment.yml +++ b/data/BuildandDeployment.yml @@ -14,6 +14,8 @@ Build: level: 4 implementation: Docker samm2: i-secure-build|A|2 + iso27001-2017: + - 14.2.6 Defined build process: risk: Performing builds without a defined process is error prone. For example, as a result of incorrect security related configuration. @@ -27,6 +29,9 @@ Build: level: 1 implementation: "Jenkins, Docker" samm2: i-secure-build|A|1 + iso27001-2017: + - 12.1.1 + - 14.2.2 Regular tests: risk: After pushing source code to the version control system, any delay in receiving feedback on defects makes them harder for the developer to remediate. measure: On each push and/or at given intervals automatic security tests are performed. @@ -38,6 +43,10 @@ Build: level: 2 implementation: "" samm2: i-secure-build|A|3 + iso27001-2017: + - 14.2.3 + - 14.2.8 + - 14.2.9 Signing of code: risk: Unauthorized manipulation of source code might be difficult to spot. measure: Digitally signing commits helps to prevent unauthorized manipulation of source code. @@ -52,6 +61,8 @@ Build: - Defined build process samm: OA3-B samm2: i-secure-build|A|2 + iso27001-2017: + - 14.2.6 Signing of artifacts: risk: Unauthorized manipulation of artifacts might be difficult to spot. For example, this may result in images with malicious code in the Docker registry. @@ -69,6 +80,8 @@ Build: - Defined build process samm: OA3-B samm2: i-secure-build|A|1 + iso27001-2017: + - 14.2.6 Deployment: Backup before deployment: risk: If errors are experienced during the deployment process you want to deploy @@ -86,6 +99,9 @@ Deployment: - Defined deployment process samm: OE2-A samm2: TODO + iso27001-2017: + - 12.3 + - 14.2.6 Blue/Green Deployment: risk: A new artifacts version can have unknown defects. measure: By having multiple production environments, a deployment can be performant @@ -101,6 +117,13 @@ Deployment: dependsOn: - Smoke Test samm2: TODO + iso27001-2017: + - 17.2.1 + - 12.1.1 + - 12.1.2 + - 12.1.4 + - 12.5.1 + - 14.2.9 Defined deployment process: risk: Deployments without a defined process are error prone thus allowing old or untested artifact to be deployed. measure: A defined deployment process significantly lowers the likelihood of errors during the deployment phase. @@ -112,6 +135,9 @@ Deployment: level: 1 implementation: Jenkins, Docker samm2: i-secure-deployment|A|1 + iso27001-2017: + - 12.1.1 + - 14.2.2 Environment depending configuration parameters: risk: Attackers who compromise source code can see confidential access information like database credentials. @@ -126,6 +152,9 @@ Deployment: implementation: "" samm: SA2-A samm2: i-secure-deployment|B|1 + iso27001-2017: + - 9.4.5 + - 14.2.6 Handover of confidential parameters: risk: Attackers who compromise a system can see confidential access information like database credentials. Parameters are often used to set credentials, for @@ -145,6 +174,12 @@ Deployment: - Environment depending configuration parameters samm: "SA2-A" samm2: i-secure-deployment|B|2 TODO might be 1 + iso27001-2017: + - 14.1.3 + - 13.1.3 + - 9.4.3 + - 9.4.1 + - 10.1.2 Rolling update on deployment: risk: While a deployment is performed, the application can not be reached. measure: A deployment without downtime is performed*. @@ -158,6 +193,10 @@ Deployment: dependsOn: - Defined deployment process samm2: i-secure-deployment|A|1 + iso27001-2017: + - 12.5.1 + - 14.2.2 + - 17.2.1 Same artifact for environments: risk: Building of an artifact for different environments means that an untested artifact might reach the production environment. @@ -174,6 +213,10 @@ Deployment: - Defined build process samm: OE2-A samm2: i-secure-deployment|A|2 + iso27001-2017: + - 14.3.1 + - 14.2.8 + - 12.1.4 Usage of feature toggles: risk: By using environment dependent configuration, some parameters will not be tested correctly. i.e. 
if
@@ -190,6 +233,11 @@ Deployment:
     dependsOn:
     - Same artifact for environments
     samm: EG1-B
+    iso27001-2017:
+      - 14.3.1
+      - 14.2.8
+      - 14.2.9
+      - 12.1.4
   Usage of trusted images:
     risk: Developers or operations might start random images in the production cluster which have malicous code or known vulnerabilities.
     Measure: Whitelist signed artifacts/images or whitelist a trusted (internal) registry.
@@ -202,6 +250,11 @@ Deployment:
     usefulness: 3
     level: 2
     samm2: i-secure-deployment|A|2
+    iso27001-2017:
+      - 15.1.1
+      - 15.1.2
+      - 15.1.3
+      - 14.1.3
   Inventory of running artifacts:
     risk: In case a vulnerability of severity high or critical exists, it needs to be known where an artifacts with that vulnerability is deployed with which dependencies.
     Measure: A documented inventory or a possibility to gather the needed information (e.g. the documentation of which script needs to be run by whoom) must be in place.
@@ -214,6 +267,9 @@ Deployment:
     usefulness: 3
     level: 3
     samm2: o-incident-management|TODO
+    iso27001-2017:
+      - 8.1
+      - 8.2
 Patch Management:
   A patch policy is defined:
     risk: Vulnerabilities in running containers stay for long and might get exploited.
@@ -225,6 +281,10 @@ Patch Management:
     usefulness: 4
     level: 1
     samm2: o-environment-management|B|1
+    iso27001-2017:
+      - 12.6.1
+      - 12.5.1
+      - 14.2.5
   Nightly build of images:
     risk: Vulnerabilities in running containers stay for too long and might get exploited.
     measure: Images are getting build at least nightly.
@@ -235,6 +295,8 @@ Patch Management:
     usefulness: 3
     level: 2
     samm2: o-environment-management|B|1
+    iso27001-2017:
+      - 12.6.1
   Automated PRs for patches:
     risk: Known vulnerabilities components might stay for long and get exploited, even when a patch is available.
     measure: Fast patching of third party component is needed. The DevOps way is to have an automated pull request for new components. This includes 
@@ -245,6 +307,9 @@ Patch Management:
     usefulness: 5
     level: 1
     samm2: o-environment-management|B|1
+    iso27001-2017:
+      - 12.6.1
+      - 14.2.5
     implementation:
       - dependabot
       - Jenkins
@@ -258,6 +323,8 @@ Patch Management:
     usefulness: 3
     level: 3
     samm2: o-environment-management|B|1
+    iso27001-2017:
+      - 12.6.1
   Usage of a short maximum lifetime for images:
     risk: Vulnerabilities in running containers stay for too long and might get exploited.
     measure: The nightly builded images are deployed minimum every 1 day.
@@ -268,6 +335,8 @@ Patch Management:
     usefulness: 3
     level: 4
     samm2: o-environment-management|B|1
+    iso27001-2017:
+      - 12.6.1
     implementation:
       - Sample concept:
(1) each container has a set lifetime and is killed / replaced with a new container multiple times a day where you have some form of a graceful replacement to ensure no (short) service outage will occur to the end users.
(2) twice a day a rebuild of images is done. The rebuilds are put into a automated testing pipeline. If the testing has no blocking issues the new images will be released for deployment during the next "restart" of a container. What has to be done, is to ensure the new containers are deployed in some canary deployment manner, this will ensure that if (and only if) something buggy has been introduced which breaks functionality the canary deployment will make sure the "older version" is being used and not the buggy newer one.
   Reduction of the attack surface:
@@ -280,6 +349,9 @@ Patch Management:
     usefulness: 3
     level: 2
     samm2: o-environment-management|B|1
+    iso27001-2017:
+      - hardening is missing in ISO 27001
+      - 14.2.1
     implementation: 
     - Distroless
     - Fedora CoreOS
diff --git a/data/CultureandOrg.yml b/data/CultureandOrg.yml
index 0f34a7f28..24b8277f5 100755
--- a/data/CultureandOrg.yml
+++ b/data/CultureandOrg.yml
@@ -11,7 +11,9 @@ Education and Guidance:
     level: 1
     samm: EG1-A
       - In case you do not have the budget to hire an external security expert, an option is to use the OWASP Juice Shop on a "hacking Friday"
-      - https://cheatsheetseries.owasp.org/    
+      - https://cheatsheetseries.owasp.org/
+    iso27001-2017:
+      - 7.2.2
   Regular security training for all:
     risk: Understanding security is hard.
     measure: Provide security awareness training for all personnel involved in software development on a regular basis like twice in a year for 1-3 days.
@@ -22,6 +24,8 @@ Education and Guidance:
     usefulness: 3
     level: 2
     samm: EG1-A
+    iso27001-2017:
+      - 7.2.2
     implementation:
       - In case you do not have the budget to hire an external security expert, an option is to use the OWASP Juice Shop on a "hacking Friday"
       - https://cheatsheetseries.owasp.org/
@@ -35,6 +39,11 @@ Education and Guidance:
     usefulness: 3
     level: 1
     samm: EG2-B
+    iso27001-2017:
+      - security consulting is missing in ISO 27001 may be
+      - 6.1.1
+      - 6.1.4
+      - 6.1.5
   Regular security training of security champions:
     risk: Understanding security is hard, even for security champions.
     measure: Regular security training of security champions.
@@ -45,6 +54,9 @@ Education and Guidance:
     usefulness: 3
     level: 2
     samm: EG2-B
+    iso27001-2017:
+      - security champions are missing in ISO 27001
+      - 7.2.2
   Regular security training for everyone:
     risk: "Understanding security is hard, for internal as well as external employees."
     measure: Regular security training for everyone.
@@ -55,7 +67,9 @@ Education and Guidance:
     usefulness: 3
     level: 3
     samm: EG2-B
-    implementation: Often, external employees are not invited for interal trainings. This activity focuses on providing security trainings to internal as well as external employees. It is conducted every two weeks for around one hour. 
+    iso27001-2017:
+      - 7.2.2
+    implementation: Often, external employees are not invited for interal trainings. This activity focuses on providing security trainings to internal as well as external employees. It is conducted every two weeks for around one hour.
   Each team has a security champion:
     risk: No one feels directly responsible for security and the security champion does not have enough time to allocate to each team.
     measure: Each team defines an individual to be responsible for security. These individuals are often referred to as 'security champions'
@@ -66,6 +80,10 @@ Education and Guidance:
     usefulness: 3
     level: 2
     samm: EG2-B
+    iso27001-2017:
+      - security champions are missing in ISO 27001 most likely
+      - 7.2.1
+      - 7.2.2
     implementation: https://www.owasp.org/index.php/Security_Champions_Playbook
   Security-Lessoned-Learned:
     risk: After an incident, a similar incident might reoccur.
@@ -77,6 +95,8 @@ Education and Guidance:
     usefulness: 3
     level: 3
     samm: IM-3, ST-3, SR2-B
+    iso27001-2017:
+      - 16.1.6
   Conduction of collaborative security checks with developers and system administrators:
     risk: Security checks by external companies do not increase the understanding of an application/system for internal employees.
     measure: Periodically security reviews of source code (SCA), in which security SME, developers and operations are involved, are effective at increasing the robustness of software and the security knowledge of the teams involved.
@@ -87,6 +107,11 @@ Education and Guidance:
     usefulness: 3
     level: 3
     samm: IR1-B
+    iso27001-2017:
+      - Mutual review of source code is not explicitly required in ISO 27001 may be
+      - 7.2.2
+      - 12.6.1
+      - 12.7.1
   Conduction of collaborative team security checks:
     risk: Development teams limited insight over security practices.
     measure: Mutual security testing the security of other teams's project enhances security awareness and knowledge.
@@ -97,6 +122,9 @@ Education and Guidance:
     usefulness: 2
     level: 4
     samm: EG2-A
+    iso27001-2017:
+      - Mutual scurity testing is not explicitly required in ISO 27001 may be
+      - 7.2.2
   Conduction of build-it, break-it, fix-it contests:
     risk: Understanding security is hard, even for security champions and the conduction of security training often focuses on breaking a component instead of building a component secure.
     measure: The build-it, break-it, fix-it contest allows to train people with security related roles like security champions the build, break and fix part of a secure application. This increases the learning of building secure components.
@@ -106,6 +134,8 @@ Education and Guidance:
       resources: 1
     usefulness: 3
     level: 3
+    iso27001-2017:
+      - 7.2.2
     implementation: https://builditbreakit.org/
   Conduction of war games:
     risk: Understanding incident response plans during an incident is hard and ineffective.
@@ -116,6 +146,11 @@ Education and Guidance:
       resources: 5
     usefulness: 2
     level: 4
+    iso27001-2017:
+      - ware games are not explicitly required in ISO 27001 may be
+      - 7.2.2
+      - 16.1
+      - 16.1.5
   Reward of good communication:
     risk: Employees are not getting excited about security.
     measure: Good communication and transparency encourages cross-organisational support. Gamification of security is also known to help, examples include T-Shirts, mugs, cups, giftcards and 'High-Fives'.
@@ -125,6 +160,9 @@ Education and Guidance:
       resources: 1
     usefulness: 3
     level: 2
+    iso27001-2017:
+      - not required by ISO 27001
+      - interestingly enough A7.2.3 is requiring a process to handle misconduct but nothing to promote good behavior.
     implementation: 
       - Enhance motivation can be performed with the distribution of pins as a reward, see OWASP Security Pins Project
       - https://owaspsamm.org/presentations/OWASP_Top_10_Maturity_Categories_for_Security_Champions.pptx
@@ -139,6 +177,8 @@ Education and Guidance:
     usefulness: 5
     level: 4
     samm: EG2-B
+    iso27001-2017:
+      - 7.1.1
 Culture and Org.:
   Conduction of advanced threat modelling:
     risk: Inadequate identification of business and technical risks.
@@ -150,6 +190,11 @@ Culture and Org.:
     usefulness: 3
     level: 4
     samm: TA2-B
+    iso27001-2017:
+      - not explicitly covered by ISO 27001
+      - may be part of risk assessment
+      - 8.2.1
+      - 14.2.1
   Conduction of simple threat modelling on business level:
     risk: Business related threats are discovered too late in the development and deployment process.
     measure: Threat modelling of business functionality is performed during the product backlog creation to facilitate early detection of security defects.
@@ -160,6 +205,11 @@ Culture and Org.:
     usefulness: 3
     level: 3
     samm: TA1-A
+    iso27001-2017:
+      - not explicitly covered by ISO 27001
+      - may be part of risk assessment
+      - 8.2.1
+      - 14.2.1
   Conduction of simple threat modelling on technical level:
     risk: Technical related threats are discovered too late in the development and deployment process.
     measure: Threat modelling of technical features is performed during the product sprint planning.
@@ -170,6 +220,11 @@ Culture and Org.:
     usefulness: 3
     level: 3
     samm: TA1-A
+    iso27001-2017:
+      - not explicitly covered by ISO 27001
+      - may be part of risk assessment
+      - 8.2.1
+      - 14.2.1
   Creation of advanced abuse stories:
     risk: Simple user stories are not going deep enough. Relevant security considerations are performed. Security flaws are discovered too late in the development and deployment process
     measure: Advanced abuse stories are created as part of threat modelling activities.
@@ -182,6 +237,12 @@ Culture and Org.:
     dependsOn:
       - "Creation of simple abuse stories"
     samm: TA2-A
+    iso27001-2017:
+      - not explicitly covered by ISO 27001
+      - may be part of project management
+      - 6.1.5
+      - may be part of risk assesment
+      - 8.1.2
     implementation: "Don't Forget EVIL User Stories and Practical Security Stories and Security Tasks for Agile Development Environments"
   Creation of simple abuse stories:
     risk: User stories mostly don't consider security implications. Security flaws are discovered too late in the development and deployment process.
@@ -193,6 +254,12 @@ Culture and Org.:
     usefulness: 4
     level: 2
     samm: TA2-A
+    iso27001-2017:
+      - not explicitly covered by ISO 27001
+      - may be part of project management
+      - 6.1.5
+      - may be part of risk assesment
+      - 8.1.2
     implementation: Don't Forget EVIL User Stories and Practical Security Stories and Security Tasks for Agile Development Environments
   Information security targets are communicated:
     risk: Employees don't known their organisation security targets. Therefore security is not considered during development and administration as much as it should be.
@@ -204,6 +271,9 @@ Culture and Org.:
     usefulness: 4
     level: 1
     samm: SM1-B
+    iso27001-2017:
+      - 5.1.1
+      - 7.2.1
 Process:
   #  Data classification:
   Definition of simple BCDR practices for critical components:
@@ -215,7 +285,8 @@ Process:
       resources: 2
     usefulness: 4
     level: 1
-
+    iso27001-2017:
+      - 17.1.1
   Definition of a change management process:
     risk: The impact of a change is not controlled because these are not recorded or documented.
     measure: Each change of a system is automatically recorded and adequately logged.
@@ -225,7 +296,10 @@ Process:
       resources: 1
     usefulness: 3
     level: 3
-
+    iso27001-2017:
+      - 14.2.2
+      - 12.1.2
+      - 12.4.1
   Approval by reviewing any new version:
     risk: An individual might forget to implement security measures to protect source code or infrastructure components.
     measure: On each new version (e.g. Pull Request) of source code or infrastructure components a security peer review of the changes is performed (two eyes principle) and approval given by the reviewer.
@@ -236,7 +310,10 @@ Process:
     usefulness: 3
     level: 3
     samm: IR1-B
-
+    iso27001-2017:
+      - peer review - four eyes principle is not explicitly required by ISO 27001
+      - 6.1.2
+      - 14.2.1
   #  Used licenses of components are known:
 
   Prevention of unauthorized installation:
@@ -248,6 +325,9 @@ Process:
       resources: 1
     usefulness: 3
     level: 3
+    iso27001-2017:
+      - 12.5.1
+      - 12.6.1
     implementation: "Example: All docker images used by teams need to be based on standard images."
     comment: "By preventing teams from trying out new components, innovation might be hampered"
 
diff --git a/data/Informationgathering.yml b/data/Informationgathering.yml
index 4f0f9ebec..84771dae2 100755
--- a/data/Informationgathering.yml
+++ b/data/Informationgathering.yml
@@ -13,6 +13,8 @@ Monitoring:
     - Simple application metrics
     - Visualized metrics
     samm2: o-incident-management|A|2
+    iso27001-2017:
+      - 12.1.3
   Advanced webapplication metrics:
     risk: People are not looking into tests results. Vulnerabilities not recolonized, even they are detected by tools.
     measure: All defects from the dimension Test- and Verification are instrumented.
@@ -26,6 +28,8 @@ Monitoring:
     - Simple application metrics
     - Visualized metrics
     samm2: o-incident-management|A|2
+    iso27001-2017:
+      - 12.6.1
   Alerting:
     risk: Incidents are discovered after they happend.
     measure: Thresholds for metrics are set. In case the thresholds are reached, alarms are send out. Which should get attention due to the critically.
@@ -39,6 +43,10 @@ Monitoring:
     - Visualized metrics
     samm2: o-operational-management|B|3
     samm: OE1-B
+    iso27001-2017:
+      - 16.1.2
+      - 16.1.4
+      - 12.1.4
   Coverage and control metrics:
     risk: The effectiveness of configuration, patch and vulnerability management is unknown.
     measure: "Usage of Coverage- and control-metrics to show the effectiveness of the security program. Coverage is the degree in \n        which a specific security control for a specific target group is applied with all resources.\n        The control degree shows the actual application of security standards and security-guidelines. Examples are gathering information on anti-virus, anti-rootkits, patch management, server configuration and vulnerability management."
@@ -52,6 +60,8 @@ Monitoring:
     - Visualized metrics
     implementation: https://ht.transparencytoolkit.org/FileServer/FileServer/OLD%20Fileserver/books/SICUREZZA/Addison.Wesley.Security.Metrics.Mar.2007.pdf
     samm2: o-incident-management|A|2
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
   Deactivation of unused metrics:
     risk: High resources are used while gathering unused metrics.
     measure: Deactivation of unused metrics helps to free resources.
@@ -64,6 +74,9 @@ Monitoring:
     dependsOn:
     - Visualized metrics
     samm2: o-incident-management|A|1
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 12.1.3
   Defence metrics:
     risk: IDS/IPS systems like packet- or application-firewalls detect and prevent attacks. It is not known how many attacks has been detected and blocked.
     measure: Gathering of defence metrics like TCP/UDP sources enables to assume the geographic location of the request.
@@ -76,6 +89,9 @@ Monitoring:
     dependsOn:
     - Visualized metrics
     samm2: o-incident-management|A|2
+    iso27001-2017:
+      - 12.4.1
+      - 13.1.1
   Grouping of metrics:
     risk: The analysis of metrics takes long.
     measure: Meaningful grouping of metrics helps to speed up analysis.
@@ -86,6 +102,9 @@ Monitoring:
     usefulness: 2
     level: 3
     samm2: o-incident-management|A|2
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 12.1.3
   Metrics are combined with tests:
     risk: Changes might cause high load due to programming errors.
     measure: Metrics during tests helps to identify programming errors.
@@ -98,6 +117,8 @@ Monitoring:
     dependsOn:
     - Grouping of metrics
     samm2: o-incident-management|A|2
+    iso27001-2017:
+      - not explicitly covered by ISO 27001
   Screens with metric visualization:
     risk: Security related information is discovered too late during an incident.
     measure: By having an internal accessible screen with a security related dashboards helps to visualize incidents.
@@ -110,6 +131,9 @@ Monitoring:
     dependsOn:
     - Grouping of metrics
     samm2: o-incident-management|A|2
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 16.1.5
   Simple application metrics:
     risk: Attacks on an application are not recognized.
     measure: Gathering of application metrics helps to identify incidents like brute force attacks, login/logout.
@@ -121,6 +145,8 @@ Monitoring:
     level: 1
     implementation: Prometheus
     samm2: o-incident-management|A|1
+    iso27001-2017:
+      - 12.4.1
   Simple system metrics:
     risk: Without simple metrics analysis of incidents are hard. In case an application uses a lot of CPU from time to time, it is hard for a developer to find out the source with linux commands.
     measure: Gathering of system metrics helps to identify incidents and specially bottlenecks like in CPU usage, memory usage and hard disk usage.
@@ -132,6 +158,8 @@ Monitoring:
     level: 1
     implementation: collectd
     samm2: o-incident-management|A|1
+    iso27001-2017:
+      - 12.1.3
   Targeted alerting:
     risk: People are bored (ignorant) of incident alarm messages, as they are not responsible to react.
     measure: By the definition of target groups for incidents people are only getting alarms for incidents they are in charge for.
@@ -145,6 +173,9 @@ Monitoring:
     - Alerting
     samm: OE1-B
     samm2: o-operational-management|B|3
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 16.1.5
   Visualized metrics:
     risk: Not visualized metrics lead to restricted usage of metrics.
     measure: Metrics are visualized in real time in a user friendly way.
@@ -158,6 +189,8 @@ Monitoring:
     - Simple application metrics
     - Simple system metrics
     samm2: o-incident-management|A|2
+    iso27001-2017:
+      - 12.1.3
 Logging:
   Centralized application logging:
     risk: Local stored logs can be unauthorized manipulated by attackers with system access or might be corrupt after an incident. In addition, it is hard to perform an correlation of logs. This leads attacks, which can be performed silently.
@@ -173,6 +206,9 @@ Logging:
     - Alerting
     samm: SA2-B
     samm2: o-incident-management|A|1
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 12.4.1
   PII logging concept:
     risk: Personal identifiable information (PII) is logged and the law of GDPR is not followed.
     measure: A concept how to log PII is documented and applied.
@@ -184,6 +220,10 @@ Logging:
     level: 1
     implementation: rsyslog, logstash, fluentd, bash
     samm2: o-incident-management|A|1
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 12.4.1
+      - 18.1.1
   Logging of security events:
     risk: No track of security-relevant events makes it harder to analyse an incident.
     measure: Security-relevant events like login/logout or creation, change, deletion of users should be logged.
@@ -197,6 +237,8 @@ Logging:
       - PII logging concept
     implementation: rsyslog, logstash, fluentd, bash
     samm2: o-incident-management|A|1
+    iso27001-2017:
+      - 12.4.1
   Centralized system logging:
     risk: Local stored system logs can be unauthorized manipulated by attackers or might be corrupt after an incident. In addition, it is hard to perform a aggregation of logs.
     measure: By using centralized logging logs are protected against unauthorized modification.
@@ -208,6 +250,9 @@ Logging:
     level: 1
     implementation: rsyslog, Logstash
     samm2: o-incident-management|A|1
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 12.4.1
   Correlation of security events:
     risk: Detection of security related events with hints on different systems/tools/metrics is not possible.
     measure: Events are correlated on one system. For example the correlation and visualisation of failed login attempts combined with successful login attempts.
@@ -221,6 +266,9 @@ Logging:
     - Visualized logging
     - Alerting
     samm2: o-incident-management|A|2
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 12.4.1
   Visualized logging:
     risk: System and application protocols are not visualized properly which leads to no or very limited logging assessment. Specially developers might have difficulty to read applications logs with unusually tools like the Linux tool 'cat'
     measure: Protocols are visualized in a simple to use real time monitoring system. The GUI gives the ability to search for special attributes in the protocol.
@@ -235,4 +283,7 @@ Logging:
     - Centralized application logging
     implementation: ELK-Stack
     samm2: o-incident-management|A|1
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 12.4.1
 ...
diff --git a/data/Infrastructure.yml b/data/Infrastructure.yml
index 321c8a443..bcb61b563 100755
--- a/data/Infrastructure.yml
+++ b/data/Infrastructure.yml
@@ -14,6 +14,9 @@ Infrastructure Hardening:
       - CIS Docker Bench for Security
       - "For example for Containers: Deny running containers as root, deny using advanced privileges, deny mounting of the hole filesystem, ..."
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - system hardening is not explicitly covered by ISO 27001 - too specific
+      - 13.1.3
   Applications are running in virtualized environments:
     risk: Through a vulnerability in one service on a server, the attacker gains access to other services running on the same server.
     measure: Applications are running in a dedicated and isolated virtualized environments.
@@ -24,6 +27,9 @@ Infrastructure Hardening:
     usefulness: 3
     level: 2
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - virtual environments are not explicitly covered by ISO 27001 - too specific
+      - 13.1.3
   Checking the sources of used libraries:
     risk: Application and system libraries can have implementation flaws or deployment flaws.
     measure: Each libraries source is checked to have a trusted source.
@@ -35,6 +41,10 @@ Infrastructure Hardening:
     level: 2
     samm: SA1-A
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 14.2.1
+      - 14.2.5
   Segmented networks for virtual environments:
     risk: Virtual environments in default settings are able to access other virtual environments on the network stack. By using virtual machines, it is often possible to connect to other virtual machines. By using docker, one bridge is used by default so that all containers on one host can communicate with each other.
     measure: The communication between virtual environments is regulated.
@@ -50,6 +60,9 @@ Infrastructure Hardening:
       - bridges
       - firewalls
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - virtual environments are not explicitly covered by ISO 27001 - too specific
+      - 13.1.3
   Infrastructure as Code:
     risk: No tracking of changes in systems might lead to errors in the configuration. In additions, it might lead to unauthorized changes. An examples is jenkins.
     measure: Systems are setup by code. A full environment can be provisioned. In addition, software like Jenkins 2 can be setup and configured in in code too. The code should be stored in a version control system.
@@ -61,6 +74,10 @@ Infrastructure Hardening:
     level: 3
     implementation: GitOps, Ansible, Chef, Puppet, Jenkinsfile
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 12.1.1
+      - 12.1.2
   Limitation of system calls in virtual environments:
     risk: System calls in virtual environments like docker can lead to privilege escalation.
     measure: System calls in virtual environments like docker are audited and limited.
@@ -74,6 +91,8 @@ Infrastructure Hardening:
     - Applications are running in virtualized environments
     implementation: seccomp, strace
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - system hardenong is not explicitly covered by ISO 27001 - too specific
   Immutable Infrastructure:
     risk: The availability of IT systems might be disturbed due to components failures
     measure: Redundancies in the IT systems
@@ -88,6 +107,9 @@ Infrastructure Hardening:
       - Usage of Semantic Versioning for components like project images
     implementation: Remove direct access to infrastructure
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 17.2.1
   Microservice-Architecture:
     risk: Monolithic applications are hard to test.
     measure: A microservice-architecture helps to have small components, which are more easy to test.
@@ -99,6 +121,8 @@ Infrastructure Hardening:
     level: 4
     samm: SA2
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - not explicitly covered by ISO 27001
   Production near environments are used by developers:
     risk: In case an errors occurs in production, the developer need to be able to create a production near environment on a local development environment.
     measure: Usage of infrastructure as code helps to create a production near environment. The developer needs to be trained in order to setup a local development environment. In addition, it should be possible to create production like test data. Often personal identifiable information is anonymized in order to comply with data protection laws.
@@ -113,6 +137,9 @@ Infrastructure Hardening:
     - Infrastructure as Code
     samm: SA1
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - 12.1.4
+      - 17.2.1
   Role based authentication and authorization:
     risk: Everyone is able to get unauthorized access to information on systems or to modify information unauthorized on systems.
     measure: The usage of a (role based) access control helps to restrict system access to authorized users.
@@ -127,6 +154,8 @@ Infrastructure Hardening:
     - Defined deployment process
     - Defined build process
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - 9.4.1
   2FA:
     risk: One factor authentication is more vulnerable to brute force attacks and is considered less secure.
     measure: Two factor authentication for all privileged accounts on systems and applications
@@ -138,6 +167,11 @@ Infrastructure Hardening:
     level: 3
     implementation: Smartcard, YubiKey, SMS, TOTP
     samm2: "TODO"
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 9.1.1
+      - 9.4.2
+      - 14.2.5
   Simple access control for systems:
     risk: Attackers a gaining access to internal systems and application interfaces
     measure: All internal systems are using simple authentication
@@ -152,6 +186,8 @@ Infrastructure Hardening:
     implementation: HTTP-Basic Authentication, TLS, VPN
     samm: EH1-B
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - 9.4.1
   Usage of a chaos monkey:
     risk: Due to manuel changes on a system, they are not replaceable anymore. In case of a crash it might happen that a planned redundant system is unavailable. In addition, it is hard to replay manual changes.
     measure: A randomized periodically shutdown of systems makes sure, that nobody will perform manual changes to a system.
@@ -162,6 +198,9 @@ Infrastructure Hardening:
     usefulness: 3
     level: 4
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 17.1.3
   Usage of security by default for components:
     risk: Components (images, libraries, applications) are not hardened.
     measure: Hardening of components is important, specially for image on which other teams base on. Hardening should be performed on the operation system and on the services inside (e.g. Nginx or a Java-Application).
@@ -176,6 +215,8 @@ Infrastructure Hardening:
     dependsOn:
     - Defined build process
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
   Usage of test and production environments:
     risk: Security tests are not running regularly because test environments are missing
     measure: A production and a production like envirnoment is used
@@ -188,6 +229,10 @@ Infrastructure Hardening:
     dependsOn:
     - Defined deployment process
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 12.1.4
+      - 17.2.1
   versioning:
     risk: Changes to production systems can not be undone.
     measure: versioning of artifacts related to production environments. For example Jenkins configuration, docker images, system provisioning code.
@@ -200,6 +245,11 @@ Infrastructure Hardening:
     dependsOn:
     - Defined deployment process
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 12.1.1
+      - 12.1.2
+      - 14.2.2
   Virtual environments are limited:
     risk: Denial of service (internally by an attacker or unintentionally by a bug) on one service effects other services
     measure: All virtual environments are using resource limits on hard disks, memory and CPU
@@ -212,4 +262,9 @@ Infrastructure Hardening:
     dependsOn:
     - Applications are running in virtualized environments
     samm2: o-environment-management|A|1
+    iso27001-2017:
+      - virtual environments are not explicitly covered by ISO 27001 - too specific
+      - 12.1.3
+      - 13.1.3
+      - 17.2.1
 ...
diff --git a/data/TestandVerification.yml b/data/TestandVerification.yml
index 1c52a3713..67e885be0 100755
--- a/data/TestandVerification.yml
+++ b/data/TestandVerification.yml
@@ -11,6 +11,9 @@ Dynamic depth for applications:
     level: 4
     implementation: OWASP Code Pulse
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - part of periodic review, PDCA
   Coverage of client side dynamic components:
     risk: Parts of the service are not covered during the scan, because JavaScript is not getting executed. Therefore, the co
     measure: Usage of a spider which executes dynamic content like JavaScript, e.g. via Selenium.
@@ -24,6 +27,9 @@ Dynamic depth for applications:
     - Usage of different roles
     samm: ST-2
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 14.2.3
+      - 14.2.8
     implementation: Ajax Spider
   Coverage of hidden endpoints:
     risk: Hidden endpoints of the service are not getting tracked.
@@ -38,6 +44,8 @@ Dynamic depth for applications:
     dependsOn:
     - Usage of different roles
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
   Coverage of more input vectors:
     risk: Parts of the service are not covered. For example specially formatted or coded parameters are not getting detected as parameter (e.g. parameters in REST-like URLs, parameters in JSON-Format or base64-coded parameters).
     measure: Special parameter and special encodings are defined, so that they get fuzzed by the used vulnerability scanners.
@@ -50,6 +58,8 @@ Dynamic depth for applications:
     dependsOn:
     - Usage of different roles
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
   Coverage of sequential operations:
     risk: Sequential operations like workflows (e.g. login -> put products in the basket
     measure: Sequential operations are defined and checked by the vulnerability scanner in the defined order.
@@ -63,6 +73,9 @@ Dynamic depth for applications:
     dependsOn:
     - Usage of different roles
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 14.2.8
+      - 14.2.3
   Coverage of service to service communication:
     risk: Service to service communication is not covered.
     measure: Service to service communication is dumped and checked.
@@ -75,6 +88,9 @@ Dynamic depth for applications:
     dependsOn:
     - Simple Scan
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 14.2.3
+      - 14.2.8
   Simple Scan:
     risk: Deficient security tests are performed. Simple vulnerabilities are not detected and missing security configurations (e.g. headers) are not set. Fast feedback is not given.
     measure: A simple scan is performed to get a security baseline. In case the test is done in under 10 minutes, it should be part of the build and deployment process.
@@ -91,6 +107,9 @@ Dynamic depth for applications:
     - OWASP Zap
     - Arachni
     samm2: v-security-testing|A|1
+    iso27001-2017:
+      - 14.2.3
+      - 14.2.8
   Usage of different roles:
     risk: Parts of the service are not covered during the scan, because a login is not performed.
     measure: Integration of authentication with all roles used in the service.
@@ -103,6 +122,10 @@ Dynamic depth for applications:
     dependsOn:
     - Simple Scan
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 14.2.3
+      - 14.2.8
   Usage of multiple scanners:
     risk: Each vulnerability scanner has different opportunities. By using just one scanner, some vulnerabilities might not be found.
     measure: Usage of multiple spiders and scanner enhance the coverage and the vulnerabilities.
@@ -116,6 +139,9 @@ Dynamic depth for applications:
     - Usage of different roles
     implementation: SecureCodeBox
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 12.6.1
+      - 14.2.5
 Static depth for applications:
   Exclusion of source code duplicates:
     risk: Duplicates in source code might influence the stability of the application.
@@ -130,6 +156,10 @@ Static depth for applications:
     dependsOn:
     - Defined build process
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 14.2.1
+      - 14.2.5
   Static analysis for all components/libraries:
     risk: Used components like libraries and legacy applications might have vulnerabilities
     measure: Usage of a static analysis for all used components.
@@ -143,6 +173,8 @@ Static depth for applications:
     - "Static analysis for important client side components"
     - "Static analysis for important server side components"
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 12.6.1
   Static analysis for all self written components:
     risk: Parts in the source code of the frontend or middleware have vulnerabilities.
     measure: Usage of static analysis tools for all parts of the middleware and frontend.
@@ -158,6 +190,8 @@ Static depth for applications:
     - "Static analysis for important client side components"
     - "Static analysis for important server side components"
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 12.6.1
   Static analysis for important client side components:
     risk: Important parts in the source code of the frontend have vulnerabilities.
     measure: Usage of static analysis tools for important parts of the frontend are used. Static analysis uses for example string matching algorithms and/or dataflow analysis.
@@ -173,6 +207,8 @@ Static depth for applications:
     - jsprime
     - bdd-mobile-security-automation-framework
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 12.6.1
     dependsOn:
     - Defined build process
   Static analysis for important server side components:
@@ -188,6 +224,8 @@ Static depth for applications:
     dependsOn:
     - Defined build process
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 12.6.1
   Stylistic analysis:
     risk: False source code indenting might lead to vulnerabilities.
     measure: Analysis of compliance to style guides of the source code ensures that source code indenting rules are met.
@@ -199,6 +237,10 @@ Static depth for applications:
     level: 4
     implementation: PMD
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 12.6.1
+      - 14.2.1
+      - 14.2.5
   Test of client side components with known vulnerabilities:
     risk: Client side components might have vulnerabilities.
     measure: Tests for known vulnerabilities in components of the frontend are performed.
@@ -214,6 +256,8 @@ Static depth for applications:
       - retire.js
       - npm audit
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 12.6.1
   Test of server side components with known vulnerabilities:
     risk: Server side components might have vulnerabilities.
     measure: Tests for known vulnerabilities in server side components (e.g. backend/middleware) are performed.
@@ -228,6 +272,8 @@ Static depth for applications:
     implementation: OWASP Dependency Check
     samm: SA
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 12.6.1
   Usage of multiple analysers:
     risk: Each vulnerability analyser has different opportunities. By using just one analyser, some vulnerabilities might not be found.
     measure: Usage of multiple static tools to find more vulnerabilities.
@@ -238,6 +284,10 @@ Static depth for applications:
     usefulness: 1
     level: 4
     samm2: v-security-testing|A|3
+    iso27001-2017:
+      - 12.6.1
+      - 14.2.1
+      - 14.2.5
     dependsOn:
     - "Test of server side components with known vulnerabilities"
     - "Test of client side components with known vulnerabilities"
@@ -253,6 +303,12 @@ Test-Intensity:
     usefulness: 2
     level: 3
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 14.2.2
+      - 14.2.3
+      - 14.2.1
+      - 14.2.5
+      - 12.6.1
   Deactivating of unneeded tests:
     risk: As tools cover a wide range of different vulnerability tests, they might not match the used components. Therefore, they need more time and resources as they need and the feedback loops takes too much time.
     measure: Unneeded tests are deactivated. For example in case the service is using a Mongo database and no mysql database, the dynamic scan doesn't need to test for sql injections.
@@ -263,6 +319,10 @@ Test-Intensity:
     usefulness: 1
     level: 2
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 12.6.1
+      - 14.2.1
+      - 14.2.5
   Default settings for intensity:
     risk: Time pressure and ignorance might lead to false predictions for the test intensity.
     measure: The intensity of the used tools are not modified to safe time.
@@ -273,6 +333,10 @@ Test-Intensity:
     usefulness: 1
     level: 1
     samm2: v-security-testing|A|1
+    iso27001-2017:
+      - 12.6.1
+      - 14.2.1
+      - 14.2.5
   High test intensity:
     risk: A too small intensity or a too high confidence might lead to not visible vulnerabilities.
     measure: A deep scan with high test intensity and a low confidence threshold is performed.
@@ -283,6 +347,10 @@ Test-Intensity:
     usefulness: 3
     level: 1
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 12.6.1
+      - 14.2.1
+      - 14.2.5
 Consolidation:
   Advanced visualization of defects:
     risk: Correlation of the vulnerabilities of different tools to have an overview of the the overall security level per component/project/team is not given.
@@ -297,6 +365,11 @@ Consolidation:
     - OWASP Defect Dojo
     - Purify
     samm2: defect-management|B|1
+    iso27001-2017:
+      - 16.1.4
+      - 8.2.1
+      - 8.2.2
+      - 8.2.3
   Definition of quality gates:
     risk: Improper examination of vulnerabilities leads to no visibility at all.
     measure: Quality gates for found vulnerabilities are defined. In the start it is important to not overload the security analyst, therefore the recommendation is to start with alerting of high cirital vulnerabilities.
@@ -308,6 +381,10 @@ Consolidation:
     level: 1
     samm: "IR2-A"
     samm2: "i-defect-management|A|2"
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 12.6.1
+      - 16.1.4
     implementation: "See other actions, e.g. \"Treatment of defects with severity high\"."
   Integration of vulnerability issues into the development process:
     risk: To read console output of the build server to search for vulnerabilities might be difficult. Also, to check a vulnerability management system might not be a daily task for a developer.
@@ -320,6 +397,11 @@ Consolidation:
     level: 3
     implementation: "At SAST (Static Application Security Testing): Server-side / client-side teams can easily be recorded. With microservice architecture, individual microservices can be used usually Teams. At DAST (Dynamic Application Security Testing): vulnerabilities are classified and can be assigned to server-side and client-side teams."
     samm2: "i-defect-management|B|2"
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 16.1.4
+      - 16.1.5
+      - 16.1.6
   Reproducible defect tickets:
     risk: Vulnerability descriptions are hard to understand by staff from operations and development.
     measure: Vulnerabilities include the test procedure to give the staff from operations and development the ability to reproduce vulnerabilities. This enhances the understanding of vulnerabilities and therefore the fix have a higher quality.
@@ -331,6 +413,11 @@ Consolidation:
     level: 4
     implementation: Mozilla Zest
     samm2: i-defect-management|B|2
+    iso27001-2017:
+      - 16.1.4
+      - 8.2.1
+      - 8.2.2
+      - 8.2.3
   Simple false positive treatment:
     risk: As false positive occure during each test, all vulnerabilities might be ignored.
     measure: False positives are suppressed so they will not show up on the next tests again. Most security tools have the possibility to suppress false positives. A Vulnerability Management System might be used.
@@ -345,6 +432,9 @@ Consolidation:
     - Purify
     samm: IR2-A
     samm2: i-defect-management|A|2
+    iso27001-2017:
+      - not explicitly covered by ISO 27001 - too specific
+      - 16.1.6
   Simple visualization of defects:
     risk: The security level of a component is not visible. Therefore, the motivation to enhance the security is not give.
     measure: Vulnerabilities are simple visualized.
@@ -360,6 +450,11 @@ Consolidation:
     - OWASP Defect Dojo
     - Purify
     samm2: i-defect-management|B|1
+    iso27001-2017:
+      - 16.1.4
+      - 8.2.1
+      - 8.2.2
+      - 8.2.3
   Treatment of all defects:
     risk: Vulnerabilities with severity low are not visible.
     measure: All vulnerabilities are added to the quality gate.
@@ -369,7 +464,10 @@ Consolidation:
       resources: 1
     usefulness: 2
     level: 4
-  samm2: i-defect-management|B|2
+    samm2: i-defect-management|B|2
+    iso27001-2017:
+    - 16.1.4
+    - 12.6.1
   Treatment of defects with severity high or higher:
     risk: Vulnerabilities with severity high or higher are not visible.
     measure: Vulnerabilities with severity high or higher are added to the quality gate.
@@ -381,6 +479,9 @@ Consolidation:
     level: 1
     comment: False positive analysis, specially for static analysis, is time consuming.
     samm2: i-defect-management|B|2
+    iso27001-2017:
+      - 16.1.4
+      - 12.6.1
   Treatment of defects with severity middle:
     risk: Vulnerabilities with severity middle are not visible.
     measure: Vulnerabilities with severity middle are added to the quality gate.
@@ -392,6 +493,9 @@ Consolidation:
     level: 3
     comment: False positive analysis, specially for static analysis, is time consuming.
     samm2: i-defect-management|B|2
+    iso27001-2017:
+      - 16.1.4
+      - 12.6.1
   Usage of a vulnerability management system:
     risk: Maintenance of false positives in each tool enforces a high workload. In addition a correlation of the same finding from different tools is not possible.
     measure: Aggregation of vulnerabilities in one tool reduce the workload to mark false positives.
@@ -405,6 +509,12 @@ Consolidation:
     - OWASP Defect Dojo
     - Purify
     samm2: i-defect-management|B|1
+    iso27001-2017:
+      - 12.6.1
+      - 16.1.3
+      - 16.1.4
+      - 16.1.5
+      - 16.1.6
 Application tests:
   High coverage of security related module and integration tests:
     risk: Vulnerabilities are rising due to code changes in a complex microservice environment in not important components.
@@ -417,6 +527,9 @@ Application tests:
     level: 4
     samm: ST2-B
     samm2: v-security-testing|B|3
+    iso27001-2017:
+      - 14.2.3
+      - 14.2.8
   Security integration tests for important components:
     risk: Vulnerabilities are rising due to code changes in a complex microservice environment.
     measure: Implementation of essential security related integration tests. For example for authentication and authorization.
@@ -429,6 +542,9 @@ Application tests:
     implementation: HttpUnit
     samm: ST2-B
     samm2: v-security-testing|B|3
+    iso27001-2017:
+      - 14.2.3
+      - 14.2.8
   Security unit tests for important components:
     risk: Vulnerabilities are rising due to code changes.
     measure: Usage of unit tests to test important security related features like authentication and authorization.
@@ -444,6 +560,9 @@ Application tests:
     - Karma
     samm: ST2-B
     samm2: v-security-testing|B|3
+    iso27001-2017:
+      - 14.2.3
+      - 14.2.8
   Smoke Test:
     risk: During a deployment an error might happen which leads to non-availability of the system, a part of the system or a feature.
     measure: Integration tests are performed against the production environment after each deployment.
@@ -458,6 +577,9 @@ Application tests:
     - Defined deployment process
     samm: ST2-B
     samm2: v-security-testing|B|3
+    iso27001-2017:
+      - 14.2.3
+      - 14.2.8
 Dynamic depth for infrastructure:
   Load tests:
     risk: As it is unknown how many requests the systems and applications can serve, due to an unexpected load the availability is disturbed.
@@ -469,6 +591,10 @@ Dynamic depth for infrastructure:
     usefulness: 3
     level: 4
     samm2: v-security-testing|A|1
+    iso27001-2017:
+      - 12.1.3
+      - 14.2.3
+      - 14.2.8
   Test of the configuration of cloud environments:
     risk: Standard hardening practices for cloud environments are not performed leading to vulnerabilities.
     measure: With the help of tools the configuration of virtual environments are tested.
@@ -482,6 +608,11 @@ Dynamic depth for infrastructure:
       - kube-hunter
       - openVAS
     samm: EH2-B
+    iso27001-2017:
+      - system hardening is not explicitly covered by ISO 27001 - too specific
+      - 12.6.1
+      - 14.2.3
+      - 14.2.8
   Weak password test:
     risk: Weak passwords in components like applications or systems, specially for privileged accounts, lead to take over of that account.
     measure: Automatic brute force attacks are performed. Specially the usage of standard accounts like 'admin' and employee user-ids is recommended.
@@ -493,6 +624,8 @@ Dynamic depth for infrastructure:
     level: 3
     implementation: HTC Hydra
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 9.4.3
   Test network segmentation:
     risk: Wrong or no network segmentation of pods makes it easyer for an attacker to access a database and extract or modify data.
     measure: Integration of fine granulated network segmenation (also between pods in the same namespace)
@@ -505,6 +638,10 @@ Dynamic depth for infrastructure:
     implementation: netassert
     dependendsOn: Segmented networks for virtual environments
     samm2: v-security-testing|A|2
+    iso27001-2017:
+      - 13.1.3
+      - 14.2.3
+      - 14.2.8
 Static depth for infrastructure:
   Test the definition of virtualized environments:
     risk: The definition of virtualized environments (e.g. via Dockerfile) might contains unsecure configurations.
@@ -518,6 +655,12 @@ Static depth for infrastructure:
     implementation:
       - hadolint
     samm2: v-security-testing|A|1
+    iso27001-2017:
+      - system hardening, virtual environments are not explicitly covered by ISO 27001 - too specific
+      - 12.6.1
+      - 14.2.3
+      - 14.2.8
+      - 14.2.1
   Test cluster deployment resources:
     risk: The deployment configuration (e.g. kubernetes deployment resources) might contain unsecured configurations.
     measure: Test the deployment configuration for virtualized environments for unsecured configurations.
@@ -530,6 +673,11 @@ Static depth for infrastructure:
     implementation:
       - kubesec
     samm2: v-security-testing|A|1
+    iso27001-2017:
+      - system hardening is not explicitly covered by ISO 27001 - too specific
+      - 12.6.1
+      - 14.2.3
+      - 14.2.8
   Test of infrastructure components for known vulnerabilities:
     risk: "Infrastructure components might have vulnerabilities."
     measure: "Test for known vulnerabilities in infrastructure components. Often, the only way to respond to known vulnerabilities in operating system packages is to accept the risk and wait for a patch. As the patch needs to be applied fast when it is available, this activity depends on 'Usage of a maximum life for images'."
@@ -547,6 +695,9 @@ Static depth for infrastructure:
       - OpenSCAP
       - Vuls
     samm2: v-security-testing|A|1
+    iso27001-2017:
+      - 12.6.1
+      - 14.2.1
   Test the configuration of cloud environments:
     risk: Standard hardening practices for cloud environments are not performed leading to vulnerabilities.
     measure: With the help of tools the configuration of virtual environments are
@@ -561,6 +712,11 @@ Static depth for infrastructure:
      - kube-bench
     samm: EH2-B
     samm2: v-security-testing|A|1
+    iso27001-2017:
+      - system hardening is not explicitly covered by ISO 27001 - too specific
+      - 12.6.1
+      - 14.2.3
+      - 14.2.8
   Stored Secrets:
     risk: Stored secrets in git history, in container images or directly in code shouldn't exists because they might be read unauthorized.
     measure: Test for secrets in code, container images and history
@@ -574,6 +730,10 @@ Static depth for infrastructure:
       - truffleHog
       - go-pillage-registries
     samm2: v-security-testing|A|1
+    iso27001-2017:
+      - vcs usage is not explicitly covered by ISO 27001 - too specific
+      - 9.4.3
+      - 10.1.2
   Check for image lifetime:
     risk: Old container images in production indicate that patch management is not performed and therefore vulnerabilities might exists.
     measure: Check the image age of containers in production.
diff --git a/detail.php b/detail.php
index 46f3813e6..14ccfedee 100644
--- a/detail.php
+++ b/detail.php
@@ -89,7 +89,16 @@ function printDetail($dimension, $subdimension, $elementName, $dimensions, $repo
     if (array_key_exists("samm2", $element) && !empty($element['samm2'])) {
     	$samm = $element['samm2'];
     	echo "
OWASP SAMM 2 Mapping: $samm
";
-    }    
+    }
+    if (array_key_exists("iso27001-2017", $element) && !empty($element['iso27001-2017'])) {
+        echo "
ISO27001:2017 Controls Mapping:
";
+
+        echo "";
+    }
 }
 
 printDetail($dimension, $subdimension, $elementName, $dimensions);
\ No newline at end of file