NSX Security Sample Demo Flow Script
DFW All Rules page
In this demo, we’ll walk through how the distributed features of NSX helps you quickly achieve
segmentation and simplify policy management that can help get you to a zero trust security
model. We’ve broken down segmentation into a prescriptive process, where you start with
more coarse policies and move to more granular over time
Environment rules
1. (Expand rules) The first place to start for quick wins and jump start reducing the attack
surface is to create coarse segmentation rules
2. Based on things like Prod/Dev/Test or other similar categories
3. And we can leverage your existing VLANs and segments, no changes needed
4. With this example we are blocking Prod and Dev workloads from communicating
5. I'm highlighting a couple of options you could leverage to create guard rails in the
environment
6. (Prod networks group) Our sources include workloads on the production segment and
specific production workloads
a. for the segment we're including any workloads in a specific segment or vlan
b. for the workloads I'm leveraging the context we get for all the VMs to
automatically include all that have a name that starts with prod
7. And it’s similar for the Dev group
8. This L7 stateful firewall is distributed inside the hypervisor
9. Every workload automatically gets a firewall
10. And that firewall sees every packet in/out of the workload
11. The gives us a unique position to leverage context about the workload we are securing
to simplify policy
12. Because we don’t have to rely on the physical network or IP address, we can give you a
really powerful segmentation tool
13. (PCI example) If we had PCI or another group of workloads that are in the same L2
network as the non-PCI, we don’t need to change their network configuration to achieve
segmentation
14. (PCI servers) We can simply tag them as PCI, and create a group that includes all PCI VMs
with this tag
15. Now we can control the communication for them regardless of their underlying VLAN or
IP address
16. If the VM moves around the policy will follow
17. (PCI to PCI rule) Here we allow PCI to talk to other PCI and block everything else
18. You could also leverage a similar approach for other groupings - create a group based on
context and policy is automatically applied based on your rules
Pause for questions
Application rules - overview
1. At this point in our process we have created a simple and powerful segmentation
outcome (from PPT Step 1)
2. Now we can turn our attention to securing our applications with more granular policies
if needed
Application - VDI (ASK AND SKIP IF THEY DONT USE VDI )
1. An example use case that is more and more common now is preventing the spread of
malware if a remote user in VDI is compromised
2. For that we can create a single rule to start that says VDI cannot talk to VDI
3. (VDI Desktops) Using a tag that can be applied every time a new VDI VM is created,
which places it in the VDI desktop group
4. And when the VM is removed no one has to go to a firewall and remove a policy
5. Another common situation is remote developers needing access to the dev app
6. (AD group) We can create a policy that says if you are part of the Private Cloud
Developers AD group
7. We will allow access to the dev app servers
8. We are using Identity firewalling to permit the right users to the correct workloads
Application - Dev App
1. For the application that our developers are accessing we can create a policy that covers
all of their app tiers
2. We are allowing the web front end to be accessed by port 80 and 443 (group definition)
3. We are putting the web front end VMs into a group automatically when they have the
dev-app-web tag applied
4. This can be done with any number of automation solutions
5. The web tier to talk to the database over 80 and 443
6. And we can apply a Drop policy at the end for everything else trying to access the
application
7. We’ve provided the least amount of access possible using simple policies with dynamic
groups
8. This will significantly reduce the attack surface of this application
Emergency rule
1. One last thing I want to highlight here
2. Because we see every packet in/out of the workloads
3. And know the context of the workloads themselves
4. We make it easy to create an emergency policy in case of some event that we need to
control quickly
5. This is your big red button that you create centrally and it gets pushed to the entire
environment
6. This example is blocking SMBv1 for something like a Wannacry attack
7. We leverage our L7 inspection engine to block it with this rule
Pause for questions
IDS/IPS
1. This gets us that Step 1 of segmenting our network
2. We can further enhance our security posture by looking for attack attempts against
vulnerable software
3. The proverbial "known bad" that is out there
4. That is where we leverage the distributed IDS/IPS
5. Like the distributed firewall, it resides in the hypervisor and sees all of the traffic
6. Each workload can have it applied as needed for your security policies
7. (IDS Page)
8. Looking at the events dashboard you can quickly see the activities that are occurring in
your environment
9. In a timeline layout
10. If we look below we can see that there are several incidents that have occurred that we
need to investigate
11. (Expand high event)
12. And here’s an event tied to a specific CVE
13. In this example we see the product affected as well as the details such as CVSS and CVE
14. We can leverage the context of the workloads to correlate back to the affected VMs
(click)
15. List of VMs (close)
16. (Arrow)We can see both the direction of attack and traffic flow
17. Clicking on the intrusion history bar we see more chronological details (click)
18. 150 > 101 - We can see that the attacker at .150 attacked .101
19. 101 > 102 - Then we see that .101 laterally attacked .102…they are on the same L2
network
20. We didn’t require any taps and we can see movement inside the same layer 2 network
that traditional appliances would have missed
21. Giving you even better visibility
(Back to dashboard)
IDS/IPS Setup and optimization (OPTIONAL)
1. (Profiles)
2. Like the DFW we can optimize our IDS/IPS deployment
3. I can create profiles that set which signatures I want to evaluate in the DC
4. (Expand App Servers)
5. Here I have narrowed down the sigs to only those apps I have deployed
6. (Products Affected)
7. Our signatures have additional metadata included that allow more granular selection
8. Show rule total
9. (Expand VDI)
10. I could also approach the (Attack Targets) as a way to select the appropriate sigs to
apply
11. Here VDI sigs would only be for client based attacks
12. (Rules)
13. (Expand Prod and VDI)
14. Then I can apply these groups of sigs to the rules to set where I want to evaluate
15. You can see that those profiles I created are applied to those same FW groups we used
earlier
16. If I want to switch to prevent I can make that change to the rule and then go into the
specific sigs to set the prevent action of Drop/Reject as appropriate
17. You have that level of granular control
Summary
That was a quick walkthrough of how you can quickly achieve segmentation with
simplified and distributed policies that also gives you greater visibility
