NEWS AND BLOGATAHON2021 BLOGS

Covering breadth of SDLC through Security Testing

BlogATAhon2021 Entry

Covering breadth of SDLC through Security Testing

by Vishal Goyal

As application development continues to evolve, security testing has become extremely important. This has led to trends like DevSecOps and SSDLC to emerge and have become critical to success of the projects and client satisfaction.

Application security (short AppSec) includes all tasks that introduce a secure software development life cycle to development teams.

In 2020, a supply chain attack against a large IT company has exposed as many as 18,000 companies to cyber-attacks. Hackers had managed to alter the versions of a network monitoring tool that the company had released.

On July 02, 2021, large IT solutions developer for MSPs and enterprise clients, announced that it had become the victim of a cyberattack. It appears that attackers carried out a supply chain ransomware attack by leveraging a vulnerability in companies’ software against multiple managed service providers (MSP).

Many industries led consortiums have been setup to investigate security as critical element of software development and define common grounds to assess security within applications.

Web Application Security Consortium (WASC) has created the Threat Classification Reference Grid to allow individuals and products to reference Threat Classification sections with a static identifier (WASC ID).

The Common Vulnerabilities and Exposures (CVE) system provides a reference-method for publicly known information-security vulnerabilities and exposures. The use of CVEs ensures that two or more parties can confidently refer to a CVE identifier (ID) when discussing or sharing information about a unique vulnerability.

Shift left security helps organizations save a lot of time and money later since the cost of remediating a security vulnerability in post-production is so much higher compared to addressing it in the earlier stages of the SDLC.

Static Application Security Testing (SAST)

In this the application source code is analyzed while components are at rest. SAST analyzes application source code, byte code, and binaries for coding and design flaws that suggest possible security vulnerabilities. This gets usually implemented during development and QA and is often integrated into CI servers and integrated development environments (IDEs).

Security Vulnerabilities require immediate action and cannot be ignored. It is important to get detailed issue descriptions and code highlights that explain why your code is at risk.

As per recent research conducted, security vulnerabilities correlate with low code health, development hotspots, and a high author churn in the organization. A recent study (“The Presence, Trends, and Causes of Security Vulnerabilities in Operating Systems of IoT’s LowEnd Devices” (2021) by AlBoghdady, Wassif, ElRamly) investigates the presence of security vulnerabilities in some of the most popular open source IoT codebases Study didn’t just look at code, but also human factors like team experience and evolutionary properties of the code. The study identified a “strong negative correlation between security error density and the Qualitative Team Experience”.

SAST should be performed early and often against all files containing source code.

Dynamic Application Security Testing (DAST)

Dynamic application security testing (DAST) is a black box testing method that examines an application as it’s running to find vulnerabilities that an attacker could exploit. DAST is performed on a running application in an environment like production by simulating attacks against an application, service, or API, discovering vulnerabilities that are triggerable.

 

Below are examples of tests which we simulate for a web application. These are classified into High, Medium, Low, and Informational risk levels with details on where the issues were discovered and guidelines on how to fix them.

  • Advanced SQL Injection
  • SQL Injection
  • Application Error Disclosure
  • CSP: Wildcard Directive
  • CSP: script-src unsafe-inline
  • Cross-Domain Misconfiguration
  • Source Code Disclosure
  • Sub Resource Integrity Attribute Missing
  • X-Frame-Options Header Not Set

Interactive Application Security Testing (IAST) has emerged as an important element of security testing framework. IAST primarily differs from SAST in that SAST tests the entire codebase, while IAST only tests the functional flow which we are interacting with. This helps creating fewer false positives because IAST uses more than just source code to determine vulnerabilities. However, SAST can provide a more comprehensive test of the codebase than IAST on its own. IAST is also distinct from DAST because of its location within the application itself. The embedded agent allows for more granular issue identification with IAST than with DAST. IAST tools can specify the line of code in question, while DAST can only infer the sources of observed vulnerabilities.

Software Composition Analysis (SCA)

