StealthWatch Demo Story Guide v1

StealthWatch Story Guide v1
Last Updated: 17-NOVEMBER-2016
About This Story Guide

A Story Guide is intended to provide a sample flow for leveraging a demonstration platform by infusing customers insights into the
solution. The goal is to highlight the capabilities and possibilities on offer to address customer issues and display how the product
can help the customer achieve specific business outcomes. This story guide is designed to assess customer needs, supported by
a whiteboard preparation and the product demonstration.
This story guide is designed to be customer-focused, engaging, and concise. Presenting this information should take 5-7 minutes,
although you can elaborate, as necessary.
DNA Summary
Figure 1. DNA Summary
At this stage of the engagement, you have gone through the following sales motions:
• Step 1: Qualify
• Step 2: Discovery
• Step 3: Set the Agenda
o White board
o YOU ARE HERE - Demo
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 21
Set the Agenda – Demonstration Objectives
This story guide includes the following scenarios:
• Scenario 1 – An overview of the StealthWatch Dashboard. This can be used to gain a view of the real-time threat
environment within a customer’s network. If a customer’s primary concern is answering the question of, What threats exist
in my network right now, this is the place to start.
• Scenario 2 – Uses the comprehensive Flow Query tool to manually validate network segmentation between host device
communities. If a customer is concerned with keeping business units, manufacturing devices, IOT sensors, medical
devices, etc. secured and separated from other organizations and devices, this demo can be used to demonstrate the
effectiveness of those segmentation efforts. What methods do you have to quickly discern the effectiveness of your
efforts?
• Scenario 3 – Network forensics and investigation into suspected data theft of confidential or critical information. When
customers are concerned that confidential information and data integrity is maintained, this demo is effective in showing
how StealthWatch can be used to track down data breaches. If a data breach were to occur, how quickly would you be
able to identify when it happened, what device was used, who was on the device, where it happened and the
methodology?
These scenarios allow you to:
• Demo Network-as-a-Sensor (StealthWatch) capabilities
• Tie demo back to customer’s top business initiatives and environment.
• Keep it simple and avoid technical deep dives which are not recommended at this stage
• Proactively highlight simplified management capabilities
• Emphasize that we are not simply a feature-rich HW company with CLI only
Customer discussions during demonstration should be focused on helping your customer Lower Risk. Common sample
challenges, benefits and related demonstration flows have been included as part of this guide.
Challenges
Focus on Risk:
• Secure perimeter does not mean secure network as insider threats remain invisible to perimeter security
• No automated mechanism for validating the application of security policy
• No simple way to gather data during a security incident
Benefits
Focus on Lower Risk
• Enable the entire network to gain real time visibility into security threats and anomalous behavior across the environment
• Automated and proactive notification of policy and compliance exceptions
• Full audit trail of all network transactions for detecting anomalous traffic and performing more effective forensic
investigations
Notes on the Demonstration Environment

