Stop playing whack-a-mole and put threats to rest with Cisco Stealthwatch Cloud

I was recently able to grab some time with a Cisco customer to hear about their experience with Cisco Stealthwatch Cloud, a SaaS-based Network Detection and Response (NDR) solution. Aspire Technology Partners, a Managed Security Service Provider, explained their use of the product for one of its customers that was in a dangerous situation involving some slippery malware floating around in the network. As I worked on this case study, I couldn’t help but think of one thing in particular…The North Carolina State Fair.

I am a relatively new North Carolina resident. Prior to working from home, I was no stranger to the commute up I-40 to building 9 of Cisco’s RTP campus. As I found my way around my new home state, I kept hearing that the NC State Fair is a rite of passage for new residents. I decided to check it out. What an experience that was. I got to see a monster truck show, a lot of farm animals and the world’s largest pumpkin. I also ate more fried food on a stick than my heart could handle. We also got to play whack-a-mole, a game that requires you to smash each mole as they poke their heads out of the machine with a mallet. As you progress, you earn points for each successful ‘whack’. Unfortunately, you can never really win since they never stop popping up.

Without an NDR tool like Stealthwatch Cloud in place, the modern Security Operations Center (SOC) is effectively doing the same thing. Their endpoint and perimeter solutions, while critical to network safety, are playing whack-a-mole: stomping on malware and isolating devices as they become infected while still knowing that the network is still at risk. Without east-west monitoring and visibility into encrypted traffic, businesses are susceptible to subsequent attacks once malware has established a foothold on the network. If your security team can’t identify how threats are accessing the network, malware could stay hidden for months…or even years.

Aspire Technology Partners was working with a customer who deployed an Incident Response (IR) team to contain a threat, believed to be ransomware, that was surfacing all over their network. The Aspire SOC team decided to deploy Stealthwatch Cloud to track the malware through east-west traffic monitoring. Here are a few reasons why Stealthwatch Cloud was critical to not only detecting the threat, but also stopping it dead in its tracks:

Stealthwatch Cloud deploys almost instantly

The Aspire SOC team deployed Stealthwatch Cloud on the customer’s private network in just 2 hours. This allowed the team to immediately start digging through east-west flows to hunt down the threat.

Stealthwatch Cloud detects threats behaviorally

Stealthwatch Cloud uses the network itself as a sensor, and offers both automated threat detection and the ability to search manually for threats. The team needed to identify the foothold of the attacker, and with comprehensive visibility provided by Stealthwatch Cloud, was able to discover that the malware found its way into the network via a vulnerable 3rd party device. No endpoint or agent-based solution could have figured this out.

Built-in remediation methods enable quick response to threats

Stealthwatch Cloud offers a wealth of integrations with 3rd party and Cisco solutions that allow users to go one step further and communicate across their organization, pivot into other tools to carry on an investigation and much more. Alerts come alongside their supporting observations that contain bits of context that users can leverage as they continue to investigate. A simple firewall rule blocked out this malware for good.

So, stop playing whack-a-mole, unless you’re at the fair. Even with proper agent-based and perimeter protection, your network may still be at risk. You can fill that gap and gain comprehensive visibility on-prem or in the cloud with Stealthwatch Cloud.

Continue reading

Cisco Secure Cloud Architecture for AWS

More and more customers are deploying workloads and applications in Amazon Web Service (AWS). AWS provides a flexible, reliable, secure, easy to use, scalable and high-performance environment for workloads and applications.

AWS recommends three-tier architecture for web applications. These tiers are separated to perform various functions independently. Multilayer architecture for web applications has a presentation layer (web tier), an application layer (app tier), and a database layer (database tier). There is the flexibility to make changes to each tier independent of another tier. The application requires scalability and availability; the three-tier architecture makes scalability and availability for each tier independent.

Figure 1: AWS three-tier architecture

AWS has a shared security model i.e., the customers are still responsible for protecting workloads, applications, and data. The above three-tiered architecture offers scalable and highly available design. Each tier can scale-in or scale-out independently, but Cisco recommends using proper security controls for visibility, segmentation, and threat protection.

Figure 2: Key pillars of a successful security architecture

[SAFE Secure Cloud for AWS (pdf)]

Cisco recommends protecting workload and application in AWS using a Cisco Validated Design (CVD) shown in Figure 3. All the components mentioned in this design have been verified and tested in the AWS cloud. This design brings together Cisco and AWS security controls to provide visibility, segmentation, and threat protection.

Visibility: Cisco Tetration, Cisco Stealthwatch Cloud, Cisco AMP for Endpoint, Cisco Threat Response, and AWS VPC flow logs.

Segmentation: Cisco Next-Generation Firewall, Cisco Adaptive Security Appliance, Cisco Tetration, Cisco Defense Orchestrator, AWS security group, AWS gateway, AWS VPC, and AWS subnets.

Threat Protection: Cisco Next-Generation Firewall (NGFWv), Cisco Tetration, Cisco AMP for Endpoints, Cisco Umbrella, Cisco Threat Response, AWS WAF, AWS Shield (DDoS – Basic or Advance), and Radware WAF/DDoS.

