New XR Programmability Learning Labs and Sandbox Let You Explore

Turning team focus to network automation and programmability

I came from a network service provider background. Then, when I starting working at Cisco, I was working on the Cisco Security network team. The global network we built, owned, and managed was much like a service provider network. We had lots of transit links, and circuits with service providers, and tons of peering links, and sessions all over the world. Managing this was a full-time job, and I am just talking about managing the WAN (wide area network) here. Which is why, like many of you and other network teams out there whose network requires speed, scale, and data analytics, my team and I turned our focus to network automation and programmability.

The majority of our network devices (both core and edge) were running IOS XR. IOS XR has always been one of my favorite platforms, so it was with great excitement that when I began working for the Cisco DevNet team, my specialist area would be working with the IOS XR teams and platform.

What is new to learn here?

A great question, I am pleased you asked! We have built a dedicated sandbox environment for IOS XR programmability and learning labs to go with this.  The IOS XR Programmability sandbox and learning labs provide an environment where developers and network engineers can explore the programmability options available in this routing platform. These include:

◈ Model Driven Programmability with YANG Data Models, NETCONF and gRPC
◈ Streaming Telemetry
◈ Service-Layer APIs
◈ Application Hosting

What gear can you access in the sandbox?

We wanted to build a sandbox that provides the right level of simplicity for users to get started while offering a flexible platform they can build on. The sandbox provides two Cisco IOS XRv 9000 devices (R1 and R2) connected back to back, plus a Linux host that acts as a development box (DevBox). The image version on Sandbox tile is 6.4.1 this is available on both the two IOS-XR nodes.

The new IOS XR programmability sandbox lets you explore programmability options available in this routing platform.

The all-new learning labs and track

You can use the IOS-XR programmability learning track to familiarize yourself with the rich set of programmable interfaces and APIs offered by IOS-XR. The goal of this track is to introduce you to the architectural tenets of the IOS-XR network stack and showcase how APIs at every layer of the stack – from Manageability APIs like YANG models, CLI, ZTP hooks to Service Layer APIs at the network infrastructure layer can be used to completely transform the way you manage and provision your network.

◈ IOS-XR CLI automation Cisco IOS-XR offers a comprehensive portfolio of APIs at every layer of the network stack, allowing users to leverage automated techniques to provision and manage the lifecycle of a network device. In this module, we start with the basics: the Command Line Interface (CLI) has been the interaction point for expect-style scripters (TCL, expect, pexpect etc.) for ages; but these techniques relying on send/receive buffers are prone to errors and inefficient code. This is where the new onbox ZTP libraries come handy. Use them for automated device bring-up or to automate Day1 and Day2 behavior of the device through deterministic APIs and return values in a rich Linux environment on the router.

◈ IOS-XR Model-Driven Automation: YANG models Cisco IOS-XR offers a comprehensive portfolio of APIs at every layer of the network stack, allowing users to leverage automated techniques to provision and manage the lifecycle of a network device. APIs that are derived, documented and versioned using deterministic models are contractually obliged to match the expectations laid out by the model. Following this ethos, in IOS-XR, all the capabilities of the software, traditionally offered through the Command Line Interface (configuration commands, show commands, exec commands) are mapped to equivalent Config and Oper YANG models backed by the internal IOS-XR Database called SYSDB. In this module, we start taking the first steps towards model-driven programmability as we dive deeper into IOS-XR Yang models. We look at the interaction with these models with tools such as ncclient, YDK or gRPC clients and tips to map your CLI configurations to corresponding YANG-Modeled XML/JSON representations.

◈ IOS-XR Streaming Telemetry: SNMP is dead! It is time to move away from slow, polling techniques employed by SNMP for monitoring that are unable to meet the cadence or scale requirements associated with modern networks. Further, Automation is often misunderstood to be a one-way street of imperative (or higher-layer declarative) commands that help bring a network to an intended state. However, a core aspect of automation is the ability to monitor real-time state of a system during and post the automation process to accomplish a feedback loop that helps make your automation framework more robust and accurate across varied circumstances. In this module, we learn how Streaming Telemetry capabilities in IOS-XR are all set to change network monitoring for the better – allowing tools to subscribe to structured data, contractually obliged to the YANG models representing operational state of the IOS-XR internal database (SYSDB) at a cadence and scale that are orders of magnitude higher than SNMP.

