New Catalyst Products Bring 5G and Accelerated SASE to the WAN Edge

Cisco is expanding its Catalyst 8000 Edge Platforms Family and Catalyst Cellular Gateways to help customers build a resilient, reliable digital footprint that spans data center, cloud and branch deployments. The new announcements extend the both the Catalyst 8000 Edge Platforms Family and Cellular Gateways to include a new 5G Cellular Gateway, a new virtual CPE edge device that can host Cisco or third party VNFs, as well as extensions to the Catalyst 8500 aggregation and Catalyst 8300 branch portfolio.

Whether you’re streaming video, hosting a conference call, checking emails or accessing other critical business applications, you need secure, seamless connectivity no matter where these applications are hosted. These new Cisco Catalyst Edge Platforms accelerate  multicloud journeys with choices that include on-premises and cloud-delivered security. All Cisco Catalyst 8000 Edge Platforms contain the latest Cisco Trust Anchor technology, a secure core providing a hardware-embedded root of trust for enhanced device authenticity and data privacy.

Cisco Catalyst 8500L: 1/10G optimized WAN Edge Aggregation

The Cisco Catalyst 8500L is a new model within the 8500 series targeted to meet entry-level 1G/10G aggregation use cases. It’s powered by twelve x86 cores and up to 64GB memory to support secure connectivity for thousands of remote sites and millions of stateful NAT and Firewall sessions.  The Catalyst 8500L provides ultra-fast IPsec crypto performance and advanced flow-based forwarding to keep up with the demands of today’s high-speed, secure connectivity.

Like the multicloud journey in prior years, the emerging need to support remote workers is creating further architecture shifts in customer deployments. Today, businesses find that establishing aggregation sites at either core locations or colocations helps them own the first mile on their branch and remote worker journeys to the internet and other software defined cloud interconnects (SDCI). The Catalyst 8500L comes in a slim 1RU form factor that can be easily racked and stacked in a colocation or core site to support more distributed architectures.

Cisco Catalyst 8200: Expanding the WAN Edge Branch Portfolio

The Catalyst 8200 Series Edge Platforms complement the Catalyst 8300 launched in October to address diverse connectivity needs for branch deployments. The Cisco Catalyst 8200 supports 8 CPU cores for high performance packet forwarding, 8Gb of default RAM to run the latest security services, and Intel® QuickAssist Technology (QAT) for hardware-accelerated performance.  The Catalyst 8200 Series gives up to 1Gbps of aggregate forwarding throughput, which is double the performance of its ISR 4300 predecessor.

The Catalyst 8200 platform offers modular access with a diverse set of WAN connectivity choices via shared NIM/PIM interfaces with the Catalyst 8300 and ISR 4000 series. On-premises integrated security or cloud-delivered security solutions are critical for businesses looking to connect and secure their WAN edge and remote traffic. Yet, many businesses seeking greater simplicity and automation in their IT setup have limited IT staff.

Catalyst 8000 Edge Platforms contain a user-centric design that makes device setup simple with RFID tags on each device to cut inventory management time, rounded corners for better handling and installation, and centralized cloud-based orchestration for easy bring-up. Improved device air flow via circular hex-pattern reduces the need for external cooling, while support for HVDC electricity reduces energy costs even further. The Catalyst 8200 comes in a modest form factor with a physical depth that’s less than 12” to most remote and mobile environments, allowing you to extend SD-WAN into the farthest reaches of your network.

Cisco Catalyst 8200 uCPE: Software-Defined Small and Lean Branches

For service providers and businesses seeking maximum flexibility with network functions virtualization (NFV), Cisco Catalyst 8200 Series Edge uCPE is the latest addition to our SD-Branch portfolio. The platform is purpose built for customers and service providers who need to offer performance alongside shifting technology needs and flexibility. Its 8 CPU cores support up to 500 Mbps aggregate IPsec performance and still have cores left to support additional Cisco or third-party virtual network functions (VNF).

The compact 1RU footprint, shallow depth and the ability to add PIM/NIM interfaces (shared with ISR 4000 and the Catalyst 8000 family) for cellular and WAN connectivity options gives the customers utmost flexibility vs. a white box solution. Catalyst 8200 uCPE can be deployed in SDWAN mode with vManage playing a common orchestrator for configuring the overlay and the underlay.

Cisco Catalyst Cellular Gateway 5G (Sub 6Ghz)

5G brings faster downloads, lower latency and increased capacity to the Wide Area Network. This, combined with SD-WAN, gives customers high speed bandwidth capacity at lower costs which helps them meet the growing throughput demands of an ever-expanding branch.

The latest Cisco Catalyst Cellular Gateway brings Sub 6Ghz 5G connectivity to businesses for ultra-fast wireless WAN and wireless SD-WAN links. Catalyst Cellular Gateways are simple to setup, able to be plugged into your router or edge platform via Power over Ethernet (PoE). Whether your edge device sits in the most remote closet or deepest basement matters little, simply run the Catalyst Cellular Gateway to the nearest reception point and power your network with the latest in 5G.

Broadband connectivity may not be available or reliable in certain locations, yet businesses there can still carry on with their digital transformation thanks to 5G cellular technology which is expanding rapidly in its roll-out. Set up and management are further simplified using Cisco vManage.

Simplified Tiered Licensing

The software capabilities available in feature-rich IOS XE and vManage can be easily consumed through a simplified, three-tiered DNA licensing model.

