In confidential computing environments, attestation is crucial in verifying the trustworthiness of the location where you plan to run your workload or where you plan to send confidential information. Before actually running the workload or transmitting the confidential information, you need to perform attestation.This blog provides an overview of the components implemented in the confidential containers (CoCo) to support the IETF RATS model (Remote ATtestation procedureS Architecture). The components include the Attestation Service (AS), Key Broker Service (KBS), Reference Value Provider Servi

In confidential computing environments, _attestation_ is crucial in verifying the trustworthiness of the location where you plan to run your workload or where you plan to send confidential information. Before actually running the workload or transmitting the confidential information, you need to perform **attestation**.

This blog provides an overview of the components implemented in the confidential containers (CoCo) to support the IETF RATS model **(Remote ATtestation procedureS Architecture)**. The components include the Attestation Service (AS), Key Broker Service (KBS), Reference Value Provider Service (RVPS), Attestation Agent (AA), and Confidential Data Hub (CDH). The AS, KBS, and RVPS components are part of the Trustee project, whereas the AA and CDH are part of the guest-components project in CoCo.

We begin by introducing the RATS model and its components. After that, we discuss the Trustee project, its various components, and how they relate to the RATS model. Finally, we present a few use cases that demonstrate the usage of the CoCo Trustee and guest-components project.

**RATS architecture and key components**

The key components in the RATS architecture are described in the following diagram:

*   **Attester** - provides **Evidence**, which is evaluated and appraised to decide its trustworthiness (for instance, a test to see whether it’s authorized to perform some action). Evidence may include configuration data, measurements, telemetry, or inferences.
*   **Verifier** - evaluates the validity of the evidence received from the attester and produces **attestation results**, which are sent to the Relying party. Attestation results typically include information regarding the Attester, while the Verifier vouches for the validity of the results.
*   **Relying party** - depends on the validity of information originating from the attester for reliably applying an action. This information can come from the verifier or directly through the attester.
*   **Relying party owner** - authorized to configure the appraisal policy that the **relying party** will use when receiving the attestation results (such as admin).
*   **Verifier owner** - authorized to configure the appraisal policy the **verifier** will use when receiving the evidence.
*   **Endorser** - for us, the hardware manufacturer who provides an **endorsement**, which the **verifier** uses to validate the evidence received from the attester. The endorsement is a secure statement the Endorser vouches for on the integrity of an Attester's various capabilities
*   **Reference Value Provider** - for us the hardware manufacturer who provides **reference values**, which the verifier uses to verify that claims were recorded by the attester. Reference values are, for example, golden measurements or nominal values.

In practice, the data flow between the verifier, attester, and relying party can be done through the **passport check model** and **background check model**.

**Passport check model**

In the passport model, the **attester** validates an identification token with the **verifier**. It then presents the **identification token** to the **relying party**. It's a similar process to when you present your passport at an airport to confirm your own identity when entering a country.

In this model, the attester requests the passport from the verifier by providing **evidence** and receives a passport in the form of **attestation results**. It can now interact directly with the relying party by presenting its passport (attestation result).

The following diagram shows this flow: 

**Background check model**

In the background check model, the **relying party** asks for verification each time the **attester** presents its evidence. This is similar to performing a full background check on an individual every time the individual enters a country.

The attester provides **evidence** to the relying party, which forwards it directly to the verifier. The verifier compares the evidence with the **appraised policy** it contains, and returns an **attestation result** to the relying party. The relying party compares the attestation results with its own **appraisal policy**.

Unlike a passport model, where the attester sends **attestation results** to the relying party, the background model requires the attester to send the relying party **evidence** (which is sent as-is to the verifier).

The following diagram illustrates the background check model:

**The Trustee project**

The trustee project (previously known as CoCo KBS) includes components deployed on a trusted side and used to verify whether the remote workload is running in a trusted execution environment (TEE). It also verifies that the remote environment uses the expected software and hardware versions.

This diagram shows the architecture for the Trustee model:

The **left side** includes the **guest components** running inside the TEE, including the Attestation Agent (AA) and Confidential Data Hub (CDH). The **right side** includes the external components, which the guest components interact with, such as the Key Broker Service (KBS), Attestation Service (AS), and the Reference Value Provider Service (RVPS).

**Trustee and guest components****Key Broker Service (KBS)**

The Key Broker Service (KBS) facilitates remote attestation and managing and delivering secrets. Equating this to the RATS model, the KBS is the **relying party** entity. The KBS, however, doesn’t validate the attestation evidence. Instead, it uses the attestation service (AS) to verify the TEE evidence.

**Attestation Service (AS)**

The Attestation Service (AS) is responsible for validating the TEE evidence. This includes evidence from the following TEEs: Intel TDX, Intel SGX, AMD SEV-SNP, ARM CCA, Hygon CSV, and more.

When mapped to the RATS model, the AS is the equivalent of the **verifier**.

The AS receives attestation evidence and returns an attestation token containing the results of a two-step verification process. Note that the KBS is the client of the AS, however the evidence originates from the attestation agent (AA).

The following diagram shows the AS components:

The AS runs the following verification process:

1.  **Verify the formatting and the origin of the evidence** - for example, checking the signature of the evidence. This is accomplished by one of the platform-specific Verifier Drivers.
2.  **Evaluate the claims provided in the evidence** - for example, validating that the measurements are what the client expects. This is done by a Policy Engine with help from the RVPS.

**Verifier driver**

A verifier driver parses the attestation evidence provided by the hardware TEE. It performs the following tasks:

1.  Verifies the hardware TEE signature of the TEE quote and report provided in the evidence
2.  Receives the evidence and organizes the status into a JSON format to be returned

**Policy Engine**

The AS allows users to upload their own policies when performing evidence verification. When an attestation request is received by the AS, it uses a policy ID in the request to decide which policies should be evaluated. The results of all policies evaluated are included in the attestation response.

**Reference Value Provider Service (RVPS)**

The reference value provider service (RVPS) is a component in the AS responsible for verifying, storing, and providing reference values. RVPS receives and verifies inputs from the software supply chain, stores the measurement values, and generates reference value claims for the AS. This operation is performed based on the evidence verified by the AS.

The following diagram shows the RVPS components:

RVPS contains the preprocessors, extractors, and store components:

**Preprocessors**

These are plugins that preprocess the reference value registration messages before sending it to extractors.

**Extractors**

These are plugins that process different types of provenance in the input message. Each plugin consumes the input message, and then generates an output **Reference** value.

**Store**

The store component provides persistent storage for the reference values.

**Attestation Agent (AA)**

The Attestation Agent (AA) is the entity running inside the TEE that connects to the KBS in order to perform attestation.  AA is responsible for sending the evidence (claims) from the TEE to prove the trustworthiness of the environment.

