Threat Landscape Trends: Endpoint Security, Part 2

Part 2: LOLBins, operating systems, and threat types

Being aware of what’s occurring on the threat landscape can be a valuable tool when it comes to defending your organization. If you’re well informed, that puts you in a good position to decide how best to protect your assets and allocate resources accordingly. While it’s important to stay up to date with the latest ground-breaking attack techniques and new threats, it’s equally important to keep abreast of the overall trends.

The fact is that, for every novel technique discovered, there are countless attacks taking place in the same time frame that use well-known and well-trodden tactics. For every attack carried out by a nation state, there’s a dozen million-dollar ransomware attacks that started with a simple phishing email.

This is why watching the trends is so important: it provides a view of what you’re most likely to encounter. This is the purpose of this new blog series, Threat Landscape Trends. In it, we’ll be taking a look at activity in the threat landscape and sharing the latest trends we see. By doing so, we hope to shed light on areas where you can quickly have an impact in defending your assets, especially if dealing with limited security resources.

In Part 1, we took a look at critical severity threats and MITRE ATT&CK tactics that were spotted by the Indication of Compromise (IoC) feature in Cisco’s Endpoint Security solution. In this second part, we’re going to step back and look at a larger swath of the IoC alerts to see what’s most frequently encountered.

The methodology remains the same as in Part 1, which we provide again at the end of this blog. In a nutshell, the data presented here is similar to alerts you would see within the dashboard of Cisco’s Endpoint Security solution, only aggregated across organizations. This time we rank the IoCs that organizations have encountered grouped by particular topics. The data set covers the first half of 2020, from January 1st through June 30th.

Signal from Noise

According to Cisco’s 2020 CISO Benchmark Report, one of the biggest issues IT folks face is alert fatigue. Of the respondents that claim they suffer from such fatigue, 93 percent said they receive at least 5,000 alerts per day. In circumstances like this, it’s absolutely critical to be able to derive what’s important from what can be discarded.

As we showed in Part 1, the vast majority of alerts fall into the low and medium severity categories (35 and 51 percent, respectively). It may be tempting to discount lower severities outright. Indeed, in some circumstances, this may be the correct course of action.

For instance, some of the more common low severity IoCs, like running PsExec as an administrator or stopping the firewall with NetSh, may on occasion trigger on activities carried out by IT administration—whether or not these are considered best practices. While not an attack, these sorts of alerts may be worth having a conversation about with the IT department, when time allots.

However, the significance of an alert shouldn’t be based on the severity alone. Under some circumstances, low severity alerts can be just as concerning as a critical severity alert. The trick is to figure out the context surrounding them. What happened before and after an alert? Are there other lower-severity alerts in the same time frame? Stringing together a series of suspicious alerts can give a much clearer picture of potential attacks that may only alert on lower severity IoCs.

For example, let’s say an attacker sends a phishing email to your organization. If the recipient opens the Word attachment, a macro contained within launches a script (triggering the IoC W32.WinWord.Powershell.ioc). The script in turn runs encoded PowerShell commands (W32.PowershellEncodedBuffer.ioc) to set the stage to download further malicious code (W32.PowershellDownloadString.ioc).

This scenario is comprised entirely of low- and medium-severity IoCs. Each of these by themselves do not necessarily point to an attack, but when viewed as a string of IoCs, it’s very unlikely that these would be associated with anything but malicious activity. At the end of the day, the idea with the lower IoC categories is that they indicate activity within your environment that should be investigated, especially if IT says they didn’t do it.

With this in mind, in the metrics that follow we’ll look at medium, high, and critical-severity IoCs. This is because, while low-severity IoCs are critical when looking at a series of alerts appearing in sequence, individually they can muddy the waters when analyzing larger malicious trends across organizations. Filtering out these IoCs ensures that the activity that we’re focusing on is actual malicious activity, as opposed to a round-about administrative solution.

So, without further ado, let’s have a look at more threat landscape trends, covering LOLBins, OSes, and other threats.

LOLBins

Utilizing the tools built into operating systems is a very common attack tactic these days. Leveraging such readily available binaries decreases the chances that an attacker will be discovered, compared to custom-tailored malicious tools that can stand out. Using readily available tools for malicious activity is generally referred to as “living off the land,” and the binaries utilized are called LOLBins. 

