Shining a Light on Shadow IT

But there is another ecosystem of applications and hardware besides IoT devices to manage in the realm of Shadow IT. From the old days of departments buying OTS packaged software for special projects, to today’s BYOD to work, organizations struggle with un-vetted and unauthorized information technology accessing sensitive personal and business data. IT SecOps deploys a wide range of security processes to gain some control over these proliferating endpoints in enterprise networks—often with limited success. The proof of that, unfortunately, is in the growing number of successful malware infections and data breaches that use these unregulated endpoints as gateways to the network crown jewels.

Cisco recognizes that security is foundational to the network itself. When you apply identity and security policies consistently throughout the network fabric, Shadow IT devices and applications become part of the managed ecosystem, and not outliers operating under their own security parameters. So when the Finance department, for example, decides to purchase and use only iPad tablets to access SaaS financial applications, only iPads tagged as part of the “Finance” network have access to the apps. Meanwhile, HR’s Surface tablets are assigned policies to send and receive data from SaaS HR apps, not financial data. These policies enforce network intentions.

Policies are codified network intentions that manage and automatically configure access privileges for devices and their associated applications. By assigning policies at the device level, or groups of devices, the network automatically adapts to changes, such as location, ownership, and signs of infection. Let’s look at how intent-based networking simplifies the management of Shadow IT devices and applications—and everything else.

Detecting and Identifying Shadow IT Devices 

Control of Shadow IT begins with locating and identifying devices and applications as they connect to the network. Cisco Identity Services Engine (ISE) scans the network, cataloging in DNA Center all devices or services operating on the wireless and wired network segments. ISE automatically tags rogue devices with policies that limit their access and connectivity until their legitimacy is verified and appropriate security policies applied. In essence, ISE prevents Shadow IT from accessing sensitive data sources without the knowledge of IT.

Providing Persistent Security with Software-Defined Segmentation

After shadow IT devices are identified and tagged by the ISE and cataloged in DNA Center, the concept of micro-segmentation comes into play with Cisco SD-Access. The goal is to apply policies to devices that follow them around the network—campus, wireless, WAN, mobile—virtually segmenting them according to the defined network intentions. The security for any device is therefore persistent, no matter where the device may roam.

For example, the tablets purchased by the finance department can join the network anywhere in a wireless campus environment, yet are constrained to specific data sources to which they can connect. The policies attached to tablets in a virtual segment can also maintain a higher quality of service with priority for traffic to the SaaS financial applications, versus a lower level of service for streaming video from the internet. Devices that have internet exposure are monitored for malware, with policies that automatically isolate an infected device from the rest of the network. This capability is especially critical with Shadow IT devices which may not have up-to-date security patches.

Cisco provides several technologies to manage virtual software-defined segmentation, all working under the umbrella of DNA Center. Tagging individual or groups of devices to create software-defined segments with security policies is automated with Cisco Trustsec, which works in conjunction with ISE. A department’s Shadow IT devices can be tagged as one group and security policies applied consistently no matter where the device connects to the network. Security tagging plays a critical role in compliance too, by ensuring, for example, that payment card data touches only specific groups of devices. Cisco Stealthwatch is a third component working with ISE and Trustsec that is critical to managing Shadow IT. Once devices are cordoned into software-defined segments, Stealthwatch monitors their health to detect any infections such as zero-day malware or ransomware and quarantines the offending devices and connections.

Managing Shadow IT in the Multi-Cloud

The growing use of public and hybrid clouds are another reason to better manage Shadow IT. Recent IT surveys show that the average organization uses over 1,427 different cloud services. When a department decides to use a file-sharing platform, subscribe to a SaaS CRM application, or run apps on AWS, they are doing so to improve efficiency and ease of use. Doing so, of course, opens up connections between sensitive enterprise data and third-party clouds, the security of which are beyond SecOp’s immediate control. With the capability to apply security and access policies, an intent-based network plays a critical role in controlling data inside and outside the enterprise.

For enterprises that have multi-cloud projects—whether officially condoned or emerging from the shadows—the Cisco DNA Center open cloud management platform provides granular control of how devices connect to cloud resources and defines how data flows among data center, public and private clouds, and SaaS platforms. Assigning traffic segmentation policies for public and private clouds creates end-to-end segregation with device and application-aware topologies that select the best paths to achieve desired SLAs and optimum application experience for both sanctioned and shadow technology.

Take Back Control by Integrating Shadow IT into the Network Ecosystem

Shadow IT projects will continue to take root and proliferate throughout enterprise networks. With the ubiquitous availability of cloud apps, mobile devices, and freemium services, employees will find ways to make their work life more efficient, easier, and indeed fun. Instead of fighting rogue devices and applications, IT can exert control over shadow IT by integrating the devices and services into the network ecosystem. With intent-based networking, IT can automate the application of policies to keep data secure while expanding the choices of devices and applications that employees and departments can use.

