What is security governance?
Security governance is a framework of policies, standards, and processes that form a structure for making decisions and defining expectations with respect to software security. The most important combination of policies, standards, and processes is the secure SDLC, which defines how a firm will build security in for both its various SDLCs and for software acquisition.
The vast majority of firms have no software security governance. That means they have no secure SDLC and, despite many claims to the contrary, no systematic control over the security posture of their application portfolio.
That’s bad. Customers don’t like it, insurance companies don’t like it, regulatory bodies don’t like it, and executives and boards of directors don’t like it. In today’s world, control over the application portfolio security posture is simply a required cost of business.
Some firms establish their framework through a centralized corporate group that issues formal policies, mandatory standards, and rigid processes. When this is done in a vacuum without appropriate stakeholder input, engineering teams often see it as bureaucracy simply for the sake of bureaucracy.
Some firms establish their framework through an engineering group that defines, for example, required technology stacks, mandatory coding standards, and defects that are always unacceptable.
In the end, it may not matter which group establishes or enforces the mandatory expectations, as long as it actually gets done. Without these efforts, there’s no “secure SDLC” regardless of anyone’s good intentions.
3 reasons you need security governance
1. Policies define how the business will act in a given scenario.
While different firms may use a term such as requirements, responsibilities, or “our culture,” each probably has a set of decisions it has committed to paper and will follow. Software security needs to be a first-class citizen and get its own policy—by any name—providing objective directions on how the firm as a whole will behave with respect to software security. This greatly reduces the chance of any one person engaging in behavior that puts the whole firm at risk.
2. Standards establish the level of quality or accomplishment that must be reached by a given effort.
The important point is that standards, like policies, must be mandatory. If compliance is optional or they can be redefined locally at will, then the “standards” may actually be procedures or guidelines and should be defined as such. Documented software security standards will reduce or eliminate certain security vulnerabilities by, for example, providing developers clear guidance and pre-built secure-by-design modules. Standards provide developers pragmatic and clear guidance about what your company will accept and what it will not. Our experience shows that the majority of security bugs are not exotic, one-of-a-kind issues, but well-known vulnerabilities that are often easily preventable.
3. Good business processes are transparent, align with corporate culture, and provide cost-effective value to all stakeholders.
Good processes prevent bad artifacts—including source code—from getting to the point where they create unacceptable risk for the firm. Whether the process is a secure SDLC with gates or is agile/Scrum with security reviews, it must set clear expectations for who does what and clear guidance for “acceptable” means relative to security. Keep in mind, a good process here will set expectations everywhere, not just with employees but also with vendors and others.
8 security standards and policies to consider
- Software security. Tell everyone the high-level expectations for getting software security done in your firm.
- Application testing. Define application risk ranking classifications, determine which applications must be tested, which gates they must pass and set schedules for testing intervals.
- Software projects. Define impact rankings for software projects and outline how the rankings drive associated assurance efforts.
- Remediation. Set expectations for which coding bugs and design flaws must be fixed and how quickly they must be addressed.
- Network security. Determine protocols and authorization levels.
- Data security. Identify and classify 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.
Who needs security governance?
While helping organizations design software security initiatives, we’ve seen governance frameworks of all shapes and sizes. And we know that what may fit a global organization employing thousands of developers and building large, dynamic application portfolios in a highly regulated environment may be inappropriate for a smaller engineering-driven company with a handful of applications, a distributed management culture, and no compliance requirements.
However, regardless of your organization’s size, clear, enforceable, and enforced software security policies and standards—especially when executed in the form of a secure SDLC—will improve communication and increase your ability to create and maintain secure software. This is true even if your group hates the word “policy” and doesn’t put much stock in “standards.” Regardless of the names used in your culture, every process works better when it's clearly defined and enforces expectations you can monitor and measure.
Interested in learning more about how better security governance can help your organization improve its ability to create, acquire, and field software that is more secure? We offer software security services to help you jump-start a software security initiative, or measure and improve yours if you already have one.
Continue Reading
SANS report: Securing the shifting landscape of application development
