Intelligent alert management

The challenge

In cyber security, we all know what alert fatigue is, and we know there is no silver bullet to get out of it. In our previous incarnation, our product was guilty as well. Who wants to go through 20,000 alerts one by one? And this was just from one product.

Building a detection engine

This article is part of a series in which we will explore several features, principles, and the background behind what we consider to be the building blocks of a security detection engine within an extended detection and response (XDR) product.

In this first article, we’ll start with alert fatigue and how we avoid it through the creation of intelligent alerts.

To manage alert fatigue, we are aware of several traditional approaches. “We only pay attention to High and Critical alerts,” some have said. That certainly helps, but at the expense of bringing more problems aboard. Apart from missing a large chunk of the sometimes-notable message that the security product is trying to convey, the “inbox” of the product becomes a dump of unclosed alerts.

“In your next release, could you add elaborate filters and checkboxes so that I can mass close those alerts?” some have asked. We tried this way, but we found ourselves amidst views containing tables within tables, a very baroque system with the delicacy and simplicity on par with the space shuttle.

“We gave up and got a SIEM and a SOAR!” we heard from others. That is all fine, when one wishes to move their SOC staff from security specialist roles to engineering integrators.

To sum up, we observed that in any case, we were really trading one issue for another. Rather than trying to manage the alert fatigue problem, we switched our approach to avoiding it in the first place. We introduced Alert Fusion.

Alert Fusion

In the Alert Fusion system, the basic unit of work is the alert. Rather than having one alert per each security event, we build the alerts intelligently, to mimic the unit of work of the security analyst.

Here is an example of such a unit of work. It covers two assets, having detected an identical set of threats on both. It’s easy to see that WannaCry, SMB service discovery, and Excessive communication likely go together. While remediating these infections, one might want to have a look at the Emotet infection as well. Altogether, neglecting this this unit of work is considered a critical risk, so it easily makes it to the top of the alert list.

The second example has a single ArcadeYum Threat spanning a larger base of 78 assets. It is one of those pesky browser-altering, additional software promoting things that one might want to eradicate en masse, rather than one by one. Admittedly, it isn’t as problematic as WannaCry though, so it is considered a medium risk.

Altogether, these two alerts cover nearly a hundred significant security events and many more contextual ones. Apart from removing the need for manual correlation, we can immediately discern the nature, the breadth, and the depth of the risks presented.

To sum up, an alert serves to collate findings that the analyst might want to solve in ensemble, either by working on it as an incident or getting rid of it due to reasons of his choosing. To prioritize their work, an alert has a risk, and the alerts are ordered using this value.

The risk, as well as the grouping, are determined automatically by the system using what it knows about the detections. Now, let’s dive deeper into the basic ingredients in the cookbook: the threats and the assets.

Threats

A threat is anything we can name as a security risk. In this example, we feature Shlayer. It is important to note that we express threats in the language of threat intelligence and risk management – “what” has been detected as opposed to the technical language of detection means – “why” was it detected. We’ll cover the exact means of detection in a later article. For now, let’s assume that we somehow detected it.

A threat has a severity, in this example it is critical, which serves as a basis for the risk calculation. Threats come with factory default severities which be changed freely to suit the threat model of each customer. For example, some customers may not care as much about crypto mining on their assets when compared to other customers.

We realize that detection methods are not infallible, especially in the world of machine learning. So, we assign a confidence value when a threat is detected. Currently, it can be either high or medium. The latter means the detector is not quite sure of the detection, so the risk is dialed down.

Assets

Similarly, we organize assets into Asset Groups that bear a business value. The organization is up to the customer and their threat model. Some customers have more diverse needs, while others have more of a flat structure. Where possible, we offer an educated guess of the default value for an Asset Group.  For example, servers get a high value, while guests get a low value. In any case, the values can be changed freely. The medium business value has no impact on the risk, while others will either increase or decrease it accordingly.

Reactive system

