Relevant and Extended Detection with SecureX, Part Two: Endpoint Detections

In part one of this series we introduced the notion of risk-based extended detection with SecureX – the idea that a user can prioritise detections into incidents based on their idea of what constitutes risk in their environments and then extend those detections with enrichments from other products. In subsequent posts we are diving deeper into different Cisco Secure detection technologies and how their respective detections can be prioritised, promoted to SecureX as incidents and extended. In this post we will look at detections from Cisco Secure Endpoint: what makes them relevant and important, the new automatic promotion feature and the triaging of endpoint events in SecureX.

What Makes an Endpoint Detection?

We’re digging into Endpoint Detections first for a Reason: Endpoint Detection and Response (EDR) solutions, like Cisco Secure Endpoint, have been central to Security Operations and Incident Response teams for years. In fact, when performing research with many of our security operations customers earlier this year we found that a majority of customers treat detections from their EDRs as their highest fidelity level and automatically put endpoint derived detections at the front of their incident response queues.

There are multiple reasons for why Endpoint Detections are so valuable to SecOps:

◉ Endpoint Detections are high fidelity:

   ◉ The nature of residing on an endpoint allows the detection system to be accurate in describing what is being seen. The observables and Indicators of Compromise (IOCs) in an endpoint detection (ex. Filename, file hash, hostname, URL) are typically accurate in what they are observing and explaining

◉ Endpoint Detections are explainable:

   ◉ Many of the detections generated by endpoint solutions link back to a file hash and threat intelligence with an explanation of what that file is and does, what the risk is to the asset that it is on, and the level of risk to the organization as a whole.

◉ Existence of Endpoint data itself provides insight:

   ◉ This intuitively obvious statement derives from the fact that the reason there is an endpoint detection in the first place is that it came from an agent that was installed on an owned asset. You don’t tend to go to the effort of installing and managing agents on unowned or non-valuable assets and on top of that in the very nature of installing the agent the asset became more valuable.

Just because an EDR can detect something, doesn’t mean that all detections are equal: understanding what the threat is, its risk to the device it’s on, the risk to the data on the device and the risk to the rest of the organization all are factors in determining how important the detection is. One of the most common, yet most overlooked components of what makes an endpoint detection important is security policy, for example forbidden applications. Applications can be forbidden for numerous reasons, from internal policy to government regulations, but those custom detections can be the most informing and actionable to a security operations team. In the example Simple Custom Detection from Cisco Secure Endpoint below we can see adding the SHA-256 of tor.exe to a simple custom detection on the left and the occurrence of that detection on the right.

Figure 1 – Configuration of Simple Custom Detection to detect tor.exe

Figure 2 – Occurrence of detection of tor.exe

In the detection occurrence figure above, at the top right, you might notice the label “Medium” indicating the severity of the threat detected. The notion of Severity was introduced to Cisco Secure Endpoint in the fall of 2018, providing a new setting for an analyst to leverage in prioritising events.

In Cisco Secure Endpoint there are four severity tags that can be applied to a given event; these severity tags are assigned by Cisco threat research team based on the global threat landscape knowledge and are continuously tuned to maintain a high level of accuracy. Since their introduction, we have found the below security events to be very useful in allowing Cisco Secure Endpoint customers to prioritise events and sort their inboxes using the severity tag and what it indicates:

◉ Critical – involving known malware families identified with very high precision

◉ High – generic malicious behaviors and generic malware, not attributed to a particular family

◉ Medium and Low – possibly malicious or risky detections, that could indicate about a potential compromise or degraded security posture

A new feature of both Cisco Secure Endpoint and Cisco SecureX is the ability to have Critical and High Cisco Secure Endpoint events automatically promoted as Incidents in Cisco SecureX Threat Response, allowing for the extension and prioritisation of Cisco Secure Endpoint detections.

Extending an Endpoint Detection:

