Policies are an important part of how UpGuard works, but in large implementations, policy bloat can make managing different groups of devices unwieldy. To combat this, UpGuard has implemented policy variables and variable override options in version 2.29 to allow people to better use a single policy across multiple groups. Out-of-the-box policies don’t always offer the necessary flexibility to adjust to real environments, but with UpGuard’s policy variables and overrides, administrators can adjust their expected configurations to apply to multiple systems or environments, taking into account their differences, and allowing them to focus on maintaining the configurations they care about.
It's a topic that comes up frequently for us here at UpGuard. Our customers are always keen to know how they can take control and simplify their configuration management processes. We've all experienced at some time or another that issue that was the result of a database migration that didn't complete, a column that has mysteriously changed data type or an old version of a stored proc or view being restored to a new database.
We received a lot of positive feedback regarding our last article on Controlling SQL Configuration Drift so thought it might be a good idea to continue along that same theme of analysis and follow it up with an article about DNS configuration and some simple steps you can take to prevent configuration drift.
Controlling database configuration drift is a tricky subject. It's a topic that comes up frequently for us here at UpGuard and customers are always keen to know how they can go about taking control and simplify their configuration management processes. We've all experienced at some time or another that issue that was the result of a database migration that didn't complete, a column that has mysteriously changed data type or an old version of a stored proc or view being restored to a new database.
We've been working with a lot of Windows shops recently and IIS configuration seems to be a big pain point for many enterprises. Other than a brief stint in mainframe purgatory after university, I started life as a .Net developer and these conversations reminded me of my fun with IIS back in the day. In reflecting on this, I realized that the developer/operations interaction around IIS configuration is a near perfect example of the type of conflict that gave birth to the DevOps movement.
I shouldn't have to explain the concept of configuration drift to most of you, but just in case, it is the phenomenon where running servers in an infrastructure become more and more different as time goes on, due to manual ad-hoc changes and updates, and general entropy. If you're more of a visual learner, I strongly encourage watching this video from Sesame Street.
Many enterprise network workers are now adopting automation technology as a means of completing operational tasks, and of creating a more efficient environment within an IT enterprise. One of the advantages of adopting IT automation is that it helps to deliver optimal IT management, without the need for any significant capital investment.
While there are many benefits to cloud computing, one of the major difficulties is migrating from the in-house servers to a cloud computing platform. Configuration issues can develop when a company does not have the right tools, and when it lacks clear communication.
Cyber resilience is a fundamental change in understanding and accepting the true relationship between technology and risk. IT risk (or cyber risk, if you prefer) is actually business risk, and always has been. And the cybersecurity industry, for what it's worth, has generally avoided this concept because it goes against the narrative that their respective offerings—whether it's a firewall, IDS, monitoring tool, or otherwise—would be the one-size-fits-all silver bullet that can keep businesses safe. But reality tells a different story.