A SAFE Journey to Selling Devices to Cloud and Datacenter Providers

Observations from the OCP Global Summit | San Jose, CA | October, 18, 2023

If you missed it, there was a significant launch of the Open Compute Project (OCP) Foundation’s new community-led security program for improving device security underpins a fundamental change in the way device vendors and manufacturers engage and sell their products to the worlds leading cloud and datacenter providers.

Beyond standing up a framework for driving continuous security conformance assurance, the Security Appraisal Framework and Enablement (S.A.F.E.) program redefines(and optimizes) the relationship between the device vendor, the device adopter, and the security review provider.

Back when I served as chief security officer for Microsoft’s Cloud and AI Security group, I encountered a scaling problem with the way Azure worked with device vendors (think in terms of CPU’s, GPU’s, SSD’s, network cards, etc.) in validating the integrity and security of their devices. The short story is that before any device or it’s firmware could be deployed within a datacenter a security assessment had to be undertaken – and only devices (and their firmware) that came back with “clean” security reports could be purchased and ultimately deployed. Through a combination of Microsoft’s in-house and trusted third-party penetration testing and code review teams, each key device would be tested and an iterative improvement cycle would continue until the security assurance report came back clean.

There were two obvious problems with that mode of security assurance and interaction. As a purchaser and adopter of devices, how do you scale an in-house security practices to assess and assure the thousands of devices from hundreds of vendors and their ever-changing firmware? And, as a device vendor, how do you meet and coordinate the overlapping yet distinct security requirements of every purchaser and adopter of your technology?

Which brings me back to S.A.F.E. While it has been a couple years since I moved on from Microsoft, it’s fantastic to see that those first meetings with the OCP team and like-minded cloud service providers to tackle those problems that culminated this week in the official launch of the solution – and doubly proud of IOActive’s key involvements in both the creation of the S.A.F.E. device security checklist and Security Review Provider (SRP) criteria, and for being one of the founding SRP providers.

For device vendors, I think S.A.F.E. is great news.

A few points to justify that statement:

1. Just one set of device security requirements (complete with device checklists) that address all OCP member purchasers and adopters. Better yet, community-driven and publicly available security requirements (with input from purchasers, vendors, and SRP providers alike) that will evolve and adapt to the changing world
2. Accredited and trusted OCP SRP providers that device vendors can engage with at anytime in their device and firmware’s development lifecycle – cost-effectively accelerating and simplifying a vendors journey to “clean” S.A.F.E.-Approved product status; ultimately ensuring a vendor’s devices can be purchased and deployed by cloud and datacenter providers quicker than ever before
3. Devices with advanced and proprietary technologies can be security tested and assured to meet adopter security requirements without the vendor having to share proprietary source code with the adopter.

One last perspective to share – oriented specifically to device vendors: there’s fantastic innovation going on across the cloud and datacenter device ecosystem. As I navigate the OCP conference Expo hall, passing by liquid cooling-systems, quantum computing data connectors, petabyte storage arrays, and even specialized forklifts for moving data racks- I’m reminded that many vendors are only just now starting their security journey, and the prospect of having to meet the detailed requirements of S.A.F.E. may feel daunting.

In all my time at Microsoft (and IBM for that matter), I never encountered a device vendor that “nailed security” the first time, nor the third time. Reaching S.A.F.E. approval will be a journey that requires a trusted security partner. When you’re ready for that journey, you’ll not find a stronger and more accomplished or experienced partner than the team at IOActive.

-- Gunter Ollmann

First Published: IOActive Blog - October 19 2023

Why Cybersecurity is Critical in MLOps

Larger and more sophisticated businesses will lean into building out their in-house data science teams and capabilities

If your business relies on machine learning (ML) to drive strategic decision-making, you’re in good company. A recent report by ClearML shows the technology clearly entering the mainstream, with 60% of organizations’ ML leaders planning to increase ML investments by more than a quarter in 2023. The same study revealed that 99% of respondents either already have dedicated budgets for ML operations (MLOps) or plan to implement them this year.

