This is the fourth post in SAFECode’s Month of Champions series on building and sustaining a successful Security Champions program.

Also check out our podcast discussion with the series authors on the importance of Security SCs here.

By: Tania Ward, Dell with Altaz Valani, Security Compass

In our first blog post on this topic we explained the need to support a security culture within the software development lifecycle (SDLC) and the key role of Security Champions (SCs) in helping us meet that need. In the second blog post we dove deeper into the core skills and capabilities of a SC. In this blog post, we answer the question, “How do you build an effective SC program in your organization?”

Lay the foundation

We all know what happens when a house is built on a weak foundation. It’s unstable in the long run. Building an SC program is no different. There are foundational requirements that need to be in place for the program to be sustainable and effective:

  • Understand your existing security culture – putting on your security super-hero cap and reactively bouncing from one development team to another won’t save the day. You need to understand the current state of your culture first before you start systematically adding foundational security elements into it.
  • Management/Executive buy-in – this isn’t about getting a sheriff badge. It is about instituting sustainable change across the organization by getting support to create and roll out a program. It all starts with getting management buy-in and presenting factual data on how that program can save your company money, create value, or minimize risk (through better resiliency or compliance, for example). It is vital that you make the security program measurable. Show the long-term value you hope to achieve as you implement the foundational blocks of the security program.
  • Buy-in from Engineering/SCRUM team – the team needs to be aware that they are not policed by a new police officer in their town but supported by a member to resolve upcoming problems early on in a practical and risk-oriented way. The teams support is critical for the success of the role. We need support from top and bottom for the SC to succeed.
  • Policy & Standards – a book without pages, is it really a book? Put developer-friendly words to your pages and define what ‘building security in’ using concepts like Security by Design (means across the different phases of your SDLC) and Security by Default (making sure the product is secure at deployment). This will help you build a stronger foundation with the developer community in your organization.
  • Funding – it’s important to have financial backing to help drive reward & recognitions, invest in training/conferences/workshops, or sponsor fun activities such as Capture the Flag (CTF) to keep teams hungry for more. You need to engage teams and build a foundation based on proven financial commitment. Obtaining this commitment can then be used as the basis for achieving grassroots developer support.

Define and operationalize your program

This is where you define the main components that will make up your program. Yes, the sounds of nails being hammered in, and frames going up is the sign of progress. However, don’t build it too fast!

  • What is your organizational structure?? An SC is embedded into a software development team in order to accelerate development and to identify and solve security problems early in the development lifecycle. You should consider:
    • Whether the program is centralized or decentralized based on the size and development team layout of your company
    • Key problems that the SC will help address in different areas
    • How many teams the SC is expected to support
    • Geographic distribution
    • Risk tolerance across the organization
  • What are the roles and responsibilities? As we discussed in our second blog post, the following considerations should be addressed:
    • The target persona of your SC
    • Clear SC roles and responsibilities that not only define the skills needed, but also set clear expectations
    • SC influence by business function as SCs may not only exist in engineering teams, but may also be extended to end customer projects
    • Additional SC functional roles, for example, a developer, QE, or PM
    • Reporting structure that clearly outlines to whom the SC should report, for example, Engineering, Product Management, or Security?
  • Where do we find SCs? There are a number of approaches that have been adopted successfully by SAFECode members:
    • Anyone can become a SC. You need to provide a clear security certification and qualification program.
      • Identify engineers who have willingness to learn about software security and demonstrated security skills
      • Sell the role as an employee development opportunity
      • Volunteering-driven approach as opposed to “volun-telling”. Forcing someone into the role will not last
    • Hire security Subject Matter Experts (SMEs) s to fulfill the SC roles and responsibilities.
  • Do I need an operational playbook?: Everyone has a game plan and so should you. Whether it’s having regular sync ups, materials ready to go, a cadence for newsletters, or a centralized community – an SC’s knowledge can’t be static. It’s important to define a personal and career growth plan for this role. This requires SCs to have sufficient time to expand their knowledge and skill set. SCs must be enabled (intentional allocation of time and budget) to engage in the following activities:
    • Capture the Flag: Keep the skills relevant and evolving based on threat landscape
    • Tools: In a fast-paced environment, tools can save precious time by automating certain security tasks. The right tool is one that easily integrates with engineering’s existing processes and tools and is customized to reduce false positives in the environment in which it is being used.
    • Train the trainer: Train your SCs on the “what?” and “how?”
      • Aligning with what we mentioned in our second blog, the “what?” can include Secure Development Lifecycle processes, secure design principles, secure coding, security testing, tools, and writing security requirements.
      • The “how?” can include internal or external computer-based training (CBT), a buddy system with members from the security team, and on job training to change for understanding. We do not recommend reliance on CBTs alone.
      • Workshops on topics like threat modeling and code analysis.
      • Providing sufficient budget and time in order to update and acquire skills continually without having to go through a lot of red tape.
      • Awareness training so they know the latest security issues to look out for.
    • Conferences: The goal is to network and share information with other industry security practitioners.
    • Security Forums: This can be used for educational purposes especially if there are new attack vectors and threats. It can also be used as an avenue for presenting issues.

In conclusion, just finding an SC and telling them to go fix security will not work. To be successful, SCs need the support of a formalized, management-backed program with clear organizational and professional goals. We’ve added some links to additional resources below that may be helpful in thinking through SC program design. But do you know how to spot trouble in your SC program? Stay tuned for our next post that will highlight common warning signs you should be on the lookout for.

Additional resources that may be helpful: