Network segmentation…. air gap segmentation… the names go on and on.  But no matter what you call it, you designed it and deployed it for a reason.  Likely a very good reason.  Potentially even a reason with fines and consequences should the segmentation not work.  So once you deploy it…. what then?  Just trust it is working and will always stay working?

 Trust, But Verify

I admit I am likely viewed as boringly logical when it comes to the network.  It just doesn’t seem logical to me to spend so many hours in the design and the deploy phase and then just trust that it is working.   

Don’t just trust.  Verify. 

Use whatever tool you want.  Just please… know what is really going on in your network.  Know reality.   

In this blog I’m going to show you how you can use Stealthwatch to get visibility into what is REALLY going on in your networking in reference to your segmentation.  

How can Stealthwatch tell you if your segmentation is working or not?  I refer to Stealthwatch as “Your Network Detective Command Center”.  If there are hosts in your network communicating with hosts you know they shouldn’t be communicating with…. then all you need to do is get the visibility into that.  How?  Easy… enlist your network.  If 2 end hosts in your network are talking with each other in your network….  they are going through your network devices.  Easy then…. just “deputize” your network devices to report into the Network Detective what they see.  🙂 

In the associated YouTube for this blog we look into 2 examples.  Why two?  Because we are going to have different things end up being the issue in each one. 🙂

1. Guest Wireless 
2. HVAC Contractors

In this blog we shall focus on just the first one.

Ready to play?  First let’s review what I have in my network.  In my environment above I have

1. Stealthwatch Management Console (SMC) version 7 running as a VM
2. Stealthwatch Flow Collector (FC) version 7 running as a VM
3. 4 Cisco devices doing exactly what they were configured to do before… just now they have also been “deputized” to “report in” what they see (via Netflow in this specific example) 

Guest Wireless

We will focus on of a very simple Guest Wireless segmentation with just 2 subnets.

• Guest Wireless End Host Subnet: 10.2.96.21
• Guest Services Servers: 10.2.209.0

We have designed our network such that

• Guest Wireless end users should communicate only with
  • Other Guest Wireless End Users
  • Guest Services Servers 
• Guest Services Servers should communicate only with
  • Other Guest Services Servers
  • Guest Wireless End Users 

Let’s see if this is indeed what is happening in your network in reality.  

What do we need to do?  It’s simple. 

1. Create Stealthwatch Host Group(s)  for Guest Wireless
2. Create A Stealthwatch Custom Security Event to trigger an alert of a Policy Violation should any Guest Wireless end user be found communicating with any other subnet besides the Guest Services Servers.

Create Stealthwatch Host Group(s)

We have a number of choices here.  We can create one host group and put both subnets in it and create a policy that triggers if anyone within that host group talks to any host outside of that host group.  Another option is we can go more granular and create 2 host groups and then just add more detail to the policy we will be creating.

For now, let’s just go simple and put them both in the same host group.

So we go to Host Group Management as you can see above.  Within Host Group Management we find we, again,  have a lot of choices. Basically you can set up your host groups however best fits your uses… your needs… and your organizational preferences.

We will just go under “By Function” and add the host group under that.  

“New Host Group” will show up on the right and we can type in

• “Guest Services” for the Host Group Name

and also type in

• The 2 subnets 10.2.96.0/24 and 10.2.209.0/24 into the IP Addresses and Ranges box

 Time now to create the custom security event.

Create A Stealthwatch Custom Security Event

We will go into “Policy Management” in Stealthwatch.  As you can see below we have no Custom Events as of yet.  So we will Create a New Policy. 

As you can see in the pic above, we named the Custom Security Event – “Seg Violation: Guest” .    So far we have nothing in our policy.  This is why the verbiage is only “Alarm when….” right now.  Once we have created the policy the words listed will, in plain english, explain what the policy is doing.  I really like this feature.

So since we have nothing added yet.  We will click the “+” sign to “Add a rule”. 

As you can see below a drop down box will appear.  This is a drop down of all the rule types.  For us we will be keeping it super simple and just selecting “Subject Host Groups”

Adding Subject Host Group to the Policy

What happens next is that you will be selected to pick which host groups for your subject host groups and also whether or not you want the rule to be for an include of that subject host group or an exclude of that subject host group.   

Where you pick from will actually come from a menu section that will come in from the left.  In the pic below I caught the screen of the youtube just between when I selected “subject host group” and when the menu that comes in from the left fully appears.  

Below is with the menu section on the left fully on screen and ready for you to make your selections.  I really like the fact that it reminds you at the top that you had selected “Subject host groups” on the previous page.  

In our example we will be “including” Guest Services in our Subject Host groups.

Now that it is included…. we are back to the Policy we are creating.  As you can see below the wording is starting to take form:  

