Improving Application Experience with Full-Stack Observability

In the not-too-distant past, everything in the application and networking stack was under IT’s control. Workloads lived securely in the on-premise data center—people sat in their campus offices connected to the secure wireless network, and an MPLS service with an SLA connected branch offices to the data center.

Today, workforce productivity depends on cloud and SaaS applications that often rely on the public cloud infrastructure, which in turn depends on the internet as part or all of the WAN connectivity which in turn depends on a multitude of ISPs, CDNs and advanced network services. Hybrid and native clouds applications are mostly containerized, so performance can be affected by the communication paths among the microservices, both in the data center and cloud. The total application experience as perceived by the workforce is dependent on the performance of all the components of applications and network connections acting in concert. If one element falters, the whole experience can be impacted.

NetOps and DevOps need to understand the interdependencies among the component applications and tune the enterprise network and internet paths accordingly. A unifying view can only be provided by the network fabric that monitors and analyzes the full stack of interlacing components: from the foundational network data layer to the software-defined WAN to application containers in the cloud. With the workforce accessing applications from literally everywhere, all the time, IT requires pervasive, real-time monitoring of network, internet, and application performance with auto-healing capabilities. This is Full-Stack Observability, driven by software-defined controllers and network analytics that enable ​action, policy, and automation.

Observability Begins with a Deep Historical View

To improve application experience, IT needs tools to record, analyze, and report on network and application activity at a massive scale to build a deep historical data set against which to apply AI and Machine Reasoning tools. Hybrid and cloud applications consist of multiple micro-components connected by east-west traffic in the data center or cloud service. Continuous monitoring and analysis are needed to optimize application experience because many inter-application communication issues are transitory and difficult to replicate. Application performance needs to be recorded for machine analysis to determine recurring issues and root causes. Full Stack Observability from the perspective of the application requires:

◉ Application end-user experience as measured by ThousandEyes, NetFlow, or AppDynamics;

◉ Dependency graph to the underlying composite application services and infrastructures;

◉ Comprehensive availability and performance data on each of the supporting components such as composite application services, public cloud services, ISPs, networking devices, compute and storage infrastructure.

The irony of having mountains of telemetry and activity logs awaiting analysis by overworked IT teams is that there is too much noise in too much data for humans to deal with in a timely manner. When the volume of data is beyond human scale and below human sensitvity, machine reasoning (MR) automates the analysis of trillions of bytes of switch and router telemetry, wireless radio fingerprints, and network access point interferences to uncover patterns in the chaos, and turn the findings into actionable insights and automated mitigation actions.

Automated Observability with AI Nework Analytics

To make full use of the deep historical and real-time data, IT can take advantage of an Analytics Stack that can:

◉ Use purpose-built applications to augment human engineers in NetSecOps with Insights into network performance and security vulnerabilities

◉ Leverage machine-speed analytics and knowledgebase-driven Machine Reasoning Engine (MRE) to unburden NetSecOps from mundane monitoring tasks to focus on proactive digital transformation projects with DevOps.

◉ Achieve massive collection, storage, and parsing of diverse data lakes—collections of anonymized network and application telemetry based on volume, velocity, and variety of data to compare performance and security metrics.

For several decades, Cisco has been building a data lake of worldwide, anonymized customer telemetry in parallel with a knowledgebase of expert troubleshooting experience, both of which are available to machine reasoning algorithms under the command and control of Cisco DNA Center. With Cisco AI Network Analytics, NetOps can, for example, be forewarned of increases in Wi-Fi interference, network bottlenecks, uneven device onboarding times, and office traffic loads in the more traditional data center and campus network environments.

Observability for cloud-based applications, however, needs a different approach as much of the application infrastructure is not under direct control of IT. Direct internet connections to clouds can be unreliable—especially for latency-sensitive applications—unless they are monitored and automatically tuned using cloud onramps.

