American Cyber Security Management

Secure and certify all your data and processes

Addressing Application Security

By

Introduction

When we discuss application security, we focus on the application itself, not the networks or infrastructure that it will be operating within, just the products of the development team, comprised of the development manager, developers, DevOps engineers, and testers. The code that the developers write is but a slowly diminishing piece of the puzzle, increasingly developers are composing applications from a variety of generated code, frameworks, and libraries; any of which may be vectors for attack. How do we go about addressing the security of our developed applications?

OWASP to the rescue

You may be asking:

  • How do we identify the application vulnerabilities?
  • What risks do they pose?
  • Where are they found in our code and how do we identify them?
  • How do we prevent them?

Fortunately, we have the Organization for Web Application Security Project (OWASP), a 501(c)(3) worldwide not-for-profit charitable organization is focused on improving the security of software. They document the OWASP Top 10 Most Critical Web Application Security Risks which represents a broad consensus about the most critical security risks to web applications. Their project members include a variety of security experts from around the world who have shared their expertise to produce the documented list. 1 OWASP reviews and revises its Top Ten (T10) list every four years, with the most up-to-date version at the time of this writing being the 2017 RC2 2 (i.e. release candidate 2). The T10 list categorizes, ranks, and provides information for about the vulnerabilities, including how to detect and prevent them.

OWASP provides a broad range of resources for addressing all aspects of application security, many of which are referenced in the appendix of the T10 document. Of particular interest to me is the OWASP Testing Guide 3. While many of today’s software developers are familiar with Test Driven Development for functionality, the thought of adding tests to provide coverage for SECURITY vulnerabilities may seem foreign. Developers and DevOps engineers must learn the OWASP T10 and understand the tools they need to address validation, encoding/decoding, testing, and other techniques for addressing the vulnerabilities.

Steps to secure your application software

Creating secured application code requires:

  • A defined Software Development Life Cycle (SDLC) — it is crucial that you know what changes are being introduced into your applications, that they are reviewed, and scanned for security vulnerabilities; these tasks must be part of the development culture and explicitly part of your SDLC.
  • Trained developers and engineers — Assess your development team’s software security skills and make sure that they have periodic security training. The threats are changing all of the time, your teams much change with them. OWASP is a great starting point.
  • Developer’s integrated Development Environment (IDE) tools augmented with security plugins — The earlier in the development process that security vulnerabilities can be detected, the less it costs to remediate those errors. The development teams should be using static code analysis plugins that can detect OWASP T10 vulnerabilities as they are entered into an Integrated Development Environment (IDE).
  • Quality code processes including a security context (code reviews, both manual & automated static code analysis) — The best way to find issues of all types, but especially security is to go directly to the source code. In fact, there are some vulnerabilities that will be missed by automated scans.
  • Standardize Logging Practices — Developers should have a guide to adding the needed logging statements to code to assist in the detection of attempts or breaches and providing the required information.
  • Expand application testing to include security coverage — Just as your developers write tests for functionality, they should also be expected and assessed for developing security tests. Code reviews should include ensuring that both functionality and security tests are sufficient and accurate.
  • Continuous Integration (CI) tasks static code analysis and dependency CVE analysis — CI servers’ build tasks should be configured to both perform static security code analysis (e.g.findsecbugs) and perform CVE analysis (e.g. OWASP Dependency-Check 4 ) on the dependencies of the software. If these controls had been in place, Equifax would have been alerted to the root cause issue that leads to their breach. If vulnerabilities are detected, the build should be failed. The development team management should be able to understand the generated report data.
  • Development team managers trained to understand the need and purpose of the security & SLDC controls and who have the support from their management to ensure that they are utilized.

References

  1. OWASP Top Ten Project: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
  2. OWASP Top 10 2017 RC2 – PDF: https://www.owasp.org/images/b/b0/OWASP_Top_10_2017_RC2_Final.pdf
  3. OWASP Testing Guide Introduction: https://www.owasp.org/index.php/Testing_Guide_Introduction#Developers.27_Security_
  4. OWASP Dependency Check: https://www.owasp.org/index.php/OWASP_Dependency_Check

*American Cyber Security Management (AmericanCSM.com) is focused on reducing your risk of data misuse. We do this through our Security, Privacy and DevOps offerings, delivered by seasoned experts. We can ensure your Agile delivery processes are secured and efficient, while maximizing your investments.