Software Integrity Blog


The 3 fundamentals of a software security initiative

You take calculated risks every day. Just this morning, say you decided to walk across the street against the light because no cars were in sight and you had to get to work on time. But had that street been a highway—or if you had been with your child—you quite possibly would have made a different decision.

We rely on our experiences, and the experiences of people we trust, to set the bar for the risks we take on. Some risks are acceptable and some aren’t. Software security is no different.

When it comes to assessing security risks that could impact the trust of your customers and the reputation of your business, you can’t make arbitrary decisions. You can’t just hope the software and applications used within your organization are secure. Instead, you need a system that makes sure you don’t ignore unacceptable risks.

The critical need for a software security initiative (SSI)

As compliance and regulatory requirements increase and high-profile breaches raise awareness of software security, organizations are investing in approaches they believe will reduce risk such as application security testing regimes. Some of these approaches involve penetration testing a handful of apps once a year to meet minimal compliance requirements. Others have installed wireless application protocol (WAP) and monitoring programs to bolster firewall protection.

Are these approaches valid? Yes. Are they strategic? No, they are not.

Proactive security saves time and money, but it is not going to be enough. A security PROGRAM is what you need to put in place to lower your exposure across the board,” according to Tyler Shields, Senior Analyst, Forrester Research, Inc.

A comprehensive SSI has multiple benefits:

  • Gets your team up to speed on security requirements more quickly
  • Improves communication and alignment across teams
  • Provides consistency for everyone in your software supply chain
  • Helps you measure and communicate success
  • Makes sure you address unacceptable risk

A blueprint for software security

The most effective SSIs are tuned to fit your organization and built to scale. They help you “show your work” by creating a methodology for lowering your risk and explaining how you have made investment decisions.

The best way to develop a software security initiative is a three-pronged approach that includes security standards, security policies and security metrics. Standards and policies drive cooperation toward a defined and shared goal. And, metrics are crucial to ensure that you are achieving success with your security program.

1st Fundamental: Security standards

Standards provide developers and application testers with guidance on what your company will accept and what it won’t. They are essential to maintaining consistency across your supply chain.

When standards are documented and widely communicated, developers understand rules for the type of code they may use (e.g., COTS, open source, libraries) and the security requirements they must incorporate in their programs (e.g., asserting specific crypto algorithms or defining banned coding functions).

2nd Fundamental: Security policies

Security policies ensure that everyone involved shares a common definition of terms, understands roles and responsibilities, and has a set of operating procedures and governance rules to follow.

Security policies typically cover:

  • Application testing – define risk classifications, determine which applications must be tested and which gates they must pass
  • Remediation – set expectations for fixing bugs and flaws
  • Network security – determine protocols and authorization levels
  • Data security – protect your valuable IP and sensitive customer data
  • Physical security – govern access control and secure your infrastructure
  • Disaster recovery – determine steps to take in the event of an attack, including reporting, recording, and resolution

3rd Fundamental: Security metrics

In order to demonstrate your results and track your progress over time, you must establish a defined set of metrics.

Some examples of strategic and operational metrics include:

  • Number of critical applications that must undergo in-depth testing
  • Number of tested applications
  • Time to run test per application
  • Time from design to launch to create a secure application
  • Number of applications that meet or exceed compliance requirements
  • Number and cost of resources to ensure application security
  • Number of bugs in code that reach production

Right-size your security strategy to match your business

A software security initiative must be customized to match your organization. And of course you will want the program to be cost-effective and address your business’ specific level of unacceptable risk.

Whether you have a standalone software security group with security oversight or you embed responsibility for security within each engineering group or business unit, you can adapt this three-pronged model to create or evolve your software security initiative, and lower your risk of a security breach.

Learn more about designing your software security program.

More by this author