Trustworthy Networking is Not Just Technological, It’s Cultural – Part 3

Part 3: Developing a Culture of Trust

In my two previous posts on the topic of trustworthy networking, I’ve focused on the multiple technologies Cisco designs and embeds into all our hardware and software and how they work together to defend the network against a variety of attacks. I explored how it’s not just about the trust technologies but also about the culture of trustworthy engineering that is the foundation of all that we do. In this post I’ll focus on how Cisco builds and maintains a culture of trustworthiness.

But first, what is culture? What is does trustworthy mean? Just as there are a diversity of human societies, there are different characterizations of culture and trust.

Fusing several definitions, we can summarize culture as:

◉ The quality in a person or society that arises from a concern for what is regarded as excellent in arts, letters, manners, scholarly pursuits, etc. and provides important social and economic benefits.

◉ Culture enhances our quality of life and increases overall well-being for both individuals and communities.

Trustworthy is another word with a variety of implications:

◉ Trust describes something you can rely on, and the word worthy, describes something that deserves respect.

◉ Trust is intangible – it is an intellectual asset, a skill, and an influencing power for leaders. Showing trustworthiness by competence, integrity, benevolence, and credibility makes a difference in daily leadership work.

◉ Trustworthy describes something you can believe in — it’s completely reliable.

Therefore, a culture of trustworthiness provides a consistent approach to designing, building, delivering, and supporting secure products and solutions that customers can rely on to “do what they are expected to do in a verifiable way”. When engineers approach product design and development with integrity and security of product functionality and ensure the safety of customer data from day one of a project, then the outcome has an excellent chance of being trustworthy. Let’s look at how Security Leadership permeates Cisco culture with reliability and credibility through education, social contracts, and a strict adherence to Cisco Secure Development Lifecycle (CSDL).

A Culture of Trustworthiness Starts with Continuous Security Education

Designing trustworthy networks requires a commitment to professional improvement with deep learning into secure technologies, threat awareness, and industry-standard principles. At Cisco this education starts with levels of Cisco Security Space Center program that every employee and contractor must complete to various levels of proficiency depending on their jobs. To date, over 75,000 people in the Cisco workforce have completed the required levels of Security training. This greatly increases security awareness throughout the organization. It also gives the workforce a common language to discuss the principles of trustworthy design and support.

Pervasive cultural security also requires a legion of advocates inclusive of Cisco employees, vendors, partners, and customers. For example, embedded in every aspect of engineering are Security Advocates who advise, monitor, and report on the implementation of trustworthy security processes. Advocates pride themselves as having a thorough understanding of Cisco Security Space Center training. Security and Vulnerability Audits provide assurance that CSDL is followed and as problems are uncovered during the development and testing cycle they cannot be ignored. Audit teams reports not to engineering management but to the C-suite to ensure that problems are completely fixed or a release red-lighted until they are remediated. This is another example of a culture of trust that permeates across functional departments all the way to the C-level—all in service of protecting the customer.

Threat modeling is another skillset reinforced through training and applied consistently throughout the development lifecycle. It represents a repeatable process for identifying, understanding, and prioritizing solution security risks. Engineers analyze external interfaces, component interactions, and the flow of data through a system to identify potential weaknesses where solutions might be compromised by external threats.

Development security policies not only set the rules for protecting the organization, but also protect investments across people, processes, and technology.

◉ Employee and supplier codes of conduct are signed annually to keep people focused on the importance of trust and their promise to deliver secure products across the value chain and never intentionally do harm.

◉ Enterprise information security and data protection policies are aligned with security standards like ISO 27001.

◉ Using site audits to continuously monitor Cisco and partner development properties ensures that physical security policies—such as camera monitoring, security checkpoints, alarms and electronic or biometric access control—are being maintained.

◉ Data protection and incident response policies are available to customers to help them understand the processes Cisco has in place to protect their data privacy and the actions that will be taken should a data breach occur.

◉ The Product Security Incident Response Team (PSIRT) is independent from engineering and is critical to keeping an unbiased watchful eye on all internally and externally developed code. Anyone at Cisco, customers, and partners can report security issues in shipping code and be assured that they will be logged and addressed appropriately.

Tailoring Cisco Secure Development Lifecycle (CSDL) to Solution Type

We examined the Cisco Secure Development Lifecycle in Part 1 of this series but considering how rapidly networks are evolving to accommodate “data and applications everywhere” and the dispersal of the workforce from campus environments, it deserves another look relating to the culture of trust. The constantly evolving development techniques that are needed to address emerging security threats resulting from these increasingly dispersed workplace.  The evolving workforce means that secure development processes must be adapted depending on the type of solution and where they are deployed:

◉ on-premises networking device

◉ appliance running application

◉ network controller/management

◉ application running in the cloud

◉ combination of on-prem and cloud; aka hybrid cloud.

During development, engineers are trained to approach each of these according to the end deployment. For example, standardized toolsets, such as Cisco Cloud Maturity Model (CCMM), provide a consistent method to assess the quality of all of Cisco’s SaaS offerings. It includes evaluations of many quality attributes, such as availability, reliability, security, scalability, etc. CCMM provides a quantitative and standardized method to gauge the health of all Cisco cloud offerings.

Infusing a Culture of Trust Throughout the Value Chain

If a trustworthy culture stopped at the walls of Cisco and the minds of our employees, there would still be room for bad actors and malicious code to wreak havoc. That’s why Cisco extends our trustworthy principles to partners and suppliers throughout the value chain. We strive to put the right security in the right place at the right time to continually assess, monitor, and improve the security of our value chain throughout the entire lifecycle of Cisco solutions.

Cisco Trust Value Chain

Cisco value chain security continually assesses, monitors, and improves the security of our partners who are third-party providers of hardware components, assembly, and open-source software that are an integral part of our solutions’ life cycles.

We strive to ensure that our solutions are genuine and not counterfeited or tainted during the manufacturing and shipment processes. The steps Cisco and our partners adhere to ensure that our solutions operate as customers direct them to and are not controlled or accessible by unauthorized rogue agents or software threats.

These investments in our people and partners, along with services like Technology Verification, help Cisco provide a comprehensive plan that covers how and what we are doing to support the security, trust, privacy, and resiliency of our customers. Earning customer trust is about being transparent and accountable as we strive to connect everything securely.

To understand our complete Trustworthy Networking story, please refer to Part 1: The Technology of Trust and Part 2 How Trustworthy Networking Thwarts Security Attacks of this blog series, as well as The Cisco Trust Center web site.

Continue reading

Network Automation with Cisco DNA Center SDK – Part 2

In Part 1 of this series we went through setting up the SDK; importing into your python project; and making your first call using the SDK to authenticate against an instance of the DevNet Sandbox;

Let’s roll up our sleeves and dig into the next part of utilizing the SDK. In this installment of the blog series, we will look at how simple it is to leverage python to programmatically run IOS commands throughout your entire infrastructure with DNAC’s command runner APIs. We will also assume you already have installed the SDK and understand how authentication works.

What is Command Runner?

Command Runner is a feature in Cisco DNA Center that allows you to execute a handful of read-only (for now) IOS commands on the devices managed by DNAC

Here is how you can get a list of all supported IOS commands.

commands = dnac.command_runner.get_all_keywords_of_clis_accepted()

dnac – Our connection object we created from Part 1 of the series

command_runner – Command runner class. Calling it will allow us to access the underlying methods

get_all_keywords_of_clis_accepted() – This is the method we are after to display a list of all supported keywords.

Makes sense? Now that we understand what Command Runner is, let’s dig into using the APIs to build a simple use case.

Command Runner flow

The use case we are about to build together is a simple configuration backup. In order to accomplish this task we will need to:

1. Retrieve a list of all managed devices

2. Execute a `show run` on each device using Command Runner APIs

3. Retrieve the results and save them to file

But before we do so, understanding Command Runner flow is prudent.

Cisco DNA Center API calls are asynchronous, which means for each executed task a Task id is created. Upon task completion content can be retrieved from /file endpoint.

Endpoints and methods used

◉ POST /dna/system/api/v1/auth/token

◉ GET /dna/intent/api/v1/network-device

◉ POST /dna/intent/api/v1/network-device-poller/cli/read-request

◉ GET /dna/intent/api/v1/task/{task_id}

◉ GET /dna/intent/api/v1/file/{file_Id}

This sounds too complex, right? Not really, with the help of our handy dandy SDK we are able to handle all of this very easily.

Let’s take it step by step

Authenticate

– Create a new connection object and assign it to a variable

dnac = DNACenterAPI(username=dnac_creds['username'], password=dnac_creds['password'], base_url=dnac_creds['url'])

Retrieve list of devices

– Using the devices class to call get_device_list() method to retrieve a list of all managed devices.

– Upon 200 OK loop through the list of Switches and Hubs and extract the device id, we need to leverage it to programmatically run the command on each device

– Access device id variable via device.id pass it to and call cmd_run() function

def get_device_list():

    devices = dnac.devices.get_device_list()

    devicesuid_list = []

    for device in devices.response:

        if device.family == 'Switches and Hubs':

            devicesuid_list.append(device.id)

    print("Device Management IP {} ".format(device.managementIpAddress))

    cmd_run(devicesuid_list)