**Confidential Data Hub (CDH)**

The Confidential Data Hub (CDH) facilitates secure key retrieval for kata-agent and applications. It also provides additional services, such as secure mount for external storage or key management client services to retrieve keys directly from external Key Management Services. The secure mount service enables mounting of encrypted storage inside the TEE. We'll cover the secure mount service in a subsequent blog.

The following diagram shows the CDH components:

**Resources for learning about the attestation flow**

For an **overview of attestation**, read our Learn about Confidential Computing Attestation blog series.

For details on **attestation flow in confidential containers**, read our Understanding the Confidential Containers Attestation Flow article.

For a **step-by-step flow of confidential containers attestation on Azure** cloud, read our Confidential Containers on Azure with OpenShift: A technical deep dive article.

**Mapping Trustee components to the RATS model**

This is how the RATS model maps to the Trustee components model:

Note the following:

*   The **Attester** functionally is performed by the **AA** and **CDH** guest side components.
*   The **Verifier** is mapped to the **AS**.
*   The **Relying party** is mapped to the **KBS** receiving attestation results from the AS, and performing actions based on the results.
*   The **Endorser** usually originates from the platform manufacturer (Intel, AMD, IBM, and so on), so it can be the manufacturer itself or a CSP that got endorsed by the hardware manufacturer.
*   The **Reference Value Provider** is mapped to the **RVPS** and provides the endorsed reference. Note that reference values do not originate from the hardware manufacturer, but rather they reference measurements of the kernel, firmware image, and so on. They are trusted artifacts meaning signed by an identity you can trust and are used for performing the verification.
*   The **Verify owner** and **Relying Party** owner are the entities who operate the KBS and AS on the user's behalf.

**Background check model**

The background check model is a common way to configure the KBS and AS components, so we present it before the passport model. The following diagram shows the model: 

In this model, the AA communicates with the KBS providing the hardware evidence and the KBS communicates with the AS to verify it. After the evidence is verified, the KBS releases the secrets back to the CDH when requested.

In background check mode, the KBS is the relying party, the AS is the verifier, and the AA is the attester.

**Passport model**

In the passport model, the validation of evidence and provisioning of resources are typically handled by  different KBSes. The following diagram shows the model: 

We now have 2 KBS entities:

*   The first KBS, with the AS, verifies the evidence from the guest.
*   The second KBS provides secrets to the guest.

The AA interacts with **upper KBS + AS (Trustee 1)** in order to attest, verify the evidence, and receive a token (a passport). It then requests the secret resources from the **lower KBS (Trustee 2)**.

In practice, we recommend using the passport model when the attestation and resource provisioning are handled by separate entities.

**Attestation use cases leveraging Trustee components**

There are many use cases that can leverage the Trustee and guest components. For simplicity, we focus on the **background check model** (a single KBS) and not the **passport model** (with two KBS entities).

**Attestation for virtual machines (VMs) and their workloads**

Confidential VMs (CVMs) leverage hardware-based security features, such as AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) or Intel TDX (Trust Domain Extensions) to provide a secure execution environment for sensitive workloads. These VMs confirm that code and data remain encrypted and isolated, even from other privileged softwares on the host system. However, validating the integrity of these VMs and their underlying hardware is critical to guaranteeing the confidentiality and security of the data that is processed.

For a detailed description of confidential VMs, read our Learn about Red Hat Confidential Virtual Machines blog series.

VM attestation verifies the integrity of a confidential VM and its underlying platform components, including the CPU, firmware, and hypervisor. The attestation process might be initiated by the firmware or initrd.

From a trust perspective, you need assurance that the VM you just created on a public cloud is really a CVM with an operating system of your choice. In particular, you need to make sure that the host hasn’t started a non-confidential VM with a specially crafted guest operating system to steal your secrets instead.

The following diagram shows the overall architecture for VM attestation: 

Note the following:

*   The CVM can run over a KVM hypervisor, some other hypervisor on bare metal or on a public cloud provider infrastructure.
*   The AA works with the Trustee AS.

Here is a list of Trustee and guest components being used:

**Trustee components**

**Guest components**

KBS

AA

AS

 

RVPS

 

**Attestation for a confidential containers workload**

Moving from the VM level attestation to a container level attestation, let’s focus on container workload the user wants to run in a secure manner protected from the host.

Attestation for confidential containers verifies the container runtime stack running in the confidential environment. This includes kata-agent, supporting services like agent-protocol-forwarder, process-user-data, open policy agent, and default policies that are needed to run the container.

If the confidential containers are using the VM trusted execution environment, then the attestation includes attestation of the VM followed by attestation of the container runtime components. This diagram shows the overall architecture for confidential container attestation: 

Note the following:

*   Peer-pods are used for running confidential containers over VMs (on-prem and public cloud). For additional details, read Deploying confidential containers on the public cloud
*   The trustee model is used twice in this case to attest the CVM and then attest the confidential container runtime components

Here's a list of Trustee and guest components being used:

**Trustee components**

**Guest components**

KBS

AA

AS

 

RVPS

 

**Attestation to retrieve container image signing or decryption keys**

This use case is specific to obtaining the key for signature verification of a signed container image or obtaining the decryption key for encrypted images. For example, you might use encrypted container images to ship proprietary or sensitive code, such as AI models.

If the confidential containers are using the VM trusted execution environment, then the attestation process begins with VM attestation to confirm the integrity of the underlying execution environment. Once the VM's trustworthiness is established, container attestation proceeds, confirming the authenticity and integrity of the container runtime components. After a successful attestation, the container runtime requests the key from the Key Broker Service (KBS) for signature verification or decryption of the container images before starting the application.

The following diagram shows the overall architecture for retrieving the container image signing or decryption keys:

The attestation process is similar to attesting a confidential container workload, with the extra step of CDH retrieving the signing or decryption key that gets used by the kata-agent for signature verification or decrypting the container image.

This is a list of Trustee and guest components being used:

**Trustee components**

**Guest components**

KBS

AA

AS

CDH

RVPS

 

**Attestation for releasing application secrets**

This use case is specific to obtaining the key used by the workload. An example use case for obtaining the key is **Data Clean Rooms**. 

A number of organizations want to analyze data without compromising the privacy of individuals whose data is being analyzed (a joint bank fraud detection effort, for example). They're required to create a shared secured environment for data leaving the boundaries of those individuals. They would also want that environment to run in the cloud at scale. This can be accomplished by a secure key release where the data decryption key is only released to a specific TEE based on attestation.

The following diagram shows the idea: 

If the confidential containers are using the VM trusted execution environment, then the attestation process begins with VM attestation to ensure the integrity of the underlying execution environment. Once the VM's **trustworthiness** is established, container attestation proceeds, confirming the authenticity and integrity of the container runtime components. After a successful attestation, the container runtime starts the application.

