The Multicloud Vision of Cisco’s ACI Anywhere Becomes Reality

The data center is not centered in one place anymore. With applications active at all points on the network, the data center can no longer be confined to a specific place but be more of a nerve cluster situated where the data is—which could be anywhere along the edge-cloud continuum.

At the edge, where new data is generated. In the cloud, any cloud, or on-premise, where it’s processed. Wherever it makes the most sense to execute at speed. Ready and able to provide intelligence on the spot. Ready for change. Ready for growth.

Modern IT infrastructure is performing an intricate and elaborate dance with these data sources and requirements. Cisco’s ACI Anywhere is that critical infrastructure component enabling policy driven network automation for connectivity and segmentation for these data elements, independent of where data resides.

Cisco ACI Anywhere now delivers a true hybrid multicloud capability for customers, taking a holistic, policy driven abstraction on top of cloud native APIs , regardless of the type of workload – physical, virtual, or containerized, across on-premises and/or public cloud.

Cloud Challenges

During recent conversations with customers who operate some of the most demanding and complex data center environments, we found that many are dealing with the same issues, such as:

◈ Inconsistent segmentation capabilities across hybrid instances pose security, compliance, and governance challenges

◈ Complex operational models due to diverse and disjointed visibility and troubleshooting capabilities, with no correlation across different cloud service providers. .

◈ Managing secure connectivity across these hybrid data and application workload environments.

◈ Multiple panes needed to configure, manage, monitor, and operate these multicloud instances.

◈ Last, but not least, training and learning new cloud native constructs.

Solving the Challenges

As the premier policy-driven infrastructure solution for the largest enterprises, Cisco ACI can play a key role in enabling customers to embrace multicloud capabilities.

Cisco Cloud Application Centric Infrastructure (Cloud ACI) is a comprehensive solution for automated network connectivity, consistent policy management, and simplified operations for multicloud environments.

The solution captures business and user intent, uses group-based network and security policy models, and translates them into cloud-native policy constructs for applications deployed across various cloud environments.

Cloud ACI Solution Core Components

While customers benefit from an ACI policy driven infrastructure in the on-premises environment, Cisco Cloud ACI allows them to automate the management of end-to-end connectivity, as well as the agentless enforcement of consistent security policies, for workloads across on-premises and in public clouds through a single pane of glass.

Key components include:

◈ Multisite Orchestrator (hosted anywhere) for inter-site policy definition

◈ Cisco’s Cloud Application Policy Infrastructure Controller (APIC) runs natively in public clouds to provide automated connectivity, policy translation, day two operations, and enhanced visibility of workloads in the public cloud

◈ CSR 1000V instance (runs in the cloud) for IPSec VPN tunnel (Underlay), and VXLAN (overlay termination) for data-plane connectivity between on-premises and cloud

Accelerating Cloud-based Journeys – What’s New?

For customers whose journeys start in the cloud, we are now introducing the Cloud-first ACI solution, or ACI Multicloud, which uncouples the solution from the on-premises data center and allows you to securely connect and segment workloads not only in the public cloud, but also across public clouds.

For customers extending their on-premises ACI infrastructure into public cloud, we are now introducing Cloud ACI extensions to Azure cloud, in addition to the already shipping Cloud ACI extensions on AWS.

We are also introducing new ACI and SDWAN integration for branch offices (Network Edge). An integral component of customers cloud journey also requires secure, policy driven interconnects between the data center and branch offices, that are a cost-efficient alternative to provisioning dedicated connections. Through this integration, customers can now automate WAN path selection between the branch office and the on-premises data center based on application policy.

Enjoy the benefits of a policy driven infrastructure … Anywhere

Collectively, these capabilities reduce management complexity, enable a common governance and security posture, simplify ‘Day 2 operations’ with enhanced visibility across on-premises and public cloud, while leveraging the rich native services available in public clouds for scale and flexibility.

Customers can benefit from secure workload mobility and preserve the application policies, network segmentation, and identity of the workloads, whether it’s to achieve their business continuity, disaster recovery mandates, cloud bursting SLAs, or simply accelerating your cloud migration journey.

In addition, customers can benefit from Cisco ACI broad ecosystem that allows for integration with most commonly deployed solutions such as Cisco AppDynamics, CloudCenter, F5, Citrix, ServiceNow, Splunk, SevOne, and Datadog.

With new Azure extensions, customers can tap into the rich cross-silo insights through ACI integrations with Azure technologies like Azure Monitor*, Azure Resource Health* and Azure Resource Manager * to fine-tune their network operations for speed, flexibility and cost.

Customers can leverage widely adopted tools such as Terraform and Ansible to achieve end-to-end workflow-based automation.