On 12-May this year, President Biden signed an executive order which calls for greater open-source security. President Biden’s executive order recognizes the need to secure open-source software. Reality is that most organizations do not currently have a good understanding of all the open-source software being used in their applications. Neither do they have any software bill of materials (SBOM) that identifies the exact components and versions in use across those applications.

Software composition analysis (SCA) tools perform automated scans of an application’s code base to provide visibility into open-source software usage. This includes identifying all open-source components, their license compliance data, and security vulnerabilities. In addition to providing visibility into open-source software use, SCA tools also prioritize open-source vulnerabilities and ideally provide insights and auto remediation to resolve security threats.

According to the State of Application Security, 2021 report published by Forrester “Open-source usage continues to grow, and security hygiene as-is can’t keep up. Open-source usage has only accelerated as development teams strive to produce high-quality applications quickly. Almost 99% of audited codebases contain some amount of open source, and the average percentage of open source in those code bases has almost doubled — from 36% in 2015 to 70% in 2019. Unfortunately, open-source vulnerabilities continue to be pervasive, and firms are unable to react quickly enough to remediate the issues, with over 50% of survey respondents reporting that it took a week or longer to remediate known OSS vulnerabilities in their code

There are additional technologies which are specifically designed for running applications

  • Web application firewall (WAF) which sits in front of a running web application and filters out attacks based on pre-set rules.
  • Runtime application self-protection (RASP) which operates from inside the application itself. RASP identifies and blocks attacks in real time by monitoring the applications behaviour, helping to mitigate the effects of vulnerabilities left in the code.

Infrastructure as a Code (IaaC) frameworks Testing

While we do thorough testing of the application stack, it is equally important to test the infrastructure as a code scripts for misconfigurations which can lead to security issues. This is applicable for both on-premises scripts as well as cloud templates for Azure, AWS, GCP.

  • Pipeline checks for hidden secrets within the code base
  • Testing IaaC scripts for any rule’s violation or security issues
  • Validate if Kubernetes is deployed securely per Kubernetes Hardening Guidelines from NSA and CISA (Cybersecurity technical report)

The National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) released a Cybersecurity Technical Report, “Kubernetes Hardening Guidance,” on 03-AUG-2021. This report details threats to Kubernetes environments and provides configuration guidance to minimize risk. The security testing framework needs to include tools to be able to check the K8 yaml files and clusters against these hardening guidelines and provide details on services which do not confirm to these. Some of the tests recommended in this report are listed below

  • Non-root containers
  • Immutable container filesystem
  • Privileged containers
  • hostPID, hostIPC privileges
  • hostNetwork access
  • allowedHostPaths field
  • Protecting pod service account tokens
  • Resource policies
  • Control plane hardening
  • Exposed dashboard

Conclusion

Security testing is critical and not a choice. Organizations need to adopt a shift left approach to security testing, ensure it covers the breadth of software development lifecycle and adopt tools and frameworks which makes it easier for projects to adopt and implement.

References

  1. State of Application Security, 2021 report published by Forrester, https://www.forrester.com/report/the-state-of-application-security-2021/RES164041
  2. Cybersecurity Technical Report published by NSA and CISA, https://www.defense.gov/
  3. National Vulnerability Database, https://nvd.nist.gov/
  4. Common Vulnerabilities and Exposures, https://cve.mitre.org/
  5. Common Weakness Enumeration, https://cwe.mitre.org/
  6. Web Application Security Consortium, https://www.webappsec.org/
  7. The Presence, Trends, and Causes of Security Vulnerabilities in Operating Systems of IoT’s Low-End Devices
  8. https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/

Vishal Goyal who works with Persistent Systems Limited is an experienced and proven technology consultant with 20-year track record of delivering results, adding value, and motivating teams. Diverse experiences include leading application support, managing and leading global project teams, building new innovative solutions and working across different geographies. Speaker with NASSCOM and enjoy writing about innovation, technology, and customer centricity

Leave a Comment