KnowBe4 introduces InstantRevert™. Finally, you are able to determine your policy for an ideal configuration – call it a 100% compliant state for either a workstation or a (cloud based) server – and if assets covered by your policy change, InstantRevert will immediately revert back to your specified compliant configuration.

Before we go into more detail, let’s have a look at the immediate benefits this has from a system administration perspective:
- Dramatic reduction in help-desk tickets
- Significantly improved security
- Massive IT Operations time savings
- Audit time and costs reduced 50% or more

Now, let’s have a look at how things often are done traditionally. Organizations put policies and procedures in place as a means to meet compliance requirements. Audits are done at least once a year, and there is a scramble to pass the audit. After the audit and remediation though, focus is lost and ‘compliance drift’ sets back in. Sounds familiar?

There are many problems with this approach for physical and virtual machines, in the cloud or at your site. The moment endpoint machines drop out of compliance, you are more and more vulnerable to hackers because end-users make errors. Non-compliant (cloud-based) servers are an even bigger risk, as your organizational data may become exposed. And then there is the problem with compliance assessment and the remediation of the problems. Often it takes a long time to remediate, if that step happens at all. This leaves widows of vulnerability that we all know are serious risks.

Wouldn’t it be great if you could prevent this whole tiresome process of:
1) IT Security identifies relevant compliance policies and runs scanners that assess against that policy
2) System Administration gets the report with the compliance violations
3) Admins work to correct the violations on top of the normal workload, often one machine at a time
4) After this remediation, change occurs on end-users’ machines and sometimes undoes the correction
5) Last, after this compliance drift in step 4, the whole thing starts back up at 1) above

Worst is, that due to the fact this process is very time consuming and frankly unrewarding, it gets done as little as possible, sometimes only once a year. You can see what is wrong with this picture, and InstantRevert will help you get out of this endless race with no winners!

Real-time Compliance

As you just saw, the traditional approach to point-in-time testing and remediating the violations can result in several problems:
1) Your visibility and reporting gets seriously degraded
2) It’s very expensive, as this approach requires more tools and more staff
3) The delays cause an extended vulnerability window putting both servers and endpoints at risk

The way out is Real-time Compliance, you could also call it continuous compliance. What you need is an approach to compliance that allows you to specify a 100% compliant configuration state which can be maintained at all times, shown on a management console to be in compliance, and keeps all machines in your specified ‘ideal system end state’. That ideal end state is what you define it to be, based on your policy. You will have created a condition where you are continuously compliant, saved IT Operations time, reduced your cost significantly and experienced dramatically reduced help desk calls. Better yet, you can constantly work on improving your compliance without any sliding back!

Need to comply with PCI DSS, HIPAA, SOX, Basel II/III, Bill 198, USGCB, STIG or GLBA?

Each of these regulations creates a business challenge. We have taken each of these regulations, and explain how InstantRevert helps you comply.
Please check this separate page which has sections for each of these.

Intelligent Agent

The InstantRevert intelligent agent monitors all machines for the current configuration, comparing them to the policies you have set for that machine. In case of an unauthorized configuration change, it will revert that back. See the FAQ for the timeframes. It will report back to the InstantRevert Console what the result is of the configuration change.

No Bloatware!

Is this concept completely new? No, traditional configuration management frameworks from CA, BMC, HP and IBM also have real-time compliance as their goal. But these are massive, super-expensive and yearlong deployments. InstantRevert was built from scratch to be a lean and mean configuration enforcer. The InstantRevert Agent is less than 500KB in size, CPU usage is less than one percent, and can be deployed in minutes – not months.

InstantRevert, Your Configuration Enforcer

InstantRevert really is active configuration management for endpoints, servers and the cloud. See it as your ‘configuration enforcer’. It will give you real-time visibility, your information will be consistent over all machines, your costs will be significantly reduced, and as a bonus you can make it home for the weekend. InstantRevert currently supports the Windows Operating System (Linux is on the 2012 roadmap) and is a client-server architecture with a lightweight intelligent agent on each machine. That agent continuously monitors the state of security and compliance across endpoints, servers and cloud, and keeps all machines compliant. With InstantRevert you have a revolutionary solution in your hands that gives you “configure-and-forget”. It addresses the regulatory need for compliance reporting. At the same time it satisfies your operational need to have centralized visibility while enforcing security configurations on all machines in your network and in the cloud. Using InstantRevert you can finally escape the old reactive compliance cycle for a new compliance best-practice.

