Bridging the IT Skills Gap Through SASE: A Path to Radical Simplification and Transformation

Imagine a world where IT isn’t a labyrinth of complexity but instead a streamlined highway to innovation. That world isn’t a pipe dream—it’s a SASE-enabled reality.

As we navigate the complexities of a constantly evolving digital world, a telling remark from a customer onstage with me at Cisco Live in June lingers: “We don’t have time to manage management tools.” This sentiment is universal, cutting across sectors and organizations. An overwhelming 82% of U.S. businesses, according to a Deloitte survey, were prevented from pursuing digital transformation projects because of a lack of IT resources and skills. Without the right experts to get the job done, teams are often entangled in complex, disparate systems and tools that require specific skills to operate.

The IT talent crunch

Today’s tech landscape presents a challenge that IT leaders can’t ignore: complex IT needs combined with a fiercely competitive talent market. Internally, teams are overwhelmed, often struggling to keep up with ever-evolving technical demands. In fact, many teams are strapped and rely on early-in-career staff to fill wide gaps left behind by more experienced predecessors. And the problem is only going to get worse.

For experienced IT workers, it’s an attractive time to entertain new opportunities. According to a global Deloitte study, 72% of U.S. tech employees are considering leaving their jobs for better roles. Interestingly, a mere 13% of employers said they were able to hire and retain the tech talent they most needed.

Now more than ever, organizations must rethink their approach to talent management and technology adoption to stay ahead of the curve.

Convergence as a catalyst for transformation

In an era where time is a premium and complexity is the norm, the need for convergence has never been more apparent. Technical skills, while essential, are not enough. The real game-changers are adaptability, cross-functional collaboration, and strategic foresight. And yet, these “soft skills” can’t be optimally used if teams are entangled in complex, disparate systems and tools that require specialized skills to manage and operate.

So how do organizations tackle this dilemma? How do they not just keep the lights on but also innovate, improve, and lead? In a word: convergence. Unifying siloed network and security teams as well as systems and tools with a simplified IT strategy is key to breaking through complexity.

A platform to radically simplify networking and security

Secure access service edge (SASE) is more than just an architecture; it’s a vision for the future where the worlds of networking and security are not siloed and become one. Cisco takes a unified approach to SASE, where industry-leading SD-WAN meets industry-leading cloud security capabilities in one, robust platform to make managing networking and security easy.

Figure 1. SASE architecture converging networking and security domains

Unified SASE converges the two domains into one, streamlining operations across premises and cloud. Admins from both domains gain end-to-end visibility into every connection, making it easier to optimize the application experience for users, providing seamless access to critical resources wherever work happens. This converged approach to secure connectivity through SASE delivers real outcomes that matter to resource-strapped organizations.

Simplify IT operations and increase productivity

◉ Administrators find it easier to manage networking and security when they are consolidated

◉ 73% reduction in application latency improves collaboration and enhances overall productivity

◉ 40% faster performance on Microsoft 365 improves employee experience

Do more with less

◉ 60% lower TCO for zero-trust security enables budget reallocation to strategic initiatives3

◉ 65% reduction in connectivity costs helps ease the burden on IT budgets3

Enhance security without adding complexity

◉ Simplify day-2 operations with centralized policy management, which makes it easier for IT teams to execute

◉ Improve security posture through consistent enforcement—from endpoints and on-premises infrastructure to cloud—across your organization

Scale and adapt

◉ Cloud-native architecture supports scaling and addresses the challenges of rapidly evolving IT landscapes

◉ Prepares your organization for changes, reducing the need for constant upskilling or reskilling in IT teams

Organizations can use SASE architecture to advance their technological frameworks and strategically address the IT skills gap, leading to long-term business success.

Shifting gears: Unifying, simplifying, innovating

SASE is not merely a technological evolution; it’s a paradigm shift in how we approach IT management. This lets IT admins focus less on tool management and more on driving business innovation, enriching user experiences, and evolving in tune with market demands.

Figure 2. Introducing unified SASE with Cisco+ Secure Connect, a better way to manage networking and security

The path ahead with unified SASE from Cisco

Cisco offers a unified, cloud-managed SASE solution, Cisco+ Secure Connect. From on-premises to cloud, this comprehensive SASE solution delivers simplicity and operational consistency, unlocking secure hybrid work for employees wherever they choose to work. The beauty of Cisco’s unified SASE solution lies in the principle of interconnecting everything with security everywhere–if it is connected, it is protected. It’s that easy.

Source: cisco.com

Continue reading

The myth of the long-tail vulnerability

Modern-day vulnerability management tends to follow a straightforward procedure. From a high level, this can be summed up in the following steps:

• Identify the vulnerabilities in your environment
• Prioritize which vulnerabilities to address
• Remediate the vulnerabilities

When high-profile vulnerabilities are disclosed, they tend to be prioritized due to concerns that your organization will be hammered with exploit attempts. The general impression is that this malicious activity is highest shortly after disclosure, then decreases as workarounds and patches are applied. The idea is that we eventually reach a critical mass, where enough systems are patched that the exploit is no longer worth attempting.

In this scenario, if we were to graph malicious activity and time, we end up with what is often referred to as a long-tail distribution. Most of the activity occurs early on, then drops off over time to form a long tail. This looks something like the following:

A long tail distribution of exploit attempts sounds reasonable in theory. The window of usefulness for an exploit is widest right after disclosure, then closes over time until bad actors move on to other, more recent vulnerabilities.

