The Case for Automating Security in the Development Process  

The scale and complexity of today’s computer systems and application development environments have come with an equally large and complex range of security threats. Add to the mix the increasingly accelerated development cycles and frequent software releases, and you have an ever-evolving production cycle of bugs, patches and vulnerabilities. Manual security processes are simply not enough to keep up with this emerging reality. In this article we take a look at how organizations are automating security in fast and agile development processes.

What is security automation?

A brief primer on security automation: the use of technology to automate analysis of security vulnerabilities and incident response in applications and systems. Automation is a vital tool in security orchestration that streamlines processes and integrates secure design early in the software development life cycle (SDLC). Automation is used for both detection and response and can provide a wealth of information that DevSecOps [From DevOps to DevSecOps: The Security Challenges of DevOps] teams can use to eliminate security gaps quickly and efficiently.

Best practices for implementation

Adding automation to your processes can be challenging, especially if you are not sure where to start. Here are some best practices to keep in mind when reviewing your current use of automation and start planning for the next stage.

Threat modeling

Threat modelingcan grant you a better understanding ofsecurity issue priority, weaknesses to specific threats or types of vulnerabilities, where dependencies lie, and where security measures are lacking. Although it cannotbe automated in the same way as testing, it can be used to inform testing protocols and the process reinforces making security considerations  during the development process.

In addition to components, you should consider potential environments and static as well as dynamic errors.  But keep in mind, modeling is only one step in the process and it shouldn’t be allowed to consume excessive amounts of time.

When modeling threats, it is important to find a balance between thoroughly analyzingeach aspectof an application and taking rain checksfor those components that are highly complex. Oncemodeling is done, it should be used to inform where automation is useful and when it mustbe used in addition to manual testing.

Communicate workflows and how to integrate automation

Automation is only helpful if your team members know how to respond to results and are willing to do so. Tools that may seem optimal for security can make workflows impossible for development and, on the flip side, integrations that simplify operations can create extra work for security. In most cases, communication is key to ensuring the success of DevSecOps.

When you communicate workflows clearly and use them to evaluate the benefits or drawbacks of possible automation functions, you ensure that all team members understand why a tool is important and how to use it efficiently. Likewise, careful selection of the automation features you implement will guarantee that the information they provide is being used and adding value instead of just being ignored.

Select tools carefully

When selecting which tools to use, you should first make sure they fit the requirements of your product.  Product-specific tools can be used for different projects or aspects of projects to maximize benefit. Tools that allow you to customize test parameters and policies, and those that are not language dependent will often provide greater value.

While many tools use vulnerability information listed in security databases, such as the Open Web Security Project’s (OWASP) list, it is important that the ones you select use this information in relation to an actual analysis of code or program environment rather than simply running blind checks. You will benefit the most when you select a variety of complementary tools and evaluate both their speed and accuracy. Some tool categories to consider:

• SAST—check applications statically through review of source code or binaries and point to vulnerabilities by line
• DAST—check applications and environments dynamically as a whole but can only alert to issues, not highlight where issues lie in code
• IAST—check sections of applications and environments dynamically and can point to vulnerabilities in source code
• RASP—provide active monitoring and response after product release

Security automation in the cloud

Software development is increasingly being done in cloud environments, either in the migration of systems or for cloud-native applications. These applications involve hundreds of interconnected microservices, span multiple environments, and are continually updated via the CI/CD pipeline by an array of team members. The complexity involved in developing in the cloud makes automation a requirement for maintaining security.

DevOps teams need to be able to monitor application and environment performance from a centralized place which can be accomplished through log aggregation tools or API calls. With multiple members contributing to a project, it is easy to add the wrong permissions to newly added data or applications or even miss setting access restrictions in the first place. Solutions that simplify permissions management or alert to access vulnerabilities can help teams catch these issues before they become a liability.  The security of sandbox environments, used for testing, should be continually monitored by these tools as well, since they are often set up with default credentials or even live data.

Using automation efficiently

The efficiency and effectiveness of the tools you choose rely on how you configure and implement them. Setting alert threshold policies to ensure issues are worked in order of priority rather than chronological occurrence will help you to ship a maximally secure product in your given timeframe.

When alerts do occur, they should provide correlated findings and system or application status so team members can immediately take action instead of having to manually research why the alert was generated. Standardizing response procedures for common or repetitive tasks will facilitate this action and reduce the specific expertise needed for each occurrence, increasing the number of teammates that can effectively resolve issues.

Automated processes should be scheduled to have the least impact on an agile work environment. If you’re running tasks with high processing requirements or that require downtime in the middle of your workday, you’re losing out on any time-saving benefits that automation can provide. Lastly, when introducing automation to your workflows, automate only a few functions at a time so if problems arise, you can easily find the incompatibility and your team doesn’t lose productivity trying to adapt to a mass of changes.

Wrap up

Automation is not a cure-all but it can be used to improve the collaborative abilities of your team and should be used as a complement to your manual processes. DevSecOps teams were created so security would no longer be an afterthought and they only work when teams use processes that fit the needs and abilities of all members. When used strategically, automation allows these teams to work effectively to speed up the integration of security and ensure that products are as secure as possible upon release.