I feel the lack of a "motivation" blurb for every recommendation may lead to blindly checking boxes.
Going through a grueling security compliance process at a previous job taught me that no single list of recommendations covers all the edge cases and complexity of modern software. At least with a "motivation" section, I was able to piece together what was actually expected of me. It also helps with prioritization if the "motivation" includes the consequences of non-compliance.
For example: the "data flow diagram" is probably meant to be part of threat modeling, where you're forced to think like an attacker. That may sound like a tedious paper-pusher task that could be put off, but actually IMO it's really nice to do early on since a threat model can help tell you where to focus your "minimal" security efforts: https://owasp.org/www-community/Threat_Modeling
I've found rationales and similar to be double-edged in practice. They're immensely valuable to people like yourself who just want to understand the point of a question to better implement what its getting at. They're also fodder for people whose primary interest lies in finding ways to undermine the goals.
Writing things like this, with clear requirements and no justifications, is what I do when I expect people will try and use explanations to weasel out of requirements.
Example: I once had a coworker try and justify sending full credit card data through Kafka as not really storing it if you set the retention time to under a second. So it was fine under PCI-DSS, right?
Comments
I feel the lack of a "motivation" blurb for every recommendation may lead to blindly checking boxes.
Going through a grueling security compliance process at a previous job taught me that no single list of recommendations covers all the edge cases and complexity of modern software. At least with a "motivation" section, I was able to piece together what was actually expected of me. It also helps with prioritization if the "motivation" includes the consequences of non-compliance.
For example: the "data flow diagram" is probably meant to be part of threat modeling, where you're forced to think like an attacker. That may sound like a tedious paper-pusher task that could be put off, but actually IMO it's really nice to do early on since a threat model can help tell you where to focus your "minimal" security efforts: https://owasp.org/www-community/Threat_Modeling
I've found rationales and similar to be double-edged in practice. They're immensely valuable to people like yourself who just want to understand the point of a question to better implement what its getting at. They're also fodder for people whose primary interest lies in finding ways to undermine the goals.
Writing things like this, with clear requirements and no justifications, is what I do when I expect people will try and use explanations to weasel out of requirements.
Example: I once had a coworker try and justify sending full credit card data through Kafka as not really storing it if you set the retention time to under a second. So it was fine under PCI-DSS, right?