I Recently bumped into a nice blog post about Secure Development Lifecycle (SDL) in the agile context. Disclaimer: yours truly is not particularly a fanboy of the prevailing mainstream agile buzz, mainly due to the nagging feeling of a chronically shortsighted investment horizon in the practical daily agile proceedings.
Nevertheless, in the well crafted SDL blog mentioned above there were a few small items that I would like to respectfully disagree with, at least to some extent.
For example, the most beneficial angle for tacking key security aspects in the software R&D would in my opinion be to consider key results from threat modeling as ordinary backlog items, and push those through the casual development pipeline like any other feature.
Specifically, for any security features to be considered as ordinary features, it is of utmost importance to assure the appropriate test automation is in place, e.g., the CI system must automatically maintain the proof that the particular security threat in question has been properly mitigated, preferably by design. For any developers out there working for cyber security product companies this would seem like a rather obvious logical consequence from state-of-the-art test automation and continuous integration .
For many cyber security threats a proper industry standard mitigation already exists, that can be subjected to casual test automation:
Nevertheless, in the well crafted SDL blog mentioned above there were a few small items that I would like to respectfully disagree with, at least to some extent.
For example, the most beneficial angle for tacking key security aspects in the software R&D would in my opinion be to consider key results from threat modeling as ordinary backlog items, and push those through the casual development pipeline like any other feature.
Specifically, for any security features to be considered as ordinary features, it is of utmost importance to assure the appropriate test automation is in place, e.g., the CI system must automatically maintain the proof that the particular security threat in question has been properly mitigated, preferably by design. For any developers out there working for cyber security product companies this would seem like a rather obvious logical consequence from state-of-the-art test automation and continuous integration .
For many cyber security threats a proper industry standard mitigation already exists, that can be subjected to casual test automation:
- Need confidentiality? Encrypt your data.
- Need to safeguard your keys? Use a whitebox or deploy a HSM.
- Want to block malware? Deploy software whitelisting at the operating system level.
- Need strong authentication? Deploy PKI.
- Want control flow integrity? Follow software protection best practices at the trust boundary edge.
Basically, the bottom line here seems to be the following: if you claim your product is trustworthy in a certain sense you better have test automation in place to back your claim.
To be fair, not all Security is about establishing technological barriers due to the human factors involved. In the end, this only emphasizes the need to build systems that are known to be secure by design, so there will be less attack surface for human errors like falling into social fishing attacks.
