API Security

Apigee Sense Protection: Act on Threats to Your APIs

Our customers expose critical business functions via APIs, so API security is a significant concern. They want the ability to take action without delay when APIs are abused. Apigee Sense collects, analyzes, detects, and provides a dashboard showing abuse of APIs managed using Apigee Edge.

The Sense Protection feature completes the “CAVA” (collect, analyze, visualize, and act) lifecycle. It enables an Apigee Sense customer to act on detected abuse and to selectively stop abusive API traffic.

Why did we do this?

The protection feature represents significant progress within the Apigee API platform, and an important step in our effort to deliver data-driven API management. It shortens the lifespan of an attack and decreases the operational cost of dealing with one. Consequently, it reduces any economic incentive to mount automated attacks on APIs.

 

How did we do this?

As part of this feature, we added the ability to trap and shape API traffic to Apigee Edge. As a Sense customer, you’ll now see an “Act” button whenever an attack is detected. Clicking on it will bring you to a quick workflow that will enable you to block traffic from the identified attacker, and, if you choose, other similar bots.

Every API call passes through a pre-proxy Apigee Sense layer. The logic checks whether the call originates from a host that’s been blocked. If this is the case, then the rest of the chain is aborted and an HTTP 403 response is returned. Otherwise, the call continues on to the normal execution path.

In addition to blocking, we also offer the capability to flag API calls. A flagged call is passed on to the back-end system with an additional header field.

The challenge is in keeping the large blacklist across all the orgs that we service updated and current across our distributed API serving infrastructure. To ensure that we don’t add any significant latency to the API call path, this blacklist check has to be done in an entirely “local” way.

To do this, we cache (and actively refresh) a segment of the blacklist on every message processor. The choice of the segment is coordinated with the routing infrastructure so that each segment of the blacklist is available where it will be needed and only where it will be needed.

We have also built an internal service that maintains and serves the blacklist segments to the API gateway. It’s our intention that over time, this service will provide the additional context necessary for each API call. For example, it provides the state machine for slowly switching traffic from one version of logic to the next during a deployment cycle while continually monitoring availability data.

Data-driven improvements

Our vision is that eventually a lot of system change and the context for managing API calls will become data-driven and be mediated by the services we’ve built to enable Sense and Sense Protection.

This means that Sense Protection activity takes place in a separate path, outside of the proxy handling workflow of Apigee Edge. The deployment for protection is independent of that of the API proxy. Therefore, any change to the API proxy doesn’t compromise the ability to act against any attacker, and a change to the protection logic will not change the essential behavior of the API proxy.

Finally, blocked traffic never hits critical logic in the API handling path and, nor does it cause any back-end load. Because of this, any customer with blocked robot traffic will see an improvement in performance both at the API and, more importantly, within their back-end systems due to the reduction in traffic that had been generated by those abusing the API.

Learn more about Apigee Sense. —Harish Deshmukh, Prithpal Bhogill, and Vibhor Sonpar contributed to this post.

 

You're Thinking Cloud, But Not APIs? Seriously?

The principles of cloud computing might be decades old, but it wasn’t until 2006, when Amazon entered the cloud market, that the modern cloud era really began. Like the processor virtualization market a decade earlier, cost, benefit, and flexibility are providing the basis for an ever-increasing pace of enterprise cloud adoption.

Cloud is ultimately about three things:

  1. Building cloud native applications that scale

  2. Moving and modernizing existing applications

  3. Repartitioning your enterprise architecture flexibly between public and private clouds and operating all clouds as one

But if you’re not thinking about APIs as you embark upon your cloud journey, you’re thinking wrong.

Build for the cloud

Cloud is about self-service It’s about your developers (and you) not standing in line for resources. How is self service delivered? APIs, of course. IaaS APIs, PaaS APIs, and service APIs.

Cloud is about agility It’s about your developers (and you) not standing in line because of dependencies on other teams. How is this independence delivered? APIs, of course. Microservices APIs.

Cloud is about scale It’s about your application breaking free from the limits of a single VM.  How is this liberation achieved? APIs, of course. PaaS APIs.

Cloud is about a set of services It’s about services that you consume so that you can focus on your value-add. How are those services delivered to you? APIs, of course. Others make their services friendly through consumption-centric APIs.