But is this how exploitation attempts really play out? Do attackers abandon exploits after a certain stage, moving on to newer and more fruitful vulnerabilities? And if not, how do attackers approach vulnerability exploitation?

Our approach

To answer these questions, we’ll look at Snort data from Cisco Secure Firewall. Many Snort rules protect against the exploitation of vulnerabilities, making this a good data set to examine as we attempt to answer these questions.

We’ll group Snort rules by the CVEs mentioned in the rule documentation, and then look at CVEs that see frequent exploit attempts. Since CVEs are disclosed on different dates, and we’re looking at alerts over time, the specific time frame will vary. In some cases, the disclosure date is earlier than the range our data set covers. While we won’t be able to examine the initial disclosure period for these, we’ll look at a few of these as well for signs of a long tail.

Finally, looking at a count of rule triggers can be misleading—a few organizations can see many alerts for one rule in a short time frame, making the numbers look larger than they are across all orgs. Instead, we’ll look at the percentage of organizations that saw an alert. We’ll then break this out on a month-to-month basis.

Log4J: The 800-pound gorilla

The Log4J vulnerability has dominated our vulnerability metrics since it was disclosed in December 2021. However, looking at the percentage of exploit attempts each month since, there was neither a spike in use right after disclosure, nor a long tail afterwards.

That first month, 27 percent of organizations saw alerts for Log4J. Since then, alerts have neither dropped off nor skyrocketed from one month to the next. The percent of organizations seeing alerts range from 25-34 percent through June 2023, averaging out at 28 percent per month.

Perhaps Log4J is an exception to the rule. It’s an extremely common software component and a very popular target. A better approach might be to look at a lesser-known vulnerability to see how the curve looks.

Spring4Shell: The Log4J that wasn’t

Spring4Shell was disclosed at the end of March 2022. This was a vulnerability in the Spring Java framework that managed to resurrect an older vulnerability in JDK9, which had initially been discovered and patched in 2010. At the time of Spring4Shell’s disclosure there was speculation that this could be the next Log4J, hence the similarity in naming. Such predictions failed to materialize.

We did see a decent amount of Spring4Shell activity immediately after the disclosure, where 23 percent of organizations saw alerts. After this honeymoon period, the percentage did decline. But instead of exhibiting the curve of a long tail, the percentages have remained between 14-19 percent a month.

Keen readers will notice the activity in the graph above that occurs prior to disclosure. These alerts are for rules covering the initial, more-than-a-decade-old Java vulnerability, CVE-2010-1622. This is interesting in two ways:

1. The fact that these rules were still triggering monthly on a 13-year-old vulnerability prior to Spring4Shell’s disclosure provides the first signs of a potential long tail.

2. It turns out that Spring4Shell was so similar to the previous vulnerability that the older Snort rules alerted on it.

Unfortunately, the time frame of our alert data isn’t long enough to say what the initial disclosure phase for CVE-2010-1622 looked like. So since we don’t have enough information here to draw a conclusion, what about other older vulnerabilities that we know were in heavy rotation?

ShellShock: A classic

It’s hard to believe, but the ShellShock vulnerability recently turned nine. By software development standards this qualifies it for senior citizen status, making it a perfect candidate to examine. While we don’t have the initial disclosure phase, activity remains high to this day.

Our data set begins approximately seven years after disclosure, but the percentage of organizations seeing alerts ranges from 12-23 percent. On average across this timeframe, about one in five organizations see ShellShock alerts in a month.

A pattern emerges

While we’ve showcased 3-4 examples here, a pattern does emerge when looking at other vulnerabilities, both old and new. For example, here is CVE-2022-26134, a vulnerability discovered in Atlassian Confluence in June 2022.

Here is ProxyShell, which was initially discovered in August 2021, followed by two more related vulnerabilities in September 2022.

And here is another older, commonly targeted vulnerability in PHPUnit, originally disclosed in June 2017.

Is the long tail wagging the dog?

What emerges from looking at vulnerability alerts over time is that, while there is sometimes an initial spike in usage, they don’t appear to decline to a negligible level. Instead, vulnerabilities stick around for years after their initial disclosure.

So why do old vulnerabilities remain in use? One reason is that many of these exploitation attempts are automated attacks. Bad actors routinely leverage scripts and applications that allow them to quickly run exploit code against a large swaths of IP addresses in the hopes of finding vulnerable machines.

This is further evidenced by looking at the concentration of alerts by organization. In many cases we see sudden spikes in the total number of alerts seen each month. If we break these months down by organization, we regularly see that alerts at one or two organizations are responsible for the spikes.

For example, take a look at the total number of Snort alerts for an arbitrary vulnerability. In this example, December was in line with the months that preceded it. Then in January, the total number of alerts began to grow, peaking in February, before declining back to average levels.

The cause of the sudden spike, highlighted in light blue, is one organization that was hammered by alerts for this vulnerability. The organization saw little-to-no alerts in December before a wave hit that lasted from January through March. It then completely disappeared by April.

This is a common phenomenon seen in overall counts (and why we don’t draw trends from this data alone). This could be the result of automated scans by bad actors. These attackers may have found one such vulnerable system at this organization, then proceeded to hammer it with exploit attempts in the months that followed.

So is the long tail a myth when it comes to vulnerabilities? It certainly appears so—at least when it comes to the types of attacks that target the perimeter of an organization. The public facing applications that reside here present a large attack surface. Public proof-of-concept exploits are often readily available and are relatively easy to fold into attacker’s existing automated exploitation frameworks. There’s little risk for an attacker involved in automated exploit attempts, leaving little incentive to remove exploits once they’ve been added to an attack toolkit.