The use of LOLBins appears to be quite common for malicious activity, based on alerts seen during the first half of 2020. In our research, 20-27 percent of the IoC alerts organizations encountered at least once in a given month were related to suspicious LOLBin activity.

Percentage of IoC alerts organizations encountered related to suspicious LOLBins.

What’s notable is the five percent jump witnessed in April. This is primarily due to activity related to an adware application called Browser Assistant. This adware generally injects JavaScript into web browsers to display advertisements. During April, Browser Assistant was seen using PowerShell to load itself into memory without launching files (using reflective DLL injection, to be specific). This is highly suspect, being a technique often used by fileless malware.

Two LOLBins in particular appear to dominate the top LOLBin IoCs seen: PowerShell and the Windows Scripting Host (covering both WScript and CScript). Both of these LOLBins facilitate the execution of scripts within the Windows operating system.

Top LOLBin IoCs

Overall, PowerShell is involved in five of the top ten IoCs seen relating to LOLBins, comprising around 59 percent of all LOLBin alerts. In many cases, PowerShell is used to download malicious code into memory or download further executables. The Windows Scripting Host is often leveraged to launch malicious files, perform reconnaissance, move throughout the network, or contact remote locations. The Windows Scripting Host made up 23 percent of all LOLBin alerts.

What’s interesting in looking at the malicious use of these native binaries is that bad actors often leverage one LOLBin to launch another. This is clear with the eighth and tenth entries in our list and can be seen in other IoCs beyond the top ten. Malicious actors likely swap LOLBins during an attack in order to hide their tracks.

Top OS IoCs

Let’s take a look at the two primary desktop operating systems, Windows and macOS, to see how attackers are targeting them.

Windows

Naturally, PowerShell makes its presence known, with appearances in three IoCs in the top ten. The Windows Scripting Host appears twice as well, showing just how prevalent LOLBins are in the Windows environment. In all, half of the top 10 IoCs on Windows use LOLBins.

Top Windows IoCs

Adware also appears quite prominently on Windows, with three adware installers and ad-injecting IoCs making the top 10. However, these IoCs should not be taken lightly for being adware. These instances are some of the more egregious adware installers, often going well beyond what is considered a legitimate install process.

Other activities of note include:

◉ The presence of The Onion Router (TOR) connections ranks highly. TOR can feasibly be used to allow encrypted traffic through firewalls, at best to get around IT policies, and worst for data exfiltration.

◉ Quietly disabling UAC via the registry is something an attacker might do in order to run malicious code that requires elevated privileges.

◉ Using NSlookup to send DNS TXT queries is a technique often used by bad actors for C2 communication.

MacOS

Adware appears quite frequently on macOS as well, comprising four of the top ten IoCs seen. What’s interesting is that LOLBins don’t appear as frequently here as they do on Windows. Instead, attackers are likely to hide their presence by disabling the security programs, excluding their files from quarantine, clearing command histories, and hiding files.

Top macOS IoCs

Threat categories

Finally, let’s home in on some specific threat types. Here is a closer look at four key types of threats currently seen on the threat landscape.

Ransomware

The most common IoC alert seen relating to ransomware is the deletion of shadow copies, which are snapshots of the file system used by the Windows operating system for backups. Ransomware threats often delete these files to prevent encrypted files from being restored from local backups. This particular IoC comprised 66 percent of all ransomware-related IoC alerts.

Top Ransomware IoCs

It’s also worth noting that ransomware often uses the Windows Scripting Host to execute a .zip file that contains malicious JavaScript. This is a technique used by malicious actors that install ransomware, such as WastedLocker. However, since such zipped JavaScript files are also used in other malicious attacks outside of ransomware, such as email campaigns for Emotet, it is not included in the list above.

Credential Stealing

The most commonly encountered credential stealing tool, Mimikatz, was featured in Part 1 of our look at Endpoint Security related trends. At 28 percent, this critical-severity, credential-dumping tool topped other regularly used techniques, likely for the all-in-one approach that the tool offers.

Apart from Mimikatz, malicious actors were seen utilizing the Findstr utility on files, digging through LSASS, and combing through the registry in order to find credentials.

