As soon as the top layers have endorsed a security architecture program, you can begin to find people throughout the organization and, especially, task-oriented people who not only support security, but are interested and motivated to build security into the systems that they create, deploy, and maintain. The “friendlies” comprise the resource base with whom your security architects will work. Your supporters will accelerate your program simply by taking security architect input seriously. The power that a couple of motivated individuals can have on the tone of a group, and that can even ripple out beyond a single team throughout your teams and groups, never ceases to amaze me. It just takes a few individuals, as long as these individuals are supportive in a visible way.
It never hurts to have support, no matter who offers it. However, the classic, introverted engineer who hardly ever speaks to anyone isn’t going to have this ripple effect. You need to find people who will actively express their support. For instance, a single security architect sitting with about a dozen other members of a project team is just a voice in the crowd. But if the project manager, an engineer, and another architect actively engage in the security conversation, this has a profound effect on the entire team. Even those who are resistant to security requirements (for whatever reason) won’t be able to dismiss the security conversation out of hand.
In other words, when starting the program, plan for time for you and whoever is working with you to get out into the implementation teams and meet people, talk to them about security, find out what they think. More importantly, uncover fears about security, perhaps even poor experiences in the past. The latter is critically important. If you’re working with a pre-existing social debt, you need to understand what the history is, how the debt was accumulated, and what pain points originated with this debt.
For instance, at one organization at which I worked, a past administration had declared that every change to a software product had to be threat modeled. This statement alone will garner plenty of resistance: Most engineers will spot the flaw in the logic immediately. That is, not all changes engender a change to the threat model. Cosmetic changes, in particular, typically do not change a threat model at all.
But even worse, in the past program, threat models were considered so secret, so proprietary, that the people running the program thought that the threat modeling and its methodology were too secret to share. One manager told me that when he asked how he was to threat model, he was told that it was a secret. Whatever that administration was thinking, and I wasn’t there, so I can’t say, it was clear from talking to the group of managers in the meeting where this was said, that they had rejected entirely the concept of threat modeling as a nonproductive activity.
Obviously, my job was to undo that social debt; I had to overturn the organizational resistance to security architecture, in general, and threat modeling, in particular. Since you’ve presumably worked through at least some of this book, you’ll know that I do not believe that every change requires threat modeling. In fact, such across-the-board, simplistic generalizations will immediately be spotted as falsehoods. But further, a lack of transparency—an opaque program—for whatever reason, had moved the probably neutral to a completely resistant position.
By visiting teams and simply listening, one can learn a great deal. That’s almost always the first thing that I do when I join a new organization: I go on a “fact-finding mission.” Is there any history with security architecture? Have there been failures? And if so, why? What are people currently doing to achieve security objectives? Where do those security objectives originate? Who are the people who are engaged in security and what are their reasons for engagement? If I can, I try to identify those who are resistant, even potential enemies.
Although I prefer to think of everyone I meet as neutral, as a potential supporter, I am not, I hope, so naive as to dismiss the possibility that some people are opposed to security in general. Furthermore, not everyone likes me; some people with whom I interact will resist me and my program simply because, for some reason, they don’t like me or my style or the shape of the program in general. Identifying resistance helps me better formulate a plan to work around it or through it, as much I can.
In essence, during the very early stages of setting up a program, I circulate through as many of the teams that are tasked with delivery as I possibly can. I try to keep an open mind and put my agenda aside so that I can listen and fully understand the situation into which a security architecture program will be inserted. At the same time, I try to identify people who are supportive of the cause, and I also try to identify those who may have had bad experiences in the past or who are resistant.
As assessments take place, I find reasons to interact with my supporters. In other words, I “network” heavily and continuously. This is the outreach part of the work of building a program. I actively seek opportunities to interact that go beyond “your team will need to perform this task.” I perform favors as I can. I develop relationships regardless of any particular person’s position in the organizational hierarchy; I ignore rank as much as humanly possible. Every potential supporter is golden and worthy of my attention.
After an architecture assessment and threat model, there are likely to be security requirements. And that’s where I need every friend I can find. There are many reasons why critical security requirements are going to be difficult to implement. In order to solve problems, I will need at least a faction of supporters, unless I get a majority on a team who are willing to enter into the search for workable solutions. Grassroots support engenders solution-oriented team discussion. I believe that solutions created and supported by implementation teams are much easier to bring to fruition than escalations seeking senior management mandates. Grassroots support will multiply and amplify the efforts of your security architects many times over.