Execute Command Runner

– As we iterate over each device, we will need to execute show run command. to do so use command_runner class and call read run_read_only_commands_on_devices() method. This method requires two inputs of type list: commands and deviceUuids

– Upon execution DNAC will return a taskId (asynchronous, remember?)

– Check its progress via task class by calling get_task_by_id() method. Once the task has been successfully executed (you can use the built-in error handling within the SDK to check but that’s for another blog post) grab the returned fileId

– Now simply access the file class and call the download_a_file_by_fileid() method et VOILA!

def cmd_run(device_list):

    for device in device_list:

        print("Executing Command on {}".format(device))

        run_cmd = dnac.command_runner.run_read_only_commands_on_devices(commands=["show run"],deviceUuids=[device])

        print("Task started! Task ID is {}".format(run_cmd.response.taskId))

        task_info = dnac.task.get_task_by_id(run_cmd.response.taskId)

        task_progress = task_info.response.progress

        print("Task Status : {}".format(task_progress))

        while task_progress == 'CLI Runner request creation':

            task_progress = dnac.task.get_task_by_id(run_cmd.response.taskId).response.progress

        task_progress= json.loads(task_progress)

        cmd_output = dnac.file.download_a_file_by_fileid(task_progress['fileId'])

        print("Saving config for device ... \n")

Congratulation!

That was a lot! Luckily the SDK handled a lot of the heavy lifting for us here. This is a great example of configuration management. You could use this as a base to start building out a simple configuration drift monitoring tool given that the config is returned as JSON data. We can easily use JSON query to check for any configuration drift and automatically rebase it to the original config. This can be taken a step further even by leveraging Git for version control of your device config.

Continue reading

Network Automation with Cisco DNA Center SDK – Part 1

From orchestrating deployment automation to network management and assurance, Cisco DNA Center controller is the brain of network automation. With Cisco’s API-first approach in mind, Cisco DNA Center enables developers to build network applications on top of DNA Center.

Let’s start from the beginning

For this blog, I’m going to start from the very beginning:

◉ you don’t need prior knowledge of Cisco DNA Center

◉ you don’t need to know advanced coding and networking concepts

◉ you will need basic Python and API knowledge to understand the utilization of the SDK

If you do not have basic Python and API knowledge … don’t worry. DevNet has some great resources to get you started with the basics.

Start Now – Cisco DNA Center SDK

At this point you should have you developer environment ready to go, if you don’t, this DevNet module should help

Now let’s make sure we install our SDK before we start using it.

DNA Center SDK is available via PIP and the Python Package Index (PyPI). To install it simply run:

$ pip install dnacentersdk

Working with the DNA Center APIs directly without the help of the Python SDK is pretty straight forward, however, when you are looking to write a network automation, the code can become rather repetitive.

import requests

         DNAC_URL = [DNA Center host url]

         DNAC_USER = [username]

         DNAC_PASS = [password]

         def get_auth_token():

             """

             Building out Auth request. Using requests.post to make a call to the Auth Endpoint

             """

             url = 'https://{}/dna/system/api/v1/auth/token'.format(DNAC_URL) 

             hdr = {'content-type' : 'application/json'} 

             resp = requests.post(url, auth=HTTPBasicAuth(DNAC_USER, DNAC_PASS), 

         headers=hdr) 

             token = resp.json()['Token'] 

             print("Token Retrieved: {}".format(token)) 

             return token

Using the `requests` library we make a POST call to the /auth/token endpoint. The result, if 200OK, will return an authentication token that will need to be utilized for all subsequent API calls as part of `X-Auth-Token` header call. Which means every time we have to call the get_auth_token() function to refresh the token. This is what we are trying to avoid as you can see how repetitive this could get.

Life with Cisco DNAC Center SDK

The DNA Center SDK saves you an insane amount of time by not requiring you to:

◉ Setup the environment every time

◉ Remember URLs, request parameters and JSON formats

◉ Parse the returned JSON and work with multiple layers of list and dictionary indexes

Enter dnacentersdk (queue The Next Episode and drop the shades 🕶 )

With dnacentersdk, the above Python code can be consolidated to the following:

from dnacentersdk import DNACenterAPI

DNAC_URL = [DNA Center host url]

DNAC_USER = [username]

DNAC_PASS = [password]

dnac = DNACenterAPI(username= DNAC_USER, password= DNAC_PASS, base_url= DNAC_URL)

Let’s dig into the code here to see how simple it is:

1. Make the SDK available in your code by importing it

from dnacentersdk import DNACenterAPI

2. Define your DNA Center’s host url, username and password

