When it Comes to Compliance Requirements – Topology Matters!

When I look at the evolution of network security and how IT and security practitioners have protected the network for the last 30 years, I can’t help but notice how traditional network security enforcement points (insert your favorite firewall here) are still used to secure networks and workloads. They have evolved to offer a diverse set of features (i.e., IPS, decryption, application detection) to deeply analyze traffic coming in and out of the network to protect workloads. However, while firewalls are very capable appliances, it has been proven that they are not enough to keep malicious actors at bay, especially if those actors manage to breach the firewall defenses and move laterally in the network. But why is this?

We are in the digital era, where the concept of the perimeter is no longer contained to a location or a network segment. To offset this new reality and provide a more tailored-based policy control for protecting workloads, vendors have moved security closer to the workload.

There are two approaches to do this -, using agent or agentless techniques to build a micro-perimeter around the workloads.

Which approach is the correct one to take? Well, this depends on multiple factors, including organizations, type of application, or team structure. So, let’s start untangling this.

The challenge(s)

The most direct approach to protect applications is to install software agents on every workload and call it a day. Why? Because then every workload has its own micro-perimeter, allowing access to only what is necessary.

However, it is not always possible to install a software agent. Perhaps it is a mainframe application or a legacy operating system that requires fine-grained policies due to a compliance mandate. Or application workloads that are in the cloud and the agent installation is simply not possible due to organizational constraints.

And this is not the only challenge or consideration for choosing your approach. The teams or groups that comprise any company often have different security requirements from each other, leading to the triad challenge: people, processes, and technology.

Let’s start with people (policy owner) and process (policy execution). Usually, each organization has its own set of unique requirements to protect its application workloads, and a defined process to implement those requirements in the policy. To support this, a tool (technology) is required, which must adapt to each organization’s needs and should be capable of defining a common policy across agent and agentless workloads.

To start unwrapping this, you need to ask yourself:

◉ What are we protecting?

◉ Who is the owner of the policies?

◉ How is policy execution done?

As an example:

Say you want to protect a finance application (what) using an agent-based approach (how), and the owner of the policies is the App Team/Workload Team (who). In this scenario, as long as the application doesn’t break and the team can continue to focus on coding, this is generally an acceptable approach. However, when implementing the common policy, the translation from human language to machine language tends to generate extra rules that are not necessarily required. This is a common byproduct of the translation process.

Now, let’s assume that in your organization the protection of a legacy application (what) is tasked to the Network/NetSec team (who) using an agentless enforcement approach with network firewalls (how) because in this case, it is not possible to install software agents due to the unsupported legacy operating system. As in the first example, extra rules are generated. However, in this case, these unnecessary extra rules create negative consequences because of firewall rules auditing requirements for compliance mandates, even though they are part of the common policy.

Topology as the source of truth – pushing only what is required

Cisco Secure Workload has been addressing the people, process, and technology challenges since its inception. The solution embraces both approaches – installing software agents on workloads regardless of form factor (bare-metal, VM, or container) or by using agentless enforcement points such as firewalls. Secure Workload adapts to each organization’s needs by defining the policy, such a zero trust microsegmentation policy, to effectively apply micro-perimeters to application workloads in support of the zero trust approach. All within a single pane of glass.

However, as explained in the example above, we still needed to align our policy to the compliance needs of the Network/NetSec team, only using the policy rules that are required.

To tackle the additional rules challenge, we asked ourselves, “What is the most efficient way to push policies into a network firewall using Secure Workload?”

The answer boiled down to a common concept for Network/NetSec teams – the network topology.

So how does it work?

With Secure Workload, the term topology is intrinsic to the solution. It leverages the topology concept using a construct named “Scopes”, which are totally infrastructure agnostic, as shown in Figure 1.

It allows you to create a topology tree in Secure Workload based on context, where you can group your applications and define your policy by using human intent. For example, “Production cannot talk to Non-Production” and apply the policy following the topology hierarchy.