This story guide in intended to assist Account Managers with demonstrating some of the key functions within Cisco’s StealthWatch
‘Network as a Sensor’ solution set and does not include exploration of other components (NetFlow configuration, AD, or ISE
‘Network as an Enforcer’). This demo is built in dCloud as an always-on demo environment and is comprised of:
• StealthWatch Components (SMC, FC)
• ISE
• Active Directory
• Simulated NetFlow data from Live Customer Environments
o Data cannot be modified
o Data on 24hr repeated cycle
o Variations in Alarms > Alarms will come and go depending on where simulated data is in 24hr cycle
This demo is intentionally limited in scope. Additional information on StealthWatch can be found by visiting Cisco on the web at:
www.cisco.com/go/security
Important: This story guide represents an example of how to structure the conversation during the demo. Note: It does not strictly
follow the dCloud standards
Value Proposition
The StealthWatch System provides enhanced visibility into advanced threats by identifying suspicious patterns of traffic within a
Cisco network. These suspicious patterns are supplemented with contextual information from other Cisco devices to improve the
overall analytics and establish specific threat levels associated with an activity. The solution delivers the following capabilities:
• Discover and mitigate advanced threats more quickly and before sensitive information is lost or critical business
operations are disrupted.
• Gain network-wide threat visibility by turning the entire network into a security sensor.
• Understand how advanced malware is propagating across the networked devices.
• Accelerate the design and deployment of next generation advanced threat detection and response system by combining
best-in-class tools into a framework validated by Cisco.
• Build on your existing network infrastructure investments for advanced threat detection and response.
The value of StealthWatch helps customers preserve revenue generation by protecting operations, save money by avoiding loss
and exposure, and lowering the risk associated with a Digital Enterprise.
Solution Components
The key components of the solution are:
• Aggregation and analysis of NetFlow telemetry and other data to detect threats and anomalous behavior, provided by the
StealthWatch System
• Network-wide security telemetry, provided by NetFlow export from Cisco Catalyst® switches, Cisco routers, Cisco ASA
5500 Series Adaptive Security Appliances (ASA), and Cisco NetFlow Generation Appliances
• Identity context for users and devices, including authentication, posture validation, and device profiling, provided by the
Cisco Identity Services Engine (ISE)
Accessing the Demonstration Platform
Access the main DNA Demo Platform page in the closest location.
NOTE: It is recommended that you pick the datacenter closest to your location, although you may use any datacenter.
Table 1. Main Page Address by Datacenter
Datacenter DNA Demo Platform
AMER https://dcloud2-rtp.cisco.com/dCloud/dna.jsp
EMEAR https://dcloud2-lon.cisco.com/dCloud/dna.jsp
APJ https://dcloud2-sng.cisco.com/dCloud/dna.jsp
GC https://dcloud2-chi.cisco.com/dCloud/dna.jsp
Click StealthWatch Hyperlink in the Step Two: Follow the VOD Walkthrough table.
Table 2. Step Two: Follow the VOD Walkthrough
Step Two: Follow the VOD Walkthroughs
StealthWatch
Click StealthWatch Hyperlink in the Step Three: Run the Demos table.
Table 3. Step Three: Run the Demos
Step Three: Run the Demos
StealthWatch
NOTE: If this is your first time logging into dCloud, you will need to accept the terms and conditions to continue.
1. The log in page displays. Enter the username amdemo1 and password C1sco12345.
2. Click Sign In.
Figure 2. Log In To StealthWatch
Scenario 1. Real-time Risk: Challenge/Benefit
Traditionally network security has relied on perimeter devices. One of the limitations of that method is gaining insight into what is
happening throughout the network. By enabling NetFlow across all devices in the network and by sending that information to the
StealthWatch system, we are able to gain network-wide threat visibility and turn the entire network into a security sensor.
An overview of the StealthWatch Dashboard. This can be used to gain a view of the real-time threat environment within a
customer’s network. If a customer’s primary concern is answering the question “What threats exist in my network right now,” this is
the place to start.
Challenge - Focus on Risk

• Secure perimeter does not mean secure network as insider threats remain invisible to perimeter security
Benefits - Focus on Lower Risk