The application then starts another attestation sequence to request the application secret from the Key Broker Service (KBS).  Confidential Data Hub (CDH) is used to request the application secret from the KBS by initiating an attestation sequence to prove the trustworthiness of the environment.

The following diagram shows the additional step of obtaining the application secret:

Note the following:

*   The attestation process is similar to attesting a confidential container workload, with the extra step of CDH retrieving the application secrets and providing it to the application
*   If the container images are signed or encrypted, then first the signing or decryption key is fetched (as described in the previous use case), followed by the application secret retrieval by CDH

Here's a list of Trustee and guest components being used:

**Trustee components**

**Guest components**

KBS

AA

AS

CDH

RVPS

 

**Trustee project and confidential computing**

In this blog we have introduced the Trustee project which is part of the confidential containers CNCF initiative and includes a number of services providing attestation capabilities for containers, VMs, shared keys and more.

We’ve covered the IETF RATS model, reviewed the Trustee components and showed the mapping between Trustee and the RATS model. We’ve also reviewed a number of use cases requiring attestation and presented how the Trustee components are used for those purposes.

In future blogs, we'll dive deeper into the Trustee projects looking at the technical details and hands on instructions on how to try out things.

Introducing Confidential Containers Trustee: Attestation Services Solution Overview and Use Cases

Nearly three months after Operation Cronos, it's clear the gang is not bouncing back from the innovative law-enforcement action. RaaS operators are on notice, and businesses should pay attention.

Source: Jan Zwoliński via Alamy Stock Photo

Despite the LockBit ransomware-as-a-service (RaaS) gang claiming to be back after a high-profile takedown in mid-February, an analysis reveals significant, ongoing disruption to the group's activities — along with ripple effects throughout the cybercrime underground, with implications for business risk.

LockBit was responsible for 25% to 33% of all ransomware attacks in 2023, according to Trend Micro, easily making it the biggest financial threat actor group of the last year. Since it emerged in 2020, it has claimed thousands of victims and millions in ransom, including cynical hits on hospitals during the pandemic.

The Operation Cronos effort, involving multiple law enforcement agencies around the world, led to outages on LockBit-affiliated platforms, and a takeover of its leak site by the UK's National Crime Agency (NCA). Authorities then used the latter to make arrests, impose sanctions, seize cryptocurrency, and more activities related to the inner workings of the group. They also publicized the LockBit admin panel and exposed the names of affiliates working with the group.

Further, they noted that decryption keys would be made available, and revealed that LockBit, contrary to its promises to victims, never deleted victim data after payments were made.

In all it was a savvy show of force and access from the policing community, spooking others in the ecosystem in the immediate aftermath and leading to wariness when it comes to working with any re-emergent version of LockBit and its ringleader, who goes by the handle "LockBitSupp."

Researchers from Trend Micro noted that, two and a half months after Operation Cronos, there's precious little evidence that things are turning around for the group — despite LockBitSupp's claims that the group is clawing its way back into normal operations.

**A Different Kind of Cybercrime Takedown**

Operation Cronos was initially met with skepticism by researchers, who pointed out that other recent, high-profile takedowns of RaaS groups like Black Basta, Conti, Hive, and Royal (not to mention the infrastructure for initial access trojans like Emotet, Qakbot, and TrickBot), have resulted in only temporary setbacks for their operators.

However, the LockBit strike is different: The sheer amount of information that law enforcement was able to access and make public has permanently damaged the group's standing in Dark Web circles.

"While they often focus on taking out command and control infrastructure, this effort went further," Trend Micro researchers explained in an analysis released today. "It saw police manage to compromise LockBit's admin panel, expose affiliates, and access information and conversations between affiliates and victims. This cumulative effort has helped to tarnish the reputation of LockBit among affiliates and the cybercrime community in general, which will make it harder to come back from."

Indeed, the fallout from the cybercrime community was swift, Trend Micro observed. For one, LockBitSupp has been banned from two popular underground forums, XSS and Exploit, hampering the admin's ability to garner support and rebuild.

Shortly after, a user on X (formerly Twitter) called "Loxbit" meanwhile claimed in a public post to have been cheated by LockBitSupp, while another presumed affiliate called "michon" opened up a forum arbitration thread against LockBitSupp for nonpayment. One initial-access broker using the handle "dealfixer" advertised its wares but specifically mentioned that they did not want to work with anybody from LockBit. And another IAB, "n30n," opened a claim on the ramp\_v2 forum about loss of payment surrounding the disruption.

Perhaps worse, some forum commentators were extremely concerned by the sheer amount of information that police were able to compile, and some speculated that LockBitSupp may even have worked with law enforcement on the operation. LockBitSupp quickly announced that a vulnerability in PHP was to blame for the ability of law enforcement to infiltrate the gang's information; Dark Web denizens simply pointed out that the bug is months old and criticized LockBit's security practices and lack of protection for affiliates.

"The sentiments of the cybercrime community to LockBit's disruption ranged from satisfaction to speculation about the group's future, hinting at the significant impact of the incident on the RaaS industry," according to Trend Micro's analysis, released today.

**LockBit Disruption's Chilling Effect on the RaaS Industry**

Indeed, the disruption has sparked some self-reflection among other active RaaS groups: A Snatch RaaS operator pointed out on its Telegram channel that they were all at risk.

"Disrupting and undermining the business model seem to have had a far more cumulative effect than executing a technical takedown," according to Trend Micro. "Reputation and trust are key to attracting affiliates, and when these are lost, it's harder to get people to return. Operation Cronos succeeded in striking against one element of its business that was most important: its brand."

Jon Clay, Trend Micro's vice president of threat intelligence, tells Dark Reading that LockBit's defanging and the disruption's chilling effect on RaaS groups in general present an opportunity for business risk management.

"This can be a time for businesses to reassess their defense models as we may see a slowdown in attacks while these other groups assess their own operational security," he notes. "This is also a time to review a business incident response plan to make sure you have all aspects of a breach covered, including business operation continuity, cyber insurance, and the response — to pay or not pay."

**LockBit Signs of Life Are Greatly Exaggerated**

LockBitSupp is nonetheless attempting to bounce back, Trend Micro found — though with few positive results.

New Tor leak sites launched a week after the operation, and LockBitSupp said on ramp\_v2 forum that the gang is actively seeking out IABs with access to .gov, .edu, and .org domains, indicating a thirst for revenge. It wasn't long before scores of supposed victims started appearing on the leak site, starting with the FBI.

However, when the ransom payment deadline came and went, instead of sensitive FBI data appearing on the site, LockBitSupp posted a lengthy declaration that it would continue to operate. In addition, more than two-thirds of the victims consisted of reuploaded attacks that occurred prior to Operation Cronos. Of the others, the victims belonged to other groups, such as ALPHV. In all, Trend Micro's telemetry revealed just one small true LockBit activity cluster after Cronos, from an affiliate in southeast Asia that carried a low, $2,800 ransom demand.