The Scope Tree is the topology of your application workloads within the organization, but the key is that it can be shaped for different departments or organizational needs and adapted to each team’s security requirements.

The concept of mapping a workload Scope to a network firewall is called “Topology Awareness.”

Topology Awareness enables the Network/NetSec teams to map a particular Scope to a specific firewall in the network topology, so only the relevant set of policies for a given application is pushed to the firewall.

So, what does this execution look like? With the Scope mapping achieved, Secure Workload pushes the relevant policy to the Cisco Secure Firewall by way of its management platform, Secure Firewall Management Center (FMC). To maintain compliance, only the required policy rules are sent to FMC, avoiding the extra unnecessary rules because of Topology Awareness. An example of this is shown in Figure 2:

Key takeaways

Operationalizing a zero trust microsegmentation strategy is not trivial, but Secure Workload has a proven track record of making this a practical reality by adapting to the needs of each persona such as Network/NetSec admins, Workload/Apps owners, Cloud Architects, and Cloud-Native engineers – all from one solution.

With topology awareness, you can:

◉ Meet compliance and audit requirements for firewall rules

◉ Protect and leverage your current investment in network firewalls

◉ Operationalize your zero trust microsegmentation strategy using both agent and agentless approaches

Source: cisco.com

Continue reading

Provide State-of-the-Art Endpoint Protection as a Managed Service

Cisco Secure Endpoint (formerly AMP for Endpoints) provides comprehensive, cloud-based security for endpoint detection and response (EDR). This unique solution contains several detection engines powered by Cisco Talos threat intelligence to prevent, detect, respond, and block cyber threats before your systems are compromised. The capabilities of Cisco Secure Endpoint include the following:

• Next-gen antivirus protection
• Continuous behaviour monitoring of endpoints (system-level)
• Dynamic file analysis
• Endpoint isolation
• Orbital advanced search
• Threat grid cloud
• Threat hunting mapped to the MITRE ATT&CK framework

Secure Endpoint contains tools and features tailored to help Managed Security Service Provider (MSSP) Partners extend endpoint security as a service, offering managed detection and response (MDR) services. The tool that helps providers more easily manage their customers is the Secure Endpoint MSSP console.

This console gives providers a single dashboard that lists all customers (child organizations) and their provision status. After successful login with a Cisco Security Cloud Sign-On account, the admin can log into the MSSP console or directly into a child organization. Each admin can also set a default organization.

The key benefits provided to partners by using the Secure Endpoint MSSP Console include:

◉ Quick onboarding of new customers with just a few clicks

◉ Easy ability to provision, monitor, and manage trial accounts and then convert trial accounts into subscriptions

◉ Comprehensive, high-level view of the entire customer base with brief states of provisioning, payment, and compromised

◉ Ability for MSSP Partners to automate customer onboarding and reporting using the service provider set of APIs

Figure 1  Customer page from the Secure Endpoint MSSP Console

Figure 1 shows a sample customer page from the console. Detailed instructions for using the console are provided in the Cisco Secure Endpoint MSSP Console Guide. 

Integration with other security technologies and automation

Secure Endpoint APIs enable automation and communication across any expanded set of security telemetry beyond endpoints. MSSP Partners can leverage these capabilities to respond to threats completely using a comprehensive architecture whose components work together. APIs help achieve integration with other security technologies and application to enhance response capabilities. Secure Endpoint has already been integrated with many Cisco ecosystem partners.

A unique subset of Secure Endpoint APIs exists to support MSSP use cases. MSSP Partners can use these APIs to do the following:

◉ Create customers

◉ Retrieve the status for all customers

◉ Disable customer APIs

◉ Fetch the total monthly usage of an MSSP Partner

◉ Gather detailed billing information

The MSSP Partner-specific APIs are under <api_endpoint>/v1/mssp.

Move from EDR to XDR for increased visibility and improved endpoint protection