Steps
1. When we first login into the system, we are presented with a dashboard showing our current threat environment.
Figure 3. Security Insight Dashboard
2. On the left hand side is the navigation pane. From here, you can jump back to the Dashboard at any time. You can also
access different views of the data gathered by StealthWatch, grouped by network elements such as hosts or users under the
Network Tab, or you can access information about the data traversing the network under the Flows tab. We will be using both
of these navigation elements in the upcoming scenarios.
Figure 4. Navigation Pane
3. Across the top of the Dashboard are the current security events.
Figure 5. Top of Dashboard
Events are generated when policies, anomalies, attacks, exploitations or other security related violations are detected.
As you can see from the counters, policy violations make up the majority of the current threats on the dashboard.
Policies include built-in or customer developed policies based on rules such as forbidding specific traffic types between host
groups. Threats are also detected by known threat signatures and behaviors, or by unknown deviations from baseline network
behaviors.
There are two critical points in the discussion so far.
• One is that we are gaining real time insights into security threats throughout the environment by leveraging the core
infrastructure.
• Two is that StealthWatch extensively leverages the actual traffic behavior within the network to detect deviations in normal
behavior, which is much more effective against day-zero attacks.
NOTE: The trend numbers within the categories will change and refresh on a regular basis. This is normal behavior and reflects
the real-time data collection within the StealthWatch Demo System.
Here is a breakdown of alarm categories:
• Concern Index – Hosts behaving as bad actors in the network
• Target Index – Hosts that are the target or recipient of scans or other malicious attacks.
• Recon – Indicates the presence of unauthorized and potentially malicious scans using TCP or UDP and being run against
hosts inside the network. These scans, referred to as reconnaissance are early indicators of attacks against your network,
and the scans may come from inside or outside your network.
• C&C – Indicates the existence of bot-infected servers or hosts in your network attempting to contact a C&C Server.
• Exploitation – Tracks direct attempts by hosts to compromise each other, such as through worm propagation and brute
force password cracking.
• DDoS Source – Host acting as a denial of service source
• DDoS Target – Host acting as denial of service target
• Data Hoarding – A host that is downloading unusually large volume of data from one or more hosts.
• Exfiltration – Tracks inside and outside hosts to which an abnormal amount of data has been transferred. If a host triggers
a number of these events exceeding a configured threshold, it results in a Data Exfiltration alarm.
• Policy Violation – Any violation of a rule(s) within a policy
• Anomaly – Tracks events that indicate that hosts are behaving abnormally or generating traffic that is unusual, but is not
consistent with another category of activity.
The information presented above is great for gaining insight into what is happening now. If we look at the various dashboards
below the current alarms, we can see threats over time.
4. On the left dashboard, we are presented with a breakdown of all the alarms by type and frequency over the last week.
Figure 6. Alarms by Type
5. In the middle dashboard, we get a snapshot of all of the alarms within the last 24 hours broken out by type.
Figure 7. Today’s Alarms
6. In the right hand dashboard, we see top applications over the last 24 hours.
Figure 8. Top Applications
7. The last portion of the Dashboard shows the total amount of flow data through the network for the last 48 hours. This is useful
to visually inspect the normal baseline trend in flow volume, and provides immediate visual indications of abnormal behavior.
Figure 9. Flow Collection Trend
Summary
Most organizations invest in a perimeter-based approach to network security. While effective at the perimeter, security does not
end at the network boundary. The StealthWatch System translates the information provided by Netflow into actionable intelligence,
allowing security teams to detect even the stealthiest attackers. From real-time current threats to the daily and weekly summaries,
StealthWatch enables to customers to have immediate access to data resulting in Lower Risk.
Scenario 2. Policy Validation: Challenge/Benefit
When we think of security at the network level, we immediately call to mind firewalls, access control lists, and other complex, static
methods of security enforcement. Alternative techniques for separating traffic or secluding host communities often rely on even
more complexity, such as VRF’s. Agility becomes a challenge with these static methods, costs increase as we add more devices
into the network for security enforcement, or complexity increases in trying to maintain a consistent, network wide policy. While
these challenges are in themselves barriers to success, perhaps an even bigger challenge is in validation and ongoing knowledge
of whether these efforts are working or effective at achieving the intended goal.
StealthWatch is uniquely suited to validating the results of your security investment by providing full disclosure of what is
happening in the network before and after deploying security measures.
This scenario uses the comprehensive Flow Query tool to manually validate network segmentation between host device
communities. If a customer is concerned with keeping business units, manufacturing devices, IOT sensors, medical devices, etc.
secured and separated from other organizations and devices, this demo can be used to demonstrate the effectiveness of those
segmentation efforts. What methods do you have to quickly discern the effectiveness of your security efforts?
For many customers, segmentation or separation is a critical element to their security framework. For manufacturing, IP enabled
robotics or plant systems need to be segmented from the general office worker systems. In healthcare, medical devices remain
separate and independent from other parts of the network. In many cases, it is difficult and time consuming to verify device level
segmentation. Even then, it is impossible to know if fully automated endpoints are only able to communicate with other automated
endpoints. Full, ongoing visibility is the only means of verifying your security efforts are functioning as intended.
In this demo scenario, a customer had a challenge with factory automation disruption. This customer recently deployed
segmentation to isolate the factory floor from the rest of the network but does not know if the machines are truly isolated. Since
machine to controller is the only communication acceptable, any communication with something else, say an end-user workstation
or a server, indicates a violation of policy and a failure to effectively isolate the factory automation environment.
To make an analogy for what we are going to do here, think of all the phone calls you have in your received calls list on your cell.
To fastest way to find spam or unwanted calls would be to filter out all the legitimate calls and everything left will be spam. We are
going to do the same thing here. We will filter out the legitimate traffic to our protected hosts, and whatever is left will be unwanted
traffic and indicate the security effort needs more work. If we have nothing left, and there are no extraneous flows, we will know the
security effort was successful.
Validation can be automated via policy creation for long-term use, but for this demonstration we will do a manual verification to
provide an idea of how StealthWatch can be used to validate your security measures. This manual example can be automated,
modified or adapted to provide ongoing verification.

