With the growing pace of applications embracing contemporary technologies like containers, Kubernetes and cloud native stacks like AWS and Azure, ensuring that apps using these technologies get secured is paramount. Product teams will end up having to prioritise security along with a truck load of other things on their backlogs. This poses significant challenges for companies trying to get their apps to the market on time.
In this article, we will look at a step-by-step approach towards Application Security Assessments that can help product teams to be proactive about application security, rather than being reactive.
Methodology and Steps
While many industry experts talk about various concepts to incorporate application security, DevSecOps has been a popular choice among top software giants. Among the many available, Gartner’s DevSecOps model has been one of the foremost proponents of this concept. Our article will focus on certain key concepts that will resonate with Gartner’s representation of DevSecOps and its implementation in the real world.
Taking this into consideration, we will propose our step-by-step approach to Application Security Assessment in two aspects: Manual and Automation. First let’s talk about facets of automation that can be implemented in a given software development lifecycle iteration.
Automation : The medium of implementation
In the contemporary scenario, applications are built to scale and are optimised for performance when they are deployed in production environments. This is where DevOps plays a key role to operationalise the agility of product development by deploying the apps seamlessly across their hosted infrastructure. However, the challenge for the product teams lie in anticipating and preventing attacks from malicious users across the world.
Read more: The biggest issues with appsec automation
While traditional threats like Denial of Service or Distribute DoS attacks are quite well handled through IDS/IPS and WAF systems, sophisticated attacks like XML External Entity(XXE), Insecure Deserialisation or Insecure Direct Object Reference flaws still tend to exist in many applications.
Product teams should look to create feedback loops across the SDLC to provide information about new and existing vulnerabilities. This can be achieved by embracing automation to enhance application security.
- Starting with the hosted environment, ensure that all production instances are homogenous and templatised. With infrastructure-as-code being used for continuous deployment, use of tools like Chef Inspec or Hashicorp Sentinel or Open Policy Agent can make things relatively easier.
- Parameterised DAST scans configured with Dynamic Application Security Tools (DAST) can help in finding low-lying security flaws. These scan results can provide product teams a reasonable amount of confidence prior to pushing changes to production.
- Use of Static Application Security Tools (SAST) and Source Composition Analysis (SCA) tools as part of the developer ecosystem will help finding issues introduced by either new code or new libraries can be caught early on.
Going in this order helps product teams to start shifting security left, iteration after iteration and ensure that they are able to scale up on maturity across sprints. This will be much more effective with the following changes in the team culture.
With that, we will now look into the list of things product teams will have to execute manually as part of their security checklist.
Manual Assessment: Things to consider
In the earlier section, we have discussed the automation possibilities to the Application Security Assessment challenge; and while it has its benefits, it also brings about a pernicious problem of result management.
Among the many challenges the product teams have in dealing with qpplication security, arguably one of the biggest ones is prioritisation. Given that the product teams collectively have limited time in any given sprint, this means that security is one among the many things that they will have to do. Invariably, application figures quite low in the ranks given its propensity for obscurity and complexity.
Here are some ways you can effectively utilise the results from tool automation:
- Correlate the results from each tool used in the assessment and map them to appropriate CWE IDs wherever applicable.
- Use the Severity assigned by the tool to categorise the list of findings; and if that’s not available try using an industry standard metric like CVSS v3 or DREAD to capture the quantitative aspects of the damage each finding can have on the application.
- Make it a habit to incorporate threat modelling at the start of a new sprint as a timeboxed event. This allows teams to start building a repository of potential threats, abuse cases and security tests they might want to test against their application. This could eventually feed into the automation segment and help with both depth and breadth of coverage.
Product teams looking for success in conducting application security assessments should keep in mind that both tactical and strategic awareness are essential ingredients.
The key is in finding the right balance among these two aspects and iteratively pushing the boundaries of appsec capabilities within the team. It’s always better for teams to start small and from the left of the proverbial software development lifecycle.