In summary, we see that Alert Fusion presents alerts which act as units of work and are prioritized by their risk, calculated from customer-applied settings such as threat severity and asset value.

It wouldn’t be realistic to expect that all configuration, if any, was done to the system upfront. For example, a detection on a guest network might make one realize that the business value of this asset group might need to be lowered.  So, we provide the option to tweak alerts on the fly. We support a reactive workflow model.

The existing alerts may be reorganized at any time by turning a few knobs, namely the threat severity and asset value. This gives the option to explore safely. When not satisfied with the change, simply turn them back, rinse, and repeat.

Wrap-up

So, have we tackled alert fatigue successfully? As the saying goes, time will tell. It is already beginning to do so.

Since this system was introduced in 2020, we have seen a significant reduction in alerts per customer, usually in a few orders of magnitude. Our UI does not have to work as hard, in terms of checkboxes, pagination, and filtering. Consequently, more customers reach the nice-to-be-in place of a zero-alert inbox, where 100% of the alerts have been viewed and interacted with.

Source: cisco.com

Continue reading

Relevant and Extended Detection with SecureX

Al Huger spoke about Cisco’s vision of Extended Detection and Response (XDR); specifically covering the breadth of definitions in the industry and clarifying Cisco’s definition of XDR:

“A unified security incident detection and response platform that automatically collects and correlates data from multiple proprietary security components.”

He also detailed the way Cisco’s approach to XDR is founded upon our cloud-native platform SecureX. In this blog series I’m going to expand on that XDR definition and explore how extended detection and other XDR outcomes can be achieved today leveraging the SecureX platform and integrated products.

The phrase “Extended Detection” conjures up an image of multiple data elements, perhaps many of them otherwise considered low fidelity signals, all merged into a single, high-fidelity alert. This extended detection is so wonderful that an analyst can immediately access the business relevance, the risk, the root cause and the appropriate response actions; perhaps this alert is so explainable that all this can be done automatically at machine-scale. Before we get to this state of nirvana, let’s take a step back and look at the phrase “Extended Detection” and that end state. It all begins with a detection.

But is it important?

That question – “but is it important” – stems from a more fundamental one: what does this alert mean to me? In our security operations centres today, we can have a number of products that generate detections, observations, sightings, etc. that feed into our operational processes. On their own these alerts indicate something potentially of interest in the space of that security tool. For example, an Endpoint Detection and Response product such as Cisco Secure Endpoint makes the observation of a malicious file seen on a host or a Network Detection and Response product such as Cisco Secure Network Analytics makes an observation of a host downloading a suspiciously high amount of data. These alerts tell us that something happened but not what it means in the context of the environment that it fired —your environment — creating that original question: “but is it important?”

In my experience “importance” is in the eye of the beholder. What can be considered a false positive in one environment is that high-fidelity, actionable pure-gold event in another: with the only difference being the environment the alert fired in. If we revisit the notion of the OODA (Observe, Orient, Decide, Act) loop for a moment, this is the second step of Orientation, bringing into account the environment variables that when held against the initial observation accelerate the decision and action phases.

In the Orient stage we are bringing domain variables, such as the user, device, application, severity, etc., together to answer the question “but is it important?” and the essence behind what we are doing is extension: extending the observation, or that initial detection into something more. This is the empirical prioritisation of incidents that matter.

This elevation of an observation or a detection to an incident of importance is a central concept in Extended Detection and Response. The outcome that we are after is the creation of a highly actionable incident, one that is enriched with data and context about the nouns and verbs involved so that we can make an informed decision about the incident and, in an ideal world, playbook a response such that when similar incidents, with similar nouns and verbs appear, automatically trigger the correct response actions.

One of the trickiest parts of this conversation is what those variables – those nouns and verbs – are and what are the ones that matter to an organization. Some customers I’ve worked with treat endpoint events as the highest severity and highest risk, others choose MITRE Tactics, Techniques and Procedures (TTPs) as their primary objects of interest and others might prioritise around users, devices, applications and roles in an organization. This great degree of variability indicates that there must be flexibility in the methodology of incident creation, promotion and decoration.