◈ IOS-XR Service-Layer APIs: Cisco IOS-XR offers a comprehensive portfolio of APIs at every layer of the network stack. For most automation use cases, the manageability layer that provides the CLI, YANG models and Streaming Telemetry capabilities, is adequate. However, over the last few years, we have seen a growing reliance in web-scale and large-scale Service Provider networks on off-box Controllers or on-box agents that extract away the state machine of a traditional protocol or feature and marry their operation to the requirements of a specific set of applications on the network. These agents/controllers require highly performant access to the lowest layer of the network stack called the Service Layer and the model-driven APIs built at this layer are called the Service-Layer APIs. With the ability to interact with RIB, the Label Switch Database (LSD), BFD events, interface events and more capabilities coming in the future, it is time to take your automation chops to the next level.

The sandbox provides two Cisco IOS XRv 9000 devices (R1 and R2) connected back to back, plus a Linux host that acts as a development box (DevBox).

Getting Started

The development box includes a “hello world” sample app to check the uptime on routers to get you started.

hello-ydk.py

The script illustrates a minimalistic app that prints the uptime of a device running Cisco IOS XR. The script opens a NETCONF session to a device via the devices IP address, reads the system time and prints the formatted uptime.

Sample Output:

Continue reading

Why Organizations With Sensitive Research or Intellectual Property Need a Zero Trust Cybersecurity Framework Approach

The emergence of Zero Trust has shifted the center focus of some security frameworks from securing the perimeter to protecting sensitive data. While both are extremely important, this shift to a sensitive data-centric framework has advantages. To further understand the benefits of Zero Trust, consider a few specific scenarios:

◈ A large university that does over $100M in Federal Research

◈ Any company with intellectual property or in the process of acquiring or selling off organizations

◈ A state, county, or large city that needs to protect their Criminal Justics Information Services (CJIS) data

◈ Industrial Controls Systems (ICS); power, water, roads, or buildings.

◈ Election infrastructure security

Using those above situations, let’s start with the basics that you need to understand:

◈ Who is after your sensitive information:

     ◈ Where does it sit?

     ◈ What are the capabilities of the bad actors?

     ◈ What are the three biggest gaps that you need to address asap?

◈ Do you have an accurate inventory of your hardware?   Can’t protect what you do not know about…

◈ Inventory of your software and their application flows?  Most moves to cloud fail due to lack of insight related to dependencies.

◈ What are your key risks (threats, brand image, fines, and compliance).

◈ Understand what your top 50 pieces of sensitive data are.  Rarely does anyone do full data classification.

◈ Understand where your top 50 pieces of sensitive data presently reside.

◈ What are your organiazations capabilities around Segmentation, Priviledge Escalation Monitoring, and Multi Factor Authentication?

◈ Can you spot priviledge escalaton (user and application processes) ?

◈ How well are your security solutions integrated? Automated? Use the same intelligence?

Then analyze where you are with the necessary people, process, and technology basics. Most organizations should leverage the resources and technologies that they already have and understand where the gaps are, so they can address them over the next one to three years.   Cisco Advanced Security Services can help you with this analysis, strategy, implementation analysis, design, pilot, and implementation work.

Go to a workshop with Cisco Advanced Services, so you understand what the gaps are, how to best address them, and prioritize your work.  This end-to-end approach will help you address your key use cases to get the outcomes you need addressed.

Some of Cisco’s Related Zero Trust Services

◈ Strategy, Risk, & Programs IT Governance
     ◈ Security Strategy & Policy
     ◈ Security Program Maturity Assessment
     ◈ 3rd Party Risk Program
     ◈ Security Program Development
     ◈ Identity & Access Management
◈ Infrastructure Security
     ◈ Network Architecture Assessment
◈ Integration, Automation, and Advance Analytics

Cisco is actively involved with organizations with these types of challenges. We have the product and services experience to help you determine a practical systems approach to Zero Trust.  Reach out to your Cisco Security Services team so we can help guide your through this.

9 Pillars Of The Zero Trust Ecosystem – Jeff’s View

Continue reading

Moving Towards The Zero Trust Cybersecurity Framework?