Another key pillar is Identity and Access Management (IAM): Cisco Duo and AWS IAM

Figure 3: Cisco Validated Design for AWS three-tier architecture

Cisco security controls used in the validated design (Figure 3):

◉ Cisco Defense Orchestrator (CDO) – CDO can now manage the AWS security group. CDO provides micro-segmentation capability by managing firewall hosts on the workload.

◉ Cisco Tetration (SaaS) – Cisco Tetration agent on AWS instances forwards “network flow and process information” this information essential for getting visibility and policy enforcement.

◉ Cisco Stealthwatch Cloud (SWC) – SWC consumes VPC flow logs, cloud trail, AWS Inspector, AWS IAM, and many more. SWC includes compliance-related observations and it provides visibility into your AWS cloud infrastructure

◉ Cisco Duo – Cisco Duo provides MFA service for AWS console and applications running on the workloads

◉ Cisco Umbrella – Cisco Umbrella virtual appliance is available for AWS, using DHCP options administrator can configure Cisco Umbrella as a primary DNS. Cisco Umbrella cloud provides a way to configure and enforce DNS layer security to workloads in the cloud.

◉ Cisco Adaptative Security Appliance Virtual (ASAv): Cisco ASAv provides a stateful firewall, network segmentation, and VPN capabilities in AWS VPC.

◉ Cisco Next-Generation Firewall Virtual (NGFWv): Cisco NGFWv provides capabilities like stateful firewall, “application visibility and control”, next-generation IPS, URL-filtering, and network AMP in AWS.

◉ Cisco Threat Response (CTR): Cisco Threat Response has API driven integration with Umbrella, AMP for Endpoints, and SWC (coming soon). Using this integration security ops team can get visibility and perform threat hunting.

AWS controls used in the Cisco Validated Design (Figure 3):

◉ AWS Security Groups (SG) – AWS security groups provide micro-segmentation capability by adding firewalls rules directly on the instance virtual interface (elastic network interface – eni).

◉ AWS Web Application Firewall (WAF) – AWS WAF protects against web exploits.

◉ AWS Shield (DDoS) – AWS Shield protects against DDoS.

◉ AWS Application Load Balancer (ALB) and Network Load Balancer (NLB) – AWS ALB and NLB provides load balancing for incoming traffic.

◉ AWS route 53 – AWS Route53 provides DNS based load balancing and used for load balancing RAVPN (SSL) across multiple firewalls in a VPC. 

Radware controls used in the Cisco Validated Design (Figure 3):

◉ Radware (WAF and DDoS): Radware provides WAF and DDoS capabilities as a service.

Cisco recommends enabling the following key capabilities on Cisco security controls. These controls not only provide unmatched visibility, segmentation and threat protection, but they also help in adhering to security compliance.

In addition to the above Cisco security control, Cisco recommends using the following native AWS security components to protect workloads and applications.

Continue reading

SaaS-delivered Encrypted Traffic Analytics with Cisco Stealthwatch Cloud

We’ve reached an interesting turning point for encrypted traffic.

Gartner predicted that 80% of web traffic would be encrypted by 2019. Sure enough, this prediction came true. Last year, the team at Let’s Encrypt, an organization that helps enable encryption for websites, cited that 80% of web traffic they’ve seen is now encrypted. We have reached the point where the average volume of encrypted traffic on the internet has now surpassed the average volume of unencrypted traffic.

This is largely good news, as moving forward, encrypting internet traffic is now the new norm online and will continue to grow. This is good for data privacy and should let us sleep a bit easier knowing that as out information traverses the internet, it’ll be encrypted.

However, much like the adoption rate of encrypted traffic, encrypted threats are also on the rise. This year, Gartner has predicted that more than 70% of malware campaigns will use some type of encryption to conceal malware delivery, command-and-control activity, or data exfiltration. Complicating matters, it’s also predicted that 60% of organizations will fail to decrypt HTTPS efficiently, thereby missing critical encrypted threats.

Traditional threat inspection methods that rely on bulk decryption, analysis, and re-encryption are not always practical or feasible, for both performance and resource reasons. These methods also compromise privacy and data integrity. Unfortunately, many organizations do not have a way to detect malicious activity in encrypted traffic without the use of decryption. With the growing amount of encrypted traffic and the number of threats hiding within it, how should organizations ensure the encrypted traffic coming into their network is safe, without compromising the integrity of that data?

A better approach to analyzing encrypted traffic

Stealthwatch Cloud is a Software-as-a-Service (SaaS) solution that is easy to try, easy to buy, and simple to operate and maintain. Stealthwatch Cloud analyzes network behavior to detect advanced threats, even those hiding in encrypted traffic. Cisco’s proprietary Encrypted Traffic Analytics (ETA) technology uses attributes like Initial Data Packet (IDP) to detect malware in encrypted traffic, without decrypting the data.

Recently, Stealthwatch Cloud has added further integrations with Cognitive Intelligence, our amazing cloud-based machine learning and AI R&D team as well as its Confirmed Threat Service.