Continue reading

Why download the exploit, when you can carry it with you?

For the 2nd year, RSA Conference 2018 APJ created an educational exhibit, sponsored by RSA and Cisco, to monitor the RSA Conference public Wi-Fi network provided by the Marina Bay Sands (MBS). This exhibit was created in the form of the RSA Conference Security Operations Center (SOC). RSA and Cisco provided technology and staffing to monitor the network for threats, but also to educate attendees on the risks of free Wi-Fi.

What is the difference between a SOC and a NOC?

Network Operations Center

The NOC is usually responsible for monitoring and maintaining the overall network infrastructure—its primary function is to ensure uninterrupted network service

Security Operations Center

The SOC is responsible for protecting networks, as well as web sites, applications, databases, servers and data centers and other technologies

RSA and Cisco provided the SOC. The NOC was provided by the MBS.

The mission of the RSAC SOC was to ensure the conference Wi-Fi is not attacked (denial of service, laterally spreading malware, etc.). We did not block malicious DNS traffic, downloads or attachments; as this was a learning and demonstration environment. We make sure that network is protected from attackers. We locate (when we can) and advise users when they are at risk.

What technology is in the RSAC SOC?

MBS provided the RSAC SOC a span of all network traffic from the .RSAConference network, which was passed through the Cisco Next Generation Firewall / ISP and then split the traffic to NetWitness Packets NetWitness Packets and the Cisco Stealthwatch teams.

RSA used NetWitness Packets to collect and investigate all traffic on the Wi-Fi network, from the firewall; to detect deviations from normal behavior and create a probability-weighted risk score for alerts based on these results. NetWitness inspects every network packet session for threat indicators at time of collection and enriches this data with threat intelligence and business context. At the end of the conference, all of this data was wiped from NetWitness.

For suspicious files that might be malicious, NetWitness Packets checks a community AV lookup, some static analysis and its own network intelligence. Then the NetWitness Orchestrator sends the files to Cisco Threat Grid for dynamic malware analysis.

Threat Grid combines advanced sandboxing with threat intelligence into one unified solution to protect organizations from malware. Threat Grid analyzes the behavior of a file against millions of samples and billions of malware artifacts. The SOC team had a global and historical view of the malware, what it’s doing and how large a threat it posed to the RSAC network.

Threat Grid identifies key behavioral indicators of malware and their associated campaigns. The SOC team was able to save time by quickly prioritizing attacks with the biggest potential impact. We used tools like Glovebox, to safely interact with samples and observe malware behavior directly. In addition, we used Cisco Umbrella to have visibility in all DNS activity. We also used the Threat Intelligence of Cisco Visibility and Talos Intelligence.

When the Cisco team found a potential threat, they handed it off to the RSA team for further investigation. In summary, the technology stack was:

◈ Firewall – Cisco Next Generation Firewall with IPS
◈ Full Packet Capture and Investigation – RSA NetWitness Packets
◈ Orchestration – RSA NetWitness Orchestrator, powered by Demisto
◈ Dynamic File Analysis – Cisco Threat Grid
◈ DNS / IP Intelligence – Cisco Umbrella / Cisco Umbrella Investigate
◈ Encrypted Traffic Analytics – Cisco Stealthwatch and Cognitive Threat Analytics
◈ Threat Intelligence – Cisco Visibility

Identifying endpoint vulnerabilities without an agent

Cisco’s Next Generation Firewall was set up as the perimeter Firewall for the wireless connection of the RSA APJ event. All traffic to and from wireless guests went through the Firepower Threat Defense (FTD). FTD not only detected threats, but also discovered what was running on the network endpoints; such as Operating Systems, Ports, Applications and Files.

Discovered Applications

Discovered Files

Geolocation Information

During the conference, several threats were detected, and we were able to see the total Connections and Bytes connecting to known bad IP Addresses.

We were also able to see the Total Intrusion Events detected per Classification.

FTD automatically correlated threat events with the contextual information discovered to identify which IPS events to prioritize for further investigation. This was reflected via Impact Flag 1 events. Data showed that there were 31 events to be prioritized.

Impact Flag 1 events shown below.

Checking the Rule documentation of the BMP overflow IPS event, it shows that it is applicable only for traffic coming from external network to internal network.

And, applicable if the target host has this vulnerability, with cve.mitre.org documentation included.

Checking on the event we confirmed that the event is coming from the Internet going inside the network. IPS Event Details below.

Checking on the host profile, we confirmed the target host had this specific vulnerability.