“ESG Research validates that companies are increasingly adopting a hybrid cloud approach as a centerpiece of the their digital transformation journeys. In fact, many are standardizing on a Multi-cloud policy.
However, these distributed compute environments create significant management and operational complexity. Cisco ACI Anywhere, and more specifically, Cloud ACI for Microsoft Azure with its native integration in Azure, is the “Easy” button that helps to consolidate and simplify management across the on-premises data center and the popular Azure cloud environment.
It enables a common policy ,security and governance framework across all locations enabling consistent application segmentation, access control and isolation across varied deployment models. We expect this message to resonate with all market segments and customers.”
—Bob Laliberte, Practice Director and Senior Analyst with the Enterprise Strategy Group.

Looking Towards the Future

Our ACI anywhere vision is to provide the freedom of choice, agility, security, and flexibility of being able to connect and run your workloads Anywhere without compromising your security and governance mandates.

With the new ‘Cloud ACI on Azure’ and ‘Cloud First ACI’, along with ‘ACI and SD-WAN’ integration, Cisco has taken another huge step forward toward delivering that vision. And there is more to come in future.

Continue reading

From Controllers to Multi-Domain: 7 Pillars of Intent-Based Networking

About four years ago, my team at Cisco sat down to re-architect enterprise networking, because we knew that the traditional models for running networks were not going to be able to scale with the changes being forced on to them. For example, we saw that the number and types of devices connecting to networks was growing exponentially; that the security perimeter was shifting from data center to being fully distributed in the network; and that wireless networks had become primary networks, not overlays. Meanwhile, networks were getting more business-critical. Even life-critical.

One thing that was not going to change: Nobody was getting more people to run their systems. Our networks are more complex, more threatened, and more important, but they have to be run by the same kinds of teams, using the same kind of tools, that were in place ten years ago.

Fortunately, the technologies available to address these challenges are evolving as well. Wireless technologies, AI, rich behavioral and telemetry databases, more flexible and economical WAN links, and abundant cloud compute resources are becoming available to address the new reality.

These are some of the reasons we have gone all-in with intent-based networking (IBN). We released our first products that supported IBN in 2017 – primarily the Catalyst 9000-series switches and Cisco DNA Center. And it’s why we acquired the SD-WAN innovator Viptela, also in 2017.

Behind these new products and acquisitions there is a long-term vision. All our new enterprise products are based on seven core tenets of this vision. I want to explain those here. It may help you see the strategy behind the products we have launched in the past few years. And it will give you an idea of the new services and tools we’ll be rolling out soon.

1. Controller-Based Networking

Networks are complex systems, and a core focus of intent-based networking is that they should be run and managed as cohesive systems. That means network managers need a controller, from which they can monitor, manage, and automate their networks, and eventually create closed-looped systems.

A controller-first system architecture is made up of loosely-coupled systems. It allows network devices and controllers to be upgraded individually, without causing major network disruptions (no more “flag days.”) And by using APIs and well-defined data structures for communication between devices, we also get a system in which programming, maintenance, and upgrading to new capabilities is more straightforward.

2. Wireless as an Equal to Wired

In the past, enterprise networking meant wired networking: cables and fibers connecting critical devices to each other. Wireless, for the most part, was seen as an emerging access technology for devices on the edge of the network. Wireless networks were built as  overlays on top of the wired networks. The separation into different infrastructures led to inconsistent policies and operating models between the wired and wireless clients.

We can no longer relegate wireless communication to a different system. Wireless is the predominant access technology for end-user and IoT devices, and to keep these devices managed and secure, we need to think of wireless and wired as one network.

In our latest access products, from our switches like the Catalyst 9300 to Wireless Lan Controllers (WLC) like the Catalyst 9800, we use the same fundamental technologies: The same line of ASICs and the same operating systems. This was not a superficial change. We reengineered our entire line for this, so that the same networking capabilities and security could be enabled for all our devices, and so user policies would be the same no matter what access medium the user was on.

3. Integrated Security

The most modern and insidious security threats often come in today via end-user devices. In addition to traditional attacks focusing on data theft, the goal of many attacks today is destruction of infrastructure, by encrypting and denying access to critical information. But traditional firewalls are much less effective with attacks that move from device to device inside a network, which is a growing threat in the era of wireless, which, from a security perspective, is also the era of the network without a perimeter. There is no “DMZ” anymore. Infected devices can launch attacks no matter what network they are on, and their attacks can jump not just from machine to machine, but from network to network. The only way to prevent these attacks is for the network to act as the first line of defense.

Because these security threats are more complex, and attacks more fluid, it’s important that we use network segmentation as a primary security tool, instead of relying primarily on blacklists. We need dynamic, controller-based systems to manage segmentation and whitelisting across network domains to make sure that people, apps, and devices have access to the resources they need, but that they are never put in contact with the devices, apps, and networks they don’t.