The first step should be an investigation and analysis of what your sensitive data is, where it lives, and who accesses it. Then analyze the three Foundational Pillars (see below) to see where you are with the necessary people, process, and technology basics. Most organizations should leverage the resources and technologies they already have in place, and understand where the gaps are so they can address them over the next one to three years. Cisco Advanced Security Services can help you with this analysis, strategy, and implementation work.

The three foundational Pillars are:

1. Zero Trust Platform
2. Security Automation and Orchestration
3. Security Visibility and Analytics

These Zero Trust Foundational Pillars work great whether you leverage the CIS 20, NIST 800, or the ISO 27000 family cybersecurity frameworks. A few key things you need for all of them include:

◈ Segmentation, Priviledge Escalation Monitoring, and Multi Factor Authentication
◈ Inventory of your hardware and software plus application flows
◈ What are your key risks (threats, brand image, fines, and compliance)
◈ Understand what your top 50 pieces of sensitive data are
◈ Understand where your top 50 pieces of sensitive data presently resides
◈ Who is after this information?   What are their capabilities

A quick high level overview of the 3 foundataional pillars based on the information from Forrester Research: :

1. Zero Trust Platform
• Data security, which is ultimately a technology solution
• Managing the data, categorizing and developing data classification schemas, and encrypting data both at rest and in transit
2. Security Automation, Orchestration Security, and Risk leadership to leverage and use tools and technologies that enable automation and orchestration across the enterprise.
• The ability to have positive command and control of the many components that are used as part of the Zero Trust strategy.
3. Security Visibility and Analytics
• You can’t combat a threat you can’t see or understand. Tools such as traditional security information management (SIM), more-advanced security analytics platforms, security user behavior analytics (SUBA), and other analytics systems enable security professionals to know and comprehend what’s taking place in the network.
• This focus area of the extended Zero Trust ecosystem helps with the ability of a tool, platform, or system to empower the security analyst to accurately observe threats that are present and orient defenses more intelligently.

Do a workshop with Cisco Advanced Services so you understand what the gaps are, how to best address them, and prioritize your work.  This end to end approach will help you address your key use cases to get the outcomes you need addressed.

Be sure to take into consideration the Core principles that make up Zero Trust:

1. Identify and Catalog your Sensitive Data
2. Map the data flows of your sensitive data
3. Architect your Zero Trust network
4. Create your automated rule base
5. Continuously monitor your trusted ecosystem

We have the product and services experience to help you determine a practical systems approach to Zero Trust  Reach out to your Cisco Security Services team so we can help guide your through this.

Continue reading

How Antifragile Systems of Trust Can Strengthen Blockchain Initiatives

What doesn’t kill us makes us stronger. We resist gravity, and our muscles become stronger. We negotiate conflicts, and our emotional intelligence increases. But what if this also applied to IT systems? The next generation of networked systems could autonomously improve themselves as outside forces threaten them.

I and the rest of the Cisco Innovation team already believe blockchain is going to play an important role in securing data, but blockchain could also help entire networks learn to better protect themselves and intervene more quickly.

“Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better. … The antifragile loves randomness and uncertainty, which also means — crucially — a love of errors, a certain class of errors. Antifragility has a singular property of allowing us to deal with the unknown, to do things without understanding them — and do them well. Let me be more aggressive: We are largely better at doing than we are at thinking, thanks to antifragility. I’d rather be dumb and antifragile than extremely smart and fragile, any time.”

We could take a lesson from this idea to design decentralized antifragile systems — whether they are business networks, applications or infrastructure — that become stronger the more people or machines try to break them. Blockchain technology offers specific advantages that all enterprise networks require — one single version of the truth, data immutability and automated processes among them. Combining blockchain technology with machine learning algorithms would allow multi-stakeholder systems to continually improve themselves, better react to challenges in the future and perhaps even anticipate potential problems.

I wrote an article last year about FCAPS, blockchain and trust that is relevant here. Anyone who works in telecommunications is at least tangentially familiar with the ISO/OSI and ITU network management models that shape our processes for fault, configuration, account, performance and security management — FCAPS.

My theory is that setting up machine learning algorithms to constantly measure specific parameters and adjust themselves accordingly could allow those systems to learn new solutions to preserve their operation levels. You would break systems of trust down into key components and use tight feedback loops to record and respond to specific parameters. Those tightly defined parameters could evolve over time. In a multi-stakeholder ecosystem, each stakeholder would extend insights to the collective. So in essence, there is no one system of trust but a series of trusted domains, each independently serving a specific, special function.