Secure Endpoint provides a solid foundation for MSSP Partners to add on other detection and response services. Secure Endpoint can detect fileless malware, ransomware, polymorphic attacks, and more by continuously monitoring all the files and applications that enter a device. The information collected enhances the detection mechanism to perform threat hunting and carry out forensic activities.

MSSP Partners can seamlessly integrate other tools into the Secure Endpoint cloud to amplify security for their customers. The recently launched Cisco XDR uses the latest technologies to provide even higher visibility by collecting and correlating threat information while using analytics and automation to help detect both current and future cyberattacks.

Figure 2  Using Secure Endpoint MSSP Console with Cisco XDR

Figure 2 shows how MSSP Partners can progress their SecOps journey. Partners would use the console for day 1 provisioning of customers, setting up the management of all the customer endpoints, and then add other detection points such as:

◉ Network detection and response (NDR) with Cisco Secure Network Analytics

◉ Email threat monitoring with Cisco Secure Email Threat defence

◉ Internet access security with Cisco Umbrella

The telemetry gathered can be put into Cisco XDR, where it is correlated to provide intelligence-based actionable outcomes.

Source: cisco.com

Continue reading

The Value of SOC2 and ISO27001 in Enhancing Customer Trust

In an era of ever-evolving cybersecurity threats, a strong security posture for your cloud-based applications is paramount. Certifications such as SOC2 and ISO27001 represent an international benchmark that demonstrate a product’s robustness in security, service resiliency, and sound data management practices. Recently, our product, Secure Email Threat Defense, successfully completed the SOC2 certification process, and I’d like to share our experience to highlight the importance of these certifications for security-conscious buyers.

To gain certification, our team had to show an accredited external auditor that Secure Email Threat Defense met or exceeded the requirements of SOC2 and ISO27001. In obtaining SOC2 Type 2 certification, we validated our adherence to the Trust Services Criteria: security, availability, and confidentiality. ISO27001 further demanded effective processes and controls to protect information systems and contained data.

These combined certifications assure our customers that Email Threat Defense:

◉ Operates in a secure, reliable, and responsible manner.

◉ Protects our customers’ information.

◉ Provides transparency in system development, deployment, and maintenance as evidenced in our SOC2 Type 2 report.

◉ Commits to independent audits that will validate the effectiveness of our controls, both procedurally and from an implementation perspective.

As part of the audit process, Email Threat Defense had to prove its commitment to internal processes and provide evidence of ongoing adherence to internal controls. Our efforts in access management, change management, business continuity, incident response, and vulnerability management were scrutinized.

In the area of access management, we showcased our commitment to best practices and granular access permissions, ensuring that customer data is protected at all times. When it comes to change management, we follow strict policies and require approval for all system changes, enabling us to deliver quality features quickly.

Our business continuity and incident response capabilities were also thoroughly reviewed. We demonstrated our service’s resiliency to upstream service failures within AWS and Azure, as well as our team’s robust incident response capabilities. In a disaster recovery scenario, we showed our ability to restore critical customer data, including Search and Reporting data.

Finally, in the realm of vulnerability management, we proved our ability to remediate vulnerabilities within industry-standard SLAs, thereby mitigating the risk of known and emerging threats.

By obtaining SOC2 and ISO27001 certifications, we have displayed our unwavering commitment to information security and to our customers, providing an additional layer of trust for our users. For security-conscious buyers, these certifications represent a reliable method for evaluating the security posture of cloud-based applications such as Email Threat Defense. These certifications are not merely symbolic badges; they indicate a level of trust that our customers can rely on  in an uncertain cybersecurity landscape. We’re proud of the work we’ve done to achieve this significant milestone and we will continue to prioritize security as we further develop, innovate, and optimize Email Threat Defense.

Source: cisco.com

Continue reading

Preparing for 2023 and what lies in store for Endpoint Security

A new year is almost upon us and as we look back on our accomplishments in 2022, we also look forward to helping our customers become more security resilient and be better prepared for 2023. As part of this forward-looking process, and with the help of Gartner Peer Insights, we surveyed 100 Security and IT professionals to understand their level of security maturity and obtain their perspective on the future.