Complementing the network segmentation, we also need to evolve our ideas of where and how we deploy traditional security functions. Along with the traditional standalone deployment models, security services need to be fully integrated with switches and routers, as well as available as cloud services.

Overall, we need networking to be and integral part of how we secure the enterprise against  modern threats.

4. Data-Driven

The key to everything we’re building now is data. Data from every dimension of our networking equipment can be collected, collated, parsed, and analyzed. Because when we know what our network equipment is doing we know if it is delivering on our customers’ strategic and day-to-day needs. In Cisco DNA Center, data powers our Assurance capability, which helps us close the loop from intent to action. (In vManage, vAnalytics plays this role.)

The massive amount of information could be overwhelming. Standard algorithms can help us find standard issues that crop up. Beyond that, we rely on machine intelligence to perform complex correlations and generate more valuable insights, like spotting pattern-breaking behavior that may indicate problems on the network.

We are also pioneering the field of machine reasoning to combine machine intelligence with knowledgebases created by teams of experts, to provide smart alerts to network operators, and ultimately, automatic remediation of issues to improve our customers’ experiences with their networks.

5. Cloud-First

This machine intelligence runs locally on our customers’ networks, but there’s extra benefit to be gained when we combine metadata about network use across enterprises. Many of our machine learning capabilities use cloud-based resources, primarily to leverage the vast resource of global data on how networks are performing, and the issues they are facing. This is how the information security industry has long been identifying and remediating global zero-day exploits; we use similar capabilities, seasoned with AI, to improve day-to-day network performance and efficiency for all. No matter where our controller systems run – on-prem or in the cloud – using cloud-based data makes the network more powerful and proactive.

We are also delivering updates to our controllers’ software from the cloud, instead of requiring network operators to manually pull software and update these systems. Furthermore, the rich telemetry we can get from cloud-connected devices enables us to roll out software upgrades gradually across our customer base – and even within customers’ installations. This way, customers can keep up with security issues, and we can deliver new capabilities as we develop them. And yes, it sounds basic if you’re accustomed to using consumer devices like smartphones, but designing controllers for over-the-air updates is a change in this industry – just like Tesla’s ability to roll software updates out to customers’ cars has changed the expectations for how the auto industry delivers software to the car.

While nearly all our customers are moving to cloud-based systems architectures, that transition can be a complex, multiyear journey. For now, most networks are hybrid, on-prem plus cloud, and will be for a long time. In order to seamlessly operate these hybrid networks, customers need consistent features across all their devices and services. We are enabling this by delivering IOS-XE on physical switches & routers, and as virtual instances in the cloud.

6. Support for Existing Networks

It’s one thing to design a networking system using all modern concepts and systems. But the real world isn’t a green field of open racks and empty conduit. We need our systems to work in our customers’ existing “brown field” installations. Businesses generally upgrade infrastructure gradually, piece by piece. Older networking components have to co-exist with the new. “Rip and replace” isn’t a workable implementation tactic.

That is why, although we built Cisco DNA Center and all our new Catalyst 9000-series hardware to be programmable using new, well-defined APIs  and new interaction capabilities, we also control and gather data from older products, using traditional CLI (Command Line Interface), SNMP (Simple Network Management Protocol), and other legacy control schemes. Cisco DNA Center presents the network operator – and network applications – with a unified modern interface for all network equipment, and it chooses the best way to connect to the equipment to carry out the operator’s intent.

Similarly, to support the installed base of equipment on existing networks, we are also enabling SD-WAN and vManage on older ISR platforms, so customers can introduce SD-WAN into their current deployments.

7. Multi-Domain

Today’s networks are made up of multiple operational domains (for example: campus, data center, and security), that are tightly linked. Today’s customers need more than interconnected domains. To support business needs, they need security and access policy that spans domains, and they need the agility to support new needs as they arise, with complete end-to-end visibility.

The need for tight integration, despite the differences in the domains, is one of the biggest drivers for moving to a controller-based, fully abstracted architecture.

I’ve long believed that Cisco is uniquely positioned to create this holistic and end-to-end system, and to help businesses create these networks for their own uses. No matter which domain these critical transformation projects starts at, eventually they will need to end up in the same place: With a true multi-domain, any-to-any network controller architecture.

The Goal: Closing the Loop and Supporting Business Transformation

Business today requires infrastructure that responds to technical issues immediately and automatically – in machine time, not human time.

Our intent-based networking systems are designed to close the loop from intent, to activation, to continuous verification (Assurance) – quickly addressing deviation from the original intent.

Intelligence can enter the loop from several sources, including people and systems outside of Cisco: Our network controllers learn from their environment, providing intelligence to developers and partners, so they can add value in the feedback loop – for example, with smarter service desk tool, or automated troubleshooting systems.

The network systems can also be a part of larger business feedback loops. When the entire network is sensing its environment, that data can feed into systems that serve other purposes. For example, we can use the location intelligence our networks gather about the devices they serve, to inform business processes in a way that has simply not been possible before.

