Home Computer Science Securing Systems Applied Security Architecture and Threat Models
Building a Program
A program cannot be built solely from top down, or completely from the bottom up, or only across a peer network, but rather all of these must come together in parallel, and also such that each vector of program development supports and strengthens the other dimensions. You will want to work on each of these dimensions at the same time. In my experience, there is no proper linear order, though it is true that, without senior management buy-in, very little can successfully take place.
Senior Management's Job
Senior Management must buy into an assessment program, but there must be more than lip service. The program will require senior management’s ongoing support in three ways.
First, if there is any hierarchy in your organization at all, there must be a clear directive from the top that security architecture assessments, and, most importantly, the requirements that are output from the threat model must be completed. That is, security requirements must be empowered, which is the same thing as saying that the architects who generate the requirements have been empowered by the organization to design security into the organization’s systems.
Senior management communications can be made through their usual channels: newsletters, at organizational all-hands meetings, blog postings, through the organization’s hierarchy as “pass downs.” The key trick here is that this cannot be messaged just once through one, single media channel. Various formats and vectors combine for a more powerful delivery. No one on the system delivery teams should be surprised when a security architect shows up and asks to see the architecture. This message doesn’t have to be constant, but like all similar process-oriented communications, it will need to be repeated regularly.
But there’s more that senior management must do; they must stand behind the empowerment. Smart people will push back. Sometimes, the non-security people will have the best course for the company in mind. Remember, we all make mistakes; everyone is fallible.
When there is conflict between the security requirements and other considerations, we have already discussed escalation. If senior management always delegates the decisions back downwards, or worse, typically ignores security concerns, one of two things is going on. Possibly, security’s manner of explaining the situation and organizational risk may be faulty. (This work has previously delved into how to express risk and to whom.) But if the risks are clear and senior decision makers simply ignore the situation entirely, then it is likely that the assessment program isn’t truly empowered. In that case, the program cannot be successful without full buy-in from the top. It would be time to re-empower the program.
Finally, when push comes to shove around resource priorities, without full support from those who hire, fire, and assign tasks, it doesn’t make any difference what has been declared; all those downward communications about the importance of designing security into systems have been lip service, if none of the security requirements will actually be accomplished. Security requirements lead directly to tasks. Those tasks will need people and compute time in order to be accomplished. The best organizational “empowerment” is useless without time, on the ground, to get real tasks completed. Security, like any other organizational goal, has to have sufficient resources for delivery.
|< Prev||CONTENTS||Next >|