Detecting Unauthorized Changes Automatically (Part 3)
This article is part of a 5 part series covering how unauthorized changes still remain the bane of today's IT operations, regardless of advances in technology, and how automated change detection is critical for addressing this.
- Unauthorized Changes Still Undermine Modern Environments
- Apply Change- Centric Causal Analysis to Quickly Fix Problems
- Detect Unauthorized Changes Automatically
- Empower the Service Desk to Prevent Incidents
- Know What Changed to Stop Outages
Part 3 of a 5 part series
- - - -
How do you address an unauthorized change that has actually happened, but is not yet responsible for an incident?
How do you fix something before the business experiences negative impact from the action?
- Automatically detect changes. You need to be able to know what changed and when anywhere in the environment. IT Operations must always think about the entire application delivery chain and know what changed - no matter what that application does in the environment.
- Identify changes at a granular level. Knowing what’s changed is not enough. It is imperative to gather change information at the granular detail level (what’s changed, what the parameters are, how many times a change occurred), and then correlate this information to approved change requests.
Despite the fact that many organizations put processes in place for protection, they still need to be able to correlate what actually changed in terms of time, location, scope, and the nature of the change. This provides IT Operations with a clear picture of any discrepancy, in terms of what was intended to be done and what was actually done.
How should change requests be handled when the data is insufficient? Many times organizations realize that their processes are inadequate and have very little information to rely on (e.g., generic comments or an e-mail that says “Hey, I'm changing XYZ tonight.”).
Collecting All Changes
Many organizations lack the ability to identify changes. Evolven helps by collecting and providing detailed key data around all changes that occur and that could affect the application delivery chain. In terms of a simple O.S.I. model, one needs to recognize what has changed from the highest level of the application stack all the way down to the most detailed infrastructure layer since at any point in time one of those areas can affect another. One minor application change can have a significant impact on the entire infrastructure. Organizations with Infrastructure as a Service (IaaS) still need to consider what the potential negative impact is to storage if they make an application change. IT Operations still needs to know all of the details around ALL layers of the application stack.
Correlating Actual and Planned Changes
Evolven captures all data and uses it in context with service integration platforms, correlating both actual and planned changes.
Who? Who will conduct the change? Who actually made it?
First thing is who is supposed to make the change and who actually made it? Is it manual? Is there a release automation tool that is set up to make the change? This is one of the important areas to correlate because it applies a different level of risk.
What? What changed? What is the scope? What was actually changed?
In addressing the ‘what’ question, many times this means manual intervention into the Requests for Change (R.F.C.) process. IT Operations must know what is going to change: which configuration item (C.I.), what host, and what are the details around this? Often times vague or general comments are provided such as something was changed on the database, which makes it difficult for change requests to be properly acted upon. Evolven helps by applying automated analytics, correlating natural language responses along with other input, and analyzing data to provide insights and alert IT Operations where to focus their resolution efforts.
This means understanding anomaly detection and understanding loneliness factors. What environment is usually modified in this type of change request? Did a change get modified that isn’t normally performed? Also was there any pattern discovery? How can IT Operations see the consistency of change execution into something out of the norm? Evolven detects risky changes early on by correlating and analyzing changes with data from existing ITSM and monitoring tools.
When? Authorized timeframe? When was the change made?
Evolven leverages the authorized timeframes in order to ascertain when a change was made for greater accuracy within the Requests For Change (R.FC.) process. Evolven can automatically identify the timeframe per environment where the change happened because Evolven is constantly collecting change information. Evolven can detect a change - whether it’s a manual input, automated, scheduled, or something else.