Perhaps more concerningly, the group has also been developing a new version of ransomware — Lockbit-NG-Dev. Trend Micro found it to have a new .NET core, which allows it to be more platform-agnostic; it also removes self-propagating capabilities and the ability to print ransom notes via the user's printers.

"The code base is completely new in relation to the move to this new language, which means that new security patterns will likely be needed to detect it. It's still a functional and powerful piece of ransomware," researchers warned.

Still, these are anemic sign of life at best for LockBit, and Clay notes that its unclear where it or its affiliates may go next. In general, he warns, defenders will need to be prepared for shifts in ransomware gang tactics going forward as those participating in the ecosystem assess the state of play.

"RaaS groups are likely looking at their own weaknesses being caught by law enforcement," he explains. "They may review what types of businesses/organizations they target so as to not give much attention to their attacks. Affiliates may look at how they can rapidly shift from one group to another in case their main RaaS group gets taken down."

He adds, "shifting towards data exfiltration only versus ransomware deployments may increase as these don't disrupt a business, but can still allow profits. We could also see RaaS groups shift entirely towards other attack types, like business email compromise (BEC), which don't seem to cause as much disruption, but are still very lucrative for their bottom lines."

**About the Author(s)**

Tara Seals has 20+ years of experience as a journalist, analyst and editor in the cybersecurity, communications and technology space. Prior to Dark Reading, Tara was Editor in Chief at Threatpost, and prior to that, the North American news lead for Infosecurity Magazine. She also spent 13 years working for Informa (formerly Virgo Publishing), as executive editor and editor-in-chief at publications focused on both the service provider and the enterprise arenas. A Texas native, she holds a B.A. from Columbia University, lives in Western Massachusetts with her family and is on a never-ending quest for good Mexican food in the Northeast.

LockBit Ransomware Takedown Strikes Deep Into Brand's Viability

PRESS RELEASE

SEATTLE – April 3, 2024 – A new survey from the Cloud Security Alliance (CSA), the world’s leading organization dedicated to defining standards, certifications, and best practices to help ensure a secure cloud computing environment, and Google Cloud, found that a remarkable 55% of organizations surveyed plan to adopt GenAI solutions within the next year, signaling a substantial surge in GenAI integration. The State of AI and Security Survey Report indicates that the push behind AI’s adoption can be attributed in large part to C-level executives (82% of respondents indicated executive leadership as being behind the push), who recognize the competitive advantage it offers in the modern business environment.

The study also found that AI integration into cybersecurity is not just a concept but also a practical reality for many, with 67% of respondents stating that they have tested AI specifically for security purposes. As for the ability to leverage AI, 48% of professionals expressed confidence in their organization's ability to execute a strategy for leveraging AI in security, with 28% feeling reasonably confident and 20% very confident. Given the nascent stage of GenAI in this field, this level of assurance suggests that many professionals might be optimistic about their preparedness or overlook the intricacies of AI integration.

“The insights shared in this report into how industry experts view and prepare for AI's evolving role in cybersecurity are pivotal in navigating this transition and ensuring a resilient, forward-looking digital infrastructure,” said Hillary Baron, lead author and Senior Technical Director for Research, Cloud Security Alliance.

“AI is transforming cybersecurity, offering both exciting opportunities and complex challenges. However, the disconnect between the C-suite and staff in understanding and implementing AI highlights the need for a strategic, unified approach to successfully integrate this technology," said Caleb Sima, chair of CSA’s AI Safety Initiative.

“Once in a generation, we see a chance for profound cybersecurity transformation, not just incremental gains. With generative AI, we have the potential to turn the tables on attackers by 10x’ing the capabilities of defenders. While we need to counter attacker use of AI, it’s even more important to get going on integrating AI into cyber defenses today. The findings in the report resonate well with Google’s Secure AI Framework,” said Phil Venables, CISO, Google Cloud.

Among the survey’s other key findings:

*   Security professionals are cautiously optimistic about AI. 63% of respondents believe in AI's potential to enhance security measures, especially in improving threat detection and response capabilities. However, 34% see AI as more beneficial for security teams, while 31% view it as equally advantageous for both protectors and attackers, and a notable 25% of respondents expressed concerns that AI could be more advantageous to malicious parties.
    
*   AI will empower, not replace, security professionals. Only a small fraction (12%) of security professionals believe it will completely replace their role. The majority believe it will help enhance their skill set (30%), support their role generally (28%), or replace large parts of their role (24%), freeing them up for other tasks.
    
*   C-suite executives have different perspectives from their staff when it comes to AI. C-levels demonstrate a notably higher self-reported familiarity with AI technologies than their staff. Moreover, C-levels report having a clearer understanding of potential AI use cases, with 51% feeling very clear about them, compared to just 14% of staff.
    
*   2024 will be the year for AI Implementation. Over half (55%) of organizations are planning to implement security solutions and tools with GenAI and are exploring a diverse range of use cases for these technologies, with the top use cases being rule creation (21%), attack simulation (19%), and compliance violation detection (19%).
    

Google Cloud commissioned CSA to develop a survey and report to better understand the industry’s knowledge, attitudes, and opinions regarding AI. Google Cloud financed the project and co-developed the questionnaire with CSA research analysts. The survey was conducted online by CSA in November 2023 and received 2,486 responses from IT and security professionals from organizations of various sizes across the Americas, APAC and EMEA. CSA’s research analysts performed the data analysis for this report.

Download the State of AI and Security Survey Report.

About Cloud Security Alliance  
The Cloud Security Alliance (CSA) is the world’s leading organization dedicated to defining and raising awareness of best practices to help ensure a secure cloud computing environment. CSA harnesses the subject matter expertise of industry practitioners, associations, governments, and its corporate and individual members to offer cloud security-specific research, education, training, certification, events, and products. CSA's activities, knowledge, and extensive network benefit the entire community impacted by cloud — from providers and customers to governments, entrepreneurs, and the assurance industry — and provide a forum through which different parties can work together to create and maintain a trusted cloud ecosystem. For further information, visit us at www.cloudsecurityalliance.org, and follow us on Twitter @cloudsa.

More Than Half of Organizations Plan to Adopt AI Solutions in Coming Year, Reports Cloud Security Alliance and Google Cloud

PRESS RELEASE

Austin, TX – April 3, 2024 – CyberRatings.org (CyberRatings), the non-profit entity dedicated to providing confidence in cybersecurity products and services through its research and testing programs, has completed an independent test of eleven market leading Cloud Network Firewall vendors. Six products were Recommended, one product received a Neutral rating, and four received a Caution rating.