• No automated mechanism for validating the application of security policy

Steps
1. From the Dashboard, select Flows in the left hand navigation pane.
Figure 10. Flows
2. Next, select the first item, Flow Search from the list. As you can see in this next window, the Flow Analysis: Build Query page,
we can choose a number of options to select broad search criteria, or narrow our search down to very specific host
conversation. In our example, we will select the Advanced tab.
Figure 11. Flow Analysis: Build Query
3. Now that we are at the Advanced Tab, it is time to build the query.
4. First, we will change the Range to Last Week so we can view any flows that have happened in the last 7 days. Since we do
not know when, or if a conversation has happened, we want to cast a wide net to see if our security measures are working as
we expect.
Figure 12. Query Builder
5. The next part of our query, in the left hand pane where the Search Subject is listed, we are going to narrow the search down to
devices in the Machines hosts. Since StealthWatch collects data on every flow in the network, it would be pinpoint from
unknown sources without some type of filtering. Our focus in this demo is to ensure our automation hosts in the Machines
group, are only talking to the ControlSystems group.
6. We need to do a little drill down here. StealthWatch can organize hosts in a hierarchical fashion; we will click on the Host
Groups button. Inside Hosts is the default setting, but we will narrow this down to the ControlSystems hosts.
7. The hierarchy is arranged as Host Groups -> Inside Hosts and finally Machines.
Figure 13. Host Groups > Inside Hosts
This group of hosts has been defined by their IP Address in the StealthWatch Management Console Application as part of this
demo.
Our goal is to identify any traffic that may have reached the Machine hosts from anything other than the ControlSystem hosts. The
easiest way to do this is to look for all flow data to our Search hosts (Machines group), excluding anything from the ControlSystem
group.
8. Now we will exclude any ControlSystems group flow data from our query. In the right hand pane where we select the
conversation or flow peer, under Host we’ll change Includes to excludes:
Figure 14. Excludes Host Groups
9. Next, we will click on the IP Address/List and change it to Host Groups. The resulting screen should look familiar and similar to
the one we saw in the Search Subject tab we just completed.
10. Next, we will select the ControlSystems host group. We will drill down just as we did before, starting with Host Groups, then
Inside Hosts, and finally ControlSystems.
Figure 15. Excludes ControlSystems
11. Now that we have defined what devices we want to see conversations between, our Machines group and anything outside of
that group, we need to specify what type of traffic we are looking for. In our case, we are looking for any flows (traffic) that is
outside Machines to ControlSystems, so it is unnecessary to narrow down our search definition any further.
12. Now, we will scroll to the bottom of the screen and click on the Review Query button.
Figure 16. Review Query
13. This screen enables us to review our query. Our query is designed to show all flow data to our search hosts (ControlSystems)
excluding any flow data from automation devices (Machines).
Figure 17. Query Builder
14. Now, we will run the query. It will take a few moments for the query to run. The system is processing every flow record
generated within the network for the last week. The more flow data that exists, the longer the query will take. What is truly
amazing is how fast this is given the workload underway. In just a few moments, the system is processing thousands or
possibly millions of flow records.
Figure 18. Running Query
Summary
If our network policies are functioning correctly, when the query completes, we should see no flow records. If any flow records were
returned as part of this query, we would know that the customers change to their environment, whether a
firewall/segmentation/ACL/etc., that security effort was faulty in some respect because the ControlSystems group would be
conclusively shown to be sending or receiving traffic flows with hosts outside Machines.
All companies want some reassurance of security and that their security efforts are making a difference. How many companies can
say they have real-time, pervasive visibility into the effectiveness of those efforts? Have the investments, both in money and effort,
made a positive impact in securing the infrastructure? StealthWatch provides ongoing, visible and demonstrable evidence and
feedback on the measures undertaken to secure the Digital Enterprise.
Scenario 3. Data Theft Forensics: Challenge/Benefit
Unfortunately, data theft happens daily. Where in the past, attackers were primarily focused on disrupting services; today’s security
breaches are focused on theft. StealthWatch works across the attack continuum, providing early behavioral insight to detect
attacks and security breaches early in their reconnaissance cycle, identification of attacks in progress and post-incident forensics.
In fact, when StealthWatch is coupled with ISE, Incident response goes from guesswork to context aware, user centric analysis
Network forensics and investigation into suspected data theft of confidential or critical information. When customers are concerned
that confidential information and data integrity is maintained, this demo is effective in showing how StealthWatch can be used to
track down data breaches. If a data breach were to occur, how quickly would you be able to identify when it happened, what device
was used, who was on the device, where it happened and the methodology?
Not all threats are easily detected or based on malicious traffic. Social engineering coupled with valid traffic types can still result in
lost revenue or damaged credibility. The integrity of sensitive data such as partner or supplier information can easily be
intentionally or unintentionally exposed to a third party. What part can StealthWatch play in assisting with network forensics?
Let us say there is a rumor circulating that partner data or some other sensitive information is being sent off-site. At this point, it is
just a suspicion, but it needs to be investigated.

