The recent pandemic fundamentally altered enterprise operations in many ways. The unforeseen and rapid onset of the pandemic presented challenges for which few enterprises were prepared. Chief among these challenges was the mass migration of workers from offices to their homes. Enterprise network and security teams were suddenly tasked with delivering secure, reliable access to sensitive enterprise resources to home networks they could neither see nor control.

Balancing security and agility is a continuous effort: Enterprises constantly strive to deliver the speed and agility required to remain competitive, while simultaneously ensuring the level of security necessary to protect the enterprise from an increasingly diverse threat landscape. In the early days of the pandemic, when not just the productivity, but the health and safety of the workforce was in question, agility often trumped security. Even in retrospect, it is difficult to find fault in these decisions. However, as the dust of the pandemic settles, many enterprises have been left with potentially unsecure network configurations, the result of changes made rapidly and outside of normal change control processes.

While the pandemic amplified this problem, it is not new. Temporary access, testing and development, mergers and acquisitions and human error are just a few common sources of unsecure network configurations. In fact, any change introduces risk, which increases exponentially with the speed of change. This can be represented as “Degree of Change ^{Speed of Change} = Potential Risk.” If we accept this to be true, the pandemic may be the greatest single source of potential risk most will experience in their careers.

Despite the perpetual risk, change must occur with increasing speed for an enterprise to remain competitive and undertake business transformation initiatives. If the resulting risk cannot be avoided, how can enterprises reduce this risk to an acceptable level? Enterprises must establish processes to both mitigate existing risk and reduce future risk. To be effective, these processes must be run continuously and in parallel.

Mitigating existing risk

The objective of mitigating existing risk is to detect and address pre-existing unsecure configurations in the enterprise network. This requires defining a set of security requirements, or guardrails, which can be used to uniformly assess the entire enterprise network. What defines an unsecure configuration will vary between enterprises and may be influenced by applicable laws, regulations, standards, industry best practices and the enterprise’s risk tolerance. Although varied, there are generally two groups of security requirements.

First are requirements which would be considered unsecure, regardless of the individual enterprise. For example, Telnet being permitted from the internet to a demilitarized zone network (DMZ) is almost always a bad idea. If the enterprise is subject to The Payment Card Industry Data Security Standard (PCI DSS), allowing almost any traffic from the internet to a PCI data network would create risk and be a violation of PCI.

This category of security requirements is normally the easiest to define and is an effective way to begin identifying low hanging fruit while the process matures.

Security requirements which are specific to the individual enterprise fall into the second group. Security requirements in this category will take longer to define and must be continuously re-examined to remain congruent with the risk profile of the enterprise. Examples might include only allowing access to a critical network from a few select subnets over secure protocols, like HTTPS and SSH, or not permitting any access from a development network to a production network.

While opportunistic attackers are most likely to find only the unsecure configurations in the first group of security requirements, determined actors executing targeted attacks will dig deeper. Properly defining these security requirements must involve input from a wide range of stakeholders. The enterprises who are most successful in defining these requirements often start with the most critical or highly regulated network segments or with very high-level segmentation requirements. As the security requirements and processes are tested and proven, future iterations can expand to additional network segments and become more granular.

Reducing future risk

However successful mitigating existing risk is, it is a reactive process. A proactive, secure-by-default approach is much more efficient and effective at reducing risk from unsecure configurations. The objective of reducing future risk is to proactively detect potentially risky configurations before they are provisioned to the network.

The same security requirements designed to detect existing risk can be leveraged within change control processes to identify potentially risky configuration changes before they are made. Performing this security assessment on changes at scale, while continuing to provide business agility, requires automation, which can be achieved through scripting or purpose-built solutions. Reliable, automated security assessments provide enterprises with the ability to conditionally automate the entire change process, from request to provisioning, if no risk is identified and any other required conditions are met, further increasing business agility.

Automating security assessments of changes is especially critical in DevOps or CloudOps processes, where enterprise security teams tend to have less direct control and oversight. Because of the autonomy of these teams and the transient nature of the assets they control, the most effective way to enforce security is to create security guardrails within which the teams can operate freely. In this manner, enterprises can retain the agility of these new processes and technologies without sacrificing security.

Like death and taxes, change and the resulting risk are inevitable. In most enterprise networks, this risk through unsecure configurations has accumulated through years of normal network operations and increased dramatically over the course of the pandemic. Demand for increased speed to support DevOps, cloud adoption and business transformation initiatives will continue to grow, compounding the probability that these unsecure configurations will lead to a serious security incident. Mitigating the resulting risk requires parallel efforts to continually identify and correct existing unsecure configurations and to automate the proactive detection of potentially unsecure configurations in DevOps, CloudOps and change processes.