What is left to explore is whether long-tail vulnerabilities exist in other attack surfaces. The fact is that there are different classes of vulnerabilities that can be leveraged in different ways. We’ll explore more of these facets in the future.

It only takes one

Finding that one vulnerable, public-facing system at an organization is a needle-in-a-haystack operation for attackers, requiring regular scanning to find it. But all it takes is one new system without the latest patches applied to give the attackers an opportunity to gain a foothold.

The silver lining here is that a firewall with an intrusion prevention system, like Cisco Secure Firewall, is designed specifically to prevent successful attacks.  Beyond IPS prevention of these attacks, the recently introduced Cisco Secure Firewall 4200 appliance and 7.4 OS bring enterprise-class performance and a host of new features including SD-WAN, ZTNA, and the ability to detect apps and threats in encrypted traffic without decryption.

Also, if you’re looking for a solution to assist you with vulnerability management, Cisco Vulnerability Management has you covered. Cisco Vulnerability Management equips you with the contextual insight and threat intelligence needed to intercept the next exploit and respond with precision.

Source: cisco.com

Continue reading

Cisco report reveals observability as the new strategic priority for IT leaders

Research from Cisco AppDynamics, The Age of Application Observability, tells us that teams have reached a tipping point as they look to tackle complexity and deal with fractured IT domains, tool sprawl, and ever-growing demands from customers and end users for flawless, performant, and secure digital experiences.

There is also an emerging consensus that observability is a mandatory component of the solution. The report reveals that 85% of IT leaders now see observability as a strategic priority. Observability allows teams to ask questions about the state of IT systems and to get insights into the applications and supporting systems that keep a business running, derived from the telemetry data they collectively produce.

As we look to a new era of insight, one in which teams are evolving from reactive to proactive by correlating that telemetry with business outcomes, Cisco Full-Stack Observability offers a transformative model. It helps teams identify the root cause of digital-experience disrupting scenarios even before they happen – with or without human intervention – and prioritize prescriptive actions in response.

The age of observability

Observability is the path to a more federated view among teams and processes. But do teams see it as worth the necessary investment in time and resources? The Cisco AppDynamics report tells us that they believe it is.

While almost half (44%) of report participants say new innovation initiatives are being delivered with cloud native technologies – and they expect this figure to climb to 58% over the next five years – the vast majority (83%) acknowledge that this is leading to increased complexity.

There is agreement among respondents that observability can help resolve this complexity. And there is almost universal consensus that the journey to observability is rooted in common challenges.

• According to the report, 92% agree that hybrid environments are here to stay.
• Nearly three-quarters (78%) say the volume of data makes manual
• Cloud cost is creeping with 81% indicating heightened scrutiny on cloud investments

The recognition of these and other matters outlined in the report has brought with it an important shift in perspective. Business leaders strongly support observability plans and recognize that the journey to observability is well underway.

This is confirmed by the report, with 89% saying their organization’s expectations around observability are increasing. Even for organizations that are early in the observability journey, steps are being taken toward accelerating full stack observability as a foundation for future success.

Invest in the right tools (not more tools)

Monitoring is not observability, yet 64% of those surveyed admit they find it difficult to differentiate between observability and monitoring solutions. They say it is common to adopt more monitoring tools as more hybrid infrastructure is brought online and in support of expanded services and reach.

Many IT departments are deploying separate tools, for example, to monitor on-premises and cloud native applications, which means they don’t have a clear view of the entire application path.

The solution is not another tool, adding additional latency, complexity, and cost. The way forward is to invest in an observability solution that has the power to help consolidate, simplify, transform, and automate.

Essentially, by bridging the gap between business and technology worlds, this changes the conversation.

According to the report, 88% of respondents say observability with business context will enable them to become more strategic and spend more time on innovation. They understand that it’s a revenue-generating, organization-optimizing investment.

Adjust processes accordingly

While success requires the right tools, it also requires a change to the processes that underpin them. How departments are structured, staffed, and resourced. How teams communicate, and when. The fact is that processes and behaviors have always lagged the pace of technology.

According to the report, 36% of respondents believe this is contributing to the loss of IT talent. Nearly half say this trend will continue if leaders don’t find new ways to break down silos between IT and business domains.

Eight out of ten surveyed point to an increase in silos due to managing multi-cloud and hybrid environments, and less than one-third (31%) report ongoing collaboration between their IT operations and security teams. The majority agree that the biggest barrier to collaboration between IT teams is the use of technology and tools which reinforce these silos.

Cisco Full-Stack Observability provides a foundation for digital transformation – which respondents agree will continue to accelerate as the driving force behind every enterprise – in part by streamlining IT operations so teams can collaborate to optimize digital experiences.

The new strategic priority

Observability is now understood as a new way to foster cross-domain collaboration, supporting new ways of working together, and incentivizing better business outcomes. This means, for example, that teams can align digital experiences with profit, compliance, growth, and delivery time.

The Cisco report brings into focus the fast pace of hybrid adoption in the enterprise, and the technical challenges that follow. This is where Cisco Observability Platform really shines. It brings together the rich telemetry data generated by normal business operations, offering solutions that make it understandable and correlating it with business objectives in a usable way.

Teams are acutely aware that the road to digital transformation is paved with new challenges, but they also recognize that managing and mitigating these issues means getting on that path sooner. Cisco Full-Stack Observability is the answer.

Source: cisco.com

Continue reading

How to Begin Observability at the Data Source

More data does not mean better observability