These integrations allow Stealthwatch Cloud to ingest ETA telemetry from supported Cisco networking devices and provide additional, enhanced fidelity of encrypted (as well as non-encrypted) traffic. From there, ETA will alert users of potential threats that might be hiding in encrypted traffic. These alerts include cryptomining, unpublished TOR, botnets, Ramnit, Sality, malicious file download, phishing and typosquatting and more.

In a performance study by Miercom, Cisco Encrypted Traffic Analytics showed as much as 36% faster rates of detection, finding 100% of threats in three hours. Furthermore, the study found that Cisco ETA detected 100% of malicious flows within three hours

How it Works

Cognitive Intelligence’s Confirmed Threat Service provides Stealthwatch Cloud with a list of high-confidence Indicators of Compromise (IOCs in the form of IPs and domains), a full description of the related global threat, and a write-up of recommended remediation steps. These IOCs are generated as a result of processing billions of connections from across the globe using a pipeline of analytical techniques which include the collection of Initial Data Packets. In essence, the Confirmed Threat Service is the outcome of multi-layered machine learning and encrypted traffic analytics that can convict known as well as unknown global threat campaigns. Cisco ETA can match field data extracted from the IDP against known IOCs which allows Stealthwatch Cloud to then correlate local customer telemetry to the global Confirmed Threat Service.

New alerts created via this threat intelligence will show up as “Confirmed Threat Watchlist Hit” alerts. These alerts can include named malware type families and also provide details on what they do (exfiltration, exploit, content distribution, botnets, ransomware, etc). Some of the threat intelligence provided by the Confirmed Threat Service is created in collaboration with Cisco Talos. Talos will seed intelligence (initial set of seed IOCs), title and description of a threat. Cognitive Intelligence will then expand this seed set of IOCs with new occurrences using information gathered from IDPs and machine learning – which in turn yields new IPs and domains that are also related to the given threat and appear in real customer telemetry.

Meeting Compliance Needs

In addition to being able to effectively monitor encrypted traffic coming into their network, organizations also have to consider how they use encryption on their own data. When using encryption for data privacy and protection, an organization should be able to answer major questions:

How much of the digital business uses strong encryption?

What is the quality of that encryption?

This information is critical to prevent threat actors from getting into the encrypted stream in the first place. Today, the only way to ensure that encrypted traffic is policy compliant is to perform periodic audits to look for any TLS violations. However, this method isn’t perfect due to the sheer number of devices and the amount of traffic flowing through most businesses.

Cisco Encrypted Traffic Analytics provides continuous monitoring without the cost and time overhead of decryption-based monitoring. Using the collected enhanced telemetry, Stealthwatch provides the ability to view and search on parameters such as encryption key exchange, encryption algorithm, key length, TLS/SSL version, etc. to help ensure cryptographic compliance.

Together, Cisco ETA and Stealthwatch Cloud can also identify encryption quality instantly from every network conversation, providing organizations with the visibility to ensure enterprise compliance with cryptographic protocols. These tools deliver the knowledge of what is being encrypted and what is not being encrypted on your network so you can confidently claim that your digital business is protected and compliant. This cryptographic assessment is displayed in Stealthwatch Cloud and can be exported via APIs to third-party tools for monitoring and auditing of encryption compliance.

Continue reading

Using Amazon Web Services? Cisco Stealthwatch Cloud has all your security needs covered

Like many consumers of public cloud infrastructure services, organizations that run workloads in Amazon Web Services (AWS) face an array of security challenges that span from traditional threat vectors to the exploitation of more abstract workloads and entry points into the infrastructure.

This week at AWS re:Inforce, a new feature for AWS workload visibility was announced – AWS Virtual Private Cloud (VPC) Traffic Mirroring.  This feature allows for a full 1:1 packet capture of the traffic flowing within and in/out of a customer’s VPC environment.  This allows for vendors to provide visibility into the entire AWS traffic, and the ability to perform network and security analytics.  Cisco Steathwatch Cloud is able to fully leverage VPC Traffic Mirroring for transactional network conversation visibility, threat detection and compliance risk alerting.

Stealthwatch Cloud is actually unique in that we have had this level of traffic visibility and security analytics deep within an AWS infrastructure for a number of years now with our ability to ingest AWS VPC Flow Logs. VPC Flow Logs allow for a parallel level of visibility in AWS without having to deploy any sensors or collectors. This method of infrastructure visibility allows for incredibly easy deployment within many AWS VPCs and accounts at scale in a quick-to-operationalize manner with Stealthwatch Cloud’s SaaS visibility and threat detection solution. In fact, you can deploy Stealthwatch Cloud within your AWS environment in as little as 10 minutes!

Additionally, we are seeing that the majority of customer traffic in, out and within a VPC is encrypted. Stealthwatch Cloud is designed from the ground up to assume that the traffic is encrypted and to model every entity and look for threats leveraging a multitude of data points regardless of payload.

