Use Peer Networks
Just as important as the grassroots network is your peer network across line management, senior architects and other technical leaders, and directors (i.e., middle management). When push comes to shove, these are the people who are going to help sort and solve problems. For many decisions that involve risk escalations or risk assumptions, management is going to be empowered in many organizations to make the call and to work through conflicts in their organizations. A hostile director can absolutely kill the security architecture for that organization. I like to say that people don’t have to like me, but they have to respect me and my program. This is particularly true for middle management (usually at the director level).
If you are the director tasked with booting a security architecture and assessment program, your peers will be the network through which most of the day-to-day resourcing and priority issues are set. Although it is true that line management often takes care of these task-setting activities, if they run into trouble, it’s to your peer network that they will turn. It is through your peer network that you will need to influence priorities.
Just as important as middle management, senior technical leaders strongly influence the success or failure of a security architecture program. First, security architecture fits in as a portion of an overall architecture program and practice. That is, security is a specialty architecture practice that influences, shapes, and changes a system architecture within many organizations. Architects envision systems. Security architects envision the security of those systems. Although it is possible that both roles can be fulfilled by the same person, these are usually different people with separate but highly intersecting bodies of practice. It is a disaster if the architects and, especially, architecture leaders are not supportive of security architecture. In this case, nothing will get done.
Typically, the first security architect is someone who is quite senior. Her or his peer network will be the other technical leaders: senior engineers, senior architects, distinguished engineers and architects, enterprise architects, and the like. Your most senior security architect will need to have the support of some, preferably most (best is all) of the technical leaders who could be involved in understanding and delivering security requirements.
And so it goes, down the seniority hierarchy and through the grade levels. Normally, even beginning security architects are already established architects in their own right. These people will need to have the support of their peer network on the teams for which they are delivering assessments and requirements.
Considering who comprises these peer networks, I try not to forget line management, as they are tasked with delivering real systems. The same is true for project managers who are driving projects. These two roles (and similar, whatever they’re called in the organization) will have to invite security in and will have to make sure that requirements are included in the deliverables. If line managers and project/program managers are unaware of the importance of their role, no matter how wonderful your assessments, threat models, and requirements are constructed, again, nothing will likely get done. Furthermore, a project manager who doesn’t understand the sophisticated nature of security solution discussions may not allot a sufficient amount of time for creative thinking. Security will only be given five minutes on the agenda when it actually needs forty-five minutes. Again, the result of this will be that security requirements that are difficult are likely to get postponed, perhaps indefinitely.
In order to fully support a security assessment and threat modeling process, line management and project managers will need to have a clear process that is well defined. Each step along the way will need to be executed in some more or less linear time order, or the project can’t be project managed. There is resistance built into this problem, as we have seen that there tends to be some retracing of steps during the “peel the onion” assessment (assessment can be an organic and recursive process). For project managers who are more comfortable with strict linearity, these horizontal movements and retracings will produce tension and anxiety.
Much has been written about where in a system delivery process architecture assessment belongs. I set my own thoughts down in Chapter 9 of Core Software Security: Security at the Source, by James Ransome and Anmol Misra.3 However, the entire book contains a lot of material about where these tasks take place: early. This is obviously not the only book on this subject. Early security assessments within a development process should be well-trodden territory. Remember the very first quote of this book calling for early architectural assessment for security?
You’ll want to make the timing of activities perfectly clear in your delivery process or project lifecycle. There isn’t much that can actually be done when the security assessment takes place a week, or worse, a day before going live. Rarely have I seen decision makers stop deployment, even in the face of the critical security misses discovered during late assessment.
Generally, architecture tasks take place in the early phases of a project or system delivery cycle. The precise timing will depend on the sort of projects you’re delivering as well as the rest of your lifecycle—that is, whether you’re using waterfall, Agile, or something else. Whatever your process, at least some of the architecture will happen early, as should the beginning of the security assessment. Your project management function will need to understand the lifecycle and where the security assessment fits into it, in detail, in order to support your assessment program and your security architects.
Program effectiveness can be increased while also accelerating the speed of adoption by broadcasting program successes through the peer network. People like to hitch their wagons to anything that is achieving success. It is said that success breeds success. Your partners may view their future success through a lens of your current wins.
Constantly broadcasting one’s own or one’s team’s success may seem like bragging. It isn’t just the successes of your own team that you can broadcast but, additionally, those places where your partner teams have successfully implemented security requirements. Indeed, if you can broadcast those sales that have been closed because the security features that customers needed were already built into products, you demonstrate the importance of security as a differentiator in the marketplace. Dr. James Ransome and I successfully used this tactic to drive security deeply into an organization’s product management function.
Before James and I arrived on the scene, customer security inquiries were handled out-of-band and out of sight. The product management function for that product didn’t receive important information about what customers’ security teams were demanding, so few customer security demands were being worked into new and updated offerings, and security was all but invisible. That was the goal of a previous security organization: to make security as invisible as possible.
However, that product was sold (as a SaaS) to many enterprises. Enterprises can be very finicky about giving their data to third parties. The enterprise security teams would be brought into the sale to perform a due diligence review of the prospective vendor and the offering. Of course, the customer security teams would try to make the product fit their internal policies and expectations. In order to meet enterprise policy requirements, the product had to have certain security features. But those requests weren’t being captured in an orderly fashion; product management didn’t have the correct information about what security their enterprise customers needed.
James and I realized that there was a gold mine lying undiscovered in these security team to security team conversations. We got our security team, mostly James and myself, involved in these sales discussions. But we included the sales team and the product managers, as well. We developed security marketing literature and other artifacts to demonstrate how security was implemented in the product. By articulating more clearly how security was built, we were able to head off customer attempts to redesign security solutions for something they didn’t really understand fully.
As enterprise sales started to close without previous security hitches, our partner teams and our peer network, in particular, took notice.
Although these tactics won’t eliminate every bit of resistance in a peer network, in this case it was as if we had supplied lubrication to our working with those people who controlled the direction that our product was heading in, that is, the product management team. In addition, these successes went viral through the sales department as sales (and marketing) began to realize how important security was in closing the big enterprise sales. By networking on top of those first few successes, we were able to achieve architecture engagement in the product development lifecycle. We further reaped the rewards of the confidence that salespeople had in the security team’s knowl?edge and business understanding. This confidence rippled throughout the organization, across our peer network, as well as downwards through our peers’ organizations. Upper management took notice that the security team was making a difference.
When things go sideways between security architects and another organization or team, it is my practice to take full responsibility for whatever part I may have had or my team has had in the problem. Of course, I don’t think it’s wise to broadcast these mistakes throughout the various networks—upwards, across, and downwards. Still, for those involved, transparency and a strong sense of accountability goes a long way to building trust. It’s not that mistakes happen that is the problem; mistakes are bound to occur. We are, after all, merely human. Rather, your leadership and that of your architects will be judged on how you handle mistakes—yours and any that crop up in the work. Responsibility and accountability for one’s actions are a mark of a leader. And make no mistake about it: Security architects must be leaders.
Your security architects may not have people reporting to them, so they may not officially be “people managers.” Because part of an architect’s job is to influence, and part of the job will be to establish security direction for the systems under assessment, security architects are generally going to be leaders in their organization, at least within the scope of that influence, whatever it may be. Because of this aspect of the role, that is, helping systems achieve an organizational security posture, training in many aspects of leadership is critical.
In my leadership roles, I’ve consistently been asked to help evaluate the performance of peers, partners, and those for whom I was supposed to be offering leadership. My HR training in these aspects of the management role has come in very handily.
For a practice such as the security architecture as described in this book, support and, ultimately, buy-in in will need to come from the organizational decision makers, the grassroots, and across your network. That is, building a network of support, even when it’s relatively few in number—upwards, across, and downwards—will greatly accelerate adoption and follow through for your security assessment program. Even with relatively few numbers of supporters, the organization will achieve that “tipping point” that spells success for the entire program. Communications are important. Repeated communication will likely be a necessity.
In my communication plan, I include obtaining peer and grassroots evaluation and feedback. I don’t necessarily take every bit of feedback exactly as it is expressed. But even wild accusations and projections often have a kernel or grain of truth hiding within them. In this way, I can tailor the program to the organization’s needs more precisely. Every organization has its local idiosyncrasies. And every organization has its limitations and constraints: Organizations develop a unique and individual culture. General statements such as those in this chapter have to be tuned to the way business is transacted in each organization. I can’t know what that tuning is without finding out how people in the organization are used to doing things, what the expectations are, and what the perceptions are about my team, and then finding out about interactions around security.
Just as important as the actual feedback, is a sense of participation, a sense of cocreation. I’ve been privileged to start security architecture programs several times in my career (as of this writing, four to be precise). This implies that there’ll be a sense of newness, a sense of innovation, a sense of something to be created. I invite my peer network and the grassroots to help shape the program, though not in its entirety, of course. As you can see from this book, I do have some very definite ideas. Still, there are always plenty of choices, some new problems that crop up in a complex program like security architecture. There’s always room for creativity and synthesis.
This sense of participation in something new and interesting is infectious. Rather than trying to be personally charismatic (I’m not!), I make the program, the work, charismatic. People like to have a little fun, enjoy a little creativity at work. Security architecture is so complex, and there are so many variables to getting things done, it’s a perfect test bed for innovation. As I’ve stressed above, mistakes are going to happen anyway. If I can keep disasters from happening, while at the same time, I’m willing to try different ways of achieving ends even if these have some risk of failing, this invitation to play attracts supporters and helps to build towards a tipping point to a successful, self-sustaining security architecture program.
Figure 13.1 is a whimsical visual representation of the social networks that need to be cultivated for program success. As shown in the figure, socialize and keep evangelizing and socializing; stay on message. Michele Guel says, “Say it three times, then find a different way to say it.” Prepare to perform years of repeated messaging. The effort to move a major public website’s authentication from HTTP to HTTPS was the work
Figure 13.1 Socializing the program across the organization.
of three different security architects and took eight years. It’s important not to give up when a security requirement is the “right thing to do,” even in the face of significant resistance. Eventually, conditions will ripen such that that the “right thing” can happen.