The first tier into Cisco DNA Software for SD-WAN and Routing is Cisco DNA Essentials.  It encompasses core SD-WAN capabilities such as: circuit load balancing, (DIA), centralized management & orchestration, and traffic path steering. It enables a robust blend of the latest routing capabilities (NAT, BGP, DNS, etc.) and base security capabilities (MACsec, ACLs, Snort IPS, Enterprise Firewall, etc.).

Moving up to Cisco DNA Advantage, subscribers receive everything in Cisco DNA Essentials plus more advanced routing capabilities (MPLS BGP Support, IGMPv3, etc.), more advanced security functionality (Advanced Malware Protection, SSL proxy, etc.), expanded SD-WAN capabilities, vAnalytics, plus access to Cisco’s Cloud OnRamp for SaaS, for IaaS, and for Colocation.

The most advanced Cisco DNA Premier subscription delivers the Cisco’s complete SASE portfolio with a single license! The integration of Cisco Umbrella SIG Essentials into Cisco DNA Premier enables customers to centrally manage the security posture for all remote and branch locations and implement effective cloud security throughout the Cisco SD-WAN fabric.

Designed for an intent-based network, the Catalyst 8000 Series Edge Platforms are the gateway to hybrid and multicloud applications across your cloud, data center and edge locations. The new portfolio announcements augment the Catalyst 8300, 8500, and Cellular Gateway launched last October. These new edge devices offer the resiliency, performance and security needed for today’s multicloud world.

Source: cisco.com

Continue reading

Latest Cisco CCNP Data Center 350-601 Certification Exam Sample Questions and Answers

Cisco CCNP Data Center DCCOR Exam Description:

This exam tests a candidate's knowledge of implementing core data center technologies including network, compute, storage network, automation, and security. The course, Implementing Cisco Data Center Core Technologies, helps candidates to prepare for this exam.

Cisco 350-601 Exam Overview:

• Exam Name:- Implementing and Operating Cisco Data Center Core Technologies
• Exam Number:- 350-601 DCCOR
• Exam Price:- $400 USD
• Duration:- 120 minutes
• Number of Questions:- 90-110
• Passing Score Variable:- (750-850 / 1000 Approx.)
• Recommended Training:- Implementing and Operating Cisco Data Center Core Technologies (DCCOR)
• Exam Registration:- PEARSON VUE
• Sample Questions:- Cisco 350-601 Sample Questions
• Practice Exam:- Cisco Certified Network Professional Data Center Practice Test

Related Articles:-

• 7 Amazing Tips on How to How to Pass Cisco 350–601 DCCOR Exam
• PROVEN TECHNIQUES TO PREPARE FOR A CISCO 350-601 DCCOR EXAM
• Need Some Extrinsic Motivation While Preparing for Cisco 350-601 DCCOR Exam? Click Here.

Continue reading

The Whole Shebang with the Cisco Catalyst 9105 Access Point

If you’re reading this blog, I’m betting you’re a technology enthusiast and that you’ve heard of all the hottest innovations in wireless today. Whether it be the gargantuan increase in throughput-efficiency with Wi-Fi 6, the exciting new possibilities enabled by the Internet-of-Things (IoT), or the powerful yet easy-to-setup wireless home office solutions, they’ve all become a reality and are deployment-ready today!

This begs the question, what is the right wireless platform that will benefit us from these innovations?

Assuming you’ve caught up on the news, you’ve probably heard the commotion from the different wireless companies boasting about their flagship access points (AP), lined up with insane hardware specifications. Something on the lines of having 8×8 radios to support the densest of the client environments, being armed with some state-of-the-art chip that provides users with full visibility into the RF, and integration with their ultra-modern software application for complete network control. You might be thinking, soon enough, well, even some built-in AI software that will predict your future!

Jokes aside, what a time to be alive; all this incredible innovation, and it’s just a matter of time before they’re adopted by enterprises all over the world. However, are these flagship APs right for everyday people like us in our current situation?

It’s not news that most of us are working from home, so if your corporate adopts these new APs, we won’t be able to experience it for days to come. In addition to having a high price point, with standard smartphones and most laptops maxing out with just 2×2 radios, all that fancy hardware specifications on these APs are unfortunately overkill for a simple household anyways.

So, what platform should we use to support our remote working situation?

Introducing the Catalyst 9105

Well, I’m proud to present to you our newest and cutest AP in Cisco’s Wi-Fi 6 portfolio, the Catalyst 9105AXI (Infra model), and 9105AXW (Wall Plate Model). With robust 2×2 radios capable of performing Wi-Fi 6, state-of-the-art software supporting Cisco’s IoT solution, and an efficiently designed internal hardware enabling its small form-factor design, the Catalyst 9105 is not only the perfect AP for small to mid-size offices but also your home.

Figure 1. Catalyst 9105AXW (left) and 9105AXI (right)

With the Catalyst 9105AXI and 9105AXW having dimensions of just 5.9″ x 5.9″ x 1.2″ and 6.3″ x 3.5″ x 1.3″ respectively, these two APs are by far the smallest members of the Catalyst 9100 family. However, when we hear the word small, we automatically assume less powerful, but let me assure you; this platform is far from weak, so why don’t we speak a language that deters any skepticism. Let’s talk numbers.

Wi-Fi 6 with 2×2 Radios

Before we get into the specific features of Wi-Fi 6, I’d like to set the stage by directly presenting to you the raw speeds the Catalyst 9105 can execute with single 2×2 Wi-Fi 6 endpoints associated with its 80 MHz channel. From the tables below, you can see that regardless of the endpoint’s model, each can achieve between 700 to 800 Mbps downstream and 500 to 700 Mbps upstream. For an access point smaller than an average book, these numbers are incredible.