Vulnerability list of the target host based on the discovered Operating System and Applications.

Why download the exploit, when you can carry it with you?

On the 2nd day of the Conference, the SOC team observed a .DOC file sent to a conference attendee in a plain text email, along with several PDFs. The .DOC file was extracted by NetWitness and had a score of 0 from the RSA Malware Analysis Community lookup, meaning it had never been detected by an AV vendor. The Static Analysis score was 80, making it worth a review, and the Dynamic Analysis/Sandbox score from Threat Grid was 100, meaning confirmed malicious based on behavior. The team went into action to assess the threat.

The .DOC file was assigned a Threat Score of 100 for the Behaviors of launching Powershell and creating an Executable File.

We were able to see the code in the document to create and launch the eng.exe file.

After the creation of the executable, the malware dropped some artifacts on disk that are known to be used by remote access Trojans and opened communication with a domain on the Umbrella block list for Malicious.

We pivoted to Umbrella Investigate to learn more. If we had AMP for Endpoints deployed on the endpoints in the network, we would have instantly been able to see affected endpoints and remediate.

In Umbrella Investigate, we learned more about the domain, including the global requests for the campaign.

Most affected computers from the United States.

We found the hosted IP address 5[.]79[.]72[.]163 (link to the Investigate report) and then went into Cisco Visibility to access the global Cisco threat intelligence and to see if there were more associated IPs.

With this intelligence, we were able to go to the Firewall and NetWitness teams and check if there was any outbound communication to those three IP addresses. There were none, indicated the person who received the email did not open it on a vulnerable endpoint at the conference.

Everything an attacker needs for spear phishing lures

Threat Grid currently supports the following file types for analysis:

For RSAC SOC, the NetWitness team focused on submitting the following file types, with the distribution in parenthesis:

◈ .PDF (93%)

◈ .EXE (4%)

◈ .DLL (2%)

◈ .DOC/X (<1%)

◈ .XLS/X (<1%)

We saw many invoices, billing statements and confidential business proposals as attachments to emails sent with unsecure protocols, such as POP3 and HTTP. Each could be used by an attacker, sniffing the public network; to craft a custom spear phishing lure, as they had legitimate business and financial information; such as the email addresses of the sender/receiver, account information, billing address and the types of products/services the email recipient expected to receive.

Cryptomining

At Black Hat Asia 2018 in March, we saw a massive increase in cryptocurrency mining. Also, with the Black Hat training courses, there were 20 times as many domains of concern for roughly the same amount of DNS requests, around 5 million for each of the conferences in Singapore.

There was much less Cryptomining at RSAC; however, several common sites were active:

◈ widgetsbitcoin[.]com (links to the Umbrella Investigate report)

◈ api.hitbtc[.]com

◈ ws022.coinhive[.]com

◈ coinhive[.]com

◈ cdn.mngepvra[.]com

◈ authedmine[.]com

◈ coin-hive[.]com

◈ coinone.co[.]kr

When we saw the cryptocurrency mining activity based on Umbrella DNS request, Stealthwatch provided the visibility into endpoint without an agent/connector. Below is the dashboard of Cognitive Cloud Analytics (CTA). Together with Cisco Stealthwatch Enterprise, CTA is part of Cisco Encrypted Traffic Analytics. This solution can detect malware hiding in encrypted traffic without decrypting the data.

Upon investigate into “High Risk” and “Confirmed” event. There were three endpoints identified to have cryptocurrency mining activity at the time of investigation.

Below is the snapshot of the endpoint activities related to cryptocurrency mining.

Together with Umbrella, we could identify endpoint with initial cryptocurrency mining DNS request and detail HTTPS request to the server with Stealthwatch Enterprise and CTA.

Continue reading

Open vRAN Update: NETCONF/YANG Comes to 5G RAN!

One of the key principles of the Open vRAN ecosystem that Cisco and its ecosystem partners announced earlier this year, is to establish open, standard interfaces and management for vRAN. Recently the xRAN Forum has defined the use of IETF’s NETCONF/YANG standard for programmatically configuring and managing its lower layer split RAN architecture.

We are proud to have taken a lead role, working closely with top tier operators and other vendors (including ecosystem partner Mavenir), in helping the xRAN Forum define the use of NETCONF/YANG by the 5G Radio Unit. We are excited about this for many reasons. Not only will the use of native YANG models ensure the easiest route to full multi-vendor interoperability in the future disaggregated RAN, but it should also ease the integration of the management for the lower layer split deployment into existing systems.