How are system administrators solving problems with InstantRevert?

Like we said, InstantRevert is a very powerful tool that helps you solve difficult technical gotchas. Here are some examples of how system administrators are using InstantRevert to solve a variety of hard-to solve admin issues.

Download The 5-Machine Full-function Eval

Download the eval now, and use the Quickstart Guide to get going. You will immediately understand this is a new power tool that allows you to manage your network in a whole new way! Scroll back up and click on the Download Tab.

Frequently Asked Questions

Is this a new V1.0 product? If so, I’m going to wait.

No, this is version 3, and it runs on thousands of production machines as we speak. This is seasoned code, that has been in the works for over 3 years. Check the Release Notes in the Documentation section. Download the full-function eval and try it for yourself. We recommend you read the QuickStart Guide before you start, and make sure the prerequisites are installed before you run the InstantRevert install.

Can I run it in ‘report mode’ without making any immediate changes?

Yes, you can. Look at the change reports, and decide (after some weeks or months) when you want to turn on the instantaneous revert option.

Can use it to protect the whole registry?

You use InstantRevert for registry- and file protection of high value assets. For example, to protect the settings of a mission critical application on a server, or the cricial apps an end-user works with all day. Because InstantRevert is fairly granular with respect to specifying the file(s) or registry key(s) to protect, it is not typically used to protect large numbers of OS settings (Microsoft does a pretty good job of that now themselves).

What reverts back and how fast?

Assets you explicitly have specified as covered by Policy are protected and will be reverted. File and registry settings are reverted within milliseconds. Processes and Services are polled and the polling time determines how long it is before they are modified. That time is configurable, the highest frequency is one second.

What is the difference between InstantRevert and Group Policy?

1) Group Policy is largely open loop; you define policies and the assumption is they will work (which is a really bad assumption in our experience). The primary mode of GP feedback is the event log on each individual machine. So, for example, if you use GP to deploy an application, the way you verify that it was properly deployed is to browse to the event log on each system and confirm the three entries for a properly installed MSI exist without error. On the contrary, InstantRevert is largely closed loop. It provides feedback at your InstantRevert Admin Console for the actions taken by the its Agents.

2) GP is only periodically updated; every one to two hours by default – assuming the machine is on the network and logged into the domain. Certain GP is only updated on domain logon (like software installs, drive mappings, startup scripts, logon scripts) and so if policy set by such GP is changed, it remains changed until the next logon, which could be days. So if a setting gets changed, it is typically out of compliance for at least an hour and sometimes days, weeks or even more. InstantRevert corrects settings much quicker, in some cases in milliseconds.

3) GP often fails to be applied for a literal plethora of reasons. We have seen Fortune 500 environments where fewer than 50% of machines actually have the GP fully applied when audited. (Come to think of it, we don’t know that we’ve ever seen an environment where all the GP is successfully applied to all machines.) If you go to http://support.microsoft.com and search for ‘Group Policy Error’ you get 234,000 results.

4) Understanding GP is non-trivial. Here’s what someone needs to know to get started using Event Logs to debug GP problems: debug GP problems
Here’s an example of one of the many ways in which GP can unexpectedly fail. InstantRevert provides you with an easy way to see if Policy on a machine has failed from the Console.

Isn’t Microsoft’s SCCM doing the same thing?

Conceptually, SCCM is a lot like InstantRevert – only way more complicated and many times slower. It would almost take a whitepaper to do this justice, but here are the highlights:
1) First, this capability has existed within SCCM since 2007 and an early version of it was in SMS 2003 SP1. The length of time it’s been around versus the number of sites actually using it should tell you something.
2) InstantRevert continuously monitors settings and reverts them either within roughly a millisecond or, for processes and services, within a few minutes (although, if the setting is important, this can be reduced to every second). To give you a feel for the timeframes, changes in Policy to a machine participating in SCCM Compliance Settings arrive at the machine within two (2) hours.
3) The SCCM default Compliance Evaluation Schedule is every 60 minutes. Here are the instructions for changing it (look at the instructions – this is the type of thing you also need to do in order to remediate a non-compliant value.
4) SCCM requires domain membership. InstantRevert does NOT require domain membership.
5) InstantRevert provides a simpler, more direct interface for common actions – like protecting files and registry keys.
6) SCCM Compliance Settings have dozens upon dozens of options for ANY remediation to be performed. On top of that, you must write the remediation script yourself to perform the remediation for everything but registry values. There are also limitations on when remediation can be performed. For example, the Rule Type must be Value (it cannot be Existential) and the Operator must be Equals (it cannot be Not equal to, Greater than, Less than, Between, greater than or equal to, Less than or equal to, One of, or None of).
7) Another difference is that InstantRevert provides comprehensive logging related to Policy. SCCM Compliance Settings are only reported as one of several states – with NO additional information available. So each SCCM Policy Item equivalent is simply reported as Unknown, Compliant, Non-Compliant, Failed. If it’s unknown, non-compliant, or failed and you want to know why – good luck.

