How To Simplify Cisco ACI Management with Smartsheet

Have you ever gotten lost in the APIC GUI while trying to configure a feature? Or maybe you are tired of going over the same steps again and again when changing an ACI filter or a contract? Or maybe you have always asked yourself how you can integrate APIC with other systems such as an IT ticketing or monitoring system to improve workflows and making your ACI fabric management life easier. Whatever the case may be, if you are interested in finding out how to create your own GUI for ACI, streamline and simplify APIC GUI configuration steps using smartsheets, and see how extensible and programmable an ACI fabric is, then read on.

Innovations that came with ACI

I have always been a fan of Cisco ACI (Application Centric Infrastructure). Coming from a routing and switching background, my mind was blown when I started learning about ACI. The SDN implementation for data centers from Cisco, ACI, took almost everything I thought I knew about networking and threw it out the window. I was in awe at the innovations that came with ACI: OpFlex, declarative control, End-Point Groups (EPGs), application policies, fabric auto discovery, and so many more.

The holy grail of networking

It felt to me like a natural evolution of classical networking from VLANs and mapped layer-3 subnets into bridge domains and subnets and VRFs. It took a bit of time to wrap my head around these concepts and building underlays and overlays but once you understand how all these technologies come together it almost feels like magic. The holy grail of networking is at this point within reach: centrally defining a set of generic rules and policies and letting the network do all the magic and enforce those policies all throughout the fabric at all times no matter where and how the clients and end points are connecting to the fabric. This is the premise that ACI was built on.

Automating common ACI management activities

So you can imagine when my colleague, Jason Davis (@snmpguy) came up with a proposal to migrate several ACI use cases from Action Orchestrator to full blown Python code I was up for the challenge. Jason and several AO folks have worked closely with Cisco customers to automate and simplify common ACI management workflows. We decided to focus on eight use cases for the first release of our application:

◉ Deploy an application

◉ Create static path bindings

◉ Configure filters

◉ Configure contracts

◉ Associate EPGs to contracts

◉ Configure policy groups

◉ Configure switch and interface profiles

◉ Associate interfaces to policy groups

Using the online smartsheet REST API

You might recognize these as being common ACI fabric management activities that a data center administrator would perform day in and day out. As the main user interface for gathering data we decided to use online smartsheets. Similar to ACI APIC, the online smartsheet platform provides an extensive REST API interface that is just ripe for integrations.

The plan was pretty straight forward:

1. Use smartsheets with a bit of JavaScript and CSS as the front-end components of our application

2. Develop a Python back end that would listen for smartsheet webhooks triggered whenever there are saved Smartsheet changes

3. Process this input data based on this data create, and trigger Ansible playbooks that would perform the configuration changes corresponding to each use case

4. Provide a pass/fail status back to the user.

The “ACI Provisioning Start Point” screen allows the ACI administrator to select the

Site or APIC controller that needs to be configured.

Once the APIC controller is selected, a drop down menu displays a list of all the use

cases supported. Select to which tenant the configuration changes will be applied,

and fill out the ACI configuration information in the smartsheet.

Selecting the checkbox for Ready to Deploy, and saving the smartsheet, will trigger a webhook event that will be intercepted by the backend code and the Ansible configuration playbook will be run.

A big advantage to using Smartsheets compared to the ACI APIC GUI is that several configuration changes can be performed in parallel. In this example, several static path bindings are created at the same time.

Find the details on DevNet Automation Exchange

You can find all the details and the public repository for this application on the DevNet Automation Exchange.

You can also find hundreds of similar use case examples in the DevNet Automation Exchange covering all Cisco technologies and verticals and all difficulty levels.

Drop me a message in the comments section if you have any questions or suggestions about this automation exchange use case.

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

SAN Congestion Innovation with Cisco DIRL

Cisco DIRL offers solutions to SAN congestion without any dependency on hosts or storage.

We announced the release of Cisco® Dynamic Ingress Rate Limiting (DIRL), a major innovation to alleviate SAN congestion. Cisco DIRL is a reality today and promises to offer a practical solution to SAN congestion from a fabric perspective without any dependency on the host or storage. If you have not had a chance to review this new innovative technology, I would recommend reviewing the video, blog, presentation, solution overview or the Interfaces Configuration Guide.