Let’s break down what this means. YANG (RFC 7950) is a modelling language that is used by xRAN to model the configuration and operational state of its 5G Radio Unit, together with defining remote procedure calls (RPCs) for supporting tasks like software management, and notifications for indicating xRAN defined alarms. Because YANG defines syntax, relationships and constraints between the data, it enables operators of xRAN’s lower layer split to validate configuration data against the model before committing the configuration of the xRAN Radio Units.

The use of augmented IETF standard YANG models, together with xRAN specific models, lays the foundation for cross-domain orchestration of the RAN with other domains that have already adopted NETCONF/YANG. Recognizing that xRAN Radio Unit suppliers need to be able to support vendor differentiation, the YANG models are extensible, allowing them to be augmented to support enhanced vendor-specific functionality, while simultaneously ensuring baseline multi-vendor interoperability of the standardized functionality defined by xRAN.

With the results of xRAN’s work now public, all Open vRAN Ecosystem members have endorsed these early deliverables as an important first step towards the evolution of a truly open and virtualised RAN.

Continue reading

5 Reasons Cloud UC and BroadSoft Are Top of Mind

There, my Cisco colleague Andy Johnston and I shared an overview of the cloud unified communications market to a standing-room‑only audience. We described how the combined strength of the Cisco and BroadSoft calling portfolios are helping you accelerate transitioning to cloud.

I’d like to highlight five key reasons why I think our overview resonated so well.

1. Customer cloud UC perceptions have changed

We recently conducted a survey with over 1,000 IT decision makers from seven countries. In it, we learned that cloud UC is a key priority of their digital transformation strategies. 74% of respondents said they will choose a cloud provider in the next 24 months.

2. SMBs need native mobile

Mobile working has many benefits. Many small businesses are ditching their on-premises solution and going mobile first for both cost and efficiency reasons. One of our portfolio’s most unique and innovative differentiators is our ability to deeply integrate communications within the core mobile network. This allows our mobile carrier partners like Verizon, Vodafone, Telstra, Deutsche Telekom, and Rogers to deliver a fixed-mobile converged experience that helps SMBs become more agile and productive, and appear bigger and stronger.

3. Mid-market needs enterprise-grade features without cost and complexity

Mid-market organizations need enterprise-grade features and a way to seamlessly and reliably network their PBX and cloud applications. This includes:

◈ a common network dialing plan

◈ a consistent collaboration experience across locations

◈ centralized and local administration capabilities

In addition, they need simplicity, on-demand scalability, global scale, and reliable communications for remote and mobile employees.

4. Flexible and smooth transition to cloud

Transitioning to the cloud will take some time for mid-sized and large enterprises that have large investments they simply cannot replace overnight. A 2017 study by global research firm Nemertes suggests that more than 70% of enterprises are still running TDM to at least half of their endpoints. You need solutions that both maximize the life of in-place investments and allow you to network with cloud solutions via SIP trunking for new locations, expansions, branch offices, contact centers, and mobile workers.

5. Cloud UC offers a better total cost of ownership

Cloud is a natural and more economical solution for new sites, site expansions, and smaller branch offices. In our survey:

◈ 68% of respondents believe their current on-premises systems are too expensive to maintain

◈ 70% believe cloud will reduce their IT staff efforts

◈ 69% say their current systems don’t have the advanced features they need

For many, cloud contact centers will offer more capabilities, on-demand flexibility, and superior multisite and remote-agent support. In fact, 88% of premises-based contact center users are considering moving to CCaaS, with 68% in active evaluation.

The Transition Zone

For all these reasons, we’ve developed a thoughtful technology plan that provides a smooth network transition from on-prem to cloud. A hybrid model that ensures user adoption helps you realize value more quickly and move at a pace that makes sense for your organization.

Flexible and affordable migration strategies with hybrid configuration support allow you to implement a cap-and-grow strategy. You maintain your in-place investments until they reach the end of their natural life-cycle, then transition to cloud when the time is right.

The Cisco Collaboration Flex Plan decouples the purchasing and deployment so that you can choose on-premises, hosted, or cloud options. You can move your organization, specific users, specific sites, or individual applications when it suits you in a flexible, phased approach that addresses all your needs.

This level of flexibility is available today. As you look to make your cloud transition, consider a vendor that can provide a complete solution that looks not only at your PBX requirements, but addresses your mobility and voice conferencing needs as well.

Cisco and BroadSoft are in a prime position to help you make the transition and migrate while leveraging your existing investments.

Continue reading

Top 7 Multicloud Initiatives – Delivering on the Multicloud Promise

According to IDC, by 2021, enterprises’ spending on cloud services and cloud-enabling hardware, software, and services will more than double to over $530 billion, leveraging a diversifying cloud environment that is 20% at the edge, more than 15% specialized (non-x86) compute, and more than 90% Multicloud. A high majority of enterprise IT organizations out there want to adopt multicloud now. It is thrilling to see enterprises around the world undertaking the key initiatives necessary to transform and stay ahead of the game in a multicloud era. Let’s examine what it takes to deliver the promise behind these initiatives.