The results of the survey, called “Gartner Peer Insights – Future of Endpoint Security” can be found here in Infographic form.

Key insights from the Survey:

◉ Many organizations are employing EDR and XDR capabilities, but few have reached full maturity.

◉ Organizations are looking for integrated platforms that support hybrid workforces while simplifying vendor management.

◉ In anticipation of the ever-increasing threat landscape, organizations are looking to highly integrated and automated endpoint security solutions.

◉ Organizations want future-proof endpoint security solutions that bolster their security resilience.

Insight Example

Regarding the first key insight, approximately two-thirds of the organizations surveyed have implemented EDR and XDR capabilities. These two capabilities are critical to detecting and eliminating threats, either before a breach has occurred or before a breach has had an opportunity to create damage.

Figure 1: Deployed endpoint security capabilities

Insight Example

Another key insight is related to endpoint vendor selection. In the survey, it’s noted that the top criterion organizations are looking for when selecting an endpoint security solution is the ability to support a hybrid workforce. This isn’t surprising given the events that have occurred over the last few years and the mix of remote workers expanding to working from home. Many organizations feel that the hybrid workforce is here to stay, in varying levels of remote workforce vs. on-premises workforce. The obvious implications directly related to the endpoint solutions are flexibility (e.g., deployment options), scalability, efficacy, resilience, and manageability, as a few examples.

Figure 2: Top Motivations when considering endpoint security

Source: cisco.com

Continue reading

More than a VPN: Announcing Cisco Secure Client (formerly AnyConnect)

We’re excited to announce Cisco Secure Client, formerly AnyConnect, as the new version of one of the most widely deployed security agents. As the unified security agent for Cisco Secure, it addresses common operational use cases applicable to Cisco Secure endpoint agents. Those who install Secure Client’s next-generation software will benefit from a shared user interface for tighter and simplified management of Cisco agents for endpoint security.

Go Beyond Traditional Secure Access

Swift Endpoint Detection & Response and Improved Remote Access

Now, with Secure Client, you gain improved secure remote access, a suite of modular security services, and a path for enabling Zero Trust Network Access (ZTNA) across the distributed network. The newest capability is in Secure Endpoint as a new module within the unified endpoint agent framework. Now you can harness Endpoint Detection & Response (EDR) from within Secure Client. You no longer need to deploy and manage Secure Client and Secure Endpoint as separate agents, making management more effortless on the backend.

Increased Visibility and Simplified Endpoint Security Agents

Within Device Insights, Secure Client lets you deploy, update, and manage your agents from a new cloud management system inside SecureX. If you choose to use cloud management, Secure Client policy and deployment configuration are done in the Insights section of Cisco SecureX. Powerful visibility capabilities in SecureX Device Insights show which endpoints have Secure Client installed in addition to what module versions and profiles they are using.

The emphasis on interoperability of endpoint security agents helps provide the much-needed visibility and simplification across multiple Cisco security solutions while simultaneously reducing the complexity of managing multiple endpoints and agents. Application and data visibility is one of the top ways Secure Client can be an important part of an effective security resilience strategy.

Source: cisco.com

Continue reading

Announcing Risk-Based Endpoint Security with Cisco Secure Endpoint and Kenna Security

With a tidal wave of vulnerabilities out there and brand-new vulnerabilities coming out daily, security teams have a lot to handle. Addressing every single vulnerability is nearly impossible and prioritizing them is no easy task either since it’s difficult to effectively focus on the small number of vulnerabilities that matter most to your organization. Moreover, the shift to hybrid work makes it harder to assess and prioritize your vulnerabilities across your endpoints with traditional vulnerability scanners.

Kenna Security maps out the vulnerabilities in your environment and prioritizes the order in which you should address them based on a risk score. We’re excited to announce that after Cisco acquired Kenna Security last year, we have recently launched an integration between Kenna and Cisco Secure Endpoint to add valuable vulnerability context into the endpoint.

