- ITDM 2025 전망 | “비전을 품은 기술 투자, 모두가 주춤한 시기에 진가 발휘할 것” 컬리 박성철 본부장
- 최형광 칼럼 | 2025 CES @혁신기술 리터러시
- The Model Context Protocol: Simplifying Building AI apps with Anthropic Claude Desktop and Docker | Docker
- This robot vacuum and mop performs as well as some flagship models - but at half the price
- Finally, a ThinkPad model that checks all the boxes for me as a working professional
CIS Control 16 Application Software Security | The State of Security
The way in which we interact with applications has changed dramatically over 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 organizations applications against it to bypass network security controls and compromise sensitive data.
Key Take Ways 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.
Safe Guards for Control 16
- 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 Protect. 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.”
- 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 is to include such items as: a vulnerability handling policy that identifies reporting process, responsible party for handling vulnerability reports, and a process for intake, assignment, remediation, and remediation testing. As part of the process, use a vulnerability tracking system that includes severity ratings, and metrics for measuring timing for identification, analysis, and remediation of vulnerabilities. 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 Protect. 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.
- 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 of who are part of the software development cycle to identify the patterns in their development process that create vulnerabilities in the first place.
- 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 is to include 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 Protect. This safeguard is pertaining 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 to the overall policies your organization upholds, and in your range of scope.
- 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.
- 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 facilitates 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 Protect. Introducing a rating system will help your team understand which vulnerabilities have the greatest to least impact.
- 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 its main focus. These components will need to be modified once initialized with the security policies set forth in the SSDF.
- 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.
- 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 to promote security within the development team, and build 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 life style stages during application development. There are different standards that may fit into your organizations SDLC, for example following OWASP secure coding practices checklist will cover:
- 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
- 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. Secure design also means minimizing the application infrastructure attack surface, 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.
- 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 Protect. “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.
- 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.
- 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 Protect. 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
- 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 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 12: Network Infrastructure Management
CIS Control 13: Network Monitoring and Defense
CIS Control 14: Security Awareness and Skill Training
CIS Control 15 Service Provider Management
CIS Control 16 Application Software Security