Let’s say your system is designed to move data from one point to another point with some certain level of efficiency. Then a configuration change happens — perhaps it’s a simple user error or a malicious configuration change. The system could learn from that instance so that the next time such a change happens, the system can automatically correct it or alert an admin to the issue that would cause it to move out of spec. Now imagine these changes as a collection of events across multiple enterprise domains.

Extremely few environments today have only one vendor as the source of their technology. Just one data center will have multiple vendors involved, and you have to be sure that this heterogeneous system runs efficiently across all providers. Let’s say your business application spans multiple clouds — how do you ensure your product delivers the quality your customers expect if something happens to one of your service providers?

Some of these issues can be learned and prevented in the future to create more robust, responsive systems. This article proposing a manifesto for antifragile software from the University of Bologna is also interesting. Inspired by the Agile Manifesto, the researchers have laid out a common framework for making software that is antifragile; the principles could also be applied to making antifragile networks. The Antifragile Software Manifesto is all about building networks of trust and continuous improvement. Here are some highlights:

◈ Our highest priority is to satisfy the customer by building a non-linear, proactive, and self-adaptive system.
◈ All stakeholders, and the broader environment, lead the antifragile organization.
◈ Continuous exposure to faults and automatic fixing is the primary measure.
◈ An antifragile organization promotes a context aware environment. The stakeholders should be able to maintain a system indefinitely.

Sounds like enterprise blockchain, right? We are striving to create networks that are decentralized and self-adapting, with many stakeholders and built-in redundancy, where all participants have skin in the game but no one actor can sabotage it. Adding machine-learning algorithms that constantly improve these enterprise blockchain networks will even better protect the data and stakeholders involved.

For our enterprise clients, confidence and privacy of data are understandably very important matters. Sustaining these states can be accomplished using selective disclosure. You define who gets to see what information as you write data to a blockchain network. Policies should be set up in the network so data being posted is always compliant with the governance models all parties have agreed upon. Your users’ roles and responsibilities within the network will grant them the according degrees of access to information. So an auditor could be granted access to all information, but a data entry specialist would have only access to certain areas.

The next level would be creating a data overlay specifically for the purpose of providing algorithms access to ecosystem-attested data — data that is compliant, shared correctly and of high value. In theory, machine-learning algorithms may produce higher quality insights for antifragility as ecosystem-wide observations are shared. Infrastructure is a perfect example of a complicated system with many stakeholders and massive amounts of high-quality data for a machine-learning algorithm to munch on. Putting the blockchain in between infrastructure and machine learning would potentially give us the ability to increase quality for all users while maintaining control of data access and preventing tampering.

If you’d like to read more about Cisco’s take on blockchain, you will enjoy our whitepaper. And feel free to leave a comment if you have any thoughts to add on how blockchain could be integrated with machine learning to create smarter systems.

Continue reading

The Five Focus Areas for 5G Security Innovation and Thought Leadership

5G brings the promise of new revenue opportunities for service providers. Service providers will be able to offer new differentiated services and capabilities, connecting customers to multi-cloud services and applications with specific KPIs.

To help service providers in the delivery of 5G, Cisco’s Cloud-to-Client approach unifies multi-vendor solutions into a single, standards-based architecture and spans across multi-cloud, IP routing, 5G core, service edge, access networks, Internet of Things (IoT), and security.

New revenue opportunities are infinite, so are security threats. Many IoT services will utilize new 5G air interfaces. Networks will be more distributed leading to a surge in entry points for more destructive threats, and new transient or moving threat boundaries.

To prepare service providers for these looming security challenges, Cisco offers a comprehensive security approach for the optimal deployment and consumption of 5G services, revealed in detail in our 5G security innovation with Cisco white paper.

5G Security Risks

5G will increase in wireless capacity by 1,000 times and connect 7 billion people and 7 trillion “things”, estimates a joint initiative between EU Commission and European ICT.

This massive throughput connectivity and capabilities in 5G require a major network architectural change, from radio access to the core. It bridges wireless and wireline networks through an evolving architecture which can involve network slicing, Control and User Plane Separation (CUPS), Mobile Edge Computing (MEC), just to name a few of the changes to the network. As the network changes at the same time, new challenges and threats will come about.