With this initial integration, Secure Endpoint customers can now perform risk-based endpoint security. It enables customers to prioritize endpoint protection and enhances threat investigation to accelerate incident response with three main use cases:

1. Scannerless vulnerability visibility: In a hybrid work environment, it’s increasingly difficult for traditional vulnerability scanners to account for all devices being used. Instead of relying on IP address scanning to identify vulnerabilities in an environment, you can now use the existing Secure Endpoint agent to get a complete picture of the vulnerabilities you need to triage.

2. Risk-based vulnerability context: During incident response, customers now have an additional data point in the form of a Kenna risk score. For example, if a compromised endpoint has a risk score of 95+, there is a high likelihood that the attack vector relates to a vulnerability that Kenna has identified. This can dramatically speed up incident response by helping the responder focus on the right data.

3.Accurate, actionable risk scores: Organizations often struggle to prioritize the right vulnerabilities since most risk scores such as Common Vulnerability Scoring System (CVSS) are static and lack important context. In contrast, the Kenna Risk Score is dynamic with rich context since it uses advanced data science techniques such as predictive modeling and machine learning to consider real-world threats. This enables you to understand the actual level of risk in your environment and allows you effectively prioritize and remediate the most important vulnerabilities first.

How does the Kenna integration work?

The Kenna integration brings Kenna Risk Scores directly into your Secure Endpoint console. As an example of this integration, the computer in the screenshot below (Figure 1) has been assigned a Kenna Risk Score of 100.

Figure 1: Kenna Risk Score in the Secure Endpoint console

Risk scores can be anywhere from 0 (lowest risk) to 100 (highest risk). The score is inferred based on the reported OS version, build, and revision update information, combined with threat intelligence on vulnerabilities from Kenna.

Clicking on the actual numeric score itself brings you to a page with a detailed listing of all vulnerabilities present on the endpoint (see Figure 2 below).

Figure 2: List of all vulnerabilities on an endpoint

Each vulnerability has a risk score, an identifier, and a description that includes icons with additional details based on vulnerability intelligence from Kenna:

Active Internet Breach: This vulnerability is being exploited across active breaches on the Internet

Easily Exploitable: This vulnerability is easy to exploit with proof-of-concept code being potentially available

Malware Exploitable: There is known malware exploiting this vulnerability

All of this information is extremely valuable context during an incident investigation. Exploiting vulnerabilities is one of the most common ways malicious actors carry out attacks, so by quickly understanding which vulnerabilities are present in the environment, incident responders have a much easier time honing in on how an attacker got into their organization.

Additionally, for vulnerabilities that currently have fixes available, clicking on the green “Fix Available” button on each vulnerability displays a box with links to the applicable patches, knowledge base articles, and other relevant information (see Figure 3 below). This gives analysts the information they need to efficiently act on an endpoint.

Figure 3: Recommended fixes for each vulnerability

Who can access the Kenna integration?

Vulnerability information and Risk Scores from Kenna Security are now available in the Cisco Secure Endpoint console for:

◉ Windows 10 computers running Secure Endpoint Windows Connector version 7.5.3 and newer

◉ Customers with a Secure Endpoint Advantage or Premier tier license, including Secure Endpoint Pro

Most vulnerabilities in our customer base occur on Windows 10 workstations, so we decided to release first with Windows 10 to deliver this integration faster. We plan on adding support for other Windows versions and operating systems such as Windows 11, Windows Server 2016, 2019, and 2022 in the near future.

We hope that you find this integration useful! This is the first of many steps that we are taking to incorporate vulnerability information from Kenna Security into Secure Endpoint, and we are excited to see what other use cases we can enable for our customers.

The Cisco Secure Choice Enterprise Agreement is a great way to adopt and experience the complete Secure Endpoint and Kenna technology stack.  It provides instant cost savings, the freedom to grow, and you only pay for what you need.

Source: cisco.com

Continue reading

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

Introducing the new ‘Defending Against Critical Threats’ report