Observability into Cisco Cloud OnRamps for each of the major cloud services—Microsoft Azure, Amazon AWS, and Google Cloud, as well as colocation, and SaaS platforms—provides the ability to monitor and set performance parameters that are automatically applied to maintain the proper quality of service based on the type of application and cloud provider. Paths are calculated by tracking characteristics including packet loss, latency, and jitter in the data plane tunnels among cloud workloads and edge devices. Cisco AppDynamics and ThousandEyes provide application layer observability for inter-cloud and intra-cloud dynamics that enables NetOps and DevOps to monitor and identify factors affecting application experience.

Network Analytics + Software-Driven Controllers = Full Stack Observability

AI Network Analytics working in conjunction with Software-Driven Controllers enables Full Stack Observability. Operational intents and security policies defined in software-driven controllers are compared with telemetry and operational anomalies detected by an MRE to automatically adjust operations or isolate rogue devices. Always-on AI Analytics watch over the distributed workforce and workloads at machine-speed, making automatic adjustments or sending alerts with suggested remediations to appropriate levels of IT personnel or to SIEM applications to log and kickoff trouble tickets. Over time, NetOps and DevOps can fine-tune application performance using a consistent flow of insights from analytics to adapt to changes in workloads, workforce, and workplace.

The next shift is using AI and MRE to “personalized” recommendations on updates and patches for controllers. Upgrading controllers carries a certain risk given the complexity and many differences among existing network configurations. Knowing in advance what affect an update can have—and even if it applies to the existing configuration—can bring peace of mind to the process. Does a specific configuration warrant a patch if that issue is not relevant? If not, then there is no reason to force an update that is not required. Are controllers running an OS version with active PSIRT vulnerabilities? NetOps is alerted to put a higher priority on upgrading those specific controllers. Automation and observability go hand in hand to make operation teams more efficient so they can spend time on more valuable tasks.

Observability Provides Operational Simplicity and Serviceability

Full stack observability is the foundation of a new network and security operating model that ensures application experience and trust. The ultimate outcome of attaining full-stack observability is to make all the operations teams—NetOps, SecOps, DevOps and CloudOps—able to work together to raise the levels of serviceability across the application infrastructure. Automations that support full-stack observability simplify operations as well by eliminating many of the time-consuming and tedious tasks of network monitoring and troubleshooting.

Source: cisco.com

Continue reading

How Agility Has Become The Ultimate Superpower For IT

Many CIOs and IT professionals are feeling between a rock and hard place right now, battling the disruption caused by the global pandemic while facing immense pressure to accelerate their digital journeys.

Yet out of the crucible of these opposing forces, remarkable opportunities have emerged, along with new learnings and new innovations.

I recently had the pleasure of moderating a roundtable discussion with the CIOs of three large customers. I also spoke with two of my colleagues — Jeetu Patel, SVP and GM of Cisco’s Security and Applications business, and Todd Nightingale, SVP and GM of Cisco’s Enterprise Networking and Cloud business.

The disruption our CIOs faced was unprecedented. In the early days of the pandemic, one of them — a large health care system in northeastern United States — sent 1,000 back-office employees home within the space of a week. Many had never worked remotely before. Even today, only about 25 staff members are allowed back on site at any given time. And with 75 percent of workers set to remain remote, there appears to be no going back to the old ways.

Another, from a federal government department in Australia with responsibilities including immigration and customs border policy kicked off 2020 with the triple-whammy of massive wildfires, freak hailstorms, and the pandemic. With travel plummeting, the agency faced steep declines in revenue, even as the number of people accessing its network remotely soared from 500 to 20,000. This CIO’s team was asked to do more with less — and quicker.

Our third CIO — from a multinational technology company — said business continuity shot to the No.1 priority as markets went into lockdown. In India, that meant 200,000 people going remote almost overnight. This meant beefing up the network and VPN to keep mission-critical processes up and running.

Todd Nightingale said much of his focus is on ensuring our customers’ infrastructure is ready for these types of massive transitions. That means pushing critical resources, systems and functions to the cloud — such as Cisco’s Webex collaboration platform — and making them available everywhere, whether people are working from home, at critical sites or walking down the street.

“There’s this real need for everything we could have done from an office to now be doable from anywhere,” Todd said. “It’s an amazing transformation and it’s driving a ton of what we do.”