In addition to the ability to automatically promote Critical and High Secure Endpoint events into Threat Response as Incidents is the creation of the notion of a High Impact Incident in Threat Response. The High Impact Incident List, an example seen below, are Incidents that are perceived to be of the highest criticality and importance to a security operations center. You will note in the screenshot below that there are two Incidents that appear in the High Impact Incident List and an additional 6,063 as Other Incidents: this is the process of identifying those incidents that are deemed to be the most critical, highest risk to the organization. In its first iteration the incidents that make their way onto the High Impact Incident list are those that are promoted from Cisco Secure Endpoint. As previously mentioned, we’ve found that Security Operations Centers tend to prioritise endpoint detections for numerous reasons.

In the above figure you might notice that labels “Enriched” and “Enriching” next to the two Incidents in the High Impact Incident list. Another recent enhancement is the automatic enrichment (or extension) of the incidents that are in the High Impact Incident List. What is happening behind the scenes is Cisco Threat Response is searching all integrated products for additional details about the attributes in the incident.

As we explored in the first part of this series, in the Orient stage of the OODA loop you are enriching or extending a detection. Potentially more important than the details about the file involved in the endpoint detection are the external factors such as:

◉ What role does this device have in my organization?

◉ Who is the user on the device?

◉ What other devices might be involved in the incident?

◉ What external knowledge is there of the threat?

◉ How often is this threat seen?

And, any other detail that might be used to assess the business risk of the detection.

By automatically enriching these High Impact Incidents with data from other integrated products we are shortening the Orient step portion of the OODA loop considerably, speeding up that mean-time-to-respond.

Once it has finished enriching, if we click on the top Incident in the High Impact Incident list and then on Linked References, we can see the Snapshot that was created during the enrichment process and that there were nine different observables investigated across multiple data sources integrated with SecureX Threat Response.

Opening the automatically created Snapshot takes us to an investigation in Cisco SecureX Threat Response. We can quickly see that not only the original device – w7-hoser – is involved but also another device on the network – w7-darrin – and that both have communicated to the same known malicious external IP addresses. If you look closely at the SHA-256 in the centre of the image you might notice that it is the same SHA-256, for tor.exe, that we used earlier to create a Simple Custom Detection.

From here we have a wealth of information for a given High Impact Incident:

◉ We know the hosts involved

◉ We know they are using banned applications

◉ We know some external threat intelligence

And, we can use that information to quickly make a decision that would frame our response action, quickly tightening our OODA loop.

In this post we’ve reviewed some concepts behind what makes an endpoint detection, why they’re valuable, and how to leverage Cisco SecureX to automatically extend the detection and create a High Impact Incident in SecureX Threat Response. 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 behaviour detections from Cisco Secure Network Analytics into Cisco SecureX.

Source: cisco.com

Continue reading

Cisco and Intel: Next-Gen Wireless Client Visibility with Intel Connectivity Analytics!

Introducing Intel Connectivity Analytics

Cisco and Intel present a new analytics solution, Intel Connectivity Analytics, that gives granular driver-level wireless client insights for any client using the latest Intel driver and wireless chipsets while connected to a supported Cisco wireless network (visit Intel Connectivity Analytics FAQ for the SW/HW compatibility matrix). This feature significantly impacts the enterprise PC vertical, where Intel Wi-Fi 6/6E chipsets make up the majority of the market share. With the Intel Connectivity Analytics capability built directly into the Intel wireless drivers, it eliminates the need to install any client-side agent, enabling this feature to be leveraged in even non-corporate settings.

More than just telemetry, Intel Connectivity Analytics provides intelligent reports that allow network administrators to understand what to do next for any problem and ensure a great user experience in even the most complex wireless deployments by addressing the use cases in Figure 1 below.

Figure 1. Intel Connectivity Analytics Use Cases

Six Intelligent Reports to Solve All Your Problems

Intel Connectivity Analytics generates six reports (Figure 2) in real-time based on information forwarded by wireless clients to the AP and then Cisco Catalyst controller or Meraki Dashboard that directly addresses the use cases depicted in Figure 1.

Note: Station information, Neighboring AP, and Failed AP reports are generated at client association, while others are triggered when the situation arises.

Figure 2. Intel Connectivity Analytics Reports Details