Risk-Based Extended Detection with SecureX

Our objective is to enable a risk-based approach to incident management. This allows a user of Cisco’s security detection and response products to prioritise detections into incidents based on their own concept of risk – which as discussed, could vary organization by organization.

In Cisco SecureX we have an artifact called an Incident. The SecureX Incident is a combination of events, alerts, and intelligence concerning a possible security compromise, which drives an incident response process that includes confirmation, triage, investigation and remediation. This concept of an Incident, in combination with configuration settings in the integrated products and the investigation features of Cisco SecureX   Response will be used as the basis for our Extended Detection and enrichment in this blog series.

Today, an Incident can be created manually through an investigation or threat hunting exercise, or promoted automatically, based on configuration, from some integrated products. As a construct the Incident is built on the Cisco Threat Intelligence Module (CTIM) and has several core tenants that allow for enrichment with different variables associated with the Incident.

In the below figure for example we have an Incident that was automatically created through promotion from Cisco Secure Network Analytics. In the image below, we see a Custom Security Event “Employees to Bottling Line” with a high severity level (how the severity level was derived will be the topic of a future blog in this series).

Clicking “Investigate Incident” will launch an investigation in Cisco SecureX Threat Response , automatically enriching the Observables in the Incident (in this case consisting of two IP Addresses, a MAC Address and a username) resulting in the below enrichment. This simple investigation enriched (or extended) the incident with data associated from those observables across nine different integrated products, resulting in the below diagram.

At this point we can investigate further, determining the impact or relevancy of the sightings. But first we are going to take a Snapshot and add it to the current incident, saving the enrichment.

While this very simple process took an alert from one product, manufactured an Incident and extended it with data from another product, we haven’t yet dug into some of the fundamentals that we want to explore in this series: namely, how we can triage, prioritise and respond to detections based on risk-driven metrics and variables that matter to our organization. Future posts in this series will explore the different integrated products in SecureX and how their detections can be promoted, enriched and extended in SecureX. In the next post in this series, we will begin with the automatic promotion and triaging of endpoint events into Cisco SecureX.

Source: cisco.com

Continue reading

Cisco Secure Cloud Insights is your Eye in the Sky

In the world of cybersecurity where information holds the keys to the kingdom, there is no shortage of data generated by numerous security tools. However, there arguably remains a lack of information. Security professionals often refer to information as ‘Actionable Intelligence’ or ‘Context’. Those engaged in the trenches of cyber warfare would appreciate a more nuanced view which states that Context is the catalyst that converts Data into Intelligence. Context helps answer important questions such as How, What, Where, When and Who, but even more advanced questions such as So What and What Next, to get to the root cause and aid remediation. While context may be an easy concept to grasp, execution remains challenging.

With that context (pun intended) I am pleased to announce the launch of Cisco Secure Cloud Insights in partnership with JupiterOne. Secure Cloud Insights brings fresh and powerful capabilities to the SecureX portfolio, including comprehensive public cloud inventory and insights, relationship mapping to navigate cloud-based entities and access rights, and security compliance reporting. This new offering extends beyond traditional cloud security posture management and will enable Cisco’s security customers to effectively manage risk and reduce the attack surface of their cloud-native processes and applications.

Cisco has witnessed organizations on their digital transformation journeys grappling with IT sprawl and struggling to gain visibility into their cyber universe. Cloud Insights addresses this very pain-point by tracking and normalizing data across multi-cloud and hybrid environments. Cloud Insights provides a knowledge graph of consolidated metadata pertaining to configurations, access policies, settings, tags, rules, and more that govern interaction between entities. Entities encompass users, roles, groups, policies, databases, datastores, devices, code repositories, storage buckets (eg. AWS S3), cloud compute instances (eg. AWS EC2), containers, functions, etc. APIs ingest this data from approximately fifty pre-defined integrations covering public cloud environments, vulnerability scanners, endpoint protection and network security tools, development and code repositories, identity providers, and more. Custom integrations are also supported using SDKs and webhooks.