The ultimate challenge for this technology, though, is human. To run controller-based, programmable, intent-based networks, and to use the intelligence these networks generate for real transformation, our IT teams need new skills.

That’s why training and certification programs are part of our journey to intent-based networking. Education has always been in our DNA – we’ve been certifying technical personnel since 1993. We recently added new programs for app developers, too, recognizing the role these skills will play in the future of network management.

No matter how much we automate and simplify the management of networks, there will always be new opportunities to improve how a network works, to increase its efficiency, and to use it to help a business succeed. Our customers know where they need to take their technology. We’re going to help them get there.

Continue reading

Best Practices for Search Friendly Content, Cisco Marketing Velocity Style

Before we begin writing rank-worthy content, let’s first confirm our topic. Not every topic is relevant to search and there’s no need to search optimize an article if no one is looking for it. Opinion pieces and news are two examples of formats that have inherent disadvantages in search. No one’s really searching for them.

So begin by checking your topic against a few basic criteria:

◈ Does the article answer a question?
◈ Does it explain how to do something?
◈ Is it an “evergreen” topic that won’t quickly go out of date?
◈ Is it suggested by Google?

That last criteria makes it a sure bet it has SEO potential. If you see that Google is suggesting the phrase when you begin typing, it’s vetted as a search-friendly topic.

You’ve picked your topic, so you’ve picked your target keyphrase. Now we’re ready to begin constructing a search friendly article.

Tip! Keep in mind that the longer the keyphrase, the easier it is the rank for. Only the very famous websites will rank for one- and two-word phrases. Virtually any website can rank for the six- and seven-word phrases! 

1. Search-Friendly Title and Headline

The title tag (<title>) and the header (<h1>) should both include the target keyphrase, ideally at the beginning.

The title and the header don’t need to be identical. Headers can be long, but for the title tag, keep the total length to 60 words. This will keep it from getting truncated when Google uses the title as the link in Google search results.

Consider using punctuation such as parentheses or a colon to create double headlines. The first half should use the target keyphrase. This helps the rankings. The second half should use numbers, specific benefits or unexpected words. This helps the clickthrough rate.

Here are a few examples:

◈ Video Conferencing Tips for Sales Teams: 5 tips for better remote meetings

◈ Career Tips for Tech Support Professionals (and how to jump to a senior role)

◈ How to Configure a Switch to Be a Root Bridge: 3 Steps for Manual STP Setup 

2. Semantically Related Phrases

It’s good to use the target keyphrase in the body text. It’s even better to use the semantically related phrases. Which phrases are semantically related to your topic? Look around and you’ll find them everywhere:

◈ Other words suggested by Google when you search for your target keyphrase

◈ Phrases in the “Searches Related to” box at the bottom of the search results page

◈ Questions in the “People also ask” box

As you write, work these into your article. It’s good for rankings because it’s good for quality. A great page on your topic should also cover these related subtopics. It should answer all of the related questions.

3. Format for Scan Readers

If the visitor clicks on your search listing, but leaves after just a few short seconds, Google sees this as an indication that your article isn’t high quality and isn’t rank-worthy. So getting the visitor to stick around is important for maintaining your rankings.

How can we get the visitor to engage? By making the content easy to scan. That starts with short paragraphs. No one wants to read a long, dense block of text. So keep your paragraph length down to three or four lines.

Next, use lots of formatting to keep the scan readers flowing.

◈ Subheads

◈ Numbered lists and bullet lists

◈ Bolding and italics

◈ Multiple images, diagrams, charts

◈ Contributor quotes from experts

We all have to accept that visitors aren’t going to read everything. Research shows that on a typical visit to a typical webpage, visitors have time to read 28% of the words at most (20% is more likely)

Source: NN Group

But visitors are more likely to keep reading, even if the article is very long, as long as it’s formatted to be easily consumed. So break it up, add white space, and help scanners get to the information they’re looking for quickly.

4. Research, Data, Statistics

Some assertions are backed by evidence. The rest are simply unsupported claims. When you add research data, you are instantly more credible. Your case is stronger. Your message is supported.

Example: The last section of this article made an assertion (formatting is important because visitors are scanning) that was supported by data (NN Group found that visitors aren’t reading everything) making the point stronger.

Bring data to your articles. It will give you the opportunity to add visuals and it will make your content more likely to be cited by others in their content.

5. Internal Links

Finally, search-friendly content is interconnected. It has links from other pages which give it authority. But it also creates deeper paths into other content, helping to prevent the visitor from going back to search results.

Here is a list of links that work:

◈ A link to an older article

Never miss the chance to connect your new articles to high value content you’ve already created.

◈ A link from an older article to your new article

You’re not done publishing something new until you’ve linked to it from something old!

