Secure Development Practices Aren’t Enough

By Stacy Simpson, SAFECode

A key principle guiding SAFECode’s work has always been our belief that secure software development can only be achieved with an organizational commitment and a holistic assurance process. But what does that mean in practice? Simply put, it means that a mature secure development lifecycle (SDL) includes more than just a checklist of secure development practices. It also encompasses all aspects of a healthy business process, such as program management, stakeholder engagement, deployment planning, program measurement and continuous improvement. SAFECode felt strongly enough about these non-technical aspects of the secure software development process that we included such considerations for SDL planning and implementation in our third and most recent edition of our flagship publication Fundamental Practices for Secure Software Development.

SAFECode is uniquely positioned to support those working toward building a holistic corporate program for delivering secure software. Many of our Member representatives, especially those on our Board of Directors, have direct responsibility for leading secure software programs at large global commercial technology providers, overseeing nearly all aspects of program management. Using their advice, we thought we’d create a series of short articles that expand on the guidance offered in our Fundamental Practices paper and point to additional SAFECode resources that can assist with these key elements of program planning.

Culture and the SDL

We’ll kick off this Fundamentals of Managing Software Security series at the intersection of corporate culture and SDL planning. In truth, a discussion of building security-supportive culture could fill an entire book, but we’ll try to stick here to some practical, concrete advice that our Members have identified as essential building blocks of culture development. There are two areas of culture-related SAFECode recommendations we’ll address:

• Security leaders must consider the existing culture of their organization when planning the deployment of a new SDL process or application security control.
• Creating and fostering a security-supportive culture is essential to successfully scaling a software security program.

 

Consider the Existing Culture in Program Planning

 

We’ll start by talking a bit more about what we mean when we recommend in our Fundamental Practices paper that security leaders consider the culture of their organization when planning the deployment of any new SDL process or application security control. It is important to recognize that any new secure development practice is not being implemented or performed in a vacuum. Security leaders working to socialize secure development practices should become students of the culture and business practices of their organizations. What can be learned from Human Resources’ roll-out of a new employee benefit program? How did Product Management get development to buy in to the new set of documentation requirements it added last year? Studying past examples of process or requirements changes – including those that were unsuccessful – will help inform your own deployment and implementation strategy. Does the organization seem to respond well to corporate mandates from the C-level or is a more grassroots approach from within the engineering team more likely to be embraced?  What incentives seem to work well for behavior change? Who are the key influencers within the organization and how can they help socialize a new program or practice within their teams? How does a new process support the vision of the organization and goals of its employees – and how can that alignment of purpose be better communicated?

Steve Lipner, SAFECode’s executive director, expands a bit on this in a blog post he wrote for CSO on Conway’s Law and its application to SDL implementation. Conway’s Law says “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” It’s normally interpreted to say that the structure of systems is often the same as the structure of the organizations that create them.

In the blog post, Steve ponders whether software security assurance teams that aren’t part of a development organization might be doomed by the social boundaries of their organization to trying to achieve software assurance with after-the-fact inspection and testing. He concludes that regardless of the organizational structure, a successful software security team has to understand the way the development organization works, work cooperatively with the development organization, and focus on enabling them to build secure software as part of their task of building software. It is an interesting read for anyone thinking about integrating security into an existing development culture.

 

Forge a New Culture of Security

 

In addition to the consideration of existing culture and its impact on an organization’s SDL implementation strategy, there is a growing recognition among security leaders of the importance of fostering a security-supportive culture.

SAFECode Chairman Eric Baize talked about the importance of culture development in a keynote at OWASP AppSec California 2018. To paraphrase, ‘Successful implementation of software security at scale has led to an emerging need of bringing a cultural change across development organizations, software developers, and technology users. Development organizations play a pivotal part in serving this need and should plan on creating an ecosystem that makes security pervasive for developers. They could do so through a program aimed at driving multi-tiered expertise and empowerment across all engineering functions.’ We have both a video of the keynote and a summary posted here for anyone interested in learning more about driving better security by changing the software development culture.

 

Bring Champions to the Culture Challenge

 

There is no single right way to foster a security-supportive culture and most organizations use a variety of methods to create the environment they need for the SDL to succeed. But the use of Security Champions is a culture-building mechanism in common practice across SAFECode members. A Security Champion is a member of the development team uniquely empowered to support SDL execution and security activities on a daily basis.

The need for Security Champions arose from the observation that development organizations interested in building a security culture often lean on an ad-hoc mix of activities, such as an occasional Capture-the-Flag Exercise or “bug bash” or an informal security volunteer program where senior developers mentor junior team members on a certain aspect of security. Unfortunately, in the absence of management visibility and program-level support, such ad-hoc efforts frequently face resistance and often fail to make an impact. SAFECode members attribute much of this difficulty to the lack of a sponsor – or a “champion” – at the program level to cohesively drive security activities. To change this dynamic, many SAFECode members implemented programs that provide development teams with resident Security Champions who are consistently available to support SDL execution and security activities. Ideally the Security Champion comes from development team and is seen as an insider trying to help with an important challenge rather than an outsider trying to impose new rules or overhead.

Given the positive outcomes SAFECode Members reported from their own Security Champions programs, SAFECode decided to highlight this program element by hosting a “Month of Champions” this past January. Members provided guidance throughout the month on how to build and sustain a successful Security Champion program, even sharing lessons learned from mistakes they have seen made along the way. These insights should be of interest to anyone working to build a more security-supportive culture within their development organizations – whether they already have an established a Security Champions program, are considering implementing one, or just hearing the idea for the first time. One key takeaway from the guidance is that just naming a Security Champion and telling them to go fix security will not work. To be successful, Security Champions need the support of a formalized, management-backed program with clear organizational and professional goals.

 

Consider Training’s Role in Culture Development

 

The expertise and skill level of an organization also has a significant impact on its security culture. Software security training and education programs are often implemented to increase security awareness, and ensure the skills necessary to meet security expectations and implement recommended security practices. Training has long been a core focus for SAFECode and we’ll share more on training’s relationship to culture development and program management in an upcoming article. Stay tuned!