Identifying out-of-date Driver, Validating New Drivers, and Identifying Hardware issues:

The Station Information report provides network administrators with driver-level client information that would not have been available in typical telemetry. This additional information allows network administrators to pinpoint the specifications such as software driver or hardware model that clients experiencing poor Wi-Fi are on and target just them.

Figure 3. Identifying Hardware Issues with Intel Connectivity Analytics

Figure 4. Station information or Device Classifier WebUI Output on the Catalyst 9800 Controller

Outdated wireless drivers can also be a common culprit for a poor wireless experience. The station information report gives network administrators peace of mind when rolling out software updates knowing they have complete visibility on the Catalyst or Meraki controller.

Figure 5. Identifying Out of Date Drivers (Left) & Validating New Drivers (Right) with Client Connectivity Analytics

Troubleshooting Roaming:

When a client roams, it’s entirely a wireless client’s decision to do so, and the network has little to no visibility into the reason. Thanks to Intel Connectivity Analytics, we have reports that will share these insights with reason codes such as Low RSSI, 11v Recommendations, Missed Beacons, and Better AP. Based on these insights, a network administrator can determine whether the suspicious client roam was for a legitimate reason or not.

Figure 6. Troubleshooting Roaming with Client Connectivity Analytics

Figure 7. Roaming Scenario Report WebUI Output on the Catalyst 9800 Controller

Identifying Poor Connectivity:

When a wireless client’s RSSI falls below a certain threshold, a Low RSSI report will be generated to alert network administrators about possible coverage holes. These issues can then be proactively addressed by increasing the Tx power on an AP, deploying additional APs, and monitoring if more Low RSSI reports are generated.

Figure 8. Identifying Poor Connectivity with Client Connectivity Analytics

Identifying Misbehaving APs:

Intel Connectivity Analytics supported clients will report if an AP is broadcasting invalid IEs in their beacons, probes, and association responses that would cause connectivity and security concerns. In fact, failed AP reports will even go deeper at the packet level and highlight problematic authentication frames, association frames, or missing response frames.

Intel Connectivity Analytics can even detect rogue AP behavior with the Unknown AP report, which is used to identify and flag rogue BSSID’s (BSSIDs that are not part of an earlier neighbor report)

Figure 9. Identifying Misbehaving APs with Client Connectivity Analytics

Figure 10. Unknown AP Report CLI Output on the Catalyst 9800 Controller

How Does It Work?

Intel Connectivity Analytics uses a Cisco Catalyst 9800 series controller and Catalyst 9100 access point topology from the Cisco Enterprise Network side. The controller enables the features by default on a per WLAN basis. Intel Connectivity Analytics supported client sends the driver-level telemetry back to the access point, which is then processed and presents users with intelligent reports and insights.

Figure 11. Intel Connectivity Analytics Topology

For a technical understanding, refer to the following points:

1. All Intel Connectivity Analytics packet exchanges are protected using PMF for security purposes.

2. Cisco network running IOS XE 17.6.1 or later with the feature enabled will advertise Intel Connectivity Analytics feature support in the Beacon frames.

3. Supported Intel clients will detect and begin forwarding telemetry periodically via a protected Action frame.

As you can see, Intel Connectivity Analytics provides network administrators with granular client-side telemetry in an agentless package at a level never seen in the past. With its wide range of use cases, minimum day 0 requirements, there’s no reason why you wouldn’t leverage such a powerful wireless analytics solution! Take the wireless experience of your network to the next level with Intel Connectivity Analytics today!

Source: cisco.com

Continue reading

Building a Scalable Security Architecture on AWS with Cisco Secure Firewall and AWS Gateway Load Balancer

Comprehensive cloud support is essential when agile and efficient security at scale is required. With Cisco Secure Firewall Threat Defense 7.1, we have added support for the AWS Gateway Load Balancer (GWLB) to drive simple, agile, and efficient security in the cloud. This integration simplifies insertion of Cisco Secure Firewall in AWS with Geneve protocol (RFC 8926) encapsulation. It makes architectures more scalable, in part by removing the need for source network address translation (SNAT) in the traffic path. Let’s consider a few common use cases where this new capability makes a difference.