In this writeup, I will cover the core of Cisco DIRL so that you can gain a solid understanding of this new innovative technology that does not require any changes to the host or storage. I will not cover how Cisco DIRL solves congestion, please refer to the web links listed above for that information.

First let’s cover the basics.

Fibre Channel (FC) Buffer to Buffer crediting

FC is built on the premise of offering a lossless fabric tailor made for storage protocols. Lossless fabric means that the probability of frame drop inside the switches and the interconnecting links is kept to a minimum. This guarantee is important to meet the performance requirements of storage protocols like SCSI/FICON/NVMe.

While FC switches implement various schemes to avoid frame drops within the switches, the way no frame drop is achieved on links interconnecting two FC ports is through a mechanism known as Buffer to Buffer (B2B) crediting. Let me break down the B2B crediting concept:

◉ During a FC link up, the number of receive buffers on a port is exchanged as B2B credits with its peer port (during FLOGI/ACC on a F-Port and ELP/ACC on a E-port). The transmitters at either ends set a TxBB counter = number of receive buffers on the peer port.

◉ An R_RDY primitive is used to indicate the availability of one buffer on the receive side of the port sending the R_RDY.

◉ As traffic starts flowing on the link, the R_RDY is used to constantly refresh the receive buffer levels to the transmitter. At the transmitter, every transmitted frame decreases TxBB counter by 1 and every R_RDY received from the peer increases the TxBB counter by 1. If TxBB counter drops to 0, no frame can be transmitted. Any frame needing to be sent has to wait till an R_RDY is received. At the receiver end, as and when incoming frames are processed and switched out, its ready to receive another frame and an R_RDY is sent back to the sender. This control loop constantly runs bidirectionally on every FC link. It ensures the transmit end of an FC port can transmit a frame only if the receiving port has a buffer to receive the frame.

Figure 1: B2B crediting on an FC link

 

To see B2B crediting in action, take a look at a Cisco MDS switch that is switching traffic, and view the interface counters (Figure 2) that indicate the exchanged and live credits on a FC link.

Figure 2: Cisco MDS show  interface command displays B2B credits

Insight: FC Primitives are single words (4 bytes) that carry a control message to be consumed at the lower layers of the FC stack. They are not FC frames and so transmitting a R_RDY itself does not require a credit. The R_RDYs are inserted as fill words between frames (instead of IDLEs) and so do not carry an additional bandwidth penalty either.

I hope I have touched upon just the enough of the basics to introduce you to two interesting concepts unique to Cisco MDS FC ASICs that forms the foundation of CISCO DIRL technology.

1. Ingress Rate Limiter

In the Cisco MDS FC ASICs, a frame rate limiter is implemented at the receiver side of port to throttle the peer transmitting to it. The rate limiter is implemented as a leaky bucket and can be enabled on any FC port. If you never heard this term before, please review the information at Wikipedia: Leaky bucket to learn more about this technology.

The ingress buffers on the port are treated like a leaky bucket and filled by a token when a full frame is received. At the same time the tokens are leaked from the bucket at a configurable rate of ‘R’. The rate ‘R’ is programmed based on a dynamically deduced rate by the Cisco DIRL software logic.

As the bucket leaks and the received frames are switched out, R_RDYs have to be sent to the peer. The sending of the R_RDY is tied to two bucket thresholds viz. Low and High threshold as follows:

◉ If bucket occupancy < Low Threshold, R_RDY is immediately sent out.

◉ If the bucket occupancy > Low Threshold and < High threshold, R_RDY is sent with credit pacing.

◉ If the bucket occupancy > High threshold, the R_RDY is held back and will be sent out when occupancy falls below the High threshold.

In summary, an R_RDY is sent out only if the bucket has ‘leaked enough’.

2. Credit pacing