Figure 2. Cisco internal Catalyst 9105 throughput test results

To bring it up a notch, let me ask you this. What is the first thing we think of when the topic of Wi-Fi 6 comes up? Faster speeds? Lower latency? Higher security? Less interference? How about all of the above, enabled by Wi-Fi 6 specific features such as OFDMA, BSS Coloring, Target Wake Time, WPA3, and 1024 QAM. Quite the list of innovations, and while both Catalyst 9105 models support each of these features, let’s focus on the most exciting one, OFDMA!

To my experienced wireless readers, why OFDMA is under constant spotlight comes as no surprise.  However, for those who are new to wireless, OFDMA stands for Orthogonal Frequency-Division Multiple Access and, when enabled, significantly improves the wireless network’s efficiency in serving multiple clients at a time. Before OFDMA, we had OFDM, where a single wireless frame would take up an entire channel’s width for a certain period, essentially forcing each packet regardless of size to wait in a queue. With the introduction of OFDMA, the channel can now be shared by multiple packets simultaneously, enhancing the network’s ability to serve multiple endpoints in parallel.

Figure 3. OFDM vs Wi-Fi 6’s OFDMA

For a more technical explanation, let takes a 20 MHz channel, for example. When using OFDM, a 20 MHz channel has only a single subcarrier (consisting of 242 resource units). As an analogy, this can be interpreted as a one-lane highway, only capable of processing a single packet at a time. When it comes to OFDMA, the 20 MHz channel can be divided into a maximum of 9 subcarriers (consisting of just 26 resource units). The highway’s overall width that we’ve mentioned earlier remains the same but can be divided into multiple narrower lanes and are adjusted based on the incoming packets’ sizes. This means that an AP that supports the full capability of OFDMA can serve nine endpoints at the same time. Since the Catalyst 9105 is intended for less dense environments, it’s designed to support four endpoints in parallel, which is not only incredible, it’s revolutionary for an AP of this size.

Figure 4. A 20MHz channel divided into resources units with OFDMA

To prove what I said is not just colorful marketing, let’s talk numbers. We’ve had Miercom, the well-known third-party network testing firm, run performance tests with Cisco’s 9105, Aruba’s AP505, and Ruckus’s R550 with OFDMA enabled to compare performance. During the test, the APs were first loaded with ten endpoints and gradually up to eighty endpoints passing traffic in parallel. You’ll observe that Cisco’s 9105 maintained a significantly superior throughput lead from the graph below than the other two vendor’s APs. In fact, you’ll observe that even with 80 endpoints associated, Cisco’s 9105 can provide almost the same throughput experience as the other vendor’s APs with just ten endpoints associated. The takeaway is obvious, while the Catalyst 9105 is small in size, it is mighty!

Figure 5. Miercom’s scaled multi-vendor OFDMA TCP performance test

Innovation within the Internet of things

But apart from the raw ability to execute Wi-Fi exceptionally, the Catalyst 9105 will also seamlessly fit into any business’s IoT solution. For readers unfamiliar with the Internet of Things, it’s the ability to leverage a wireless network to monitor and transfer data through smart devices, allowing the user to accomplish tasks in an efficient and often automated manner. Many of you probably have IoT devices in your home right now, such as a Google Home, Amazon Alexa, or a Nest thermostat. These devices being both user-friendly and practical in function, have naturally become an integral part of our day-to-day lives. This seamless enhancement is precisely what the Catalyst 9105 can accomplish but, on an enterprise-level, creating powerful yet fiscally efficient IoT solutions.

So, why do we need this? What problem are we solving?

As you can imagine, for an IoT solution to operate on an enterprise level, it requires an intricate control network that provides full visibility into every corner of the solution to ensure security. However, given that all enterprises will already have a pre-existing network, building a separate one for dedicated IoT usage is costly, complicated, and redundant.

This is where Cisco’s Application Hosting on the Catalyst Access Point feature solves these problems. Customers can now acquire custom Dockerized IoT applications from Cisco’s Solution Partner Marketplace, load them into the built-in containers on the Catalyst 9105 through Cisco DNA Center, and use them as IoT gateways to begin communicating with surrounding IoT devices.

Figure 6. The Catalyst 9105AXW integrated with Cisco’s Application Hosting IoT Solution

By allowing users to utilize their existing low-cost Catalyst 9105 network for IoT, it eliminates the looming pain of building a second network for IoT management. Integrating this solution with Cisco DNA Center, users now have an application life cycle manager that provides them full visibility into the deployment status of each IoT application. In fact, Cisco DNA Center allows users to deploy different applications to different areas of their Catalyst 9105 network, providing the ability to support multiple IoT solutions on a single network!

When it comes to real-life IoT use cases, the possibilities are endless. They can range from retail optimization with electronic shelf labels to motion sensors or cameras for building management systems and even medical wearables for health care solutions. The best part of all this is that it can be automated, creating a genuinely self-sufficient IoT solution.

Wireless Home Office Solution

Up to this point, we’ve reviewed the Catalyst 9105’s Wi-Fi 6 and IoT capabilities; however, the caveat is that most of us are still working remotely, so how can we benefit from these innovations?

As hinted earlier, the Catalyst 9105 can be deployed directly in your home. With Cisco’s remote worker solution, simply connect your Catalyst 9105 to your home network, and it will automatically associate with your company’s corporate Wireless LAN Controller (WLC) and begin broadcasting your corporate’s SSID in Wi-Fi 6.