Cloud is about serverless It’s about writing code and letting the cloud run it. How is the code run? APIs, of course. You build your logic, provide an API to it, and enable it to be used by everyone else.

Move to the cloud

Cloud is about moving key applications It’s about apps and workloads that seamlessly move to the cloud and can be modernized easily. How do you move applications? APIs, of course. You wrap your key application with APIs and route calls transparently to the right location.

Cloud is about modernization It’s about growing your business through new digital use cases.  How is this modernization achieved?  APIs, of course. You make your services developer-friendly through consumption-centric APIs.

Cloud is about no lock-in It’s about enabling applications to move to the best provider. How do you enable this optionality? APIs, of course. Applications and key components powered by APIs enable free movement between clouds.

Operate all your cloud assets uniformly

Cloud is about security It’s about ensuring that your applications, irrespective of location, are more secure than ever. How do you achieve this security? APIs, of course. When APIs power your key applications, your applications are more secure, because your security architects can see, manage, and control all of them without compromising the agility of your developers.

Cloud is about cost It’s about applications that deliver value getting more resources. It’s Darwinism in your application landscape. How do measure value? APIs, of course. Analytics on APIs helps you understand the usage and decide which location and resources make sense for each particular application.

Cloud is about operations It’s about applications residing wherever they do, but operating as one. How do you operate everything as one? APIs, of course.  APIs that manage the applications, the infrastructure, the network, the services.

Don’t think of cloud with one eye shut

Cloud is central to your business. But why handicap yourself? Think APIs in the same breath as thinking cloud.

Why Enterprise Security Needs APIs

From time to time, we will have guest authors weigh in on specific topics here. While I’m  interested in all topics, and have opinions on almost all things related to APIs and data :), sometimes it’s better to let the experts have a say. So here is a first guest post. This topic is especially important because by now people realize that digital transformation requires APIs.  And we know that APIs require security. But does security need APIs? I discussed this in a previous post; here's the first in a series of  posts that elaborates on the topic.

Enterprise security incidents surged by 38% last year and malicious attacks on enterprise data continue to have significant impact, incurring a cost of over $500 billion today to an estimated $2 trillion by 2019. Enterprises are adopting APIs and API facades to secure access to valuable enterprise data from both internal and external users and apps.

Although many new apps use REST APIs, many enterprises still employ web applications that make direct calls to backend systems. To date, enterprises have used a layered security model to thwart external threats at the app layer. By mandating the use of APIs to access critical enterprise data, enterprises can create effective security control points and gain several security advantages.

Smaller attack surface

Today, when there’s a security breach in an application, all the backend systems that provide data to the app can be exposed. By ensuring the apps only use APIs to access data on backend systems, you can automatically restrict access to a smaller set of resources and data by passing the requests through an API gateway. This minimizes the attack surface should a breach occur.

Smaller attack window

Web apps that use simple usernames and passwords are challenged to securely store these credentials. Rotating them frequently is also difficult and therefore rarely implemented. In the event of a compromise, the enterprise is severely exposed as there is no time dimension to the credentials (they don’t generally expire).

By using APIs and OAuth, you limit the opportunity for attackers by using continuously rotating credentials that expire frequently.

Defense in depth

By using API management, enterprise security teams can deploy an effective, layered security framework. You can enforce a set of security policies across all your enterprise APIs (spike arrest and injection threat protection, for example) and, if required, enforce additional security policies, such as OAuth2, on select APIs.

Think of an API management platform as the internet-exposed layer of your applications environment that provides a defensive capability in front of your backend systems. 

Versioning

With APIs and API management, you have the flexibility to downgrade or upgrade your API versions seamlessly as part of remediation efforts against security breaches. You can also roll out new API versions to select audiences before wider rollout to minimize security risks.

Virtual patching

An API management platform enables virtual patching and quick remediation against an identified vulnerability in a downstream system without having to change the source code of the system. By applying new security policies to limit potentially malicious input in the API gateway, you can significantly mitigate the impact of zero-day exploits and unpatched systems.

Security metrics

Most enterprises have limited visibility into the vulnerabilities of apps accessing your enterprise data. With APIs and API management, you automatically gain granular visibility into which backend systems are accessed insecurely.

API analytics provide traffic visibility that enables an enterprise to discern between bot traffic and legitimate traffic, transport layer security (TLS) versus non-TLS traffic, and authenticated versus unauthenticated requests. Security metrics like these enable you to fix vulnerabilities and improve overall application security.