Figure 1: Visualization of the graph database

While the graph database of mapped interactions is one of the key pillars of Cloud Insights, the other pillar is the ease with which this rich data can be queried. A simple plain language search maps to over 550 pre-built queries, with the option to create custom queries. Queries, singly or in combination, form the basis of all outcomes, be they alerts, summary dashboards, or compliance reports. By querying against this comprehensive relationship graph, tremendous opportunities and use cases become available. Cloud Insights uses this rich context to determine an organization’s security posture, including Cloud Security Posture Management, and reduces exposure by reporting compliance gaps, thereby promoting effective cyber governance and attack surface management.

With this introduction to Secure Cloud Insights, let us examine how the service fits in an organization’s security apparatus. We are experiencing a coming together of security outcomes that serve various stakeholders, be it Security Operations, Development Operations, Application Security, Cloud Architects, or Identity and Data protection processes.

Figure 2: Interaction between various cloud-native security functions

While SecOps starts on the left with security posture and attack surface management as its entry point, DevOps start at the far right with continuous integration and continuous delivery (CI/CD) pipeline and application/API security as their main care about. As SecOps moves right and begins to influence the other stakeholders within a mature organization, DevOps shifts left to include pre-deploy checks by using runtime security inputs. Due to this evolution in operations, tooling is needed to provide end-to-end coverage, no matter who the buying center or user is in an organization. Cloud Insights is thus positioned to provide contextual visibility that encompasses and enhances observability across the entire organization.

It is for this reason that we have integrated Cloud Insights with Cisco’s security platform SecureX and intend to have it play a bigger role as a context wrapper for numerous other Cisco security services. Early research suggests force multiplier effects through interactions with SecureX’s Device Insights, and a symbiotic relationship with Cisco Secure Cloud Analytics (formerly Stealthwatch Cloud). While Secure Cloud Insights connects the dots, Secure Cloud Analytics baselines behavior by analyzing traffic flowing between those dots. Integrated together, they can surface relationship-based and anomaly-based threat vectors. Early interest has also been evinced by the market of this powerful duo’s interaction with other Cisco Secure properties such as Portshift and Kenna. With this partnership, Cisco has strengthened its position to serve our customers’ cloud native and hybrid IT security needs. It has also strengthened the Cloud component in Cisco’s SecureX Platform, as seen in the figure below.

Figure 3: Inclusion of Cloud Insights to Cisco SecureX

Source: cisco.com

Continue reading

Automating AWS with Cisco SecureX

The power of programmability, automation, and orchestration

Automating security operations within the public clouds takes advantage of the plethora of today’s capabilities available and can drive improvements throughout all facets of an organization. Public clouds are built on the power of programmability, automation, and orchestration. Pulling all of these together into a unified mechanism can help deliver robust, elastic, and on-demand services. Services that support the largest of enterprises, or the smallest of organizations or individuals, and everywhere in between.

Providing security AND great customer experience

The success of the major public cloud providers is a testament itself to the power of automation. Let’s face it, Cyber Security isn’t getting any easier, and attackers are only getting more sophisticated. When considering the makeup of today’s organizations, as well as those of the future, a few key points are worth consideration.

Read More: 500-173: Designing the FlexPod Solution (FPDESIGN)

First, the shift to a significantly remote workforce it here to stay. Post-pandemic there will certainly be a significant number of employees returning to the office. However, the flexibility so many have gotten used to, will likely remain a reality and must be accounted for by SecOps teams.

Secondly, physical locations, from manufacturing facilities and office space, to branch coffee shops, not everything has the ability to go virtual and we, as security practitioners, are left with a significant challenge. How do we provide comprehensive security, alongside seamless customer, and top-notch user experience?

Clearly the answer is automation

The SecureX AWS Relay Module consolidates monitoring your AWS environment.