Can it really be this easy?

Absolutely, and the solution is simple, we use Cisco’s day-0 provisioning solution, Plug-n-Play (PnP). Before shipping the AP to the end-user, the network administrator managing this solution simply needs to create a profile for this AP on Cisco’s PnP Connect cloud portal, then point it to the IP address of the company’s WLC. When the AP receives an IP address, it’ll automatically know to reach out to Cisco’s PnPConnect server through its built-in PnP agent code and will get re-directed to and join the WLC. The fact is, only step one in the diagram below is executed by the end-user; the remaining steps are completely black-boxed, making the workflow incredibly simple.

Figure 7. Remote worker solution’s three-step onboarding process

It’s no doubt convenient, but is it secure?

It’s a resounding yes, and to explain, let’s refer to the architectural diagram below. The left side of the diagram depicts a user’s home network, and you’ll observe the deployed Catalyst 9105 can associate to the corporate office’s WLC (sitting in a public DMZ) through NAT. This connection is not only secured by Cisco Umbrella but also DTLS encrypted, meaning it has the highest level of security segmentation possible.

After the Catalyst 9105 joins the WLC, it can now utilize all its back-end infrastructure, such as the radius server for corporate 802.1x network access, and even Cisco DNA Center. With Cisco DNA Center, the network administrator managing the remote worker networks can leverage features such as Network Assurance and Intelligent Capture to monitor and troubleshoot any issues in the case that they occur, ensuring a phenomenal end-user wireless experience.

Figure 8. Remote worker solution architecture

By combining this wireless trifecta of Wi-Fi 6, Internet-of-Things, and remote worker solution, the Catalyst 9105 is not only a powerful and versatile small form-factor AP, but a multipurpose networking hub, and indeed a force to be reckoned with.

Continue reading

DCNM SAN Insights: Deep Fabric Visibility with Scalable Self-Learning Technology

As tradition, I had my paid time off during Xmas holidays. When back, I realized Cisco product development team had not slowed down their efforts to ameliorate and update existing products. One point in case is Cisco Datacenter Network Manager for SAN, DCNM-SAN for friends. The newly posted DCNM 11.5 release includes an enhancement about the validated scalability of one specific attribute that will make many users happier. Since I have not seen this specific enhancement explained and extolled anywhere else, I’ll try to offer my view on this.

Cisco SAN Analytics feature

All 32G Fibre Channel fabric switches and directors in the Cisco MDS 9000 family offer the SAN Analytics feature. This industry unique technology only inspects the Fibre Channel and SCSI/NVMe headers, not the payload, and so it is in agreement with GDPR requirements. The switch will process this data and then push the resulting metrics information out the management port. The relevant feature is known as SAN Telemetry Streaming (STS) and it uses the gRPC opensource API, based on HTTP/2 transport and gPB encoding format.

Cisco DCNM SAN Insights

Cisco DCNM for SAN includes a feature called SAN Insights. Essentially it enables DCNM to complement and enhance the SAN Analytics capability on network devices. In simple terms, DCNM SAN Insights enables DCNM to perform the following four tasks:

◉ a scalable receiver for data pushed out of MDS 9000 switches via STS

◉ a long term repository for the received data

◉ a post-processing engine for the received data

◉ an intuitive visualization tool for the processed data

Let’s talk about self-learned I/O flows

But what kind of data is streamed out of MDS 9000 switches and received, stored, processed and displayed by DCNM SAN Insights? Well, essentially it is a massive collection of all the I/O flows traversing the Fibre Channel SAN and their associated 70+ metrics like latency, I/O size, outstanding I/Os, IOPS, throughput, CRC errors and many others. All that data is continuously collected in almost real time and can be accessed in its entirty via the NX OS CLI or some script (on-switch approach). It is a lot of data, in the form of database records and tables, possibly too much for a human being to consume and digest in an easy way.

An alternative method wants MDS 9000 switches to stream the collected data out the management ports every 30 seconds (off-switch approach) and toward an external receiver. This is where DCNM SAN Insights makes the magic: it turns an elephant of data into nice charts that administrators can easily interpret. Of course, some basic knowledge of the Fibre Channel protocol and block storage transactions in general are welcome.

There is no unique definition of an I/O flow over a Fibre Channel network but the easiest way to get it is by describing an I/O flow as a combination of Initiator-Target-LUN (ITL) identifiers. When using the emerging NVMe/FC protocol, that would become Initiator-Target-Namespace (ITN). A single MDS 9000 switch port can so provide visibility for many I/O flows, even thousands of flows when it is an E_port (ISL).

Let’s make an example and fix the concept in memory. Imagine a host (Initiator) zoned 1:1 with a single all flash array port (Target) where 30 LUNs are configured and exposed to that host. On the switch port connected to the host, we would see 30 ITL flows (1x1x30). Now imagine you have many hosts and many targets and even more LUNs so you can work out your math. Depending on number of ports and other configuration parameters, a real world SAN can transport from a few hundreds to many thousands of I/O flows. With DCNM SAN Insights adoption now being so strong within datacenters of any size, I would not be surprised if we would find situations where more than 200,000 I/O flows are present and need to be monitored. In my personal (and limited) experience with this unique capability, majority of customers today seem to have between 2,000 and 40,000 I/O flows running at the same time.