As we move into the 5G era we are also seeing more sophisticated attacks. Gartner believes half of the malware next year will use some encryption to hide malware and organizations today do not have a solution for this.

In my view, 5G’s evolving architectural nature and an expanding threat surface call for an integrated end-to-end approach to cybersecurity. Our security innovations based on visibility (even in encrypted traffic) and control for the entire 5G network, up to all applications, can provide a secure delivery of new cases with service assurance.

Intrinsic Security is Key

In the world of 5G, traditional siloed security and add-on edge appliances have limitations, are complicated and costly. Security today does not interoperate enough with the network and there will be gaps if we follow the same approach with 5G.

Cisco’s security innovation is holistic and intrinsic to the network. Leveraging the network functions themselves for visibility and fast threat identification, segmentation to reduce the attack surface and the impact of an attack; threat protection to stop a breach across multiple points of the network; and support from our threat intelligence Talos team.

5G Security Innovation with Cisco

5G security needs an integrated approach to deal with close to 20 billion threats per day. With visibility and control from end-to-end, Cisco’s full suite of 5G solutions and end-to-end security architecture can help service providers in the Asia-Pacific region stop threats at the edge, protect users wherever they work, control who gets on the network, simplify network segmentation, and find and contain problems fast.

Continue reading

Containers in Production: Accelerate the Learning Curve

There is a learning curve associated with scheduling containers in production on Kubernetes. But if your cloud architect or platform engineering team can integrate and configure the set of tools needed for deploying and managing containerized workloads, then Developers, Application Ops, and Cluster Ops teams can move up the curve and accelerate time to value for your business.

But before we discuss how one can move up the learning curve, let’s first get a little context on why containers are a forcing function for change.

Historical Context

When virtual machines (VMs) were new, the technology learning curve primarily affected Ops teams who had to learn about the management, snapshotting, and migration of this new abstraction. The primary unit of management was the VM, not the physical server. Development practices didn’t change much in order to get the most value out of the technology.

But the transition to containerized workloads, as well as the deployment of containers in production on Kubernetes, have a big impact on both Dev and Ops. Containers change how applications are architected and written, and also change how applications are managed, monitored, and supported in production.

So, now both Dev and Ops have a new technology learning curve.

Developers Learning Curve

Rewriting your application for containers is not as simple as taking an application running on a physical machine or a virtual machine and just packaging it in a container. Rather, developers need to do some things differently with containers. This includes:

◈ Packaging – consider packaging with build instructions stacked in layers.
◈ Service discovery and catalog – since you’ll be running services across multiple containers, find and bind to dependent services.
◈ Key management – managing authentication and rotate keys across services.
◈ Logging and monitoring – obtaining data about the application, container, and node levels, as well as dependent services.

Ops Learning Curve

Ops arguably has an even bigger learning curve. Virtual Machines introduced a lot of dynamic things within an infrastructure environment, but containers make an order of magnitude worse because now you can spin up workloads within milliseconds, kill it, and start it somewhere else. This learning curve involves:

◈ Compute capacity planning – planning CPU and memory at a different level that includes multiple containers on a single machine (physical or virtual).

◈ Networking –. managing networking within and between Kubernetes clusters, especially since more containers means more east-west network traffic. These clusters may include both private infrastructure and public cloud.

◈ Persistent Storage – requires higher service levels than ephemeral applications.

◈ Logging and monitoring – there are usually more containers than an equivalent number of VMs for a monolithic application. And they may move if Kubernetes health check replicates pods on a different host.

◈ Data – a VM or virtual disk might include 10 different containers, so you need to shift thinking about snapshotting data at a container level.

◈ Namespaces – coding to namespaces as a variable, or mapping and managing namespaces across your various environments.

◈ Tracking changes – IT remaining responsible for Service Levels and tracking the history of simple changes. This is especially crucial with the ephemeral nature of containers and Kubernetes’ replication across nodes.

Overall, many of the Dev and Ops tools and processes that were optimized for VMs, now need to be updated and re-optimized for containers.

Don’t Get Bogged Down in the Stack

To make this work, you will likely need someone assigned to an AppOps role that works in production to support containerized applications. Also, you’ll likely need a specialized IT Ops role, call it ClusterOps, to manage Kubernetes and field requests for namespace resources or cluster lifecycle management.