• No simple way to gather data during a security incident

• Full audit trail of all network transactions for detecting anomalous traffic and performing more effective forensic
investigations
Steps
1. Start at the Navigation Pane, and click on the Host tab under the Network section.
Figure 19. Host
2. What we see now is the hosts view. This is a complete listing of all internal hosts, sorted by alarm severity. The severity level
is determined by a composite rating across the event categories tracked by StealthWatch.
Figure 20. Hosts View
3. We also see details of when the host first came on the network, when it was last seen on the network, and the categories of
events generated or identified as associated with the host. The color-coding assists in quickly assessing whether an event
requires immediate attention or intervention.
4. What we are looking for is a possible data theft or exfiltration. Since we do not know when it happened, remember we are
investigating a rumor, we will scan down the left hand side and see a list of the individual alarm types that are supported and
we will select the Exfiltration filter. We can see that there are exfiltration alarms that have been triggered within the last 24
hours. We may have more than just a rumor.
Figure 21. Exfiltration
5. Let us see what information we can get from StealthWatch regarding this exfiltration alarm.
We can see that host 10.210.7.38 was one possible host that triggered the alarm.
NOTE: The demo environment is using pre-recorded Netflow data from a live customer environment. The data is replayed, with
slight variation, every 24 hours. This may result in one, or more hosts generating the Exfiltration alarm. Host 10.210.7.38 is
expected.
6. In this demonstration, we will focus on 10.210.7.38, however in a live network; it would be prudent to recommend that all
potential events be investigated.
7. Right now we have a suspicion and confirmation that some exfiltration event happened, since we have a hit against the
exfiltration policy. However, we do not know if this is a legitimate data transfer or data theft. Let us see if we can get more
detail.
Figure 22. Host Details
8. Let us dig one-step deeper by clicking on the IP address 10.210.7.38.
Figure 23. Deeper Look at IP Address
9. Now we see that this host is part of the Compliance Systems host group, (left side of screen lists host details) and it has been
communicating with some host in China at least once a day (center of screen shows flow peers).
10. We now know what organizational unit the host belongs to which may also tell us something about the type of data this host
and user have access to and whether or not we should be concerned.
11. The chart to the upper-right shows Suspected Data Loss and Data Exfiltration events over the last 7 days. This exfiltration has
been a daily occurrence, showing a consistent pattern of data exfiltration.
12. In the bottom-left corner, under Users and Sessions the only user for this host has been Lucy. This information is derived from
ISE and utilizes the integration of ISE and StealthWatch to provide user based context for Security. The times appear to be
somewhat random. The account for Lucy is being used, but the login times are odd.
Figure 24. Users and Sessions
13. Since this host is sending data to an external host, let us see what StealthWatch can tell us about what is being sent by going
into the Application Traffic: External Tab.
Figure 25. Application Traffic: External
14. Now we can see the suspected traffic is using FTP, so something is definitely being transferred. In fact, quite a bit of
information has been sent (the number will vary depending on how long the lab has been running) and only a fraction of that
has been received.
Figure 26. Application Traffic
Summary
Based on the information uncovered by StealthWatch, we have enough information to warrant quarantine for the host, a user name
to associate with the exfiltration event, and the confirmed knowledge that data was indeed transferred offsite in violation of our
current policy rules.
Threats to the integrity of your data are not just from external sources, they are also found internally. How do we detect, locate and
verify these internal threats? StealthWatch is able to see what other systems miss – legitimate traffic being used for illegitimate
purposes or against company policy. The linkages between user and event, the forensic trail, rather than taking days or weeks via
conventional methods, is immediately available and accessible via StealthWatch.