Top Credential Stealing IoCs

Adware

Adware features heavily on both Windows and macOS operating systems. Adware appearing in the top five generally behave in a manner closer to malware than a simple annoyance of showing you an unexpected advertisement.

Top Adware IoCs

Cryptomining

While cryptomining doesn’t currently feature heavily in overall IoC lists, the most common activities seen include regular activity associated with cryptomining, such as submitting and requesting work from a cryptomining server or wallet-related activity. However, instances of fileless cryptominers and attempts to stop other miners feature in the top five as well.

Top Cryptomining IoCs

How to defend

While no doubt interesting, the information in this blog can also double as a blueprint for a plan of defense. This is especially important if working with limited resources, when prioritizing defensive actions where they’re most needed is critical. If you’re going to do one thing with this new information to protect your organization, focus your efforts on what consistently crops up in these lists: LOLBins.

Of course, this may be easier said than done, not only because these binaries are baked into the OS, but because many IT organizations utilize them in their daily operations. So how do you differentiate between normal operations and malicious activity? While it’s fairly obvious when some actions are being carried out by bad actors, others are not so clear.

First and foremost, it’s important to ensure you enable adequate logging on systems. The fact is you can’t pinpoint malicious activity if there’s no record of it.

It’s also important to have a clear understanding of the types of commands and activity that you can expect within these logs. Filtering out what you know is being carried out through automation or IT activities will clear out much of the noise, making it easier to drill down into what should be there.

It’s also important look for patterns. Individual activities and commands may not appear malicious on their own, but in the context of a series of commands, ran before and after, a malicious pattern may emerge. Create playbooks that address these patterns and use automation to detect when they trigger.

When it comes to what commands and activities are expected, every organization is different. Establishing your approach often requires the involvement a variety of people from different teams. Establishing those communications will not only help when building out a defensive plan, but can be critical in quickly resolving an incident if one arises.

Methodology

We’ve organized the data set in such a way as to obtain more meaningful trends. First, we’ve aggregated the data by the number of organizations that have received an alert about a particular activity, as opposed to the total number of detections in the given time frame. Charts are broken down by months. This means that an organization can be counted in each month, if they see the activity. Tables cover the full six-month period (January 1, 2020 through June 30, 2020), and organizations encountering an IoC are only counted once in these cases.

A word on privacy

Cisco takes customer privacy very seriously. While Cisco Security products can report telemetry back to us, this is an opt-in feature within our products. To further this end, we’ve gone to great lengths to ensure the data used for this blog series is anonymized and aggregated before any analysis is performed on it.

Continue reading

Cisco Secure Cloud Architecture for Azure

Workloads and applications are moving from a traditional data center to the public cloud as the public cloud provides an app-centric environment. Microsoft Azure offers critical features for application agility, faster deployment, scalability, and high availability using native cloud features. Microsoft Azure recommends tiered architecture for web applications, as this architecture separates various functions. There is the flexibility to make changes to each tier independent of another tier.

Figure1 shows a three-tier architecture for web applications. This architecture has a presentation layer (web tier), an application layer (app tier), and a database layer (database tier). Azure has a shared security model, i.e., the customers are still responsible for protecting workloads, applications, and data.

Figure 1: Azure three-tier web architecture

In addition to the native cloud security controls, Cisco recommends using security controls for visibility, segmentation, and threat protection.

Figure 2: Three key pillars of Cisco recommended architecture

Cisco recommends protecting workloads and applications using Cisco Validated Design (CVD) shown in figure 3. We focused on three-essential pillars (visibility, segmentation, and threat protection) of security validating this cloud security architecture.

This solution brings together a Cisco, Radware, and Azure to extend unmatched security for workloads hosted in the Azure environment.

◉ Visibility: Cisco Tetration, Cisco Stealthwatch Cloud, Cisco AMP for Endpoints, Cisco SecureX Threat Response, and Azure Network Security Group flow logs.

◉ Segmentation: Cisco Firepower Next-Generation Virtual Firewall (NGFWv), Cisco Adaptive Security Virtual Appliance (ASAv), Cisco Tetration, Azure Network Security Group

