RELEASE PHASE OF THE
SECURE SOFTWARE DEVELOPMENT LIFE CYCLE
THE RELEASE PHASE
OF THE SECURE SDLC
THE RELEASE PHASE
The release phase of the Software Development Life Cycle (SDLC) is traditionally associated with production, deployment, and post-production activities. Which generally include maintenance and support of the software that has been developed. In this phase, post-production tasks (after deployment) in traditional SDLC models do not greatly involve development engineers. Operations admins and security engineers typically complete most of thee functions, which may include software monitoring, security testing, incident response, etc. In the Secure Software Development Life Cycle (SSDLC), developers are responsible for completing additional security tasks, which - even in the post-production stage of the release phase - integrates security with development. Other factors associated with the release phase include:
• confirming that the software works as optimally in the production environment as it did in the development environment • obtaining feedback from end-users in order to make appropriate tweaks • conducting maintenance and support tasks • confirming that the software in production meets customer and user needs according to the initial requirements.
CONTINUOUS MONITORING
AND LOGGING OF THE SOFTWARE
STAY AHEAD OF CYBER-CRIMINALS
The release phase of the SDLC is composed of many maintenance tasks, and thus it is a continuous process. Security itself is a continuous process of testing, upgrading, patching, maintaining & remediation tasks to ensure that software continues to remain secure and available. That said, in the Secure SDLC engineers are responsible for additional tasks not typically associated with SDLC models of development, including adding application logging events for security purposes. The security-based software events that should be logged include:
• Login events (successes and failures) • Authorization events (successes and failures) • 4xx errors (client errors) • 5xx errors (server errors) • Database syntax errors • Access control exceptions • Validation errors • CSRF token validation errors
t is important to note that certain models and methodologies of software development, such as DevOps - which often seeks to incorporate security testing into various stages of the SDLC - integrates the various tasks associated with developers, QA testers, operations admins, and security engineers throughout the entire life cycle, and thus increases collaboration throughout software development.
It is important for developers, operations admins and security engineers to collaborate during the entire development process, including during the release and post-production phase, in order for all members of the software development team to be better equipped to mitigate high-level software failures which often occur due to a lack of collaboration and involvement from software engineers. In the release phase of the SSDLC development engineers are responsible for ensuring that critical application processes and events are logged, and consequently work closely with operations admins and security engineers.
USING MONITORING TOOLS TO WATCH FOR SECURITY EVENTS AND TRENDS FOR ATTACK SIGNATURES
USING MONITORING TOOLS
One of the most critical tasks that engineers need to accomplish in the SSDLC is to monitor applications and obtain metrics that can help to identify security threats. Data, such as metrics and attack signatures, can be correlated with certain logged events to help operations and security teams mitigate security threats before they become full data breaches. Monitoring tools, such as statsd, graphite, graphana, Splunk, and Loggly are used to gather and aggregate stats and data on security events. In addition to aggregating data and metrics, patterns & attack signatures should be visualized via real-time graphs to better understand the nature of threats to the application in the production environment. Measuring and building graphs is a key step in helping to mitigate future threats.
A simple chart or graph illustrating all successful login attempts versus failed login attempts, where a brute force attack against the login page would result in a massive spike in failed login attempts can successfully alert teams of an attack occurring in real time. Visualizing data & metrics is a powerful method of aiding teams in mitigating security threats. The proper utilization of security metrics is key to efficiently equipping engineering teams and admins with the information needed to mitigate security threats. To this end, metrics should be made transparent to the project team - and for the sake of educating all personnel, the entire organization - to ensure that all personnel are aware of the hostile production environment that the application has been deployed in.
CORRELATION BETWEEN THE LOGS AND THE TRAFFIC INFORMATION AVAILABLE
Establishing an efficient defensive front based on attacks (i.e. an attack-driven defense) allows for the implementation of a powerful system that combines event/log metrics and real-time traffic data, the correlation of which can be used to detect attacks as they happen in real-time based on the aforementioned attack signatures. With such an infrastructure in place, a feedback system can be incorporated allowing data to be fed back to engineering and admin teams. These teams can create additional security dashboards and sub-systems that permit incoming attacks to drive a variety of powerful defensive countermeasures. The utilization of a security dashboard based on security data is significant in that such a system can be used to identify additional attack signatures in real time, i.e. abnormal traffic volumes often associated with fuzzers, scanners, DoS programs, etc. Additionally, attack patterns and signatures can be used as grounds for modifying code in order to stop exploits from occurring, and can be used as a foundation for pre-empting future threats based on known vulnerabilities. In certain environments, such as a Secure DevOps environment, such modifications can be made in a matter of minutes in order to close security holes and mitigate software vulnerabilities.
MONITOR 3RD PARTY LIBRARIES
FOR EXTERNAL VULNERABILITIES
MONITOR 3rd PARTY LIBRARIES
In the software engineering industry, whether using SDKs (Software Development Kits) or Open Source code repositories, the use of third-party libraries is ubiquitous. In fact, 3rd party software may comprise up to 80 percent of an application. It is typical for open-source or vendor code - that makes up a large percentage of the code running in production - to contain vulnerabilities. It is important to monitor third-party code in order to protect your software from attacks due to a known vulnerability being present.
In fact, the risk associated with using software containing known vulnerabilities is number nine in the OWASP Top 10, which comprises 10 critical web application flaws and unsafe practices that can result in a data breach. The SSDLC process should include the use of continuous monitoring tools (e.g. OWASP Dependency Check) across the entire software supply chain to ensure that all code in use is vulnerability-free. Both automated scanners & manual penetration tests are needed to ensure that code is truly devoid of the OWASP Top 10 and CWE 25 vulnerabilities. Another key step in maintaining secure coding systems is the establishment of an internal, secure code repository that includes code libraries that have been thoroughly reviewed, scanned, and approved by security teams. When protocols are set in place to allow development engineers to utilize only approved libraries and versions it is more feasible for teams to monitor them for vulnerabilities and security holes. To ensure that this system is effective, all new versions and libraries should be scanned and approved by the security team before introducing them to the package repository. This robust system can help to ensure that only secure code is used in your software applications and that insecure code is not being deployed into the production environment.