◈ A link to a product or service page (on our site or on Cisco)

Ideally, this content drives demand. You can trigger this by gently guiding visitors toward offers that relate to your content. Anytime you mention a product or service, link.

◈ A link to a related article on another Cisco partner website

We should build relationships with other Cisco partners, let them know what we’re working on. We should find out what they’re publishing. And then link to each other whenever possible. This can do wonders for our search rankings long term.

Our content should work together, and we can work together to make it work harder. Our content should never be isolated and our teams shouldn’t work on islands.

Building interconnected hubs of content that links from one article to the next, on our site and on other partner sites can give us huge and durable benefits in SEO. Build a network of content creators and sync your publishing calendars. This, plus quality and persistence, is the key to winning the top spot in search.

To become a true SEO pro and learn even more about the tactics described above, be sure to check out my latest webinars in Marketing Velocity Learning. SEO Principles and Practices provides an introduction to creating high-ranking content and Advanced SEO takes you beyond the keyword for a practical approach to the future of search.

Continue reading

Cisco DNA Center Network Operations Center Dashboard

Background

One common request from customers is a Network Operations Center dashboard view for Cisco DNA Center.  They would like this to be open-authentication (no need for credentials) and automatically refresh.  Critical data from Cisco DNA Center, such as network device and user health can be displayed and updated for the operations team on a large screen.

Using common tools like Influx (time series), telegraf (agent) and Grafana (visualization) (TIG) it is trivial to build a small dashboard and expose it via HTTP.  Many customers are already using these tools for other dashboards.

Telegraf-Influx-Grafana stack

The only real work I need to do is write a small python script to plug into telegraf to collect network and user health data from Cisco DNA Center and convert it to a simple JSON format.

For this script I am going to use the newly released Cisco DNA Center python SDK.

Getting started

The first step is to download the code from github and create a python virtual environment. The virtualenv is recommended, but optional.

git clone https://github.com/CiscoDevNet/DNAC-NOC.git

python3 -mvenv env3

source env3/bin/activate

Next install the python requirements (the dnacentersdk). It is a good idea to update pip first, as older versions may have issues installing the SDK.

pip install -U pip

pip install -r DNAC-NOC/requirements.txt

Now test the script to ensure it is working. By default the script will try to connect to the DevNet always on sandbox.  The data collected includes device health and counts as well as user (wired and wireless) health and counts.   There is more data that you can collect by modifying the script.

$ ./DNAC-NOC/dnac_assurance.py 

{"Core.count": null, "totalcount": 14, "WIRELESS-client.count": 80, "WLC.count": null, 

"WIRED-client.count": 2, "AP.count": null, "WIRED-client.value": 100, "Access.count": null, 

"totalscore": 100, "WIRELESS-client.value": 25, "AP.score": 100, "Router.score": 100, 

"ALL-client.value": 27, "Router.count": null, 

"Access.score": 100, "Core.score": 100, "WLC.score": 100, "ALL-client.count": 82}

Script Detail

There are two APIs used to get this data seen in the code below.

“get_overall_network_health” returns the health (and count) of the network devices. They are broken into categories (WLC, router,AP, access etc).  It requires a timestamp, but that can be left empty (returning the latest).

“get_overall_client_health” returns the health (and count) of clients.  In this case I need to provide a timestamp.  That is the current time (in epoch) converted to milli-epoch (i.e. multiply by 1000).

network_health= dnac.networks.get_overall_network_health(timestamp='')

timestamp = int(time.time() * 1000)

client_health= dnac.clients.get_overall_client_health(timestamp='{}'.format(timestamp))

Telegraf configuration

I am assuming you have telegraf setup and integrated into influxdb.  As there are many blogs outlining how to install these components, I will skip over these basic steps.

The custom python script above will be run every minute and update a time series database in influxdb.  The custom.conf file contains information on how to run the script.  You need to edit this file to change the path for the python virtual environment and the script.

Once you copy the script, restart telegraf so the custom script will be executed.  The script is called every minute as the client health score gets updated every minute.

sudo cp DNAC-NOC/telegraf.d/custom.conf /etc/telegraf/telegraf.d/

sudo systemctl restart telegraf

You will now see data being populated in influxdb.

$ influx

Connected to http://localhost:8086 version 1.7.8

InfluxDB shell version: 1.7.8

> use telegraf

Using database telegraf

> show field keys from "exec_dnac"

name: exec_dnac

fieldKey	fieldType
ALL-client.count	float
ALL-client.value	float
AP.score	float
Access.score	float
Distribution.score	float
Router.score	float
WIRED-client.count	float
WIRED-client.value	float
WIRELESS-client.count	float
WIRELESS-client.value	float
WLC.score	float
totalcount	float
totalscore	float

Grafana configuration

The final step is to import a json definition of the DNAC dashboard into gafana.