◉ Threat Protection: Cisco Firepower Next-Generation Virtual Firewall (NGFWv), Cisco Tetration, Cisco AMP for Endpoints, Cisco Umbrella, Cisco SecureX Threat Response, Azure WAF, Azure DDoS, Radware WAF, and Radware DDoS.

In addition to visibility, segmentation, and threat protection, we also focused on Identity and Access Management using Cisco Duo.

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

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

◉ Workload level

      ◉ Cisco Tetration: Cisco Tetration agent on Azure instances forwards “network flow and process information” this information essential for getting visibility and policy enforcement.

     ◉ Cisco AMP for Endpoints: Cisco AMP for Endpoints offers protection against Malware.

◉ VNet level

     ◉ Cisco Umbrella (VNet DNS settings): Cisco Umbrella cloud offers a way to configure and enforce DNS layer security and IP enforcement to workloads in the VNet.

     ◉ Cisco Stealthwatch Cloud (NSG flow logs): SWC consumes Azure NSG flow logs to provided unmatched cloud visibility. SWC includes compliance-related observations, and it provides visibility 

into your Azure VNet cloud infrastructure.

◉ Perimeter

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

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

     ◉ Cisco Defense Orchestrator (CDO): CDO manages Cisco NGFWv and enables segmentation and threat protection.

◉ Identity

     ◉ Cisco Duo: Cisco Duo provides MFA service for Azure console and applications running on the workloads.

◉ Unify Security View

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

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

◉ Azure Network Security Groups (NSGs): Azure NSG provides micro-segmentation capability by adding firewalls rules directly on the instance virtual interfaces. NSGs can also be applied at the network level for network segmentation.

◉ Azure Web Application Firewall (WAF): Azure WAF protects against web exploits. 

◉ Azure DDoS (Basic and Standard): Azure DDoS service protects against DDoS. 

◉ Azure Internal and External Load Balancers (ILB and ELB): Azure ILB and ELB provide load balancing for inbound and outbound traffic.

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 provide unmatched visibility, segmentation, and threat protection and help in adhering security compliances.

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

Secure Cloud for Azure – Cisco Validated Design Guide (July 2020)

For detailed information on Secure Cloud Architecture for Azure, refer to our recently published Cisco Validated Design Guide. This design guide is based on the Secure Cloud Architecture Guide. The Secure Cloud Architecture Guide explains cloud services, critical business flows, and security controls required for the cloud environment to protect workloads. This guide covers the Cisco Validated Designs for workload protection in Azure three-tiered architecture. This also includes cloud-native security controls and Radware WAF/DDoS for workload protection in the cloud.

Continue reading

Unleashing SecureX on a real Cyber Campaign

There’s so much excitement around the general availability (GA) for SecureX. Let’s take a look under the hood as the industry learns to define what we should all expect from a security platform. And while I have your attention, I am going to attempt to thoroughly explain how SecureX delivers simplicity, visibility and efficiency through a cloud-native, built-in platform with an emerging use case. Here is the problem statement – we want to investigate cyber/malware campaigns impacting your environment and if there are any identified targets by looking at historical events from your deployed security technologies. Every Cisco security customer is entitled to SecureX and I hope you find this use case walk-through helpful. I will also share a skeletal workflow – which you can either run as your own ‘playbook’ or modify to be as simple or complex as your needs merit.

Let’s set the background. Recently we have been made aware that certain Australian government owned entities and companies have been targeted by a sophisticated state-based actor. The Australian Cyber Security Centre (ACSC) has titled these events as “Copy-Paste Compromises” and have published a summary with links to detailed TTPs (tactics, techniques, procedures). The ACSC also published and is maintaining an evolving list of IOCs (indicators of compromise) which can be found here. As far as mitigations, ACSC recommends prioritizing prompt patching of all internet facing systems and the use of multi-factor authentication (MFA) across all remote access services. Also, the ACSC recommends implementing the remainder of the ASD Essential Eight controls. Cisco Security has a comprehensive portfolio of technologies that can provide advanced threat protection and mitigation at scale. My colleague Steve Moros talked about these in his recent blog. However, if you are curious like me, you would first want to understand the impact of the threat in your environment. Are these observables suspicious or malicious? Have we seen these observables? Which endpoints have the malicious files or have connected to the domain/URL? What can I do about it right now?