If you’re familiar with observability, you know most teams have a “data problem.” That is, observability data has exploded as teams have modernized their application stacks and embraced microservices architectures.

If you had unlimited storage, it’d be feasible to ingest all your metrics, events, logs, and traces (MELT data) in a centralized observability platform. However, that is simply not the case. Instead, teams index large volumes of data – some portions being regularly used and others not. Then, teams have to decide whether datasets are worth keeping or should be discarded altogether.

For the past few months I’ve been playing with a tool called Edge Delta to see how it might help IT and DevOps teams to solve this problem by providing a new way to collect, transform, and route your data before it is indexed in a downstream platform, like AppDynamics or Cisco Full-Stack Observability.

What is Edge Delta?

You can use Edge Delta to create observability pipelines or analyze your data from their backend. Typically, observability starts by shipping all your raw data to central service before you begin analysis. In essence, Edge Delta helps you flip this model on its head. Said another way, Edge Delta analyzes your data as it’s created at the source. From there, you can create observability pipelines that route processed data and lightweight analytics to your observability platform.

Why might this approach be advantageous? Today, teams don’t have a ton of clarity into their data before it’s ingested in an observability platform. Nor do they have control over how that data is treated or flexibility over where the data lives.

By pushing data processing upstream, Edge Delta enables a new kind of architecture where teams can have…

◉ Transparency into their data: “How valuable is this dataset, and how do we use it?”

◉ Controls to drive usability: “What is the ideal shape of that data?”

◉ Flexibility to route processed data anywhere: “Do we need this data in our observability platform for real-time analysis, or archive storage for compliance?”

The net benefit here is that you’re allocating your resources towards the right data in its optimal shape and location based on your use case.

How I used Edge Delta

Over the past few weeks, I’ve explored a couple different use cases with Edge Delta.

Analyzing NGINX log data from the Edge Delta interface

First, I wanted to use the Edge Delta console to analyze my log data. To do so, deployed the Edge Delta agent on a Kubernetes cluster running NGINX. From here, I sent both valid and invalid http requests to generate log data and observed the output via Edge Delta’s pre-built dashboards.

Among the most useful screens was “Patterns.” This feature clusters together repetitive loglines, so I can easily interpret each unique log message, understand how frequently it occurs, and whether I should investigate it further.

Edge Delta’s Patterns feature makes it easy to interpret data by clustering together repetitive log messages and provides analytics around each event.

Creating pipelines with Syslog data

Second, I wanted to manipulate data in flight using Edge Delta observability pipelines. Here, I installed the Edge Delta agent on my Mac OS. Then I exported Syslog data from my Cisco ISR1100 to my Mac.

From within the Edge Delta interface, I configured the agent to listen on the appropriate TCP and UDP ports. Now, I can apply processor nodes to transform (and otherwise manipulate) my data before it hits my downstream analytics platform.

Specifically, I applied the following processors:

◉ Mask node to obfuscate sensitive data. Here, I replaced social security numbers in my log data with the string ‘REDACTED’.

◉ Regex filter node which passes along or discards data based on the regex pattern. For this example, I wanted to exclude DEBUG level logs from downstream storage.

◉ Log to metric node for extracting metrics from my log data. The metrics can be ingested downstream in lieu of raw data to support real-time monitoring use cases. I captured metrics to track the rate of errors, exceptions, and negative sentiment logs.

◉ Log to pattern node which I alluded to in the section above. This creates “patterns” from my data by grouping together similar loglines for easier interpretation and less noise.

Through Edge Delta’s Pipelines interface, you can apply processors to your data and route it to different destinations.

For now all of this is being routed to the Edge Delta backend. However, Edge Delta is vendor-agnostic and I can route processed data to different destinations – like AppDynamics or Cisco Full-Stack Observability – in a matter of clicks.

Source: cisco.com

Continue reading

SD WAN solutions for utility Distribution Automation

Networks are expanding outside traditional office buildings and into industrial fixed and mobile use cases. This results in more devices being connected to the Internet and data centers as well as increased security exposure. IoT has moved traditional networking far beyond the carpeted spaces and into industries like Fleets, Oil & Gas, Energy & Water Utilities, Remote Condition Monitoring and Control — basically anything that can establish a wide area connection. Moreover, these industrial networks are increasingly being considered critical infrastructure. In response to this expansion, Cisco has on-going innovations advancing the ways networks operate – and at the forefront of these trends is the way that SD WAN solutions enable and support industrial use cases.

Cisco Catalyst SD-WAN today is already an industry-leading wide area network solution offering a software-defined WAN solution that enables enterprises and organizations to connect users to their applications securely. It provides a software overlay that runs over standard network transports, including MPLS, broadband, and Internet, to deliver applications and services. The overlay network supports on-premises solutions but also extends the organization’s network to Infrastructure as a Service (IaaS) and multi-cloud environments, thereby accelerating their shift to the cloud.

Most utilities are used to building large networks utilizing technologies such as Internet Protocol Security (IPsec) and Dynamic Multipoint Virtual Private Network (DMVPN) to encrypt critical communications, Multiprotocol Label Switching (MPLS) for the underlying transport network, and public or private cellular for remote sites with no other WAN connectivity. Catalyst SD-WAN brings these technologies together and enables automation to greatly simplify deployments.

Automation benefits:

