For me these kind of things fell under security review processes.
We needed flexibility because we addressed so many different types of system, so went with "any documented review process", but suggested Microsoft STRIDE as an example. By systematically reviewing, what are the components, what are their history of security issues, what are the recommendations, how do they interconnect, how sensitive are the data flows, what boundaries do they cross, hopefully you should discover the tools that relate to the technology if you do this thoroughly, as well as identify where the risks lay, any documented mitigations, any recommendations or standards you should have followed etc.
That said STRIDE wasn't validated, it was more about bringing an understood structure to the process. It had a fairly lightweight risk approach, basically asking questions like "is it financial data?", but I guess the answers should tell you who will understand (and/or own) the corresponding risks & if you have the right people in the room. I'll take lightweight and done, over heavyweight and rarely done.
Also by systematically decomposing, and documenting the attributes of systems, the process speeded up each time, as I'd have recommendations on how to harden Postfix, or what is wrong with Alpine Linux images, documented already, and they'd just need a quick refresh each time.
------------------------------
Simon Waters
Founder
Insufficient Entropy
------------------------------
Original Message:
Sent: Aug 25, 2021 05:40:26 AM
From: Rima Bose
Subject: How do you risk assess infrastructure blueprints?
Infrastructure blueprints are commonly used in DevOps- these can be containers or stacks that can be readily deployed on public cloud like AWS. My question is how do you risk assess these 'blueprints' or reusable infrastructure-as-a-code? Automated Open Source Vulnerability Scanning, Pen testing and what else would you suggest?
------------------------------
Rima Bose
------------------------------