But, as MLOps mature, they also carry more risk. According to a recent study by NCC Group, organizations are deploying ML models in more applications without considering security requirements. In a separate survey by Deloitte, nearly two-thirds of AI and ML users describe cybersecurity risks as a significant or extreme threat, but only 39% feel prepared to combat those risks.

MLOps model creation pipelines are vulnerable and easily attacked in three separate ways: by malicious insiders, through software supply chain manipulation, and via compromised systems. If the SolarWinds supply chain attack taught the industry anything, it’s that continuous build processes are both a target for sophisticated adversaries and a blind spot for in-house security operations teams.

In 2023, continuous build processes will continue to be a target for threat actors. As these attacks start to impact enterprises’ bottom lines, they will have to start paying more attention to the cybersecurity side of MLOps.

Here are some ways to make MLOps projects safer and more secure.

Secure the Whole Pipeline

Part of the challenge of securing MLOps is the sheer length and depth of typical machine learning pipelines. They include a half dozen or more phases – data collection and preparation, along with the creation, evaluation, optimization, deployment and usage of an ML model. Vulnerabilities can crop up at any point in the process.

Early on, in data collection, threat actors can taint the data, manipulate the annotation or conduct adversarial attacks on the metadata stores. In later phases, open-source models and frameworks can include hidden vulnerabilities. Potential bias and system performance need to be addressed. And as models are deployed and used, new data is often introduced, expanding the attack surface and opening an organization up to all kinds of threats – including evasion attacks, model theft, code injections and privacy attacks.

At the tail end of the process, there’s a lot of intellectual property inside an ML model. Decades of transactional data and learnings from financial models that are built and trained into models may only be 10s of kilobytes in size. It’s easier to steal that model than to steal the actual source data.

These models tend to be exposed. Attackers have become skillful at querying models and reproducing them somewhere else. This requires a new way of thinking about the value of the model. Tooling and alerting not only around the theft of data but around the manipulation of the models is important to an overall MLOps security strategy.

Invest in Tooling to Scale Across SOCs

It’s no secret that security is no longer siloed in a single department. It cuts across all functions, and organizations are creating Security Operations Centers (SOCs) to improve the visibility, manageability and auditing of their overall security posture. To extend the SOC’s capability to MLOps, organizations need to incorporate tooling that scales to much larger uses than ever before.

Meeting MLOps’ data needs forces SOCs to adapt in two ways. Existing SOC operations teams are now accountable, forcing them to build the additional tooling and reporting to support MLOps teams from a security perspective. Plus, MLOps teams that are specialized in data science curation are able to leverage larger toolsets – including logging analytics platforms that provide higher levels of threat detection.

Double Down on Security Best Practices

Some of the best defense tactics for MLOps are practices organizations deploy regularly across the rest of their operations. A zero trust security policy requires the authentication and authorization of anybody trying to access applications or data used in the development of ML models. It also tracks their activity. Applying the principle of least privilege (PLoP) limits users’ access to the exact data sets and models they are authorized to touch. This reduces the attack surface by prohibiting hackers who have gained access to one data trove from moving freely throughout the system.

Use Analytics to Observe and Log ML Tasks

An important step in protecting an ML system is to understand the system’s behavior in healthy and unhealthy states. To do this, organizations need to set up alerts that trigger action before an incident occurs. This is called “observability.” A vulnerability introduced early in the training data will affect the model’s performance down the line. Tracking performance data and logging metrics of ML tasks gives organizations insights into any and all security issues that could affect the ML model.

Future Monitoring of Model Development Lifecycle

The continuous lifecycle of MLOps necessitates the continuous monitoring of a deployed model’s response to adversarial manipulation and corruption. In the future, expect to see larger and more sophisticated businesses lean into building out their in-house data science teams and capabilities, detecting threats with security analytics, and pruning and filtering data from unknowns to improve the advancements in the next generation of ML and AI.

-- Gunter Ollmann

First Published: Security InfoWatch - June 20, 2023

What to Consider When Building an Autonomous SOC