I forgot to include a Check-in Policy Item. Does that mean my Agent will never check in?

When we first prototyped InstantRevert a few years ago, we forgot to do that once too! That’s why ever since, Agents check in every ten minutes if you don’t have an explicit check-in Policy. If you do have an explicit check-in Policy the ten minute check-in doesn’t apply.

I don’t seem to be able to delete a policy – what’s up?

InstantRevert is a (very) powerful tool. We included a failsafe, just to make sure you don’t shoot yourself in the foot. In real use, there are typically at least dozens of Groups, a hundred or more Policies, and hundreds or thousands of Machines. You might think: “That Policy isn’t being used any more so I’m going to delete it!” click the checkbox and the Delete Icon in the top bar, but the Delete icon is grayed out. Why? This is the failsafe. you first need to click SAVE, and then click Delete. Having the SAVE button there prevents unintended catastrophes. Imagine that there is a Policy that formats the C: drive. Now imagine that you currently have the root Group “All Machines” selected and you accidentally click on the Policy to format the C: drive. If an explicit Save is not required, you just formatted the C: drive of thousands of machines. Told you InstantRevert was powerful!!

I’ve selected the Send Wake-Up menu item after right-clicking on a Machine in an attempt to get it to check in immediately but it doesn’t seem to be working. What’s wrong?

If Send Wake-Up doesn’t result in an Agent checking in immediately, either the Agent isn’t running or the network path to the Agent doesn’t permit a Handler-initiated message to reach the Agent. As you know, InstantRevert is a pull-based system where Agents initiate all routine communication. This pull-based architecture has the advantages of being highly scalable and minimizing the need for firewall modifications. The tradeoff for these advantages is that normally you must simply wait until the Agent connects on schedule to get the latest data. The Send Wake-Up feature was developed to assist in those instances when you don’t want to wait. It works by attempting to send a very small message to the Agent that simply requests the Agent perform a check-in immediately. But for this to work the Agent needs to receive that message – so the network must pass the Handler-initiated message to the Agent. The IP address to which the message is sent is the IP from which the Handler detects that Agent last checked in. The Port to which it is sent is the Port specified in the Agent configuration.

When setting a Schedule, I notice a “Randomization” option. What is that?