By mandating the use of APIs to access any critical enterprise data, you create effective security control points and your enterprise assets become more secure. Enterprises that are going digital and are concerned about their assets should consider an API-first approach to their digital transformations.

Coming up, we’ll take a more in-depth look into the benefits of using APIs to secure enterprise data.

APIs: The New Security Layer

Webcast replay

APIs provide both an extraordinary opportunity for building engaging customer experiences and for strengthening your relationship with key business partners. But they also provide potential openings for savvy hackers to get unauthorized access to customer data and perhaps even to compromise your key business systems.

In this webcast replay, Apigee chief architect Greg Brail discusses:

  • API security fundamentals
  • how to proactively watch for trouble
  • protection and mitigation strategies to keep your customers and your business safe

 

 

Security for APIs, or APIs for Security?

How many times have you driven away from your house wondering if you remembered to lock the door? Personally, I have turned my car around to check more than once, and my neighbors have gotten calls asking to check at least twice.

Our home is our prized asset. We need a door to allow friends and family to come in and out, but we also want to make sure that unwanted guests can’t enter. So we put a lock on the door — yet still we worry.

APIs as intelligent doors

APIs are like the doors to your enterprise assets. The purpose of the digital transformation most of today’s enterprises are undertaking is to have new use cases built around their most differentiated assets: their physical stores, content, and data.

Putting these assets on total lockdown does your enterprise no good. If your assets are in Fort Knox, what customer would actually go through the trouble of using them? What you want instead are intelligent doors (APIs) that open up the right assets for the right people, whether it’s the developers inside your company, trusted partners, or third developers building on your platform.

Because APIs are such a critical part of any digital strategy—and because a lack of API security would bring the digital revolution to a grinding halt—everyone using APIs puts a lot of emphasis on securing them. But how do you actually go about securing an API?

APIs as contracts

For this part of the discussion, it’s helpful to think about an API as a contract for accessing a particular door. Because an API is a contract, it is possible for the organization that offers the API to completely document and understand the interaction between the application that uses the API and the API itself. This contract-driven interaction model makes it possible for the organization that provides an API to add policies and security controls at every interaction.

An API team can therefore regulate which applications and end users are authorized to use an API and which parts of the API they are allowed to use. The team can also control what an authorized user can do, including limits on the number of API calls that can be made, or when they can be made. Finally, the team can follow the trail of API calls to understand exactly what authorized API users did, and what unauthorized attempts may have been made.

As a result, APIs, rather than presenting a new security risk, provide a well-documented and popular way for organizations to share access to data and services internally and with third parties, while also maintaining strict security controls.

APIs for programmatic access

Compared with the other ways enterprise data is shared—via a web site, file transfer, email, or even a printing press—a well-implemented API offers a far stronger set of security controls.

APIs are different because they are designed from the ground up to do only one thing, and that is to provide programmatic access to developers who code applications. Well-implemented APIs ensure that only authorized end users and applications can: access your enterprise assets; control the amount of API traffic that can be generated; ensure that API traffic does not contain malicious content; and even audit all traffic for later analysis and risk mitigation.

In other words, by creating intelligent doors, and by putting the right locks on them—and, over time, shutting off other, less secure existing windows and doggie doors—your enterprise assets become more secure.

If you are an enterprise going digital and you are concerned about the security of your assets, it’s time to consider an API-first approach to digital transformation.

Image:Arthur Shlain/The Noun Project

Security in the Digital Age: Deep-Dive Webcast

What are the biggest cyber threats facing financial and healthcare entities today and in the near future? How can organizations embrace innovation and agile development culture while balancing the time to market goals with risk management?

Join Jason Kobus, director of API banking at Silicon Valley Bank, and Apigee's head of security Subra Kumaraswamy in this webcast replay as they discuss how an effective API program, combined with a secure API management platform, can:

  • provide visibility for all security threats targeting their backend services

  • control access to sensitive data, end-to-end

  • enable developers to build secure apps with secure APIs

  • facilitate secure access with partners and developers

 

Industrial-Grade Data Security for Agile Development

Data breaches are making headlines on a seemingly weekly basis. With hackers exposing and exploiting millions of consumer records, data security has taken center stage among security leaders and enterprise architects. It’s a crucial time for organizations to reassess their data security architectures and risk profiles.  