DNAC_URL = [DNA Center host url]

DNAC_USER = [username]

DNAC_PASS = [password]

3. Create a DNACenterAPI connection object and save it

dnac = DNACenterAPI(username= DNAC_USER, password= DNAC_PASS, base_url= DNAC_URL)

From this point on, in order to access the subsequent API calls, you don’t have to worry about managing your token validity, API headers or Rate-Limit handling. The SDK does that for you.

Another great feature about the SDK is that it represents all returned JSON objects as native Python objects so you can access all of the object’s attributes using native dot.syntax!

Congratulations!

At this point you have a working developer environment and a python project that leverages the DNA Center SDK. For the next installment of this series, I’ll walk you through building on top of the code we are building together here, and will start exploring how to leverage the SDK to automate some of the tasks within Cisco DNA Center. For future reference, everything I have mentioned here – from SDK documentation to code – can be found on Cisco DevNet.

Source: cisco.com

Continue reading

The Darkness and the Light

Introduction

The psychoanalyst Carl Jung once said “One does not become enlightened by imagining figures of light, but by making the darkness conscious. The later procedure, however, is disagreeable and therefore not popular.”

With a quote as profound as this, one feels obligated to start by saying that workload security isn’t nearly as important as this concept of personal enlightenment that Jung seems to point to. The two admittedly are worlds apart. Yet, if you’ll allow it, I believe there is wisdom here that might be applied to the situation we find ourselves faced with- namely, reducing our business risk by securing our workloads.

The challenge

Many organizations seek to obtain an acceptable balance between the lowest spend in trade off to the highest possible value. Any business not following this general guideline may soon find themselves out of cash. A common business practice is to perform a cost-benefit analysis (CBA). Many even take risk and uncertainty into account by adding sensitivity analysis to variables in their risk assessment as a component of the CBA. However, as well meaning as many folks are, they may often focus on the wrong benefit. With security, the highest benefit is often finding the lowest risk, but again one must ask, “What are our potential risks?“.

Often when risks are evaluated folks tend toward asking questions from the perspective of outside looking in, determining who they want to get through their perimeter defenses, and where they want them to be able to go. These questions often get answered with something perhaps as nebulous as ‘our employees should be able to access our applications’. Even when they get answered in more detailed fashions, perhaps detailing groups of users needing access to specific applications, they often don’t realize that, while not entirely meaningless, that fundamentally they are asking altogether the wrong questions.

The perspective those questions come from is where the failure begins. Deep Throat’s dying words to Scully are perhaps the most appropriate and in fact the very premise from which we shall begin: “Trust no one.”

Trust no one

Most reading this will be familiar with the industry push towards Zero Trust, and while that isn’t the focus of this article, certain aspects of the concept are quite pertinent to our topic of exposing potential darkness in our systems and policies. Aspects such as not trusting yourself or the well-configured security constructs put in place.

The questions to start by asking yourself are:

◉ If your organization were compromised, how long would it take you to know?

◉ Would you even ever know?

◉ Do you trust your existing security systems and the team that put them in place?

◉ Do you trust them enough not to watch your systems closely and set triggers to alert you to undesired behavior?

Most folks believe they are quite secure, but like most beliefs, this comes from the amygdala, not the prefrontal cortex. Meaning this is based on feeling, not on rational, empirical data backed by penetration-tested proof.

I spent a decade helping folks understand the fundamentals necessary to take and pass the CCIE Voice (later Collaboration), CCIE Security, and CCIE Data Center exams. Often this would look like me and 15-20 students holed up in some hotel meeting room in some corner of the globe for 14 days straight. Often, during an otherwise quiet lab time, someone would ask me to help them troubleshoot an issue they were stuck on. Regardless of the platform, I’d ask them if they could go back and show me the basics of their configuration. Nearly every time the student would assure me that they had checked those bits, and everything was correct. They were certain the issue was some bug in the software. Early on in my teaching career I’d let them convince me and we’d both spend an hour or more troubleshooting the complex parts of the config together, only to at some point go back and see that, sure enough, there’d be some misconfiguration in the basics.

As time went on and I gained more experience, I found it was crucial to short-circuit this behavior and check their fundamentals to start. When they would inevitably push back saying their config was good, I’d reply with, “It’s not you that I don’t trust, it’s me. I don’t trust myself and with that, if you would just be so kind as to humor me and show me, I’d be truly grateful.” This sort of ‘assuming the blame’ would disarm even the most ardent detractor. After they’d humored me and gone back to beginning to review, we’d both spot the simple mistake that anyone could have just as easily made and they’d sheepishly exclaim something such as, “How did that get there!?!?  I swear I checked that, and it was correct!“. Then it would hit them that perhaps they actually did make a mistake, and they would go on to fix it. What was far more important to me than helping them fix this one issue was in helping them learn not to trust themselves, and in so doing, begin a habit that would go on to benefit them in the exam and I’d like to believe, in life. What they likely didn’t know was how much this benefitted me. It reinforced my belief in not trusting myself, rather setting up alerts, triggers, and even other pnuemonics that always forced me to go back and check the fundamentals.

