A policy, by definition, is a statement of management intent that is mandatory for an organization. A security policy, obviously, focuses on the security of information assets. The National Institute of Standards and Technology (NIST), the definitive government organization guiding American innovation for more than a century, describes security policies as “a set of rules that governs all aspects of security-relevant system and system component behavior” that “define the objectives and constraints for the security program”. An application security policy (ASP) specifically defines the objectives that security controls should achieve in the development, deployment, and management of software applications. Policies in general answer “what” has to be achieved and “why”, rather than the “how”; the latter is addressed by procedures.

Types of Security Policies

Before we dive deeper into ASP, let’s take a look at the different kinds of security policies an organization can implement and their purpose.

1. Program: a program-specific security policy is a high-level strategic document that drives the organization’s security program, defining its purpose, scope, and roles and responsibilities. Issue-specific and system-specific policies are usually derived from it. These have a lot of management inputs and are updated rarely.
2. Issue: issue-specific policies pertain to specific threats (phishing, malware, etc.) or operational practices (acceptable use of company equipment, use of social media, remote access, etc.) that impact the security of organizational assets. These are more granular than program policies but less so than system-specific policies. These are also updated more frequently than program policies but not as often as system-specific policies.
3. System: system-specific policies apply to particular system categories based on their use (payroll, order processing, etc.) or function (firewall, web server, etc.). These are the most granular type of security policies and built with inputs primarily from technical control owners. These are updated regularly to reflect changes in technology and threat environments.

The Importance of Application Security Policies

To quote Wikipedia, “An application program (software application, or application, or app for short) is a computer program designed to carry out a specific task other than one relating to the operation of the computer itself.” Applications are the means by which modern life is run, without which computers have no meaning. Even as I write this blog post, while I’m typing on my laptop, I’m using the Google Docs web application. Even if I do so offline, I’ll be using the word processing application Microsoft Word. Considering the ubiquity of applications in our everyday lives, it is obvious that securing them will be of paramount importance. Therefore, an application security program is a necessity for every organization.

Application security policies define how organizations build, deploy,  and manage their applications. This includes applications that are built internally from scratch, those that leverage open-source software (OSS) and those that are sourced fully from external vendors, whether hosted on-premises or in the cloud (software-as-a-service). The scope is broader than a software development security policy, and help achieve the following:

• Balance business needs with security mandates
• Safeguard the confidentiality, integrity and availability of data stored, processed, or handled
• Align with security best practices, including training app owners and developers
• Comply with industry and regulatory requirements

The Core Components of an Application Security Policy

While there are no exact rules specifying how to write a security policy, an application security policy (ASP) typically includes the following core components:

1. Scope definition: specifies which applications within the organization’s environment the policy applies to.
2. Threat identification: describes relevant threat actors (nation states, opportunists, etc.) and attack vectors (software misconfiguration, social engineering, etc.) that put the application at risk.
3. Vulnerability prioritization: defines the logic to differentiate between different levels of vulnerabilities (critical, high, medium, low, informational).
4. Remediation and mitigation: specifies security controls like authentication and encryption to be implemented, guided by standards like OWASP Top 10, OWASP ASVS, ISO 27001, CIS CSC, etc.
5. Testing: describes the security testing (SAST, DAST, IAST, RASP) that will be performed.
6. Monitoring: defines how the application’s security posture will be monitored post deployment to Production.
7. Roles and responsibilities: outlines the different roles and responsibilities (developer, tester, etc.) across the different stages of the application development lifecycle.
8. Incident response: specifies how a security incident post deployment will be handled.
9. Communications: outlines communications requirements (who, what, when) during all the above stages of application development, deployment, and maintenance.

Guide to Creating an Application Security Policy

Now that an application security policy template is in place, here is how you would go about creating the policy itself:

1. Identify and engage stakeholders: identify the right stakeholders (business process owners, developers, end-users) and obtain their inputs.
2. Perform an application risk assessment: identify assets (software and hardware), threats, vulnerabilities, and existing controls to determine applicable risks and risk levels.
3. Writing the policy document: write the actual document based on the above inputs and including the components mentioned in the previous section above.
4. Obtain approval: review the document with the stakeholders, refine as per feedback and obtain approval.

Guide to Implementing an Application Security Policy

As the saying goes, the proof of the pudding is in the eating. Therefore, the ASP is of no use unless it is implemented, and this is how you should go about applying security policies in your operational practices:

1. Educate and train stakeholders: any change to existing practices encounters challenges. You can tackle them by educating stakeholders about ASP benefits and training them (for example, secure development practices) on implementing ASP requirements.
2. Integrate into existing practices: by integrating ASP requirements into the existing SDLC (software development life cycle), it is possible to move to a SSDLC (Secure SDLC) paradigm, ensuring end-to-end security in application development.
3. Implement suitable tools: ASP requirements can be better met by implementing the correct tools for application development, testing, and monitoring.
4. Validate and refine: conduct regular audits to confirm ASP requirements are being met continually, making refinements as required by changing business requirements, operating conditions and threat environment.

Conclusion

The threat landscape is always changing, Attackers are constantly developing new Tactics, Techniques, and Procedures (TTPs) to affect the Confidentiality, Integrity, and Availability (CIA) of data. Applications are the touchpoints for legitimate users, and unfortunately, what attackers have access to as well. As part of the attack surface, applications are of paramount importance. In such a scenario, leaving their security to subjective judgements by individual developers puts organizations at risk. Therefore, there should be a structure around the process. Developing and implementing an application security policy is the first step to addressing that and developing a “security-first” culture. Application security (AppSec) is the next frontier of cybersecurity, and organizations should prepare themselves to win. Remember, it’s not only the initial rollout that counts, but the continuous monitoring as well. A platform like Riscosity ensures organizations have full visibility over all data-in-transit, thereby reducing the risk of applications being misused.