When the buffer(bucket) occupancy hits the High threshold, all R_RDYs are stalled. Eventually the leak will cause the occupancy to fall below High threshold and all the pending R_RDYs will have to be sent out. This can result in a burst of R_RDYs sent to the peer which can result in a flood of waiting frames to be transmitted, which can again result in the buffer at the receiver port to go past the High threshold. This ‘ping-pong’ effect can result in very bursty traffic when traffic rates are high. To avoid this, R_RDY pacing is employed wherein a hardware timer paces out the release of R_RDYs such that incoming traffic is smoothed out while not exceeding the rate ‘R’.

By using ingress rate limiting and credit pacing on a port the Cisco MDS ASICs will ensure that a host/storage port is only able to send out frames at a rate <= ‘R’ on that port. The below diagrams illustrate the functioning of the scheme.

A. Port buffer occupancy is below the lower threshold

Figure 3: Port buffer below Low threshold

B. Port buffer occupancy is above the high threshold

Figure 4: Port buffer above High threshold

C. Port buffer occupancy is between Low and High threshold. Host can only send at rate <= R

Figure 5: Port buffer between High and Low threshold with R_RDY pacing

Source: cisco.com

Continue reading

Why Innovation Is Key To Connecting The Next 3 Billion

In the last year, communication networks have emerged as a de facto way for people to stay connected with their family and friends and carry out their professional tasks, as lockdowns and social distancing norms made it impossible to lead normal lives. Telco network became the digital foundation for everything that needed connection for instance eEducation, eHealth, eCommerce, eRetail, etc. However, while people in urban areas have used high-speed broadband and digital platforms to stay connected during these unprecedented times, this is hardly true for rural and remote areas.

While the number of internet users continues to grow, 51% of the world’s population is still not using mobile internet, as per a recent GSMA report. It further says that if the current trends continue, more than 40% of the population in low- and middle-income countries will remain offline in 2025.

The fact is that it is incredibly challenging for the service providers to provide connectivity in rural areas. The high cost of setting up and managing the network coupled with low returns of investment spread over an extended period of time is the key reason for the service providers’ reluctance to set up communications networks in rural and remote areas. In addition, low population density and challenging terrain further add to the challenge.

There is a growing realization among the service providers that the network strategy for the urban markets is not suitable for the remote and rural areas. It is then a moral dilemma for the telcos.

Innovating To Provide Connectivity In Rural Areas

There is a need to innovate and go beyond the traditional network deployment models to provide high-speed broadband connectivity in rural and difficult-to-reach areas.

The telco’s need to relook and reimagine their current network architecture, which is very complex. The conventional network strategy of adding a layer for every new standard is adding to the complexity. Further, the data centers are monolithic, making it challenging for the telco’s to capture the monetization opportunity that is emerging at the edge of the network while they are connecting everything e.g. devices, machines, industries, meters, security cameras, etc, etc., everything that is benefiting from a digital connection.

Moving from monolithic, hardware-centric networks to software and an open network infrastructure can bring down cost and enable telco’s to provide connectivity in remote areas without compromising profitability. In other words, network economics need to change to adapt to this dynamic market opportunity and need.

Open Radio Access Networks (RAN)

Several new-age innovations, including Open Radio Access Networks (RAN), Edge computing and cloud-native architecture, AI/ML, etc. promise to change this and provide high-speed and reliable connectivity at a cost that is viable for unconnected and in far flung / remote areas.

Open RAN specifically is the game-changer. Essentially, it disaggregates the software and hardware components of the network infrastructure, making it easier and more economically viable to provide internet in remote areas. In addition, the disaggregation of the RAN functions helps in bringing down network cost and complexity. Further, Open RAN deployments do away with vendor lock-in and allow service providers to benefit from virtualization.

The expenditure on RAN accounts for a significant chunk of telco’s capital expenditure. With Open RAN, they are able to bring down the cost by leveraging the open ecosystem and cloud economics. Mobile operators operate in an intensely competitive environment and are constantly stressed to increase capacity and reduce costs. The Open RAN approach allows them to address these issues, and the improved cost economics makes it easier to connect the unconnected and bridge the digital divide.

Cloud-native Mobile Networks