Today’s threat landscape demands more from IT and security professionals than ever before. Schools are being forced to shut down due to ransomware attacks, major brands are falling victim to reputation-harming data breaches, and an explosion of connected devices has broadened the attack surface. At the same time, cyber-criminals are getting smarter and savvier, developing new ways to evade detection software and make money.

As cyber-criminals are getting more creative, the cybersecurity industry is improving and developing innovative solutions to protect businesses. Earlier this year, the FBI revealed it had turned the tables on the notorious Hive ransomware gang by secretly hacking the group’s systems, saving $130 million in ransomware demands for more than 300 victims. Despite our best efforts, there are still elements holding us back as an industry and continuing to make organizations vulnerable to cyber-attacks. Prevention, monitoring, and mitigation all happen in the Security Operations Center (SOC), and, right now, SOCs are facing the perfect storm for cyber-crime: lack of visibility into complex operating environments, inability to analyze cloud-scale volumes of data, and an industry-wide shortage of cybersecurity talent. As a result, security professionals are experiencing widespread burnout and unrealistic workloads, which lowers their productivity and creates higher security risks.

Autonomous SOC: Building Yours Right

A lot of the burnout security practitioners face is caused by alert fatigue. When alerts about potential cyber-attacks come in at a rate faster than SOC analysts can handle, analysts work longer hours and still miss important threats. To cut through the noise and focus on the attacks that matter most, SOCs need to take a cue from cyber-criminals and adapt to the current threat landscape: They need to start their journey to the autonomous SOC.

Understanding the Autonomous SOC

An autonomous SOC (ASOC) is composed of an artificial intelligence (AI) and/or machine learning (ML) system that receives all of the data points coming in and assists with cybersecurity monitoring and mitigation. An ASOC is ideal for threat investigation since it can automatically detect suspicious activity, learn and correlate everything about the attack quickly, and provide analysts with the context they need to detect, isolate, and neutralize the attack easily and efficiently. The ASOC also filters out false negatives, allowing analysts to direct their focus on real threats and take immediate action.

The ASOC helps alleviate many of the issues organizations face with their security posture — limited resources, overwhelmed analysts, and repetitive, monotonous tasks. AI and ML’s ability to identify patterns and outliers boosts analysts with an actionable plan of prevention and mediation. An ASOC running in the background provides a much-needed extra layer of coverage to protect organizations, especially those dealing with understaffed SOCs due to recent layoffs throughout the tech industry.

There are a lot of questions around autonomy and the SOC. Namely, will ASOCs replace human analysts? The short answer is no. Human and machine collaboration is necessary for success, especially regarding cybersecurity. ASOCs constantly evolve as they ingest data and assess new threats, which is why they will always need human analysts to create guardrails and provide feedback. ASOCs are designed to make analysts’ jobs easier, not to steal them.

What Organizations Should Consider Before Investing

The ASOC is not a passing trend. It’s where our industry is headed. IDC predicts that by 2026, 30 percent of large enterprise organizations will migrate to ASOCs for faster remediation, incident management, and response. Still, many executives misguidedly view the SOC as a department that exclusively costs the company money and does little — if anything — to drive revenue. As such, the shift to an ASOC may seem daunting or unrealistic to some organizations. Proponents of plans to build an ASOC might face pushback from others in the organization and need to justify the investment costs. The bottom line of an ASOC is to get more value out of the tools and workflows at the SOC’s disposal. In the short-term, this means SOC analysts who are less burnt out, more engaged, and stay at the company longer. In the long-term, investments in cybersecurity save the company money in terms of reputational damage and customer loss if an attack or breach occurs.

Another aspect to consider is timing. Ask yourself, “Is my organization ready for this transition?” Assess the maturity of the SOC and bring SOC analysts and leaders into the conversation. It’s also important to note that moving to an ASOC doesn’t have to be all or nothing; it’s a journey.

Keeping these elements in mind will help you to seamlessly transition to an automated SOC, the future of cybersecurity.

-- Gunter Ollmann

First Published: Solutions Review - March 30, 2023