If you are not in Australia, don’t walk away just yet! The title ‘Copy-Paste Compromises’ is derived from the actor’s heavy use of proof of concept exploit code, web shells and other tools copied almost identically from open source. So you may see some of these in your environment even if you are not being specifically targeted by this campaign. Also you can replace the example above with any other malware/cyber campaign. Typically you will find blogs from Cisco (TALOS) or other vendors or community posts, detailing the TTPs and more importantly the IOCs. In other situations, you might receive IOCs over a threat feed or simply scrape them from a webpage/blog/post. Irrespective with minor tweaks the below process should still work for any of those sources as well. Let’s get started!

Step 1 – Threat Hunting & Response

In this step, I simply copied all the IOCs from the published csv file and put them into the enrichment search box in my SecureX ribbon. This uses SecureX threat response to parse any observables (domains, IPs, URLs, file hashes, etc) from plain text and assign a disposition to each observable. We can see there are 102 observables that have been tagged as clean (3), malicious (59), suspicious (1) and unknowns (39). The unknowns are of higher concern, as the malicious and suspicious observables would hopefully have been blocked, if my threat feeds are working in concert with my security controls. Nonetheless, unless they are of clean disposition, any sightings of these observables in an environment are worth investigating. Also the ACSC will keep adding new observables to their list, as this campaign evolves. That just shows the live nature of today’s cyber campaigns and how important it to stay on top of things! Or you can automate it all, using the workflow I describe in Step 2 a bit later in this blog.

Figure 1: Observables from Text in SecureX Dashboard

Let’s see if there are any sightings of these observables in my environment and identify any targets. I do this by clicking the “Investigate in Threat response” pivot menu option in the ‘Observables from Text’ pop-up. This brings all the observables into SecureX threat response which then queries integrated security controls (modules) from my environment. In my case, 5 modules including Umbrella and AMP, had responses. I can quickly see any historical sightings, both global, and local to my environment.

Figure 2: Threat Hunting with SecureX threat response

There are few things to take note of in the screenshot above. The horizontal bar on top breaks down the 102 observables from ACSC into 9 domains, 31 file hashes, 44 IP addresses, 6 URLs and email addresses. I can now expand to see dispositions of each of them. The Sightings section (top right) gives me a timeline snapshot of global sightings and most importantly the 262 local sightings of these observables in my environment over the last few weeks. And an important detail on the top left we have 3 targets. This means that 3 of my organization’s assets have been observed having some relationship with one or more of the observables in my investigation. I can also investigate each observable more deeply in the observables section (bottom right). The relations graph (bottom left) shows me any relationships between all the 102 observables and the 3 targets. This helps me identify ‘patient zero’ and how the threat vector infiltrated my environment and spread.

Let’s expand the relations graph to get a closer look. I can apply various filters (disposition, observable type, etc.) to figure out what is going on. I can also click on any observable or target, both in relations graph as well as anywhere else in the SecureX/Threat Response user interface‑to investigate it further using threat intelligence or pivot into related Cisco Security products for a deeper analysis. Once I have completed the analysis, I can start responding to the threat, from the same screen. With a few clicks in the SecureX/Threat Response user interface, I can block any of the observables in the respective Cisco Security products (files in Cisco AMP, domains in Cisco Umbrella, etc.) and even isolate infected hosts (in Cisco AMP) to prevent further spread. I can also go beyond the default options and trigger pre-configured workflows (explained in next section) to take action in any other security product (Cisco or 3rd party) using the power of APIs/adapters. This is the illustrated by the ‘SecureX Orchestration Perimeter Block’ workflow option in below screenshot amidst other analysis/response options.

Figure 3: Incident Response with a click

So far, using SecureX threat response, we have simplified the threat hunting and response process. We were able to take all the ACSC observables, run them through various threat feeds and historical events from our security controls, while avoiding the need to jump through each security product’s user interface. We have avoided “the swivel chair effect”, that plagues the security industry!

Step 2 – Orchestrating it all with a workflow

While we achieved a lot above using the power of APIs, what if we could further minimize the human intervention and make this an automated process. SecureX orchestrator enables you to create automated workflows to deliver further value. The workflow below can be modified for any IOC source, including the TALOS Blog RSS Feed, however in this case we are going to use the ACSC provided IOC csv file.