Jeetu Patel, who oversees our Webex collaboration platform, said that a major focus is providing digital experiences that are 10 times better than in-person interactions. For example, the new noise reduction feature in Webex, courtesy of Cisco’s BabbleLabs acquisition, eliminates the need for phrases like “Can you put yourself on mute?” or “Can you stop typing, please?”

Advice for becoming future-ready

Our CIOs stressed the importance of thinking outside the box, as well as upgrading talent to be ready for the huge opportunities they see emerging post-pandemic. For example, contact tracing is an opportunity to bring IoT (Internet of Things) to life. Given the vast amounts of data that will be collected, it’s also a time to think about security differently — not just as a function, but as a mindset.

They also cited four success factors for achieving greater resilience: agility, scalability, speed, and innovation. Among their recommendations: embracing the concept of the MVP (minimum viable product), rapid innovation, flattening organizational structures, and creating task forces.

Cisco’s Todd Nightingale said that the pandemic showed organizations how fast they can move if they need to, calling agility “the ultimate superpower for IT.” Agility is the core value driving Cisco’s focus on providing a “cloud onramp” through our platforms strategy.

Equally vital to agility, said Todd, is Cisco’s cloud automation strategy, which helps organizations transform their infrastructure “with a few clicks.” He also stressed the importance of monitoring network and application performance in order to ensure the best user experience. Cisco’s recent acquisition of ThousandEyes is critical to this, as it extends our end-to-end visibility capability into networks our users don’t necessarily own.

My closing message for the roundtable was this: Disruption is here to stay. Acceleration of digitalization is inevitable — we have to do it. And in many ways, the technology is the easy part. The hard part is breaking down the barriers to be able to respond with the required speed and agility. In that sense, the pandemic has actually helped organizations move faster, innovate more quickly and face into disruptions. The opportunities are here — it’s up to us to seize them.

Source: cisco.com

Continue reading

New Cisco 500-450 Exam: UCCEIS Sample Questions | UCCEIS Exam Info

Cisco UCCEIS Exam Description:

This exam tests a candidate's knowledge of installing and deploying Cisco Unified Contact Center Enterprise (Cisco Unified CCE) solutions. Cisco Unified CCE is part of the Cisco Unified Communications application suite, which delivers intelligent call routing, network-to-desktop computer telephony integration (CTI), and multichannel contact management to contact center agents over an IP network. Skills assessed include install, setup, configure, and troubleshoot the solution.

Cisco 500-450 Exam Overview:

• Exam Name:- Implementing and Supporting Cisco Unified Contact Center Enterprise
• Exam Number:- 500-450 UCCEIS
• Exam Price:- $300 USD
• Duration:- 75 minutes
• Number of Questions:- 65-75
• Passing Score:- Variable (750-850 / 1000 Approx.)
• Recommended Training:-
• Administering Cisco Unified Contact Center Enterprise Part 1 (AUCCE1) 2.0
• Administering Cisco Unified Contact Center Enterprise Part 2 (AUCCE2) 2.0
• Deploying Cisco Unified Contact Center Enterprise (DUCCE) 2.0
• Exam Registration:- PEARSON VUE
• Sample Questions:- Cisco 500-450 Sample Questions
• Practice Exam:- Cisco Unified Contact Center Enterprise Specialist Practice Test

Related Article:-

Passing Cisco 500-450 UCCEIS Exam is Now Easy in First Attempt

Continue reading

Threat Trends: DNS Security, Part 2

Part 2: Industry trends

In our Threat Trends blog series, we attempt to provide insight into the prevalent trends on the threat landscape. Our goal in giving you the latest info on these trends is that you’ll be better prepared to allocate security resources to where they’re needed most.

Knowing the larger trends can help in this pursuit, particularly when it comes to the most common threat types. This is what we covered in part one of this Threat Trends release on DNS Security, using data from Cisco Umbrella, our cloud-native security service.

However, different industries sometimes have different levels of exposure to certain threat types. For example, those in the financial services industry may see more activity around information stealers; others in manufacturing may be more likely to encounter ransomware.