Multicloud Journey – Before the “How”, Consider the “Why” and “What”

Embracing a multicloud world is important to increasing the pace of innovation for every company today. But it can be daunting to even large IT organizations to embark upon the multicloud journey due to seemingly never-ending complexity, fragmented solutions that got implemented over time, and no consistency or data control. IDC found that about 89% of enterprises today do not have an actionable and optimized plan for cloud. Faced with CIO directives and urgent timelines, IT teams today are under extreme pressure to claim progress in adopting multicloud. Before getting into the “how” or even a POC, enterprise IT oranizations should consider the “why” and the “what” for their selected initiatives.

The “why” is about aligning the selected initiatives to needed business outcomes. For example, is IT management looking for cost reduction, agility, much-needed application technology enhancements, or on-demand and efficient scaling of IT, a competitive differentiator, or expanding the business?

The “what” is about capturing your multicloud requirements, prioritizing them, identifying dependencies, and scoping what you want to accomplish and by when. This involves coming up with distinct but connected initiatives that can be phased or accomplished in a complementary fashion.

Cisco’s multicloud approach and Multicloud Portfolio helps enterprise IT teams that are trying to take on a multicloud journey to determine the “why” and “what” and produce definitive multicloud requirements and an actionable plan.

Here are key multicloud initiatives that enterprises around the world are considering. All these initiatives may not apply to every enterprise, and, in general, an enterprise may require additional initiatives based on their cloud adoption maturity and specific application needs.

1. Connect DC/Campus, CoLo, and Cloud

When enterprise IT organizations decide to a public cloud as part of their IT technology mix, this initiative becomes important. It involves connecting data centers or campuses directly to the cloud or via a colocation option. Secure connectivity to a public cloud includes considering having a CoLo in between DCs and the cloud for various reasons like backup, data sovereignty, and a high-speed connection to cloud infrastructure on the backend.

2. Connect Branches Direct-to-Cloud

When enterprise IT organizations with branches decide to have significant numbers of applications migrate to a public cloud or subscribe to SaaS offers, the branch’s connectivity direct to the cloud becomes important in delivering the best application user experience. Also, with the increased needs of edge computing and local analytics, it is paramount to have better and direct connectivity to the cloud applications from the edge. It essentially involves connecting branches directly to the public cloud application environments (including SaaS applications) using SD-WAN solutions with the high-speed Internet service providers locally available to each branch, as well as DNS security.

3. Build and Manage a Hybrid Cloud

Modernization has been a key driver for IT organizations, with various projects supporting it, including the adoption of a public cloud in the IT mix and transforming the consumption of IT on-premises into a cloud-like experience. According to a recent IDC survey, 87% of enterprises that are using the cloud are taking steps towards creating and managing a hybrid cloud. A hybrid cloud is essentially an application infrastructure configuration that has both an on-premises private cloud and a public cloud for deploying applications in a hybrid model. An example is when the data tier is running on-premises with the web and app tier running on the public cloud.

4. Migrate and Manage Applications to Public Cloud

This is the most common initiative that enterprise IT management is asking their IT engineering and LOB engineering teams to tackle, and it has the potential to be the riskiest journey that IT can take. Many enterprises migrated applications to a public cloud and then brought them back on-premises due to various reasons they did not anticipate. This initiative requires careful selection with dependency analysis, meticulous planning, and end-to-end management of the applications to be migrated to a public cloud.

5. Manage Cloud-Native Applications in Public Clouds

With the onset of mature container technology and proliferation of cloud services, enterprise IT organizations and LOBs are driving the creation of new cloud-native applications or re-platforming existing applications to not only run the application better with scale at every microservice that is part of the application but to leverage cloud-native services that the application can use, such as auto-scaling of underlying Kubernetes on-prem as well as on the public cloud, serverless and cloud-agnostic application environments, and much more. Traditionally such capabilities required multiple management tools, but now auto-scaling is an attractive way to run the applications. This initiative requires bringing together networking, security, analytics and management for the cloud-native apps to span both on-premises and public cloud.

6. Burst Applications Into Public Cloud

Enterprise IT organizations are familiar with this strategy of extending on-premise capacity (aka bursting) for certain applications from the data center or private cloud to a public cloud infrastructure on-demand for application runtime needs. A good example of this can be found with retailers that have on premise ecommerce processing applications, but due to seasonal demands, that application footprint and sale is not enough to manage the ecommerce demand. This initiative also is becoming common among the emerging artificial intelligence (AI) applications that burst into the designated public cloud compute infrastructure, especially for analyzing the “hot” data at the edge along and expanding compute-crunching needs.

