4 key elements for proactive application security
Patching vulnerabilities AFTER the exploit is only one piece of the picture. Here are four tips from George Viegas to build in a proactive software security posture.
We most often hear of the security breaches due to cross site scripting and SQL injection attacks, after the related vulnerabilities have been successfully exploited. But what could we do to prevent such attacks occurring in the first place?
A comprehensive security program and team will not only provide reactive measure to incidents and exploits, but also actively work with the in-house information systems teams to build in a proactive software security posture. An effective application security program to proactively build secure code for information systems and software, relies most often on 2 types of automated security testing: static security scan testing and dynamic security scan testing.
A static scan is typically run during the code development cycle where the static code is scanned and through threat modeling and analysis, security flaws are uncovered. A dynamic scan is a scan of the actual code in a working environment and finds vulnerabilities while the code is “in motion” or working, hence the term dynamic. There is also a third type of test called a manual penetration test which involves human interaction through white hat analysis. An effective application security program leverages all three type of security scan testing, with static security and Dynamic security scanning deeply embedded as part of the application development lifecycle and manual penetration testing used sparingly and where needed.
An effective automated code scanning strategy must be as seamless as possible to the IT Development team. The key success factor to an effective automated security program is to require the least amount of additional work from the IT development teams. There is an inverse relationship to the in-cycle work and the success of the proactive security program. The more out of cycle work required the less the adoption and the success rate of the security code scanning program. Code scanning that is out of cycle to the IT application development process will always take time away from the development schedule and will be seen as an additional and unwelcome task. There is an extra effort required to schedule and track the process and maintain status.
The main obstacles for successful adoption of a security code scanning program are:
Manual scan effort
Code scanning that requires manual effort to upload the code, whether by API or through web portal, requires additional development time and effort. In some cases, special compile instructions are required and a special build needed for the scan to work.
Manual process
Code scanning that is out of cycle of the development process needs a process to be established for timelines to scan and duration before rescan. Dedicated resources need to manage the program to ensure that reminders are set and scans are completed on due dates.
Code coverage
An old adage in testing is that you cannot test what you don’t know. Out of cycle testing that requires a developer to upload code is also dependent on the developer to upload the correct code for static code scanning. Verification that all the libraries and dependent code is uploaded is a near impossible task for the security team maintaining the program. A single file could be uploaded for static scanning and the resultant product scan would show as passed for that product on a dashboard, unless someone manually verified the file uploaded. For a large IS program this is very time consuming process to verify across hundreds of security scans An effective application static and dynamic code scanning program has four key elements:
- On premise
- Continuously scanning
- Tightly integrated with the development build cycle
- Tightly integrated with the defect tracking system
1. On premise
A scanning program that is on premise and linked to the source control system now removes the dependency for a developer to take the time to find the code, do special compiles and upload the code. Instead, the right location of the code is selected in the source control tree and regular scanning is setup for all the child files. An on premise Dynamic scanning solution also makes it easier for dynamic scanning since no firewall rule changes are required for external tools from the scan test provider to access the test website.
2. Continuous scanning
On premise systems can be setup for continuous scanning which will not require manual intervention to upload the code. On premise systems can also be configured to scan continuously or periodically and because of the on premise setup, can scan far more frequently that a manually uploaded, manually configured scan.
3. Tightly integrated with the development build cycle
A scanning program tightly integrated with the source control and build system allows for code scanning to leverage many source control and build system features. For example advanced development teams using continuous build integration from their source control, can configure the build system to pass certain test gates before a developer’s build can be integrated or checked in to the main code base. Code security scanning tests can be setup to be one of these test gates much like Performance tests or unit tests.
4. Tightly integrated with the defect tracking system
Most modern source control and build systems are also tightly integrated with the defect tracking system such that a software defect can be tied to a particular version of code checked in which in turn can be tied to a particular system build. A code scanning program that can automatically create defects within the existing defect management system will allow for less out of cycle time and will seamlessly integrate and absorb security defects into the team defect backlog.
Effective proactive security requires code scanning to be as unobtrusive into the application development cycle as possible. The more the security scan can work like an existing development process, the better the chance of successful adoption and continuous use by the development teams.