This is what we’re going to cover in part two. We’ll focus on specific industries, looking at two things: the top threat categories they face, and the categories that they’re more likely to encounter when compared to other industries. In this way, you’ll be better armed knowing which threats you’re more likely to encounter within your industry.

As in part one, we’ll be looking at data covering the calendar year of 2020. This time we’ll be comparing yearly totals of DNS traffic to malicious sites, by industry. While we do this, we’ll occasionally drill down to the monthly level, or look at endpoint data, to highlight items of interest. All of this gives us a window into the categories of threats that generate the most traffic for various organizations.

So, without further ado, and in no particular order, here are the industry trends:

Technology

The vast majority of DNS traffic in the Technology sector—the sector involving the development and/or distribution of technological goods and services—can be attributed to two categories: cryptomining and phishing. These two categories alone accounted for 70 percent of the traffic for organizations in this sector.

Unsurprisingly, the Technology sector saw far more cryptomining traffic than any other industry. While much of this activity can be attributed to bad actors, it’s possible that more knowledge surrounding cryptocurrencies could lead workers in this field to attempt to install miners on their company computers, triggering DNS blocks in Umbrella due to company policy violations. In comparison, Financial Services—an industry where workers are more likely aware of the risks of running cryptomining software on company devices—had one of the lowest levels.

Interestingly, the Technology sector saw the second-highest level of ransomware-related traffic, primarily driven by attacks involving Sodinobiki and Ryuk. However, the incredibly high proportion of cryptomining pushed the overall percentage down, coming in a six percent. trojan activity was also high, given that Emotet and Trickbot were used to distribute Ryuk, as previously discussed in part one.

Financial Services

Phishing resulted in the highest levels of malicious DNS traffic in the Financial Services sector. In fact, this sector saw 60 percent more phishing than the next-closest sector, Higher Education. It’s possible that this sector is targeted by attackers through phishing more often than others simply because of its proximity to many bad actor’s end goal: money.

Supporting this idea is the fact that the Financial Services sector also saw more information-stealing threats than any other industry. While not known to generate high volumes of DNS traffic (only 2 percent), Financial Services saw five times as much traffic in this category than any other industry.

Financial Services also saw the second-highest amount of traffic in a number of categories, such as trojans, botnets, and remote access trojans (RATs). The breadth of malicious traffic seen in this industry could speak to how attractive a target it is to bad actors.

Healthcare

The Healthcare industry saw more trojans than any other sector, as well as higher numbers of droppers. Most of the trojan-based activity can be attributed to Emotet, as healthcare organizations were hit hard by the threat in 2020. Close to seven out of every ten trojans seen within the healthcare sector was Emotet. Throw Emotet’s close cousin Trickbot into the mix, you’re looking at 83 percent of all trojan-related traffic.

It likely comes as no surprise that ransomware also made its presence known within the Healthcare sector. Ryuk was particularly active, no doubt associated with the high activity surrounding Emotet. The Healthcare sector was also narrowly edged out of the second-highest place for ransomware, coming in only 1.5 percent lower in overall DNS traffic.

Manufacturing

Like the Technology sector, cryptomining activity was also high in the Manufacturing industry. It saw roughly half the activity seen in the Technology sector, but interestingly, there were almost three times as many endpoints in the Manufacturing sector involved in cryptomining. In short, more machines resulting in less DNS activity leads us to believe these endpoints were less powerful when compared to those in the Technology sector. It’s possible that the machines compromised are involved in the manufacturing process itself, even IoT related. In these cases, cryptomining would likely have been slower, but could still impact production speeds.

It turns out that the Manufacturing sector is also the most likely to be impacted by ransomware. This industry saw almost as much ransomware-related traffic as the next two closest industries combined (Technology and Healthcare). This appears to be a clear indication the industry is regularly targeted by bad actors, likely through big game hunting and the potential payout bad actors could receive.

Higher Education

The COVID-19 pandemic closed campuses worldwide in 2020. As classes moved remote, many malicious activities that would have been blocked on campus would have occurred on student’s home networks. This resulted in drop-offs in malicious activity for this sector in many categories from March onwards, and much lower overall numbers in 2020 than in previous years.

