Compliance Requirements, Legal Ramifications, and other Drivers with Real World Risks and Consequences are Often the Best way to Bend the Ear of a Busy Executive
|Part in a Series on Implementing a Secure Development Lifecycle: Read Vinnie’s Other Columns Here|
One of the biggest mistakes people make when building an SDL is focusing on the technical requirements such as deploying a tool or performing assessments, while failing to gain executive support. The main character in this all-too-common, sad story is the technically-inclined program manager who focuses on technical solutions because it falls within their comfort zone. Vendor marketing material doesn’t help clarify any of these misconceptions, but rather reinforces the idea that the solution lies in tools and technology.
Security technologies alone will never solve any security problems. And that’s a fact.
A real solution calls for a well-blended combination of people, process, and technology. As with any attempt to change people’s behavior and the processes they follow, there must be executive willingness to enforce the changes and encourage good behavior. By gaining executive support early in your program, you establish a foundation for long-term success. This foundation is unique because while a program can get by (although it’s not recommended) without activities like QA integration or hardening guidelines, it cannot function without upper level support – for reasons that we’ll explore shortly.
Simply put, executive sponsorship is an essential ingredient to the successful integration of security in the software development lifecycle.
Who is an Executive?
Although it would be nice, you don’t always need a Bill Gates-like figure when getting the support of an executive. When we say executive, we’re talking about individuals with two key traits – the authority to allocate time and the authority to provide money. Not coincidentally, developers are constantly looking for more time and money.
While this probably comes as no surprise to anyone who’s worked in a risk management or security role, there will always be individuals that will oppose your efforts to manage risk or improve the security of an organization. These individuals rarely have an ideological bent against securing sensitive information, but rather that they oppose it on the grounds that it will compromise their ability to do other things. This further bolsters the case to begin your negotiation for support at the highest level possible. I’ve found that working on a case-by-case basis with individual application development managers is futile for the same reason that grassroots efforts alone are bound to fail. Reaching those who have the ability to set the direction for entire organizations is the only way to be successful and avoid spinning your wheels. This is especially the case in larger organizations with multiple and/or geographically dispersed teams.
When trying to gain the support of development teams, you will inevitably encounter two questions:
“Doesn’t this security thing mean that we have new responsibilities?”
“Doesn’t this mean we have to change what we’re currently doing?”
Yes and yes. A program that successfully integrates security into the software development lifecycle requires both an increase in responsibility and time. By gaining management support you can solve those issues in advance.
A third, and slightly less important characteristic to look for in an executive sponsor is the desire to see your organization become more secure. What we have seen time and time again in accomplished programs are executives that stand behind their SDLs with authority and are more than willing to allocate the funding and necessary resources.
Basis of an Effective Business Case
When it comes to persuading those at the top, we recommend positioning the program as a solution to an existing problem that must be solved. We’ve seen many attempts to sell a secure SDL program as best practice and as an additional effort to make things more secure because it’s the “right thing to do”, but all too often those reasons fall upon deaf ears. Compliance requirements, legal ramifications, and other drivers with real world risks and consequences are often the best way to bend the ear of a busy executive. Unfortunately, this can be taken too extremes. We’ve seen security teams refer to PCI in a way that makes executives think that PCI might be waiting outside their car in the parking lot at night. It may work in the short-term, but whether crying wolf is an effective long term strategy remains uncertain.
Executive and Grassroots
While garnering executive support early in the development of an SDL program is critical, it doesn’t guarantee success. The task of gaining support doesn’t end with the executive. You can lead grassroots efforts to spread the gospel of security, but it’s even more effective when it’s championed by multiple people within the development organizations. Advocates already embedded into the development organizations are your best allies and can be one of the most effective ways of increasing the speed and depth of SDL adoption.
However, a grassroots-only approach to SDL will not succeed. Reality dictates that an urgent deadline or a change in economics will force the unfunded and unsupported project to the bottom of the queue. Without the right upper-level support, a security bug rarely trumps the other application needs. And without internal advocates, teams may be slow to adopt the dictums from management above.
Thus, a team of advocates must be gathered from the executive suite as well as from the development organizations.
Policy can be persuasive
Inevitably, when running a secure development program you’ll encounter opposition from developers, their managers, and those managers’ directors. In some cases, they may have other priorities that take greater precedence. Yet in our experience we’ve found that as we dig deeper into the reasons behind their resistance, these individuals simply need to understand the reasoning behind why they should expend their resources towards furthering security goals or delaying development of other application features. A mild form of CYA. Policy, we’ve found, is often a legitimate and acceptable justification in the CYA world.
There will also be occasions where refusal to participate boils down to simple ignorance or has no good reason whatsoever. These situations often result in an impasse only resolved by executive arbitration. If you’ve already gained the support of the executive then you will likely prevail. However, we’ve observed that when this type of security versus developer conflict is repeated over an extended period of time, it will expend your precious political capital and ultimately erode executive willingness to support security objectives. A more effective way of heading off this problem is to capture executive support within security policy, even if only in the broadest of means, such as their support of ensuring PCI or HIPAA compliance. When conflict occurs in an environment with explicit policy, you’re able to fall back to company policy (as an embodiment of executive support) when reasoning doesn’t work. This immediately puts a stop to the back and forth by appealing to a higher authority. This has the added benefit of placing the onus on the aggrieved to break policy and expend their political capital instead. A third goal accomplished with a policy is achieving the scale necessary for larger organizations.
Although there’s no guarantee that having an executive sponsor will automatically result in a flourishing and secure development lifecycle, it’s guaranteed that without the proper support from executive management an SDL program will be condemned to die on the vine. In addition, gaining grassroots support in the form of internal advocates within the development teams can act as a catalyst to your efforts, and is an efficient means of raising awareness. Finally, capturing executive support in the form of a written policy helps explain the benefits and reasons behind the SDL program. It will help you navigate political quagmires and also has the nice benefit of reminding people to do the right thing even when no one is looking.
This Column is Part in a Series on Implementing a Secure Development Lifecycle: Read Vinnie’s Other Columns Here