Today, we’re pleased to launch our annual Defending Against Critical Threats report. Inside, we cover the most significant vulnerabilities and incidents of 2021, with expert analysis, insights and predictions from our security and threat intelligence teams across Cisco Talos, Duo Security, Kenna Security, and Cisco Umbrella.

It’s clear that 2021 – and, indeed, the start of 2022 – has been very challenging for security defenders. To bring our Defending Against Critical Threats: Analyzing Key Incident Trends report to life, I sat down with six expert threat hunters and analysts from these teams, and asked them to tell me about their findings on one specific cybersecurity threat, or incident, from the past 12 months. Each expert chose to discuss a topic which tells us a lot about the current priorities of threat actors – below you’ll find a brief summary on some of the key themes we covered.

We also conducted a survey among 190+ security and technology leaders via PulseQA to gauge their perspectives on the current threat landscape. We found that 66% of respondents felt that the complexity and volume of cybersecurity attacks had escalated in 2021, whilst 36% felt that attacks had stayed consistent with the previous year.

In the survey, we also asked about the top threat concerns security leaders had for 2022. Ransomware came in as the top concern, with 38% of respondents choosing that option. In the report, we discuss the evolution of ransomware and how it has reached a critical level for certain bad actors, provoking a more severe and structured governmental response. You’ll read about this in Matt Olney’s (Talos’ Director of Threat Intelligence and Interdiction) section about the Colonial Pipeline attack.

Matt’s section also discusses supply chain attacks, which as Matt says, is one of the most challenging types of threats we face today. Forty-three percent (43%) of our Pulse respondents told us that they were impacted in a supply chain attack in 2021. Be sure to check out this section for advice on how to make your organization a smaller target for attackers.

Zero-day vulnerabilities came in as the second biggest concern for security practitioners, according to our survey. The report discusses the impact of Log4j with Talos’ Incident Response Practice Lead Liz Waddell, and how it has continued to cause an impact in 2022. Liz also provides a detailed seven-point action plan on how to deal with future zero-day attacks.

Additionally, we also look at the most impactful disclosed vulnerabilities of 2021 with Jerry Gamblin, Kenna’s Director of Security Research (now part of Cisco). This section is particularly helpful for defenders who wish to move to a more predictive-based, prioritized vulnerability management plan.

You’ll also read about  the impact of Emotet in Artsiom Holub’s (Senior Security Analyst for Cisco Umbrella) section. Emotet is a very powerful loader that came back from the dead in 2021 to cause a lot of destruction, and the signs are that it has some very nefarious plans for 2022.

Dealing with legacy or unintegrated security technology, or ‘security debt,’ is a topic we are very passionate about helping our customers to combat, and in this report, our Advisory CISO Dave Lewis discusses why it’s becoming an increasing target of opportunity for cyber criminals. We asked  respondents if they were dealing with security debt and to what extent; the overwhelming majority (75%) said they were – but it was manageable. Unfortunately, 13% said that it’s a huge issue for them. Dave’s section contains plenty of advice on how to address this issue in your organization.

Finally, for readers interested in reading about a day in the life of a Talos threat hunter, you’ll no doubt find Ashlee Benge’s section on the rise of macOS malware very thought-provoking.

The expert analysis you’ll read in this report highlights the crucial role of our defenders, and the capabilities that we, as an industry, have built based on the meticulous study of past attacker behavior.

The good news is that according to our Pulse respondents, the majority of cybersecurity professionals undertake regular incident response testing. Forty-one (41%) are testing their plans twice a year, and 29% are testing more than three times a year. Only 4% said they didn’t have an incident response plan in place.

If you’re a security defender looking to prioritize your focus areas and address patterns of concern, we hope that this year’s report will be helpful to you. It was put together by a dedicated group of security leaders, whose job it is to spot key incident trends.

Here’s what we cover in the new Defending Against Critical Threats:

◉ Colonial Pipeline: Moving Beyond Ransomware Thoughts and Prayers with Matt Olney, Director of Threat Intelligence and Interdiction, Cisco Talos

