This whitepaper presents a process of implementing a ‘Connectivity as Code’ approach that weaves network connectivity and security into the DevOps process.
Introduction
This technical whitepaper presents and discusses the concept of “Connectivity as Code”, a concept complementary to “Infrastructure as Code” (IaC). This paper explains how Connectivity as Code can be incorporated into the DevOps lifecycle for a more agile application delivery. It also describes why empowering the developer to define an application’s connectivity requirements, bridges the gap between developers and network security, and helps to automate the application delivery process end-to-end. The solution presented in this whitepaper seamlessly weaves network connectivity into the DevOps methodology while ensuring continuous compliance, so that automation does not compromise security.
This paper also shows that Connectivity as Code supports not only automation and agility in the application delivery process, but also bridges the gap between application developers and network security teams on an ongoing basis, even after the application is deployed in production. This is achieved by creating an abstraction layer that translates between the two worlds, giving application developers more control over their applications, while helping network security understand the business impact of their day-to-day tasks, and thus ensure business continuity.
The detailed technical descriptions in this document include real-life examples that can be used as is or can serve as a blueprint for implementing a DevOps process with baked-in automated network connectivity provisioning.
The network security and DevOps problem
DevOps is all about agility – fast, short delivery cycles – and automation. Enabled by recent technologies such as virtualization, cloud and SDN, the task of spinning up new servers, provisioning storage in a public or private cloud or even spinning up whole environments, now takes minutes or even seconds. Yet opening a port from a new server to a remote location on an internal or external network can take weeks, and there’s limited visibility into the process.
In a typical DevOps scenario, developers create a CI/CD pipeline that includes compiling and building processes, running unit tests, configuring test environments and running integration tests, and even pushing the new application into production – all completely automatically. But if the new application or version requires new network connectivity, the application developer needs to manually open a change request (out of band, e.g., using ServiceNow or other ITSM system), and then wait for approvals and implementation of the new connectivity flow before proceeding with the DevOps flow. This brings the entire process to a standstill, and defeats the agility desired in the application delivery process.
Moreover, the developer is usually required to provide information about firewalls, zones, subnets, and other information related to the underlying network infrastructure in these change requests – information that is not always known or clear to the application developer. At the same time, the application requirements and context are not always understood by the network security team assigned to implement the changes. This, in turn, results in back-and-forth exchanges between the developer and network security, making the entire process extremely long, error-prone, inefficient and frustrating to both teams.
The solution: Connectivity as Code
Connectivity as Code closes this gap in the DevOps process. Connectivity as Code enables the application developer to describe the application connectivity requirements in a simple file, that lists the logical flows that represent these requirements. No additional details regarding the network infrastructure, firewalls, etc., are required. Once this list is created, a new phase in the DevOps process, called the Connectivity phase (detailed below), automatically takes over, with no further involvement required from the application developer. And whenever a new version of the application is developed, the developer updates the connectivity requirements list, and the connectivity phase ensures that the new flows are provisioned.
The “Connectivity as Code” file
The Connectivity as Code file is a simple, machine-readable text file (e.g., structured as a JSON or YAML file), that represents the logical connectivity requirements of the application. It is presented as a list of abstract flows that typically include:
- Source (the consumer, who initiates the connection)
- Destination (the provider, who accepts the connection)
- Service
- Comments or additional information can be added as well
There is no need to know where the servers are located, what the underlying network topology is (e.g., whether there is a firewall between them, cloud security controls, etc.), or even their IP addresses or subnets. There is also no need to know whether connectivity is already available (e.g., because it is also required by other applications).
The file should include all connectivity requirements – between different components within the application (e.g., app server to DB), as well as external connections to/from the application (e.g., external clients connecting to the app’s web server). It should also include the connectivity requirements for the various application environments – dev, test, production, etc. – to ensure that connectivity is provisioned to allow both a smooth development and testing process, and to ensure that there are no surprises when eventually deploying the application in the production environment.
Once this file is created by the application developer, it is entered into the repository of files required for building the application, just like the code itself and any other supporting configuration files. The application’s version control should also include this connectivity file for backup, easy rollback, application versioning and branching, etc.
See the sample “Connectivity as Code” JSON file at the end of this article, describing the connectivity requirements of an application.
The DevOps CI/CD pipeline
In order to automatically provision connectivity based on the Connectivity as Code file described above, a new phase is added to the CI/CD pipeline: The Connectivity phase.
The connectivity phase is where the actual connectivity provisioning and validation takes place. This phase leverages AlgoSec’s network security policy management capabilities to automate network connectivity provisioning as part of the DevOps process (to “DevOpsify”), just like any other configuration or provisioning step in the DevOps pipeline.
In the Connectivity phase the AlgoSec solution proceeds according to the following logic:
- Read the Connectivity as Code file.
- Check whether the connectivity requirements have changed (new application, new flows required, some flows no longer needed, etc.).
If no changes were made, AlgoSec verifies that the required connectivity remains in place, and that the application will work correctly. If that is the case, nothing needs to be done – the connectivity phase is completed successfully and the CI/CD flow continues. This provides the application developer with the assurance that the necessary connectivity is in place and connectivity-related failures are not anticipated when moving into production.
Note that this process relies on AlgoSec’s traffic simulation and network analysis capabilities, which find the firewalls/access-lists/filters/security groups that are in the traffic path, and detect whether their security policy currently allows the requested connectivity or not.
If the connectivity requirements have changed, AlgoSec’s business application connectivity repository (AlgoSec BusinessFlow) is automatically updated with the new connectivity requirements for this application. This information is used both for provisioning the required connectivity now, and is also retained for future reference, to ensure that the application’s connectivity remains intact in the event of future network architecture changes, application or server migrations, or when additional filtering, policy cleanup, etc.
If one or more of the required flows is currently blocked, AlgoSec automatically triggers a security policy change request process. Through this process AlgoSec first verifies that the new flows comply with the organization’s pre-approved security policy, as well as with security best practices and industry regulations. AlgoSec then designs and implements the required changes directly on the various security devices on the network, automatically and within minutes. If, however, a change request is non-compliant, it is escalated for approval and, once approved, it is implemented automatically, thereby saving the developer the need to manually open an out-of-band change request.
This change management step is performed by AlgoSec FireFlow, AlgoSec’s change automation product, leveraging a zero-touch change workflow.
This concludes the connectivity phase, and the DevOps process now continues on to the next phase.
Let’s review a short example of this process:
Jane develops a new version of application Foo. This version includes a new spell-checking feature that requires connectivity to the SpellChecker service on the internet.
- Jane updates the connectivity file and adds the following flow:
“Foo AppServer” -> “SpellChecker Server” with service https.
Jane knows that by documenting the application’s connectivity requirements, she not only ensures a smooth deployment of the new version (even if some security policy changes are required), but that her application’s connectivity will also be “future proof” (e.g., when a new firewall is introduced, or her application server is migrated to the public cloud). - Jane commits her changes and triggers the CI/CD process. After the code is compiled and packaged and all tests are successfully completed, the process continues to the connectivity phase.
- The new connectivity requirement is detected, and the Foo application in AlgoSec BusinessFlow is automatically updated with this new flow.
- BusinessFlow detects that this flow is currently blocked, and a change request is automatically triggered in AlgoSec FireFlow.
- AlgoSec FireFlow detects that the perimeter Palo Alto Networks firewall is blocking the traffic.
- AlgoSec FireFlow runs a risk check against the pre-approved policy created by information security, and detects that this traffic is approved.
- AlgoSec FireFlow finds a rule in the perimeter firewall’s policy that allows https traffic to several other internet services, and adds the SpellChecker server as a destination to that rule. It pushes the change to Palo Alto Networks Panorama and then commits and installs the policy on the perimeter firewall.
- The connectivity phase is complete, and the process continues until the application is successfully deployed in production.
A couple of weeks later, Jane creates yet another version of Foo, but this time no new connectivity requirements are introduced.
- When Jane commits her changes, the process runs again, and this time the connectivity phase quickly detects that no changes are required.
- Connectivity is automatically verified by running a traffic simulation query to ensure that all relevant policies are configured correctly, and the process continues on to another successful deployment into production.
How it works
In order to implement the above solution, several key capabilities of the AlgoSec Security Policy Management Solution are used. In addition, AlgoSec provides several tools to easily integrate its solution with common configuration management and DevOps CI/CD solutions, as well as into home-grown automation solutions and scripts.
The following sections describe the key AlgoSec capabilities that are utilized during the connectivity phase.
Network model and simulation
As part of its core technology, AlgoSec creates a network topology model that represents the entire organizational network. This model covers on-premise, private cloud and public cloud environments, and supports all the leading network security solutions, including firewalls, routers, load balancers and cloud security controls.
The network map model is then leveraged to perform traffic simulation queries, i.e., given a specific flow, what exact path will it traverse across the network, and whether any security devices along the path currently block the traffic.
This capability provides the basis for AlgoSec’s ability to translate intent-based, abstract connectivity flows, into the technical requirements and specific network devices and policies in the underlying network security infrastructure. It is also used to design any changes required to allow missing connectivity.
Zero-touch automated change workflow
When the connectivity phase detects new connectivity requirements, a change request is automatically triggered in AlgoSec’s automated change workflow solution, AlgoSec FireFlow.
The new change request goes through several key steps:
1. Initial Plan – finding the relevant firewalls and security devices that require a change.
2. Risk Check – verifying the new connectivity flow adheres to the pre-approved organizational security policy, as well as regulatory compliance requirements.
3. Work Order – designing the exact change that needs to be made on each security device, in the fashion most optimal for the specific vendor device and policy. This includes deciding which policies, zones, and ACLs to update, reusing existing objects and rules to avoid clutter, enforcing naming conventions and documentation, etc.
4. ActiveChange – automatically pushing the designed change to the different security devices.
5. Validation – verifying the change was implemented successfully and connectivity is now available.
With AlgoSec, workflows, conditions and thresholds can be customized as needed. First example: escalate to the security team’s approval if a risk check detects change is about to raise a high security risk or affects specific firewalls, etc.
In addition, AlgoSec provides full documentation and an audit trail which are built into the automated change process, keeping the security team in control and the auditors happy.
BusinessFlow – business application repository
With Connectivity as Code, connectivity requirements of each business application are stored in AlgoSec BusinessFlow, and each change in the application’s connectivity is automatically updated, so that it remains up to date.
This application repository can then be used either by the application developers or by the network security teams, as follows.
Application developers/owners
AlgoSec BusinessFlow gives application developers or owners visibility into the connectivity status, security, vulnerabilities and compliance of their specific applications. It provides a clear summary of the application’s connectivity flows (including a schematic diagram representing the connections within the application), changes over time, and additional information regarding the security and compliance posture of the application.
AlgoSec BusinessFlow can also be used as an interface to manage the application’s connectivity requirements, and even as a mechanism to safely decommission a retired application without impacting any other active application.
Most importantly, AlgoSec BusinessFlow provides a very easy method of checking the network connectivity status of the application, for example when troubleshooting an application in production.
Network Security and architects, security operations
AlgoSec BusinessFlow automatically adds the business application context to every underlying network infrastructure device, object or rule – i.e., each firewall rule is automatically labeled with the business applications it supports. A quick analysis can then be performed to check the potential impact on business continuity of any security change or maintenance activity, such as isolating a compromised server; taking down a server, firewall or router for maintenance or upgrade; cleanup of firewall rules; network architecture changes, etc. This capability alleviates the need to attempt to reverse-engineer a firewall rule to find its associated applications, and enables safe and efficient management of the network.
Integration with orchestration and configuration management flows
In order to integrate Connectivity as Code into commercial or home-grown CI/CD orchestration solutions, AlgoSec provides several tools and sample integration code.
Ansible
If Ansible is used as the DevOps orchestrations and configuration management system, adding the connectivity phase to the DevOps process is as simple as downloading the AlgoSec Ansible role, creating a suitable playbook (sample available), and plugging the playbook into the existing flow.
The AlgoSec Ansible role, sample playbook and a sample Connectivity as Code inventory file, as well as comprehensive documentation, are available for download from the Ansible Galaxy.
The AlgoSec Ansible role is distributed as open-source, and can be used as is or customized as needed.
The AlgoSec Ansible role is implemented in Python, using the AlgoSec Python SDK and the AlgoSec APIs, and connects to the AlgoSec server deployed in the organization to perform the necessary queries and actions.
Similar modules will be available for other common orchestration solutions such as Chef, Puppet and Jenkins, or can be created as needed, using the Ansible role as a reference.
Python SDK
AlgoSec also distributes a Python SDK, which serves as a Python wrapper for AlgoSec’s APIs. It implements the logic required to implement the Connectivity as Code phase in the DevOps flow, as described above.
The AlgoSec Python SDK is distributed as open-source and is available for download from GitHub.
APIs
Alternatively, AlgoSec’s rich API set can be used with any programming language and any environment, as needed.
See the AlgoSec API guide for more details.
Summary
This whitepaper described a process of implementing the Connectivity as Code approach in order to weave network connectivity and security into the DevOps process, or to “DevOpsify” network security.
By incorporating Connectivity as Code into the DevOps process, organizations benefit from:
- Seamless management of network connectivity as part of the DevOps process for faster, more agile and problem-free application delivery, rather than as an external out-of-band issue that requires separate – and manual – handling.
- Continuous compliance and auditability throughout the application delivery process.
- Business continuity – application connectivity requirements are clearly documented and up to date, ensuring minimal disruption to the business even during network, infrastructure or architecture changes.
- The ability to bridge the gap between application developers and network security throughout the entire application lifecycle (planning and development, deployment, production and decommissioning)
Addendum: sample connectivity repository file
The following JSON file lists several connectivity requirements (or flows) for a ‘Billing’ application, and one flow for a ‘Payroll’ application.
Note: Users can choose to create Connectivity as Code files for each application separately, or group the connectivity requirements of several applications into one file (clearly listing which flows are needed to support which application).
{
"applications": [
{
"app_name": "Billing",
"app_flows": {
"flow1": {
"sources": ["HR Payroll server", "192.168.0.0/16"],
"destinations": ["16.47.71.62"],
"services": ["HTTPS"]
},
"flow2": {
"sources": ["10.0.0.1"],
"destinations": ["10.0.0.2"],
"services": ["udp/501"]
},
"flow3": {
"sources": ["1.2.3.4"],
"destinations": ["3.4.5.6"],
"services": ["SSH"]
}
}
},
{
"app_name": "Payroll",
"app_flows": {
"new-flow": {
"sources": ["1.2.3.4"],
"destinations": ["3.4.5.6"],
"services": ["SSH"]
}
}
}
]
}