Cloud network firewalls are considered to be the first line of defense when deployed in public cloud providers such as Amazon Web Services, Google Cloud Platform and Microsoft Azure. But implementing security in the cloud can be complex, with multiple factors influencing effectiveness. 

CyberRatings tested the cloud firewall products to determine how they handled TLS/SSL (authentication) 1.2 and 1.3 cipher suites (algorithms), how they defended against 984 exploits (attacks that take advantage of a software flaw or install malware), and whether any of 1,645 evasions could bypass protection. At all times the devices needed to remain stable under adverse conditions. To provide a more realistic rating based on modern network traffic, both clear text (HTTP) and encrypted traffic (HTTPS) were measured. Amazon Web Services (AWS) was the public cloud service chosen to run the test.

The combination of Security Effectiveness and Value dictated where products landed on the Security Value Map™ (SVM). Six out of the eleven products were Recommended for their Security Effectiveness with scores ranging from 99.70% to 100%. Recommended ratings are based on threat prevention (how many exploits and evasions were blocked?), TLS/SSL functionality, routing and policy enforcement, and stability and reliability to achieve a final Security Effectiveness score. These same products also demonstrated competitive pricing in the Total Cost per Protected Mbps (Value). The product rated Neutral received a 48.44% Security Effectiveness score. Four products rated Caution had Security Effectiveness scores ranging from 5.39% to 48.37%. 

“We have been testing firewalls for years, and more recently cloud network firewalls,” said Vikram Phatak, CEO of CyberRatings.org. “All of the products chosen were market leaders and the range of scores clearly shows that building a product for the cloud is different than building a product on an appliance where you control the environment,” said Phatak. “We recommend that enterprises check with their service providers or IT teams to see which cloud firewall products are currently deployed in their networks.”

As part of the cloud firewall test, CyberRatings also checked to see if products were secure by default. It was discovered that some firewall evasion defenses are not on by default, potentially leaving customers at significant risk. In response, CyberRatings is providing a policy and configuration guide to help enterprises ensure that their firewalls are configured properly.

Encryption matters: roughly 80% of web traffic is encrypted. The top four cipher suites account for over 95% of HTTPS traffic. In some products, decryption was not on by default. Firewalls will not see attacks delivered via HTTPS unless configured to do so. Performance is significantly different when TLS/SSL is turned on. With the exception of one vendor that failed to handle TLS 1.3 despite claiming support, all other vendors supported encryption. 

Enterprises should monitor security and performance capabilities, and update firewalls regularly. With the everchanging cloud platform and agile development, something can go wrong even when the security vendor does not make a change. 

The following products were evaluated:

Cloud Network Firewall

Rating

Security

Effectiveness

Rated Throughput

(Mbps)

Price per Protected Mbps

Amazon Web Services (AWS) Network Firewall

Caution

5.39%

1,000

$601.34

Barracuda CloudGen Firewall

Caution

11.38%

441

$287.86 

Check Point CloudGuard

Recommended

99.80%

1,180

$12.70 

Cisco Secure Firewall Threat Defense Virtual 

Caution

20.86%

373

$76.91 

Forcepoint NGFW

Recommended

99.80%

698

$8.45 

Fortinet FortiGate-VM

Recommended

100%

1,458

$10.56 

Juniper Networks vSRX

Recommended

99.70%

1,228

$5.72 

Palo Alto Networks VM-Series Next-Generation Firewall w/ Advanced Threat Prevention

Recommended

100%

1,036

$5.83 

Sophos Firewall

Caution

48.37%

135

$83.16 

Versa Networks NGFW

Recommended

99.90%

2,553

$7.58 

WatchGuard Firebox Cloud

Neutral

48.44%

291

$27.06 

Additional Resources:

Cloud Network Firewall Comparative Report and Test Reports

2024 Best Practices for Cloud Network Firewall Deployment

Exploring the Landscape of Cloud Network Firewalls Available on AWS

Why Firewalls Should be Secure by Default

About CyberRatings.org 

CyberRatings.org is a 501(c)6 non-profit organization dedicated to providing confidence in cybersecurity products and services through our research and testing programs. We provide enterprises with independent, objective ratings of security product efficacy to make informed decisions. To become a member, visit www.cyberratings.org and follow us on LinkedIn.

CyberRatings.org Announces Test Results for Cloud Network Firewall

PRESS RELEASE

MINNEAPOLIS, April 2, 2024 – Businesses are facing a critical gap when it comes to protecting endpoint data, according to a study released today by TAG Infosphere, Inc., a leading  cybersecurity research and advisory firm. The report, conducted in partnership with CrashPlan, identified the ever-growing potential for ransomware attacks, frequent misuse of cloud collaboration tools as a substitute for backup, and an over-reliance on manual policies as the break in the chain for current enterprise security configurations. 

For the study, TAG surveyed a group of CISOs and security practitioners, and the key findings were clear: The overwhelming majority (93%) of IT and cybersecurity teams aren’t confident in their policies to protect their enterprise data. Furthermore, survey respondents acknowledged the likelihood of a severe data breach through an employee’s endpoint.

“We were surprised to learn that a whopping 71% of those asked responded that they would not be surprised if they had a serious data breach on their PCs and laptops. If the question was extended to include that they might be surprised, the number grew to 86%,” said Dr. Edward Amoroso, Chief Executive Officer and founder of TAG Infosphere. “This is important because it implies that serious risk exists in this area. If that many CISOs would not be surprised if something bad happened, then that’s a problem.”

TAG introduces the MEAD framework (Malware, EDR, Analytics, and Data) for modernizing endpoint security. Central to MEAD is the adoption of endpoint backup solutions as a pivotal measure for enhancing cyber resilience. The report advocates for endpoint backup to reduce risks to data on endpoints, detailing how this strategy safeguards data against hardware malfunctions, user errors, and cyber threats. 

“New cybersecurity technologies are introduced every year, yet data breaches continue to happen,” said Todd Thorsen, Chief Information Security Officer for CrashPlan. “The reality is work habits have changed. Most companies now have a hybrid work model—and this has shined a light on just how ineffective manual policies are when it comes to protecting endpoint data. To improve resiliency, you simply can’t lose sight of the foundation. Despite new tools and technology designed to identify, detect and protect against bad actors and malicious activity, breaches will still happen. Which is why having strong data backup and resilience capabilities are critical for effective response and recovery.”

CrashPlan offers a cloud-native platform designed to address the aggregate risk associated with data stored on endpoints within organizations. It offers a comprehensive backup and data protection system that safeguards valuable business data from loss, theft, or accidental deletion. Businesses of all sizes, across all different business sectors, use CrashPlan today to ensure a more robust data protection and resilience approach.                                          

