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

Service Opportunities for Midsize/Small Service Providers Are Key to Competitive Differentiation

Competitive intensity across the service provider landscape has increased significantly over the past few years. While most pronounced in the large tier 1 service provider segment, the level of competition has recently picked up in the midsize and small communication service provider market. The competitive landscape now includes a broader set of providers such as the following:

◉ Cable providers broadening their portfolio of services beyond traditional video services and expanding into new areas like wireless

◉ Gaming companies offering their content as a service in conjunction with cloud and/or connectivity providers

◉ Electrical cooperatives emerging as the latest new entrants to the communications market as they look to diversify their business and bring broadband access solutions to rural areas

◉ Cloud providers playing an increasing role in hosting small-medium business workloads

To maintain competitiveness, midsize/small service providers must innovate at the service level and focus on key customer segments where they can provide differentiated value. This innovation will include improving the service enablement process to drive efficiencies and accelerating the time to market for new service offerings.

Improving the Service Enablement Process

Most midsize/small service providers interviewed as part of IDC’s SP Digital Readiness Survey are primarily focused on expanding their existing set of services to new customers and broadening their partner channel; these providers see such initiatives as key to expanding their customer base. However, over time, these providers will increasingly look to develop compelling new service offerings to customers. In fact, nearly 40% of midsize/small service providers indicated that the rollout of new services is an essential component of their growth strategy. These providers are either evaluating, planning, or executing a strategy to deliver new services to an expanding base of customers (see Figure 1).

Figure 1 – Midsize/Small Service Provider Growth Strategy

Question – What role does growing your business through adding new services, entering new markets, or targeting new types of customers play in your business strategy?

n = 201

Source: IDC’s SP Digital Readiness Survey, 2021

As midsize/small service providers look to offer new services to market, they are equally focused on making improvements to service enablement and provisioning by targeting process efficiencies and expanding their service portfolio to drive profitable growth. As part of this effort, midsize/small service providers are in the process of upgrading their internal systems with a focus on operational functions critical to stimulate new sales such as:

◉ Billing (monetization)

◉ Customer order management

◉ Pricing models

◉ Partner enablement

IDC believes that data accuracy, the appropriate pricing models, the incorporation of analytics at every step of the service creation process, and work with critical partners (app developers, compute/storage providers, and channel partners) are all essential steps in supporting the efforts of midsize/small service providers to offer new compelling services to their customer base.

New Service Priorities

On the service portfolio side, there are a collection of offerings that midsize/small service providers will emphasize to satisfy customer demand for secure and reliable connectivity solutions. In the enterprise segment, private cellular services, cloud-based network services and managed services will be key areas of focus for midsize/small service providers.

According to IDC’s SP Digital Readiness Survey, midsize/small service providers indicated that private cellular services, network as a service, and managed services were their top three service priorities (see Figure 2).

Figure 2 – Priorities for Expanding Existing Service Portfolio

Question – Which of the following services represent priorities to expand your services portfolio? (Select all that apply.)

n = 147 customer-facing and internal services respondents

Source: IDC’s SP Digital Readiness Survey, 2021

Private Cellular Services. 48% of midsize/small service providers cited private cellular as their top service priority; they should also look to add incremental value on top of their connectivity solutions by partnering with ISVs and bundling industry-specific solutions that address requirements of companies in specific industry segments. IDC believes there is a broad partner ecosystem developing to service the needs of midsize and small enterprises, comprised of communication service providers, managed service providers, ISVs, VARs, and cloud providers.

Network as a Service. – While network as a service (NaaS) is still in its infancy, enterprises see value in the ability to quickly procure, deploy, manage, and retire networking assets. NaaS will enable customers to select the hardware and services to transform their network, which allows for faster access to new technologies with less risk to existing operations, improved management, faster refresh cycles, and the ability to scale with a few clicks.

Managed Services. Given the avalanche of new technologies that enterprises are evaluating, the complexity associated with implementing and operating these solutions will drive demand for managed services. This will particularly be the case in the midsize and small enterprise market segment and remote branch offices of larger enterprises where there is a lack of in-house technical expertise. IDC believes that these companies will prefer to transfer the cost of network ownership to experienced third parties with scale.

Source: cisco.com

Continue reading