Stealthwatch Cloud takes the AWS visibility and protection capability even deeper by leveraging the AWS API to retrieve a wide array of telemetry from the AWS backend to tell a richer story of what’s actually going on throughout the AWS environment, far beyond just monitoring the network traffic itself. We illuminate API keys, user accounts, CloudTrail audit log events, instance tags, abstract services such as Redshift, RDS, Inspector, ELBs, Lambdas, S3 buckets, Nat Gateways and many other services many of our customers are using beyond just VPCs and EC2 instances.

Here is a screenshot from the customer portal with just a sample of the additional value Stealthwatch Cloud offers AWS customers in addition to our network traffic analytics:

The following screenshot shows how we are able to extend our behavioral anomaly detection and modeling far beyond just EC2 instances and are able to learn “known good” for API keys, user accounts and other entry points into the environment that customers need to be concerned about:

Combine this unique set of rich AWS backend telemetry with the traffic analytics that we can perform with either VPC Flow Logs or VPC Traffic Mirroring, and we are able to ensure that customers are protected regardless of where the threat vector into their AWS deployment may exist – at the VPC ingress/egress, at the AWS web login screen or leveraging API keys.  Cisco is well aware that our customers are using a broad set of services in AWS that stretch from virtual machines to serverless and Kubernetes.  Stealthwatch Cloud is able to provide the visibility, accountability and threat detection across the Kill Chain in any of these environments today.

Continue reading

Security Analytics and Logging: Supercharging FirePower with Stealthwatch

When we consider network threat detection, most of us immediately think of signature and rule-based intrusion detection and prevention systems (IDPSs). However, it is a little discussed fact that the very first intrusion detection systems, built back in the ‘80s, were actually based on anomaly detection!

Those pioneers understood that with the presence of zero-days and the lack of exhaustive black-lists, we needed to use the full range of analytical techniques at our disposal to be effective.

Those anomaly detection roots may not be so evident in today’s IDPSs however they were not totally lost. In fact, a whole new branch of network threat detection systems were developed that used those very same anomaly detection techniques. That heritage manifests itself, today in so-called Network Traffic Analysis (NTA) tools.

While IDPSs have made detecting the initial intrusion in the packet stream their relentless focus, NTA systems take a very different approach. They generally work on metadata generated from the network, often called network flows, so they can expand our scope of analysis in both time and space to become essential in post-breach analysis, incident response, and even threat hunting situations.

Well Cisco has arranged a family reunion!

We are proud to announce the combination of our best-in-class IDPS and NTA products, Cisco Firepower and Cisco Stealthwatch. The Security Analytics and Logging (SAL) solution brings the best of perimeter-based protection and detection with the power of visibility and security analytics over the entire network. We believe we have created the most comprehensive network-centric threat protection, detection, and response solution – something that only Cisco is in the position to achieve.

Raising the bar on Network Security

It is very well understood how IDPSs are effective in security protection: blocking activity that can be identified as a threat or violates some policy. However, we accept that threats still get through and that is why IDPS have robust rules-based detection engines based on content-inspection.

But what do we do with all these detections? What if the traffic cannot be inspected? What if decryption is not an option? What if the threat is spreading internally?

Security Analytics and Logging service is specifically designed to augment your Cisco Firepower deployment with security analytics, from the Stealthwatch Cloud platform, to drive improved threat detections and provide the insight needed for more effective protection.

It All Starts with Visibility

The foundation of the solution is the aggregation of the connection and detection logs from Cisco Firepower with the network flows that the Stealthwatch platform collects. Just think about that. A dataset that gives us unprecedented visibility into the entire breadth of your network from perimeter to access, from campus to branch. But that’s not all! That “general ledger” not only contains all the header-based metadata, but now also includes all the metadata and inferences derived from all the deep content-inspection the Cisco Firepower engine provides.

Now you might be thinking to yourself, “there are plenty of tools I can use to gain this type of visibility.” However, in practice the sheer volume, velocity, and variety of the data can lead to staggering costs. The Stealthwatch team has made working at these scales our speciality and because our back ends are optimally engineered for the security outcomes we desire, we can offer this visibility in a much more cost-effective manner.

Security Analytics Driving Rapid Response

With all that visibility comes the opportunity to apply security analytics that can detect breaches that have bypassed the content-inspection based rules at the perimeter.

The security analytics powered by Stealthwatch can achieve this by baselining normal behavior of endpoints on the network in a process we call entity modelling. These models are then used to detect malicious activity based on any changes in behavior and indicators of compromise. The Stealthwatch engine can then combine these observations with others that may come from other parts of the network or even the detection engine in Cisco Firepower to create reliable and useful alerts.

Through this, you get detection of internal and external threats based on the analysis of network telemetry and IDPS logs, all from within Cisco Defense Orchestrator (CDO) and from that same interface, you can modify your network-wide policy to immediately deploy a remediation strategy. In addition, CDO is fully integrated with Cisco Threat Response which allows you to build incident casebooks and drive response actions across the whole of the Cisco security portfolio.

Closing the Loop: Improving Protection through Policy Tuning

Up until now, I have discussed the during and after phases of an attack but with SAL we can close the loop and reason more effectively about the before phase. In this phase we, as security practitioners, try to understand what is actually on our networks and what activity is to be allowed or blocked.