About CrashPlan  
CrashPlan® enables organizational resilience through secure, scalable, and straightforward endpoint data backup. With automatic backup and customizable file version retention, you can bounce back from any data calamity. What starts as endpoint backup and recovery becomes a solution for ransomware recovery, breaches, migrations, and legal holds. So, you can work fearlessly and grow confidently.

About Tag Infosphere

TAG is a trusted research and advisory company that provides insights and recommendations in cybersecurity, artificial intelligence, and climate science to thousands of commercial solution providers and Fortune 500 enterprises. Founded in 2016 and headquartered in New York City, TAG bucks the trend of pay-for-play research by offering unbiased and in-depth guidance, market analysis, project consulting, and personalized content—all from a practitioner perspective.

About Dr. Edward Amoroso

Dr. Ed Amoroso is currently Chief Executive Officer of TAG Infosphere Inc, a global research and advisory company that supports enterprise cyber security teams and commercial security vendors around the world. Ed recently retired from AT&T after thirty-one years of service, beginning in Unix security R&D at Bell Labs and culminating as Senior Vice President and Chief Security Officer of AT&T from 2004 to 2016.

Ed has served as Research Professor at the Tandon School of Engineering at NYU since 2017. He has also been Adjunct Professor of Computer Science at the Stevens Institute of Technology for the past thirty years, where he has introduced nearly two thousand graduate students to the topic of information security. Ed also serves the Applied Physics Laboratory at Johns Hopkins University as a senior advisor. He is author of six books on cyber security and dozens of major research and technical papers and articles in peer-reviewed and major publications.

TAG Report Reveals Endpoint Backup Is Essential to Improving Data Resiliency

A China-linked threat actor had access to a router configuration database that could have completely disrupted coverage, a security vendor says.

Source: rarrarorro via Shutterstock

About six months before the 2022 FIFA World Cup soccer tournament in Qatar, a threat actor — later identified as China-linked BlackTech — quietly breached the network of a major communications provider for the games and planted malware on a critical system storing network device configurations.

The breach remained undetected until six months after the games, when researchers at NetWitness spotted it during a routine audit for the service provider. During that period, the cyber-espionage group gathered up an unknown volume of data from targeted customers of the telecommunications provider — including those associated with the World Cup and vendors providing services for it.

**A Near Miss**

But it's the "what else could have happened" that's the really scary part, says Stefano Maccaglia, global practice manager, incident response, at NetWitness, discussing the incident for the first time with Dark Reading recently.

The access that BlackTech had on the telecom provider's system would have allowed the threat actor to completely disrupt key communications — including all streaming services associated with the game. The fallout from such a disruption would have been substantial in terms of geopolitical implications, brand damage, national reputation, and potentially hundreds of millions of dollars in losses from the licensing rights and ads negotiated prior to the World Cup, Maccaglia says.

"We are normally very collected, but in this case, we were terrified," Maccaglia says of NetWitness' discovery. "The threat actor literally had their finger on the button but didn't push it."

NetWitness' involvement in the Qatar World Cup began in 2022, about six months before the event, when several local service providers hired the company to assess the cybersecurity preparedness of some of the supporting IT infrastructure for the games. Like with other security vendors involved in the effort, the telecom provider gave NetWitness access to a substantial portion of its tech stack and environment — but not to all of it.

According to Maccaglia, the NetWitness team detected and remediated several issues on parts of the provider's tech stack to which the company had access. But it wasn't until early 2023 that the service provider finally opened up the rest of the environment to NetWitness for additional auditing. This was when NetWitness unearthed log activity suggesting that someone had gained access to the provider's network.

**A Rootkit and a Backdoor**

The company's subsequent investigation showed the attacker had planted a sophisticated rootkit and a backdoor, dubbed Waterbear, on a critical configuration management database (CMDB) storing device configurations for the provider's customers. NetWitness found the attackers had used PLEAD — a remote access Trojan commonly associated with the BlackTech APT — to target additional systems within the environment.

"The attacker aimed to control this database \[from\] the beginning, because it would allow him/her to swap configurations on the fly and revert them back, once finished, leaving no traces," Maccaglia says.

BlackTech is a threat actor that the US Cybersecurity and Infrastructure Security Agency (CISA) last year identified as a threat to organizations in the telecommunications, technology, media, electronics, and industrial sectors. In an advisory, CISA described the threat actor (aka Radio Panda, Circuit Panda, Temp.Overboard, and Palmerworm) as particularly adept at modifying router malware without detection and the exploiting routers' domain-trust relationships to gain access to victim networks. "BlackTech actors' TTPs include developing customized malware and tailored persistence mechanisms for compromising routers," CISA noted. "These TTPs allow the actors to disable logging and abuse trusted domain relationships to pivot between international subsidiaries and domestic headquarters' networks."

In the attack on the telecom provider in Qatar, BlackTech actors used their access to the CMDB to change configurations on Asus routers associated with various organizations in such a manner as to make systems belonging to these organizations become accessible over the Internet. They then uploaded PLEAD — concealed in legitimate looking software updates from Asus — to these systems by modifying the DNS resolution of asus.com. The threat actor then leveraged PLEAD to steal data from the victim organizations. Among the systems infected in this manner were those associated with the World Cup games. The attackers would change the router config details for a few hours at a time and then revert back to the original rules to minimize the chances of detection, Maccaglia says.

**Worrying Lack of Visibility**

The fact that no one was able to spot the intrusion in the months leading up to the World Cup, during the event, or for months later is worrisome, Maccaglia says. With the countdown for the 2024 Summer Olympics well underway, it is imperative that the entire technology stack supporting the games be vetted for security issues, he says.

The Olympics, like other major sporting events, such as the Super Bowl, have become huge cyberattack targets in recent years. In 2019, for instance, a threat group later identified and linked to Russia's military intelligence also attempted to disrupt the opening of the Winter Olympics in South Korea after Russian athletes were banned from participating over doping concerns.

"As we saw with the World Cup, threats can live in obscure places and keep a very low profile," Maccaglia says, adding, "You can't find what you aren't allowed to look for," in advocating for broader visibility for companies like NetWitness into the entire supporting infrastructure for the game.

"When you behave as if there's always a threat present, you put yourself in a position to mitigate damage and, potentially, get ahead of the threat in the environment," he says. "This will be critical for the 2024 Summer Games."

**About the Author(s)**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

How Soccer's 2022 World Cup in Qatar Was Nearly Hacked

Effective Rhadamanthys phishing campaign spoofs nonexistent "Federal Bureau of Transportation" to compromise recipients, analysts discover.

Source: Frode Koppang via Alamy Stock Photo

An updated version of the Rhadamanthys malware-as-a-service (MaaS) is being deployed against oil and gas companies, using an effective new lure with a concerning amount of success.