• Secure Zero Touch deployment of field gateways (i.e., no field staff required to configure a gateway)
• Simple provisioning of end-to-end service VPNs to segment traffic (SCADA, CCTV, PMU, IP Telephony, etc.)
• Templated configurations making it easy to change configurations at scale and push it to gateways in the field.
• Application of unified security policies across a diverse range of remote sites and equipment
• Managing multiple backhaul connectivity options at the gateway including private MPLS for critical SCADA traffic and cellular for backup and even internet-based connections for non-critical traffic, where appropriate
• Lifecycle management of gateways (e.g., firmware updates, alarm monitoring and statistics)

Cisco SD-WAN Validated Design for Distribution Automation (DA)

SD-WAN has origins as an enterprise solution using fixed edge routers of various performance capabilities and predictable enterprise traffic patterns. Utility networks present new challenges with especially when applied to Distribution network use cases:

• Connectivity to legacy serial devices not supporting Ethernet/IP
• communications (g., Modbus RTU, DNP3 over serial, IEC101 or vendor proprietary)
• Mobility needs for mobile assets to ensure resilient wide area connectivity
• New WAN interfaces including dual 4G or 5G cellular, DSL, fiber or Ethernet
• The use of NAT to allow fixed privately addressed equipment to communicate
• Requirement to encrypt SCADA traffic across the wide area network
• Applicable to both distribution substations and field area networks
• Segregation of services via VPNs in flexible topologies (Hub & Spoke, or Meshed [Fully or Partial])
• Intelligent traffic steering across multiple backhaul interfaces when needed (critical vs. non-critical traffic)

Key use Distribution Network use cases that the Cisco SD-WAN solution can address are:

Cisco IoT Solutions have introduced a new Cisco Validated Design to address an SD-WAN architecture for Distribution Automation use cases. Leveraging the Cisco Catalyst IR1100 Rugged Series Routers as an SD-WAN router with flexible modular backhaul capabilities (DSL, Fiber, Ethernet, 4/5G, 450MHz LTE) and operating as an SD-WAN controlled edge router.

Along the distribution network feeders, the IR1101 should be positioned as a Distribution Automation gateway. It can be easily mounted within a DA device cabinet (e.g. Recloser, Cap bank controller etc) and can be powered by the same DC supply (flexible 9-36VDC input). It also has extended environmental capabilities to cope with the variations in temperature, humidity, and vibration.

The new SD-WAN for Utility Distributed Automation Design Guide builds on other existing documents that describe in detail Cisco’s SD-WAN architecture and industrial IoT hardware offerings and shows how they can be combined to provide a scalable, secure network. The new Design Guide is focused on areas that are unique or at least emphasized by DA use cases in general. This document also has detailed configuration examples for many of the DA features.

Source: cisco.com

Continue reading

Driving API Security Forward: Protecting Vehicle-to-Cloud Communications

In the rapidly evolving automotive landscape, vehicles are no longer just machines that move us from point A to point B; they have transformed into complex, interconnected systems on wheels. With this transformation, API (Application Programming Interface) security has surged to the forefront of automotive design and engineering. APIs serve as critical gatekeepers, managing the flow of data between the vehicle’s Electronic Control Units (ECUs), external devices, and the cloud. But with great power comes great responsibility. If an API is compromised, the implications can range from privacy breaches to threats to passenger safety. Automotive API security, therefore, is not just a technological challenge, it’s a safety imperative. It’s a thrilling yet daunting frontier, where the lines between software engineering, cybersecurity, and automotive design blur, and where the stakes are high— ensuring the safe and secure transportation of millions, if not billions, of people around the world.

In parallel, the Internet of Vehicles (IoV) and Vehicle-to-Everything (V2X) continue to evolve. The IoV encompasses a range of technologies and applications, including connected cars with internet access, Vehicle-to-Vehicle (V2V) and Vehicle-to-Cloud (V2C) communication, autonomous vehicles, and advanced traffic management systems. The timeline for widespread adoption of these technologies is presently unclear and will depend on a variety of factors; however, adoption will likely be a gradual process.

Over time, the number of Electronic Control Units (ECUs) in vehicles has seen a significant increase, transforming modern vehicles into complex networks on wheels. This surge is attributed to advancements in vehicle technology and the increasing demand for innovative features. Today, luxury passenger vehicles may contain 100 or more ECUs. Another growing trend is the virtualization of ECUs, where a single physical ECU can run multiple virtual ECUs, each with its own operating system. This development is driven by the need for cost efficiency, consolidation, and the desire to isolate systems for safety and security purposes. For instance, a single ECU could host both an infotainment system running QNX and a telematics unit running on Linux.

ECUs run a variety of operating systems depending on the complexity of the tasks they perform. For tasks requiring real-time processing, such as engine control or ABS (anti-lock braking system) control, Real-Time Operating Systems (RTOS) built on AUTOSAR (Automotive Open System Architecture) standards are popular. These systems can handle strict timing constraints and guarantee the execution of tasks within a specific time frame. On the other hand, for infotainment systems and more complex systems requiring advanced user interfaces and connectivity, Linux-based operating systems like Automotive Grade Linux (AGL) or Android Automotive are common due to their flexibility, rich feature sets, and robust developer ecosystems. QNX, a commercial Unix-like real-time operating system, is also widely used in the automotive industry, notably for digital instrument clusters and infotainment systems due to its stability, reliability, and strong support for graphical interfaces.

The unique context of ECUs present several distinct challenges regarding API security. Unlike traditional IT systems, many ECUs have to function in a highly constrained environment with limited computational resources and power, and often have to adhere to strict real-time requirements. This can make it difficult to implement robust security mechanisms, such as strong encryption or complex authentication protocols, which are computationally intensive. Furthermore, ECUs need to communicate with each other and external devices or services securely. This often leads to compromises in vehicle network architecture where a highcomplexity ECU acts as an Internet gateway that provides desirable properties such as communications security. On the other hand, in-vehicle components situated behind the gateway may communicate using methods that lack privacy, authentication, or integrity.

