Configuration validation automation – a hidden AvailabilityGuard™ gem!

New (or newly installed) IT components, whether hardware, OS, database or other software products, always arrive preconfigured with default settings.  Vendors put a lot of thought into choosing defaults – and keeping many of them intact is not a bad idea.  However, there’re almost always some we’d want to change.  The motivations are many, and very often they’re security-related.  Obvious examples include removing or locking default accounts, making sure critical log files are copied to safe locations, and applying the latest patches.  More complex changes could include configuration of specific authentication and authorization protocols, setting up encryption, limiting visibility and access, etc.

However, knowing what you’d like to change, or what standards you want to apply, and then validating that your changes were actually implemented – are two different things.  The larger your enterprise, the more likely it is that significant gaps between the two will exist, leaving you with unknown, and potentially unacceptable risk.

A decade ago, though even then it was highly inefficient, it was still common to see enterprises engage in yearly audits to discover precisely such deviations.  As IT transforms into much more agile delivery models and much more granular provisioning levels (such as Containers and Micro-Segmentation), manual auditing becomes completely unrealistic.

As part as the IT maturity journey, we see more and more enterprises seeking to automate configuration validation to reduce risk, while minimizing operations costs.  The most obvious choice would be to look for such capabilities in existing tools (e.g., CMDBs, change management, OS security auditing, etc.).  As it turns out – this is useful only for a limited subset of what we’d like to check for.  Anything that deviates, even slightly, from “vanilla” industry standards – can’t be easily validated.  For example, CIS benchmarks will recommend closing default accounts or changing their default password – and indeed there are several tools out there that will report when such recommendations are not met.  But what if you want to enforce one over the other?  Or even require a more exacting standard, such as making sure authentication is performed through a specific tool or protocol? Of course, this is just the tip of the iceberg – because some of the things you may want to audit require an intimate understanding of the specific semantics that are unique to your enterprise.  For example, making sure File and Directory Access Control Lists (ACLs) are formed correctly, and that File shares are restricted only to internal subnets.

This is where AvailabilityGuard™ can be amazingly useful.  As you probably know (and if you don’t, you’re warmly welcomed to check our website for more information) – AvailabilityGuard provides, out-of-the-box:

• An automated discovery engine that covers server and blade hardware, block and file storage hardware and software, OS and hypervisor configuration, SAN fabric, load-balancing, databases, public cloud infrastructure, and much more
• A check-automation engine that can detect deviation from industry best-practices, and identify risky cross-domains configurations
• A deep knowledgebase with thousands of risk signatures to help proactively identify single-points-of-failure, and data-loss risks

What is somewhat less known is that our engines are completely open to the end-user, and as a result, custom-checks can be onboarded in an extremely rapid manner.  Among the benefits of using AvailabilityGuard™ for this purpose are:

• Nothing to install. AG is completely agentless.[i]  Any check you configure on the master will automatically be applicable to the relevant systems.  Any update or improvement you incorporate takes immediate effect
• Central tracking of all custom checks; what has passed, what has failed, when and where
• Out-of-the-box integration with existing automation tools – from service desks through change management and orchestration. Specific triggers can automatically open an incident (e.g., in Service Now, Jira, Remedy, …), trigger a change process, or even let an existing orchestration engine know that an automated self-healing script should be applied
• Simplified compliance reporting

We invite you to learn more – please refer to http://support.continuitysoftware.com

[i] Though if you must use an agent in a specific environment, it’s possible to do so.