These numbers are even more impressive when you consider that all those I/O flows are automatically discovered by the switches, self-learned. It would be clearly impossible to configure them all manually. At the same time, it would be a bit useless to instruct the switches to monitor just a small subset of them, because we would miss data that could be crucial for an effective troubleshooting activity. The fact I/O flows are automatically discovered is very important because it makes SAN Analytics a proactive troubleshooting tool and not just a reactive one. DCNM SAN Insights builds upon the power of SAN Analytics, adding the ease of use that network administrators love.

Scale matters

All this said and explained, I’m now ready to share more about the recent DCNM enhancement that was the reason for me to write this blog. All data about I/O flows and their metrics are streamed out of MDS 9000 switches toward the external receiver. As a result, the receiver should be able to survive this data deluge. With DCNM 11.5, the tested and officially supported scale limit has been raised up to 60,000 simultaneous self-learned flows with 70+ metrics each, 3 times higher than previous release, and good enough for the majority of deployments.

Cisco is constantly working with customers to gather their input and analyze their real-world storage networks to understand the needs of the solution, while at the same time working to ensure the products can support those requirements. Cisco SAN Analytics is a comprehensive product solution that has the ability to generate up to 2.8 million data points every 30 seconds from a single director. At that rate, being able to consume and process that data in a meaningful manner is quite a tough job. It is not a sprint to the most metrics but rather a marathon to make sense out of the data that you have available over a reasonable amount of time. It is from this marathon with the elephant of data that we can gain actionable insights into real-world storage performance. This forms the basis for the value that DCNM SAN Insights provides. In the end, we all agree elephants are best at marathons, not sprints, right?

Hopefully it is now clear that scale matters. Dealing with one I/O flow at a time is not super-complex but dealing with thousands of I/O flows simultaneously is a totally different kind of animal. DCNM 11.5 release has just made an important step in that direction.

Cisco DCNM is a powerful and comprehensive management tool covering day0, day1 and day2 operations. It has always scored a high success in supporting the management and monitoring needs of Cisco customers for datacenter networking products. With its SAN Insights feature, it has augmented its value by also providing long-term trending, end-to-end correlation, advanced analytics (like automatic learning of the performance), automatic baseline calculations, automatic categorization of flows in colored buckets as per their health, dashboards for top talkers or slowest nodes and so on.

A nice overview of the top 10 use cases for DCNM SAN Insights can be found in this video:

Source: cisco.com

Continue reading

Securing industrial networks: What is ISA/IEC 62443?

Cyber attacks targeting industrial networks increased by 2000% from 2018 to 2019. Attacks on operational technology (OT) can interrupt production and revenue, expose proprietary information, or taint product quality. They can even put employees in harm’s way or damage the environment. Attacks on critical infrastructure—water, power, and transportation—can inflict devastating effects on the economy and public health.

Barriers to industrial cybersecurity

Securing industrial operations is now top of mind. But converting good intentions to action can be challenging, for two main reasons. First, industrial networks are often managed by OT teams that don’t have advanced cybersecurity skills. They might also be concerned that the IT team will take actions that reduce operational uptime. Unlike a 2-hour outage to an email server, whose costs are measured in lost productivity and annoyance, a 2-hour unplanned outage to an assembly line can bring output and revenue to a halt.

The other barrier is not knowing where to start. Industrial networks are very complex. Should you start by adding cybersecurity controls to the easiest systems to protect, for a quick win, or to the most critical systems? Does the bigger payoff come from segmenting the network? Detecting anomalous activity? Authorizing users? Something else?

Framework for stronger cybersecurity with nominal disruption

Fortunately, the International Society of Automation (ISA) put together the ISA99 set of standards for building secure industrial automation and control systems (IACS). The International Electrotechnical Commission (IEC) built on that work to introduce IEC 62443.

Some think the ISA/IEC 62443 set of standards is too detailed and complex. We at Cisco like it because it gives IT and OT common ground to work together. It’s a framework to implement industrial cybersecurity best practices step by step, for continuous improvement. The standard defines a secure network architecture, functional requirements, and guidelines to measure your maturity level for each requirement. OT contributes its knowledge about which assets need to communicate and how critical they are, and IT contributes its cybersecurity expertise and technology.

The standards lay out a four-step framework:

1. Take an asset inventory. You can’t secure an asset unless you know it exists. The first step is for the OT team to list all assets and rank their criticality to operations. Invest the most in the most critical assets.

2. Define zones. A zone is a group of devices with similar security requirements, a clear physical border, and the need to talk to each other (figure 1). Imagine a plant with one production line for welding and another for painting. There’s no need for the machines in the two lines to communicate, so all machines in production line 1 would be in one zone, and all machines in production line 2 would be in another. Segmenting the network into zones contains damage if the network is attacked.

3. Define conduits. These are the communications links between zones that must talk to each other. In the plant floor example, both zones need to talk to a supervisory console. Call that zone 3. One conduit connects zone 1 and 3, and another connects zone 2 and 3. No need for a conduit between zones 1 and 2. Once IT and OT have defined zones and conduits, network deployment and security enforcement become straightforward.

Figure 1: IEC 62443 zones and conduits isolate threats

4. Add controls for each zone. Start with the zones containing equipment used for your most critical processes. For each zone, add controls as time and budget permits—for user control, data integrity, data confidentiality, restricted data flow (that’s where conduits come in), timely response to security events, and maintaining resource availability during denial-of-service attacks. The IEC 62443 defines four levels of maturity for zones. At a given time, some of your zones might be at maturity level 1 (most basic) while others are at levels 2, 3, 4, or 5 (most mature).