Use-case: Ingress and Egress traffic inspection

Figure 1 below shows a scalable architecture for protecting ingress traffic using Cisco Secure Firewall and AWS Gateway Load Balancer. This architecture recommends creating an appliance VPC with an AWS Gateway Load Balancer and Cisco Secure Firewall virtual appliances in the backend pool of the gateway load balancer. Gateway load balancers talk to these firewalls using Geneve encapsulation, eliminating the need for SNAT, as packets have embedded virtual network interface (vni) information.

The Internet user sends traffic destined to the elastic-IP-address of a workload. Traffic hits the Internet gateway, and then it is redirected to the AWS Gateway Load Balancer Endpoint (GWLBe). The GWLBe sends traffic to the GWLB, and then to the firewall for inspection. Following inspection, the packet is then forwarded to the destination workload via GWLBe.

◉ Ingress Traffic Flow:

User -> IGW -> GWLBe -> GWLB -> Secure Firewall -> GLWB -> GWLBe -> Workload

Figure 1: Centralized AWS Gateway Load Balancer deployment (ingress traffic flow)

Figure 2 shows a scalable architecture for protecting outbound traffic using Cisco Secure Firewall and AWS Gateway Load Balancer. In this Cisco Validated Design, we recommend creating an appliance VPC with a Gateway load balancer and Cisco Secure Firewalls in the backend pool of gateway load balancer. Gateway load balancers talk to these firewalls using Geneve encapsulation.

The workload sends traffic to the Internet. Based on the route table, traffic is routed to GWLBe. Once traffic reaches the gateway load balancer endpoint, it forwards traffic to the gateway load balancer in the appliance VPC. The gateway load balancer then forwards the traffic to Cisco Secure Firewall. Once inspection is complete, the firewall forwards the traffic back to the GWLB. Once the traffic reaches the GWLB, it sends it back to the GWLBe, directing the traffic to the Internet.

◉ Egress Traffic Flow:

Workload-> GWLBe -> GWLB -> Secure Firewall -> GLWB -> GWLBe -> Internet

Figure 2: Centralized AWS Gateway Load Balancer deployment (egress traffic flow)

IGW1-RT: This route table is associated to Internet Gateway (IGW1) and there is a route for application subnet (10.81.100.0/24) point to the gateway load balancer endpoint (GWLBEP).

GWLBEPsubnet1-RT: This route table is associated to GWLBEPsubnet1 and there is a default route that points to the Internet Gateway (IGW).

AppSubnet1-RT: This route table is associated to AppSubnet1 and there is a default route that points to the gateway load balancer endpoint (GWLBEP1).

Firewall Configuration:

◉ Enable Firewall interface

◉ Associate security zone to firewall interface

VNI Interface configuration:

◉ Enable VNI interface and add a name for VNI interface

◉ Create and associate for Security Zone on VNI interface

◉ Enable AWS proxy

◉ Enable VTEP Interface

Use-case: Centralized deployment with AWS Transit Gateway (East/West traffic flow)

Figure 3 shows centralized security deployment architecture. In this design, AWS Transit Gateway connects application VPC to appliance VPC. Transit gateway receives traffic from application VPC and forwards the same to GWLBe (endpoint). GWLBe sends traffic to GWLB, GLWB sends the traffic to Cisco Secure Firewall. Post firewall inspection, traffic is forwarded back to the GLWB and then to the destination VPC via transit gateway.

Figure 3: Centralized deployment with AWS Transit Gateway (east/west traffic flow)

Use-case: Centralized deployment with AWS Transit Gateway (east/west traffic flow)

Figure 4 shows east/west traffic flow between customer’s Data Center and appliance VPC.

Figure 4: Centralized deployment with AWS Transit Gateway (east/west traffic flow)

Source: cisco.com

Continue reading

Cisco and Wipelot – First UWB-Based Location System with App Hosting!

Cisco and Wipelot present the first real-time location system (RTLS) with an app hosting solution using Ultra Wide-Band (UWB).