We express this intent through policies that enshrine both threat defense and compliance considerations. But designing and managing these policies across an increasingly complex digital business has historically been a major challenge and can leave many organizations vulnerable to attack.

The insight that it brings to the game drastically improves the way you can make policy decisions from within CDO. Through this capability you can query the logs collected from Cisco Firepower devices to play out what-if scenarios and validate the correct behavior of the policy at the enforcement point. In addition, the extended visibility of the rest of the network that the Stealthwatch platform provides can even allow you to determine if traffic is bypassing your enforcement points.

You can then turn around and deploy these highly tuned policies across the entire portfolio of security products right from within CDO! This is an entirely new paradigm that is required to not only scale with your growing network but also help you seamlessly manage policies across your environment powered by intelligence and insight.

Through this, you get detection of internal and external threats based on the analysis of network telemetry and IDPS logs all from within Cisco Defense Orchestrator (CDO) and from that same interface you can modify your network-wide policy to immediately deploy a remediation strategy.

Continue reading

Cisco Stealthwatch Cloud and Microsoft Azure: reliable cloud infrastructure meets comprehensive cloud security

Isn’t it great when the enterprise technology solutions you use to achieve various business outcomes partner and work seamlessly with each other? Cisco and Microsoft have done just that to provide you with a scalable and high-performance cloud infrastructure along with easy and effective cloud security.

In 10 minutes or less, Cisco Stealthwatch Cloud extends visibility, threat detection, and compliance verification to Microsoft Azure without agents or additional sensor deployments within your cloud environment.

A new way to think about security

Enterprises are continuously adopting the public cloud for many reasons, whether it’s greater scalability, better access to resources, cost savings, increased efficiency, faster time to market, or overall higher performance. While the move to the cloud offers great opportunities, it also means that the old ways of thinking about security aren’t working for most organizations anymore, especially when it comes to visibility in the cloud.

Often this lack of visibility leads to challenges surrounding network traffic analysis, identity and access management, compliance and regulation, and threat investigation. We all know of organizations that have made security mistakes related to configuration and inadvertently exposed their private data, resulting in serious repercussions. Of course, training can be improved, configurations checked, and automated tools used to validate configuration parameters, but these efforts only address the preventative aspects of security practice.  Organizations also need to actively watch what is actually happening with their cloud assets and catch the threats that aren’t prevented. Active breach detection starts with improved visibility.  Complete visibility gives you a way to protect your cloud infrastructure in real-time, so you can be agile and address issues as they arrive.

Cloud security: a shared responsibility

While your cloud provider manages security of the cloud, security in the cloud is the responsibility of the customer. You as a customer retain control of what security you choose to implement in the cloud to protect your content, platform, applications, systems and networks, no differently than you would in your company’s private datacenter.

How do you know what is happening to data in the cloud? How do you know you’ve configured your cloud assets to be secure? How do you recognize cloud assets starting to communicate with new, possibly hostile internet sites?  How do you do it in real time and quickly enough to mitigate data loss?

To answer these questions, it’s critical to have an active breach detection solution for your public cloud. And for that solution to be effective, the cloud provider needs to enable the right visibility to tap into valuable cloud network and configuration telemetry. 

Cisco and Microsoft: better together

In the continuous effort to provide customers with industry leading solutions, Cisco has been working with Microsoft to bring Cisco Steathwatch Cloud to Azure. Stealthwatch Cloud, a software as a service (SaaS) active breach detection solution based on security analytics, can now deliver comprehensive visibility, and effective threat detection in Azure environments in as little as 10 minutes.

Traditionally, organizations have tried to overlay a patchwork of agents across cloud assets to detect bad activity. This approach requires significant costs and effort to deploy, maintain, and manage in dynamic environments such as the cloud. Importantly, it frequently doesn’t scale with your cloud environment with regard to cost.  But Stealthwatch Cloud can deploy within your Azure environment with no need for an agent and scales up and down according to your actual cloud traffic utilization.

How does it work?

Microsoft provides Azure Network Security Group (NSG) flow logs that contain valuable information on north-south and east-west traffic within an Azure virtual network. Flow logs show outbound and inbound flows on a per flow basis, the network interface (NIC) the flow applies to, 5-tuple information about the flow (Source/destination IP, source/destination port, and protocol), if the traffic was allowed or denied, and in Version 2, throughput information (Bytes and Packets, and the NSG rule applied to the traffic). Organizations use this information to audit activity on their cloud network.  Stealthwatch Cloud can natively consume NSG flow logs V2 via APIs, without having to deploy any agents or sensors.

Additionally, Microsoft has also introduced Azure virtual network TAP (Terminal Access Point) that allows you to continuously and easily stream your virtual machine network traffic to Stealthwatch Cloud like a traditional, physical network SPAN or TAP. You can add a TAP configuration on a network interface that is attached to a virtual machine deployed in your virtual network. The destination is a virtual network IP address in the same virtual network as the monitored network interface or a peered virtual network. This approach provides access to not just flow logs, but also other network traffic like DNS data.