Significantly, the IEC 62443 doesn’t call the highest maturity level “mature” or “advanced.” Instead, the highest maturity level is “improving,” highlighting the fact that cybersecurity is never done. To stay ahead of ever-more-sophisticated attacks, OT and IT teams should plan to continually strengthen protection.

Source: cisco.com

Continue reading

Get Ready to Explore gRPC in the DevNet IOS XR Always-on Sandbox

"message blog { message content { string yang = 1; string gRPC = 2; } message author { string stuart_clark = 1; } }

We are always looking to deliver more at DevNet. Our fierce developer community is always learning, always coding, and we want to help them grow and learn the skills that will equip them in their roles now and for the next five years. Our DevNet sandbox has been a success for many developers, to get hands-on and explore Cisco platforms and APIs. So, when we asked to enable gRPC on our IOS XR always-on sandbox, of course, we said, ‘let’s do it’. 

What is gRPC? 

gRPC is a modern, lightweight communication protocol from Google. gRPC is a high-performance, open-source, universal RPC framework that can run in any environment.  

Protocol buffers, or Proto, are Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. It is based on protocol buffers, an open-source mechanism for serializing structured data, which is language and platform-neutral. You define the structure using protocol buffer message types in .proto files. Each protocol buffer message is a small logical record of information, containing a series of name-value pairs. XR devises ship with the YANG files that define the data models they support. Using a management protocol like gRPC, you can programmatically query a device for the list of models it supports and retrieves. gRPC encodes requests and responses in binary. gRPC is extensible to other content types along with Protobuf. The Protobuf binary data object in gRPC is transported over HTTP/2. 

gRPC supports distributed applications and services between a client and server. gRPC provides the infrastructure to build a device management service to exchange configuration and operational data between a client and a server. The structure of the data is defined by YANG models. 

◉ Efficient: Protocol buffers are verbose and descriptive. But they are smaller, faster, more efficient, and provide high performance. 

◉ Machine Readable: Protocol buffers are binary or machine-readable and can be used to exchange messages between services and not over browsers. 

◉ Generators: With a compiler, Protocol buffers can be easily compiled to source code along with runtime libraries for your choice of programming language. This makes serialization or deserialization easier, with no need for hand parsing. 

◉ Supports Types: Unlike JSON, we can specify field types and add validations for the same in the. proto file. 

Getting started with gRPC on the DevNet Sandbox 

Always-on Sandbox we are mapping the inbound port 19399 to 57777. The first thing we need to do is ensure that the IOS XR sandbox has gRPC enabled. Here is the configuration required with `tls` disabled.  

To make this simple you can clone this sample code and install the requirements. The package contains a library with the methods that are available to use over gRPC with IOS-XR boxes after 6.0.0. The API has several methods which allows a user to send simple RPC commands such as get and push using YANG and JSON. 

The repo consists of two main components: 

◉ The compiled pb2 file from the proto definition. 

◉ A Python module accessing the pb2 file with the library bindings. 

To get all the interfaces from the Always-on Sandbox IOS-XR device, we can run this small piece of code derived from OpenConfig YANG models, and serialize this as JSON. Change to into the examples directory and run the following code, this uses the YANG model. https://github.com/YangModels/yang/blob/master/vendor/cisco/xr/653/openconfig-interfaces.yang and will print all the interface from the Always-on Sandbox IOS-XR device in the `json` format. 

Code Example “Configure, update, and delete BGP“ 

This next code uses the JSON below and is based off the YANG model provided by Cisco: https://github.com/YangModels/yang/blob/master/vendor/cisco/xr/653/Cisco-IOS-XR-ipv4-bgp-cfg.yang You can walk through the hierarchy using pyang, and create a JSON model similar to the example below. https://github.com/mbj4668/pyang/wiki/TreeOutput This JSON model is for a BGP configuration. We can see that it is defining a BGP instance and a single neighbor. 

This code uses Object-Oriented Programming (OOP). This is a programming paradigm where different components of a computer program are modelled after real-world objects. An object is anything that has some characteristics and can perform a function. All args used in the running of the code are handled using Click. Click is a Python package for creating beautiful command line interfaces in a composable way with as little code as necessary. From the example’s directory run the following: 

GetConfig – Retrieves configuration data. Takes model path in JSON format as input argument. Returns configuration data in JSON format and an error string. 

◉ MergeConfig – Merge’s configuration data. Takes modelled data in JSON format as input argument. Returns error string. 

◉ DeleteConfig – Deletes configuration data. Takes modelled data in JSON format as input argument. Returns error string. 

◉ ReplaceConfig – Replaces configuration data. Takes modelled data in JSON format as input argument. Returns error string. 

Start with a ‘get.’ This will look at the Always-on Sandbox IOS-XR device configuration and return that BGP is not configured (note that this is an Always-on Sandbox and that other users might be using this or there could be stale configurations on the device).

Next, add a base BGP config using the JSON file we looked at before, using python grpc_cfg.py replace

If we logged into the Always-on Sandbox IOS-XR device, we would now see one neighbor configured. 

However, we can use the ‘get’ function once again to see this.

If this worked correctly you should see the JSON file we looked at, and the response from the get should be identical. Now, use a merge request to add another neighbor with the second JSON file. 

The resulting config should be the first config plus the second. Or in other words, there are two neighbors defined. This can also be seen by running the python grpc_cfg.py get file once more. 

To delete the configuration, we can send an empty JSON file, followed by the get file to confirm that BGP is no longer configured/active. 