But if you run Kubernetes on premises as part of a hybrid cloud solution, you’ll also need a cloud archteicture or platform engineering role to build the Kubernetes tool stack and connect to and secure the cloud. They can deploy and integrate all the tools needed to lifecycle manage your Kubernetes clusters, including underlying compute, network, and storage on private infrastructure.

Building and maintaining this type of integrated on and off-premises solution takes work — both upfront systems integration and configuration work, and the ongoing management and testing of individual tools and platforms through their upgrade cycles.

If all the tools you need to deploy containerized workloads on premises or in the cloud are integrated and tested working together such as the Cisco Hybrid Cloud Platform for Google Cloud – then it will be faster and easier for developers, as well as Application Ops and Cluster Ops counterparts, to move up the learning curve and accelerate time to value for your business.

Continue reading

Introducing the new Webex Meetings in DevNet

At Cisco, we’re dedicated to providing the best experience for our customers as well as for the people who make technology work at its fullest potential—our developers. If you were at Cisco Live, you heard the incredible momentum that our DevNet community has had in the recent timeframe, reaching 500K members. While the network is certainly one of the leading focuses of DevNet, Cisco is also making it easier for developers to get access to all the resources they need to develop for Collaboration.

What’s New

The new Webex Meetings page brings you updated XML API schemas so you can easily develop for Webex Meetings. We’ve included easy access to quick links to help you get ramped up, as well as community support if you want to chat with experts.

Get Started

The Webex Meetings page on DevNet now has a brand-new interface complete with all the tools you need to get started. You can watch video tutorials, access learning labs, and read through release notes to stay up to date on all the newest features.

Community and Support

Need to talk to an expert? Check the links under our “Community & Support” section to talk to Webex Meetings experts at Cisco as well as within the developer community. Check the knowledge base to see if other people have addressed your questions already. You can also send email support for direct assistance and send in feedback.

Explore API Reference Documents

We’ve added a repository of all reference documents that you can access at your leisure, from Data Management to Site Services. You can review the full XML API reference guide to help you as you’re working through your development process.

Webex Meetings APIs Sandbox

Our DevNet Sandboxes are provided by Cisco as a cloud service to help provide guidance for customers, partners, and developers as they integrate their solutions with Cisco technology. The sandboxes are a great way to have a personalized space to design, develop, and test customized integrations using Webex APIs.

Let us know how we’re doing!

We’re constantly looking to improve the experience for our developers to make it easier and faster to implement integrations. You can send us your feedback on how your experience is with our APIs in our developer forum to help us make improvements for the future.

Our redesigned navigation allows easier access to your core Webex Meetings functions, including (but not limited to): scheduling meetings; managing attendees, viewing meeting lists, cross-launching meetings, pulling usage reports, retrieving recordings, and more. With these tools, you’ll be able to seamlessly integrate Webex Meetings into your applications. In addition, we will be using this same portal to introduce new capabilities and new APIs going forward, so be sure to check back regularly for updates.

Continue reading

Promote Cloud Adoption in Education without Exposing Students to Risk

Cloud based collaboration is being adopted rapidly by organizations in all verticals, and education is no exception. Access to collaborative tools can’t be as simple as an on/off switch. School administrators need visibility to prevent the loss of sensitive data and to ensure that students aren’t engaging in inappropriate communication. On-premise policies must be equally enforced as students leverage cloud-based tools.

Allowing Only the Correct External Communications

Schools are quick to welcome collaborative platforms like Google Drive, Microsoft’s Office 365, and Dropbox. Cloudlock, an important piece of the Cisco Security portfolio, enables educators to enforce policies across these platforms to ensure that only the appropriate personnel are logging in. Cloudlock can detect logins from questionable locations and report on multiple failed logins to applications.

Umbrella, a cloud-based extra layer of security, can recognize requests made from an organization to dangerous domains. Policies can block security categories like malware, cryptomining, and command and control. Behavior policies can be leverage to prevent requests to inappropriate sites like gambling, alcohol, and adult themes.

Addressing Behaviors and Communications

Once students and personnel log in, policies can be enabled and enforced around communication. These pre-defined policies include categories like aggressive behavior, discrimination and cyberbullying. If students are engaging in these behaviors on collaboration platforms, administrators can be warned about incidents that violate these policies.