7. Optimize SaaS Application Connectivity and Security

Along with public cloud infrastructure adoption, software-as-a-service (SaaS) offers the enterprise a tremendous opportunity to realize an application’s business benefits by “renting” the application use vs. stretching to handle the management responsibilities of running it, updating it, etc. themselves.

Over the last 5+ years, SaaS delivery models for applications have demonstrated their ease of use, breadth, and affordability of packaged applications in a fraction of the time and for a fraction of the cost of traditional models. But SaaS also changes the role of IT. Enterprise IT organizations can no longer guarantee that SaaS providers will meet IT’s compliance standards or use any leverage to negotiate better terms and conditions. Also, IT can do little to ensure the performance of SaaS offers from various enterprise offices, which rely on local Internet service providers – and the unpredictable internet access networks—who can impact the consistency of SaaS delivery, even in regions with highly developed Internet infrastructure. This initiative uses SD-WAN capability to optimize the network path and keep it optimized.

Below is an example of how Cisco’s multicloud approach addresses the “how” in order to deliver on the promise of multicloud when it comes to an organization’s initiative to migrate applications to a public cloud.

By offering a simplified approach to answering “how,” our multicloud approach helps organizations understand the capabilities needed for their chosen initiatives in order to easily and confidently select the foundational products needed for the design and implementation stages of their multicloud initiatives.

Continue reading

Render your first network configuration template using Python and Jinja2

We all know how painful it is to enter the same text in to the CLI, to program the same network VLANs, over, and over, and over and over, and over…. We also know a better way that exists, with network programmability, but this solution could be a few years out before your company adopts the newest network programmability standards.  What are you to do???

Using Python and Jinja2 to automate network configuration templates is a really useful way to simplify repetitive network tasks, that as engineers, we often face on a daily basis. In using this alternative method to automate our tasks we can remove the common error mistakes experienced in the copying/pasting of commands into the CLI (command line interface). If you are new to network automation, this is a fantastic way to get started with network programmability.

Firstly, let’s cover the basic concepts we will run over here.

◈ What are CLI Templates? CLI templates are a set of re-usable device configuration commands with the ability to parameterize select elements of the configuration as well as add control logic statements. This template is used to generate a device deployable configuration by replacing the parameterized elements (variables) with actual values and evaluating the control logic statements.
◈ What is Jinja2? Jinja2 is one of the most used template engines for Python. It is inspired by Django’s templating system but extends it with an expressive language that gives template authors a more powerful set of tools.

Prerequisites: 

Jinja2 works with Python 2.6.x, 2.7.x and >= 3.3. If you are using Python 3.2 you can use an older release of Jinja2 (2.6) as support for Python 3.2 was dropped in Jinja2 version 2.7. To install this use pip.

pip install jinja2

Now we have Jinja2 installed let us take a quick look at this with a simple “Hello World” example with Python. To start with, create a Jinja2 file with “Hello World” inside (I am saving this into the same directory I am going to write my python code in). A quick way to create this file is with echo.

echo "Hello World" > ~/automation_fun/hello_world.j2

Now let us create our python code. We import Environment and FileSystemLoader, which allows us to use external files with the template. Feel free to create your python code in the way you feel is best for you. You can use the python interpreter or an IDE such as PyCharm.

from jinja2 import Environment, FileSystemLoader

#This line uses the current directory
file_loader = FileSystemLoader('.')

env = Environment(loader=file_loader)
template = env.get_template('hello_world.j2')
output = template.render()
#Print the output
print(output)

Use the following command to run your python program.

STUACLAR-M-R6EU:automation_fun stuaclar$ python hello_template.py
Hello World

Congratulations, your first template was a success!

Next, we will look at variables with Jinja2.

Variables With Jinja2

Template variables are defined by the context dictionary passed to the template. You can change and update the variables in templates provided they are passed in by the application. What attributes a variable has depends heavily on the application providing that variable. If a variable or attribute does not exist, you will get back an undefined value.

In this example, we will build a new BGP neighbor with a new peer. Let’s start by creating another Jinja2 file, this time using variables.  The outer double-curly braces are not part of the variable, what is inside will be what is printed out.

router bgp {{local_asn}}
 neighbor {{bgp_neighbor}} remote-as {{remote_asn}}
!
 address-family ipv4
  neighbor {{bgp_neighbor}} activate
exit-address-family

This python code will look similar to what we used before, however, we are passing three variables