That’s not to say that activity dropped off a cliff, as certain activities that would require access to campus resources did register their share of DNS activity. For instance, phishing activity managed to put Higher Education in second place when comparing across industries. Cryptomining outfits also frequently target the Higher Education sector in an attempt to siphon off computing resources, or student-discounted cloud computing credits, to run their miners.

Government

Of the industries that we’ve examined, the Government sector appears to be the most evenly distributed across the top categories highlighted in part one of this series (Phishing, Cryptomining, Ransomware, and Trojans). The Government sector even saw a fairly even distribution for each of these categories when looking at them month-on-month.

The sole exception to this trend was cryptomining, which saw low numbers in the first three quarters of the year, only to jump in October as cryptocurrency values reached a high for the year and continued to climb. However, the month-on-month numbers didn’t fluctuate through the last quarter of the year, remaining at largely the same elevated level each month.

Preventing successful attacks

As mentioned earlier, the data used to show these trends comes from Cisco Umbrella, our cloud delivered security service that includes DNS security, secure web gateway, firewall, and cloud access security broker (CASB) functionality, and threat intelligence. The malicious activity shown here was stopped in its tracks by Umbrella.

Umbrella combines multiple security functions into one solution, so you can extend protection to devices, remote users, and distributed locations anywhere. Umbrella is the easiest way to effectively protect your users everywhere in minutes.

Picking your battles

There is no doubt that examining trends on threat landscape can reap benefits. Knowing where attacks are occurring can make it easier to decide where to dedicate your resources to defend against them. Cryptomining and phishing are commonly seen these days, as are trojans like Emotet and Trickbot, used to deploy ransomware such as Ryuk.

Of course, different sectors are impacted by different threats in different ways, so it helps to understand the specific trends surrounding the sector you find yourself within. For instance, it would be wise for someone in the Financial Services sector to keep a close eye on phishing trends, while someone in the Manufacturing sector may want to take a closer look at ransomware.

Ultimately designing a defensive strategy combining the larger trends and those of your specific industry, can bring you a long way towards protecting your assets.

Methodology

We’ve followed the same overall methodology in this blog that we did in part one, with a few changes in representation. Pie charts are based off DNS query traffic to malicious sites. Any category comprising more than one percent of traffic for a particular industry is represented in the charts. All categories below one percent are combined into the ‘All Others’ group in the charts.

Source: cisco.com

Continue reading

Five ways we’re improving telework with SD-WAN and telemetry

Bad dream for an IT engineer? Try this: an executive working from home gets booted off an all-hands video meeting. Then it happens again. And again.

That happened to me a couple of months ago. Fortunately, when I received the call, I could see immediately that the problem lay with the executive’s ISP, not our network. As a result, my team quickly resolved the problem and saved hours of troubleshooting time. And I slept better.

Better visibility is one of several ways our Customer Zero team is improving the telework experience at Cisco. As Customer Zero, we try out new Cisco technologies in a real-world setting so we can share our experiences with customers. Here are five ways we’re improving telework.

We’ve always had a robust telework program. Most people who work remotely use Cisco AnyConnect Secure Mobility Client on laptops and mobile devices and some teleworkers use the Cisco Virtual Office (CVO), which includes a hardware-based VPN service. AnyConnect and CVO are both what’s known as “full tunnel” solutions. All traffic from the laptop goes through a VPN tunnel to a Cisco data center. From there, cloud traffic takes another hop to its final destination.

But if I want to work on an Excel file, it doesn’t make a lot of sense for my request to go through the Cisco data center on its way to the Office 365 cloud. The detour adds latency and unnecessarily uses data center network bandwidth. It’s smarter to “split” the tunnel, providing separate routes for data center traffic and cloud traffic.

We’ve split the tunnel using our Cisco remote worker SD-WAN solution. On the Cisco vManage console, we’ve created a rule that sends traffic destined for designated trusted SaaS providers (Webex, Cisco TV, Office 365, and Box, etc.) directly to the cloud.