I’d like to credit my colleague Oxana who is deeply involved with our devnet security initiatives for the actual playbook I am about to share below. She is very comfortable with various Cisco Security APIs.

Here is the generic workflow:

Figure 4: the Workflow

The workflow itself is fairly straightforward. It uses SecureX threat response APIs for the bulk of the work. For notifications we chose Webex APIs and SMTP, but this can be replaced with any collaboration tool of choice. The steps involved are as follows:

1. Get Indicators – by making a generic http request to ACSC hosted IOC csv file (or any other source!), do some clean up and store the raw indicators as text

2. Parse IOCs – from raw text stored in step 1, using SecureX threat response Inspect API

3. Enrich Observables – with SecureX Threat Response Enrich API to find any global sightings (in my integrated threat feeds) and more importantly local sightings/targets (in my integrated security modules like Umbrella, AMP, etc.)

4. Notify – if any targets found (from local sightings). For each queried module, post the targets on Webex teams and/or send an email.

5. Case Management – by creating a new casebook the first time any targets are found. On subsequent runs keep updating the casebook if targets found.

Here are some screenshots of the workflow in SecureX orchestrator. It is a bit difficult to fit in one screen, so you get 3 screenshots!

Figure 5: Workflow in SecureX orchestrator

It is possible to further improve this workflow by adding a schedule, so that workflow runs every few hours or days. This may be useful as ACSC keeps updating the indicators regularly. Another option could be to build in response options (with or without approval) using the SecureX threat response API. These are just ideas and the possibilities are limitless. SecureX orchestrator can be used to modify this workflow to run any API action for notifications and responses, both on Cisco and 3rd party products. Simply use the built in API targets or create new ones (eg. for 3rd party products), add any variables and account keys and just drag and drop the modules to build logic into your workflow. Essentially, we have given you the power of workflow scripting in a drag and drop UI. Every environment is different and so we will leave it for the readers to improve and adapt this workflow to their individual needs. Lastly as mentioned before, you can also use this workflow for extracting observables from any other web sources and not just the ACSC Copy Paste Compromises IOC list. To achieve this just modify the “ACSC Advisory Target” under Targets.

Figure 6: Modifying the observables source

The above workflow is hosted on github here. You can import it into your own SecureX orchestrator instance as a json file. Before you go through the import process or when you run the workflow, you will need to provide and/or adjust variables like the Webex token, Webex teams room id and email account details.

Figure 7: Adding the notification variables

Lastly when you run the workflow, you can see it running live, the input and output of every module and every ‘for’ loop iteration. This allows easy troubleshooting of things from the same friendly graphical interface!

Figure 8: Running the workflow in SecureX orchestrator

After running the playbook, you should see email notifications or Webex Teams messages, indicating targets found (or not) for each queried module. You should also see a case by selecting “Casebook” on the SecureX ribbon on the SecureX dashboard.

Figure 9: Webex Teams notifications on local sightings and targets

Figure 10: Casebook in SecureX dashboard

If you are a Cisco Webex Teams customer, simply login and get your personal webex access token to use in the workflow from here. To get the room id for the Webex Teams room that will be used for notifications from the workflow, add roomid@webex.bot to the room and it will reply to you with a private message containing the room id. Oxana has documented everything needed to get the workflow going in the readme file.

Continue reading

Happy Birthday, Threat Response: Only a year old, but boy have you seen some things!

Cisco Threat Response: For security analysts, by one of their own

The work of a security analyst is arduous and time consuming but rewarding too. I know, I spent a good part of my career sitting in a seat, investigating and responding to threats in a Security Operations Center (SOC). I spent way too many hours and weekends moving from console to console piecing together information from disparate systems to investigate a single threat. The various SOCs I was part of were made up of millions of dollars in the latest, best-of-breed technologies alongside open source components and scripts that were supposed to work together but too often didn’t.

That’s why I’ve been focused on designing and building systems to make the lives of the security analyst easier and their work more effective. It’s rewarding to see the products we’ve built have a positive impact on an analyst’s abilty to do their job effectively. A year ago, we introduced a new application for security analysts to make security investigations fast and easy. It pulls content for detection and response from across the security stack: from the cloud, network, endpoint together in a central location. We call it Cisco Threat Response.

