Discussing AppSec Policies within DevSecOps
There’s no denying that today’s digital ecosystem must be protected. But preventing increasingly frequent and severe attacks, which often target customer data and confidential information, requires more out of your organization’s security policies. Add in the challenge of organizations being asked to develop, deliver, and deploy software faster than ever before, many are finding that their application security (AppSec) policies are insufficient—resulting in costly vulnerability triage and application deployment delays.
Recent research found that 70 percent of data breaches are directly linked to vulnerable applications and 60 percent of organizations have experienced a data breach at some point in the last three years. This highlights the critical need for formal, organization-wide security policies, in addition to AppSec policies that directly influence software developers and application security teams, who must still operate at the speed that modern DevOps requires.
Before discussing AppSec policies, let’s look at the common security policies found in most organizations today.
- Regulatory:Â Ensures that organizations strictly follow standards and regulations that they are required to adhere to, primarily due to their lines of business.
- Advisory: Instructs employees of an organization about which activities and behaviors are allowed or prohibited within the organization.
- Informative:Â Aims to inform employees about risks, threats, attacks, what to look out for, and how to possibly react to a situation.
- Organizational: Operates as the outline of the organization’s security program and how they implement their security procedures and guidelines for computer systems, etc.
- System-Specific Policy: Covers particular computer systems, for example, what hardware and software are approved for usage in a specific computer system.
- Issue-Specific Policy:  Addresses specific functional and operational aspects of an organization that needs more focused attention.
In most cases, there are also highly-detailed sub-policies under issue-specific policies, and many of them are listed in the next section.
When looking closer into an organization’s issue-specific policies, they can cover many areas of security within the IT environment as follows:
- Change Management Policy
- Physical Security Policy
- Email Policy
- Encryption Policy
- Vulnerability Management Policy
- AppSec Policy
- Media Disposal Policy
- Data Retention Policy
- Acceptable Use Policy
- Access Control Policy
Although vulnerability management policies may govern how organizations manage vulnerabilities, updates, and patches in commercially-obtained software and applications, for the rest of this blog, we’ll be discussing AppSec Policies, since they often influence the overall security of internally-developed software applications.
An organization’s AppSec Policy details what are the acceptable and non-acceptable risks they’re willing to take. Software applications will always have vulnerabilities and no organization will ever fully achieve zero vulnerabilities and zero functional bugs in the software they develop. Defining what risks are acceptable and what are not, is imperative at this stage.
An AppSec policy also serves as a pseudo contract between AppSec teams and software developers, so both fully understand what’s expected of them in terms of security. This policy also serves as guidance as to what vulnerabilities should be remediated first as a result of application security testing (AST) processes. Defining security policies is tightly associated with DevSecOps and these policies are vital to measuring the overall success of your DevSecOps initiatives.
The other areas of software development affected by an AppSec policy include how organizations integrate and automate AST solutions in their DevSecOps initiatives. The policy may include guidance on how to identify vulnerabilities due to coding errors, how to correlate the AST scan results, what type of vulnerabilities should be remedied first, and how to manage and monitor key performance indicators (KPIs).
The management and monitoring function is where organizations track their AppSec program’s KPIs as well. This allows organizations to see if, over time, the amount of the software vulnerabilities is decreasing, the rate of introducing new vulnerabilities is decreasing, and the rate of severe vulnerabilities is decreasing as well. There are all kinds of KPIs that organizations use to see if their security program is effective. Automating KPI monitoring, tracking, and reporting as much as possible helps key stakeholders become and remain better informed overall.
Part of that KPI cycle is about knowing what areas need improvement and what areas don’t. This allows organizations to determine if the AppSec policy is being met or not, or if developers need more training, or incentives. Organizations can also determine if the AppSec policy in place needs refinement. All of this activity allows organizations to measure their program’s current status and level of improvements being made. It also creates a feedback loop, back to your developers, since this process never ends. And the whole idea is to allow continuous improvement throughout your DevSecOps ecosystem.
Organizations that are working to embed security in their DevOps initiatives (to achieve DevSecOps) should develop a comprehensive AppSec policy that will help them continuously improve the security of their internally-developed applications.
To learn more about optimizing your AppSec policy and how to embed security into your DevOps initiatives, download our eBook here.
*** This is a Security Bloggers Network syndicated blog from Blog – Checkmarx authored by Stephen Gates. Read the original post at: https://www.checkmarx.com/2020/03/13/discussing-appsec-policies-within-devsecops/
