AlgoBuzz Blog

Everything you ever wanted to know about security policy management, and much more.

Search
Generic filters
Exact matches only
Search in title
Search in content
Search in excerpt
Search in comments
Filter by Custom Post Type
Posts

Integrating DevSecOps with Continuous Integration: why and what you need to know

by

In previous blogs, we’ve discussed how building security into DevOps processes at an early stage helps organizations maximize the speed and agility of application development, while minimizing the risks of problems and outages when the applications go live.  Here, we will look at how security automation helps to speed up the practice of Continuous Integration (CI), which is a core element of DevOps.

The goals of CI are to find and address bugs quicker, and reduce the time it takes to validate and release new software updates. Throughout the CI process, there is a continuous cycle of automated testing.  A key part of this is connectivity testing – that is, ensuring the application being developed can connect to the databases, resources and services it needs in order to function properly, while remaining secure and compliant with policies and regulations.

If an application’s connectivity requirements are changed, for instance because the application has been migrated to the cloud, then the associated security policies need to be changed too:  and if these changes have to be done manually, it puts the brakes on the entire CI process.

However, organizations can make their CI practices more streamlined, agile and efficient by carefully considering the connectivity requirements of the applications they are developing as an integral part of the overall development cycle.

An excellent starting point for this is for development teams to start with an up-to-date repository of all the relevant connectivity flows, for each application they are working on. Then, by using a security policy management solution which automatically updates application connectivity records via API calls whenever new traffic flows are added (which I covered in detail in this blog), it’s possible to process a majority of connectivity changes automatically.

Let’s take a closer look at how this works.

If application connectivity doesn’t change

We begin by requiring that the connectivity requirements for each application are documented within the application code repository, as a machine-readable connectivity descriptor file. This connectivity descriptor is maintained by the developers as part of the code.  If the application code is modified, but its connectivity does not change, there is no risk of introducing a security or compliance issue.  All that’s needed is to test the connectivity, to ensure that traffic is still being allowed by the network filtering devices in the next stage of the lifecycle.  If this connectivity test is successful, then the application can be moved across to the next stage.

If application connectivity does change

However, if the application’s connectivity requirements do change, the developer will update the connectivity descriptor file with the new requirements.  This in turn should trigger an API call to the security policy management solution to update the relevant application’s connectivity record.  The policy management solution then calculates the new network connectivity path that the application requires, checks which security policies need to be updated, and validates that the new traffic flows are allowed.

If the changes in connectivity do not introduce security or compliance risks then the change can proceed with zero touch:  the policy management solution pushes the required updates directly on to the relevant firewalls, routers and cloud security groups to enable the new connectivity, and updates the application connectivity records accordingly. However, if application’s new connectivity requirements introduce risks of high enough severity, the change is not automatically allowed. Instead the security team then steps into conduct a security and compliance risk analysis of the changes before they are implemented. Importantly, the entire process is fully documented, providing a record and full audit trail of all connectivity changes.

With this approach, a high percentage of application connectivity changes during the CI cycle can be automatically processed, either because their underlying connectivity doesn’t change, or because the changes are already allowed by security policies and pre-approved. The bottom line is a more agile, automated application development and delivery cycle.

Subscribe to Blog

Receive notifications of new posts by email.