Three Pillars to Build Security Into Your SDLC

In today’s technology environment, the issue is no longer if your business is vulnerable to cyber security threats or may someday be attacked; the issue is ‘When?’ and, ‘Will you be prepared?’ The widespread use of cloud computing, SaaS and smart devices leave businesses of all types and scales more vulnerable than ever to attacks on their information systems. A company's financial security, intellectual property and level of trust are at risk. Everything can be lost as the result of a successful attack.

Security can’t be an afterthought or adjunct task in the software development process. The legitimacy of the threat necessitates the need to tightly integrate security into the software development lifecycle (SDLC). Identifying security issues at the end of a development is too late.

When you incorporate security into your SDLC, you create applications that are secure by design, not by chance or circumstance.

In particular, security in continuous integration (CI) environments can be challenging. The goal of CI is to provide rapid feedback on disparate code changes, allowing developers to correct errors as soon as possible by identifying functional defects introduced into the larger code base. In this environment, integrated security testing is needed to provide developers a real-time threat assessment of all changes they’ve made, regardless of their operational success in the larger code base. Without integrated security testing, there’s a risk of re-engineering solutions multiple times to address security threats detected long after functional solutions are accepted. That wastes valuable time, money, energy and effort.

Following are three pillars to build security into a continuous integration development environment, creating applications capable of standing up to any security threat:

1. Leverage Interactive Application Security Testing (IAST)

IAST combines into a single solution the techniques and benefits of static and dynamic application security testing, increasing the overall accuracy of testing by running continuous, automated malicious traffic against applications under development, while monitoring the applications in runtime. IAST monitors information from inside the application under test, including runtime requests, data and control flows, libraries and connections to create a comprehensive testing environment simulating real-world attacks. This includes context awareness, allowing organizations to prioritize different risk threats, as opposed to prioritizing differing vulnerabilities without the ability to assess their impact on data in the event of an attack.

Unlike other test methodologies, IAST pinpoints real vulnerabilities with no false positives and gives immediate, focused code remediation. [LINK: http://www.marketwatch.com/story/interactive-application-security-testing-iast-named-by-gartner-analysts-in-top-10-technologies-for-information-security-in-2014-2014-07-01].

IAST is the future of security testing and should me a mainstay of SDLC environments.

2. Choose the Right Tool for the Job

There are a variety of tools available in the marketplace capable of providing utility in an integrated security SDLC environment. As with all choices, some solutions may prove inadequate or an overkill to the task at hand. A good motto to follow when evaluating testing environments is, “Just because you can, doesn’t mean you should.” In other words, security testing requires the right tool for the job at hand, not any tool that can serve a level of purpose.

Thoughtfully marry your security testing solution with the type of software, language, methodology and budget matching your environment. Select security tools capable of automated testing, purpose-built to integrate with the continually evolving code base inherent to the CI software development process.

The right tools are needed to create the level of testing required to assure security of the application under development. This isn’t an area you want to skimp on or misalign.

3. Involve Your Security Analyst

Although security is everyone’s responsibility, it’s wise to have someone responsible to continuously oversee all security testing efforts. Security analysts should be used to verify and coordinate all test results, investigate suspicions of false positives and negatives, explain security defects to developers and educate quality assurance staff on ways to detect business logic defects.

Having a security analyst on your team throughout the SDLC process raises the importance of application security and provides a voice on the team that won’t compromise security for operational or functional abilities. As security shouldn’t be an afterthought in development, it shouldn’t be an afterthought in responsibility.

Conclusion

Cyber attacks are a real and growing threat to business and individuals that we need to prepare to quickly detect and thwart. One of the best defenses against a cyber attack is to develop applications within an integrated security environment. In this environment, security is part of the software development process, as opposed to a parallel or after-action activity. 

A big part of preparedness is selecting the right methodology. IAST is the latest approach to application security testing that provides continuous, real-time feedback on simulated cyber attacks. This is especially valuable in CI environments where disparate code changes are rapidly introduced for testing within a larger code set.

Beyond the testing environment, the tools and testing configurations you employ need to match your unique situation. While more than one testing solution may provide a level of functionality, security is too important an issue to use anything less than ideal support systems.

Last, but not least, security analysts should be an integral part of your development team. Their uncompromising voice for security underscores their importance in the development process and keeps security a top priority within your team.

The safe assumption is that your business will be under attack at some point in the future and catastrophic financial, intellectual property and customer losses may be the result of not being properly prepared. The issue developers need to address is how well they are prepared to withstand an attack, and that begins with measures taken in the software development process.