Additionally, pre-defined policies include language associated with self-harm, which would be present in shows like Netflix’s TV series 13 Reasons Why. School systems reacted to this show in varying ways including banning it, recommending that parents watch it with their children, and providing lists of resources designed to identify depression. The self-harm template provides an additional degree of visibility for educators and counselors into students’ interactions.

Protecting Access to Data for Compliance

School systems have compliance requirements also. One example is data included under the Family Educational Rights and Privacy Act (FERPA) (20 U.S.C. § 1232g; 34 CFR Part 99). This data is related to the transfer of students and access to it is restricted to the school systems involved, accrediting organizations and judicial parties overseeing these cases. Cloudlock contains templates that look for the sensitive “directory” information.

Finally, educational organizations look to ensure that only sanctioned cloud-based applications are installed and used on devices. Umbrella provides a cloud services report to identify applications that are requesting access to cloud services. This report can provide visibility into unsanctioned applications, allowing admins to restrict access to only applications sanctioned by the organization.

Continue reading

Meeting enterprise demands with dual rate 10/25G Ethernet

Enterprise networks are now being stressed by video conferencing and other demanding video applications that push beyond the speed limits of traditional 10G infrastructure.  Whether it’s IEEE802.11ax WiFi Access Points, that require 1G/2.5G/5G/10G backhaul interfaces or 1G/2.5G/5G/10G direct copper/fiber Ethernet to the desktop, new enterprises are being built for high speed that now requires 25G interfaces.

Using Cisco’s new enterprise Catalyst 9000 Family Switches and Cisco’s new SFP-10/25G-CSR-S transceivers, customers can connect Wiring Closet Switches to Aggregation Switches with 25G over MultiMode Fiber (MMF).

What is “CSR”?

“CSR” stands for Cisco Short Reach.  Using advanced optical technology, Cisco is able to provide 25Gbps bandwidth at distances up to 300/400m* over OM3/4 MMF. While providing these extended reaches, the new SFP-10/25G-CSR-S transceiver is fully interoperable with traditional IEEE 802.3by 25G transceivers that only provide 25Gbps at distances up to 70/100m over OM3/4 MMF.

Why is 300/400m over OM3/4 MMF important?

Traditional 10G networks are being built (or have been built) based upon IEEE802.3 specifications (10GBASE-SR) that allow 300/400m distances over OM3/4 MMF.   These distances are well established by network installers which has resulted in Wiring Closets being located up 300 (or 400m) from Computer Rooms/Data Centers.

Cisco’s new SFP-10/25G-CSR transceiver enables 25G over MMF at the same distance as 10GBASE-SR, which means that if the fiber infrastructure worked at 10G, it will also work with SFP-10/25G-CSR. This is not the case with IEEE 25GBASE-SR because its reach is shorter.

Interoperability with 10G

The new SFP-10/25G-CSR transceiver has dual rate capability that allows interoperability with both 25GBASE-SR and 10GBASE-SR MMF transceivers**. This allows the network to be incrementally upgraded at either the end of the fiber.

Interoperability with 40G and 100G

The new SFP-10/25G-CSR can also interoperate with 100GBASE-SR4 and 40GBASE-SR4 transceivers using 3rd party MMF breakout cables. For 100G interoperability, 25G requires the use of RS-FEC (Forward Error Correction), which is available on Cisco’s 100G ports.

See this video for further information

Continue reading

Delivering 1 Gbps over DSL with Cisco’s ISR 1000

I still remember the day I first got ADSL at home in 2000. The top speed was only 2 Mbps, but I was purely fascinated by everything I could do at home, especially playing video games. Not before long, ADSL was replaced with VDSL, which changed my use of the internet from playing games to downloading video and music files in bulk, thanks to Napster and Torrent.

Putting memories aside, the general landscape of the internet has completely changed over the last decade. No longer are the days of one desktop serving an entire family, instead each family member has at least one smartphone and possibly a laptop which are used constantly for streaming videos, music and more. Businesses have an immense scale of data to process and share over the internet. What this means is that bandwidth is the key to keeping families happy and businesses running.