Leveraging the flexibility of Cisco’s SecureX is a great place to begin your organization’s cloud automation journey. Do this by deploying the SecureX AWS Relay Module. This module immediately consolidates monitoring your AWS environment, right alongside the rest of the security tools within the robust SecureX platform. Within the module are three significant components:

◉ Dashboard tiles providing high level metrics around the infrastructure, IAM, and network traffic, as a means of monitoring trends and bubbling up potential issues.

◉ Threat Response, with features that facilitate deep threat hunting capabilities by evaluating connection events between compute instances and remote hosts, while also providing enrichment on known suspicious or malicious observables such as remote IP addresses or file hashes.

◉ Response capabilities allow for the immediate segmentation of instances as a means of blocking lateral spread or data exfiltration, all from within the Threat Response console.

The SecureX enterprise grade workflow orchestration engine offers low or no-code options for automating your AWS, environment

Customizable automaton and orchestration capabilities

The SecureX Relay Module provides some great capabilities, however there are many operations that an organization needs to perform that fall outside the scope of its native capabilities. To help manage those, and provide highly customizable automaton and orchestration capabilities, there is SecureX Orchestration. This enterprise grade workflow orchestration engine offers low or no-code options for automating your AWS, environment and many, many, more.

SecureX Orchestration operates by leveraging workflows as automation mechanisms that simply go from start-to-end and perform tasks ranging from individual HTTP API calls, to pre-built, drag and drop, operations known as Atomic Actions. These “Atomics” allow for the consumption of certain capabilities without the need to manage the underlying operations. Simply provide the necessary inputs, and they will provide the desired output. These operations can be performed with all the same programmatic logic such as conditional statements, loops, and even parallel operations.

Libraries of built-in Atomics (including for AWS) let you conduct custom operations in your cloud environment through simple drag and drop workflows.

Included with every SecureX Orchestration deployment are libraries of built-in Atomics including a robust one for AWS. From operations such as getting metrics, to creating security groups, or VPC’s, a multitude of custom operations can be conducted in your cloud environment through simple drag and drop workflows. Do you have a defined process for data gathering, or routine operations that needs to be performed? By creating workflows, and assigning a schedule, all of these operations can be completed with consistency and precision, freeing up time to address additional business critical operations.

A more effective SecOps team

By combining built in SecureX Orchestration workflows with additional custom ones critical to your organizations processes, end-to-end automation of time sensitive, business critical tasks can be achieved with minimal development. Used in conjunction with the SecureX AWS Relay module, and your organization has at its disposal a fully featured, robust set of monitoring, deployment, management, and response capabilities that can drastically improve velocity, consistency, and the overall effectiveness of any organizations SecOps team.

Continue reading

Building a Custom SecureX Orchestration Workflow for Umbrella

Improving efficiency for the Cisco team in the Black Hat USA NOC

As a proud partner of the Black Hat USA NOC, Cisco deployed multiple technologies along with the other Black Hat NOC partners to build a stable and secure network for the conference. We used Cisco Secure Malware Analytics to analyze files and monitor any potential PII leaks. We also used Meraki SM to manage over 300 iPads used around the venue for registration, as well as sales lead generation. Last but not least, we used Umbrella to add DNS level visibility, threat intelligence and protection to the entire network.

Read More: 300-620: Implementing Cisco Application Centric Infrastructure (DCACI)

Lets go over an example scenario which many customers may find themselves in. While we were in the Black Hat USA NOC, we were constantly keeping our eyes on the Umbrella security activity report, in order to recognize, investigate and work with other teams to respond to the threats.

Continuously monitoring the activity report can be taxing, especially in our case with two Umbrella organizations – one for the conference iPad deployment and another for the conference attendee network. In comes SecureX to help make our lives simpler. Using SecureX orchestration we were able to import a pre-built Umbrella workflow and easily customize it to suite our needs. This workflow pulls the activity report for a configurable list of categories, creates an incident in SecureX, notifies the team in Webex Teams and updates a SecureX dashboard tile. Let’s jump into SecureX orchestration and take a look at the workflow.