The new normal makes sensitive location detection more critical than ever before, so that your business can operate more effectively and use resources more efficiently, thus reducing costs and improving the bottom line. Imagine how powerful it would be to have a centralized dashboard showing —with 1-meter accuracy — a Real-Time Location System (RTLS) of inventory and equipment in your warehouse or manufacturing floor. The ability to evaluate how equipment is used, avoid loss or theft, and cut down on time hunting for missing items would completely change the game for any business.

While you imagine this, let me introduce to you Cisco and Wipelot’s new RTLS enterprise wireless IoT solution powered by Cisco Application Hosting and Eagle Eye. This integration is Cisco’s first Ultra-Wide-Band (UWB) solution and leverages a UWB dongle for a precise RTLS with the Cisco Catalyst 9100 series access point (AP) product line. As a background, UWB technology is radio frequency (RF) that is incredibly accurate when used for location services and can allow for approximately sub 1-meter location detection accuracy.

Leveraging UWB Technology

Cisco Catalyst 9100 Series AP with a
Wipelot UWB dongle

To leverage this UWB technology, this solution requires the following:

1. Cisco DNA Center – Used to manage the deployment and serviceability of Wipelot’s RTLS IOx Application.

2. Wiplot’s RTLS IOx Application – Deployed to the Catalyst 9100 Series AP through Cisco DNA Center to allow the AP to control the UWB dongle and communicate to the Wipelot Mobile Tag and send data to the Wipelot web dashboard.

3. Wipelot’s UWB Dongle – Inserted into the Cisco Catalyst 9100 Series AP and emits UWB RF.

4. Wipelot’s Mobile Tag – Attached to equipment or people and sends UWB location data to the Wipelot UWB dongle.

5. Wipelot’s Web Dashboard – Web UI used to visualize the location of Wipelot’s mobile tags.

When Wiplot’s RTLS IOx application has been deployed to the AP, the following topology can be referenced for how location data is sent from the mobile tags to the UWB dongle, then through the IOx application to the Wipelot web dashboard. Data structure is private and it is binary data with timing information of tags and anchors.

Data flow topology of the Eagle Eye Solution

The Wipelot web dashboard is an intuitive software that requires only minimal setup, such as uploading a floor map, entering the floor dimensions, placing the APs onto the map (highlighted in red below), as well as entering the IDs of the Wipelot mobile tags. Upon properly configuring your Wipelot web dashboard, you’ll immediately observe icons on the map (highlighted in orange below), which represent the location of your mobile tags. When your mobile tags are not moving, you’ll be able to observe an incredible 20cm location accuracy.

The web dashboard even allows for a location playback of any mobile tag, giving you the history of exactly where the tags were for any time in the past. Even while moving, this solution still guarantees an incredible 45cm location accuracy!

Since this solution is powered by Cisco Application Hosting on the Catalyst 9100 series access points, it reduces the overall cost of ownership by eliminating the need for an additional IoT overlay network specific to this solution. Powered by Cisco DNA Center, a user can have peace of mind thanks to its advanced application management capabilities, ranging from the runtime status of individual applications, detailed error logs and much more.

The Eagle Eye application hosting solution changes the RTLS IoT game by becoming Cisco’s very first integrated UWB solution in the market!

Source: cisco.com

Continue reading

Miercom study validates performance of Cisco’s SASE solution with advanced security features

Infrastructure plays an important role when it comes to transforming your branch, datacenter and cloud with SD-WAN (Software-defined WAN). This allows enterprises to leverage a combination of transport services delivering a high-quality experience from the WAN edge to cloud and increase business productivity. Any customer would want a solid infrastructure in place with no bottlenecks pertaining to network performance. Additionally, it is an icing on the cake for customers if the edge and hub devices can provide robust security features and integrated network services on demand while making the whole SD-WAN experience seamless.

Miercom recently did an independent study validating the on-box throughput performance, security features and integrated network services on the ISR 1000 series routers that are a part of Cisco’s Viptela SD-WAN solution, offering customers a single powerful device with a plethora of capabilities.

