Posture Two — Application Security Posture Management
Article 4 of 9 in Building Your Cybersecurity Posture on Medium
Application security is not a new capability, however the surface area that application security encompasses continuously expands to protect applications against new attack vectors and threat actors. Enterprises need to re-evaluate their application deployment process. As part of a holistic approach, I propose enterprises need to make all applications potential risks transparent to the organization, to security, and to product owners so that they can prioritize security tasks appropriately.
What is an Application Security Posture?
I propose Application Security Posture Management is a compliance tool that measures your applications portfolio’s risk to potential exploitation, vulnerabilities, configuration errors, and exploitable interfaces by assessing the volume, severity, security zones, and deployment frequency of your application assets. An ASPM accumulates data using the api’s of application portfolio management, code repositories, open source code scanning, static code scanning, credential scanning, image scanning, and dynamic application security test tools to create and overall risk score for each application. An ASPM should help remediate three main risks: application’s missing or incorrectly implementing security scans, security issues existing beyond your security standards timelines, and over privileged or unused access in security tools. Although ASPM’s do not exist as such at the present, I hope someday they will.
The Nature of Aging Code, Vulnerabilities and Policy Violations
Applications can be deployed into environments continuously…but not in all cases. So often we have hired a firm or built out a small tool that gets deployed and is forgotten about. What does the old waterfall process of managing projects have to do with application security…well I’m glad you’ve asked. Vulnerabilities are in your code as soon as you use a dependency or write code…it just hasn’t been uncovered yet. As researchers find code vulnerabilities in known libraries or frameworks they create a public report known as a CVE, or Common Vulnerability or Exposure. So all of your applications and their code bases, if they referenced open source libraries, will likely have new vulnerabilities found as time progresses. As a cyber security managers, as soon a new CVE is reported, your risk in your application security posture has increased without any code being written or deployed by your engineer. It’s your job to know that your risk to potential threats has increased. Understanding your application security posture is a daunting task in an ever-changing environment.
Again, the first step in knowing your application estate.
- What code repositories do you have?
- What are their dependancies?
- Are they publicly exposed or internal time bombs?
Your application estate can be collected in an application portfolio management tool, but often it’s just captured in your code repositories. Getting access to all your code repositories and putting financial controls on procuring other source code management tools is just as important as knowing your could estate. The code that drives your company must be secure, auditable, and monitored for the risk to your company…even if it is open source code and publicly available. Any vulnerability can become an exploit or a breach without warning. There is not rule that a vulnerability has to be detected before it can be weaponized.
What is a Vulnerability and what types of Vulnerabilities are there?
A vulnerability is a section of code or an interface a threat actor can take advantage of to preform a malicious actions. Some examples of this are to retrieve data, grant elevated permissions, make improper transactions, impersonate another user. Vulnerabilities are usually categorized into categories of severity: critical, high, medium, and low. Vulnerabilities also can be described by two major attributes: exploitable and fixable. Exploitable vulnerabilities are code vulnerabilities with a known way of exploiting the flaw. In application security, vulnerabilities can be found in your code or in a dependency.
Some Common Types of vulnerabilities
- Referencing Open Source Libraries with known vulnerabilities
- Exploitable — known vulnerabilities that have published ways to take advantage of it.
- Fixable — is there a new version of the dependency that fixes the security vulnerability
- OSWAP(Open Web Application Security Project®) top application security risks to applications
- CWE (Common Weakness Enumeration) Top 25 Top 25 Most Dangerous Software Weaknesses
- Misconfigurations — IaC deployed that does not implement your enterprises infrastructure security standards or technical hardening requirements
The Six Application Development Zones that need Continuously Monitored
In defining what an Application Security Posture Management tool should do, I see that in order to be successful, a ASPM would need to have visibility into these six development zone of activity and to measure application risk.
- Integrated Development Environment (IDE)- The furthest left that we can help developers avoid vulnerabilities is in their development environment. By providing immediate feedback to developers when use a dependency with a vulnerability or write code that doesn’t follow secure coding best practices, you essentially create an extremely short feedback loop. Fixing code as it is written and making sure that it is written well from the start is an extremely important practice to champion inside an enterprise. It also reduces your application portfolio’s overall risk profile by reducing most issues before they ever get built into an image or deployed to an environment.
- Source Code Repository — The next best location to find a vulnerability is in the source code repository. Tools exist today to continuously monitor your code estate react when as new CVE’s that are reported. By using automation, a new code branch can be opened, tested, and even merged and deployed to fix newly uncovered vulnerabilities.
- Continuous Integration Process — Each time you check in code, there is an opportunity to immediately check for vulnerabilities as part of your CI process. I find that this seems to a double check from standard monitoring of your source code repository, but it’s a necessary check because it ensures that when you create a new code image, you have no known vulnerabilities deployed.
- Image Repository — Continuously monitoring your image repository ensures that when applications are built, that stale images, OS vulnerabilities, and dependency vulnerabilities are detected before deployment.
- Continuous Delivery Process — Every time before you deploy code, there is an opportunity to do one last check. Even though it’s unlikely new vulnerabilities are detected during the continuous deliver process, this step produces a definitive record that you know the code delivered is compliant with all security policies at the time of deployment.
- Runtime Environment — Monitoring you runtime environments is a last line of protection against potential exploitation. As code ages, your containers may be a risk if new vulnerabilities are discovered in code dependancies.
How ASPM can Protect Your Application Portfolio
By continuously monitoring the six zones of appellation security and being able to validate that each application is monitoring for misconfigurations and vulnerabilities within the timeframes that your security policies dictate, I believe that we can get a better holistic view of your application portfolio’s risk. This understanding will enable security officers to more accurately maintain compliance, pinpoint areas of improvement, and prevent exposure to external threats.
Articles in my Medium series “Building Your Cybersecurity Posture”
Article 1 — “13 Asset types to Build Your Cybersecurity Around”
Article 2 — “The 6 Categories of Cybersecurity Posture”
Article 3 — “Posture One: The Three Streams of a Cloud Security Posture”
Article 4 — “Posture Two: Application Security Posture”
Article 5 — “Posture Three: Data Security Posture”
Article 6 — “Posture Four: The Three Focuses Enterprises Need for an Identity Access Management Posture”
Coming soon…
Article 7 — “Posture Five: Network Security Posture”
Article 8 — “Posture Six: Device Security Posture”
Article 9 — “The Future of Securing Your Assets in a Decentralized Cloud”
As my daughter says, if you are interested in “what-ever-this-is,” then please consider following me on Medium.