Application Security

AppSec is the ability to adequately protect web applications and associated services against malicious attacks. AppSec starts early in the Software Development Lifecycle (SDLC) and needs to be revisited often, even post production release.

Secure Software Development Lifecycle (SSDLC)

The SDLC contains 6 key phases; As it pertains to appsec, the following activities should occur:

  1. Planning – Review of Project Plan, Initiatives, Resources & Timeline.
  2. Requirements – Technical Security Requirements are created, reviewed and/or enforced (if they already exist).
  3. Design – The first round of design documentation is becomes complete, threat modeling begins.
  4. Development – Coding and Implementation occurs, Code reviews, code testing (such as, Static application security testing – SAST, SCA)
  5. Test – DAST (may also be development phase), Penetration testing occurs.
  6. Release – Approval to move into Production, Continuous Monitoring begins, Annual/biannual/quarter Pentesting.

Mitigate AppSec Threats Early by “Shifting Left”

Mitigating common threats should occur early in the SDLC starting in the Requirements, Design and Development phases and continuously revisited. This article will walk through the major key events that should occur to prevent security events later.

Requirements

Application security vulnerabilities allow software to be vulnerable in ways that the developers never thought of. Security Engineering should always be involved during the requirements phase.

  • Requirements should be clearly defined, documented, reviewed and approved by the security, software, quality and applicable management teams. Approvals are key for accountability.
  • Review the OWASP top 10 and be sure to frequently reference the documentation and prevention cheat sheets. High Level Requirements should incorporate some of the common issues that are in the OWASP top 10.
  • Additional considerations when reviewing requirements: What kinds of vulnerabilities are you looking to prevent? How will you measure whether your requirement is complete?

Design

  • Review Architecture Design. Understand the architecture design such as interactions between applications, middleware systems and databases to ensure multiple applications can work together.
  • Threat Modeling is a great way to understand the potential security concerns. The goal of threat modeling is to “think like a hacker” to prevent security events post software release. Some examples of input into the threat model can be:
    • Client (HTML, Javascript) and Server Side Design (such as hardening)
    • Authentication (Such as IdP)
    • HTTP Requests/Responses
    • Database (Such as conceptual, logical and physical design review)
    • Entry Points/Exit Points (such as interfaces)
  • Web Application Firewall Considerations (WAF)
    • Using a WAF can work to mitigate some common threats, such as injection, DDoS, whitelisting/blacklisting foreign countries, security header/cookie rules. A WAF should not be the only defense, but a layer that can significantly increase protection.

Database Considerations for AppSec Design

The database is your crown jewel; be sure to consider the security of your website data. Some examples are below

  • Database Protection
    • Segregation of webserver and database server in case of a security event – both servers will not be tampered
    • Encrypting communications, for more details, see Cryptography
    • Stored procedures (for non dynamic) as a layer (not standalone)
    • Ensure that SQL User Defined code is not able to gain unauthorized access in case of compromise.
    • For more ways to address common threats see Application Threats.
    • Hardening Server permissions in case of a Remote Code Execution (RCE) vulnerability.

Development

  • Code Reviews
    • The more complex source code can get, the more it should be documented and thoroughly reviewed. Unfortunately, its common for a single developer to unintentionally create bugs, make the code difficult to understand or intentionally inject malicious data into it to use later (such as a backdoor).
  • Static App Security Testing (SAST)
    • Continuous SAST monitoring can help mitigate issues early. SAST should not be a cure-all for security bugs but it can help to understand and fix issues early on. However, keep in mind the high false-positive rate and cost association that can occur with SAST tools.
  • SCA Tools
    • Monitor Open Source vulnerabilities with an SCA tool. SCA software enables users to analyze and manage the open-source elements of their applications. However, updating open source components can break the site, be sure to test.

AppSec Testing

  • Test Early, Test Often
    • Security professionals frequently mention to ensure tests are being performed as often as possible during the design phase (nightly, weekly, monthly).
    • Applications that are live should also be frequently tested and depending on the data stored (PII), a 6 month to 12 month full penetration test should be completed. White box (pentester has full knowledge of the application) is the preferred method.
    • Anytime the application is going through a major update, it is possible to introduce a vulnerability, therefore, there should be a penetration test.

Common Threats

  1. Common Application Threats & How to Address
  2. Brute Forcing
  3. Blind XSS Testing

Further Reading

  1. Threat Modeling
  2. Lessons Learned in AppSec
  3. Sample Pentest Rules of Engagement (RoE)
  4. Cryptography
  5. Brute Forcing

About Me

About