First browse to gafana homepage (typically port 3000).  The select “+” -> create -> import

Import Dashboard

Next select “upload .json file”

Upload .json File

The select “grafana/dashboard.json” from the files you downloaded from GitHub.

select dashboard.json from the “grafana” directory

Then select Import.

import dashboard spec

Very soon you should see the dashboard being populated.

First data

Continue reading

New Threat Grid App for IBM QRadar SIEM

Two years ago, Cisco and IBM Security announced a strategic alliance to address the growing threat of cybercrime. This collaboration builds on each organization’s strengths and complementary offerings to provide integrated solutions, managed services and shared threat intelligence to drive more effective security for our joint customers. We continue to develop new applications for IBM’s QRadar security analytics platform and the Cisco Threat Grid app for QRadar with DSM was just released.

Cisco’s Threat Grid App integrates with IBM’s QRadar SIEM, enabling analysts to quickly identify, understand and respond to system threats rapidly through the QRadar dashboard. Downloadable via the IBM Security App Exchange, this powerful app combines advanced sandboxing, malware analysis and threat intelligence in one unified solution.

Threat Grid + QRadar enables analysts to quickly determine the behavior of possible malicious files, which have been submitted to Threat Grid, and rapidly drill down from QRadar into the Threat Grid unified malware analysis and threat intelligence platform, for deeper insight. This integration expedites the threat investigation process, with a dashboard view into the highest priority threats, delivered directly through QRadar versus having to pivot on disparate tools and interfaces.

Detailed results from the sandbox analysis of Threat Grid can be aggregated by QRadar to determine whether the potential threats within the organization are malicious or benign. Malware samples are then assigned a Threat Score, and displayed by hash value and the user which submitted the sample.

This information displayed on the Threat Grid dashboard can be used to quickly resolve threats detected by QRadar. This results in improved efficiency and optimization for security analysts, by quickly identifying the top priorities for threat investigation.

With the QRadar DSM capabilities, you can see the analysis results over time.

Also, under Log Activity, for suspicious IP addresses, you can use the right-click to see instant contextual threat intelligence from Threat Grid.

Threat Grid also integrates with IBM Resilient Incident Response Platform (IRP) for automated response and X-Force Exchange for even greater threat intelligence enrichment. For example, analysts in the IRP can look up Indicators of Compromise (IoC) with Cisco Threat Grid’s threat intelligence, or detonate suspected malware with its sandbox technology. This empowers security teams to gain valuable incident data in the moment of response.

These technology integrations between Cisco Security and IBM Security enables a more extensive security architecture for greater speed and efficiency in identifying, investigating, and remediating threats. Together, we deliver the intelligence, automation and analytics required to provide data and insights that today’s security practitioners require.

Continue reading

Business Benefits of Segmentation with Software-Defined Access

The goal of moving applications to the cloud and integrating with SaaS platforms is to satisfy the growing demand for connectivity to data resources and applications at any time, from anywhere. However, achieving that goal with high levels of Quality of Experience (QoE) for applications depends on the enterprise wide area networks. Managing QoE connectivity among campus, branch, and cloud resources naturally increases network complexity. That translates into an increase in workload for IT teams to keep up with changing prioritization of traffic, network access rules, and data security policies.

But just because a network is complex doesn’t mean it has to be complicated. A Software-Defined Architecture (SDA) is the antidote for complicated. Separating data, control, and management planes makes networks both more flexible and manageable by automating many formerly manual tasks. A significant portion of those tasks are handled by Cisco Software-Defined Access (SD-Access) working at the controller plane level, reducing complexity and improving scalability and mobility of devices and the workforce.

Empowering IT with an Architecture for Access

When people, devices, and applications are located anywhere, automating the onboarding and provisioning of them with the correct access and security policies is paramount to maintaining control and security. SD-Access applies access and security policies generated by network intents. Translating intents into actions is the foundation of Intent-Based Networking, where higher-level business intents create network access and security policies that are automatically applied to devices and people to determine access rights and security privileges.

SD-Access simplifies network management, especially for segmentation and secure access policies, but also for operational consistency, increasing productivity, and a seamless experience. In this post, we will examine the business and security benefits of automating segmentation and access control.

Automation Simplifies Network Segmentation Management

To simplify the complexity of campus-branch-cloud connectivity, SD-Access shifts the workload from IT staff performing routine tasks of onboarding every individual device and managing network configurations, to building intelligence into the network itself. The network learns to manage itself by, for example, automatically onboarding specific device types with pre-ordained security and access policies that follow people and devices across the wired and wireless fabrics, from ground to cloud.

Automating access and segmentation is also critical for the successful integration and security of the Internet of Things (IoT) and the myriad types of devices that are being deployed throughout buildings, campuses, branches, and cloud edge. As sensors, cameras, and edge-processing applications proliferate, they need to be securely added to network segments with tight control over who and what can access them, and with which services they can communicate.