A plethora of SecureX orchestration content is available on our GitHub repo to help you find value in our automation engine in no time. At the link above, you’ll find fully built workflows, as well as building blocks to craft your own use cases. Here is what the 0023 Umbrella: Excessive Requests To Incidents workflow looks like upon importing it (shoutout to @mavander for authoring the workflow).

You can see in the variable section there are four variables, three strings and one integer. “Categories to Alert On” is a comma separated list of categories we want to be notified about, which makes it very easy to add or remove categories on the fly. In our case, we want to be notified if there is even one DNS request for any of the Security Categories, which is why we have set the “request threshold” to one.

Now that our variables are set, let’s dig into the first web service call that is made to the Umbrella API. Umbrella has three API’s:

◉ The management API

◉ The Investigate API

◉ The reporting API (which is the one we need to use to pull the activity report)

There are often minute differences when authenticating to various API’s, but luckily for us, authenticating to the Umbrella API is built into the workflow. It’s as simple as copying and pasting an API key from Umbrella into orchestration and that its. You’ll notice the Umbrella API key and secret are stored as ‘Account Keys’ in orchestration this way you can reuse the same credentials in other workflows or other API calls to Umbrella.

In this case, we are dynamically crafting the URL of /v2/organizations/<umbrella_org_id>/categories-by-timerange/dns?from=-1hours&to=now by using the Umbrella org ID from the variables above. Notice the API call is going to GET an activity report for the past hour, but it could be modified to be more or less frequently.

Now that we have a JSON formatted version of the activity report, we can use JSON path query to parse the report and construct a table with the category names and the number of requests. Using this dictionary, we can easily determine if Umbrella has seen one or more requests for a category which we want to alert on.

If the conditions are met, and there was activity in Umbrella, the workflow will automatically create a SecureX incident. This incident can be assigned to a team member and investigated in SecureX threat response, to gain additional context from various intelligence sources. However, our team decided that simply creating the SecureX incident was not enough and that a more active form of notification was necessary to ensure nothing got overlooked. Using the pre-built code blocks in SecureX orchestration, we customized the workflow to print a message in Webex teams this way the whole team can be notified and nothing will go unseen.

Here is what the message looks like in Webex teams. It includes includes the name of the category and how many requests in said category were seen in the past one hour. We scheduled the workflow to run once an hour, so this way even if we needed to step away to walk the Black Hat floor or meet with a NOC partner, we can still stay abreast to the latest Umbrella detections.

It also includes a hyperlink to the SecureX incident to make the next step of conducting an investigation easier. Using SecureX threat response we can investigate any domains detected by umbrella to get reputational data from multiple intelligence sources. In this particular example www.tqlkg[.]com showed up as ‘potentially harmful’ in the Umbrella activity report. The results of the threat response investigation show dispositions from 5 different sources including a suspicious disposition from both Talos and Cyberprotect. We can also see that the domain resolves to 6 other suspicious URLs. In a future version of this workflow this step could be automated using the SecureX API’s.

In addition to the Webex teams alert, we created a tile for notification the SecureX dashboard, which is on display for the entire NOC floor to view.

You can see in the dashboard high level statistics, which are provided from Secure Malware Analytics (Threat Grid) including “top behavioral indicators”, “submissions by threat score” “submissions by file type” as well as the “request summary” from Umbrella.

Also notice the “private intelligence” tile – this is where you can see if there were any new incidents created by the orchestration workflow. The SecureX dashboard keeps the entire Black Hat NOC well-informed as to how Cisco Secure’s portfolio is operating in the network. Adding tiles to create a custom dashboard can be done in just a few clicks. In the customize menu you will see all the integrated technologies that provide tiles to the dashboard.  Under the “private intelligence” section you can see the option to add the ‘Incident statuses and assignees’ tile to the dashboard – it’s that easy to create a customized dashboard!

