A Word on Automated Discovery and Security Credentials

The discovery and mapping of IT infrastructure components to a business service is a lot like forensics.  The latter is defined as “the application of a broad spectrum of sciences and technologies to investigate and establish facts of interest in relation to criminal or civil law.”  As anyone who has watched the umpteen versions of CSI (Crime Scene Investigation) on television knows, forensics plays a critical role in solving crimes. While I am not suggesting that IT executives are criminals, I think there is a valid, and potentially informative, analogy here so let’s explore further.

In the case of discovery and mapping of IT infrastructure, we’re applying science and technology to investigate and establish the current factual relationships between business services and IT infrastructure.

Let’s take our analogy to the next step. To perform an investigation requires certain access and permissions. Understandably, this can make some people nervous. What are you looking for? Why are you looking there? How do I know you’re not going to break something?  The bottom line is, can I trust you enough to permit access to my key possessions? Those questions apply to forensics investigations, as well as IT projects designed to discover and map business services.  Sounds pretty similar so far, right?

Now, if a ‘bad’ person is trying to hide something, a diligent forensics investigator may seek a search warrant. The concept of a search warrant is older than the Fourth Amendment to the U.S. Constitution, which guards against unreasonable searches. As a result, most searches require a warrant based on probable cause and must be specific as to the object to be searched for and the place to be searched.

OK, so this basic legal instruction is interesting, but how does it tie to an IT discovery and business service mapping project?

Well, we run into this issue all the time (and Neebula is certainly not alone) because any IT discovery solution requires certain access and permissions, which in our case translates to the term “security credentials.” Most organizations are not keen to provide credentials to their systems. It’s in their DNA. As a former officer in the Army, I can tell you that the question: “do you have a need-to-know?” is the golden rule when it comes to questioning whether to share confidential information. IT executives who have a compelling need to increase service availability or “just” allow their IT managers access to graphical, topologically-accurate maps of their key business services for a host of benefits, including enhanced root-cause analysis, better change control, improved business continuity capabilities, etc., know the answer is affirmatively “Yes!”

The fact is, if you can’t live with providing your internal co-workers and the tools they use to secure availability of key services with enough information, it’s game over because automated discovery solutions just won’t work. And that’s a shame because we see time and time again how automated software saves significant time and money, as compared with alternative, manual, labor-intensive, and error-prone approaches which can become Sisyphean-like tasks that never actually produce any value.

Looking at Security Credentials

Make no mistake, to perform automated discovery and mapping, some specific security credentials are required. It is important to be completely upfront and transparent about the specifics that are required in order to avoid misunderstanding and problems right from the start. Since IT always controls the security credentials, and all sensitive information is kept encrypted and secure without leaving the organization, security risks are minimized.

Security should never be a compromise. But, neither should it stand in the way of realizing the many efficiency benefits of implementing automated IT discovery and mapping. This is especially true when the security implications are known going in and are therefore entirely transparent and manageable. The benefits of being able to automatically discover and map a business service within hours are too great when compared with traditional manual processes that (as we’ve visited above) more than likely will never get done and never produce any tangible value.

Frankly speaking, success may depend on the IT-equivalent of a search warrant with the CIO functioning as the judge. The CIO may dictate that the good of the community (read: business) far outweighs the concerns of the suspect (read: compartmentalized security policies). We have found this approach to be particularly helpful in a number of implementations – especially where the IT security and IT operations team don’t communicate well or where the overall IT organization is too federalized to benefit from an accurate, cross-domain view of a “business service.”

It’s axiomatic that the science of forensics, by its very practice, impacts what is being analyzed (look for my future post on the Heisenberg Uncertainly Principle ;-)). But, most will agree that the benefits far outweigh any theoretical impacts it may have. Likewise, there is no doubt that organizations will benefit from an automated approach to business service discovery and service mapping. IT organizations are advised to take calculated risks to realize these benefits.

 

Yuval Cohen is a co-founder and the chief executive officer of Neebula Systems. Previously, he was vice president of Marvell Semiconductor and the general manager of Marvell Software Solutions Israel. He joined Marvell in 2003 via the company’s acquisition of Radlan Ltd., where he served as the chief technology officer and vice president of engineering. He holds a Bachelor of Science and Master of Science degree in electrical engineering from Tel Aviv University.

Image: Slavoljub Pantelic/Shutterstock.com

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>