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

Improving DNS Security While Preserving Resiliency

The IETF’s Discovery of Designated Resolvers

The Domain Name System (DNS) has played a key role in the Internet’s success. It was designed to be scalable and resilient to handle enormous growth. The DNS has also proven to be a strong control point used to identify and remediate threats as Cisco Umbrella (previously Cisco OpenDNS) has repeatedly demonstrated. As the industry seeks to strengthen privacy, it must find methods to do so that retain resilience or risk large outages. Used correctly, an emerging technology known as Discovery of Designated Resolvers (DDR) can facilitate secure discovery of resolvers. It’s a significant security feature and is the topic of this blog.

Figure 1: DNS traffic growth over four years (Source: Akamai)

Introduction

DNS has scaled well to meet the needs of over four billion people since its inception in the 1980s. In that time, there has never been an Internet-wide failure of the service. That is thanks to the millions of caching resolvers and large numbers of root servers spread around the world, along with redundancy at every other level. This architecture is no accident; it represents a solid design combined with decades of experience by people globally handling the Internet’s evolutionary growth in both size and capability.

One of the most important capabilities of the DNS is its use as a control point. For example, if bad actors attempt to use the DNS as a command-and-control (C&C) channel between them and their bots, the good guys use the DNS to identify and block those C&C channels. In the case of the recent attack on Solar Winds, this meant blocking queries to [*]avsvmcloud[.]com. A key value of Umbrella and similar services is that they are backed by expertise and ongoing operations to identify such threats. With IoT devices using mechanisms such as Manufacturer Usage Descriptions, the DNS can restrict communications from devices to a known set of destinations. Another use of the DNS is as a security control point to block or redirect answers for known malware sites.

What Has Changed?

For the past few years, the industry has been working on standardizing the privacy of DNS queries. This is a capability that OpenDNS has offered for quite some time through DNSCrypt. DNS over HTTP (DoH), which OpenDNS also supports, encrypts queries and responses over a RESTful interface and transmits them over HTTP. This is a strong technological advancement. However, the DoH standard does not define how an application should choose the resolver. Until recently, there were two ways to discover a DoH server: attempt to access DoH on the resolver handed to the application by the operating system or use one provided by the application provider.

The first method involves a bit of a guessing game. When applications try to use DoH on existing resolvers, they attempt an HTTP request over port 443 to the resolver that they learn from the operating system. The request is tested to see if a valid response is received. This requires that the DoH capability be directly bound to the existing hosts that offer DNS over UDP port 53. While this might be a reasonable first attempt to bootstrap DoH, in the longer term these services may have different scaling qualities. In addition, if the version of HTTP changes, applications would have to determine this by trying one HTTP version and then another. Also, in general, it is not good to send requests that the other side might not expect to receive.

Figure 2: Normal DNS versus Application-Controlled DNS

When non-cooperating applications or platforms choose their own resolvers, they bypass the DNS-based malware protections available to the IT administrator (illustrated in Figure 2). This circumvents the will of the user or administrator. If your resolvers are not seeing DNS queries from browsers, this may be what is happening. Moreover, if browser developers were to use a small number of DNS resolver services, one could reasonably expect the existing resolver infrastructure capacity to diminish over time due to lack of demand. This is where we begin to become concerned about overall system resilience. Many of these services on their own are highly resilient. But when they fail, they risk taking out a very large number of services for large portions of the population—at the same time. Because DNS is a fundamental service used by every application, we must pay close attention to this risk.

One key form of protection from these sorts of failures is choice. When enterprises and individuals have the choice of product, the risk of large-scale failures due to a monoculture is considerably diminished.

Enter Discovery of Designated Resolvers

The new proposal, known as Discovery of Designated Resolvers (DDR), provides a new way for clients to query locally designated resolvers for a record that indicates whether the DoH service is available. Either an application or the underlying platform can make use of DDR to locate a DoH resolver by first querying for a list of resolvers using a new DNS record called Service Binding (SVCB). SVCB works similarly to the highly tested, well-known service (SRV) record, but also allows for additional application parameters, such as Application-Layer Protocol Negotiation (ALPN) information for transport layer security (TLS). The current proposal offers several different approaches for clients to authenticate resolvers. One requires that a certificate contain an IP address. Another approach omits that requirement but requires that the IP address of the DDR-discovered resolver have the same IP address as the unauthenticated resolver. A third approach bases the resolver discovery on a name rather than an IP address. We expect these models to develop further as the DDR proposal matures.

Figure 3: Discovering DNS over HTTP with DDR

DDR resolves both visibility and scalability concerns, avoiding guesswork by developers. The infrastructure can be exercised so that a large and thriving resolver ecosystem can continue to flourish, with queries and responses encrypted, and reduce the risk of concentration of resolver services. DDR also has the potential to reduce individual device configuration complexity that is handled today by mobile device managers. What is needed are a few new records in resolvers and appropriate certificates on the resolvers.

There are several issues that DDR needs to resolve, such as how to address scaling of large numbers of resolvers, and it sometimes requires validation of IP addresses in certificates. That is a mechanism with which we currently have limited experience at scale. It also often relies on unauthenticated processes to discover the IP addresses of the resolvers that need to be in those certificates. Also, how to securely identify resolvers in devices outside an enterprise environment needs a bit more consideration.

Moving Forward and What Cisco Customers Should Do Now

As currently envisioned, DDR is the best secure resolver discovery proposal to date, but we expect this entire solution space to continue to evolve. A list of DNS resolvers is just one critical element of network configuration that needs to be securely learned. There are many others. The key is to establish trust between the end device and the network infrastructure and then rely on that trust to receive configuration information.

How do we bootstrap that trust? That is another area that the industry needs to devote more time and resources to establish.

For our enterprise, industrial, and small business customers, Cisco’s recommendation is that administrators deploy a secure and reliable resolver service that provides a layered defense against exfiltration and BOTnets—for all devices at all times whether at home, work, or elsewhere. Combined with DNSCrypt or DoH, Cisco Umbrella offers a needed level of protection for safety, security, scalability, and stability.

Because the stability and security of the Internet is an important topic, you may also wish to participate in this discussion hosted by the IETF. DDR will be discussed over the coming months and then submitted for approval. Participation in IETF activities is open to all and there is no cost to join the mailing list discussions.

Source: cisco.com

Continue reading