Gain Deeper Visibility into Risks to Meet Security Compliance Demands

If you can’t see a risk or vulnerability, you can’t take steps to reduce or remediate it — and you can’t show regulators that you’re on top of the issue. However, visibility is a common challenge among cybersecurity teams. 

A 2024 Forrester study found that more than half (52%) of financial firms agree/strongly agree that they lack full visibility into their IT estate. The stakes of noncompliance are high for any industry. The number of organizations paying more than US$100,000 in regulatory fines jumped nearly 20% between 2023 and 2024.

In the first blog post in our compliance series, we made the case for mapping regulatory compliance efforts to a layered security approach. Taking a proactive approach to filling visibility gaps can help you meet security compliance requirements for:

• Demonstrating your controls
• Performing risk management assessments
• Reporting for audits

In this post, we’ll explore visibility issues that organizations struggle with in terms of network security and API protection — and discuss layers that organizations can add to bolster their compliance. In the end, great security measures can help you meet regulatory requirements. And if you see a risk, you’re in a much better position to mitigate it.

We hear from cybersecurity leaders that their teams lack capabilities for monitoring network traffic effectively, and, therefore, can’t see risk factors such as which assets are communicating with one another. This is critical for regulations such as the Payment Card Industry Data Security Standard (PCI DSS v4.0) and the General Data Protection Regulation (GDPR). 

Both of these mandates require separating in-scope data from other systems in an IT environment, and reporting on your efforts. Network visibility is also key for information security management systems (ISMS) standards such as the International Organization for Standardization (ISO) IEC 27001, which requires segregating data and data processing facilities to avoid lateral movement in the event an attacker breaks into the network.

Organizations often have baseline layers in place for visibility; for example, traditional network firewalls can offer some insights. But these layers haven’t kept pace with enterprises’ move to a complex IT estate comprising cloud environments and microservices. As a result, security teams lack the ability to:

• Ensure compliance with various mandates’ requirements across myriad geographies where an enterprise operates, sells, and/or uses third parties

• Gain a clear sense of how applications and end users communicate and engage with databases throughout the networks

These visibility gaps make it difficult to show regulators how your enterprise is detecting cyberthreats and safeguarding against attacks that can lead to stolen data, disrupted operations, and malware. Poor visibility also makes it difficult to meet technical requirements, such as PCI DSS v4.0’s Requirement 1, in which firewalls must be configured to restrict connections between trusted and untrusted networks.

One way to solve the visibility gap in network traffic is to add a layer of software-defined microsegmentation for visualizing, monitoring, and identifying communication among assets in the network. This approach provides:

• Granular control over network interactions, and helps organizations understand, isolate, and prevent illegitimate network traffic among devices within a specific data center (i.e., east-west traffic) across complex networks that span on-prem and cloud

• Capabilities to mitigate and contain ransomware attacks by dividing a network into segments in which security controls can be defined for each segment’s risk attributes

• Enhanced east-west visibility, so security teams can better see “who can access what” in terms of sensitive resources such as customers’ credit card data

As you consider which microsegmentation layers your organization can use to improve network visibility, look for capabilities that offer real-time and historical insights. This enables attestation during compliance audits to prove that in-scope data and assets have not been compromised.

We also know that some security teams struggle to gain visibility into their fast-growing API estates. Every time a customer, partner, or vendor electronically engages with an organization, APIs are transmitting data behind the scenes, and that data is often sensitive. Today’s threat actors know that APIs are highly vulnerable — and relatively easy to breach — because of factors such as misconfigurations, poor authentication controls, and coding errors.

Many organizations can only see a portion of their overall IT estate because so many of their APIs live in the shadows and aren’t detected by traditional API protection tools. According to our 2024 API Security Impact Study, only 27% of security professionals who have full API inventories actually know which of their APIs return sensitive data — down from an already-concerning 40% in 2023.

Filtered by industry, we see even lower visibility into which APIs will provide sensitive data in response to requests, whether they’re from legitimate users or attackers.

• Healthcare: only 24.0% of APIs
• Insurance: only 20.7% of APIs
• Government/public sector: only 18.5% of APIs

Let’s use the healthcare industry as an example of what’s at stake: If a threat actor can easily manipulate a provider’s misconfigured API to retrieve patient records, that manipulation can lead to HIPAA scrutiny and fines.

In some regulations, APIs get explicit mentions. For example, the PCI DSS v4.0 contains guidance to confirm that an organization’s software securely uses the functions of external components. This includes APIs that transmit payment information such as credit card data from a mobile app to a bank’s system. 

In other instances, APIs are not mentioned by name, but the requirements clearly focus on securing the technologies that rely upon APIs to function. Take, for example, the European Union’s Digital Operational Resiliency Act (DORA), which is designed to help financial services organizations in EU member states withstand and recover from cyberattacks.

DORA Article 3 requires organizations to use information and communication technology (ICT) solutions and processes that:

• Minimize data-related security risks, unauthorized access, and technical flaws

• Prevent data unavailability, data loss, and integrity and confidentiality data breaches

• Ensure data transfer security

An API’s primary function is to facilitate a ‌fast, reliable, and secure transfer of data. Therefore, discovering, performing risk assessments for, and securing every API that touches enterprise data is essential for meeting DORA requirements. 

These controls will also help improve compliance for PCI DSS, GDPR, and a host of mandates designed to ensure cyber resiliency and data security. If you’re thinking about adding layers to improve your visibility into APIs and their risks, here are some capabilities to seek out:

• The ability to discover every API in your IT environment, managed and unmanaged, including zombie and shadow APIs

• The ability to assess each API’s risk factors (e.g., the types of data it has been exchanging, and who or what can access that data)

• The ability to visualize contextual insights to identify risks such as data leakage, suspicious behavior, malicious bots, and API attacks

• The ability to document data flows 

• The ability to generate compliance reports that map an enterprise’s API security posture to regulatory standards

To wrap up, we believe that complying with information security compliance frameworks and regulations calls for a layered approach rooted in protecting various areas within the attack surface.

Look for future posts in this series that will cover best security practices that are directly linked to what today’s regulators are demanding for security compliance management. This includes preventing lateral movement across the network, applications, and APIs.