I hope you enjoyed this edition of SecureX at Black Hat; and stay tuned for the next version of the workflow on GitHub, that will automatically conduct an investigation of suspicious domains and provide intelligence context directly in the Webex teams message.

Continue reading

Detect What Others Miss with CESA

With the executive order signed by the US government in the wake of recent cybersecurity attacks like SolarWinds, Colonial Pipeline, Microsoft Exchange server breach that have plagued high-value government entities and private organizations, it is very important to have security ammunition ready that can detect such attacks – one that can provide deep forensic details and visibility into your users and endpoints.

Read More: 350-901: Developing Applications Using Cisco Core Platforms and APIs (DEVCOR)

In the SolarWinds breach, a form of supply chain attack, the attacker spent months performing undetected reconnaissance to gain deep understanding of the inner workings of the trusted IT supplier before targeting them as the means to infiltrate US government targets bypassing ransomware defense in endpoint anti-malware solutions.  The attack went undetected by many security solutions for months. New supply chain attacks are happening regularly, with many of them targeting endpoint security components directly and with many more such new techniques emerging, it is more important than ever to have a defense-in-depth endpoint strategy with forensics capabilities.

Cisco Endpoint Security Analytics (CESA) helps solve this problem and can be that security ammunition in your security infrastructure to act as an early threat warning system by providing behavior-based deep – user, endpoint and network visibility all in one place. The three components that forms the overall CESA solution are

1. Cisco’s AnyConnect Network Visibility Module (NVM) that provides unparalleled endpoint behavioural visibility

2. CESA Collector that acts as an NVM telemetry broker, converting IPFIX NVM data into SIEM consumable Syslogs

3. Analytics platform like Splunk that can transform the endpoint telemetry data into meaningful insights and alerts

Figure 1: CESA Architecture

With the latest CESA 3.1.11 release, we have added the following features that makes it even more secure as well as provide newer user and endpoint telemetry to help you detect advanced forms of attacks.

SecureX Integration

You can now unleash the full power of SecureX threat response and accelerate the time-to-value, through the SecureX CESA Relay module (Figure 2). Through the CESA module, you can perform threat investigations using sightings of observables from CESA and use SecureX for remediation and response actions as shown in Figure 3. For example, if Umbrella had categorized a certain domain with neutral reputation, through CESA, if you observe that the process which originated the traffic to this destination domain has never connected earlier, and hence indicates a malicious activity; you can now view this relationship in SecureX, through the SecureX CESA Relay module. You can then take a response action to block the domain immediately with Umbrella and other security controls in your network.

Figure 2: SecureX CESA Relay

Figure 3: Observables extracted through CESA into your SecureX Threat Response dashboard

Secure NVM Transport

With the introduction of DTLS 1.2 support in NVM, all communications between the client and the CESA collector is now encrypted and secured. Prior to this release the information was sent over plain text UDP which could be susceptible to Man-in-the-Middle (MITM) attack where an attacker had visibility into all NVM traffic between the client and the collector. With the secure DTLS connectivity to the collector, the NVM client first verifies the availability of the collector before sending the telemetry data over the encrypted channel thus preventing network sniffing, spoofing, reconnaissance and MITM type of attacks.

Figure 4: Secure NVM Transport

Trace Path of Malicious Software

CESA can now alert you when an application is being executed from illegitimate or unexpected paths by tracing such suspicious/malicious activity all the way down to the process path of the known, unknown, or modified executable. This helps in Zero-day analysis of attacks based on suspicious activity thus simplifying your investigations. With the new Process Path Investigation dashboard, you can now see the process path from where the process was executed. In the Figure 5 below you can see that that the process “svchost.exe” is being executed from a suspicions path “d1ecfbd***”.

Figure 5: Deep visibility into process path

Find Ultra-Stealthy Threats

CESA can now also provide additional visibility into process command line arguments helping you detect attack methods such as obfuscation or other malicious evasion techniques. You can now detect unusual command line arguments to exploitable executables (eg., /bin/sh, powershell.exe, wmic etc), files given as arguments to other programs as well as whole malicious script in obfuscated form being sent as command line argument to run. With the new Process Path Investigation dashboard, you can see in Figure 6 that an attacker who has compromised the root user is trying to ssh into 10.126.111.235.