Continue reading

Threat Landscape Trends: Endpoint Security, Part 2

Part 2: LOLBins, operating systems, and threat types

Being aware of what’s occurring on the threat landscape can be a valuable tool when it comes to defending your organization. If you’re well informed, that puts you in a good position to decide how best to protect your assets and allocate resources accordingly. While it’s important to stay up to date with the latest ground-breaking attack techniques and new threats, it’s equally important to keep abreast of the overall trends.

The fact is that, for every novel technique discovered, there are countless attacks taking place in the same time frame that use well-known and well-trodden tactics. For every attack carried out by a nation state, there’s a dozen million-dollar ransomware attacks that started with a simple phishing email.

This is why watching the trends is so important: it provides a view of what you’re most likely to encounter. This is the purpose of this new blog series, Threat Landscape Trends. In it, we’ll be taking a look at activity in the threat landscape and sharing the latest trends we see. By doing so, we hope to shed light on areas where you can quickly have an impact in defending your assets, especially if dealing with limited security resources.

In Part 1, we took a look at critical severity threats and MITRE ATT&CK tactics that were spotted by the Indication of Compromise (IoC) feature in Cisco’s Endpoint Security solution. In this second part, we’re going to step back and look at a larger swath of the IoC alerts to see what’s most frequently encountered.

The methodology remains the same as in Part 1, which we provide again at the end of this blog. In a nutshell, the data presented here is similar to alerts you would see within the dashboard of Cisco’s Endpoint Security solution, only aggregated across organizations. This time we rank the IoCs that organizations have encountered grouped by particular topics. The data set covers the first half of 2020, from January 1st through June 30th.

Signal from Noise

According to Cisco’s 2020 CISO Benchmark Report, one of the biggest issues IT folks face is alert fatigue. Of the respondents that claim they suffer from such fatigue, 93 percent said they receive at least 5,000 alerts per day. In circumstances like this, it’s absolutely critical to be able to derive what’s important from what can be discarded.

As we showed in Part 1, the vast majority of alerts fall into the low and medium severity categories (35 and 51 percent, respectively). It may be tempting to discount lower severities outright. Indeed, in some circumstances, this may be the correct course of action.

For instance, some of the more common low severity IoCs, like running PsExec as an administrator or stopping the firewall with NetSh, may on occasion trigger on activities carried out by IT administration—whether or not these are considered best practices. While not an attack, these sorts of alerts may be worth having a conversation about with the IT department, when time allots.

However, the significance of an alert shouldn’t be based on the severity alone. Under some circumstances, low severity alerts can be just as concerning as a critical severity alert. The trick is to figure out the context surrounding them. What happened before and after an alert? Are there other lower-severity alerts in the same time frame? Stringing together a series of suspicious alerts can give a much clearer picture of potential attacks that may only alert on lower severity IoCs.

For example, let’s say an attacker sends a phishing email to your organization. If the recipient opens the Word attachment, a macro contained within launches a script (triggering the IoC W32.WinWord.Powershell.ioc). The script in turn runs encoded PowerShell commands (W32.PowershellEncodedBuffer.ioc) to set the stage to download further malicious code (W32.PowershellDownloadString.ioc).

This scenario is comprised entirely of low- and medium-severity IoCs. Each of these by themselves do not necessarily point to an attack, but when viewed as a string of IoCs, it’s very unlikely that these would be associated with anything but malicious activity. At the end of the day, the idea with the lower IoC categories is that they indicate activity within your environment that should be investigated, especially if IT says they didn’t do it.

With this in mind, in the metrics that follow we’ll look at medium, high, and critical-severity IoCs. This is because, while low-severity IoCs are critical when looking at a series of alerts appearing in sequence, individually they can muddy the waters when analyzing larger malicious trends across organizations. Filtering out these IoCs ensures that the activity that we’re focusing on is actual malicious activity, as opposed to a round-about administrative solution.

So, without further ado, let’s have a look at more threat landscape trends, covering LOLBins, OSes, and other threats.

LOLBins

Utilizing the tools built into operating systems is a very common attack tactic these days. Leveraging such readily available binaries decreases the chances that an attacker will be discovered, compared to custom-tailored malicious tools that can stand out. Using readily available tools for malicious activity is generally referred to as “living off the land,” and the binaries utilized are called LOLBins. 

The use of LOLBins appears to be quite common for malicious activity, based on alerts seen during the first half of 2020. In our research, 20-27 percent of the IoC alerts organizations encountered at least once in a given month were related to suspicious LOLBin activity.

Percentage of IoC alerts organizations encountered related to suspicious LOLBins.

What’s notable is the five percent jump witnessed in April. This is primarily due to activity related to an adware application called Browser Assistant. This adware generally injects JavaScript into web browsers to display advertisements. During April, Browser Assistant was seen using PowerShell to load itself into memory without launching files (using reflective DLL injection, to be specific). This is highly suspect, being a technique often used by fileless malware.

Two LOLBins in particular appear to dominate the top LOLBin IoCs seen: PowerShell and the Windows Scripting Host (covering both WScript and CScript). Both of these LOLBins facilitate the execution of scripts within the Windows operating system.

Top LOLBin IoCs

Overall, PowerShell is involved in five of the top ten IoCs seen relating to LOLBins, comprising around 59 percent of all LOLBin alerts. In many cases, PowerShell is used to download malicious code into memory or download further executables. The Windows Scripting Host is often leveraged to launch malicious files, perform reconnaissance, move throughout the network, or contact remote locations. The Windows Scripting Host made up 23 percent of all LOLBin alerts.

