CIS Control 16 Application Software Security

The way in which we interact with applications has changed dramatically over the years. Enterprises use applications in day-to-day operations to manage their most sensitive data and control access to system resources. Instead of traversing a labyrinth of networks and systems, attackers today see an opening to turn an organization’s application against it to bypass network security controls and compromise sensitive data.

Key Takeaways for Control 16

Implementation of Secure Software Development Framework (SSDF)

Using additional frameworks to harden security within software development lifecycles (SDLC) will increase the overall security for all development lifecycle phases. NIST SP 800-218 is a comprehensive framework that outlines recommended secure practices to establish during development lifecycles.

Safeguards for Control 16

16.1) Establish and Maintain a Secure Application Development Process

Description: Establish and maintain a secure application development process. In the process, address such items as secure application design standards, secure coding practices, developer training, vulnerability management, security of third-party code, and application security testing procedures. Review and update documentation annually or when significant enterprise changes occur, that could impact this safeguard.

Notes: The security function associated with this safeguard is Govern. We now have frameworks specifically tailored for securing software that can be used jointly with a company’s SDLC. NIST SP 800-218 is a Secure Software Development Framework (SSDF) that uses “a core set of high-level secure software development practices that be integrated into each SDLC implementation.”

16.2) Establish and Maintain a Process to Accept and Address Software Vulnerabilities

Description: Establish and maintain a process to accept and address reports of software vulnerabilities, including providing a means for external entities to report. The process includes such items as a vulnerability handling policy that identifies the reporting process, a responsible party for handling vulnerability reports, and a process for intake, assignment, remediation, and remediation testing.

As part of the process, a vulnerability tracking system that includes severity ratings and metrics for measuring timing for identification, analysis, and remediation of vulnerabilities should be used. Review and update documentation annually or when significant enterprise changes occur, that could impact this safeguard. Third-party application developers need to consider this an externally-facing policy that helps to set expectations for outside stakeholders.

Notes: The security function associated with this safeguard is Govern. Using a VM or Vulnerability management tool will scan hosts for software, ports, and policies and then generate a report on which applications are vulnerable, ports that are opened, and policies that have been enabled on scanned hosts.

16.3) Perform Root Cause Analysis on Security Vulnerabilities

Description: Perform root cause analysis on security vulnerabilities. When reviewing vulnerabilities, root cause analysis is the task of evaluating underlying issues that create vulnerabilities in code and allows development teams to move beyond just fixing individual vulnerabilities as they arise.

Notes: The security function associated with this safeguard is Protect. Performing root cause analysis is important because it allows those who are part of the software development cycle to identify the patterns in their development process that create vulnerabilities in the first place.

16.4) Establish and Manage an Inventory of Third-Party Software Components

Description: Establish and manage an updated inventory of third-party components used in development, often referred to as a “bill of materials,” as well as components slated for future use. This inventory includes any risks that each third-party component could pose. Evaluate the list at least monthly to identify any changes or updates to these components and validate that the component is still supported.

Notes: The security function associated with this safeguard is Identify. This safeguard pertains to inventory management of third-party software. Generally, you want to make sure that any updates to components that are used in any part of SDLC are still compliant with the overall policies your organization upholds and are within your scope.

16.5) Use Up-to-Date and Trusted Third-Party Software Components

Description: Use up-to-date and trusted third-party software components. When possible, choose established and proven frameworks and libraries that provide adequate security. Acquire these components from trusted sources or evaluate the software for vulnerabilities before use.

Notes: The security function associated with this safeguard is Protect. This safeguard is cut and dry. Make sure you have up-to-date software components from trusted third-party vendors.

16.6) Establish and Maintain a Severity Rating System and Process for Application Vulnerabilities

Description: Establish and maintain a severity rating system and process for application vulnerabilities that facilitate prioritizing the order in which discovered vulnerabilities are fixed. This process includes setting a minimum level of security acceptability for releasing code or applications. Severity ratings bring a systematic way of triaging vulnerabilities that improves risk management and helps ensure the most severe bugs are fixed first. Review and update the system and process annually.

Notes: The security function associated with this safeguard is Govern. Introducing a rating system will help your team understand which vulnerabilities have the greatest to least impact.

16.7) Use Standard Hardening Configuration Templates for Application Infrastructure

Description: Use standard, industry-recommended hardening configuration templates for application infrastructure components. This includes underlying servers, databases, and web servers and applies to cloud containers, Platform as a Service (PaaS) components and SaaS components. Do not allow in-house developed software to weaken configuration hardening.