Figure 6: Deep visibility into process path arguments

Logged-in User Visibility

Prior to this release, CESA reported console user as the originator of all traffic for all user processes. An attacker could SSH into a compromised endpoint and start performing malicious activity hiding his tracks behind that of the console user of the endpoint. With the new release, CESA reports logged-in user for remote sessions like RDP and SSH for processes launched through such sessions. As you can see below, the user “Raghul” is initiating a “Data hoarding” activity by having remotely logged into the DESKTOP-ONFHG3.

Figure 7: Remote logged-in user visibility

Continue reading

Threat Intelligence in SecureX: Fast, Free, or Easy (pick any three)

SecureX is Cisco’s free, acronym-defying security platform. (“Is it XDR? Is it SOAR? Does it solve the same problems as a SIEM? As a TIP?” “Yes.”) From the very beginning, one of the pillars of SecureX was the ability to consume and operationalize your local security context alongside global threat intelligence.

And to that end, SecureX includes, by default, a few very respectable threat intelligence providers:

➥ The Cisco Secure Endpoint File Reputation database (formerly AMP FileDB) composed of reputation ratings for billions of file hashes collected from multiple sources including Talos, Cisco Malware Analysis and Secure Endpoint

➥ The AMP Global Intelligence database, aka SecureX Public Intelligence, curated from several internal and open source thereat intelligence sources

➥ And, of course, the TALOS intelligence database, full of all manner of information discovered by the global TALOS research team and their advanced and often custom tooling

Also included is the Private Intelligence repository, which allow you to upload or create your own intelligence for inclusion in SecureX investigations.

But, there is a lot more to the world of threat intelligence than those three sources alone. Every research organization, whether free or paid, open or private, has their own area of focus, their own methods, their own guidelines and policies and practices, and their own view on any given threat. While it’s not true that more automatically equals better, a more complete and holistic view is often more valuable than a narrower view. That is, in fact, one of the primary design considerations for, and motivating reasons for the very existence of, SecureX itself.

And, many of our customers are already using additional sources – we knew that on day one, several years ago now, when we incorporated support for Virus Total into the first version of what would become SecureX threat response.

That was also a driving reason behind the roll out the remote relay modules last summer, that allow users to tie in arbitrary data sources. This design allows SecureX users to “roll their own” modules, deploy the code in their environments, and thereby leverage whatever they want as a resource in investigations.

Then we wrote and published a number of relays that were for specific well-known threat intelligence sources for users to deploy.

Recently, we have internalized these relays and are hosting them ourselves to simplify the way our customers incorporate them into their own SecureX environment. For Cisco-provided 3rd party relays, there is no longer a need to download, configure, and stand up a relay service.

What this does, is drastically decrease the investment in time and effort required in order to benefit from a multitude of available tools. Some of these tools are on-premises and are security controls or detection tools, but many are global threat intelligence providers – and many of those, are free to use.

As I was setting up a few of them myself, I realized how easy and fast this was – a click, perhaps a paste of an API key, another click, and it was done. Then I saw how many more there were. And I wondered… how long would it take to get 10 of these added, and how much would it change the nature of an investigation?

For this experiment, I used the following, chosen somewhat arbitrarily and listed purely in alphabetical order:

➥ APIvoid

➥ abuse IPdb

➥ CyberCrime Tracker

➥ FarSight DNSDB

➥ Google SafeBrowsing

➥ Pulsedive

➥ Shodan

➥ ThreatScore

➥ io

➥ VirusTotal

Several additional providers of threat intelligence options are available, and several of those are also free or at very low cost (literally under $5/mo in one case).

So, how fast can 10 completely free threat intel sources be added into SecureX, and how does it enhance the scope of that investigation? You can see the video detailing the results, here:

Source: cisco.com

Continue reading