◉ Security Debt: An Increasing Target of Opportunity with Dave Lewis, Advisory CISO, Cisco Secure

◉ The Most Critical Vulnerabilities (You Might Not Be Thinking About) with Jerry Gamblin, Director of Security Research, Kenna Security (now part of Cisco)

◉ Log4j and How To Plan for Zero-Days with Liz Waddell, Practice Lead, Cisco Talos Incident Response

◉ What’s Emotet Doing Now? with Artsiom Holub, Senior Security Analyst, Cisco Umbrella

◉ The Rise of macOS Malware with Ashlee Benge, Lead, Strategic Intelligence and Data Unification, Cisco Talos

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

Threat Protection: The REvil Ransomware

The REvil ransomware family has been in the news due to its involvement in high-profile incidents, such as the JBS cyberattack and the Kaseya supply chain attack. Yet this threat carries a much more storied history, with varying functionality from one campaign to the next.

The threat actors behind REvil attacks operate under a ransomware-as-a-service model. In this type of setup, affiliates work alongside the REvil developers, using a variety of methods to compromise networks and distribute the ransomware. These affiliates then split the ransom with the threat actors who develop REvil.

We looked at REvil, also known as Sodinokibi or Sodin, earlier in the year in a Threat Trends blog on DNS Security. In it we talked about how REvil/Sodinokibi compromised far more endpoints than Ryuk, but had far less DNS communication. However, when revisiting these metrics, we noticed that this changed in the beginning of 2021.

Figure 1-DNS activity surrounding REvil/Sodinokibi.

 

What’s interesting in revisiting this data over an 18-month span is that while the number of endpoints didn’t rise dramatically in 2021, comparing each month to the overall averages, the amount of DNS activity did. In fact, the one noticeable drop in endpoints in December appears to coincide with the beginning of a dramatic rise in DNS activity. 

What’s notable about the initial attacks is that on many occasions, zero-day vulnerabilities have been leveraged to spread REvil/Sodinokibi. In the most recent case, attackers exploited a zero-day vulnerability in the Kaseya VSA in order to distribute the ransomware. Previously the group exploited the Oracle WebLogic Server vulnerability (CVE-2019-2725) and a Windows privilege escalation vulnerability (CVE-2018-8453) in order to compromise networks and endpoints. There have been reports of other, well-known vulnerabilities being leveraged in campaigns as well.

It’s worth noting that in the case of the campaign that leveraged the Kaseya VSA vulnerability, the threat actors behind REvil disabled the command and control (C2) functionality, among other features, opting to rely on the Kaseya software to deploy and manage the ransomware. This highlights how the malware is frequently tailored to the circumstances, where different features are leveraged from one campaign to the next.

So given how functionality varies, what can REvil/Sodinokibi do on a computer to take control and hold it for ransom? To answer this question, we’ve used Cisco Secure Malware Analytics to look at REvil/Sodinokibi samples. The screenshots that follow showcase various behavioral indicators identified by Secure Malware Analytics when it is executed within a virtualized Windows sandbox.

While the features that follow aren’t present in every REvil/Sodinokibi sample, once it is successfully deployed and launched, the result is generally the same.

Figure 2-A desktop that has been encrypted by REvil/Sodinokibi.

What follows provides an overview of how the ransomware goes about locking down a computer to hold it for ransom.

Creating a mutex

One of the first things that REvil/Sodinokibi does is create a mutex. This is a common occurrence with software. Mutexes ensure only one copy of a piece of software can run at a time, avoiding problems that can lead to crashes. However, being a unique identifier for a program, mutexes can sometimes be used to identify malicious activity.

Figure 3-REvil/Sodinokibi creating a mutex.

Once the mutex is created, the threat carries out a variety of activities. The functions that follow do not necessarily happen in chronological order—or in one infection—but have been organized into related groupings.

Establishing persistence

As is the case with many threats, REvil/Sodinokibi attempts to embed itself into a computer so it will load when the computer starts. This is often done by creating an “autorun” registry key, which Windows will launch when starting up.

