Why Insurers Need Visibility Into APIs Risks
Akamai acquired Noname Security in June 2024. The Noname Security product is now Akamai API Security, but this archived blog post reflects the product and feature names on the original date of publication.
Why is API security crucial for insurance companies? Consider what happens when disaster strikes, from an unfortunate car accident to damaged business equipment. Policyholders rely on mobile apps and online portals that collect information, open claims, and process them through automated workflows. Behind the scenes, an insurer's APIs handle what amounts to a policyholder's life story told in the form of data. These APIs exchange:
Sensitive details on people’s health, homes, families, vehicles, and valuables
Personally identifiable information (PII) and payment data linked to bank accounts
Data on employees, properties, and legal matters, for businesses with policies
This proximity to data is what makes APIs a significant risk. Threat actors know that APIs provide a fast, direct path to a company's data. APIs often go into production with misconfigurations, lax authentication controls, and unintended exposure to the internet — all of which an attacker can easily exploit.
Why protecting APIs is challenging for insurance companies
In working with insurers, I've noticed a few trends that make it challenging to protect APIs.
Continuous API sprawl: With every digital initiative, APIs proliferate and constantly evolve, version after version, making it difficult to keep an accurate inventory.
Inconsistent standards: Many insurers have multiple development teams operating in silos across business units — and they don't use a central playbook for secure design.
Unseen risks: The main function of APIs is to transmit information, and yet only 4 in 10 organizations know which of their APIs return sensitive data.
In this blog post, I’ll explore the importance of API discovery, inventory, and risk assessment for insurance companies. I’ll also delve into two real-life scenarios in which Noname helped insurance companies identify and mitigate API-related risks.
The significance of API discovery and risk assessment for insurance companies
Think of APIs as the peripheral nervous system of an insurance firm's digital infrastructure. The average enterprise has between 15,000 and 25,000 APIs, depending on its size. On a nonstop basis, these APIs facilitate fast, seamless information sharing between the technologies that policyholders rely on for critical services.
Discovery and inventory
Insurance companies must have a comprehensive understanding of their API landscape to maintain control over their digital ecosystem. API discovery and inventory provide real-time visibility into the APIs in use, including legacy and unmanaged APIs. This enables organizations to identify potential security gaps, vulnerabilities, and misconfigurations that can go unnoticed.
Risk assessment
Conducting risk assessments for each API allows insurance companies to identify and prioritize potential risks. By understanding the data handled by each API and assessing its security posture, organizations can implement appropriate security measures to mitigate risks effectively. This proactive approach helps prevent data breaches, unauthorized access, and other security incidents that could lead to reputational damage and financial losses.
Real-life scenarios: How Noname helps insurers identify and address API risks
Expired tokens
During a discovery session with an insurance company, we identified an API that accepted an expired token. What's more, we found that the API returned sensitive information when called.
You might think, "Okay, it accepts an old token, but how would an attacker ever find the token or determine what resources it leads to?" In some cases, not exclusive to insurers, API developers post a wide range of authentication tokens to internet repositories where they exist like public documents. What could happen to an exposed API token? Two outcomes come to mind:
If the service accessed by the API key contains sensitive or personal data, exposing the key could lead to unauthorized data access or data breaches.
Malicious actors could also use the API key to overload an application, like an online claims tool, causing a denial of service and delaying policyholders from getting help.
In either case, such attacks could lead to eroded trust with policyholders. Fortunately, our contacts at the insurer were proactive, security-minded experts who knew this issue was about more than products; it was about people and processes. They met with a group of developers who explained that they intended for the API to remain in a testing environment, where the risks of accepting expired tokens were low.
What they didn't realize was that the in-production version of the API had the same lax authentication controls. So the security team implemented policy changes and enforced stricter practices for authentication, preventing potential data breaches and unauthorized access to sensitive policyholder information.
Older, unauthenticated versions
In another engagement, we discovered an older unauthenticated API within an insurance company's digital ecosystem. This earlier version of the API, which had been superseded by a newer authenticated version (V4), still returned sensitive data without any authentication requirements.
The insurance company was under the impression that the older version was decommissioned. Fortunately, the company's security team acted quickly. Similar to the previous example, our discovery led to an important policy change.
Both stories underscore the notion of API security being a team sport. Everyone has a key role to play: CISOs, enterprise architects, developers, and more.
Best practices for stronger API security for insurance companies
Poor visibility into APIs and inconsistent processes are widespread issues. Often, the API development workspace isn't even centralized. Developers are building APIs across multiple cloud service providers, often outside the enterprise security team's view, in addition to being siloed into business units. Many of these APIs aren't deployed through the company's API management solution, where they would at least receive basic protections like rate limiting and authentication.
Even commonly used API management tools can't provide the level of protection and visibility that insurance companies need. For example, API gateways and web application firewalls (WAFs) can only capture managed API traffic and thus cannot see or secure the vast number of unmanaged APIs that are developed and released, including shadow APIs and zombie APIs. Additionally, APIs may not be tested against common API attack methods, depending on which business unit is designing them.
The 4 pillars of API security
Today's threat landscape calls for a comprehensive API security approach encompassing four critical areas: API discovery, API posture management, API runtime protection, and API security testing. These four core capabilities can help an insurance company protect its APIs and, in turn, the sensitive data they exchange, including:
API discovery
API posture management
API runtime protection
API security testing
1. API discovery
Many organizations lack visibility into a significant portion of their API traffic. Without a complete and accurate inventory, your enterprise is exposed to a variety of risks. Here are some core API discovery capabilities that can help:
Locate and inventory all your APIs regardless of configuration or type
Detect dormant, legacy, and zombie APIs
Identify forgotten, neglected, or otherwise unknown shadow domains
Eliminate blind spots and uncover potential attack paths
2. API posture management
To protect policyholder data effectively, it's crucial to have a complete inventory of APIs and understand the types of data flowing through them. Organizations can start with the following API posture management best practices:
Automatically scan infrastructure to uncover misconfigurations and hidden risks
Create custom workflows to notify key stakeholders of vulnerabilities
Identify which APIs and internal users are able to access sensitive data
Assign severity rankings to detected issues to prioritize remediation
3. API runtime protection
To protect APIs in production, it's essential to detect and block attacks in real time. This is where API runtime protection is essential. Here are some examples of controls to implement:
Monitor for data tampering and leakage, policy violations, suspicious behavior, and API attacks
Analyze API traffic without additional network changes or difficult-to-install agents
Integrate with existing workflows (e.g., ticketing, SIEMs, etc) to alert security teams
Prevent attacks and misuse in real time with partial or fully automated remediation
4. API security testing
API development teams feel the pressure to work as quickly as possible. This need for speed makes it easier for an API vulnerability or design flaw to occur and go undetected. Here are some key API security testing capabilities to apply across the API lifecycle:
Run a wide range of automated tests that simulate malicious traffic
Discover vulnerabilities before APIs enter production, reducing the risk of successful attacks
Inspect your API specifications against established governance policies and rules
Run API-focused security tests that run on-demand or as part of a CI/CD pipeline
Final thoughts: API security for insurance companies
By proactively identifying and assessing the risks of every API, insurance companies can implement proactive security measures and mitigate vulnerabilities. The real-life scenarios we shared demonstrate the value of API discovery and risk assessment in uncovering security gaps and enabling insurance companies to enhance their API security posture.
The best practices regarding the four pillars of API protection can help companies safeguard not only their APIs, but also the data their policyholders entrust to them for safe keeping.