Rapid Adoption

Since we released the first version of Threat Response a year ago, it has been used in more than 3,600 SOCs, and has even added value in organizations without full blown SOCs. The feedback has been incredible and has given us so much confidence in Cisco Threat Response, we’re giving it away at no cost to existing customers. It’s included with the license for any Cisco Security product that integrates with it. As good as our Cisco Security products perform on their own, we know that they are even more effective when they’re used together. It’s all about making your SOC operations run faster: from detection, through investigation, to remediation. How? It’s all API-driven.

API-Driven

Cisco Security products have used APIs for years. The difference now is that Cisco Threat Response pulls them together so you don’t have to. With long lists of observables to investigate, Threat Response gets you immediate answers by calling both threat intelligence and our security portfolio APIs — confirming threats and showing you exactly where you’re affected — delivering a clear view of what’s happening.

Customers are excited to learn they can also utilize these APIs to integrate Threat Response directly into their existing Security Incident and Event Management systems (SIEMs) and Security Orchestration, Automation, and Response tools (SOARs). Customers even report they see Threat Response reducing the burden on their SIEMs.

And our customers seem to love this approach. One customer wrote to us “I like quickly being able to see infections on my network and this presents them in a really nice fashion…” Another said, “You cannot hit a target you cannot see. Threat Response simplifies security analysis”

Security integrations that simplify SOC operations

Picture a typical investigation that happens many times a day in SOCs around the world: A potential Emotet malware outbreak. Maybe you’ve investigated it yourself. Emotet a well-known banking trojan that attackers love, keeps coming back in fresh, new forms. The Indicators of Compromise associated with it include a very, very long list of known file hashes, distribution domains, and command-and-control IP Addresses. Investigating these observables one at a time to see if you’re affected can take hours.

Cisco Threat Response calls threat intelligence APIs to gather the all the dispositions for each one at once. Then it calls the Cisco Security products’ APIs and learns what each one knows about every observable. Cisco AMP for Endpoints knows what systems have the malicious file hashes. Cisco Umbrella knows which devices called out to malicious domains. Integrating your Email Security Appliance (ESA) lets you know who received that attachment or phishing URL and so forth until it gathers everything necessary to show you exactly what is happening in your environment.

More than a Pretty Face

Threat Response reflects years of back-end integration work by engineering. It begins and ends with a highly integrated architecture of world-class threat intelligence coupled the integration of advanced security technologies covering the attack surface across the cloud, network and endpoint. This is critical for effective, consistent detection and response across the critical points of your architecture.

Borrowing from the earlier example, an unknown file in an Emotet variant gets analyzed by our Threat Grid Malware Analysis engine and finds malicious behavior. Our architecture allows Threat Grid to share this intelligence across the entire portfolio so this file is blocked at the endpoint, in email, on the network for every customer around the world in a matter of minutes. And Threat Response shows you exactly every place where you were targeted by that file and confirms where it was blocked or detected.

Getting the Full Picture – the Relations Graph

That clear view we provide is perhaps the most compelling technology in Cisco Threat Response. By visually depicting the relationships among the observables and dispositions, the affected systems in your environment (called Targets and shown in purple), and the other systems that are related to the outbreak, you’ll know immediately whether you’re affected and how. Skip the hours and hours of investigation time.

Plus, you can take action directly from the Relations Graph. It provides actions (called Pivot Menus) from which you can continue the investigation in the other products’ consoles (taking you there seamlessly) or call their APIs directly to take action. Those Targets shown in purple? Maybe you want to quarantine those hosts through AMP for Endpoints, which you can do with a single click. Those malicious C2 domains? Maybe you want to tell Umbrella to block, at the DNS layer, everything on your network from connecting to them, which you can with another click.

Sources of Detection

Threat Response is driven by the individual Cisco Security products and threat intelligence sources that feed into it. Cisco Talos research and Threat Grid for threat intelligence, Threat Grid for static and dynamic file analysis, AMP for Endpoints for dynamic and retrospective endpoint detection and response, Email Security (the number one vector of attack), Umbrella for internet domain intelligence and blocking, and Next Generation Firewall for network detection and blocking. Threat Response brings these products together to bring you context about the events seen in your environment allowing you to further enrich this context with your own intelligence sources.