Modern Vehicle Architecture

ECUs, or Electronic Control Units, are embedded systems in automotive electronics that control one or more of the electrical systems or subsystems in a vehicle. These can include systems related to engine control, transmission control, braking, power steering, and others. ECUs are responsible for receiving data from various sensors, processing this data, and triggering the appropriate response, such as adjusting engine timing or deploying airbags.

DCUs, or Domain Control Units, are a relatively new development in automotive electronics, driven by the increasing complexity and interconnectivity of modern vehicles. A DCU controls a domain, which is a group of functions in a vehicle, such as the drivetrain, body electronics, or infotainment system. A DCU integrates several functions that were previously managed by individual ECUs. A DCU collects, processes, and disseminates data within its domain, serving as a central hub.

The shift towards DCUs can reduce the number of separate ECUs required, simplifying vehicle architecture and improving efficiency. However, it also necessitates more powerful and sophisticated hardware and software, as the DCU needs to manage multiple complex functions concurrently. This centralization can also increase the potential impact of any failures or security breaches, underscoring the importance of robust design, testing, and security measures.

Direct internet connectivity is usually restricted to only one or two Electronic Control Units (ECUs). These ECUs are typically part of the infotainment system or the telematics control unit, which require internet access to function. The internet connection is shared among these systems and possibly extended to other ECUs. The remaining ECUs typically communicate via an internal network like the CAN (Controller Area Network) bus or automotive ethernet, without requiring direct internet access.

The increasing complexity of vehicle systems, the growing number of ECUs, and pressure to bring cutting edge consumer features to market have led to an explosion in the number of APIs that need to be secured. This complexity is compounded by the long lifecycle of vehicles, requiring security to be maintained and updated over a decade or more, often without the regular connectivity that traditional IT systems enjoy. Finally, the critical safety implications of many ECU functions mean that API security issues can have direct and severe consequences for vehicle operation and passenger safety.

ECUs interact with cloud-hosted APIs to enable a variety of functionalities, such as real-time traffic updates, streaming entertainment, finding suitable charging stations and service centers, over-the-air software updates, remote diagnostics, telematics, usage based insurance, and infotainment services.

Open Season

In the fall of 2022, security researchers discovered and disclosed vulnerabilities affecting the APIs of a number of leading car manufacturers. The researchers were able to remotely access and control vehicle functions, including locking and unlocking, starting and stopping the engine, honking the horn and flashing the headlights. They were also able to locate vehicles using just the vehicle identification number or an email address. Other vulnerabilities included being able to access internal applications and execute code, as well as perform account takeovers and access sensitive customer data.

The research is historically significant because security researches would traditionally avoid targeting production infrastructure without authorization (e.g., as part of a bug bounty program). Most researchers would also hesitate to make sweeping disclosures that do not pull punches, albeit responsibly. It seems the researchers were emboldened by recent revisions to the CFAA and this activity may represent a new era of Open Season Bug Hunting.

The revised CFAA, announced in May of 2022, directs that good-faith security research should not be prosecuted. Further, “Computer security research is a key driver of improved cybersecurity,” and “The department has never been interested in prosecuting good-faith computer security research as a crime, and today’s announcement promotes cybersecurity by providing clarity for good-faith security researchers who root out vulnerabilities for the common good.”

These vulnerability classes would not surprise your typical cybersecurity professional, they are fairly pedestrian. Anyone familiar with the OWASP API Security Project will recognize the core issues at play. What may be surprising is how prevalent they are across different automotive organizations. It can be tempting to chalk this up to a lack of awareness or poor development practices, but the root causes are likely much more nuanced and not at all obvious.

Root Causes

Despite the considerable experience and skills possessed by Automotive OEMs, basic API security mistakes can still occur. This might seem counterintuitive given the advanced technical aptitude of their developers and their awareness of the associated risks. However, it’s essential to understand that, in complex and rapidly evolving technological environments, errors can easily creep in. In the whirlwind of innovation, deadlines, and productivity pressures, even seasoned developers might overlook some aspects of API security. Such issues can be compounded by factors like communication gaps, unclear responsibilities, or simply human error.

Development at scale can significantly amplify the risks associated with API security. As organizations grow, different teams and individuals often work concurrently on various aspects of an application, which can lead to a lack of uniformity in implementing security standards. Miscommunication or confusion about roles and responsibilities can result in security loopholes. For instance, one team may assume that another is responsible for implementing authentication or input validation, leading to vulnerabilities. Additionally, the context of service exposure, whether on the public internet or within a Virtual Private Cloud (VPC), necessitates different security controls and considerations. Yet, these nuances can be overlooked in large-scale operations. Moreover, the modern shift towards microservices architecture can also introduce API security issues. While microservices provide flexibility and scalability, they also increase the number of inter-service communication points. If these communication points, or APIs, are not adequately secured, the system’s trust boundaries can be breached, leading to unauthorized access or data breaches.

Automotive supply chains are incredibly complex. This is a result of the intricate network of suppliers involved in providing components and supporting infrastructure to OEMs. OEMs typically rely on tier-1 suppliers, who directly provide major components or systems, such as engines, transmissions, or electronics. However, tier-1 suppliers themselves depend on tier-2 suppliers for a wide range of smaller components and subsystems. This multi-tiered structure is necessary to meet the diverse requirements of modern vehicles. Each tier-1 supplier may have numerous tier-2 suppliers, leading to a vast and interconnected web of suppliers. This complexity can make it difficult to manage the cybersecurity requirements of APIs.