The goal of every security and compliance manager should be to implement a secure-by-design pattern where all sensitive data—both in transit and at rest—are secured.

A primary reason data breaches occur: organizations lack strong data protection measures such as encryption, hashing, and tokenization, and they lack strong access control models that limit sensitive data access to authorized users. Often, they also don’t secure the cryptographic keys that are employed for data protection.

It happens over and over again: hackers get their hands on sensitive data by accessing cryptographic keys that aren't safeguarded with hardware-based encryption systems such as hardware security modules, or HSMs.

HSMs: more secure than software encryption

HSMs are physical network devices, sometimes in the form of a plug-in card that attaches directly to a server. They’re a cornerstone of digital security roots of trust, and ensure that keys are protected inside a hardened, tamper-resistant device. HSMs are considered more secure than software-based encryption systems, where keys are stored in the software.

Unlike software-based cryptographic systems, an HSM-based system is not vulnerable to attacks that target operating systems and applications that store and manage cryptographic keys within the software elements.

Balancing security with self-service

Organizations handling data security often grapple with trying to implement strong security control without creating too much complexity.

So how can developers continue to be agile and innovate their next mobile or IoT app while protecting sensitive data? Developers prefer self-service and easy-to-use APIs to help build engaging apps and experiences. But the majority of the developers aren’t trained in secure design and coding practices and don't possess the skills to develop the industrial-grade cryptographic systems required to support an organization’s data protection needs.

Successful IT organizations understand that good security can be achieved when developers consume security-as-a-service in the form of APIs. This makes it essential for organizations to choose an API management platform that is not only capable of supporting strong security controls such as HSM, but also can abstract and hide complexity from the developers who consume APIs that handle sensitive data.

Where are your keys?

Developers interacting with Apigee Edge, for example, can store and manage the cryptographic keys in a secure way using a commercial HSM module. What are the typical keys used by the platform when protecting sensitive data that crosses the trust boundary?

  • Keys that authenticate and encrypt two-way SSL/TLS sessions
  • Keys that encrypt XML/JSON payloads when dispatched to a destination service
  • Keys used for signing REST payloads

In all the these cases, cryptographic keys should be stored in HSMs offered by the likes of Safenet, Thales, or Amazon’s AWS CloudHSM, and should be governed by strong access control.  

Improve adoption, embed security, quell breaches

Any enterprise data protection strategy and architecture must consider strong cryptographic systems to help protect sensitive data. Data protection using HSM is a recommended approach for organizations dealing with customers' personally identifiable information (PII) or sensitive or regulatory data—such as financial institutions, healthcare organizations, and government agencies.

And when the protection mechanisms and configuration are made available to developers via APIs, it improves developer adoption of security and automatically embeds security into applications. While these measures alone don’t guarantee absolute data security, they can make security breaches far less likely.

For more on API security, check out the webcast replay, "How to Achieve Agile API Security."

Photo: "T"eresa/Flickr

The IRS Breach and the Importance of Adaptive API Security

The recent Internal Revenue Service data breach, which used the “Get Transcript” API to access the agency’s data, highlights the increased sophistication of cyber attacks that aim to profit from taxpayers’ personal information. The API in question was used by the IRS’ browser-based app to remotely access IRS systems and was implemented to deliver line-by-line tax return information, account details (marital status and income adjustments, for example), and wage and income statements.

In the United States, tax data is very valuable to cyber criminals, as it can be abused to receive phony refunds (this kind of fraud costs the U.S. approximately $6 billion annually) and commit mortgage fraud, identity theft, and other crimes. The IRS wasn’t able to detect and block this latest attack because its back-end application was authorizing users using personally identifiable information (PII) such as social security numbers, which can be gathered through other channels, phishing attacks, or from black markets that sell PII data. So the agency’s intrusion detection system wasn’t able to distinguish a legitimate taxpayer access request from a fraudulent request.

The trouble with knowledge-based authentication

The IRS could have employed stronger authentication schemes, such as two-factor authentication using smartphones, but this entails higher implementation and support costs, and can potentially impede user adoption due to a degraded user experience and a lack of phone capabilities such as SMS. Instead, the IRS used a simple authentication mechanism that has a very low barrier to adoption. Unfortunately, it also made it much easier for bots and cyber criminals to steal taxpayer data, and it did so with a 50% success rate.