from jinja2 import Environment, FileSystemLoader
#This line uses the current directory
file_loader = FileSystemLoader('.')
# Load the enviroment
env = Environment(loader=file_loader)
template = env.get_template('bgp_template.j2')
#Add the varibles
output = template.render(local_asn='1111', bgp_neighbor='192.168.1.1', remote_asn='2222')
#Print the output
print(output)

This will then print this output, notice that as we have repetitive syntax (the neighbor IP address), the variable is used again.

STUACLAR-M-R6EU:automation_fun stuaclar$ python bgp_builder.py
router bgp 1111
 neighbor 192.168.1.1 remote-as 2222
!
 address-family ipv4
  neighbor 192.168.1.1 activate
exit-address-family

If we have some syntax that will appear multiple times throughout our configuration, we can use for loops to remove redundant syntax.

For Loops with Jinja2

The for loop allows us to iterate over a sequence, in this case, ‘vlan’. Here we use one curly brace and a percent symbol. Also, we are using some whitespace control with the minus sign on the first and last line.  By adding a minus sign to the start or end of a block the whitespaces before or after that block will be removed. (You can try this and see the output difference once the Python code has been built). The last line tells Jinja2 that the template loop is finished, and to move on with the template.

Create another Jinja2 file with the following.

{% for vlan in vlans -%} 
    {{vlan}}
{% endfor -%}

In the python code, we add a list of vlans.

from jinja2 import Environment, FileSystemLoader

#This line uses the current directory
file_loader = FileSystemLoader('.')
# Load the enviroment
env = Environment(loader=file_loader)
template = env.get_template('vlan.j2')
vlans = ['vlan10', 'vlan20', 'vlan30']
output = template.render(vlans=vlans)
#Print the output
print(output)

Now we can run with python code and see our result.

STUACLAR-M-R6EU:automation_fun stuaclar$ python vlan_builder.py
vlan10
vlan20
vlan30

All of the code for these examples can be found on my GitHub https://github.com/bigevilbeard/jinja2-template

Continue reading

Python Scripting APIs in Cisco DNA Center Let You Improve Effectiveness

Just before I left for Cisco Live US, I was given the chance to work with the APIs on Cisco DNA Center. Having never used Cisco DNA Center this was a quick learning curve, but once I started I could see some great possibilities and some more coding fun to be had! Once back from Cisco Live US, where I learned even more about DNA Center (an awesome experience), I was excited to expand my knowledge and leverage some fun python code using the APIs that DNA Center has to offer.

Dude, where is my DNA Center sandbox?

All the Python code you are about to see and learn about can be used on the DNA Center Always-On Sandbox. I used this for the creation of the code and documentation for this blog post and testing/building this code. This DevNet Sandbox lets you:

◈ Access at any time without making a reservation or using VPN connection

◈ Learn the DNA Center GUI or experiment with the REST API

◈ Access a pre-configured network topology running on genuine Cisco hardware

Because this sandbox is always available to all users, any other user may potentially overwrite your work at any time. The other caveats to an always-on DNA Center sandbox are… you cannot configure the network or devices and you cannot activate and enforce policy on network devices. I should also note there is other DNA Center sandbox’s that are reservable which provides your own private lab environment for the duration of the reservation.

Network device’s script, simple and easy to create

By the end of this blog post, you will learn:

◈ How to use the DNA Center APIs

◈ How to use the DNA Center APIs in a Python script

I have started with a simple Python script.  The Python script uses the DNA Center APIs to get device information. The APIs provide a list of all of the network devices the DNCA controller knows about and all of their attributes. For example, hostname, serial platform type, software version, uptime, etc. You can either get all of the devices or a subset. The script print to console using PrettyTable is a simple Python library designed to make it quick and easy to represent tabular data in visually appealing ASCII tables.

DNA Center Sandbox Network Topology, access anytime

Using DNA Center APIs

By looking at the API Catalog within DNA Center you can see this contains documentation about each API call, including the request method and URL, query parameters, request header parameters, responses, and schema, along with ways to preview or test the request.

Pre-Requisites

In order to run the code featured here, you must have Python 3.6 installed. We will use the following Python packages listed below.

◈ requests

We will use this to make HTTP requests

◈ prettytable

This will be used to generate ASCII tables in Python

We must also import HTTPBasicAuth from requests.auth. This can be all installed by using the requirements.txt file on the GitHub repo (link below).  Use pip to install the requests libraries as shown below:

pip install -r requirements

Authentication

The DNA Center APIs use token-based authentication. Token-based authentication works by ensuring that each request is accompanied by a signed token which is verified for authenticity and only then responds to the request. This POST function logs in retrieves a token the request and returns the response body.