The creation of run keys, like mutexes, is a fairly common practice for software. However, REvil/Sodinokibi sometimes creates run keys that point to files in temporary folders. This sort of behavior is hardly ever done by legitimate programs since files in temporary folders are meant to be just that—temporary.

Figure 4-REvil/Sodinokibi creating a run key for a temporary file.

Terminating processes and services

REvil/Sodinokibi not only establishes persistence, but it also disables and deletes keys associated with processes and services that may interfere with its operation. For example, the following two indicators show it attempting to disable two Windows services: one involved in managing file signatures and certificates, and another that looks after application compatibility.

Figure 5-REvil/Sodinokibi disabling another service.

Figure 6-REvil/Sodinokibi deleting another service.

It’s worth noting that these two behavioral indicators carry a medium threat score. This is because there are legitimate reasons that these activities might happen on a system. For example, processes and services might be disabled by an administrator. However, in this case, REvil/Sodinokibi is clearly removing these processes so that they don’t interfere with the operation of the malicious code.

Deleting backups

Many ransomware threats delete the backups residing on a system that they intend to encrypt. This stops the user from reverting files to previous versions after they’ve been encrypted, taking local file restoration off the table.

Figure 7-REvil/Sodinokibi deleting a shadow copy used in backups and restoration.

Disabling Windows recovery tools

The command that REvil/Sodinokibi uses to delete backups also includes a secondary command that disables access to recovery tools. These tools are available when rebooting a Windows computer, and disabling them further cripples a system, preventing it from easily being restored.

Figure 8-REvil/Sodinokibi disabling recovery tools.

Figure 8-REvil/Sodinokibi disabling recovery tools.

Changing firewall rules

REvil/Sodinokibi sometimes makes changes to the Windows Firewall. In this case, it turns on Network Discovery, which makes it easier to find other computers on the network and spread further.

Figure 10-REvil/Sodinokibi enabling Network Discovery.

Contacting the C2 server

To carry out various functions remotely, the threat actors behind REvil often need it to connect back to a C2 server. Each of the C2 servers listed below have been classified as high risk by Cisco Umbrella.

Figure 11-Domains flagged as High Risk by Cisco Umbrella.

When looking at these domains using Umbrella Investigate, we see that the domain is associated with REvil/Sodinokibi.

Figure 12-Information in Cisco Umbrella Investigate about a REvil/Sodinokibi domain.

Encrypting files

Once most of the previous functions have been carried out, REvil/Sodinokibi will execute its coup de grâce: encrypting the files on the drive.

Figure 13-REvil/Sodinokibi encrypting a drive.

Creating ransom notes

During this process, REvil/Sodinokibi creates additional files in the folders it encrypts. These files contain information about how to pay the ransom.

Figure 14-REvil/Sodinokibi creating ransomware notes.

Changing desktop wallpaper

Finally, REvil/Sodinokibi changes the desktop wallpaper to draw attention to the fact that the system has been compromised.

Figure 15-REvil/Sodinokibi changing the desktop wallpaper.

The new wallpaper includes a message pointing the user to the ransom file, which contains instructions on how to recover the files on the computer.

Figure 16-The ransom note created by REvil/Sodinokibi.

Since the files have been successfully encrypted, the computer is now largely unusable. Each file has a file extension that matches what is mentioned in the ransom note (.37n76i in this case).

Figure 17-Encrypted files on a compromised endpoint.

Defense in the real world

Given the variation in behaviors during infection, running REvil/Sodinokibi samples inside Cisco Secure Malware Analytics is a great way to understand how a particular version of the threat functions. However, when it comes to having security tools in place, it’s unlikely you’ll see this many alerts.

For example, when running Cisco Secure Endpoint, it’s more likely that the REvil/Sodinokibi executable would be detected before it could do any damage.

Figure 18-Detection of a REvil/Sodinokibi executable.

Figure 19-Generic ransomware detection.

Source: cisco.com

Continue reading