Operationalizing Threat Intelligence

One of the most popular features is the browser plug in we’ve developed that takes unstructured data from any webpage or application, finds the observables or indicators of compromise and automatically renders a verdict on that observable (clean, malicious, unknown) based on our threat intelligence. Like that Talos blog example we used earlier: one click pulls all the observables mentioned on that page without the need to manually cut and paste each one (and there are 634 observables mentioned – I had them counted!) Moreover, you can access the Threat Response pivot menu, including domain blocking, without ever leaving the page.

The best part about Threat Response is rate of innovation within the application. The endgame is better cybersecurity through better SOC operations: faster detections, simpler investigations, and immediate responses. We love what we have released to date and even more excited about our roadmap. Our engineering teams are delivering new enhancements, including new features and product integrations every two weeks. There’s much more to say about Threat Response than I can detail in a blog. I encourage you to experience it for yourself. The work of the SOC teams is too important to be tedious and increasing their efficiency will have better security outcomes for everyone.

Continue reading

New Study Shows Correlating Network and Endpoint Data is Highly Manual

We recently commissioned Forrester Consulting to survey IT security professionals to find out what their desired end state was when it came to correlating security intelligence from network and endpoint. Bringing together these two disparate threat vectors allows organizations to:

◈ Increase detection and prevention capabilities
◈ Reduce manpower and resources needed for containment (and therefore costs)
◈ Exponentially decrease remediation time

In short, these are perceived benefits as they are not really happening today. Surprisingly, most organizations reported high confidence in their current threat detection and remediation systems.

But do they really have the problem covered?

Turns out – No. Perception and reality differ in this case. Many respondents claim to have integrated systems but in practice, being able to make decisions about endpoint and network security requires considerable time and effort from teams, if the data can be used at all. This shouldn’t really come as much of a shock at all since we asked what security technologies they had implemented and what they were planning to implement. While there is no clear standout winner for what is going to be implemented, what is clear is of the 21 solutions that we inquired about, respondents are spreading their capital expenses all over the place. This is why most organizations are doing the work manually.

Too many tools, little integration, no automation

With so many different security solutions in place, it’s no wonder there is so much time spent doing manual analysis and investigation into security incidents. Earlier this summer I spoke with a lot of security professionals at the Gartner Security Summit and at Cisco Live who talked about how siloed their products were. The data produced by one tool couldn’t even be consumed by another, and the information they could correlate took forever. One conversation in particular that stands out was an incident responder from a large power company who talked about how they had taken more than 6 months to investigate a single incident because they couldn’t track back the path of infection, and identify how it was propagating through their network. This is not an uncommon story that we hear. Over the last decade so many tools have been deployed that it is now making the job harder, not easier. If only they could have a security architecture where the tools talked to each other, and correlated data automatically.

Automating data analysis for improved detection is a reality

The term “architecture” has been used so much it quite possibly is one of the few terms that requires more definition than “cloud”.  Simply put, we view an architecture as something that works together. Not a bunch of API’s that get cobbled together to push data somewhere (and eventually the API gets changed and that’s all broken…), and then the manual analysis happens, but a set of technologies, and specifically security tools, that all work together – automatically – to reduce the manual effort. This means having your endpoint detection and response solution (EDR) correlating files seen by your firewall or intrusion detection system with those analyzed your sandbox, and connect it with telemetry from the web proxy to identify associated traffic as well as command & control (CNC) infrastructure, and additional tools attackers are using – and all without you having to do anything.

While it may sound absurd, we call it Advanced Malware Protection, or AMP Everywhere. When you put the same eyes everywhere, you see everything. More visibility means a better ability to prevent advanced attacks.

For a good technical overview of how AMP works, check out this chalk talk.

Continue reading

Deep Dive into AMP and Threat Grid integration with Cisco Email Security

In this blog post, we are going to dive deeper and explain the workflows of AMP and Threat Grid integration with Cisco Email Security (applies to both Cloud Email Security and on premise Email Security Appliance), as well as help administrators refine security posture in their organizations. Let’s start with a quick recap of how file reputation, file analysis and file retrospection work together in general.

Continue reading