Putting a Face to Software Security Champions

Posted on

This is the third post in SAFECode’s Month of Champions series on building and sustaining a successful Security Champions program. See here for Part One: Start 2019 Strong: Join SAFECode for Our Month of Champions and here for Part Two: Building Secure Software: It Takes a Champion.

By Kristian Beckers, Siemens and John Martin, Boeing with Nick Ozmore, Veracode

Product team manager: “The security people are smart but they’re like helicopter parents. They fly in, make a lot of noise telling us to do things differently, then fly off. We’re left with trying to figure out how to handle all the stuff they said ‘NO’ to.”

The second post of this series talked about why a Security Champion (SC) program is needed, including the common misconception among many software development teams (and the culture at large) that security issues are at best a hindrance and at worst a roadblock to productivity. In this post, we’ll talk about the qualifications and functions of an SC and demonstrate that security does not have to be the roadblock it is perceived to be. In fact, productivity, speed and quality improve as a result of a security mindset.

So, who is an SC?

 

Typically, an SC is an active software developer who is also a knowledgeable member of a larger software security community. They are embedded into a software development team in order to accelerate development, by identifying and solving security problems early in the development lifecycle. SCs ensure that security quality gates are met throughout the development lifecycle. The SC is empowered to escalate problems to the security team and management. In short, SCs are enablers inside of development teams that prevent security from becoming a blocker for product release. In this way, SCs empower development teams to produce continuous security value for customers.

What characterizes an SC?

SCs face the challenge of integrating security by default (by design). It is the SC who ensures that security is integrated right from the beginning. They work to help developers produce secure code starting with the very first line of code they write. They also ensure that security makes it onto the product roadmap. They also need to make sure that security is not only in their team’s code, but also in code of upstream vendors.

The role of an SC should be treated as a primary responsibility, ideally a full-time or near full-time job. SCs need to partner closely with the broader security team and be able to prioritize security issues based on risk. In this way, an SC is a context-aware topic driver in the engineering team and interface/translator to the security team. An SC should not be a Scrum Master, a PO (Product Owner), or a person that has multiple roles already and no time to cope with the various challenges producing continuously security value presents.

An SC also checks that verification-type activities are done properly. The SC makes someone accountable to run testing tools and ensures that they know how to interpret the results while keeping the SC involved, at least in an awareness capacity. Also, the SC can be responsible for Secure Code and Design Reviews within their respective teams and assign OPS responsibilities for security issues.

What else do Security Champions do?

SCs are also experts at helping and coaching teams. One SAFECode member company that uses risk-ratings as compliance and production-gate criteria (higher risk software had increased test and compliance requirements prior to production) had a development team that was using binary scanning as the final code quality gate and was repeatedly having a ‘one-and-done.’ They would scan once at the end of the production cycle, pass, and go to delivery. When the development team began including a Security Champion, it began to recognize that its current “one-time” scan approach was flawed and incomplete. The Security Champion was able to conduct a risk assessment and to help the team identify better components, deal with the increased volume of security findings, and hit the appropriate security production gates. Within just a few months, the team went from being a false-negative (unreported high-risk defects) to proactively identifying and addressing security issues.

The core duties of SCs can be categorized into three areas: (1) Directly support team members in security activities and foster security expertise and awareness among the development team (Security Awareness Duties); (2) enable the integration of software engineering activities with the development lifecycle (Enable Security Duties); and (3) Understand intrinsically both the company’s and their assigned product portfolio’s risk appetite (Risk-oriented Duties) and apply this understanding to the entire software development lifecycle. Below we break these three responsibility areas down in more detail:

  1. Security Awareness Duties include:
    1. Fostering security expertise and awareness among the development team
    1. Motivating team members to address security concerns early and continuously, and raise awareness of security issues
    2. Communicating security status (achievements and problems) to the security team and team members
  1. Enable Security Duties include:
    1. Ensuring that security features are prioritized appropriately and not handled with less urgency than functional features
    2. Ensuring that security is addressed right from the beginning (security by design)
    3. Ensuring that security is integrated and injected everywhere and that the development team has the right tools they need to succeed (end to end)
  1. Risk-oriented Duties include:
    1. Ensuring a risk-oriented approach (i.e., Risk Appetite) that includes knowing the risks the company or domain is willing to take on
    2. Checking that the risk-oriented approach is integrated into all stages of the software engineering process (SDLC)

It is important to note that the detailed definition of the duties of an SC may vary between organizations of different sizes, domains, and security process maturity. For example, one SAFECode member stated that their SCs aren’t pushing new security features, but ensuring the wider development team is following secure development practices and using/reviewing tool output, performing secure code reviews, etc.

Various roles in the software engineering context can become SCs or SC Supporters and contribute to the security effort:

  • Engineers know the details of one security mechanism and can check if details of, for example Identity and Access Management (IAM), are securely used and best practices are applied.
  • Developers know the nitty gritty details of implemented applications and can spot security problems in code (4 eyes principle or pair programming).
  • Solution Designers/Architects understand how system parts interface and where security problems in system composition, commissioning, and integration occur.
  • Program Managers explain to the development team the value security creates for their product and why it provides trust to their customers.
  • Product Owners understand the security value of the functionality being built in the current sprint. They ensure that acceptance criteria exist that reflect these.

SCs must have knowledge in key areas relevant for conducting security tasks. At least the following competencies must exist or be obtained with training:

  1. Software Engineering
    1. Software Development Methods and Tools
    2. Secure Software Development and Deployment
  2. Threat and Risk Analysis (see also SAFECode’s white paper on Tactical Threat Modeling)
    1. Threats Identification & Mitigation
    2. Attack Path Analysis
    3. Software and Information Risk Analysis (such as Threat Modeling)
  3. Vulnerability Monitoring and Incident Handling
    1. Vulnerability Lists (e.g. CVE) and Ratings (e.g. CVSS)
    2. SIRT & PSIRT Playbook support
  4. Soft Skills
    1. Conflict resolution
    2. Discussion and presentation skills
    3. Motivating people
    4. Drinking a lot of coffee with all stakeholders all the time (team, managers, etc..)

 

In some contexts, professional certifications may also be required or helpful depending on business needs. While SAFECode members do not endorse any one certification, examples of potentially relevant certifications include: the Information Systems Audit and Control Association’s (ISACA) Certified Information Security Manager (CISM) and Certified Information Systems Auditor (CISA) certifications, as well as ISC2’s Certified Information Systems Security Professional (CISSP) and Certified Security Software Lifecycle Professional (CSSLP) certifications.

Summing up, an SC has both security engineering and software engineering knowledge. SCs have to be able to talk to experts in both fields and be a catalyst for the unification of both fields.

Identifying or hiring an SC is really just the first step. They also need to have the right support to truly be empowered to be difference-makers. Stay tuned for the next post in our series, which will discuss how to create a successful Security Champions program.

Copyright © 2007-2018 Software Assurance Forum for Excellence in Code (SAFECode) – All Rights Reserved
Privacy Policy

Share
Share