Product Security is a relatively newer security function compared to traditional information security functions. In most organizations product security is synonymous with application security, but it usually either includes or is tightly coupled with Infrastructure(cloud) security, and incident response. It makes sense because the security of a product is tightly coupled with that of the underlying infrastructure, and product incidents response requires deep product knowledge. Infrastructure these days is also declarative, and expressed as code.

A common question I have been asked is: How would you build a product security function or a program? There is no right answer to this question, because what is right always depends on the context of the organization. However, it might help to understand the various responsibilities the Product Security function usually owns. Generally speaking, any product security function is responsible for:

1. Identifying Product Risk
2. Working with the business to mange product risk
3. Educate and spread awareness about product security

In this post I present a product security function-map to help you organize your thoughts around building a product security function. At a high level, the product security team could be classified into four major functions, one of which is an oversight function (guess which one):

1. Security Assurance (Security Assessments, Requirements, and Standards)
2. Product Vulnerability and Risk Management
3. Security Tooling and Automation
4. Policy and Program Management

Security Assurance

This is the team responsible for publishing security standards, determining what standards or requirements apply to each product or feature, and performing security assessments to identify risk. Members of this team have deep technical knowledge about software security issues, and individual products of the business.

Some common activities of this function include:

• Publish security standards or guidelines
• Define mandatory security controls and engagement process with each engineering team for Secure SDLC
  • Work with compliance function to align the controls with the compliance requirements
  • Work with Security Automation and design the control implementation to actually help identify, prevent security issues
• Identify security issues within the products by performing the following activities:
  • Threat Modeling
  • Penetration Testing
  • SAST, DAST, SCA/OSS Scans and triage results
• Security Education and Awareness: One of the biggest complaints about ‘Security Training’ is that it’s useless, and boring. The reason that’s the case is because most training is generic, and not tailored to each function. The security assurance team has the most product-specific context about the common security anti-patterns and bugs. Therefore, if not deliver security training, this team could help produce content.
• Support Product Level Detection and Response: One of the areas that is not covered well in even a few mature organization is detection and response for adversarial activity within the application functionality. Even when the application produces proper audit logs, the SOC teams are usually not very familiar with application functionality and anomalous behavior. Therefore detection and response is not built properly to use application logs. The security assurance function can help build that.

Product Vulnerability and Risk Management

The primary responsibility of this function is to help manage risk across product lines and collaborating with different business units to manage their risk backlog. Because this is the primary responsibility of this function, it makes sense that this function is also responsible for communicating with the external stakeholders about product risk. The Product Security Incident Response team, which is responsible for handling product bug reports, and coordinating with CIRT, is also a part of this function.

Some common activities of this function include:

• Track Risk across all Products
  • For every product, periodically review all incoming, risk-accepted and addressed issues
  • Communicate the risk-status to internal stakeholder responsible for risk in each product area
  • Communicate the product risk, and backlog to Product leadership
  • Establish and maintain a risk management process
• PSIRT:
  • Manage responsible disclosure, and bug bounty programs
  • Manage customer reported, or other externally reported vulnerabilities
  • Coordinate with CIRT, Legal and PR on product incident response and communications
  • Coordinate with Customer Support on customer responses, and loop in Security Assurance, Product Management, or Engineering where required

Security Tooling and Automation

While #1 and #2 in this list directly correlate with the responsibilities of a product security team, this is not a separate function in most product security teams. The product security engineers who work on security assessments also spend a part of their time on tooling and automation within most security functions. I recommend seriously considering carving out tooling and automation into a separate function for step-function improvements in operational efficiency. Otherwise, security assessments, and day-to-day operations usually end up taking most of your security engineers' time, and the automation projects end up behind schedule.

• Deliver security controls and risk reporting as automated, self-service solutions:
  • Deliver automation to integrate SAST, DAST, OSS, container-scanning, antivirus scanning tools with build pipelines
  • Evaluate tools for the pentest functions or write tools that are required
  • Onboard engineering teams to use the security controls
  • Deliver automation for monitoring and reporting on control execution, tracking control output, and alerting
  • Deliver reporting for ‘Risk Management’ team around ‘Risk Tracking’
• Post onboarding, improve the quality of scanner output for SAST, DAST, OSS until they are completely self-service:
  • For SAST, DAST and OSS, tune the tools to enable high signal output
    • establish baselines of each prod, write custom rules and auto-suppress known-bad rules per project
    • Work closely with the product teams to incorporate feedback as an ongoing function
• Improve Customer Experience
  • Create a web application frontend for the onboarding process as opposed to a pull request
  • Create a Dashboard that allows drill-down of risk
  • Write WebDriver tests to enable reproduction of security bugs found in PSIRT or by pentest functions

Policy and Program Management

This is the oversight function responsible for governance and oversight of the whole program. Common activities for this function include:

• Policy and Process Management

• Define and maintain product security policies, standards and guidelines

• Program Management

  • Operations management
  • Program health management

• Pre-Sales Support

• Customer Support