Cofense has been tracking the campaign, which uses emails and a PDF file disguised as communications from the "Federal Bureau of Transportation," according to a new flash alert from the email security analysts. No such bureau exists, and may be a mashup of the Department of Transportation and the Bureau of Transportation Statistics, an purview.

"It is not clear as to why this specific sector is \[being targeted\], but the campaign in its current form could be relevant in most sectors if threat actors decided to change targets," the Cofense alert explained. "While the campaign was actively sending emails, it was successfully reaching targets at an alarming rate."

The campaign appeared just days after the LockBit takedown in February, the analysts said. The latest version of Rhadamanthys, 5.0, was updated earlier in 2024 with improvements to its evasion and data stealing capabilities, Cofense added.

The phishing emails are also carefully crafted, the researchers pointed out. The phishers crafted multiple, provocative subject lines like, "Notification: Incident Involving Your Vehicle," and "Attention Needed: Your Vehicle's Collision."

"As peculiar as it might seem to use vehicle incidents as a phishing lure, the threat actor(s) here put immense effort to ensure that their emails along with the infection chain target recipient's emotions," Cofense added. "Each email body and subject are both different than the next, but they can be summarized by notifying an employee of a car incident through an employer notification, possible legal actions, or even a notice of contacting law enforcement."

**About the Author(s)**

Oil &amp; Gas Sector Falls for Fake Car Accident Phishing Emails

As part of its Secure by Design initiative, CISA urged companies to redouble efforts to quash SQL injection vulnerabilities. Here's how.

Source: Casimiro PT via Shutterstock

For more than a decade, injection vulnerabilities have literally topped the charts of critically dangerous software flaws, deemed more serious than all other types of vulnerabilities in the 2010, 2013, and 2017 Top 10 lists maintained by the Open Web Application Security Project (OWASP).

Still, the warnings have failed to weed out the issues. Last year, the Cl0p group stole data from companies using a previously unknown SQL injection (SQLi) vulnerability in MOVEit's file-transfer application. In late March, the Cybersecurity and Infrastructure Security Agency (CISA) called for companies to redouble their efforts to eliminate the security issue, which application security experts consider one of 13 different "unforgivable" classes of vulnerabilities that programmers should catch during development.

"Despite widespread knowledge and documentation of SQLi vulnerabilities over the past two decades, along with the availability of effective mitigations, software manufacturers continue to develop products with this defect, which puts many customers at risk," the agency stated in its March 25 advisory. "Vulnerabilities like SQLi have been considered by others an 'unforgivable' vulnerability since at least 2007."

The root of injection vulnerabilities is a lack of input sanitization; when the application receives variable input, there's always the risk of that input being tainted, says Randall Degges, head of developer relations at application security firm Snyk.

"Although this has been an issue since programming existed, the reason it’s still in the top 10 vulnerabilities after all this time is because there are an infinite number of ways to use input, and often time sanitizing input is tricky," he says.

For software developers looking to nix this particular issue, here's how.

**1\. Educate Yourself and Others**

The first step is always education. OWASP offers cheat sheets on SQLi, how to detect the vulnerability, and ways of creating safe code. Some Web application frameworks aim to educate developers while they are programming, using application programming interface (API) names to make the risk of some functions clear, such as React's "dangerouslySetInnerHTML" function, says James Kettle, director of research at PortSwigger, an application security testing firm.

In addition, developers should not necessarily trust the makers of open source software — especially components that have not been well vetted — to use safe code, and online tutorials are often unsafe as well, he says.

"I think the core issue is that there's a lot of unsafe APIs, where anyone using the API is vulnerable by default," Kettle says. "Even when there are more modern secure APIs available, fresh code is written using the unsafe versions, thanks to old unsafe examples in StackOverflow."

**2\. Harden the DevOps Pipeline Using Automated Tools**

Developers should implement unit tests to check code for SQLi flaws — and other common security issues — during development, add static application security testing (SAST) both prior to and after commits, and include scans for SQLi as part of dynamic application security testing (DAST).

Unit tests can be added using frameworks such as tSQLt for testing Microsoft SQL Server, pgTAP for testing applications that use PostgreSQL, and Pytest and SQLAlchemy for unit testing in Python programs. A variety of SQL unit testing best practices should be followed to make the tests more useful, such as isolating the SQL tests from dependencies and avoiding descriptive naming of the tests.

In addition to automated tests in the development pipeline, developers should make sure to use SQL frameworks, such as SQLAlchemy, because many security improvements are already baked in, says Snyk's Degges.

"Pretty much all modern SQL frameworks and tools provide convenience methods to help with this nowadays, so your best bet is to thoroughly read through the relevant framework documentation to ensure you're using it correctly when building queries," he says.

**3\. Play Around With SQLMap**

The open source program SQLMap is a great tool for penetration testers to experiment with SQLi, exploit any potential vulnerabilities, and dump a database to prove that the vulnerability can be exploited. The tool can also educate application developers to the true dangers of SQLi and how vulnerable code can be exploited.

However, the tool is not necessarily the best way to scan for potential vulnerabilities, says PortSwigger's Kettle.

"In my experience, the detection capabilities are slow, heavyweight, and prone to false positives," Kettle says. "Also, it can't explore websites to find the attack surface, which is one of the biggest challenges for finding these vulnerabilities automatically."

**4\. Consider a DAST Service**

Automating SQL injection scanning using DAST as part of the quality assurance stage — and even earlier in the DevOps pipeline, if possible — can help catch any overlooked vulnerabilities. In addition, DAST scanning is a good way to find SQLi in legacy code.

While Web application firewalls (WAFs) can prevent SQLi attacks from reaching an application, they should be used only as part of a defense-in-depth strategy, Kettle says.

"Personally, I've seen runtime protection like WAFs bypassed so many times that I don't have much confidence in them," he says. "I would recommend a bug-bounty program as an effective way to surface undetected vulnerabilities instead, and use WAFs as a last resort for systems that are in such a bad state that known vulnerabilities can't be patched."

**5\. Expand Beyond SQL**

Finally, companies should also look for other types of injection vulnerabilities and make sure their developers recognize risky patterns, since SQLi is only one class of injection vulnerabilities.

OWASP broadened the definition of an injection vulnerability to be any software flaw where user-supplied data is not validated or sanitized by an application and then sent to an interpreter. Cross-site scripting, SQL, operating system scripting, and parsing the Lightweight Directory Access Protocol (LDAP) are all areas that can be vulnerable to injection.

With the advent of artificial intelligence models, for instance, prompt injection is the latest form of an injection attack.

**About the Author(s)**

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

How to Tame SQL Injection

Google has announced the introduction of Device Bound Session Credentials (DBSC).

Google has announced the introduction of Device Bound Session Credentials (DBSC) to secure Chrome users against cookie theft.