So how do you verify that the user who claims to be John Doe is indeed John Doe, when your mode of authentication is a simple username and password combination? Is combining this with an additional layer of authorization based on user attributes such as knowledge based user attributes enough to keep cyber thieves at bay?

The short answer is “no.” This type of knowledge-based authentication is becoming less relevant in today’s world, where the knowledge is no longer a secret. It has become pretty easy for cyber criminals to dig up relevant PII and assume a taxpayer’s identity.

So how can organizations protect their crown jewels while making it easy for users to access their data or transact in a secure way? How can you instill confidence and trust in consumers who are eager to access government, commerce, financial, and healthcare services using smart phones and personal computers?

The adaptive security approach

Organizations have to adopt an adaptive security approach—one that learns consumer behavior and automatically detects and blocks any cyber criminal or bots that may have gained access to consumer usernames, passwords, and other personal attributes used for knowledge-based authentication.

Using machine learning and statistical models, an adaptive security system constantly learns “good behaviors,” which helps it distinguish”bad behaviors” and enforce dynamic policies that block bots from accessing a protected resource (the web, an API, or a datastore).

Bad behaviors manifest in the form of anomalous activities, including:

  • Systematic walk-throughs of the application resource paths by bots

  • Requests originating from a bot network or low-reputation IP address or ISP or compromised proxies and devices (rooted Android devices or PCs with malware, for example)

  • High rates of access from certain IP addresses or end points

  • High rates of access to URIs (resources) that are infrequently accessed by end users (password or home address changes, for example)

  • High rates of form submissions with slight variations in the input parameters (bots using brute force techniques with authentication API calls using random user IDs, for example)

  • High error rates on access to resources, especially those that are available to privileged users or applications

Gaining visibility into API access anomalies by way of bot activities is an important consideration when implementing API security and fraud protection program. Bots, also commonly referred to as content scrapers or spiders, are increasingly targeting retailers, e-commerce service providers, and anyone who has valuable content.

Studies show that bot activity represents more than half of overall Internet traffic. Bots are known to target retailers with dynamic pricing, loyalty programs, financial services, services with copyright materials, and intellectual property such as visual designs. They can have a major load impact on a website and API backend infrastructure, create performance headaches for operators, and hurt a company’s brand and bottom line due to content theft or competitive information scraping.

Advanced API analytics 

At Apigee we’ve implemented an adaptive security system using the advanced API analytics capabilities of the Apigee Edge API management product and our Insights predictive analytics product. This advanced analytics functionality provides our customers visibility into bot activities or brute-force attacks against APIs using stolen keys or user account details.

For example, if an API key is breached and abused by hackers to access the APIs in an unauthorized fashion, the bot detection system will detect the anomaly and flag the end points as bots.  Furthermore, a full bot protection architecture can be implemented in Edge using an API that automatically imports blacklists from the bot analytics system. Using this closed loop mechanism, bots can be blocked or throttled by Edge, protecting the origin servers from bot traffic.

This adaptive API security system is designed to protect consumers and enterprises to thwart dynamic threat vectors that are hard to detect otherwise using static policies.

In summary, an effective API security program requires a layered security approach that combines traditional security controls (authentication, authorization, auditing, encryption, and threat protection) with an adaptive security control that continuously learns and protects APIs from malicious bots. Organizations that invest in the adaptive security approach protect their brand image, reduce fraud and content theft, and safeguard their customer data from malicious bots on the internet.

API Security Deep Dive (webcast & podcast)

Threat protection and application access controls are key security mechanisms that protect APIs when exposed to internal or external users and developers.
In this technical deep-dive webcast, Apigee's Subra Kumaraswamy and Chris Von See discuss API threats and the protection mechanisms that every API and app developer must implement for safe and secure API management. 
This webcast covers: 

  • the API threat model 
  • how to design and implement appropriate guardrails for API security using built-in policies and configuration 
  • a demo of Apigee Edge threat protection features, including TLS encryption, XML/JSON/SQL injection attacks, and rate limiting 

Whether you're an IT security architect or an API or app developer, this webcast will help you understand secure API management. 

 

API-First Security: Don't Build Your Own Maginot Line

