It’s 10 pm, Do You Know Where Your Configuration Assets Are?
About
This content is brought to you by Evolven. Evolven Change Analytics is a unique AIOps solution that tracks and analyzes all actual changes carried out in the enterprise cloud environment. Evolven helps leading enterprises cut the number of incidents, slash troubleshoot time, and eliminate unauthorized changes. Learn more
In the late 1960s, the catchphrase, “It's 10 pm, Do You Know Where Your Children Are?” was delivered across TV sets nationwide (in the US) reminding parents to keep their children safe in a time of rapid change, civil unrest, and turmoil. Today, there’s plenty of change, and unrest (and sometimes even turmoil) in Information Technology (IT) Infrastructure and Operations (I&O) teams as they transform into agile cultures embracing DevOps, DevSecOps, and Platform Engineering. But instead of “children” they need to protect, it is an entity referred to as “configuration”.
Configurations Matter
Configurations are the controlling elements of code, infrastructure, and applications. The configuration includes all the components of the infrastructure and applications, their parameters, and their attributes. NIST defines configuration as “the possible conditions, parameters, and specifications with which an information system, or system component, can be described or arranged.”
Configurations define the “behavior” of systems and applications. And since we live in a world of duality, there is always an opposite - and here it is - something called a “misconfiguration”. A misconfiguration is often a hidden risk that may ultimately lead to “bad behavior” impacting stability, security, and/or compliance. Impacts on one or more of these can severely harm a company’s reputation and slow down its efforts at Digital Transformation. It may be a mistake, an oversight, or even an intentional exploit…but no matter it still hurts.
For example, with all good intent an engineer makes a configuration change to an AWS region, but as it was unauthorized, any checks at approval time to ensure consistency between regions are bypassed. This change is one that is compliant with policy and doesn’t immediately cause an incident…but waiting for its chance to wreak havoc sits a hidden difference between regions that are required to be consistent. This “risky change” is a ticking time bomb that will eventually go off when another engineer makes further changes, even authorized, based on a faulty assumption that the regions are consistent…but they are not.
Proactive automation (as far “left” in the application lifecycle as possible) as well as real-time change detection and reconciliation, are necessary to uncover risky changes and misconfigurations, prevent their impact, and ensure consistency.
Now You See Them…Now You Don’t
But where are they? Configurations are everywhere, in your data center, private cloud, and public cloud deployments. But they come and go – they can be ephemeral. For example, containers used in cloud-native applications spin up and down quite quickly and a risky change or misconfiguration to one of these can have a grave impact.
You can’t mitigate and secure what you are unaware of or can’t see. But surprisingly, many enterprises have significant configuration blind spots and lack an overall asset inventory. They are without end-to-end visibility of their configurations and effective guidance on how to prevent impact from risky configurations. As a result, these enterprises continue to suffer from risky changes such as those that are unauthorized, inconsistent, anomalous, or ones that impact security. Any one of these can negatively impact customer experience.
The Times They are “a Changing”
There is a current trend amongst DevOps teams to expand their scope to include cyber security concerns, becoming a practice referred to as DevSecOps. As containers and serverless functions are increasingly used in cloud workloads, the need to ensure their security becomes ever more important. It has become clear that security and management of its configuration must be integrated into the agile methodologies used for rapid deployment, thus the need to include security in DevOps has become paramount.
Development, operations, and security teams all interact with configuration and together share the same configuration risks. A missed patch by operations threatens security. Wrong permissions set on a folder can impact application availability. Outdated privileged access could result in unexpected, accidental results and allow willful intrusion. An incorrect application setting can lead to overutilization of a server and impact operations. An erroneous DB Schema can cause a reliability issue.
It is essential that security testing in development is conducted as part of the sprint and not in a waterfall manner at the end of the sprint. Otherwise, you will spend precious cycles fixing misconfigurations whose effect could have been prevented.
Employ an automated, end-to-end inventory of configuration assets
To effectively address configuration and change problems across the hybrid, multi-cloud, enterprises need a “single pane of glass” covering all configurations in granular detail, end-to-end, removing blind spots and enabling DevSecOps with configuration awareness. This is the critical first step in preventing undesirable consequences such as exposures, non-compliance, and stability-impacting issues resulting from misconfigurations. The practitioners of Dev, Sec, and Ops all use different tools, with different perspectives. However, they share configuration risks. This single risk-based view is required for effective DevSecOps convergence and protection from misconfigurations and risky changes that can be devastating to the business.
Silos Strike Again
Standards are good as there are so many to choose from…Some enterprises are beginning to “standardize” how they handle configurations. But they are doing it separately for each technology stack or deployment type – YAS style (yet another silo). There are configuration repositories for Kubernetes, ones AWS provides for its own environment, and GitHub for configuration as code. Some only work in the cloud, while others only work in the data center. This silo approach is unfortunate as it severely limits the effectiveness of configuration repositories.
Each repository requires specific expertise and individual access rights, and not everyone knows how to even use these tools. Furthermore, configurations are implemented differently. Some are implemented as scripts or code, while others as artifacts such as Terraform templates. You will need access rights to each, the skill to utilize them along with an understanding of the infrastructure architecture and application logic necessary to make sense of these configurations.
Configuration Risk Intelligence
Using a Configuration Risk Intelligence approach with an automated, end-to-end inventory of configuration assets can enable DevSecOps teams with a single shared view into end-to-end configurations across the hybrid, multi-cloud. This provides a risk-scored view enabling DevSecOps teams to mitigate the undesired, unexpected impact of configuration setup and modification. The Configuration Risk Intelligence approach can identify all configuration assets, baseline them, access their risks as they change, and initiate action to address risk before there is an impact.
It’s 10 pm, Do You Know Where Your Configuration Assets Are?
It’s got to be 10 pm somewhere in the world…but no worries, the automation in Configuration Risk Intelligence throughout the application/infrastructure lifecycle will provide the answer. It will detect and score misconfigurations and risky changes, and as an integrated part of your toolchain initiate the proactive action necessary to ensure stability, security, and compliance.