Video cameras, for example, should only communicate with a video server, not an application or web server. Placing cameras and their peer servers in one segment, isolated from other enterprise network assets, is a simple way to secure video devices. As additional cameras are connected, the network recognizes the device type and automatically adds them to the correct segment. Sudden changes in attempts to communicate with resources outside the segment can indicate a takeover attempt by malware, resulting in the network isolating the device  and thwarting the malware’s attempt to move laterally through the network.

The business benefits of automating onboarding of devices are plentiful: from eliminating the need to send technicians to remote locations to securely configure devices, denying access to unknown devices to prevent infections from spreading, and enabling IT to move from routine tasks to working on innovative projects.

Cisco SD-Access gives IT time back by reducing the effort it takes to manage and secure the network and improve the overall end-user experience.

Enforce Consistent Policies Across the Enterprise

Consistency is key to ensuring people, devices, and data resources all interact according to network policies. For enterprises with many regional locations, it’s common to have instances of Cisco DNA Center for each region to provide location-specific contextual insights for faster issue resolution and capacity planning. That could complicate the consistent application of policies. Fortunately, the regional Cisco DNA Centers can leverage a master instance of Cisco Identity Services Engine (ISE) so that SD-Access can apply access and segmentation policies across each region. With this capability, SD-Access ensures that security and access policies defined by corporate IT are implemented consistently across global networks, while enabling regional control over specific aspects of workforce and device rules.

Segmentation Eases Regulatory Compliance

With all the new privacy regulations coming online across the globe, being able to demonstrate compliance with these rules is paramount to avoiding legal battles and court fines resulting from data breaches. Employing SD-Access to define segmentation to keep private information strictly separated from other business data helps organizations prove they are in compliance.

Compliance with Payment Card Industry (PCI) regulations for protecting payment card information is an example of the business benefits of segmentation that SD-Access can manage. To comply with PCI standards, payment data must be kept separate from any other IT system and limit access to specific people and processes with no external internet connections—thus contained in a “PCI Island”. SD-Access creates microsegments that effectively isolate every device and application that “touches” payment data, effectively creating virtual PCI Islands where they are needed in a global network.

Building this level of segmentation would be difficult with a manual, case-by-case approach. Assigning people and compute resources to a PCI Island security group tag (SGT) simplifies segmentation, helping to maintain compliance, saving time and minimizing rigorous PCI testing. Securing payment and personal information this way also reduces the risk of exposing sensitive data in breaches.

SD-Access Directly Benefits Business Processes Across Industries

Every industry is moving applications and data to the cloud, some faster than others, but all driven by competitive pressures, operational changes, and regulatory demands.

◈ Healthcare organizations are methodically moving sensitive patient data to cloud platforms where it can be accessed by healthcare providers distributed across regions, while ensuring that access is strictly controlled and monitored for compliance.

◈ Pharmaceutical enterprises, which use acquisitions as a growth strategy, use SD-Access to simplify their network operations and the process of integrating IT operations by first segmenting resources during the acquisition process, and then uniting them by changing access policies across the board as the acquisition culminates.

◈ Government branches, consisting of dozens of agencies, use SD-Access to streamline, unite, and secure wired and wireless network operations among the distributed workforce in offices, branches, and in the field.

◈ Manufacturing facilities, which have a complex mix of IoT devices, mobile computing, and data center resources, use SD-Access to segment traffic to provide the appropriate SLAs for latency for time-critical manufacturing processes, keep malware from spreading should one device be infected, and provide secure workforce access to the appropriate applications.

◈ Financial institutions with highly distributed sites use SD-Access—along with SD-WAN—to securely connect branch and headquarter networks while ensuring that sensitive data is accessible only to employees with the appropriate access privileges.

While each industry has its own path for designing and building a software-defined architecture based on SD-Access, ISE, and Cisco DNA Center, most achieve breakeven results in about 14 months, an ROI of 300%, and cost savings of over 52%. In addition, business benefits often shared by Cisco customers are a 67% reduction in network provisioning costs, 48% reduction in the cost of a security breach, 80% reduction in cost to resolving networking issues, and 94% reduction in the cost to optimize policies.

It’s time for your organization to examine how to benefit from software-defined segmentation based on SD-Access.

Continue reading

Automating Your Network Operations: Focus on Outcomes

When I started this blog series, I had intended to present a cohesive approach to automating your network operations, eventually leading to DevOps. The intent was to take you beyond simply automating ad-hoc tasks using contrived examples to a more systematic way of automating your network operations (hence the title). Unfortunately, I completely failed because I presented it in an ad-hoc way. So in this blog, I am going to go back to the beginning: What are we trying to achieve?

