Defining the Baseline for Application Developers’ Security Knowledge
The blog posts that I’ve published over the past few weeks have explored the security skills gap and the training, resources, and processes required to address application security. In today’s article, let’s take a swing at defining the knowledge and skills our development staff needs in order to produce secure application software.
Recently, I was working with an education client and as we worked through defining the scope of the security-augmented developer course, we kept going back to the question “What security knowledge does a developer need to know when they come to work for you to be able to write secure code?”. I had never before sat down and produced a discrete list and that’s what we’ll do today. Because the responsibility for application security is shared by the developers, DevOps, and their management, today we’ll primarily look at the developer role, but refer to the others as needed.
For the purpose of this article (and the past two), the scope of “Application Security” is focused solely on the source code and the dependencies that are referenced therein. The topics of identity & access; data; network; infrastructure; and logging, auditing, & analysis are outside of this article’s discussion.
Here are a few items that must be implemented to secure in-house developed software:
- A well-defined Software Development Life Cycle (SDLC).
- OWASP T10 Trained developers and DevOps engineers.
- Developer’s integrated Development Environment (IDE) tools augmented with security plugins.
- Quality code processes
- Standardized Logging Practices.
Defining the Baseline
From the list above, let’s pull out the developer skills out of each.
Well-Defined Software Development Lifecycle (SDLC)
A SDLC includes a detailed plan for how to develop, alter, maintain, and deploy a software system. From a security perspective, a key objective is to ensure ONLY code that is required to meet the release’s requirements is added and deployed in a release. The necessary development knowledge that comes into play is knowledge of a SCM Branching / Merging Model / Workflow such as Gitflow.
A developer should know how to branch, commit, merge software into the organization’s SCM (e.g. git or subversion) so that features that are not part of a release get introduced into the release codebase. In an organization that uses GIT as it’s SCM, the use of GITFlow2 should be well understood by the development team members.
OWASP T10 Trained developers and DevOps engineers
The Open Web Application Security Project (OWASP) Top 101 (T10) covers the ten most critical software application’s security risks. While developers should understand all of the T10, in a modern enterprise software development organization where there are usually also SecOpsIT, DevOps, & Ops staff some of the OWASP T10 items will be the responsibility of the other groups.
For example regarding A2:2017 Broken Authentication, rarely would most development teams be implementing an Authentication system, that function is much more likely to be purchased as a third-party software package and installed, configured, & administered by SecOpsIT and/or Ops staff. This said, a developer should still understand A2:2017 Broken Authentication risk so that they don’t inadvertently expose a flaw through incorrect usage of a authentication package that allows an attacker to compromise passwords, keys, or session tokens.
The T10 risks that application developers should be generally most heavily focused on are:
- A1:2017 Injection
- A3:2017 Sensitive Data Exposure
- A5:2017 Broken Access Control
- A6:2017 Security Misconfiguration
- A7:2017 Cross-Site Scripting (XSS)
- A8:2017 Insecure Deserialization
- A10:2017 Insufficient Logging & Monitoring
With the following focused on only if the application accepts XML (A4) or there is no DevOps team:
- A2:2017 Broken Authentication – As discussed above, a developer typically needs only know how to appropriately use an authentication package, unless they are developing one.
- A4:2017 XML External Entities (XXE) — The use of XML as a data representation has been decreasing for a number of years. However, it is still used quite widely in legacy code, especially in financial/medical/insurance domains. If XML as a data transport is used within your organization and allows external entity references, then this risk should be a focus. BTW, this vulnerability was one of those exploited by the Equifax attackers.
- A9:2017 Using Components with Known Vulnerabilities — This should be addressed by both the developer using tooling in their IDE and the DevOps team implementing checks in the CI builds. Pro versions of Build Artifact Repository systems (Nexus & Artifactory) offer CVE checking on requested downloads and the ability to warn developers of issues during development.
Developers might consider using a security library such as OWASP’s Enterprise Security API 2 to secure their applications using the library’s validation, encoding/decoding, and other security features to mitigate security issues.
Developers (+D), security testers (+T), application managers (+A), and organization’s (+O) security managers should read their perspective appendixes at the end of the T10 document for excellent role-specific information.
Integrated Development Environment (IDE) Security Tooling
Virtually all software developers use an IDE to write their code. These tools such as Eclipse (OSS) and Intellij IDEA (Lic) can be expanded via plugins. The developer should know how to install and use the appropriate plugins for their IDE of choice.
The Find Security Bugs (find-sec-bugs) plugin4 provides security audits of Java web applications and Android applications. (Also works with Groovy and Scala projects) for the Eclipse and IntelliJ platforms and is very well supported.
Note: the FindBugs parent project is dead, SpotBugs5 is its successor. Find Security Bugs has been updated to work with SpotBugs. See the migration document.
Quality & Security code processes
Writing quality code is the first step to creating secure code. Code reviews including both manual and automated are critical to ensuring the quality and security of your code. Likewise, unit and integration testing ensures that your code performs and provides the required functionality and continues doing so over time.
For manual code reviews to be meaningful, they should cover both the style (coding convention) and the content of the code. The style is important because if differing styles are used across a codebase, then it will make maintenance and bug fixes more difficult. The content should be reviewed for efficiency, flexibility, security, and maintainability. OWASP provides a Java Security Practice 6 page to provide criteria to review the code. A developer should be able to describe the coding conventions and detect OWASP T10 risks in the code as well as any items described in the Java Security Practice.
Automated reviews should be implemented in the CI jobs by the DevOps team. Both CVE dependency checks and static code reviews should be implemented. The same Find Security Bug project provides the Maven & Gradle dependencies to perform the static review. OWASP provides an OWASP Dependency-Check tool 7 to check the application’s dependencies for CVE issues.
Unit and integration testing of functionality are a staple of quality software development environments. An application’s security should also be unit and integration tested. A developer should be able to test their code with cross-site scripting, injection, and other OWASP T10 tests.
Standardized Logging Practices
Application logging is so crucial to detecting security incidents, monitoring policy violations, and providing additional application-specific data for incident investigation. The OWASP Logging Cheat Sheet 8 provides an excellent guide for application logging . A developer should be able to to enumerate:
- Event data sources
- Which events to log
- Event attributes
- Data to exclude
In order to build quality and secure software, developers should:
- Know their roles within an SDLC and specifically understand the SCM workflow used by the organization (e.g. GitFlow).
- Understand in depth the OWASP T10, these are the ten most critical security risks. However the T10 is only a beginning, developers must establish and use repeatable security processes and standard security controls.
- Understand the importance to integrate security tools such as SpotBugs/FindSecBugs into their IDEs.
- Be able to lead and/or participate in code reviews, incorporating security concerns into their reviews.
- Be able to develop security context unit and integration tests
- Be able to enumerate the logging:
- Event data sources
- Which events to log
- Event attributes
- Data to exclude
- OWASP T10 Project: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
- OWASP Enterprise Security API: https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
- Gitflow Workflow: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
- Find Security Bugs: https://github.com/find-sec-bugs
- Spot Bugs: https://spotbugs.github.io/
- Java Security Practice: https://www.owasp.org/index.php/Java_leading_security_practice
- OWASP Dependency Check: https://www.owasp.org/index.php/OWASP_Dependency_Check
- OWASP Logging Cheat Sheet: https://www.owasp.org/index.php/Logging_Cheat_Sheet
*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.