patternMinor
Context of DevOps in ISO 27001 security audits
Viewed 0 times
27001auditssecuritycontextisodevops
Problem
Correct me if I am wrong, ISO 27001 addresses mostly organizational and operational aspects. This sounds a little bit abstract and regulatory.
On the other hand, in DevOps, if you wish DevSecOps, there is proactive and very specific demand for processes and tools to ensure that no vulnerabilities are delivered to customer.
How do these two domains fit together?
Do security auditors ask actually in a security audit questions like,
On the other hand, in DevOps, if you wish DevSecOps, there is proactive and very specific demand for processes and tools to ensure that no vulnerabilities are delivered to customer.
How do these two domains fit together?
Do security auditors ask actually in a security audit questions like,
- "Do you have a vulnerability scan as part of your component dependency management?
- Have you checked your API for OWASP breaches?
- Do you scan your Docker images, being aware of risks connected to base images?"
Solution
In my experience auditors tend to follow a Top-down Risk Assessment process whereby they review the inherent risk to business and IT for a company or system, then look at the controls that company has in place to mitigate the inherent risk and the residual risk that remains.
A top-down risk assessment opposes the way most technical people work, in that we look at specific vulnerabilities, defects and design flaws and then work up from there in a more bottom-up approach.
There is nothing inherently wrong with either approach they both have a place in any given company, so in answer to your questions:
-
Auditors do not tend to ask domain-specific questions such as Have you checked your API for OWASP breaches; they do tend to ask questions such as What controls are in place to mitigate the risk of data loss due to software vulnerabilities?
-
The thing to realise about ISO 27001, and most standards, is that they are not prescriptive - they are designed to provide a standard business language to enable communication between Business/IT and Auditors. More often than not "implementing" any standard is about identifying the existing processes that meet the requirements of the standard and documenting them, then looking for any gaps or flaws and plugging the holes.
The same logic goes for ISO 9000, ITIL, COBIT, COSO, etc. it's very rarely about enforcing some pre-defined process. Instead, it is a case of creating a mapping between what the auditor is looking for and what the business is doing.
A top-down risk assessment opposes the way most technical people work, in that we look at specific vulnerabilities, defects and design flaws and then work up from there in a more bottom-up approach.
There is nothing inherently wrong with either approach they both have a place in any given company, so in answer to your questions:
-
Auditors do not tend to ask domain-specific questions such as Have you checked your API for OWASP breaches; they do tend to ask questions such as What controls are in place to mitigate the risk of data loss due to software vulnerabilities?
-
The thing to realise about ISO 27001, and most standards, is that they are not prescriptive - they are designed to provide a standard business language to enable communication between Business/IT and Auditors. More often than not "implementing" any standard is about identifying the existing processes that meet the requirements of the standard and documenting them, then looking for any gaps or flaws and plugging the holes.
The same logic goes for ISO 9000, ITIL, COBIT, COSO, etc. it's very rarely about enforcing some pre-defined process. Instead, it is a case of creating a mapping between what the auditor is looking for and what the business is doing.
Context
StackExchange DevOps Q#5622, answer score: 2
Revisions (0)
No revisions yet.