Getting Security Requirements Implemented
You’ve performed a thorough analysis of the architecture and built a relevant threat model. The requirements have been written at the correct level for each implementing organization. You’re done, right? Sadly, no, the job isn’t finished until every requirement has been processed. “Processed” in this context is multifaceted, since for any modestly complex system, there is some possibility that one or more of the requirements cannot be built as specified due to factors outlined above. After we examine strategies for ensuring that requirements are built, we will take a look at some strategies for working through those situations where the requirements must change.
It's A Partnership
Architecture and design represent one important side of delivering a security posture. That’s what this book is all about: How does one go about achieving an architecture and an architectural design that represent the security needs for a system? In today’s fast-paced, often “agile” software development, how can the secure design be implemented? In my experience, tossing requirements, architectures, and designs “over the wall” and into the creative, dynamic pit of Agile development is a sure road to failure. Three things, not mutually exclusive by any means, are likely to occur:
- 1. Artifacts injected into an Agile methodology from the outside will be ignored because the documents appear to be irrelevant.
- 2. Developments, learnings, and changes during development will cause elements to change, even for assumptions to get invalidated, causing security elements to change drastically or not get accomplished at all.
- 3. If the Agile team members attempt to adhere strictly to artifacts brought in from the outside and not directly generated by the Agile process, this blind adherance will cause team velocity and creativity to fall, even to stagnate.
The key to Agile is deep engagement based upon trust and personal responsibility. Since Agile processes let designs emerge out of a creative, innovative, self-regulating process, attempts to issue edicts and expect perfect adherence fly directly in the face of how the benefits of Agile are to be reaped. Agile is a direct response to command and control governance processes. Governance based upon strict obedience is bound to fail. Or Agile will fail—these two are diametrically opposed.