The success of Japan’s Rakuten Mobile, a greenfield operator, is showing us the way. It operates the world’s first fully cloud-native mobile network. Rakuten Mobile launched 4G service in April 2020 and followed this by launching 5G Non-Standalone within few months in September 2020. A cloud-native and automated network promises to bring the benefits of connectivity in yet-to-be-connected areas, thus transforming lives and powering economies.

The industry needs a paradigm shift in thinking beyond the traditional network deployment approach to connect the remaining half of the world’s population. Telco’s need to experiment with out-of-the-box solutions to bridge the digital divide. This will not only allow them to add new subscribers to the network but also contribute to the overall economic and social growth.

Source: cisco.com

Continue reading

Revolutionizing Customer Engagement and Collaborative Development

Our customers are looking for ways to simplify management of their Cisco devices and adopt new technologies faster while maintaining strong security across their environment. They are facing challenges in locating the right information necessary for deployment, obtaining access to the right resources, gaining visibility into their assets as well as more automated capabilities to reduce risks, increase uptime, and optimize overall performance.

Cisco CX Cloud was built to address these concerns, alongside the Success Tracks suite of service packages. A cloud-based Software as a Service (SaaS) platform, CX Cloud provides customers with unified access to all of their Cisco portfolio in one pane of glass. Users can view their assets, contract coverage and licenses, access insights into the health of their network infrastructure, be alerted to security advisories, detect risks, open support cases in-app, and take advantage of contextual learning to train their IT teams all within CX Cloud.

Realizing the value of IT investments quickly is critically important to delivering results with agility. Our customers have told us that they want to be able to self-service, but at the same time be able to leverage consultative subject matter experts to help navigate more complex infrastructures. For example, one of our customers mentioned that often once a vendor sells something, they are left to figure out how to set it up, how to use it, and how to make it work to meet their needs. Another received a mandate to eliminate all critical security vulnerabilities across their entire infrastructure in a relatively short time frame, which is traditionally neither fast nor easy to accomplish, and weren’t sure where to begin.

In partnership with our customers, the CX Cloud Insights & Innovation Team aligns CX Cloud’s platform capabilities with our customers’ goals, so value is realized faster. We help customers learn how to use the CX Cloud platform and move through every stage of the adoption lifecycle, removing barriers along the way and identifying how to make the platform exactly what our customers need it to be. We have engaged with many customers and have learned from them the many ways CX Cloud helps them every day.

We engage with customers early and often, learning together and from one another and working together to solve their biggest pain points. Our engagement enriches the customer experience as we collaborate with our customers to determine how they can leverage the platform and how it can be used to help fulfill their responsibilities. As previously mentioned, one customer had to meet a deadline to reduce critical impact security advisories fast. They used CX Cloud Advisories to demonstrate their progress against this goal. It allowed them to identify what assets were vulnerable and then follow the guidance to remediate those vulnerabilities. From their efforts, they were able to reduce their risk by 33% in a matter of a few weeks. Customers say CX Cloud is intuitive and easy to use, and the expert level guidance from our team takes any remaining questions off the table to help them learn how to get the most from CX Cloud fast. The only question to answer is how fast do you want to go

We actively search for solutions to problems customers face on a day-to-day basis while we train and educate them on how to use CX Cloud. Looking again at our customer who needed to tackle security vulnerabilities across their entire infrastructure, they knew immediately this traditionally is neither fast, nor easy to accomplish. With the capabilities delivered by CX Cloud, customers can be efficient and effective in achieving this goal and be proactively notified of critical vulnerabilities before they become an emergency. How is this possible Using the insights and guidance delivered by CX Cloud, customers can skip the investigation required to identify if and where problems exist. Instead, they can move directly to remediation because CX Cloud will do the investigation for them by automatically scanning the environment. As shared by another customer, it takes on average two hours per week for them to investigate potential problems in the network. With CX Cloud monitoring their environment, those two hours can now be spent implementing fixes to known issues instead. What can you achieve with time back each week And what more can you accomplish when reacting to problems is a thing of the past