Notes: The security function associated with this safeguard is Protect. Default configurations of applications, databases, web servers, and cloud containers are not designed with security as their main focus. These components will need to be modified once initialized with the security policies set forth in the SSDF.

16.8) Separate Production and Non-Production Systems

Description: Maintain separate environments for production and non-production systems.

Notes: The security function associated with this safeguard is Protect. Always have separate production and non-production systems.

16.9) Train Developers in Application Security Concepts and Secure Coding

Description: Ensure that all software development personnel receive training in writing secure code for their specific development environment and responsibilities. Training can include general security principles and application security standard practices. Conduct training at least annually and design in a way that promotes security within the development team and builds a culture of security among the developers.

Notes: The security function associated with this safeguard is Protect. Secure coding practices should be incorporated into all lifestyle stages during application development. There are different standards that may fit into your organization’s SDLC; for example, following the OWASP secure coding practices checklist will cover the following:

Input Validation
Output Encoding
Authentication
Session Management
Access Control
Cryptographic Practices
Error Handling and Logging
Data Protection
Communication Security
System Configuration
Database Security
File Management
Memory Management

16.10) Apply Secure Design Principles in Application Architectures

Description: Apply secure design principles in application architectures. Secure design principles include the concept of least privilege and enforcing mediation to validate every operation that the user makes, promoting the concept of “never trust user input.” Examples include ensuring that explicit error checking is performed and documented for all input, including for size, data type, and acceptable ranges or formats. A secure design also means minimizing the surface of the application infrastructure attack, such as turning off unprotected ports and services, removing unnecessary programs and files, and renaming or removing default accounts.

Notes: The security function associated with this safeguard is Protect. OWASP has a good framework for security architecture that include security principles such as: defense in depth, securing the weakest link, use of secure defaults, simplicity in design of security functionality, secure failure, running with least privilege, etc.. The model has 3 maturity levels with increases in sophistication as the maturity level rises.

16.11) Leverage Vetted Modules or Services for Application Security Components

Description: Leverage vetted modules or services for application security components, such as identity management, encryption, and auditing and logging. Using platform features in critical security functions will reduce developers’ workload and minimize the likelihood of design or implementation errors. Modern operating systems provide effective mechanisms for identification, authentication, and authorization and make those mechanisms available to applications. Use only standardized, currently accepted, and extensively reviewed encryption algorithms. Operating systems also provide mechanisms to create and maintain secure audit logs.

Notes: The security function associated with this safeguard is Identify. “Work smarter, not harder” rings true for this safeguard. Modern operating systems have built-in modules and services that can be leveraged by the applications your organization chooses to develop.

16.12) Implement Code-Level Security Checks

Description: Apply static and dynamic analysis tools within the application life cycle to verify that secure coding practices are being followed.

Notes: The security function associated with this safeguard is Protect. Monitor and document stages of the application lifecycle and make sure that secure coding practices are being followed throughout.

16.13) Conduct Application Penetration Testing

Description: Conduct application penetration testing. For critical applications, authenticated penetration testing is better suited to finding business logic vulnerabilities than code scanning and automated security testing. Penetration testing relies on the skill of the tester to manually manipulate an application as an authenticated and unauthenticated user.

Notes: The security function associated with this safeguard is Detect. During this safeguard, rigorous testing is conducted. OWASP has a penetration testing execution standard (PTES) that is defined in 7 phases:

Pre-engagement Interactions
Intelligence Gathering
Threat Molding
Vulnerability Analysis
Exploitation
Post Exploitation
Reporting

16.14) Conduct Threat Modeling

Description: Conduct threat modeling. Threat modeling is the process of identifying and addressing application security design flaws within a design before code is created. It is conducted through specially trained individuals who evaluate the application design and gauge security risks for each entry point and access level. The goal is to map out the application, architecture, and infrastructure in a structured way to understand its weaknesses.

Notes: The security function associated with this safeguard is Protect. Understanding weaknesses in the application architecture and infrastructure is the primary objective of threat modeling. Through the penetration testing safeguard of 16.13, OWSAP goes into detail on the overview and importance of threat modeling and why it is critical for both testers as well as the organization.

Read more about the 18 CIS Controls here:

CIS Control 1: Inventory and Control of Enterprise Assets

CIS Control 2: Inventory and Control of Software Assets

CIS Control 3: Data Protection

CIS Control 4: Secure Configuration of Enterprise Assets and Software

CIS Control 5: Account Management

CIS Control 6: Access Control Management

CIS Control 7: Continuous Vulnerability Management

CIS Control 8: Audit Log Management

CIS Control 9: Email and Web Browser Protections

CIS Control 10: Malware Defenses

CIS Control 11: Data Recovery