Stealthwatch Cloud can be powered by both NSG flow logs v2 and vTAP data. Stealthwatch Cloud analyzes this data using entity modeling to identify suspicious and malicious activity. For every active entity on the network, Stealthwatch Cloud builds a behavioral model – a simulation of sorts – to understand what the entity’s role is, how it normally behaves, and what resources it normally communicates with. Then it uses this model to identify changes in behavior consistent with misuse, malware, compromise, or other threats.

For instance, if an Azure resource normally only communicates with internal hosts, but suddenly it begins sending large amounts of data to an unknown external server, it could be a sign of data exfiltration. Stealthwatch Cloud would detect this behavior in real-time and alert your security team.

Continue reading

How Stealthwatch Cloud protects against the most critical Kubernetes vulnerability to-date, CVE-2018-1002105

The increasing popularity of traditional cloud computing technologies such as server-less, on-demand compute and containerized environments has made technologies like Kubernetes part of our daily vernacular as it relates to running our applications and workloads.

Kubernetes solves many of the problems with managing containers at-scale. Automation, orchestration, elasticity are a few of the major draws for organizations to leverage Kubernetes, either in the cloud, on premises, or hybrid. Kubernetes creates a network abstraction layer around the siloed containers that allows for this facilitation. Think of it as a wide open highway that allows you to route throughout the many containers that are actually performing your workloads.  From web servers to database servers, these containers are the flexible, scalable workhorses for an organization.

With great accessibility comes a drawback, however. Should an attacker gain access to a pod, a node or an internal Kubernetes service, then part or all of that cluster is at risk of compromise. Couple that with the fact that in many instances Docker containers are actually running scaled down Linux operating systems like CoreOS or Alpine Linux. Should one of those containers become exposed to the Internet (and many workloads require access to the Internet), you now have an exposed attack surface that expands along with the exposed workloads themselves.

Last week the most severe Kubernetes vulnerability discovered to-date was announced, CVE-2018-1002105. It scored a 9.8 out of a possible 10.0 on the CVSS severity score…which is unprecedented.  In a nutshell this vulnerability allows an attacker to send an unauthenticated API request to the Kubernetes API service. Despite being unauthenticated, the access request leaves a remaining TCP connection open for the API backend server. This connection then allows an attacker to exploit the connection to run commands that would grant them complete access to do anything they desire on the cluster.  Scary stuff!

This vulnerability underscores the fact that organizations need to have both the visibility to see such traffic and also the analytics to know if the traffic represents a risk or compromise. Suppose you unknowingly expose a group of Apache Kubernetes pods to the Internet to perform their intended web services and a new vulnerability is exploited on that pod, like Struts. The attacker would then have root access on the pod to perform recon, install necessary tools and pivot around the cluster. And, if they are aware of the API vulnerability, then it’s a walk in the park for them to take full control of your cluster in a matter of minutes.

Not a good day for an organization if – and more likely when – this occurs. Data theft, compute theft, skyrocketing bills….just to name a few, are immediate side effects to a takeover of this magnitude.  So how can Stealthwatch Cloud help in this scenario and similar potential exploits?

How Stealthwatch Cloud Protects Kubernetes Environments 

Stealthwatch Cloud deploys into a Kubernetes cluster via an agentless sensor that leverages Kubernetes itself to automatically deploy, expand and contract across a cluster. No user interaction is required. The solution deploys instantly to every node in a cluster and exposes every pod and the communication with those pods between internal nodes and clusters, as well as externally. This allows for an unprecedented level of visibility into everything a cluster is doing, from pods communicating to the internet to worker nodes communicating internally with the master node. We then add entity modeling which compares new behavior to previous behavior and machine learning based anomaly detection to alert on IOC’s throughout the Kill Chain to alert on over 60 indicators of suspicious activity across a cluster.

Hypothetically speaking, if one of your Kubernetes clusters were compromised, Stealthwatch Cloud would send alerts in real-time on various aforementioned activities. The tool would alert on the initial pod reconnaissance, and on connection activity once the pod was exploited. If the attacker moved towards the API server, Stealthwatch Cloud would alert on internal reconnaissance, suspicious connections to the API server itself, further data staging, data exfiltration and a variety of other alerts that would indicate a change from known good behavior across every component of a Kubernetes cluster…all in an agentless, automated, scalable solution.

Continue reading

Automated Policy & Segmentation Violation Alerting with Stealthwatch Cloud

Stealthwatch Cloud is best known for network behavioral anomaly detection and entity modeling, but the level network visibility value it provides far exceeds these two capabilities. The underlying traffic dataset provides an incredibly accurate recording for every network conversation that has transpired throughout your global network.  This includes traffic at remote locations and deep into the access layer that is far more pervasive than sensor-based solutions could provide visibility into.

Stealthwatch Cloud can perform policy and segmentation auditing in an automated set-it and forget-it fashion. This allows security staff to detect policy violations across firewalls, hardened segments and applications forbidden on user endpoints. I like to call this setting virtual “tripwires” all over your network, unbeknownst to users, by leveraging your entire network infrastructure as a giant security sensor grid. You cannot hide from the network…therefore you cannot hide from Stealthwatch Cloud.

