Protect Your Applications with a Secure SDLC

Chad Bairnsfather, Director of Information Security, EnvisionRxOptions

Chad Bairnsfather, Director of Information Security, EnvisionRxOptions

Security of web applications is an essential part of any enterprise security program. Web applications offer clients and customers a convenient way to access their information and pay for services. Unfortunately, a company’s web presence is also a prime target for hackers who thrive from the financial benefit of stealing your customer’s personal data or credit card information. Hacking of web applications is one of the most common attack vectors for data breaches and the negative impacts of a successful breach can be severe in both financial and reputational terms. How can organizations defend against this persistent threat? The answer lies within the people, process, and technology in your software development lifecycle (SDLC).

Investing in development and security staff are critical for a secure SDLC. Provide developers with access to ongoing secure coding training. Content should focus on avoiding vulnerabilities which are common causes of data breaches and should include the Open Web Application Security Project’s (OWASP) “Top Ten” list. Security staff must be expertly trained on the latest hacking techniques and the tools used to identify vulnerabilities.   Finally, focus on hiring security staff with a strong development background. This will foster an environment of teamwork through collaboration and clear communications and allow for a more seamless integration of security in all phases of development.

"Your web applications are a primary target for hackers looking to steal confidential information from your customers or clients.  Your best defense is a layered approach which leverages your people, process, and latest technology"

A strong process for a secure SDLC is fundamental, unfortunately, this is where many organizations falter. On the surface, this seems like a no-brainer - SDLC is already a process…adding security to this should be simple!!  In reality, this is quite difficult without setting proper expectations and standards. First, and probably most important, clearly define security roles and responsibilities. A secure SDLC requires developers, application security engineers, and project/delivery managers working together towards a common goal – the release of secure technology. Set the proper expectations through security policies which define when and where application security activities occur and identify the employees who participate. Vulnerability remediation timelines should be clearly defined based on severity. And finally, create a repeatable procedure which incorporates security in all phases. A well-defined procedure will improve employee onboarding and training and ensure staff are complying with your policy.  Project and delivery managers will support (and appreciate) these policies and procedures by incorporating them in development of project plans.

Rely on published standards whenever possible. OWASP provides a great resource– the Application Security Verification Standard (ASVS).  The ASVS is a reference for implementation of security controls within web applications and the creation of security testing plans. There are three verification levels within ASVS. Level 1 covers all software and Level 2 is appropriate for applications which process confidential information such as healthcare data and credit card payments. Level 3 is reserved for critical installations such as military and community safety. If you outsource the development and hosting of web applications, ASVS can be a great measuring stick to ensure they are providing the best possible security for your clients and customers.

Design phases of application development should include threat modeling exercises where development and security staff build a secure design through the establishment of security or compliance requirements. You will need your architectural and data flow diagrams for this exercise. OWASP has good reference material for this as well.  Developers should scan their source code for vulnerabilities throughout the development phase and review scan results and remediation with security staff. These are all “shift left” approaches which can avoid software flaws which can be costly or sometimes impossible to remediate in later phases of a project. Manual security testing should be done by qualified security staff prior to application release. This type of penetration testing can detect the most common vulnerabilities but also logic flaws which are difficult to detect with automated tools. Use lower environments which mimic production for these tests. The type of release should dictate the testing scope.  New applications require a full range of testing, but modifications will have a limited scope. Be flexible here to avoid security bottlenecks.  Introduce automation by integrating security scanning tools within the software build process. Your security software vendor can be a valuable resource here.  Time spent on building automation will result in a more consistent process with shorter delivery times.

Finally, remember to “secure the process”. Limit access rights by role and environment and follow change management best practices to protect the integrity of your delivery process. Maintain good separation between production and lower environments and use data masking whenever possible to limit access to confidential data.  Auditors will focus on the security and integrity of your process if you are assessed for compliance. 

Hackers continuously evolve their techniques to infiltrate web applications and you must defend with the latest technology and tools available. Static Application Security Testing (SAST) tools allow developers to scan source code during development phases (white-box testing). Scan results include severity levels and details of vulnerabilities discovered and will identify the best location for remediation. Be prepared to deal with false positives due to the difficultly in proving exploitability.  However, certain vulnerabilities, such as injection flaws, will be identified with high confidence. Continuous use of SAST will result in better code, secure coding standards, and avoid costly bug fixes. Dynamic Application Security Testing (DAST) tools analyze your application in a running state (black-box testing) and will find run-time or environmental vulnerabilities. SAST and DAST complement each other and can be configured to automatically execute and report findings to development or security staff.

Manual security testing or penetration testing require a comprehensive suite of tools. These use more advanced techniques including the intercept and tampering of requests between a browser and the application or tools designed for specific vulnerabilities such as clickjacking. SAST and DAST tools do not replace manual testing.  Each tool or testing approach is designed to identify specific types of vulnerabilities. 

Finally, you can’t rely exclusively on vulnerability management to fully secure your applications so protect them with a Web Application Firewall (WAF). These devices are designed specifically to identify and block the most common hacking attempts and operate at the application layer. Cloud WAF products are easy to deploy - you can be configured and running in minutes. They incorporate the latest threat intelligence so you can stay ahead of the hackers and require very few, if any, dedicated resources. Collectively, the WAF along with other tools and testing mentioned previously form a “defense-in-depth” for your web applications. 

As stated previously, your web applications are a primary target for hackers looking to steal confidential information from your customers or clients. Your best defense is a layered approach which leverages your people, process, and latest technology. This will greatly reduce your risk and help avoid the costly impacts of a web application breach.