In January we reported how hackers found a way to gain unauthorized access to Google accounts, bypassing multi-factor authentication (MFA), by stealing authentication cookies with info-stealer malware. An authentication cookie is added to a web browser after a user proves who they are by logging in. It tells a website that a user _has already logged in_, so they aren’t asked for their username and password over and over again. A cybercriminal with an authentication cookie for a website doesn’t need a password, because the website thinks they’ve already logged in. It doesn’t even matter if the owner of the account changes their password.

At the time, Google said it would take action:

> “We routinely upgrade our defenses against such techniques and to secure users who fall victim to malware. In this instance, Google has taken action to secure any compromised accounts detected.”

However, some info stealers reportedly updated their methods to counter Google’s fraud detection measures.

The idea that malware could steal authentication cookies and send them to a criminal did not sit well with Google. In its announcement it explains that, “because of the way cookies and operating systems interact, primarily on desktop operating systems, Chrome and other browsers cannot protect them against malware that has the same level of access as the browser itself.”

So it turned to another solution. And if the simplicity of the solution is any indication for its effectiveness, then this should be a good one.

It works by using cryptography to limit the use of an authentication cookie to the device that first created it. When a user visits a website and starts a session, the browser creates two cryptographic keys—one public, one private. The private key is stored on the device in a way that is hard to export, and the public key is given to the website. The website uses the public key to verify that the browser using the authentication cookie has the private key. In order to use a stolen cookie, a thief would also need to steal the private key, so the more robust the “hard to export” bit gets, the safer your cookies will be.

Google stated in its announcement that it thinks this will substantially reduce the success rate of cookie theft malware. This would force attackers to act locally on a device, which makes on-device detection and cleanup more effective, both for anti-malware software as well as for enterprise managed devices.

As such, Device Bound Session Credentials fits in well with Google’s strategy to phase out third-party cookies.

Development of the project is done in the open at Github with the goal of DBSC becoming an open web standard. The goal is to have a fully working trial ready by the end of 2024. Google says that identity providers such as Okta, and browsers such as Microsoft Edge, have expressed interest in DBSC as they want to secure their users against cookie theft.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

 Google Chrome gets &#8216;Device Bound Session Credentials&#8217; to stop cookie theft 

Security teams often confuse tool purchasing with program management. They should focus on what a security program means to them, and what they are trying to accomplish.

Source: Panther Media GmbH via Alamy Stock Photo

COMMENTARY

I've had the pleasure of speaking to hundreds of security teams, and the biggest mistake I've seen is that they often mistake tool purchasing with program management, meaning they often think of the tool driving the program, rather the tool being a part of the program. Instead of focusing on the tool, security teams should focus on what a security program means to them, and what they are trying to accomplish. Below, I share insights that can improve your cybersecurity strategy.

**The Misconceptions and Limitations of Cybersecurity Tools**

Not planning a program end to end can lead to failure. Being able to detect something, but doing nothing about it, isn't useful. Too often, security teams fall for the misconception that a security tool is a comprehensive security program. But can we fault them?

Cybersecurity tools are packaged to be appealing: sleek dashboards, integrations, APIs, multiple language support, the promise to find everything. These features give the illusion of a sure bet for security. Security teams buy these tools expecting, then hoping, finally pleading, that their bet will pay off. 

**The Known-Bug Breach**

Organizations routinely need weeks to months to fix a software vulnerability. Even more startling, in a third of security breaches, the pending security fix was known before it was exploited. Why? This often stems from security tickets falling in priority because of the inability to drive a meaningful vulnerability management program and getting stakeholder buy-in. 

**Best Practices for Building Effective Cybersecurity Programs**

The National Institute of Standards and Technology (NIST) defines a security program "as maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions." A security program answers: why this, what to do about it, when, how, and who. It simplifies those answers by forming them into policies and instructions for everyone to follow.

"In my org," a former chief information security officer (CISO) told me, "we didn't greenlight any tool purchasing until a remediation plan was established for the tool." This ex-CISO understands that managing security well is managing the security program, which, in turn, is managing, maintaining, and building a security culture. To be effective, you have to embed the security program in every layer of the business.  

My advice: Before you buy a tool like SAST, lay the groundwork for a security program.

There are so many threat models and definitions out there that it can be overwhelming. Instead, keep it simple to start. Use this tried-and-true formula:

program = tool + people + processes + goals

If you do this, you will avoid the misconception that a tool is a program. These best practices bolster more effective cybersecurity programs that are resilient, adaptable, and capable of remediating bugs. 

In the following two sections, I want to call out two important and often overlooked pieces of this equation that might be misunderstood.

**Stakeholder Engagement in Security Programs**

Stakeholder engagement is crucial to a security program. The vast majority of a security team's success is based on the relationships and buy-in they achieve with key stakeholders, like engineering teams. Forgetting stakeholder buy-in and commitment will fail the vast majority of purchases.

Stakeholder engagement ensures that everyone understands the importance of cybersecurity and eliminates ambiguity. The security program helps every individual understand their role in security and importance in fulfilling that role. In the case of implementing a SAST tool, not having buy-in from your engineering team means you're going to rack up a vulnerability count because you can't act on it. 

**Vulnerability Management **

Vulnerability management is a core component of a strong security program, and generally applicable to most security tools. We've found only the largest of enterprises will hire a dedicated vulnerability manager, and often most organizations don't have someone owning and driving those vulnerabilities.

Vulnerability management involves identifying, assessing, prioritizing, and then addressing vulnerabilities in the system. This is a continuous process that requires regular monitoring and updating. 

For example, in fixing code vulnerabilities from a SAST tool, essential to vulnerability management is remediation and, later, prevention. There is plenty of information about proactive efforts. The big addition I can add here is using cutting-edge tools to achieve rapid maturation for your vulnerability management program — namely, auto-remediation. The recent developments in AI have enabled teams to behave like their counterparts. For example, product managers can now do data science tasks. Additionally, AI is enabling teams to automatically fix vulnerable source code. Security teams can't scale their efforts alone. They need to invest in actions and systems that help them drive programs. 

**Conclusion**

Cybersecurity tools are no replacement for a robust security program. No one buys construction tools and starts building willy-nilly. Without a plan, they'd end up with a chaotic assembly of screwed-in screws, hammered nails, and sawed boards. That isn't productivity. It's busywork. Sadly, a tool without a robust plan behind it can go the same way. A security program assures that security tools are effective and deliver value for your organization — and, ultimately, increase the security of your organization.

**About the Author(s)**

Founder & CEO, Corgea

Ahmad Sadeddin is the founder and CEO of Corgea. A three-time startup founder and product leader, he's worked on building and scaling software products for over 15 years. Securing software products was always a challenge, so Corgea was born from his frustration at the manual and inefficient processes to remediate security issues. Corgea automatically fixes insecure code.

Tag

#auth