Lighting up the darkness

So, how does all of this apply to workload protection?

Organizations have many applications, built by many different teams on many different platforms running on many different OSes, patch levels, having different runtimes and calling different libraries or classes. Surprisingly, many of these are often not well understood by those teams.

Crucial to business security is understanding the typical behavior in an organization’s workloads. Once understood, we can begin to create policy around each one. However, alone, policy is not enough to be trusted. Beyond implementing L4 firewall rules in each workload, it’s important to closely monitor all activity happening. Watching the OS, the processes, the file system, users shell commands, privilege escalation from a user login or a process, and other similar workload behaviors is key to knowing what’s actually happening rather than trusting what should be.

An example might be someone cloning a git repo containing some post-exploitation framework -something such as Empire or PoshC2 to use once they gain initial access after exploiting some vulnerability, testing different techniques to elevate their privileges using a valid account attack or perhaps that of a hijacked software process by using an exploitation for privilege escalation attack.

This isn’t by any means a new sort of attack. Nor is the knowledge that workload behaviors must be actively monitored.

So why then does this remain such a problem?

The challenges have been in collecting logs at scale, parsing them in the context of every other workload’s actions, and garnering useful insights. While central syslog collection is necessary, there remain some substantial drawbacks, primarily with that last bit about context. Avert so-called Zero-Day attacks requires live, contextual monitoring such as is achieved through this type of active forensic investigation.

A better source of light

How do we cast the proper light on only activity we’re interested in?

How do we help our workloads have a sort of -again, if you’ll allow the rough metaphor- collective conscious?

Cisco Secure Workload  is based primarily on distributed agents installed on every workload, constantly sending telemetry back to a central cluster. Think of them as Vary’s informants: “My little birds are everywhere.” -The Master of Whisperers, GOT

These informants play a dual role: First in reporting back to the cluster what I like to call the 3 P’s: Packages (installed), Processes (running), and Packets (Tx/Rx’d); and secondly in obtaining from the cluster a list of rules to be applied to each workload’s firewall rules specific to each workload. They also gather the very type of forensic activity we’ve been discussing. This is done with the collective knowledge and context of every other workload’s behavior.

Cisco Secure Workload gives us great power in defining the behaviors we wish to monitor for, and we can draw from a comprehensive pre-defined list, as well as write our own.

Aggressive Disclosure

Some new regulations require that breaches to an organization must be reported quickly, such as with GDPR where reporting is mandated within 72 hours of each occurrence. Most regulations don’t require that aggressiveness in reporting, but are being taken to task over such inadequate measures, such as in the case of HBR’s report on  a hotel chain breach.

Hackers were camping out for four years in the workloads of a smaller hotelier that the chain aquired. FOUR YEARS! That is an awfully long time to not know that you’ve been pwned. What I wonder is, how many more organizations have currently breached workloads today with no knowledge or insight. Complete darkness, one might say.

As Jung might have appreciated, it’s time to make that darkness conscious.

Key takeaways

1. Don’t rush security policies. Get key stakeholders in the same virtual room, discuss business, application, and workload behavior. Ask questions. Don’t ask with a grounding in known technological capabilities. Ask novel questions. Ask behavioral questions such as “how should good actors behave, who are those good actors, and what bad behavior should we be monitoring and alerting for.” Ensure wide participation with folks from infosec, governance, devops, app owners, cloud, security, and network teams, to name a few.

2. Evaluate carefully the metrics you are using for CBAs and, if you’re not sure if you are using the best metrics, ask a trusted advisor -someone who has been down this path many times- about what you should be measuring.

3. Trust no one. Not yourself, not the security policies put in place. Test and monitor everything.

4. Cast a bright, powerful light into your workload behavior. Deploy little birds to every workload and have them report behavioral telemetry back to a central, AI-driven policy engine, such as Tetration. Turn all of your workloads -regardless if they live in a single data center or are spread out across 15 clouds and DCs- into a single conscious

5. Be sure you can meet current and future laws on aggressive reporting in less time than regulations call for. You want this knowledge for yourself in as short of time as possible so that you can take meaningful action to remediate, even if you aren’t subject to such regulations.