What’s interesting in looking at the malicious use of these native binaries is that bad actors often leverage one LOLBin to launch another. This is clear with the eighth and tenth entries in our list and can be seen in other IoCs beyond the top ten. Malicious actors likely swap LOLBins during an attack in order to hide their tracks.

Top OS IoCs

Let’s take a look at the two primary desktop operating systems, Windows and macOS, to see how attackers are targeting them.

Windows

Naturally, PowerShell makes its presence known, with appearances in three IoCs in the top ten. The Windows Scripting Host appears twice as well, showing just how prevalent LOLBins are in the Windows environment. In all, half of the top 10 IoCs on Windows use LOLBins.

Top Windows IoCs

Adware also appears quite prominently on Windows, with three adware installers and ad-injecting IoCs making the top 10. However, these IoCs should not be taken lightly for being adware. These instances are some of the more egregious adware installers, often going well beyond what is considered a legitimate install process.

Other activities of note include:

◉ The presence of The Onion Router (TOR) connections ranks highly. TOR can feasibly be used to allow encrypted traffic through firewalls, at best to get around IT policies, and worst for data exfiltration.

◉ Quietly disabling UAC via the registry is something an attacker might do in order to run malicious code that requires elevated privileges.

◉ Using NSlookup to send DNS TXT queries is a technique often used by bad actors for C2 communication.

MacOS

Adware appears quite frequently on macOS as well, comprising four of the top ten IoCs seen. What’s interesting is that LOLBins don’t appear as frequently here as they do on Windows. Instead, attackers are likely to hide their presence by disabling the security programs, excluding their files from quarantine, clearing command histories, and hiding files.

Top macOS IoCs

Threat categories

Finally, let’s home in on some specific threat types. Here is a closer look at four key types of threats currently seen on the threat landscape.

Ransomware

The most common IoC alert seen relating to ransomware is the deletion of shadow copies, which are snapshots of the file system used by the Windows operating system for backups. Ransomware threats often delete these files to prevent encrypted files from being restored from local backups. This particular IoC comprised 66 percent of all ransomware-related IoC alerts.

Top Ransomware IoCs

It’s also worth noting that ransomware often uses the Windows Scripting Host to execute a .zip file that contains malicious JavaScript. This is a technique used by malicious actors that install ransomware, such as WastedLocker. However, since such zipped JavaScript files are also used in other malicious attacks outside of ransomware, such as email campaigns for Emotet, it is not included in the list above.

Credential Stealing

The most commonly encountered credential stealing tool, Mimikatz, was featured in Part 1 of our look at Endpoint Security related trends. At 28 percent, this critical-severity, credential-dumping tool topped other regularly used techniques, likely for the all-in-one approach that the tool offers.

Apart from Mimikatz, malicious actors were seen utilizing the Findstr utility on files, digging through LSASS, and combing through the registry in order to find credentials.

Top Credential Stealing IoCs

Adware

Adware features heavily on both Windows and macOS operating systems. Adware appearing in the top five generally behave in a manner closer to malware than a simple annoyance of showing you an unexpected advertisement.

Top Adware IoCs

Cryptomining

While cryptomining doesn’t currently feature heavily in overall IoC lists, the most common activities seen include regular activity associated with cryptomining, such as submitting and requesting work from a cryptomining server or wallet-related activity. However, instances of fileless cryptominers and attempts to stop other miners feature in the top five as well.

Top Cryptomining IoCs

How to defend

While no doubt interesting, the information in this blog can also double as a blueprint for a plan of defense. This is especially important if working with limited resources, when prioritizing defensive actions where they’re most needed is critical. If you’re going to do one thing with this new information to protect your organization, focus your efforts on what consistently crops up in these lists: LOLBins.

Of course, this may be easier said than done, not only because these binaries are baked into the OS, but because many IT organizations utilize them in their daily operations. So how do you differentiate between normal operations and malicious activity? While it’s fairly obvious when some actions are being carried out by bad actors, others are not so clear.

First and foremost, it’s important to ensure you enable adequate logging on systems. The fact is you can’t pinpoint malicious activity if there’s no record of it.

It’s also important to have a clear understanding of the types of commands and activity that you can expect within these logs. Filtering out what you know is being carried out through automation or IT activities will clear out much of the noise, making it easier to drill down into what should be there.

It’s also important look for patterns. Individual activities and commands may not appear malicious on their own, but in the context of a series of commands, ran before and after, a malicious pattern may emerge. Create playbooks that address these patterns and use automation to detect when they trigger.

When it comes to what commands and activities are expected, every organization is different. Establishing your approach often requires the involvement a variety of people from different teams. Establishing those communications will not only help when building out a defensive plan, but can be critical in quickly resolving an incident if one arises.

Methodology

We’ve organized the data set in such a way as to obtain more meaningful trends. First, we’ve aggregated the data by the number of organizations that have received an alert about a particular activity, as opposed to the total number of detections in the given time frame. Charts are broken down by months. This means that an organization can be counted in each month, if they see the activity. Tables cover the full six-month period (January 1, 2020 through June 30, 2020), and organizations encountering an IoC are only counted once in these cases.

A word on privacy

Cisco takes customer privacy very seriously. While Cisco Security products can report telemetry back to us, this is an opt-in feature within our products. To further this end, we’ve gone to great lengths to ensure the data used for this blog series is anonymized and aggregated before any analysis is performed on it.

Continue reading