def dnac_login(host, username, password):

    url = "https://{}/api/system/v1/auth/token".format(host)

    response = requests.request("POST", url, auth=HTTPBasicAuth(username, password),

                                headers=headers, verify=False)

    return response.json()["Token"]

The next Python function uses the network-devices API. As mentioned above the APIs provide a list of all of the network devices the DNCA controller knows about and all of their attributes. Here we are using the GET Method. GET is used to request data from a specified resource, GET is one of the most common HTTP methods.

def network_device_list(dnac, token):

    url = "https://{}/api/v1/network-device".format(dnac['host'])

    headers["x-auth-token"] = token

    response = requests.get(url, headers=headers, verify=False)

    data = response.json()

Printing with prettytable module

Now we have all our information, you can make this presentable and readable using the python module prettytable to create one table with headers. This holds the ‘Hostname’, ‘Platform Id’, ‘Software Type’, ‘Software Version’, ‘Up Time’ (you can also add serial number, MAC address, management IP address….etc)

dnac_devices = PrettyTable(['Hostname','Platform Id','Software Type','Software Version','Up Time' ])

dnac_devices.padding_width = 1()

As part of the network-device API, the Python script is connecting to DNA Center and using a loop for iterating over a sequence querying for the information, selecting the data required from the returned output, and then populating the table.

for item in data['response']:

        dnac_devices.add_row([item["hostname"],item["platformId"],item["softwareType"],item["softwareVersion"],item["upTime"]])

Running the code

Testing this out against the DNA Center in the DevNet Sandbox, we can see the following output we requested printed a clear table format.

python get_dnac_devices.py

+-------------------+----------------+---------------+------------------+-----------------------+

|      Hostname     |  Platform Id   | Software Type | Software Version |        Up Time        |

+-------------------+----------------+---------------+------------------+-----------------------+

| asr1001-x.abc.inc |   ASR1001-X    |     IOS-XE    |      16.6.1      | 180 days, 19:21:43.97 |

|  cat_9k_1.abc.inc |   C9300-24UX   |     IOS-XE    |      16.6.1      | 180 days, 20:20:17.26 |

|  cat_9k_2.abc.inc |   C9300-24UX   |     IOS-XE    |      16.6.1      | 180 days, 20:14:43.95 |

|   cs3850.abc.inc  | WS-C3850-48U-E |     IOS-XE    |     16.6.2s      |  177 days, 7:33:46.98 |

+-------------------+----------------+---------------+------------------+-----------------------+

Adding additional attributes required?

No problem! Let now say for example we wanted to expand on this and added some additional (or we could replace/remove) attributes to our information. This is really simple to do. In our code we only need to update two places, the header and the additional attribute we want to parse from DNA Center from the script. Let’s add the devices serial number and management IP address.

dnac_devices = PrettyTable(['Hostname','Platform Id','Software Type','Software Version','Up Time', 'Serial Nu', 'MGMT IP' ])

dnac_devices.padding_width = 1

for item in data['response']:

        dnac_devices.add_row([item["hostname"],item["platformId"],item["softwareType"],item["softwareVersion"],item["upTime"], item["serialNumber"], item["managementIpAddress"]])

Now, let’s run the Python script once more and see the additional attributes we added.

python get_dnac_devices.py

+-------------------+----------------+---------------+------------------+-----------------------+-------------+      Hostname     |  Platform Id   | Software Type | Software Version |        Up Time        |  Serial Nu  |   MGMT IP   |

+-------------------+----------------+---------------+------------------+-----------------------+-------------+

| asr1001-x.abc.inc |   ASR1001-X    |     IOS-XE    |      16.6.1      | 180 days, 19:21:43.97 | FXS1932Q1SE | 10.10.22.74 |

|  cat_9k_1.abc.inc |   C9300-24UX   |     IOS-XE    |      16.6.1      | 180 days, 20:45:36.37 | FCW2136L0AK | 10.10.22.66 |

|  cat_9k_2.abc.inc |   C9300-24UX   |     IOS-XE    |      16.6.1      | 180 days, 20:40:03.91 | FCW2140L039 | 10.10.22.70 |

|   cs3850.abc.inc  | WS-C3850-48U-E |     IOS-XE    |     16.6.2s      |  177 days, 7:33:46.98 | FOC1833X0AR | 10.10.22.69 |

+-------------------+----------------+---------------+------------------+-----------------------+

Conclusion, automate all the things

We can all acknowledge that manual processes are the adversary of quick value delivery, high productivity, and security. Automation isn’t only about making tasks quicker though. It also allows the creation of repeatable environments and processes as we have seen above with this Python script. Anyone on your team could run this script, no more logging support tickets for information about network devices and their current images or device types or logging into every device and running the same CLI commands, just run the automated script.

Continue reading