While leading vehicle cybersecurity standards like ISO/SAE 21434, UN ECE R155 and R156 cover a wide range of aspects related to securing vehicles, they do not specifically provide comprehensive guidance on securing vehicle APIs. These standards primarily focus on broader cybersecurity principles, risk management, secure development practices, and vehicle-level security measures. The absence of specific guidance on securing vehicle APIs can potentially lead to the introduction of vulnerabilities in vehicle APIs, as the focus may primarily be on broader vehicle security aspects rather than the specific challenges associated with API integration and communication.

Things to Avoid

Darren Shelcusky of Ford Motor Company explains that while many approaches to API security exist, not all prove to be effective within the context of a large multinational manufacturing company. For instance, playing cybersecurity “whack-a-mole,” where individual security threats are addressed as they pop up, is far from optimal. It can lead to inconsistent security posture and might miss systemic issues. Similarly, the “monitor everything” strategy can drown the security team in data, leading to signal-to-noise issues and an overwhelming number of false positives, making it challenging to identify genuine threats. Relying solely on policies and standards for API security, while important, is not sufficient unless these guidelines are seamlessly integrated into the development pipelines and workflows, ensuring their consistent application.

A strictly top-down approach, with stringent rules and fear of reprisal for non-compliance, may indeed ensure adherence to security protocols. However, this could alienate employees, stifle creativity, and lose valuable lessons learned from the ground-up. Additionally, over-reliance on governance for API security can prove to be inflexible and often incompatible with agile development methodologies, hindering rapid adaptation to evolving threats. Thus, an effective API security strategy requires a balanced, comprehensive, and integrated approach, combining the strengths of various methods and adapting them to the organization’s specific needs and context.

Winning Strategies

Cloud Gateways

Today, Cloud API Gateways play a vital role in securing APIs, acting as a protective barrier and control point for API-based communication. These gateways manage and control traffic between applications and their back-end services, performing functions such as request routing, composition, and protocol translation. From a security perspective, API Gateways often handle important tasks such as authentication and authorization, ensuring that only legitimate users or services can access the APIs. They can implement various authentication protocols like OAuth, OpenID Connect, or JWT (JSON Web Tokens). They can enforce rate limiting and throttling policies to protect against Denial-of-Service (DoS) attacks or excessive usage. API Gateways also typically provide basic communications security, ensuring the confidentiality and integrity of API calls. They can help detect and block malicious requests, such as SQL injection or Cross-Site Scripting (XSS) attacks. By centralizing these security mechanisms in the gateway, organizations can ensure a consistent security posture across all their APIs.

Cloud API gateways also assist organizations with API management, inventory, and documentation. These gateways provide a centralized platform for managing and securing APIs, allowing organizations to enforce authentication, authorization, rate limiting, and other security measures. They offer features for tracking and maintaining an inventory of all hosted APIs, providing a comprehensive view of the API landscape and facilitating better control over security measures, monitoring, and updates. Additionally, cloud API gateways often include built-in tools for generating and hosting API documentation, ensuring that developers and consumers have access to up-to-date and comprehensive information about API functionality, inputs, outputs, and security requirements. Some notable examples of cloud API gateways include Amazon API Gateway, Google Cloud Endpoints, and Azure API Management.

Authentication

In best-case scenarios, vehicles and cloud services mutually authenticate each other using robust methods that include some combination of digital certificates, token-based authentication, or challenge-response mechanisms. In the worst-case, they don’t perform any authentication at all. Unfortunately, in many cases, vehicle APIs rely on weak authentication mechanisms, such as a serial number being used to identify the vehicle.

Certificates

In certificate-based authentication, the vehicle presents a unique digital certificate issued by a trusted Certificate Authority (CA) to verify its identity to the cloud service. While certificate-based authentication provides robust security, it does come with a few drawbacks. Firstly, certificate management can be complex and cumbersome, especially in large-scale environments like fleets of vehicles, as it involves issuing, renewing, and revoking certificates, often for thousands of devices. Finally, setting up a secure and trusted Certificate Authority (CA) to issue and validate certificates requires significant effort and expertise, and any compromise of the CA can have serious security implications.

Tokens

In token-based authentication, the vehicle includes a token (such as a JWT or OAuth token) in its requests once its identity has been confirmed by the cloud service. Token-based authentication, while beneficial in many ways, also comes with certain disadvantages. First, tokens, if not properly secured, can be intercepted during transmission or stolen from insecure storage, leading to unauthorized access. Second, tokens often have a set expiration time for security purposes, which means systems need to handle token refreshes, adding extra complexity. Lastly, token validation requires a connection to the authentication server, which could potentially impact system performance or lead to access issues if the server is unavailable or experiencing high traffic.

mTLS

For further security, these methods can be used in conjunction with Mutual TLS (mTLS) where both the client (vehicle) and server (cloud) authenticate each other. These authentication mechanisms ensure secure, identity-verified communication between the vehicle and the cloud, a crucial aspect of modern connected vehicle technology.

Challenge / Response

Challenge-response authentication mechanisms are best implemented with the aid of a Hardware Security Module (HSM). This approach provides notable advantages including heightened security: the HSM provides a secure, tamper-resistant environment for storing the vehicle’s private keys, drastically reducing the risk of key exposure. In addition, the HSM can perform cryptographic operations internally, adding another layer of security by ensuring sensitive data is never exposed. Sadly, there are also potential downsides to this approach. HSMs can increase complexity throughout the vehicle lifecycle. Furthermore, HSMs also have to be properly managed and updated, requiring additional resources. Lastly, in a scenario where the HSM malfunctions or fails, the vehicle may be unable to authenticate, potentially leading to loss of access to essential services.