The Maginot Line is remembered as one of history’s most costly strategic blunders. France’s massively complex, heavily fortified, and expensive 940-mile line was built before WWII to keep Germany at bay. But France’s foes simply skirted the fortification via Belgium, and conquered France in six weeks.

The Maginot Line failed because it wasn’t designed to counter the newer threats and tactics employed by Germans at that time; it wasn’t flexible enough to adapt to new, nimbler threats.

The Maginot Line (image: Wikimedia.org)

Digital security strategies can exhibit a similar weakness, as they’re not designed to adapt to new and unexpected threats (the Heartbleed vulnerability is a good example).

Omnichannel security

A typical enterprise has hundreds of business applications hosted in private or public clouds that interact with their users (customers, partners, and employees) spread across geographies and time zones. These interactions take place via a variety of channels: web, mobile, APIs, VPNs, cloud services, and sometimes via contactless payment terminals supporting Apple Pay.

As a consequence, enterprises need to plan for an omnichannel user engagement model that provides a consistent user experience, with security and privacy built into all channels. And it should be supported by a security architecture that’s responsive enough to enable enterprises to prevent, detect, and react to newer threats, in near-real time.

The problem with bolt-on security

One way to achieve this outcome is to secure each channel independently using point solutions. This approach usually involves a bolt-on security model, in which the protection mechanism addresses specific threats for individual channels—securing mobile apps using a custom authentication without OAuth, SSO (Single Sign-on), and support for federated identity store, for example.

With this approach, a business won’t be able to support new security requirements as user engagement moves from a single channel to multi-channel mode. And, from the perspective of the chief information security officer, a channel-specific security approach may provide the Maginot Line-like perception of strong fortifications, but won’t be able to withstand new threats that blend across channels. Ultimately, the channel-specific security strategy leads to security weakness, with inconsistent user experiences across channels.  

API-first architecture

An effective digital security strategy and architecture that adapts quickly to new threats can be realized by building on an API-first architecture. In this model, every mobile, web, and IoT device interacts with business applications via APIs. An API-first architecture facilitates interactions within and across channels via an API tier that’s distributed to scale with user engagement. By building security into the API tier, an enterprise can enforce a consistent protection mechanism across all channels.

One of the advantages of API-first architecture is the ability to expose APIs as “products” with built-in authentication, authorization, and threat protection. API products enable the right level of security for users, irrespective of the channel through which the interaction takes place.

For example, a "private" API product can expose private APIs which support SSO for employees using a corporate active directory, while a "public" API product supports SSO using a federated or social identity. As a result, you can manage security across channels in a very consistent way while preserving the agility of the business units exposing different sets of APIs.

 
Screen Shot 2015-04-07 at 1.02.28 PM.png
 

API-first security principles

Every enterprise should follow API-centric security principles, as they are a critical part of an API-first architecture:

  • Expose your APIs as API products with fine granular access control built in. Your mobile app designed for users of your public API product can support social logins, such as Facebook. A mobile app designed for your employees using a private API product may use your corporate directory for authentication and authorization needs. Both products should support OAuth and authorization scope to limit access to different sets of APIs.

  • Always configure security; code only when absolutely necessary. Using the API product approach, you can configure security policies that support authentication, authorization, and threat protection that persist across channels. Security configuration provides a better experience for developers and helps developers adapt security features faster. Threat protection features such as rate limiting and OWASP Top-10 Injection protection act as a defense layer for all channel interactions. But you’ll still need the option to code security for cases where configuration may not be an option. For example, you may need to query your internal SIEM (security information event management) system for malicious sets of IP addresses (black lists) and block the threats across all channels.

  • Log all API interactions across channels to get an end-to-end view of user, device and app activities. This approach helps provide correlations of user activities across all channels and identify any abnormal behavior that deserves investigation. API analytics can provide insights into traffic spikes from certain devices, apps, IP addresses, or geographies.

  • Always layer API security with other controls for a defense-in-depth strategy. Be sure to employ additional access protection between apps and API services. An example: using IP-based whitelisting and two-way SSL/TLS in addition to OAuth-based security.

Remember, build your apps and services upon an API-first architecture that’s resilient and adaptive to new threats. An API-first architecture enables consistent security policy enforcement across channels while improving user engagement and developer productivity.

With an API-first architecture approach, you can avoid the digital Maginot Line, where hackers exploit the weakest channel and create a costly data breach response situation for your organization.