Be vigilant in monitoring and revisiting the basics often. By staying humble, questioning everything, and going back to the basics, you likely will find ways of tightening security while simplifying access.

Source: cisco.com

Continue reading

Wireless Spectrum is Not Just for Mobile Operators Anymore

Cable operators scored a big win in the race for 5G by diving into the Federal Communications Commission’s (FCC) recent Citizens Broadband Radio Service (CBRS) spectrum auction. Three of the country’s largest cable companies – Cox, Comcast, and Charter – collectively bid more than $1 billion to gobble up mid-band spectrum perfectly suited for 5G. This promises to be a game-changer in mobile offerings.

These three large Multisystem Operators (MSOs) bought a collective 19-24MHz for $1.14 billion across their wireline footprints, combining for 4.6BMHz Point of Presence (POPs), or .25 cents per MHz/POP. This is a standard measurement for the value of spectrum based on how many people are covered versus how much spectrum is available.

The CBRS licenses are for 10-year periods and purchased on a per-county basis, with 40MHz available in any given county, and some of this may cover large, urban areas. Cable companies will now be able to deliver consumer mobile services, Fixed Wireless Access (FWA) services, and Managed Private Networks (MPNs) for enterprises. In the early phase, MPNs (4G/5G+WiFi6) will be very attractive to enterprises as they don’t need to buy or sublease the license for the whole county and can rely on the expertise from MSOs to run these networks.

Because the services work both outdoors and indoors, enterprises may wish to use it to connect their Internet of Things (IoT) devices. They may even use it to replace or supplement Wi-Fi in addition to IoT connectivity. Service providers, meanwhile, will most likely use CBRS to deliver FWA services and as a replacement for last-mile fiber access and consumer mobile service to offload their traffic from their Mobile Virtual Network Operator (MVNO) partner.

Part of the lure in the purchasing spectrum for these MSOs is to build their own inside-out wireless networks to eliminate high roaming costs they’re paying major mobile service providers through MVNO agreements. Analysts estimate they’re paying up to $700 million in MVNO costs every year.

How cable operators can win with CBRS

The mobile “greenfield” cable companies don’t have legacy 3G or 4G networks to build from, however, they’ll need to make some big decisions around the architecture. Should they start with 4G and then migrate to 5G or go directly to 5G? Should they look at the standard radio model or the new disruptive open Radio Access Network (oRAN) architecture? Going all cloud-native is a no brainer but how distributed the network should be is a decision they need to make. Deciding on what level of automation and security will enable them to run this network at an attractive cost should be a key driver.

In the 4G world, Cisco is a leading provider of packet core and we’re radio agnostic. In the past, service providers were locked into whoever owned the radio, but we can give operators a lot of flexibility. Not being locked into a vendor is a huge advantage from a cost perspective because they can purchase radio equipment from smaller, less expensive, and more agile vendors that will be more open to meeting their demands than larger companies. Another advantage is being able to mix and match from several different vendors and operate them across various regions of their market to identify which ones are the best performers.

As a leader in 5G, we’re a founding member of the Open RAN Policy Coalition. Our first oRAN deployment was a highly successful Non-Standalone (NSA) network with Rakuten in Japan. The best part of that deployment is that Rakuten is free to partner with any number of vendors. DISH Network has also publicly stated its intention to build a 5G Standalone (SA) network using oRAN technology, so it’s clearly gaining traction throughout the industry.

Cable operators need to consider new technology as they expand and modernize networks to capture new service opportunities. Not being locked down between radio and compute allows them to maximize their investment in compute. Also, now that they’ve jumped into the mobile business with both feet, cable executives will be under increasing pressure to make these new ventures profitable. For example, Comcast’s offering is reportedly on track to break even by the end of 2021 with approximately 3.5 million lines of service. Utilizing oRAN could really help make this a reality while saving Capital Expenditures (CapEx) and keeping those costs off the books.

How will this affect 5G development?

CBRS spectrum is expected to cover 80 percent of cable customers in the United States. That’s a very large swath of the country and could mean big money for the MSOs if they use it right. That’s why the FCC is referring to this as the “5G spectrum”. This will make the big cable companies very competitive in the race to roll out SA 5G networks.

Because they are new to this domain, their competitiveness will come from being able to offer more customized solutions for their customers.  As Cable Operators modernize and add new capabilities to their network, they need to look to the future – go right for 5G. The 4G subscribers today will face a cycle of upgrades over the next 24-36 months when most will move into the 5G phone domain, and all smartphones will be 5G within the next few years.

