Home Computer Science Securing Systems Applied Security Architecture and Threat Models
The same security architecture patterns turn up time and again, even across seemingly disparate architectures. The high-level solutions to these patterns remain relatively consistent, even when there are local variations in how the solutions are accomplished.
But establishing requirements, even when well expressed and described in ways appropriate for different implementing stakeholders, isn’t enough. Security architecture can’t end at the point at which the requirements have been delivered. Some things will change. Flexibility and creativity will help ensure that security objectives will be met in the face of change. This is especially true when working in an Agile environment. The key to success is continuing involvement and deep engagement.
Where there is resistance, having concrete examples helps stakeholders understand the reasoning that gives birth to each security requirement. Sometimes, a single, pithy statistic or particular attack example will help others jump on the security bandwagon. For those instances in which there is outright resistance, identifying what is being protected or some other solvable pain point can turn enemies into allies.
No matter what happens, in complex, highly dynamic organizations there must be some governance that security requirements are being fulfilled. This is necessary even when there is a great deal of security buy-in, because there always seems to be at least one clever person who will attempt shortcuts to delivery. There has to be a method that catches these attempts even when they are rare. Otherwise, the defense of other systems may be impacted; there’s a due diligence responsibility to ensure that requirements are met or risks raised to decision makers.
|< Prev||CONTENTS||Next >|