| About |
2FA |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | 2FA |
| ns1:Measure | Two factor authentication for all privileged accounts on systems and applications |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.5 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-9.1.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-9.4.2 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
A patch policy is defined |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | A patch policy is defined |
| ns1:Measure | A patch policy for all artifacts (e.g. in images) is defined. How often is an image rebuilt? |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/environment-management/stream-b#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.5.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.5 |
| ns1:hasSubdimension |
Patch Management |
| About |
Ad-Hoc Security trainings for software developers |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Ad-Hoc Security trainings for software developers |
| ns1:Measure | Provide security awareness training for all personnel involved in software development Ad-Hoc. |
| ns1:assessment | |
| ns1:hasImplementation |
<a href=https://cheatsheetseries.owasp.org/ target="_blank"></a> OWASP Juice Shop |
| ns1:hasReference |
https://owaspsamm.org/model/governance/education-and-guidance/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-7.2.2 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Advanced availability and stability metrics |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Advanced availability and stability metrics |
| ns1:Measure | Advanced metrics are gathered in relation to availability and stability. For example unplanned downtime's per year. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/incident-management/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.3 |
| ns1:hasSubdimension |
Monitoring |
| About |
Advanced webapplication metrics |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Advanced webapplication metrics |
| ns1:Measure | All defects from the dimension Test- and Verification are instrumented. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/incident-management/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 |
| ns1:hasSubdimension |
Monitoring |
| About |
Alerting |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Alerting |
| ns1:Measure | Thresholds for metrics are set. In case the thresholds are reached, alarms are send out. Which should get attention due to the critically. |
| ns1:assessment | |
| ns1:hasReference |
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.4 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.4 |
| ns1:hasSubdimension |
Monitoring |
| About |
Aligning security in teams |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Aligning security in teams |
| ns1:Measure | By aligning security SME with project teams, a higher security standard can be achieved. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/governance/education-and-guidance/stream-b#3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-7.1.1 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Analyze logs |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Analyze logs |
| ns1:Measure | Check logs for keywords. |
| ns1:assessment | |
| ns1:hasImplementation |
SigmaHQ |
| ns1:hasSubdimension |
Static depth for infrastructure |
| About |
App. Hardening Level 2 |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | App. Hardening Level 2 |
| ns1:Measure |
Following frameworks like the
|
| ns1:assessment | |
| ns1:hasImplementation |
OWASP ASVS OWASP MASVS |
| ns1:hasReference |
hardening is not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/design/security-requirements/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.3 |
| ns1:hasSubdimension |
Application Hardening |
| About |
App. Hardening Level 3 |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | App. Hardening Level 3 |
| ns1:Measure |
Following frameworks like the
|
| ns1:assessment | |
| ns1:hasImplementation |
OWASP ASVS OWASP MASVS |
| ns1:hasReference |
hardening is not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/design/security-requirements/stream-a#3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.3 |
| ns1:hasSubdimension |
Application Hardening |
| About |
Application Hardening Level 1 |
| rdf:type |
ns1:Activity |
| rdfs:comment | To tackle the security of code developed in-house, OWASP offers an extensive collection of [Cheatsheets]() demonstrating how to implement features securely. Moreover, the Security Knowledge Framework[1] offers an extensive library of code patterns spanning several programming languages. These patterns can be used to not only jumpstart the development process, but also do so securely. [...] ### Planning aka Requirements Gathering & Analysis The Requirements gathering process tries to answer the question: _"What is the system going to do?"_ At this stage, the [SAMM project]() offers 3 distinct maturity levels covering both [in-house](design/security-requirements/stream-a/) software development and [third party](design/security-requirements/stream-b/) supplier security.  Organizations can use these to add solid security considerations at the start of the Software Development or Procurement process. These general security considerations can be audited by using a subsection of the ASVS controls in section V1 as a questionnaire. This process attempts to ensure that every feature has concrete security considerations. In case of internal development and if the organization maps Features to Epics, the [Security Knowledge Framework]() can be used to facilitate this process by leveraging its questionnaire function, shown below. Source: [OWASP Project Integration](index.md) |
| rdfs:label | Application Hardening Level 1 |
| ns1:Measure |
Following frameworks like the
|
| ns1:assessment | |
| ns1:hasImplementation |
API Security Maturity Model for Authorization OWASP ASVS OWASP MASVS |
| ns1:hasReference |
hardening is not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/design/security-requirements/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.3 |
| ns1:hasSubdimension |
Application Hardening |
| About |
Applications are running in virtualized environments |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Applications are running in virtualized environments |
| ns1:Measure | Applications are running in a dedicated and isolated virtualized environments. |
| ns1:assessment | |
| ns1:hasReference |
virtual environments are not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.3 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Approval by reviewing any new version |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Approval by reviewing any new version |
| ns1: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. |
| ns1:assessment | |
| ns1:hasReference |
peer review - four eyes principle is not explicitly required by ISO 27001
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-6.1.2 |
| ns1:hasSubdimension |
Process |
| About |
Automated PRs for patches |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Automated PRs for patches |
| ns1:Measure |
Fast patching of third party component is needed. The DevOps way is to have an automated pull request for new components. This includes
|
| ns1:assessment | |
| ns1:hasImplementation |
dependabot |
| ns1:hasReference |
https://owaspsamm.org/model/operations/environment-management/stream-b#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.5 |
| ns1:hasSubdimension |
Patch Management |
| About |
Backup |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Backup |
| ns1:Measure | Performing automated periodical backups are used. Backup before deployment can help facilitate deployments whilst testing the backup restore processes. |
| ns1:assessment | |
| ns1:hasReference |
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.6 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Blue/Green Deployment |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Blue/Green Deployment |
| ns1:Measure | By having multiple production environments, a deployment can be performant on the first environment to spot possible defects before it is deployment in the production environment(s) |
| ns1:assessment | |
| ns1:hasImplementation |
Blue/Green Deployments |
| ns1:hasReference |
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.4 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.5.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.9 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-17.2.1 |
| ns1:hasSubdimension |
Deployment |
| About |
Building and testing of artifacts in virtual environments |
| rdf:type |
ns1:Activity |
| rdfs:comment | While building and testing artifacts, third party systems, application frameworks and 3rd party libraries are used. These might be malicious as a result of vulnerable libraries or because they are altered during the delivery phase. |
| rdfs:label | Building and testing of artifacts in virtual environments |
| ns1:Measure | Each step during within the build and testing phase is performed in a separate virtual environments, which is destroyed afterward. |
| ns1:assessment | |
| ns1:hasImplementation |
CI/CD tools |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-build/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.6 |
| ns1:hasSubdimension |
Build |
| About |
Centralized application logging |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Centralized application logging |
| ns1:Measure | A centralized logging system is used and applications logs (including application exceptions) are shipped to it. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/incident-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.4.1 |
| ns1:hasSubdimension |
Logging |
| About |
Centralized system logging |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Centralized system logging |
| ns1:Measure | By using centralized logging logs are protected against unauthorized modification. |
| ns1:assessment | |
| ns1:hasImplementation |
logstash rsyslog |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/incident-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.4.1 |
| ns1:hasSubdimension |
Logging |
| About |
Check for malware |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Check for malware |
| ns1:Measure | Check for malware in components (e.g. container images, VM baseline images, libraries). |
| ns1:assessment | |
| ns1:hasImplementation |
ClusterScanner |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.2.1 |
| ns1:hasSubdimension |
Static depth for infrastructure |
| About |
Checking the sources of used libraries |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Checking the sources of used libraries |
| ns1:Measure | Each libraries source is checked to have a trusted source. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.5 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Conduction of advanced threat modeling |
| rdf:type |
ns1:Activity |
| rdfs:comment | **Example High Maturity Scenario:** Based on a detailed threat model defined and updated through code, the team decides the following: * Local encrypted caches need to expire and auto-purged. * Communication channels encrypted and authenticated. * All secrets persisted in shared secrets store. * Frontend designed with permissions model integration. * Permissions matrix defined. * Input is escaped output is encoded appropriately using well established libraries. Source: OWASP Project Integration Project |
| rdfs:label | Conduction of advanced threat modeling |
| ns1:Measure | Threat modeling is performed by using reviewing user stories and producing security driven data flow diagrams. |
| ns1:assessment | |
| ns1:hasImplementation |
Draw.io Miro (or any other collaborative board) OWASP SAMM Threagile Threat Matrix for Storage Threat Modeling Playbook Whiteboard |
| ns1:hasReference |
may be part of risk assessment not explicitly covered by ISO 27001
https://owaspsamm.org/model/design/threat-assessment/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-8.2.1 |
| ns1:hasSubdimension |
Design |
| About |
Conduction of build-it, break-it, fix-it contests |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Conduction of build-it, break-it, fix-it contests |
| ns1: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. |
| ns1:assessment | |
| ns1:hasImplementation |
Build it Break it Fix it Contest |
| ns1:hasReference |
https://owaspsamm.org/model/governance/education-and-guidance/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-7.2.2 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Conduction of collaborative security checks with developers and system administrators |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Conduction of collaborative security checks with developers and system administrators |
| ns1: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. |
| ns1:assessment | |
| ns1:hasReference |
Mutual review of source code is not explicitly required in ISO 27001 may be
https://owaspsamm.org/model/governance/education-and-guidance/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.7.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-7.2.2 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Conduction of collaborative team security checks |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Conduction of collaborative team security checks |
| ns1:Measure | Mutual security testing the security of other teams project enhances security awareness and knowledge. |
| ns1:assessment | |
| ns1:hasReference |
Mutual security testing is not explicitly required in ISO 27001 may be
https://owaspsamm.org/model/governance/education-and-guidance/stream-a#1 https://owaspsamm.org/model/governance/education-and-guidance/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-7.2.2 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Conduction of simple threat modeling on business level |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Conduction of simple threat modeling on business level |
| ns1:Measure | Threat modeling of business functionality is performed during the product backlog creation to facilitate early detection of security defects. |
| ns1:assessment | |
| ns1:hasReference |
may be part of risk assessment not explicitly covered by ISO 27001
https://owaspsamm.org/model/design/threat-assessment/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-8.2.1 |
| ns1:hasSubdimension |
Design |
| About |
Conduction of simple threat modeling on technical level |
| rdf:type |
ns1:Activity |
| rdfs:comment | # OWASP SAMM Description Threat modeling is a structured activity for identifying, evaluating, and managing system threats, architectural design flaws, and recommended security mitigations. It is typically done as part of the design phase or as part of a security assessment. Threat modeling is a team exercise, including product owners, architects, security champions, and security testers. At this maturity level, expose teams and stakeholders to threat modeling to increase security awareness and to create a shared vision on the security of the system. At maturity level 1, you perform threat modeling ad-hoc for high-risk applications and use simple threat checklists, such as STRIDE. Avoid lengthy workshops and overly detailed lists of low-relevant threats. Perform threat modeling iteratively to align to more iterative development paradigms. If you add new functionality to an existing application, look only into the newly added functions instead of trying to cover the entire scope. A good starting point is the existing diagrams that you annotate during discussion workshops. Always make sure to persist the outcome of a threat modeling discussion for later use. Your most important tool to start threat modeling is a whiteboard, smartboard, or a piece of paper. Aim for security awareness, a simple process, and actionable outcomes that you agree upon with your team. Once requirements are gathered and analysis is performed, implementation specifics need to be defined. The outcome of this stage is usually a diagram outlining data flows and a general system architecture. This presents an opportunity for both threat modeling and attaching security considerations to every ticket and epic that is the outcome of this stage. Source: # OWASP Project Integration Description There is some great advice on threat modeling out there *e.g.* [this]() article or [this](threatmodeling) one. A bite sized primer by Adam Shostack himself can be found [here](). OWASP includes a short [article](Category:Threat Modeling) on Threat Modeling along with a relevant [Cheatsheet](Threat Modeling Cheat Sheet.html). Moreover, if you're following OWASP SAMM, it has a short section on [Threat Assessment](). There's a few projects that can help with creating Threat Models at this stage, [PyTM](pytm) is one, [ThreatSpec](threatspec) is another. > Note: _A threat model can be as simple as a data flow diagram with attack vectors on every flow and asset and equivalent remediations. An example can be found below._  Last, if the organizations maps Features to Epics, the Security Knowledge Framework (SKF) can be used to facilitate this process by leveraging it's questionnaire function.  This practice has the side effect that it trains non-security specialists to think like attackers. The outcomes of this stage should help lay the foundation of secure design and considerations. **Example Low Maturity Scenario:** Following vague feature requirements the design includes caching data to a local unencrypted database with a hardcoded password. Remote data store access secrets are hardcoded in the configuration files. All communication between backend systems is plaintext. Frontend serves data over GraphQL as a thin layer between caching system and end user. GraphQL queries are dynamically translated to SQL, Elasticsearch and NoSQL queries. Access to data is protected with basic auth set to _1234:1234_ for development purposes. Source: OWASP Project Integration Project |
| rdfs:label | Conduction of simple threat modeling on technical level |
| ns1:Measure | Threat modeling of technical features is performed during the product sprint planning. |
| ns1:assessment | |
| ns1:hasImplementation |
Draw.io Miro (or any other collaborative board) OWASP SAMM Threat Matrix for Storage Threat Modeling Playbook Whiteboard |
| ns1:hasReference |
may be part of risk assessment not explicitly covered by ISO 27001
https://owaspsamm.org/model/design/threat-assessment/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-8.2.1 |
| ns1:hasSubdimension |
Design |
| About |
Conduction of war games |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Conduction of war games |
| ns1:Measure | War Games like activities help train for incidents. Security SMEs create attack scenarios in a testing environment enabling the trainees to learn how to react in case of an incident. |
| ns1:assessment | |
| ns1:hasReference |
ware games are not explicitly required in ISO 27001 may be
https://owaspsamm.org/model/governance/education-and-guidance/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.5 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-7.2.2 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Correlation of security events |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Correlation of security events |
| ns1:Measure | Events are correlated on one system. For example the correlation and visualization of failed login attempts combined with successful login attempts. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/incident-management/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.4.1 |
| ns1:hasSubdimension |
Logging |
| About |
Coverage analysis |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Coverage analysis |
| ns1:Measure | Check that there are no missing paths in the application with coverage-tools. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific part of periodic review, PDCA
https://owaspsamm.org/model/verification/security-testing/stream-a#2 |
| ns1:hasSubdimension |
Dynamic depth for applications |
| About |
Coverage and control metrics |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Coverage and control metrics |
| ns1:Measure | Usage of Coverage- and control-metrics to show the effectiveness of the security program. Coverage is the degree in which a specific security control for a specific target group is applied with all resources. 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. |
| ns1:assessment | |
| ns1:hasImplementation |
<a href=https://ht.transpare target="_blank">https://ht.transpare</a> |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/incident-management/stream-a#2 |
| ns1:hasSubdimension |
Monitoring |
| About |
Coverage of client side dynamic components |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Coverage of client side dynamic components |
| ns1:Measure | Usage of a spider which executes dynamic content like JavaScript, e.g. via Selenium. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Dynamic depth for applications |
| About |
Coverage of hidden endpoints |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Coverage of hidden endpoints |
| ns1:Measure | Hidden endpoints are getting detected and included in the vulnerability scan. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/verification/security-testing/stream-a#2 |
| ns1:hasSubdimension |
Dynamic depth for applications |
| About |
Coverage of more input vectors |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Coverage of more input vectors |
| ns1:Measure | Special parameter and special encodings are defined, so that they get fuzzed by the used vulnerability scanners. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/verification/security-testing/stream-a#2 |
| ns1:hasSubdimension |
Dynamic depth for applications |
| About |
Coverage of sequential operations |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Coverage of sequential operations |
| ns1:Measure | Sequential operations are defined and checked by the vulnerability scanner in the defined order. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Dynamic depth for applications |
| About |
Coverage of service to service communication |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Coverage of service to service communication |
| ns1:Measure | Service to service communication is dumped and checked. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Dynamic depth for applications |
| About |
Creation and application of a testing concept |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Creation and application of a testing concept |
| ns1:Measure | A testing concept considering the amount of time per scan/intensity is created and applied. A dynamic analysis needs more time than a static analysis. The dynamic scan, depending on the test intensity might be performed on every commit, every night, every week or once in a month. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.5 |
| ns1:hasSubdimension |
Test-Intensity |
| About |
Creation of advanced abuse stories |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Creation of advanced abuse stories |
| ns1:Measure | Advanced abuse stories are created as part of threat modeling activities. |
| ns1:assessment | |
| ns1:hasImplementation |
[Don't Forget EVIL U |
| ns1:hasReference |
may be part of project management may be part of risk assessment not explicitly covered by ISO 27001
https://owaspsamm.org/model/design/threat-assessment/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-6.1.5 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-8.1.2 |
| ns1:hasSubdimension |
Design |
| About |
Creation of simple abuse stories |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Creation of simple abuse stories |
| ns1:Measure | Abuse stories are created during the creation of user stories. |
| ns1:assessment | |
| ns1:hasImplementation |
[Don't Forget EVIL U |
| ns1:hasReference |
may be part of project management may be part of risk assessment not explicitly covered by ISO 27001
https://owaspsamm.org/model/design/threat-assessment/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-6.1.5 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-8.1.2 |
| ns1:hasSubdimension |
Design |
| About |
Creation of threat modeling processes and standards |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Creation of threat modeling processes and standards |
| ns1:Measure | Creation of threat modeling processes and standards through the organization helps to enhance the security culture and provide more structure to the threat model exercises. |
| ns1:assessment | |
| ns1:hasImplementation |
OWASP SAMM Threat Modeling Playbook |
| ns1:hasReference |
may be part of risk assessment not explicitly covered by ISO 27001
https://owaspsamm.org/model/design/threat-assessment/stream-b#3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-8.2.1 |
| ns1:hasSubdimension |
Design |
| About |
Deactivating of unneeded tests |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Deactivating of unneeded tests |
| ns1: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. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.5 |
| ns1:hasSubdimension |
Test-Intensity |
| About |
Deactivation of unused metrics |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Deactivation of unused metrics |
| ns1:Measure | Deactivation of unused metrics helps to free resources. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/incident-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.3 |
| ns1:hasSubdimension |
Monitoring |
| About |
Defense metrics |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Defense metrics |
| ns1:Measure | Gathering of defense metrics like TCP/UDP sources enables to assume the geographic location of the request. Assuming a Kubernetes cluster with an egress-traffic filter (e.g. IP/domain based), an alert might be send out in case of every violation. For ingress-traffic, alerting might not even be considered. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/incident-management/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.4.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.1 |
| ns1:hasSubdimension |
Monitoring |
| About |
Defined build process |
| rdf:type |
ns1:Activity |
| rdfs:comment | Sample evidence as an attribute in the yaml: The build process is defined in REPLACE-ME Pipeline in the folder vars. Projects are using a Jenkinsfile to use the defined process. |
| rdfs:label | Defined build process |
| ns1:Measure | A well defined build process lowers the possibility of errors during the build process. |
| ns1:assessment | - Show your build pipeline and an exemplary job (build + test). - Show that every team member has access. - Show that failed jobs are fixed. Credits: AppSecure-nrw [Security Belts]() |
| ns1:hasImplementation |
CI/CD tools |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-build/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.2 |
| ns1:hasSubdimension |
Build |
| About |
Defined decommissioning process |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Defined decommissioning process |
| ns1:Measure | By having a clear decommissioning process, applicaitons not used are not running anymore and can therefore not be explointed. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/operational-management/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-11.2.7 |
| ns1:hasSubdimension |
Deployment |
| About |
Defined deployment process |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Defined deployment process |
| ns1:Measure | A defined deployment process significantly lowers the likelihood of errors during the deployment phase. |
| ns1:assessment | |
| ns1:hasImplementation |
CI/CD tools Docker |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-deployment/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.2 |
| ns1:hasSubdimension |
Deployment |
| About |
Definition of a change management process |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Definition of a change management process |
| ns1:Measure | Each change of a system is automatically recorded and adequately logged. |
| ns1:assessment | |
| ns1:hasReference |
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.4.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.2 |
| ns1:hasSubdimension |
Process |
| About |
Definition of quality gates |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Definition of quality gates |
| ns1:Measure | Quality gates for found vulnerabilities are defined. In the beginning it is important to not overload the security analyst, therefore the recommendation is to start with alerting of high critical vulnerabilities. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/implementation/defect-management/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.4 |
| ns1:hasSubdimension |
Consolidation |
| About |
Definition of simple BCDR practices for critical components |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Definition of simple BCDR practices for critical components |
| ns1:Measure | By understanding and documenting a business continuity and disaster recovery (BCDR) plan, the overall availability of systems and applications is increased. Success factors like responsibilities, Service Level Agreements, Recovery Point Objectives, Recovery Time Objectives or Failover must be fully documented and understood. |
| ns1:assessment | |
| ns1:hasReference |
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-17.1.1 |
| ns1:hasSubdimension |
Process |
| About |
Each team has a security champion |
| rdf:type |
ns1:Activity |
| rdfs:comment | Implement a program where each software development team has a member considered a “Security Champion” who is the liaison between Information Security and developers. Depending on the size and structure of the team the “Security Champion” may be a software developer, tester, or a product manager. The “Security Champion” has a set number of hours per week for Information Security related activities. They participate in periodic briefings to increase awareness and expertise in different security disciplines. “Security Champions” have additional training to help develop these roles as Software Security subject-matter experts. You may need to customize the way you create and support “Security Champions” for cultural reasons. The goals of the position are to increase effectiveness and efficiency of application security and compliance and to strengthen the relationship between various teams and Information Security. To achieve these objectives, “Security Champions” assist with researching, verifying, and prioritizing security and compliance related software defects. They are involved in all Risk Assessments, Threat Assessments, and Architectural Reviews to help identify opportunities to remediate security defects by making the architecture of the application more resilient and reducing the attack threat surface. Source: [OWASP SAMM]() |
| rdfs:label | Each team has a security champion |
| ns1:Measure | Each team defines an individual to be responsible for security. These individuals are often referred to as 'security champions' |
| ns1:assessment | |
| ns1:hasImplementation |
OWASP Security Champions Playbook |
| ns1:hasReference |
security champions are missing in ISO 27001 most likely
https://owaspsamm.org/model/governance/education-and-guidance/stream-b#1 https://owaspsamm.org/model/governance/education-and-guidance/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-7.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-7.2.2 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Environment depending configuration parameters (secrets) |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Environment depending configuration parameters (secrets) |
| ns1:Measure | Configuration parameters are set for each environment not in the source code. By using encryption, it is harder to read credentials , e.g. from the file system. Also, the usage of a credential management system can help protect credentials. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-deployment/stream-b#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.6 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-9.4.5 |
| ns1:hasSubdimension |
Deployment |
| About |
Exclusion of source code duplicates |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Exclusion of source code duplicates |
| ns1:Measure | Automatic Detection and manual removal of duplicates in source code. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.5 |
| ns1:hasSubdimension |
Static depth for applications |
| About |
Filter outgoing traffic |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Filter outgoing traffic |
| ns1:Measure | Having a whitelist and explicitly allowing egress traffic provides the ability to stop unauthorized data leakage. |
| ns1:assessment | |
| ns1:hasReference |
virtual environments are not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.3 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Full Coverage of App. Hardening Level 3 |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Full Coverage of App. Hardening Level 3 |
| ns1:Measure |
Following frameworks like the
|
| ns1:assessment | |
| ns1:hasImplementation |
OWASP ASVS OWASP MASVS |
| ns1:hasReference |
hardening is not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/design/security-requirements/stream-a#3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.3 |
| ns1:hasSubdimension |
Application Hardening |
| About |
Grouping of metrics |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Grouping of metrics |
| ns1:Measure | Meaningful grouping of metrics helps to speed up analysis. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/incident-management/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.3 |
| ns1:hasSubdimension |
Monitoring |
| About |
Handover of confidential parameters |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Handover of confidential parameters |
| ns1:Measure | By using encryption, it is harder to read credentials , e.g. from the file system. Also, the usage of a credential management system can help protect credentials. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-deployment/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-10.1.2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.1.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-9.4.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-9.4.3 |
| ns1:hasSubdimension |
Deployment |
| About |
High coverage of security related module and integration tests |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | High coverage of security related module and integration tests |
| ns1:Measure | Implementation of security related tests via unit tests and integration tests. Including the test of libraries, in case the are not tested already. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-b#3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Application tests |
| About |
High test intensity |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | High test intensity |
| ns1:Measure | A deep scan with high test intensity and a low confidence threshold is performed. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.5 |
| ns1:hasSubdimension |
Test-Intensity |
| About |
Immutable Infrastructure |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Immutable Infrastructure |
| ns1:Measure | Redundancies in the IT systems |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-17.2.1 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Information security targets are communicated |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Information security targets are communicated |
| ns1:Measure | Transparent and timely communication of the security targets by senior management is essential to ensure teams' buy-in and support. |
| ns1:assessment | |
| ns1:hasReference |
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-5.1.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-7.2.1 |
| ns1:hasSubdimension |
Design |
| About |
Infrastructure as Code |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Infrastructure as Code |
| ns1: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. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.2 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Integration of vulnerability issues into the development process |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Integration of vulnerability issues into the development process |
| ns1:Measure | Vulnerabilities are tracked in the teams issue system (e.g. jira). |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/implementation/defect-management/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.4 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.5 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.6 |
| ns1:hasSubdimension |
Consolidation |
| About |
Inventory of running artifacts |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Inventory of running artifacts |
| ns1:Measure | A documented inventory or a possibility to gather the needed information. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-deployment/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-8.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-8.2 |
| ns1:hasSubdimension |
Deployment |
| About |
Isolated networks for virtual environments |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Isolated networks for virtual environments |
| ns1:Measure | The communication between virtual environments is controlled and regulated. |
| ns1:assessment | |
| ns1:hasReference |
virtual environments are not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.3 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Limitation of system calls in virtual environments |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Limitation of system calls in virtual environments |
| ns1:Measure | System calls in virtual environments like docker are audited and limited. |
| ns1:assessment | |
| ns1:hasReference |
system hardening is not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/environment-management/stream-a#1 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Local development linting & style checks performed |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Local development linting & style checks performed |
| ns1:Measure | Integration of quality and linting plugins with interactive development environment (IDEs). |
| ns1:assessment | |
| ns1:hasImplementation |
How to enforce a consistent coding style in your projects In-Depth Linting of Your TypeScript While Coding |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-1#A |
| ns1:hasSubdimension |
Development and Source Control |
| About |
Local development security checks performed |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Local development security checks performed |
| ns1:Measure | Integration of quality and linting plugins with interactive development environment (IDEs). |
| ns1:assessment | |
| ns1:hasImplementation |
Fortify Extension for Visual Studio Code HCL AppScan CodeSweep Setting Up the Visual Studio Code Extension Plugin |
| ns1:hasReference |
hardening is not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/verification/security-testing/stream-1#A https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.3 |
| ns1:hasSubdimension |
Static depth for applications |
| About |
Logging of security events |
| rdf:type |
ns1:Activity |
| rdfs:comment | Implement logging of security relevant events. The following events tend to be security relevant: - successful/failed login/logout - creation, change, and deletion of users - errors during input validation and output creation - exceptions and errors with security in their name - transactions of value (e.g., financial transactions, costly operations) - :unicorn: (special things of your application) |
| rdfs:label | Logging of security events |
| ns1:Measure | Security-relevant events like login/logout or creation, change, deletion of users should be logged. |
| ns1:assessment | - Show which events are logged. - Show a test for one event logging. |
| ns1:hasImplementation |
OWASP Logging CheatSheet logstash |
| ns1:hasReference |
https://owaspsamm.org/model/operations/incident-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.4.1 |
| ns1:hasSubdimension |
Logging |
| About |
Metrics are combined with tests |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Metrics are combined with tests |
| ns1:Measure | Metrics during tests helps to identify programming errors. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001
https://owaspsamm.org/model/operations/incident-management/stream-a#2 |
| ns1:hasSubdimension |
Monitoring |
| About |
Microservice-Architecture |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Microservice-Architecture |
| ns1:Measure | A microservice-architecture helps to have small components, which are more easy to test. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001
https://owaspsamm.org/model/operations/environment-management/stream-a#1 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Nightly build of images (base images) |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Nightly build of images (base images) |
| ns1:Measure | Custom base images are getting build at least nightly. In case the packages in the base image e.g. centos has changed, the build server triggers the build of depending images. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/environment-management/stream-b#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 |
| ns1:hasSubdimension |
Patch Management |
| About |
PII logging concept |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | PII logging concept |
| ns1:Measure | A concept how to log PII is documented and applied. |
| ns1:assessment | |
| ns1:hasImplementation |
logstash rsyslog |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/incident-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.4.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-18.1.1 |
| ns1:hasSubdimension |
Logging |
| About |
Pinning of artifacts |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Pinning of artifacts |
| ns1:Measure | Pinning of artifacts ensure that changes are performed only when intended. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-build/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.6 |
| ns1:hasSubdimension |
Build |
| About |
Pre-Commit checks and validations |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Pre-Commit checks and validations |
| ns1:Measure | Implement pre-commit validations to prevent secrets & other security issues being commit to source code. |
| ns1:assessment | |
| ns1:hasImplementation |
Building your DevSecOps pipeline 5 essential activities DevSecOps control Pre-commit |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-1#A |
| ns1:hasSubdimension |
Development and Source Control |
| About |
Prevention of unauthorized installation |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Prevention of unauthorized installation |
| ns1:Measure | Components must be whitelisted. Regular scans on the docker infrastructure (e.g. cluster) need to be performed, to verify that only standardized base images are used. |
| ns1:assessment | |
| ns1:hasReference |
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.5.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 |
| ns1:hasSubdimension |
Process |
| About |
Production near environments are used by developers |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Production near environments are used by developers |
| ns1: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. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.4 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-17.2.1 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Reduction of the attack surface |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Reduction of the attack surface |
| ns1:Measure | Removal of unneeded components, dependencies, files or file access rights. For container images the usage of distroless images is recommended. |
| ns1:assessment | |
| ns1:hasImplementation |
Distroless Fedora CoreOS |
| ns1:hasReference |
hardening is missing in ISO 27001
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 |
| ns1:hasSubdimension |
Patch Management |
| About |
Regular security training for all |
| rdf:type |
ns1:Activity |
| rdfs:comment | Conduct security awareness training for all roles currently involved in the management, development, testing, or auditing of the software. The goal is to increase the awareness of application security threats and risks, security best practices, and secure software design principles. Develop training internally or procure it externally. Ideally, deliver training in person so participants can have discussions as a team, but Computer-Based Training (CBT) is also an option. Course content should include a range of topics relevant to application security and privacy, while remaining accessible to a non-technical audience. Suitable concepts are secure design principles including Least Privilege, Defense-in-Depth, Fail Secure (Safe), Complete Mediation, Session Management, Open Design, and Psychological Acceptability. Additionally, the training should include references to any organization-wide standards, policies, and procedures defined to improve application security. The OWASP Top 10 vulnerabilities should be covered at a high level. Training is mandatory for all employees and contractors involved with software development and includes an auditable sign-off to demonstrate compliance. Consider incorporating innovative ways of delivery (such as gamification) to maximize its effectiveness and combat desensitization. [Source: OWASP SAMM 2]() |
| rdfs:label | Regular security training for all |
| ns1:Measure | Provide security awareness training for all internal personnel involved in software development on a regular basis like twice in a year for 1-3 days. |
| ns1:assessment | |
| ns1:hasImplementation |
<a href=https://cheatsheetseries.owasp.org/ target="_blank"></a> OWASP Juice Shop |
| ns1:hasReference |
https://owaspsamm.org/model/governance/education-and-guidance/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-7.2.2 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Regular security training for externals |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Regular security training for externals |
| ns1:Measure | Provide security awareness training for all personnel including externals involved in software development on a regular basis. |
| ns1:assessment | |
| ns1:hasImplementation |
<a href=https://cheatsheetseries.owasp.org/ target="_blank"></a> OWASP Juice Shop |
| ns1:hasReference |
https://owaspsamm.org/model/governance/education-and-guidance/stream-a#3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-7.2.2 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Regular security training of security champions |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Regular security training of security champions |
| ns1:Measure | Regular security training of security champions. |
| ns1:assessment | - Process Documentation: TODO - Training Content: TOODO |
| ns1:hasImplementation |
<a href=https://cheatsheetseries.owasp.org/ target="_blank"></a> |
| ns1:hasReference |
security champions are missing in ISO 27001
https://owaspsamm.org/model/design/threat-assessment/stream-b#2 https://owaspsamm.org/model/governance/education-and-guidance/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-7.2.2 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Reproducible defect tickets |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Reproducible defect tickets |
| ns1: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. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/defect-management/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.4 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-8.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-8.2.2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-8.2.3 |
| ns1:hasSubdimension |
Consolidation |
| About |
Reward of good communication |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Reward of good communication |
| ns1:Measure | Good communication and transparency encourages cross-organizational support. Gamification of security is also known to help, examples include T-Shirts, mugs, cups, giftcards and 'High-Fives'. |
| ns1:assessment | |
| ns1:hasImplementation |
Motivate people OWASP Top 10 Maturity Categories for Security Champions |
| ns1:hasReference |
interestingly enough A7.2.3 is requiring a process to handle misconduct but nothing to promote good behavior. not required by ISO 27001
https://owaspsamm.org/model/governance/education-and-guidance/stream-b#1 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Role based authentication and authorization |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Role based authentication and authorization |
| ns1:Measure | The usage of a (role based) access control helps to restrict system access to authorized users. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-9.4.1 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
SBOM of components |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | SBOM of components |
| ns1:Measure | Creation of an SBOM of components (e.g. application and container image content) during build. |
| ns1:assessment | |
| ns1:hasReference |
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-8.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-8.2 |
| ns1:hasSubdimension |
Build |
| About |
Same artifact for environments |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Same artifact for environments |
| ns1:Measure | Building an artifact once and deploying it to different environments means that only tested artifacts are allowed to reach the production environment |
| ns1:assessment | |
| ns1:hasImplementation |
Docker |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-deployment/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.4 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.3.1 |
| ns1:hasSubdimension |
Deployment |
| About |
Screens with metric visualization |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Screens with metric visualization |
| ns1:Measure | By having an internal accessible screen with a security related dashboards helps to visualize incidents. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/incident-management/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.5 |
| ns1:hasSubdimension |
Monitoring |
| About |
Security code review |
| rdf:type |
ns1:Activity |
| rdfs:comment | ### Benefits - New vulnerabilities may be found before reaching production. - Old vulnerabilities are found and fixed. |
| rdfs:label | Security code review |
| ns1:Measure | The following areas of code tend to have a high-risk of containing security vulnerabilities: - Crypto implementations / usage - Parser, unparser - System configuration - Authentication, authorization - Session management - Request throttling - :unicorn: (self-developed code, only used in that one software) |
| ns1:assessment | - Present the performed reviews (including participants, findings, consequences) and assess whether it is reasonable. |
| ns1:hasImplementation |
CWE Top 25 Most Dangerous Software Weaknesses |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-b#1 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Security consulting on request |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Security consulting on request |
| ns1:Measure | Security consulting to teams is given on request. The security consultants can be internal or external. |
| ns1:assessment | |
| ns1:hasImplementation |
<a href=https://cheatsheetseries.owasp.org/ target="_blank"></a> |
| ns1:hasReference |
security consulting is missing in ISO 27001 may be
https://owaspsamm.org/model/governance/education-and-guidance/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-6.1.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-6.1.4 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-6.1.5 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Security integration tests for important components |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Security integration tests for important components |
| ns1:Measure | Implementation of essential security related integration tests. For example for authentication and authorization. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-b#3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Application tests |
| About |
Security unit tests for important components |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Security unit tests for important components |
| ns1:Measure | Usage of unit tests to test important security related features like authentication and authorization. |
| ns1:assessment | |
| ns1:hasImplementation |
Karma |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-b#3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Application tests |
| About |
Security-Lessoned-Learned |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Security-Lessoned-Learned |
| ns1:Measure | Running a 'lessons learned' session after an incident helps drive continuous improvement. Regular meetings with security champions are a good place to share and discuss lessons learned. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/incident-management/stream-b#3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.6 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Signing of artifacts |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Signing of artifacts |
| ns1:Measure | Digitally signing artifacts for all steps during the build and especially docker images, helps to ensure their integrity. |
| ns1:assessment | |
| ns1:hasImplementation |
Docker Content Trust in-toto |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-build/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.6 |
| ns1:hasSubdimension |
Build |
| About |
Signing of code |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Signing of code |
| ns1:Measure | Digitally signing commits helps to prevent unauthorized manipulation of source code. |
| ns1:assessment | |
| ns1:hasImplementation |
Enforcement of commit signing Signing of commits |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-build/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.6 |
| ns1:hasSubdimension |
Build |
| About |
Simple Scan |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Simple Scan |
| ns1: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. |
| ns1:assessment | |
| ns1:hasImplementation |
OWASP Zap |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Dynamic depth for applications |
| About |
Simple access control for systems |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Simple access control for systems |
| ns1:Measure | All internal systems are using simple authentication |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-9.4.1 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Simple application metrics |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Simple application metrics |
| ns1:Measure | Gathering of application metrics helps to identify incidents like brute force attacks, login/logout. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/incident-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.4.1 |
| ns1:hasSubdimension |
Monitoring |
| About |
Simple budget metrics |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Simple budget metrics |
| ns1:Measure | Cloud providers often provide insight into budgets. A threshold and alarming for the budget is set. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/incident-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.3 |
| ns1:hasSubdimension |
Monitoring |
| About |
Simple false positive treatment |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Simple false positive treatment |
| ns1: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. |
| ns1:assessment | |
| ns1:hasImplementation |
OWASP Defect Dojo Purify |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/implementation/defect-management/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.6 |
| ns1:hasSubdimension |
Consolidation |
| About |
Simple mob hacking |
| rdf:type |
ns1:Activity |
| rdfs:comment | ### Guidelines for your simple mob hacking session - All exploits happen via the user interface. - No need for security/hacking tools. - No need for deep technical or security knowledge. - Use an insecure training app, e.g., [DVWA]() or [OWASP Juice Shop](). - Encourage active participation, e.g., use small groups. - Allow enough time for everyone to run at least one exploit. ### Benefits - The team gets an idea of how exploits can look like and how easy applications can be attacked. - The team understands functional correct working software can be highly insecure and easy to exploit. |
| rdfs:label | Simple mob hacking |
| ns1:Measure | Participate with your whole team in a simple mob hacking session organized by the Security Champion Guild. In the session the guild presents a vulnerable application and together you look at possible exploits. Just like in mob programming there is one driver and several navigators. |
| ns1:assessment | |
| ns1:hasImplementation |
OWASP Juice Shop |
| ns1:hasReference |
https://owaspsamm.org/model/governance/education-and-guidance/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-7.2.2 |
| ns1:hasSubdimension |
Education and Guidance |
| About |
Simple system metrics |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Simple system metrics |
| ns1:Measure | Gathering of system metrics helps to identify incidents and specially bottlenecks like in CPU usage, memory usage and hard disk usage. |
| ns1:assessment | Are system metrics gathered? |
| ns1:hasReference |
https://owaspsamm.org/model/operations/incident-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.3 |
| ns1:hasSubdimension |
Monitoring |
| About |
Smoke Test |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Smoke Test |
| ns1:Measure | Integration tests are performed against the production environment after each deployment. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-b#3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Application tests |
| About |
Source Control Protection |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Source Control Protection |
| ns1:Measure | Enabled protections on the source code management system preventing committed directly to an important branch. |
| ns1:assessment | |
| ns1:hasImplementation |
About protected branches Enforcement of commit signing Improve code quality with branch policies |
| ns1:hasReference |
peer review - four eyes principle is not explicitly required by ISO 27001
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-6.1.2 |
| ns1:hasSubdimension |
Development and Source Control |
| About |
Static analysis for all components/libraries |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Static analysis for all components/libraries |
| ns1:Measure | Usage of a static analysis for all used components. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 |
| ns1:hasSubdimension |
Static depth for applications |
| About |
Static analysis for all self written components |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Static analysis for all self written components |
| ns1:Measure | Usage of static analysis tools for all parts of the middleware and frontend. Static analysis uses for example string matching algorithms and/or dataflow analysis. |
| ns1:assessment | |
| ns1:hasImplementation |
Fortify Extension for Visual Studio Code HCL AppScan CodeSweep Setting Up the Visual Studio Code Extension Plugin |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 |
| ns1:hasSubdimension |
Static depth for applications |
| About |
Static analysis for important client side components |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Static analysis for important client side components |
| ns1: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. |
| ns1:assessment | |
| ns1:hasImplementation |
Fortify Extension for Visual Studio Code HCL AppScan CodeSweep Setting Up the Visual Studio Code Extension Plugin [bdd-mobile-security |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 |
| ns1:hasSubdimension |
Static depth for applications |
| About |
Static analysis for important server side components |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Static analysis for important server side components |
| ns1:Measure | Usage of static analysis tools for important parts of the middleware are used. Static analysis uses for example string matching algorithms and/or dataflow analysis. |
| ns1:assessment | |
| ns1:hasImplementation |
Fortify Extension for Visual Studio Code HCL AppScan CodeSweep Setting Up the Visual Studio Code Extension Plugin |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 |
| ns1:hasSubdimension |
Static depth for applications |
| About |
Stored Secrets |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Stored Secrets |
| ns1:Measure | Test for secrets in code, container images and history |
| ns1:assessment | |
| ns1:hasImplementation |
go-pillage-registries truffleHog |
| ns1:hasReference |
vcs usage is not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/verification/security-testing/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-10.1.2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-9.4.3 |
| ns1:hasSubdimension |
Static depth for infrastructure |
| About |
Targeted alerting |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Targeted alerting |
| ns1:Measure | By the definition of target groups for incidents people are only getting alarms for incidents they are in charge for. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.5 |
| ns1:hasSubdimension |
Monitoring |
| About |
Test cluster deployment resources |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Test cluster deployment resources |
| ns1:Measure | Test the deployment configuration for virtualized environments for unsecured configurations. |
| ns1:assessment | |
| ns1:hasImplementation |
kubesec |
| ns1:hasReference |
system hardening is not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/verification/security-testing/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Static depth for infrastructure |
| About |
Test for exposed services |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Test for exposed services |
| ns1:Measure | With the help of tools the network configuration of unintentional exposed cluster(s) are tested. To identify clusters, all subdomains might need to be identified with a tool like OWASP Amass to perform portscans based o the result. |
| ns1:assessment | |
| ns1:hasImplementation |
OWASP Amass |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Dynamic depth for infrastructure |
| About |
Test network segmentation |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Test network segmentation |
| ns1:Measure | Cluster internal test needs to be performed. Integration of fine granulated network segmentation (also between pods in the same namespace). |
| ns1:assessment | |
| ns1:hasImplementation |
netassert |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Dynamic depth for infrastructure |
| About |
Test of client side components with known vulnerabilities |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Test of client side components with known vulnerabilities |
| ns1:Measure | Tests for known vulnerabilities in components of the frontend are performed. |
| ns1:assessment | |
| ns1:hasImplementation |
npm audit retire.js |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 |
| ns1:hasSubdimension |
Static depth for applications |
| About |
Test of infrastructure components for known vulnerabilities |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Test of infrastructure components for known vulnerabilities |
| ns1: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'. |
| ns1:assessment | |
| ns1:hasImplementation |
Vuls |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 |
| ns1:hasSubdimension |
Static depth for infrastructure |
| About |
Test of server side components with known vulnerabilities |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Test of server side components with known vulnerabilities |
| ns1:Measure | Tests for known vulnerabilities in server side components (e.g. backend/middleware) are performed. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 |
| ns1:hasSubdimension |
Static depth for applications |
| About |
Test of the configuration of cloud environments |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Test of the configuration of cloud environments |
| ns1:Measure | With the help of tools the configuration of virtual environments are tested. |
| ns1:assessment | |
| ns1:hasImplementation |
kube-hunter kubescape |
| ns1:hasReference |
system hardening is not explicitly covered by ISO 27001 - too specific
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Dynamic depth for infrastructure |
| About |
Test of virtualized environments |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Test of virtualized environments |
| ns1:Measure | Test virtualized environments for unsecured configurations. |
| ns1:assessment | |
| ns1:hasImplementation |
ClusterScanner Dive to inspect a container images |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#1 |
| ns1:hasSubdimension |
Static depth for infrastructure |
| About |
Test the cloud configuration |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Test the cloud configuration |
| ns1:Measure | With the help of tools, the configuration of virtual environments are tested. |
| ns1:assessment | |
| ns1:hasImplementation |
kube-bench |
| ns1:hasReference |
system hardening is not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/verification/security-testing/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Static depth for infrastructure |
| About |
Test the definition of virtualized environments |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Test the definition of virtualized environments |
| ns1:Measure | Test the definition of virtualized environments for unsecured configurations. |
| ns1:assessment | |
| ns1:hasImplementation |
Deployment with kube-score Dockerfile with hadolint dockerfilelint |
| ns1:hasReference |
system hardening, virtual environments are not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/verification/security-testing/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Static depth for infrastructure |
| About |
The environment is hardened |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | The environment is hardened |
| ns1:Measure | Harden cluster environments according to best practices. Level 1 and partially level 2 from hardening practices like 'CIS Kubernetes Bench for Security' should considered. |
| ns1:assessment | |
| ns1:hasImplementation |
Attack Matrix Cloud Attack Matrix Kubernetes CIS Docker Bench for Security Defend the core kubernetes security at every layer |
| ns1:hasReference |
system hardening is not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.3 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Treatment of defects with severity high or higher |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Treatment of defects with severity high or higher |
| ns1:Measure | Vulnerabilities with severity high or higher are added to the quality gate. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/defect-management/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.4 |
| ns1:hasSubdimension |
Consolidation |
| About |
Treatment of defects with severity middle |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Treatment of defects with severity middle |
| ns1:Measure | Vulnerabilities with severity middle are added to the quality gate. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/defect-management/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-16.1.4 |
| ns1:hasSubdimension |
Consolidation |
| About |
Usage of a chaos monkey |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Usage of a chaos monkey |
| ns1:Measure | A randomized periodically shutdown of systems makes sure, that nobody will perform manual changes to a system. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-17.1.3 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Usage of a maximum lifetime for images |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Usage of a maximum lifetime for images |
| ns1:Measure | A short maximum lifetime for images is defined, e.g. 30 days. The project images, based on the nightly builded images, are deployed at leased once within the defined lifetime. Third Party images are deployed at leased once within the defined lifetime. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/environment-management/stream-b#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 |
| ns1:hasSubdimension |
Patch Management |
| About |
Usage of a short maximum lifetime for images |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Usage of a short maximum lifetime for images |
| ns1:Measure | A good practice is to perform the build and deployment daily or even just-in-time, when a new component (e.g. package) for the image is available. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/environment-management/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 |
| ns1:hasSubdimension |
Patch Management |
| About |
Usage of an security account |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Usage of an security account |
| ns1:Measure | Usage of a seperate account dedicated for security activities. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-deployment/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-10.1 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Usage of different roles |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Usage of different roles |
| ns1:Measure | Integration of authentication with all roles used in the service. |
| ns1:assessment | |
| ns1:hasImplementation |
Zest |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 |
| ns1:hasSubdimension |
Dynamic depth for applications |
| About |
Usage of edge encryption at transit |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Usage of edge encryption at transit |
| ns1:Measure | By using encryption at the edge of traffic in transit, it is impossible or at least harder to sniff credentials beeing outside of the organization. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-deployment/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-10.1 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Usage of encryption at rest |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Usage of encryption at rest |
| ns1:Measure | By using encryption at trdt, it is impossible or at least harder to to read information. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-deployment/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-10.1 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Usage of feature toggles |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Usage of feature toggles |
| ns1:Measure | Usage of environment independent configuration parameter, called feature toggles, helps to enhance the test coverage. Only what has been tested, goes to production. |
| ns1:assessment | |
| ns1:hasImplementation |
Docker |
| ns1:hasReference |
https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.4 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.8 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.9 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.3.1 |
| ns1:hasSubdimension |
Deployment |
| About |
Usage of internal encryption at tansit |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Usage of internal encryption at tansit |
| ns1:Measure | By using encryption internally, e.g. inside of a cluster, it is impossible or at least harder to sniff credentials. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-deployment/stream-b#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-10.1 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Usage of multiple scanners |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Usage of multiple scanners |
| ns1:Measure | Usage of multiple spiders and scanner enhance the coverage and the vulnerabilities. |
| ns1:assessment | |
| ns1:hasImplementation |
OWASP secureCodeBox |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.6.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.5 |
| ns1:hasSubdimension |
Dynamic depth for applications |
| About |
Usage of security by default for components |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Usage of security by default for components |
| ns1: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). |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/environment-management/stream-a#1 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Usage of test and production environments |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Usage of test and production environments |
| ns1:Measure | A production and a production like environment is used |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.4 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-17.2.1 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Usage of trusted images |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Usage of trusted images |
| ns1:Measure | Create image assessment criteria, perform an evaluation of images and create a whitelist of artifacts/container images/virtual machine images. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/implementation/secure-deployment/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.1.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-15.1.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-15.1.2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-15.1.3 |
| ns1:hasSubdimension |
Deployment |
| About |
Versioning |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Versioning |
| ns1:Measure | versioning of artifacts related to production environments. For example Jenkins configuration, docker images, (system provisioning) code. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-14.2.2 |
| ns1:hasSubdimension |
Development and Source Control |
| About |
Virtual environments are limited |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Virtual environments are limited |
| ns1:Measure | All virtual environments are using resource limits on hard disks, memory and CPU |
| ns1:assessment | |
| ns1:hasReference |
virtual environments are not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/environment-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-13.1.3 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-17.2.1 |
| ns1:hasSubdimension |
Infrastructure Hardening |
| About |
Visualized logging |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Visualized logging |
| ns1: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. |
| ns1:assessment | |
| ns1:hasReference |
not explicitly covered by ISO 27001 - too specific
https://owaspsamm.org/model/operations/incident-management/stream-a#1 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.4.1 |
| ns1:hasSubdimension |
Logging |
| About |
Visualized metrics |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Visualized metrics |
| ns1:Measure | Metrics are visualized in real time in a user friendly way. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/operations/incident-management/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-12.1.3 |
| ns1:hasSubdimension |
Monitoring |
| About |
Weak password test |
| rdf:type |
ns1:Activity |
| rdfs:comment | |
| rdfs:label | Weak password test |
| ns1:Measure | Automatic brute force attacks are performed. Specially the usage of standard accounts like 'admin' and employee user-ids is recommended. |
| ns1:assessment | |
| ns1:hasReference |
https://owaspsamm.org/model/verification/security-testing/stream-a#2 https://par-tec.github.io/security-ontologies/onto/iso#27001/2013/control-9.4.3 |
| ns1:hasSubdimension |
Dynamic depth for infrastructure |
| About |
Build and Deployment |
| rdf:type |
ns1:Dimension |
| rdfs:label | Build and Deployment |
| About |
Culture and Organization |
| rdf:type |
ns1:Dimension |
| rdfs:label | Culture and Organization |
| About |
Implementation |
| rdf:type |
ns1:Dimension |
| rdfs:label | Implementation |
| About |
Information Gathering |
| rdf:type |
ns1:Dimension |
| rdfs:label | Information Gathering |
| About |
Test and Verification |
| rdf:type |
ns1:Dimension |
| rdfs:label | Test and Verification |
| About |
<a href=https://cheatsheetseries.owasp.org/ target="_blank"></a> |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | OWASP Cheatsheet Series |
| ns1:hasTag | secure coding training |
| About |
<a href=https://github.com/aquasecurity/trivy target="_blank">trivy</a> |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | trivy |
| About |
<a href=https://ht.transpare target="_blank">https://ht.transpare</a> |
| rdf:type |
Implementation |
| rdfs:comment | Addison.Wesley.Security.Metrics.Mar.2007.pdf |
| rdfs:label | https://ht.transpare |
| About |
API Security Maturity Model for Authorization |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | API Security Maturity Model for Authorization |
| ns1:hasTag | api |
| About |
About protected branches |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | About protected branches |
| ns1:hasTag | scm source-code-protection |
| About |
Attack Matrix Cloud |
| rdf:type |
Implementation |
| rdfs:comment | Attack matrix for cloud Attack matrix for containers |
| rdfs:label | Attack Matrix Cloud Attack Matrix Containers |
| ns1:hasTag | mitre |
| About |
Attack Matrix Kubernetes |
| rdf:type |
Implementation |
| rdfs:comment | Attack matrix for kubernetes |
| rdfs:label | Attack Matrix Kubernetes |
| ns1:hasTag | mitre |
| About |
Blue/Green Deployments |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Blue/Green Deployments |
| About |
Build it Break it Fix it Contest |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Build it Break it Fix it Contest |
| About |
Building your DevSecOps pipeline 5 essential activities |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Building your DevSecOps pipeline 5 essential activities |
| ns1:hasTag | pre-commit |
| About |
Business friendly vulnerability management metrics |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Business friendly vulnerability management metrics |
| ns1:hasTag | documentation vulnerability vulnerability management system |
| About |
CI/CD tools |
| rdf:type |
Implementation |
| rdfs:comment | CI/CD tools such as jenkins, gitlab-ci or github-actions |
| rdfs:label | CI/CD tools |
| ns1:hasTag | ci-cd |
| About |
CIS Docker Bench for Security |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | CIS Docker Bench for Security CIS Kubernetes Bench for Security |
| About |
CWE Top 25 Most Dangerous Software Weaknesses |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | CWE Top 25 Most Dangerous Software Weaknesses |
| ns1:hasTag | documentation threat |
| About |
ClusterScanner |
| rdf:type |
Implementation |
| rdfs:comment | Discover vulnerabilities and container image misconfiguration in production environments. |
| rdfs:label | ClusterScanner |
| ns1:hasTag | container docker image misconfiguration scanning securiity-tools vulnerability |
| About |
Defend the core kubernetes security at every layer |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Defend the core kubernetes security at every layer |
| ns1:hasTag | cluster documentation kubernetes |
| About |
Dependency-Track is an intelligent Component Analysis platform that allows organizations to identify and reduce risk in the software supply chain. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill of Materials (SBOM). |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Dependency-Track is an intelligent Component Analysis platform that allows organizations to identify and reduce risk in the software supply chain. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill of Materials (SBOM). |
| ns1:hasTag | inventory sca |
| About |
Deployment with kube-score |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Deployment with kube-score |
| About |
DevSecOps control Pre-commit |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | DevSecOps control Pre-commit |
| ns1:hasTag | pre-commit |
| About |
Distroless |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Distroless |
| About |
Dive to inspect a container images |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Dive to inspect a container images |
| About |
Docker Content Trust |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Docker Content Trust |
| About |
Dockerfile with hadolint |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Dockerfile with hadolint |
| About |
Draw.io |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Draw.io |
| ns1:hasTag | defender threat-modeling whiteboard |
| About |
Enforcement of commit signing |
| rdf:type |
Implementation |
| rdfs:comment | Usage of branch protection rules |
| rdfs:label | Enforcement of commit signing |
| ns1:hasTag | signing |
| About |
Fedora CoreOS |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Fedora CoreOS |
| About |
Fortify Extension for Visual Studio Code |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Fortify Extension for Visual Studio Code |
| ns1:hasTag | ide sast |
| About |
HCL AppScan CodeSweep |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | HCL AppScan CodeSweep |
| ns1:hasTag | ide sast |
| About |
How to enforce a consistent coding style in your projects |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | How to enforce a consistent coding style in your projects |
| ns1:hasTag | ide linting |
| About |
Improve code quality with branch policies |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Improve code quality with branch policies |
| ns1:hasTag | scm source-code-protection |
| About |
In-Depth Linting of Your TypeScript While Coding |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | In-Depth Linting of Your TypeScript While Coding |
| ns1:hasTag | ide linting |
| About |
K8sPurger |
| rdf:type |
Implementation |
| rdfs:comment | Hunt Unused Resources In Kubernetes. |
| rdfs:label | K8sPurger |
| ns1:hasTag | dast infrastrcture scanner vulnerability |
| About |
Miro (or any other collaborative board) |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Miro (or any other collaborative board) |
| ns1:hasTag | collaboration defender threat-modeling whiteboard |
| About |
Motivate people |
| rdf:type |
Implementation |
| rdfs:comment | Enhance motivation can be performed with the distribution of pins as a reward, see [OWASP Security Pins Project](security pins) |
| rdfs:label | Motivate people |
| ns1:hasTag | gamification nudging security champions |
| About |
OWASP ASVS |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | OWASP ASVS |
| About |
OWASP Amass |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | OWASP Amass |
| About |
OWASP Defect Dojo |
| rdf:type |
Implementation |
| rdfs:comment | DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. |
| rdfs:label | OWASP Defect Dojo OWASP DefectDojo |
| ns1:hasTag | owasp vulnerability management system |
| About |
OWASP Juice Shop |
| rdf:type |
Implementation |
| rdfs:comment | In case you do not have the budget to hire an external security expert, an option is to use the [OWASP JuiceShop](juice shop) on a "hacking Friday" In case you do not have the budget to hire an external security expert, an option is to use the OWASP JuiceShop on a "hacking Friday" |
| rdfs:label | OWASP Juice Shop OWASP JuiceShop |
| ns1:hasTag | training |
| About |
OWASP Logging CheatSheet |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | OWASP Logging CheatSheet |
| ns1:hasTag | documentation logging |
| About |
OWASP MASVS |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | OWASP MASVS |
| About |
OWASP SAMM |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | OWASP SAMM |
| ns1:hasTag | defender owasp threat-modeling |
| About |
OWASP Security Champions Playbook |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | OWASP Security Champions Playbook |
| ns1:hasTag | security champions |
| About |
OWASP Top 10 Maturity Categories for Security Champions |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | OWASP Top 10 Maturity Categories for Security Champions |
| ns1:hasTag | security champions |
| About |
OWASP Zap |
| rdf:type |
Implementation |
| rdfs:comment | The OWASP Zed Attack Proxy (ZAP) is one of the world's most popular free security tools and is actively maintained by a dedicated international team of ... |
| rdfs:label | OWASP Zap |
| ns1:hasTag | scanner vulnerability |
| About |
OWASP secureCodeBox |
| rdf:type |
Implementation |
| rdfs:comment | secureCodeBox is a kubernetes based, modularized toolchain for continuous security scans of your software project. Its goal is to orchestrate and easily automate a bunch of security-testing tools out of the box. |
| rdfs:label | OWASP secureCodeBox |
| ns1:hasTag | scanner-orchestration vulnerability |
| About |
Purify |
| rdf:type |
Implementation |
| rdfs:comment | The goal of Purify to be an easy-in-use and efficient tool to simplify a workflow of managing vulnerabilities delivered from various (even custom) tools. |
| rdfs:label | Purify |
| ns1:hasTag | vulnerability management system |
| About |
Setting Up the Visual Studio Code Extension Plugin |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Setting Up the Visual Studio Code Extension Plugin |
| ns1:hasTag | ide sast |
| About |
Signing of commits |
| rdf:type |
Implementation |
| rdfs:comment | Signing of commits in git |
| rdfs:label | Signing of commits |
| ns1:hasTag | signing |
| About |
Threagile |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Threagile |
| ns1:hasTag | threat-modeling |
| About |
Threat Matrix for Storage |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Threat Matrix for Storage |
| ns1:hasTag | cluster documentation kubernetes storage |
| About |
Threat Modeling Playbook |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Threat Modeling Playbook |
| ns1:hasTag | defender owasp threat-modeling whiteboard |
| About |
Whiteboard |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | Whiteboard |
| ns1:hasTag | collaboration defender threat-modeling whiteboard |
| About |
Zest |
| rdf:type |
Implementation |
| rdfs:comment | Zest is an experimental specialized scripting language (also known as a domain-specific language) originally developed by the Mozilla security team and is intended to be used in web oriented security tools. |
| rdfs:label | Zest |
| ns1:hasTag | zap |
| About |
[Don't Forget EVIL U |
| rdf:type |
Implementation |
| rdfs:comment | [Do not Forget EVIL User Stories](Agile Software Development: Don't Forget EVIL User Stories) and [Practical Security Stories and Security Tasks for Agile Development Environments](SAFECode Agile Dev Security0712.pdf) |
| rdfs:label | [Don't Forget EVIL U |
| About |
[bdd-mobile-security |
| rdf:type |
Implementation |
| rdfs:comment | [bdd-mobile-security-automation-framework](bdd mobile security automation framework) |
| rdfs:label | [bdd-mobile-security |
| About |
dependabot |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | dependabot |
| About |
dockerfilelint |
| rdf:type |
Implementation |
| rdfs:comment | dockerfilelint is an node module that analyzes a Dockerfile and looks for common traps, mistakes and helps enforce best practices. |
| rdfs:label | dockerfilelint |
| ns1:hasTag | docker dockerfile sast |
| About |
go-pillage-registries |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | go-pillage-registries |
| About |
kube-bench |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | kube-bench |
| About |
kube-hunter |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | kube-hunter |
| About |
kubescape |
| rdf:type |
Implementation |
| rdfs:comment | _Testing if Kubernetes is deployed securely as defined in Kubernetes Hardening Guidance by to NSA and CISA_ |
| rdfs:label | kubescape |
| ns1:hasTag | kubernetes misconfiguration vulnerability |
| About |
logstash |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | logstash |
| ns1:hasTag | logging tool |
| About |
netassert |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | netassert |
| About |
npm audit |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | npm audit |
| About |
retire.js |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | retire.js |
| About |
rsyslog |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | rsyslog |
| ns1:hasTag | logging tool |
| About |
truffleHog |
| rdf:type |
Implementation |
| rdfs:comment | |
| rdfs:label | truffleHog |
| About |
Application Hardening |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Application Hardening |
| ns1:hasDimension |
Implementation |
| About |
Application tests |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Application tests |
| ns1:hasDimension |
Test and Verification |
| About |
Consolidation |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Consolidation |
| ns1:hasDimension |
Test and Verification |
| About |
Deployment |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Deployment |
| ns1:hasDimension |
Build and Deployment |
| About |
Development and Source Control |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Development and Source Control |
| ns1:hasDimension |
Implementation |
| About |
Dynamic depth for applications |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Dynamic depth for applications |
| ns1:hasDimension |
Test and Verification |
| About |
Dynamic depth for infrastructure |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Dynamic depth for infrastructure |
| ns1:hasDimension |
Test and Verification |
| About |
Education and Guidance |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Education and Guidance |
| ns1:hasDimension |
Culture and Organization |
| About |
Infrastructure Hardening |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Infrastructure Hardening |
| ns1:hasDimension |
Implementation |
| About |
Monitoring |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Monitoring |
| ns1:hasDimension |
Information Gathering |
| About |
Patch Management |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Patch Management |
| ns1:hasDimension |
Build and Deployment |
| About |
Process |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Process |
| ns1:hasDimension |
Culture and Organization |
| About |
Static depth for applications |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Static depth for applications |
| ns1:hasDimension |
Test and Verification |
| About |
Static depth for infrastructure |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Static depth for infrastructure |
| ns1:hasDimension |
Test and Verification |
| About |
Test-Intensity |
| rdf:type |
ns1:SubDimension |
| rdfs:label | Test-Intensity |
| ns1:hasDimension |
Test and Verification |