Our InfoSec team is strict about what they consider a trusted cloud. Other cloud traffic, like iCloud, also bypasses our data center. But rather than heading directly to its destination, it goes first to Cisco Umbrella, which blocks malicious domains and cloud applications.

The fastest path to a cloud service provider might be different at 8:30 a.m. than it is at 8:32 a.m., depending on network conditions. To deliver a consistently good experience with Office 365, we’re using an SD-WAN feature called Cloud On-Ramp for SaaS. It probes the various paths to the cloud to identify the best quality of experience at the moment and then directs the traffic over that path.

Many of us share a home internet connection. If your three kids are all in Zoom school, your Webex video might freeze. On the Customer Zero team, we’re using the QoS feature on our home ISR 1100 routers to prioritize Webex and other latency-sensitive applications. Whenever available home internet bandwidth dips below a certain threshold, the bandwidth allocated for Webex and other high-priority applications are automatically adjusted.

I’ve noticed that if an application is slow or the connection drops, a teleworker’s first instinct is to blame the equipment. I can’t count the times I’ve spent hours troubleshooting a case only to discover the source was an ISP issue. One of our favorite management tools is ThousandEyes, a software agent installed on the Customer Zero team’s laptops. ThousandEyes constantly collects user experience data—for example, the time it takes for a page to load, internet service provider issues, features used, laptop CPU utilization, runtime issues, etc. If a user opens a case but the issue disappears before we can look at it, we can go back in time to find the cause. Just last week someone reported a Webex issue, and ThousandEyes showed that at the time of the issue, laptop CPU utilization was 100%. That visibility saved us a fruitless investigation. We just explained to the user how to use a bot on Cisco Webex Teams if the issue ever happened again.

Source: cisco.com

Continue reading

Introducing the Cisco DNA Traffic Telemetry Appliance

Add-ons extend the latest technology to legacy systems, like how my old TV turned smart overnight with an additional streaming player. It is even better when the supplements work in cohesion with the primary products to deliver a seamless experience. Imagine if you could utilize the same remote to operate your TV and streaming player.

The Cisco Catalyst 9000 series wired and wireless devices enable enterprises to unlock newer network infrastructure possibilities. For instance, these platforms conduct deep packet inspection (DPI) and provide data streams for services such as the Cisco AI Endpoint Analytics and Application Assurance on the Cisco DNA Center. With Endpoint Analytics, customers are gaining unprecedented endpoint visibility, which is a crucial first step in implementing zero-trust security within the workplace and confidently deploying network segmentation without the risk of shutting down critical network services.

However, several organizations still have a portion of their network infrastructure that has not been migrated to the Cisco Catalyst 9000 series platforms. Those legacy infrastructures cannot perform the deep packet inspection required for advanced analytics. We are introducing the Cisco DNA Traffic Telemetry Appliance to bridge the gap between the new and existing deployments.

The IOS® XE-based telemetry sensor platform generates telemetry from mirrored IP network traffic from Switched Port Analyzer (SPAN) sessions of switches and wireless controllers. The appliance inspects thousands of protocols using the Network-Based Application Recognition (NBAR) technology to produce a telemetry stream for the Cisco DNA Center to perform analytics. The Cisco DNA Traffic Telemetry Appliance can handle 20-Gbps of sustained throughput traffic and inspect 40,000 endpoint sessions for device profiling.

Cisco DNA Traffic Telemetry Appliance serves two use cases: endpoint visibility and application assurance. The Cisco AI Endpoint Analytics service on the DNA Center analyzes the data received from the Telemetry Appliance to provide you with granular endpoint profiling details such as endpoint type, manufacturer, model, operating system, and others. The Cisco DNA Center also receives qualitative application performance metrics from the Telemetry Appliance and calculates application health data for business-critical applications. It analyses essential metrics such as delay, jitter, and packet loss to isolate and troubleshoot application performance issues efficiently.

Next time someone connects a TV to your network powered with the Cisco DNA Traffic Telemetry Appliance and the Cisco DNA Center, you will not only know the make, model, operating system, and other details about the endpoint. But you will also know if the user behind the device is accessing Netflix, YouTube, and other applications.  Remember, as you do this, you will also be operating both the legacy infrastructure and the new add-on appliance from a single controller, the Cisco DNA Center.