Here is how we set this framework up and put it into action!

1. Navigate to Alerts from the main dashboard under the gear icon:

2. Click Configure Watchlists on the Settings screen:

3. Click Internal Connection Blacklist on the Watchlist Config screen:

4. Here are your options:

5. From here you’ll want to fill out the above form as such:

Name:  Whatever you’d like to call this rule, for example “Prohibited outbound RDP” or “permitted internal RDP”Source IP:  Source IP address or CIDR rangeSource Block Size:  CIDR notation block size, for example (0, 8, 16, 24, etc.)Source Ports:  Typically this is left blank as the source ports are usually random ephemeral ports but you have the option if you require a specific source port to trigger the alert.

Destination IP:  Target IP Address or CIDR range

Destination Block Size:  CIDR notation block size, for example (0, 8, 16, 24, etc.)

Destination Ports:  The target port traffic you wish to allow or disallow, for example (21, 3389, etc)

Connections are Allowed checkbox:  Check this if this is the traffic you’re going to permit.  This is used in conjunction with a second rule to specify all other traffic that’s not allowed.

Reason:  Enter a user friendly description of the intent for this rule.

6. Click Add to make the rule active.

7. Here’s an example of a set of rules both permitting and denying traffic on Remote Desktop over TCP 3389:

1. Permit rule:

2. Deny Rule:

8. Resulting Alert set:

9. Now to test this new ruleset, I will attempt two RDP connections within my Lab.  The first will be a lateral connection to another host on the 10.0.0.0/8 subnet and the second to an external IP residing on the public Internet.

10. Here is the resulting observation that triggered:

11. And the resulting Alert:

12. You can also see the observed ALLOWED traffic from my lateral RDP testing. This traffic did not trigger any observation or alert:

This policy violation alerting framework allows you to be fully accountable for all network prohibited network traffic that will inevitably transit your network laterally or through an egress point.  Firewall rules, hardening standards and compliance policies should be adhered to but how can you be certain that they are?  Human error, lack of expertise and troubleshooting can and will easily lead to a gap in your posture and Stealthwatch Cloud is the second line of defense to catch any violation the moment that first packet traverses a segment using a prohibited protocol.  It’s not a matter of IF your posture will be compromised but WHEN.

Continue reading

The Role of Visibility in SecOps

The bad guys aren’t going away.  In fact, they are getting smart, more creative, and just as determined to wreak havoc for profit as they have ever been.  The good news is Security solutions and methodologies are getting better.  Next Generation Firewalls, Malware Protection, and Access Control are not only improving, but in some cases, working in concert together.   This is good news for any security team and a lot of these solutions are part of any security stack.

But how do you know when you have been breached?  How long has that attack been roaming through the network?  Who is affected?  These are the questions that visibility helps answer.  Access Control solutions are now commonplace in letting us know the “Who”, “What”, “Where”, and “When”.  Now we need to know the “How” and “Why”.  We need to know these answers not just for the network, but for our Cloud solutions as well.

Visibility into the Conversation

Learning what “normal” behavior looks like is a great place to start. Knowing how hosts behave and interact allows you to react quickly when a host deviates from the norm.  Stealthwatch provides visibility into every conversation, baselines the network, and alerts to changes.  Not all changes are bad and this level of insight will also provide critical information for network planning.

Visibility into the Files

Since malware began, there has been a need to inspect files to ensure that they have not been compromised or the source of corruption themselves.  A downloaded file that was benign yesterday could morph into something detrimental tomorrow.  Advanced Malware Protection (AMP) does retrospective analysis such that it doesn’t just inspect a file once and moves on.  It has the ability to look back in time and see exactly when and how a file changed, what it did, who it effected.  Additionally, a file discovered to be malicious on one machine can be quarantined and an update can be sent to all machines that prevents them from ever even opening that file, now limiting the exposure to the rest of the network.

Visibility into the Threats

Since it’s not a matter if a breach will occur, but when, the ultimate goal is to limit exposure and remove the threat as quickly as possible.  Threat hunting is costly, time consuming, and necessary in getting operations back to normal.  Knowing where to begin, determining the impact, removing the threat, and ultimately protecting against it from happening again is a challenge in of itself.  The longer the threat is in the network, the more damage it will do.  AMP Visibility helps in finding the threats quickly, identifying those effected, and eliminating the threat faster than ever.  Visibility displays the entire path of the malicious event, including URL, SHA values, file information, and more.  This information effectively reduces the time spent threat hunting.

Visibility into the Internet

