Hello, world!

I think that’s the obligatory first line for any technology blog, right?

But, how do you know I am here? How do you know I exist? I have a blog profile, I have a picture, I have a blog tagged to my name. All of these are contextual clues that I exist in reality, without actually being physically present.

The same contextual clues can be used to integrate identity into your network. For years now, Cisco Security has been discussing the need for pervasive identity on a network.  To be clear, identity is not just an IP address.  For anyone who doubts that I challenge you to tell me who that DHCP address lease was lent out to at a given time that the endpoint accessed another endpoint because you need to determine which user at your medical provider hosted files in a samba share.  It’s impossible!

There are numerous benefits of using a full set of identifying criteria, as opposed to the legacy use of just IP addressing, to integrate identity into the very fabric of your network.  Similar to the ripples in the space-time continuum that we heard so much about in Star Trek, the introduction of identity in the network changes the paradigm altogether, adds visibility and abilities to identify phenomena that we never had before.

Starting with this blog post and for the next few, I’m going to share insights on pervasive identity, focusing on architectures to enable identity to be used as a control for overcoming security challenges. Based on my experience as a security service technical leader for Cisco Security Services, I’ll summarize those benefits, challenges to look out for, and how you can approach this on your security journey.

Notice that I specifically use the phrasing “security journey.”  While I shudder to think that any consultant or security-focused engineer would ever disagree, the first level-setting conversation I have with all of my clients is that there will never come a time that they will be able to say “we’re as secure as we can get, there’s nothing further that we can do.” The fact remains, no matter what you’ve done to secure your network, there will always be additional threats, threat actors, and methods used to try to exploit your network.  Those threats will continue to come from external areas and will continue to evolve internally as well.  Many times, these internal threats are not the ones that one would expect.

To that extent, I’ve been presenting at colleges, executive briefings, and industry conferences for years now on a simplified way to start down the security journey.  I boil this down to five straight forward steps:

1. Understand the motivations of your attackers and the challenges of preventing these attacks
2. Gain visibility throughout your network and use that visibility throughout the security journey
3. Control endpoints utilizing the contextual identity you’ve gathered, starting at the access layer
4. Harden the network from the edge inward to limit your attack surface
5. Automate the control and hardening to limit your organizational overhead on mundane tasks.

Let’s look at the challenges I see many organizations contend with, which need to be understood and evaluated as part of the first step: “motivations and challenges.”  These major challenges include:

• Organizational Structure: The classic “My CIO just got a new iPad and wants us to get it on the network”. What a few of us in Security Services like to refer to as “executive bling”.
• Lack of Security Policy: Every time I have a customer who tells me they don’t have an information security policy, my jaw drops. It’s not like networks haven’t existed for most of my 32 years – and someone born in the time of the development of the internet has to point out the risk of not having a policy for what is and isn’t allowed on the network?
• Inability to accurately determine what is on the network and being used by whom: 90% of the companies we’ve surveyed have admitted that they don’t have this ability. For those who have somewhat of ability, it’s that the endpoint is a known corporate asset only because their inventory management system documented the MAC on introduction to the network and is being used in legacy port security, or that they are authenticating with a certificate that is provisioned during domain onboarding.

Before we ever get to a point where we can use contextual identity, we need to solve these issues, and I encourage readers to ask the hard question: Where do I fall in relation to these points?  Am I at least solving the first two and giving my help desk employee the ability to point to a policy that says “we will not allow personal devices on the network” when the CIO calls in, so they don’t have to fear for their job?  Am I providing a structure to enable the business, as opposed to preventing innovation and new ways of doing business for my company’s consumers?

At least attempting to resolve these can be the first step towards a more secure posture, though is the first of many steps to take. You can read more about Cisco Security Services’ framework for network visibility and segmentation here.

Source: blogs.cisco.com Credit@ Patrick Lloyd