Did you know that Cisco is a leading security provider, protecting 100 percent of the Fortune 100? Or that our automation tools provide a bridge between intent and action? No one is better equipped to secure the cable network. We’re moving into a domain where 5G networks are complex, with automation and security being core fundamentals of these solutions. Cisco is not just a mobile player, we’re an end-to-end network provider with SD-WAN and security portfolios, and dashboards for full network visibility and control.

The future of wireless is multi-access

Now that cable companies have purchased the spectrum license, they can offer 5G to enterprises as a managed service and couple it with Wi-Fi 6 to cover a large variety of use cases. By teaming up with service providers, we can bring them a best-of-breed ecosystem. In this way, cable operators can pinpoint areas of priority that would have a higher take rate for the service so they’re not stuck and can adjust as needed.

We’re building out this service so we can learn together, iterate on innovations, and identify high-priority areas. As a member of the CBRS Alliance, we look forward to working with these MSOs as they build out their new networks. At SCTE-ISBE Cable Tec Virtual Expo, we will be speaking on The state of Converging Access & 5G Mobile Networks. 

Source: cisco.com

Continue reading

SaaS-based Kubernetes lifecycle management: an introduction to Intersight Kubernetes Service

The transition to cloud native application architectures is rapidly growing and becoming mainstream, increasing the need for container operationalization and management. According to a Gartner report, “growing adoption of cloud-native applications and infrastructure will increase use of container management to over 75% of large enterprises in mature economies by 2024, up from less than 35% in 2020.”

Three years ago we launched Cisco Container Platform (CCP), a self-hosted software container management platform, based on upstream Kubernetes, offering integrations with all the popular public clouds as well as any hardware on-premises. As we have been enabling customers in their containerization and DevOps journeys, we always come across the three key personas that we are trying to help: IT Admins, DevOps and development teams.

◉ IT Admins, responsible for not just for the Kubernetes layer but also the end-to-end cloud infrastructure. They are looking for common tools to easily deploy, manage, visualize, and monitor across the entire infrastructure stack, from server firmware management, to the hyperconverged layer, to the automation and container lifecycle management.

◉ DevOps teams are responsible for the stack’s Day 2 operations. They are looking to protect the precious application data and automate deployment to be able to scale across both infrastructure and application stack.

◉ Development teams want a simple API to hide infrastructure complexity and tools to automate continuous delivery of their Kubernetes-based applications.

The feedback was consistent: how can we expand the functionality of our container management offering to enable integrated management of the complete infrastructure stack under the Kubernetes layer?

That’s exactly why we built Intersight Kubernetes Service.

Expanding Intersight with Kubernetes management

Back in October this year, at Cisco’s Partner Summit, we made a series of announcements under a common umbrella message of “simplifying IT operations across multicloud”. One of them was regarding Cisco Intersight and its evolution. Cisco’s Intersight, from a Cisco data center infrastructure management solution, is becoming a comprehensive cloud operations platform, helping users simplify the management and optimization of infrastructure, workload and applications – on-premises and on public clouds.

One of the first brand new modules to come out of the exciting new Intersight roadmap is Intersight Kubernetes Service (IKS). IKS effectively expands the Cisco Container Platform’s functionality to benefit from Intersight’s native infrastructure management capabilities, further simplifying building and managing Kubernetes environments. IKS is a SaaS offering, taking away the hassle of installing, hosting, and managing a container management solution. For organizations with specific requirements, it also offers two additional deployment options: (with a Virtual Appliance). So let’s take a look at how IKS can make the lives of our personas easier.

Building an end-to-end data center and edge Kubernetes environment with a few clicks

A good example comes from the retail sector: an IT admin needs to quickly create and configure hundreds of edge locations for the company’s retail branches to do AI/ML processing and a few core ones in privately-owned or co-located data centers. The reason it makes sense for processing or storing large chunks of data at the edge is the cost of shipping the data back to the core DC or to a public cloud (and latency to a certain extent).

Creating those Kubernetes clusters would require firmware upgrades, OS and hypervisor installations before we even get to the container layer. With Cisco Intersight providing a comprehensive, common orchestration and management layer, from server and fabric management, to hyperconverged infrastructure management to Kubernetes, creating from scratch a container environment can be literally done with a few clicks.

IT admins can use either the IKS GUI, its APIs or integrate with an Infrastructure as Code plan (such as HashiCorp’s Terraform) to quickly deploy a Kubernetes environment, on a variety of platforms – VMware ESXi hypervisors, Cisco HyperFlex™ Application Platform (HXAP) hypervisors and/or directly on Cisco HyperFlex™ Application Platform bare metal servers (coming soon) – enabling significant savings and efficiency without the need of virtualization.

Similar to the Cisco Container Platform, IKS will also soon support public cloud integrations with all the popular providers. After deploying the environment customers can easily lifecycle manage the entire stack as shown in this video (shown between 1.49-3.22).