Hybrid Approaches

Hybrid approaches to authentication can also be effective in securing vehicle-to-cloud communications. For instance, a server could verify the authenticity of the client’s JSON Web Token (JWT), ensuring the identity and claims of the client. Simultaneously, the client can verify the server’s TLS certificate, providing assurance that it’s communicating with the genuine server and not a malicious entity. This multi-layered approach strengthens the security of the communication channel.

Another example hybrid approach could leverage an HSM-based challenge-response mechanism combined with JWTs. Initially, the vehicle uses its HSM to securely generate a response to a challenge from the cloud server, providing a high level of assurance for the initial authentication process. Once the vehicle is authenticated, the server issues a JWT, which the vehicle can use for subsequent authentication requests. This token-based approach is lightweight and scalable, making it efficient for ongoing communications. The combination of the high-security HSM challenge-response with the efficient JWT mechanism provides both strong security and operational efficiency.

JWTs (JSON Web Tokens) are highly convenient when considering ECUs coming off the manufacturing production line. They provide a scalable and efficient method of assigning unique, verifiable identities to each ECU. Given that JWTs are lightweight and easily generated, they are particularly suitable for mass production environments. Furthermore, JWTs can be issued with specific expiration times, allowing for better management and control of ECU access to various services during initial testing, shipping, or post-manufacturing stages. This means ECUs can be configured with secure access controls right from the moment they leave the production line, streamlining the process of integrating these units into vehicles while maintaining high security standards.

Source: cisco.com

Continue reading

Unlocking Success in the Digital Landscape: Deloitte and Cisco

For more than twenty years, Deloitte and Cisco have been dedicated to creating meaningful results for our mutual clients in the ever-evolving digital landscape. By combining Cisco’s market presence with Deloitte’s expertise, we deliver scalable, adaptable solutions tailored to support unique digital transformation objectives. Our work together merges Cisco’s leadership in IT infrastructure, security, and related sectors with Deloitte’s expertise in digital transformation, analytics, and cloud services.

Our clients access Deloitte’s customized solutions across its consulting, advisory, and tax divisions, leveraging profound industry insights to achieve their business goals. We identify the optimal blend of products and services that integrate seamlessly with their environments, driving digital transformation in areas such as full-stack observability (FSO), connected factories, the future of work, sustainability, and security.

Improving application performance with Full-Stack Observability (FSO)

Deloitte and Cisco collaborate to offer FSO to SAP and AWS clients. By integrating Cisco AppDynamics (AppD) with other monitoring tools, we enhance application performance and drive better business outcomes. AppD addresses SAP visibility and performance concerns at the advanced business application programming (ABAP) code level to provide essential visibility data.

Our efforts offer several benefits to our clients, including:

• Real-time discovery and visualization of all SAP components and their dependencies, helping to ensure a comprehensive view during SAP cloud migrations
• Reduction of inter-team conflicts by providing a unified source of truth for application performance that bridges the gap between development, operations, and SAP Basis teams
• Code-level visibility into SAP ABAP and connected non-SAP applications, expediting root cause analysis and performance issue identification
• Establishing baseline health and performance metrics for applications before cloud migration, simplifying issue detection at every migration stage and validating success by comparing pre- and post-migration metrics

Enabling Industrial Smart Operations

In the age of Industry 4.0, leading organizations are transitioning from traditional to digital supply network operations. Traditional linear supply chains lack agility and efficiency, inhibiting broader revenue streams and profit growth. The Digital Supply Network is a dynamic system that incorporates ecosystem partners and leverages digital technologies such as predictive algorithms and real-time IoT sensor data.

Cisco supports secure data collection with sensors, multiaccess wireless, and a cybersecurity platform. Deloitte provides industry expertise and helps transform supply chains through strategy, implementation, cloud operations, and AI solutions.

The outcome? Industrial Smart Operations, delivered by Deloitte and Cisco.

Driving a sustainable future of work

Deloitte and Cisco collaborate to create the contemporary employee experience while reducing the global carbon footprint of offices and factories.

This transformation is influenced by four important trends:

• Expansion of a remote hybrid workforce
• Reevaluation of real estate requirements and evolving workplace dynamics
• Increasing integration of artificial intelligence and telemetry in workplaces
• Organizational imperative to embrace a broad range of energy efficiency measures in support of net-zero carbon emissions objectives

Fueled by rapid connectivity, innovative talent models, and cognitive technologies, Deloitte and Cisco are actively shaping the modern employee experience while simultaneously driving environmental sustainability in offices and factories worldwide.

Enhancing security postures

Together, we help our mutual clients confidently transform their cyber and strategic risk mitigation programs and reduce overall risk exposure. Deloitte also works with Cisco to integrate the Cisco Security Portfolio into the Deloitte Zero Trust PRISM Financial Risk asset. This zero-trust cybersecurity posture makes it possible to create more robust and resilient security, simplify security management, improve the end-user experience, and allow customers to incorporate cyber risk elements into their overall risk exposure.

Making an impact that matters

Cisco’s cutting-edge cybersecurity technology, industrial IoT, network transformation, collaboration and observability solutions, and SD-WAN, combined with Deloitte’s distinguished professional services, provide significant value to customers around the world.

Source: cisco.com

Continue reading