What is an Application Security Policy?
WHAT IS AN APPLICATION SECURITY POLICY?
Now more than ever, cybersecurity is top of mind for every business unit — and Development is no exception. In the post-Equifax breach world, we understand that good Application Security isn’t just about tools, but about the processes that deliver the right information into Development pipelines at the right time. This mindset has led companies to explore SecDevOps: the integration of security into Development processes.
The key here is the word “right.” More is not more when it comes to information. In fact, it’s the exact opposite. Yes, we want BIG data, but let’s not confuse data with information.
da·ta | \ ˈdā-tə : factual information (such as measurements or statistics) used as a basis for reasoning, discussion, or calculation
in·for·ma·tion | \ ˌin-fər-ˈmā-shən : knowledge obtained from investigation, study, or instruction
In other words, data are pieces of information — like individual bits — without organization or context. When they get this structure — like lines of code — they become meaningful and actionable, and this is information that can be used for decision making. There’s a reason our industry is called information technology, not data technology.
In Application Security, the data are the security test results and the context is a policy. Without context, there is no way to understand what the security test result means for that company, division or specific project, so that it doesn’t just become another alert that creates bottlenecks.
At its core, a policy is a reflection of the company’s risk profile, providing guidance on how to execute it, when to execute it, and how to control for it.
What is an Application Security Policy?
Well, let’s start with what it isn’t: Compliance, Business Workflow Rule, Checklist…you get the gist. While these may be downstream functions of a policy, if you start with the mindset that it is one of these things, then you will only see it as a thing you have to do, not a strategic tool for how to implement Application Security.
Our good friend Merriam Webster tells us a policy is “a definite course or method of action selected from among alternatives and in light of given conditions to guide and determine present and future decisions.” Not to sound like a broken record, but again, policies are not rules or checklists, but rather guidance on how to manage specified situations — both proactively and reactively.
At its core, a policy is a reflection of the company’s risk profile, providing guidance on how to execute it, when to execute it, and how to control for it. Policies should not be about perfection, but rather finding the guidelines that work 80% of the time, so DevOps and AppSec teams can focus their attention on the 20% where they don’t work to find solutions, rather than the all or nothing
A Rose by Any Other Name
The concept of a policy already exists in Development, it’s called something different: Coding Standards.
So when Development thinks of policies as just secure coding standards, it not only reduces friction in their adoption, but provides natural points for Application Security to integrate into the SDLC:
- Design: Understand what policies are pertinent to a project and how they will impact project delivery.
- Code: Share the policies with the Developers and allow them to provide feedback during the pull request
- Build: Check — either manually or through automation — to understand if the code meets the standards to be committed.
- Test: Identify security defects, fix what has to be fixed before release and prioritize the rest as part of technical debt
- Deploy: Verify that the code meets the standards set to be released into production — and if not, that it has the appropriate signoffs to be deployed
- Maintain: Continue to identify new security defects and continuously re-prioritize security debt
- Operate: Get continuous feedback on policy performance and real-time understanding of the health of the pipeline from an Application Security perspective
Policies provide the context for how to manage the data at each stage and turn it into actionable information. Going back to Merriam, we’re reminded that a policy is a “ method of action…to guide, “ which means that it’s not a definitive rule, but a guideline. That being said, it is critical to have visibility into understanding when the policy has not been followed so that you can make educated decisions on how to handle it.
Why do policies have such a bad rap?
Policies have lived outside of the world that they impact — Development — for too long, often trapped in Excel and PDF files that get distributed quarterly and lack connection back to the work they’re impacting. So, no wonder they often feel aspirational or esoteric. A good policy is rooted in action: how and when to execute and control — and how to manage when it doesn’t work.
- How to execute: What are the instructions? How do I implement it?
- When to execute: In what situations is this policy applicable?
- What is the control: Is this manual or automated? What is the test and how often is it run?
- Exception Handling: Who needs to approve? When will it be fixed (if ever)?
When the focus is on creating actionable policies, they can be integrated into the existing development processes without disrupting the workflow and will even improve Development productivity, reducing project delivery risk and potential “fire drills,” all while producing better code.
A good policy will evolve. Development priorities and security risk are never static, so policies must be living, breathing entities. As the threat landscape changes, a company grows or enters a new direction, and efficacy is measured, policies are going to change.
Originally published at https://wabbisoft.com on March 1, 2020.