We are also constantly being misled and misdirected to go to sites that we shouldn’t.  Whether it’s as simple as a fat-finger or being intentionally misled, anyone can easily end up in a very dark place.  Embedded links within an email that appears legitimate brings our guard down.  The first URL you click on may be OK (think reddit.com ) but what happens as you go deeper?  Should your employees be allowed to click on a link that is two hours old?  How can I protect my employees when they are off-net?  These are questions asked every day.  Cisco Umbrella is built into the foundation of the Internet and as a DNS service, endpoints can be protected both on and off-net.  Umbrella’s Investigate lets you explore deeper into the URL to get a complete picture of everything; from where the site is hosted, who owns it, it’s reputation, and even Threat scores via integrations with AMP’s Threat Grid.  Umbrella’s view of the Internet can prevent up to 90% of threats from ever making it to the endpoint, thus making the rest of the security stack that much more efficient.

Visibility is the Key!

The bad guys only need to be successful at breaching the network once.  The good guys need to be successful EVERY time.  Firewalls, Intrusion Detection, Endpoint protection, and other security solutions are critical in handling 99% of the risks.  That’s a great number.  It’s that 1% that gets through that keeps security people awake at night and is going to cause the most harm.  Having the ability to see not just the north-south traffic, but the east-west, is vital to detecting anomalies early.  When there is an event that requires research, reducing the time it takes to get to the bottom of it and ultimately eliminating the threat quickly keeps business humming optimally.

Continue reading

Deploying Stealthwatch Cloud in a Google GKE Kubernetes Cluster

Cisco Stealthwatch Cloud has the unique ability to provide an unprecedented level of visibility and security analytic capabilities within a Kubernetes cluster. It really doesn’t matter where the cluster resides, whether on-premise or in any public cloud environment. Stealthwatch Cloud deploys as a daemonset via a yaml file on the cluster master node, ensuring that it will deploy on every worker node in the cluster and both expand and contract as the cluster’s elasticity fluctuates. It’s very simple to configure this and once it’s configured, the sensor will deploy with each node and ensure full visibility into all node, pod and container traffic. This is done via deploying with a host-level networking shim that ensures full traffic visibility into every packet that involves any container, pod or node.

How’s this done? In this guide I’m going to walk you through how to deploy Stealthwatch Cloud within the Google Cloud Kubernetes Engine or GKE.  I’m choosing this because its incredibly simple to deploy a K8s cluster for labbing purposes in a few minutes in GKE, which will allow us to focus our attention on the nuts and bolts of deploying Stealthwatch Cloud step by step into an existing K8s cluster.

The first step is to login to the GKE utility within your Google Cloud Platform console:

Create your cluster:

Click Connect to get your option to connect using the built-in console utility. Click the option for “Run in Cloud Shell”:

Click Start Cloud Shell:

You will now be brought into the GKE Cloud Shell where you can now fully interact with your GKE Kubernetes cluster:

You can check  the status of the nodes in your 3-node cluster by issuing the following command:

kubectl get nodes

You can also verify that there are currently no deployed pods in the cluster:

kubectl get pods

At this point you’ll want to reference the instructions provided in your Stealthwatch Cloud portal on how to integrate Stealthwatch Cloud with your new cluster. In the Integrations page you find the Kubernetes integration page:

First we’ll create a Kubernetes “Secret” with a Service Key as instructed in the setup steps:

Now we’ll create a service account and bind it to the read-only cluster role:

Next, create a k8s DaemonSet configuration file.  This describes the service that will run the sensor pod on each node. Save the contents below to obsrvbl-daemonset.yaml:

Save the file and then create the sensor pod via:

You can see that now we have a Stealthwatch Cloud sensor pod deployed on each of the 3 nodes. That daemonset.yaml will ensure that the pod is deployed on any new worker node replicas as the cluster expands, automatically. We can now switch over to the Stealthwatch Cloud portal to see if the new sensors are available and reporting flow telemetry into the Stealthwatch Cloud engine. Within a few minutes the sensor pods from GKE should start reporting in and when they do you’ll see them populate the sensors page as unique sensors in your Sensor List:

At this point Stealthwatch Cloud is now providing full visibility into all pods on all nodes including the K8s Master node and the full capabilities of Stealthwatch Cloud including Entity Modeling and behavioral anomaly detection will be protecting the GKE cluster.

We can now deploy an application in our cluster to monitor and protect. For simplicity’s sake we’ll deploy a quick NGINX app into a pod in our cluster using the following command:

sudo kubectl create deployment nginx --image=nginx

You can verify the status of the application along with the Stealtwatch Cloud sensors with the following kubectl command:

kubectl get pods -o wide

You’ll see in the above that I actually have 2 NGINX instances running and it’s simply because I edited the YAML file for the NGINX app to ensure that 2 replicas were running upon deployment. This can easily be adjusted to set your needs as you scale your K8s cluster.

After a few minutes you can now query your Stealthwatch Cloud portal for anything with “NGINX” and you should see the following type of results:

You’ll see both existing and non-existing NGINX pods in the search results above. This is because as the cluster expands and contracts and the pods deploy, each pod gets a unique IP Address to communicate on. The non-existent pods in the Stealthwatch Cloud search results represent previously existent pods in our cluster that were torn down to do reducing and increasing replica pods over time.

At this point you have full visibility into all of the traffic across the NGINX pods and full baselining and anomaly detection capabilities as well should any of them become compromised or begin behaving suspiciously.

Continue reading