Miercom validated the on-box throughput tests on Cisco’s ISR 1000 series SD-WAN routers and its competitive counterparts in the same environment and in an unbiased fashion. Cisco’s SD-WAN routers performed consistently better by showcasing superior on-box throughput than the competition in different scenarios. Key features such as IPSec, Zone-Based Firewall, QoS and NAT were tested and validated during performance testing.

Performance of Cisco SD-WAN ISR 1000 series routers vs competition

One of the key findings during performance testing was that the competition lacked advanced security features on their SD-WAN gear offering only basic zone-based firewall with primitive allow/deny rules. Conversely, Cisco offers advanced security features including zone-based firewall, Advanced Malware protection, URL Filtering, IPS and TLS/SSL Decryption etc. making it a truly robust and powerful box to secure your WAN edge to cloud deployments. Cisco SD-WAN is all powered by the threat intelligence from Talos and is consistent with security stack in cloud with Cisco Umbrella.

vManage dashboard showcasing the advanced security policies in Cisco’s SD-WAN solution

Cisco SD-WAN routers also offer integrated Wireless services like Mobility Express for Wi-Fi, in-built LTE capabilities, Cisco Stealthwatch integration etc., making it a true full stack capable solution. Cisco ISR’s built-in Mobility Express feature allows routers to act as a virtual wireless controller with the capacity of managing 50 access points with advanced features like application visibility, rogue detection etc. On the other hand, the competition lacked the integrated Wi-Fi services feature – relying on third-party vendors for this capability.

vManage dashboard showcasing the advanced on-box security features in Cisco’s SD-WAN solution

Cisco SD-WAN also provides on-box LTE capabilities offering on-box SIM card slots on the ISR routers Conversely, the competition has limited SKUs with built-in LTE capabilities and must rely on third-party vendors which makes it more complex for the customer in terms of management and cost. Customers have a broader range of choice and management with Cisco SD-WAN’s additional wireless features that reduce cost and complexity. Another notable feature Cisco SD-WAN offers is Stealthwatch integration for visibility, threat analysis and network compliance using machine-learning detection. Competition fails to offer such advanced capabilities in a single box. Also, Cisco is the only SD-WAN provider to offer voice services on their ISR router platform.

Cisco’s simplified licensing structure eliminates the need for numerous add-on licenses and support contracts to activate features. Its tiered model reduces time, complexity, and cost for customers. Miercom validated Cisco’s tiered model as easy to activate, consume and renew. The competition’s approach to their licensing model is highly complex with expensive enablement of individual add-on features. Also, it does not provide the option for both consumption-based and subscription licensing like Cisco does.

Source: cisco.com

Continue reading

Zero Trust framework improves workforce security and productivity, while cutting support costs

Like most companies, Cisco is committed to continually improving security while simultaneously simplifying the user experience.

We’ve learned some important lessons along the way.

There are multiple points where user ID and password credentials can be potentially compromised. For example, employees sometimes chose to ignore best practices by utilizing easy-to-remember passwords such as “123456.” Others would share their Cisco passwords or use them externally for non-business-related applications—essentially utilizing their passwords everywhere.

When we relied only on the password login process, it is estimated that about 80 percent of all hacks were caused by credentials/identity theft. Other points of concern included new-hire onboarding or credentials delivery, password resets on behalf of users, password-related communications, and overall handling or management of password details. All can contribute to potential risks.

Further complicating matters, when most of our workforce went remote in early 2020, it became confusing and taxing for users to know how to access different applications. For example, some apps required a Virtual Private Network (VPN) connection, while others could be accessed directly. Like many other companies, Cisco invested in VPN expansion to support employees working from home, while also rolling out Zero Trust on a limited basis initially (more details below).

As the lines increasingly blurred between work and home life, many remote workers became frustrated at connecting via VPN and enduring the authentication process potentially multiple times a day. It can be tiring for users to keep track of which applications need VPN and which don’t – reducing their productivity. Ultimately, using a VPN when the workforce is almost fully remote can be inefficient, especially when we’re sending data back over the corporate network, only to have it eventually return to the cloud.