Before I do that, I want to introduce a new blogger, Jason King. Jason and I have a very similar background in operations and development. We’ve both spent a large part of our careers on the front lines designing, building, and operating large systems and networks and hope to leverage that experience in our blogs, repos, and other works. With his help, hopefully we can get the series moving more smoothly.

Automated Humans vs. Automated Business

Do we just want a human to be able to perform a single operation faster? If so, then we might not actually achieve that. Why is this? Automation is geared at deploying single or multiple changes across a large number of devices. However, many changes do not fall into this category.

Engineering vs. CRUD

There are basically two types of changes that are made to a network in steady state operations:

◈ Architectural/Engineering: These are changes to the architecture of the network (e.g. Routing, QoS, Multicast) that generally affect the entire network. It is also the architecture for how new services are deployed (e.g. tenants, remote sites, etc.)

◈ Create, Read, Update, Delete (CRUD): These are changes that deal with delivery of network services to a particular customer or application (e.g. putting a port in a VLAN, adding an ACE to an ACL, or adding a load balancing rule).

The rigor of DevOps is absolutely the way to make major architectural changes to a network because of the network-wide effect that these changes have and the relatively small number of changes that occur.

CRUD is often different, however. While making a single change (e.g. SNMP Community Strings) on thousands of devices is an operation for which the overhead of DevOps is justified, that same overhead may significantly slow down operations involving a single change on a single device (e.g. changing a port VLAN).

The DevOps overhead is not necessarily a bad thing, even for small changes. There are significant advantages in enforcing configuration management, revision control, code review, and testing on every change. It does not, however, always make network operations faster or easier. This increased friction can make it unpalatable to many network teams and hinder adoption.

Constraints-based IT

There is also the Theory of Constraints with states that “any improvements made anywhere besides the bottleneck are an illusion.” (Eliyahu M. Goldratt, 2014)

This means that if you are automating processes that are not slowing down your business, you are not having an effect on your business. The entire effort is potentially a waste of time and money. That is why automation should begin with a thoughtful process that identifies the most important outputs of your infrastructure and what the current bottlenecks are in producing those outputs.

In general, automation is going to provide your business two main improvements:

When your enterprise produces customer value faster (e.g. onboarding new customer and/or offering new services), the business generally brings in more revenue. Adding a faster time to remediation (e.g. less maintenance and quicker trouble resolution) reduces operating costs and increases customer satisfaction. When done right, it is a powerful combination proves the best outcomes for any automation project.

This is why we must focus on automating business processes and not just humans. In fact, the best way to automate a business is to remove the human from the process, at least from that value chain between the customer’s request and the delivery of that request.

“If it does not have an API, it does not exist”

– Mitchell Hashimoto

Automating Business Processes: API-Driven Automation

When we consider how to automate business processes, we must focus on reducing the time between the time a customer requests a new service and the time they receive that service. Humans, generally, are not the best way to reduce this time, which is where APIs come in. APIs allow each step of the process to be automated.

For example, when a user wants to add a firewall exception for a new server, they can go to a self service portal to make that request. That request can then go through the review process to make sure that it is aligned with business policies (hopefully automatically) and appropriately approved. Once it is approved, the ITSM pokes the automation framework through an API to begin the delivery of the service. The advantages of this approach is that:

1. It takes the network team out of the CRUD

2. It allows the network team to define and put checks around how changes to the network are performed

Hold the phone!

We are going to let a customer request a complex service with potentially harmful repercussions without having a human in the loop??? Well … yes. But even if you do need a human in the loop, you don’t need an entire team of them in the loop. And in either case, that is why DevOps is important. DevOps is not just automation, it is the development, testing, deployment, and validation of the artifacts that provide the service. If you properly develop and test these artifacts, you can be reasonably assured that the process does not go pear shaped. If you do the proper validation of deployed services, you can “fail fast” back to a previous version of the artifacts.

DevOps is the safety harness for automation, but that does not mean that you cannot start automating without it. In fact, very few organizations are able to implement a righteous DevOps pipeline in one go. The DevOps journey should be viewed as a stepwise approach to delivering business value. In this blog, we have provided some criteria for how to determine what to automate in order to achieve maximum value. You should not automate just to automate. Start with automation that addresses your critical business needs that fall into the categories outlined above, but always keep an eye on the end goal of building toward DevOps processes and, ultimately, business transformation.

What’s next?

Well, instead of writing blogs over the past 6 months, we’ve been working with a team of people to create a CI/CD pipeline for SD-WAN. Not a set of examples of what you could do, but a fully functional, operationally righteous framework that we and our customers use in their operations. To get there, we wrote Ansible modules for Viptela, VIRL, NFVIS, and PyATS that automate every step of the process. We’ll cover this in our next blog, followed by an in-depth treatment of each component and how to consume it individually on your stepwise path to DevOps.

Continue reading