Imagine you want to silently install an application on 5,000 machines at a particular time. Now imagine that the .MSI for that application is 200 MB. The transfer of the .MSI occurs on the next check-in by each Agent after saving the Policy to transfer that file (it’s then cached on the Machine until the Policy’s execution time). A simultaneous transfer of 5,000 instances of a 200 MB file could saturate your network and/or adversely affect the performance of other things dependent upon the network. Randomization allows that “load” to be spread over time. Simply select either a Uniform or Normal distribution (Uniform results in an equal number of Agents executing the Policy over a unit time. Normal results in the familiar bell curve distribution where most Agents execute the Policy at the scheduled time but executions are still spread out. The Randomization Limit defines the extents – plus and minus – over which the executions will occur. So, a Uniform Randomization with the Randomization Limit = 30 and Interval of Minutes will result in executions from 30 minutes prior to 30 minutes after the scheduled time.

I checked the logs after scheduling a Policy on 100 Machines using the Randomization feature. My settings should have resulted in ten Machines executing the Policy in each of ten one-minute periods. But sometimes only 8 Machines executed the Policy during a one-minute period and other times 12 Machines executed it. Is there something wrong?

Not at all. Randomization is a statistical feature and so is subject to minor deviations from the “ideal” case. Rather than create a bottleneck by having the Handler schedule each Agent’s execution at a particular time, the Agents themselves use a Monte Carlo algorithm to select their own execution times. When dealing with hundreds of Agents or more, there is typically less than 1% deviation from the ideal case.

Why do I need to press the Refresh button to refresh the Console display? Can’t you just make it refresh automatically every few seconds?

A design decision was made when the Console was originally developed that necessitates refreshing in order to see current information. We understand this is sometimes annoying and are changing the underlying architecture in the next major release such that the various bits of the display update themselves automatically when underlying data change. Unfortunately it is not as simple as automatically “pushing” the Refresh button every few seconds. Doing that would result in loss of information if a user were changing a setting when the automatic refresh occurred – which would undoubtedly be even more annoying.

The Machine Name and Agent Version are returned automatically by every Agent and I know additional details can be returned by using a GetMachineDetails Policy Item. I also know that I could write a PowerShell script and use the Policy-Defined Data Viewer to view the results. Is there any other information available that might be of value to me?

There is a little more information that is collected for each Agent which isn’t displayed. It’s easy to see if you are familiar with SQL. The Machine table in the InstantRevert database contains the last date and time an Agent checked in, the IP address through which it connected to the Handler, and also the total number of check-ins that Agent has performed since registering with the Handler.

The log messages can be quite long and with many machines reporting back such large messages I am concerned that a lot of bandwidth is being consumed. Is there some way to turn off logging?

There is no way to turn off logging – without it many of InstantRevert’s most valuable features wouldn’t work. However, the bandwidth cost of logging is VERY minimal. InstantRevert uses “codebook” logging wherein each message is represented by a single short identifier. So when you see a long message – say 1,000 characters long – that message was actually transferred from the Agent to the Handler as a only a short identifier. In fact, it is the identifier that is stored in the database too. The conversion to the text string you see in the interface occurs only upon display – thereby saving storage space in addition to bandwidth.

I understand that when an Agent first reports in to the Handler that it’s placed in the Unknown Machines group. But I don’t like that name – can I change it?

Sure. Just click on the name, wait a second, and click again (long enough that the second click isn’t registered as a double-click). This will allow you to edit the name. You can also change the Default Group (the Group into which Agents first check in) by selecting any existing Group and then setting Default Group in the Properties to True.

I manage thousands of Machines running InstantRevert and I periodically move large numbers of them from one Group to another. But doing so is time consuming. I have to manipulate the check box next to each one of them. Isn’t there a better way?

Yes! When the Machines list box is selected, you will notice the two check box icons in the toolbar become available. Simply use multi-select to select the rows of interest (shift-click for a range and/or ctrl-click to add or remove individual rows) and then use either the check icon or the uncheck icon in the toolbar to change the state of all the selected rows. When used with filtering (the colored flags in the toolbar) or searching (using the text box to the upper right of the Machines list box) you can always select or de-select even large numbers of desired Machines quickly.

Which Regulations does InstantRevert help me with?

We built a separate page for this which gives you a quick overview of all the different standards: PCI DSS, HIPAA, SOX, Basel II, Bill 198, USGCB, STIG, GLBA..

What are the technical requirements?

InstantRevert Server Administration Console
Operating System
Windows 7 (32- & 64-bit)
Windows Server 2008 SP2, R2 (32- & 64-bit)
Windows Vista SP2 (32- & 64-bit)
Windows Server 2003 R2+ (32- & 64-bit)
Windows XP Professional SP3 (32- & 64-bit)
NOTE: Embedded OS are not supported
Hardware
Pentium III 400 MHz or higher
300 MB free disk space
512 MB memory
1024 x 768 monitor resolution

Important
Microsoft .NET Framework 3.5
Microsoft SQL Server Express 2008R2

Instant Revert Endpoint Agent
Operating System
Windows 7 (32- & 64-bit)
Windows Server 2008 SP2, R2 (32- & 64-bit)
Windows Vista SP2 (32- & 64-bit)
Windows Server 2003 R2+ (32- & 64-bit)
Windows XP Professional SP3 (32- & 64-bit)
Windows 2000 Server with SP4 RU1 or later
Windows 2000 Professional with SP4 RU1 or later
NOTE: Embedded OS are not supported
Hardware
150 MB free disk space
512 MB memory

Documentation:

Download the QUICK START GUIDE first

InstantRevert V3 Product Manual

V3 Release Notes

PDF WhitePaper: A New IT best practice: Real-time Compliance

Web WhitePaper: A New IT best practice: Real-time Compliance

InstantRevert Competitive Comparison

Please fill out the form for your fully functional trial, after clicking submit you will get immediate access to the download.

Click Below To Go To The Quote Page