Zero Trust framework delivers secure, uniform user experience

As a result, Cisco decided to move from a traditional, network-based perimeter and VPN model to a Zero Trust model. Zero trust is not a single solution but a framework of solutions that verify a device, establish policy, and continually monitor device behavior. Multi-Factor Authentication is a key element of this approach. We started deploying multi-factor authentication in November 2020 for several applications, then expanded its coverage in 2021 to many additional applications, including Microsoft Office 365.

Our overall goal for Zero Trust and multi-factor authentication is to provide a secure, uniform experience while accessing applications, wherever users or applications are located. From a technical perspective, we had four objectives:

1. Implement an architecture that would allow secure, VPN-free access to some of our most-visited internal and SaaS applications

2. Validate user and device trust on a per-app basis, with an ability to set per-app access policies

3. Improve our authentication experience by reducing the burden on users

4. Build this transition seamlessly, requiring zero user action, and without any outages or distractions

Zero Trust helps us achieve these goals by incorporating user/device trust policies for remotely accessing applications. Users enjoy a “borderless experience” by accessing the network from anywhere, without having to connect through a VPN.

Instead of relying only on user ID and password credentials, Zero Trust adds a layer of protection. It leverages a user-identity certificate that is securely deployed to managed endpoints by our device management suite. This certificate then acts as the first factor of authentication, saving users the step of having to type in their username and password. This also reduces the likelihood that users will save their corporate identity and password in their browser for convenience.

After establishing user trust, the solution validates device trust and health—starting with the assumption that if a device is managed by our corporate device management platforms, then it must have a good baseline security posture. We perform an additional device health check during every authentication transaction to ensure that the device is running the latest software, screen lock, disk encryption, firewall, and anti-virus agent. This real-time check is conducted by the Duo Beyond Device Health app, which continuously operates in the device’s background.

With Zero Trust, when a user tries to log in to an application, our corporate SSO identity engine checks the user and device certificate, does a real-time health assessment of the device, and finally triggers a second-factor notification before allowing user access.

Zero Trust saves time, boosts productivity

Since Zero Trust was implemented, adoption metrics show that it is saving Cisco employees more than 410,000 VPN authentications per month. Based on Cisco IT internal analyses, it takes about 45 seconds for each VPN authentication. This represents 307,500 minutes, or 5,125 hours, saved per month – an annual savings of 61,500 hours. Assuming an average hourly cost per employee of $55, we can value this productivity improvement at $3.4 million per year for Cisco employees. This also represents an optimization of the application information traffic flowing over the company’s core network and offloaded through direct internet access.

Since incorporating controls for device health and trust at the application layer, we’ve substantially improved our ability to react to device risk. For example, we’re conducting approximately 5.76 million device health checks automatically per month. This has allowed us to identify 86,000 devices per month that users have self-remediated. That’s 86,000 potential compromises effortlessly averted.

While there were some concerns about increased support call volume when introducing device health checks for borderless access, only 0.6 percent of users have contacted our help desk for support—which is actually less than the 7 percent rate of help-desk requests for security deployment, password reset, device remediation, and support calls for authentication based on internal benchmark. We feel that the easy-to-follow remediation steps within the Duo Device Health App played a key role in minimizing our support numbers. The deployment had a minimal impact, keeping overall costs low and providing a better user experience.

Subsequently, fewer analysts have been required to provide support, leading to an estimated $500,000 per year savings in helpdesk support costs. In addition to cutting support costs and improving security, the Zero Trust Multi-Factor Authentication framework has improved productivity because users don’t need to waste time logging in to the VPN.

Figure 1. Duo Zero Trust benefits

The future of Zero Trust

Implementing Zero Trust as a critical framework and adopting a more rigorous security posture will continue providing opportunities for Cisco. For example, the remote working capabilities that Zero Trust enables has over the past two years allowed Cisco to expand access to a diverse talent pool. According to Darcie Gainer, Cisco’s Security Product Marketing Leader, the remote working capabilities with borderless access and without VPN have already allowed Cisco to grow its intern classes in 2021 and 2022.

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