Continue reading

Why Cisco Joined the Confidential Computing Consortium

Building a Networked Mesh of Hacker-Resistant Software

The world’s digital devices are based on layered software stacks.  Each of these layers has its own security vulnerabilities. A successful attack made into one of the layers of software is typically leveraged to exploit another layer.

Some digital devices embed internal protections to limit potential damage. These protections are constructed using shared keys, certificates, or even passwords. Unfortunately, these shared secrets also can be compromised. Additionally, application software layer must implicitly trust underlying layers such as the Operating System or hypervisor manager. And, for these applications, there is little that can be done when the most fundamental layers of a device are actively being exploited.

Over the years, a variety of security technologies have been implemented to protect digital devices. From anti-virus to firewalls to intrusion detection systems, entire industries have been born. But hackers continue to overcome these protections. As long as developers continue to build traditional layers of software, and as long as our protections depend on software-based shared secrets, security exploits will continue.

Confidential Computing offers a new paradigm. Built upon secrets which never leave the specific computing chips, one layer of software can now be protected from exploits originating in another layer. Additionally, a hacker who has gained administrative privileges for a device’s Operating System will be unable to read or change an application’s data or code.

There are two foundational Confidential Computing technologies that enable this new paradigm. The first is the hardware-based Trusted Execution Environment (TEE). There is a class of TEE which allows application code to be compiled, signed, and encrypted by a software developer. That code can only be decrypted and executed within a compliant TEE. Subsequent memory or disk exchanges with the CPU are fully encrypted. Even a root hacker cannot look into the memory.

But using a TEE to run a verifiably genuine application is only part of the solution. This is where the second foundational technology plays a role. This technology is known as Remote Attestation. With Remote Attestation, an application within a TEE can externally assert the secure context in which it is running. Consequently, the TEE’s remote peer can verify that it is interfacing with a known, secured instance of untampered software.

Once two peers have verified each other’s identity, it becomes possible to integrate multiple sets of trustworthy peers together. The result is a mesh of directly connected trusted software. This eliminates entire classes of Operating System and hypervisor manager compromises from the list of attack surfaces that a hacker might exploit.

Getting to these trustworthy meshes will require agreements on the inter-device protocols needed for Remote Attestation. Some of these protocols will not be a surprise. For example, we can assume technologies like Transport Layer Security (TLS) might be used to connect the TEE. But within TLS, we will still need an industry-accepted language for communicating Remote Attestation claims about a TEE. Such standardization of these protocols will take time and work.

The good news is progress is being made. One place to look is the IETF’s Remote Attestation Working Group. In this venue, architectures for such specifications are nearing completion. But neither the IETF nor other traditional standards bodies have yet to float specific protocol proposals. Implementers only have access to a set of vendor-driven proposals. And each of these proposals has been framed upon the assumptions underlying a vendor’s specific TEE chipset.

This is where the Confidential Computing Consortium (CCC) is well positioned to play a role. Within the CCC, there are projects for acquiring attestable information out of TEEs. One of these projects is Open Enclave SDK for Intel SGX. Other venues exist for parallel efforts such as OP-TEE for Arm TrustZone. But these projects just scratch the surface of what can be Remotely Attested. Only now is the industry in a position to attempt to generalize and agree upon:

◉ The definitions of specific attestable TEE claims

◉ The level of trust that can be associated with a type of TEE or even on a specific TEE instance

◉ Acceptable stacks of network transport protocols and encodings

◉ How the initiator of a request can verify only approved TEEs have been used to deliver an end-to-end function

Accomplishing any of these objectives will require effort. Simultaneously allowing protocol extensibility and vendor neutrality will be non-trivial. The CCC can influence these discussions.

At Cisco, we care a great deal about the trustworthiness of networking peers. Our reasons for joining the CCC are simple. We are going to advocate for Remote Attestation interoperability. And we are going to integrate Remote Attestation into our Network Admission Control portfolio. We believe both have significant potential to reduce the risks that come from today’s layered software stacks.

Continue reading