Adding full-stack application visibility with Intersight Workload Optimizer

DevOps teams want to bridge the application and infrastructure gap as much as possible. They would be looking to right-size their application replicas (vertically and horizontally scaling of pods and nodes) based on traffic load. A benefit of IKS is that users can connect their Kubernetes workloads to another Intersight SaaS module used for application resource management, Intersight Workload Optimizer, and benefit from right-sizing their containers (by monitoring the traffic between the pods) as explained here (4.23 – 6.11). This way customers can get maximum ROI from the different locations where capacity can be an issue such as edge locations.

At the same time, IT Admins are always aiming for complete visibility across the application and infrastructure stack, beyond just the Kubernetes layer. As both IKS and IWO are part of the same platform, users can get a comprehensive view on the health of the entire stack, which is crucially important when remediating.

Stay tuned for our big IKS general availability launch in February 2021

As we work on the roadmap for IKS and the new features it will bring, we couldn’t be more excited to work with customers exploring new grounds on how to offer more value and accelerate IT operations.

Continue reading

Webex App Hub: The Premier Collaboration App Ecosystem To Help You Get Stuff Done

Webex App Hub is a Connections Platform that Helps Everyone do Their Best Work Everyday, Everywhere

As announced today, we are thrilled to bring to market the all new Webex App Hub! This reimagined app ecosystem is designed to help people find industry-leading apps with deep integrations with Webex in order to help move work forward.  It’s easy to visit the all new Webex App Hub to find apps that automate and enhance your work experience.

Our joint work with developers, partners, and independent software vendors help extend the value of Webex by offering you a suite of collaboration solutions across multiple industries and functions. The Webex App Hub makes it simple for users and IT to take advantage of native integrations, bots, and widgets to make work flow easier and smarter.

Integrations Making it Easy to Add and Collaborate with Third-Party Applications 

Webex already integrates seamlessly with many industry-leading apps, including brand new integrations announced today with Workplace from Facebook, Box, Salesforce, ServiceNow, DropBox, and Miro.

Webex isn’t just about video conferencing and meetings. Webex is a connections platform that helps people to get work done, whenever and wherever they need to. With open APIs, SDKs, and workflow connectors including IFTTT, Zapier, and Microsoft Power Automate, Webex allows you to create truly powerful custom integrations to redefine workflows and save time. You’ll also find a wide variety of third-party apps on the Webex App Hub that work out-of-the-box and support everything from productivity and working from home to telehealth and personal reminders. Some recent additions include:

◉ PagerDuty: Automatically create a War Room space with the team responsible for a service. Add service owners and acknowledge, resolve, and escalate incidents quickly using the bot.

◉  Microsoft Outlook Alerts: Stay on top of your inbox with notifications from the Outlook Alerts for Microsoft Office 365 bot for Webex. Create custom rules based on subject lines and email recipients and never again miss a business-critical email. For greater efficiency and fluidity, you can even have those insights sent directly to relevant Webex spaces and teams.

◉ Trello: Use the Trello bot to easily update and create new Trello Cards and Lists directly from the Webex app and get real-time notifications that enable all members of the team to stay in the know.

◉ ExtendedCare Cloud Virtual Care : ExtendedCare Telehealth™ and ExtendedCare Bedside™ are available as cloud-based solutions powered by Cisco Webex Meetings. The world’s most robust collaboration infrastructure now enables enterprise-class performance, reliability, and security delivered in tailored, carefully phased deployments that meet your facility’s precise needs and expectations.

◉ ADP: With ADP Virtual Assistant, companies using ADP for payroll and Webex for internal collaboration can give their employees convenient access to their own workplace information – directly within Webex.

We make it easy for users to find and use integrations within a Webex messaging space, and soon you’ll be able to experience the same thing in a Webex meeting. Users will be able to easily add and collaborate with third-party applications while in a Webex meeting. When the meeting ends, the work is automatically saved so you can pick up where you left off when the time allows.

Out of the Box Integrations Help You Get Work Done Faster and Better

What sets the all new Webex App Hub apart is the breadth of these integrations across calling, meeting, messaging, devices, intelligence and analytics. No other collaboration app ecosystem compares in scope.

And especially for developers, we’re introducing a whole new world of opportunity: Webex is OPEN!  Come work with us and build the apps that will help power efficiency in this new world of work. The Webex SDKs and widgets make it easy  for developers to embed high quality audio-video calling and messaging into any web or native application. We’ve also exposed more powerful capabilities, like programmatically adding an embedded app to a space.

Source: cisco.com

Continue reading