DSL innovation has been relentless when it comes to meeting the growing demand for higher bandwidth in the market. The latest form of DSL that has been introduced is G.fast, which is expanding aggressively in the UK and Switzerland. G.fast is a DSL technology that has stretched its frequency spectrum up to 106 MHz with the additional capability to increase up to 212 MHz. Compared to the common VDSL2 deployment with 17 MHz, G.fast at 106MHz is capable of offering throughput up to 1 Gbps. In addition to its high bandwidth, G.fast is a more affordable option compared to fiber, since it is deployed over copper wires.

Today’s internet landscape has also played a major role in propelling local governments and service providers to work hand-in-hand to provide faster internet services to the general public. For example, the EU has launched an initiative to support access to internet connections with 1 Gbps by 2025 for all schools, transport hubs and main providers of public services, as well as digitally intensive enterprises. In order to support this initiative, it is no surprise that G.fast is highly favored by many service providers in Europe. British Telecom and Swisscom are at the forefront in leading their services with G.fast.

G.fast in Detail

G.fast is a DSL technology, but it sets itself apart in a few aspects from its predecessors, such as VDSL. First, the frequency spectrum used in G.fast is far wider compared to most profiles in VDSL2. The latest VDSL2 profile, deployed in Italy and Germany, is only at 35MHz, offering a throughput of 300 Mbps. Early G.fast deployments used a frequency spectrum of 22-106MHz to avoid interference from the range used by VDSL, which resulted in approximately 100 Mbps less throughput compared to using the full spectrum from 2 MHz. To increase the throughput on G.fast, the current frequency spectrum is being evaluated for an extension down to 2 MHz and up to 212 MHz. Particularly, 212MHz promises a peak aggregate throughput of 2 Gbps, which will enable 1Gbps for both downstream and upstream.

Another technical difference that makes G.fast unique is Time Domain Duplex (TDD). ADSL and VDSL have traditionally used Frequency Domain Duplex (FDD), where downstream and upstream had one frequency band for each to communicate. Since the frequency band for each direction of traffic was fixed, it was difficult to dynamically adjust the throughput per direction depending on need.

TDD enables both downstream and upstream to use the same frequency band, which allows G.fast to make throughput adjustments flexibly for both directions. The benefit of using TDD for G.fast is huge for service providers who have more flexibility to design different classes of service offerings on the same link.

G.fast Deployment

DSL, by design, is vulnerable to attenuation occurring on copper wires, which means that throughput varies depending on the distance from the CPE to DSLAM. G.fast is no exception to attenuation. Though it is able to reach 1Gbps in theory, in a very short loop length, it is impossible to maintain such short loop length in an actual deployment. Different studies would show different throughput results over distance, but the throughput range between the distance of 200 to 400 meters falls between 500 Mbps to 200 Mbps. For this reason, current G.fast deployments in the UK and Switzerland are designed for the distance between 200 – 300 meters with a target throughput between 200 Mbps to 500 Mbps. With the introduction of 212 MHz in the future, the serviceable areas with G.fast will be extended with higher levels of throughput.

Cisco’s Solution

Cisco never shied away from accommodating new changes in the market and meeting the most challenging demands from the customers. Cisco’s flagship product family, the Integrated Services Router Series, has evolved ever since its inception to stay competitive and relevant in the market by adding new routers with the latest innovations.

Cisco introduced the ISR 1000 Series routers in late 2017. It was the latest addition to the Integrated Services Routers family. The routers perform at an unmatched level to meet today’s growing demand for high throughput while offering a diverse set of WAN connectivity options including LTE Advanced, VDSL, Ethernet and Fiber.

In July 2018, G.fast was added to the list of supported WAN options on the 8 LAN port ISR 1000 Series routers with the creation of new models: C1112 and C1113. G.fast on the C1112 and C1113 will be supported over both POTS and ISDN to serve a wider list of countries. In addition to G.fast, both models will support ADSL and VDSL, including Profile 35b, to provide customers with flexible DSL deployment options. As early as November 2018, C1112 and C1113 will also be integrated with Cisco SD-WAN.

C1112 and C1113 are the only enterprise-grade routers in the market to provide secure and reliable connection with the ability to provide the high bandwidth required by today’s G.fast deployments. Both routers will not only enable customers to expand their service offerings with G.fast, but help them to protect their investment in the existing infrastructure.

Continue reading

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