“When any host within Guest Services communicates with any peer host, and alarm is raised”

Okay so obviously we aren’t done yet.  Let’s “add a rule” again.

This time we will pick Peer Host Groups.

Adding Peer Host Group to the Policy

Remember what we want to do is create a policy event that will alarm if anyone inside of host group Guest Services talks with any host outside of Guest Services.  So for the Peer Host Group what we want is to exclude Guest Services.  For this we click twice on the circle next to the host group.

How is our policy looking now?  Well as we can see from below the nice simple English now says:

“When any host within Guest Services communicates with any host except those within Guest Services, an alarm is raised”

Perfection!  Just what we wanted to create!

Want to make sure I point something out here.  As you can see below the default status of a newly created policy is “OFF”.  

We are going to want to “toggle” that to ON in our situation and then click save.

Now what?   Well come on… it wouldn’t be any fun if we didn’t get a nice juicy policy violation to follow.  🙂

Policy Violation

Policy Violation Triggered on Stealthwatch Security Insight Dashboard

I hope you see below that it would be hard to miss the policy violation on your Security Insight Dashboard.  LOL.  It’s only listed in 4 different locations. 🙂

Clearly our segmentation is not working.  Let’s dive into it and see what is going on.

Let’s go to the PV alert on the left under Top Alarming Hosts and click directly on host 10.2.96.21 which is at the top of the list.

Host Report

Host Report: Overview Page

What we see below is that we have been brought to a host report page.  I have to admit I really like this page and this view a lot. Lots of nice “big picture” reporting and visuals as well as granular details as well.  

One of my favorites is actually Traffic by Peer Host Group in the middle.  In the middle is the host that this host report is reporting on.  To the left will be all the Inside Host Groups it is talking with.  To the right all the outside host groups it is talking with.  What I also really love is that the thicker the line for the conversation, the more traffic.  You can also hover over the line and get a little get an idea of how much traffic.

What we are going to drill down into is actually at the bottom – the Top Security Events for 10.2.96.21.

Host Report: Top Security Events

Looking below we can see a lot of really nice information. 

First start over to the far right – Source (2) and Target (0).  What this tells us is that this host is the source of the policy violation and not the target.  

The target is 10.2.210.91 in target host group: Catch All.  

What IS Catch All?  Any device that is defined as in a subnet that you have as “inside of your network” that is not assigned to a host group yet…. will show up as Catch All  as its host group.  

We know two things now we didn’t know before:

1. 10.2.96.21 – end Guest Wireless User is the SOURCE of the Policy Violation
2. 10.2.210.91 – is the TARGET of the Policy Violation.

Lets drill down into this even more.   Let’s go to the far right bottom and click the circle under “Actions”.  From here a little box inset will pop up.  From here let’s click “Associated Flows“

 

Associated Flows of Policy Violation

What you see below are the associated flows for the Policy Violation we are investigating.  You will likely want to start here to figure out what is going on and try to get a handle as to where and how your segmentation is broken.

You have all the clues laid out before you in the associated flows – date and time… the duration… the application… the amount of data… the ports… etc etc. 

Can you think of some you might also have wanted?  lol.  Not to worry… the columns you are looking at below are just the tip of the iceberg of the wealth of information about the flows that your Network Detective can help you with.  Just click Manage Columns and you will see all your options.  I use manage columns a great deal.   There are just tons of choices as to how you want the information and the results displayed to you.  

Obviously of course I broke the segmentation so we could have a policy violation of “forbidden traffic” that should not be happening in our network.

What forbidden traffic and forbidden conversations are going on right now in your network?  Find out.  Knowledge of the “truths in your network” really is key!

 

The YouTubes

The information I covered  in this blog is based on a YouTube I did titled  “Verify Your Segmentation is Working with Stealthwatch”.   In this YouTube we cover the above Guest Wireless scenario and then we go into a 2nd scenario. 

Side note:  If you also decide to watch the video… um…. sorry for them not exactly being my usual YouTube quality.  I needed to, by the Friday after Thanksgiving, have 4 videos done for something internal at Cisco.  Being completely transparent I was trying to meet that deadline… wasn’t in my own house… and a family member was in the hospital getting a pacemaker in.  When I saw the videos I decided I wasn’t going to put them up on YouTube cause I wasn’t my usual upbeat self in teaching and I also was talking very softly.  Then I thought… ya know what… The content for the 4 videos  (IOT, ETA, DNS, and Segmentation) is important and I should upload them to YouTube for others even if I’m not overly keen on the audio portion. 

Jan 21st, 2019 Update:  The Segmentation YouTube has been updated.   It is called “Verify Your Segmentation with Stealthwatch: UPDATED“