Under Analytics

Back when network management was booming in the early 90’s, the whole idea seemed straightforward. System administrators would speak of endpoints on the network as being “under management” or conversely “unmanaged.” There seemed to be a place for everything and looking back now at those times, enterprises seemed so simple compared to today. Maybe simple is not the right term, maybe they just seemed more orderly compared to the modern network landscape.

At some point, hackers showed up and names like “under management” or “unmanaged network elements” made little difference to them. I remember security folks in the early days joking that SNMP (Simple Network Management Protocol) stood for “Security Not My Problem.” An insecure network meant that you had an insecure business! The experienced security architect knows that whether the system is under management, under someone else’s management, or completely unmanaged, if that system is part of the business, it is still their job to secure it. To put it another way, while management of systems can span certain, more specific information systems, security must always be as wide as the business.

I would like to suggest a new term and concept for our vocabulary and that is “under analytics.” I like to think of this as a conceptual means to discuss if areas of your digital business have enough visibility for continuous monitoring of its integrity. Why not just call it “under management?” Well, because more and more these days, you are NOT the one managing that area of the network. It might be the cloud service provider managing it, but it is still your problem if something gets hacked. You could even then speak of observable domains as having certain requirements that satisfy the type of analytics you would like to perform.

There are many types of observational domains to consider so let’s talk about some here. Back in the day, there was just your enterprise network. Then when folks connected to the internet, the concepts of internal and external and even the DMZ networks were referenced as observable network domains. These days, you have to deal with public cloud workloads, Kubernetes clusters, mobile devices, etc. Let’s just say that you can speak of having any amount of observable domains for which you require telemetry that will get you the visibility required to detect the most advanced threat actors in those domains.

For each of these observable domains, there will need to be telemetry. Telemetry is the data that represents changes in that domain that feeds your behavioral analytics outcomes. You could make a list of the competency questions you would want to answer from these analytical outcomes.

• Are there any behaviors that suggest my systems have been compromised?
• Are there any behaviors that suggest some credential has been compromised?
• Are there any behaviors to suggest there is a threat actor performing recognizance?

My suggestion is that you begin with these questions and then hold security analytics to them to see if they are competent to answer them daily, weekly, monthly, etc.

From there, you can go one step further and start to consider and look into scenarios like the following:

• We have a new partner network, is it “under analytics?”
• We have a new SaaS service, is it “under analytics?”
• This company has a new cloud deployment, do we know if it is “under analytics?”
• What part of our digital busines is not “under analytics?”

How well do you know your digital business behavior when it is 100% without compromise? How would you even go about answering this? The truth is, you really do need to get to this level because if you don’t, threat actors will. Even if parts of the business use SaaS products, while parts of the network are using Infrastructure as a Service (IaaS), you can still set the requirements that there must be a sufficient amount of telemetry and analytics that help you understand the answers to these questions above. Your business must always remain “Under analytics” and only then will you be one step ahead of your attackers.

To learn more, visit the Cisco Secure Network Analytics webpage.

Share