Our customers have never had as much say in the development of a Cisco product as they do with CX Cloud today. What is very exciting is how customer-centric CX Cloud really is in its development and product roadmap. Cisco is listening more than ever to learn from our customers what they need from CX Cloud and feed ideas directly into product development either through direct engagement or in-app within CX Cloud. Customer ideas are captured every day and reviewed throughout the week. Often our product managers will directly engage with customers to follow up and better understand their ideas and how they might be best implemented. And by submitting ideas online, customer will receive updates on the status of their ideas and will know when they’ve been implemented into production. Finally, in our weekly CX Cloud Club Conversations webinars, we train on, discuss, and learn about the future of CX Cloud with product management, where they also answer customer questions in a live forum.

What do you want CX Cloud to do for you Through expert engagement you’ll learn how to maximize the value of CX Cloud platform, align it with your goals, and customize it to drive efficiency in your organization.

Source: Cisco.com

Continue reading

Miercom Test endorses Cisco SD-WAN’s High Availability and Best Path optimization capabilities.

In order to achieve a resilient network, it is important to maintain high availability not only in control plane, but also at the data plane for traffic to flow smoothly, without any disruptions. In the event of unavailability of control plane, which governs and manages the data plane traffic, the whole WAN infrastructure and subsequent site traffic can go down, causing huge outages. The SD-WAN solution should be intelligent enough to not only ensure continuous data plane operation, but also to provide an optimized path for the application traffic for enhanced user experience.

Cisco SD-WAN provides faster link convergence, whenever the primary link fails, making sure that there is zero downtime on the actual traffic flowing across the network. Once the IPsec Tunnels are up and running, data plane traffic does not have any dependency on the control plane. Which means, that even if the connectivity from the edge devices to control plane is down, traffic between the IPsec established sites will remain up and running.

This has been tested and verified by Miercom, wherein following scenarios were recreated:

Figure 1. Internet link from Site-2 toward control plane was shut down, disconnecting it from controllers.

Figure 2. Internet link toward control plane was shut down, disconnecting both the sites from the controllers.

In both the cases, before bringing down the control connection, Miercom verified that IPSec Connectivity is up and running. Post verification, when the control links were shut down, it was observed that traffic flow was not impacted, and IPSec tunnels remained up and operational. It was observed that Cisco SD-WAN did not require any manual intervention for failover in both the scenarios.

Apart from providing link level resiliency for maintaining continuous flow of data traffic, Cisco SD-WAN also provides best path optimization based upon the SLAs defined in the application policies. It has been tested and verified that if the primary link goes down or if the SLA parameters such as latency, delay, jitter are compromised in comparison to what has been defined in the routing policies, then the application traffic automatically failover to the secondary link.

In comparison to such resilient SD-WAN architecture by Cisco, our competitor failed to provide high availability and disruption-free data flow. The similar scenarios were recreated and tested on our competitor’s solution. It has been observed that there is approximately 10 seconds of traffic disruption during failover testing, causing mission critical applications such as financial or banking application to go offline for a good amount of time.

Moreover, from overall architecture perspective, our competitor has dependency on cloud hosted controller and there are fixed ports in their edge devices to enable such connection. Hence, if the respective ports are taken down for disconnecting the controller communication, the edge devices will also go offline disrupting the whole network.

By comparing the functionality and performance for both the solutions, Miercom concluded that Cisco SD-WAN provides highly scalable network architecture, which enables auto failover of traffic circuits, as and when need arise. This makes sure that end users are not impacted due to any disruptions caused by link flapping or degraded circuit performance. Cisco SD-WAN always ensures that the application traffic is routed through the best optimized path, giving best user experience.

Source: cisco.com

Continue reading

Detect What Others Miss with CESA

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

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

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

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

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

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

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

Figure 1: CESA Architecture

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

SecureX Integration

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

Figure 2: SecureX CESA Relay

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

Secure NVM Transport

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

Figure 4: Secure NVM Transport

Trace Path of Malicious Software

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

Figure 5: Deep visibility into process path

Find Ultra-Stealthy Threats

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

Figure 6: Deep visibility into process path arguments

Logged-in User Visibility

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

Figure 7: Remote logged-in user visibility

Continue reading