StealthWatch Demo Story Guide v1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

StealthWatch Demo Story Guide v1

Uploaded by

Copyright:

Available Formats

StealthWatch Story Guide v1

Last Updated: 17-NOVEMBER-2016

About This Story Guide

• Step 3: Set the Agenda

These scenarios allow you to:

• Demo Network-as-a-Sensor (StealthWatch) capabilities

• Tie demo back to customer’s top business initiatives and environment.

• Proactively highlight simplified management capabilities

• No automated mechanism for validating the application of security policy

• No simple way to gather data during a security incident

• Automated and proactive notification of policy and compliance exceptions

Notes on the Demonstration Environment

• StealthWatch Components (SMC, FC)

• Simulated NetFlow data from Live Customer Environments

o Data cannot be modified

o Data on 24hr repeated cycle

• Understand how advanced malware is propagating across the networked devices.

Table 1. Main Page Address by Datacenter

Datacenter DNA Demo Platform

Table 2. Step Two: Follow the VOD Walkthrough

Step Two: Follow the VOD Walkthroughs

Table 3. Step Three: Run the Demos

Step Three: Run the Demos

2. Click Sign In.

Figure 2. Log In To StealthWatch

Challenge - Focus on Risk

Benefits - Focus on Lower Risk

Figure 3. Security Insight Dashboard

Figure 4. Navigation Pane

Figure 5. Top of Dashboard

There are two critical points in the discussion so far.

Here is a breakdown of alarm categories:

• Concern Index – Hosts behaving as bad actors in the network

• DDoS Source – Host acting as a denial of service source

• DDoS Target – Host acting as denial of service target

• Policy Violation – Any violation of a rule(s) within a policy

Figure 6. Alarms by Type

Figure 7. Today’s Alarms

Figure 8. Top Applications

Figure 9. Flow Collection Trend

Challenge - Focus on Risk

Benefits - Focus on Lower Risk

Figure 10. Flows

Figure 11. Flow Analysis: Build Query

Figure 12. Query Builder

Figure 13. Host Groups > Inside Hosts

Figure 14. Excludes Host Groups

Figure 15. Excludes ControlSystems

Figure 16. Review Query

Figure 17. Query Builder

Figure 18. Running Query

Challenge - Focus on Risk

Benefits - Focus on Lower Risk

Figure 19. Host

Figure 20. Hosts View

Figure 21. Exfiltration

Figure 22. Host Details

8. Let us dig one-step deeper by clicking on the IP address 10.210.7.38.

Figure 23. Deeper Look at IP Address

Figure 24. Users and Sessions

Figure 25. Application Traffic: External

Figure 26. Application Traffic

You might also like