A Comprehensive Guide to API Security
APIs are the heartbeat behind nearly all of our digital interactions. From checking the weather, using Uber, or asking Alexa to turn the lights on in our personal lives to e-commerce integrations, Google Drive, Microsoft SharePoint, or Okta in our professional lives, it’s hard to find a digital function that APIs don’t touch.
While APIs have been a driver of digital transformation, they haven’t come without risks. Over half (57%) of organizations have suffered from API-related breaches in the past two years, with 73% experiencing three or more incidents. Without the proper security controls, APIs can open the door for threat actors to access sensitive data and critical business resources — leaving significant reputational and financial damage in their wake.
We must change the narrative and take the right actions to secure APIs. Safeguarding APIs is not one singular function but a series of steps that follow alongside the API lifecycle from design to development and production and require collaboration between different teams. To bolster API security posture and reduce the number of API-related attacks, it’s important to take the following steps:
- Understand Who Owns API Security
It can be difficult to pinpoint a single API security owner because responsibility is shared across so many functions. Typically, one of three roles acts as the API security champion at the top: the chief information security officer (CISO), the head of enterprise and/or security architecture, or the head of product security. These leaders are typically responsible for designing and enforcing the API security program and providing strategic leadership, resource allocation, design standards, tool selection, security testing, and vulnerability management.
Next, are the “responsible stakeholders,” — those directly responsible for implementing and operating the critical API security activities designated by the CISO, the head of enterprise and/or security architecture, and/or the head of product security. Teams in this category include product and application security teams and security operations and incident response teams.
Then comes adjacent stakeholders whose job functions may not directly be responsible for securing APIs, but have responsibility for other initiatives that coincide with API security. Typically, these teams inform API security policies or use APIs to fulfill their roles. Teams in this category include governance, risk, compliance, and anti-fraud teams, data protection officers, and the API developers themselves.
- Dividing the NIST Cybersecurity Framework Actions By Team
The NIST Cybersecurity Framework 2.0 serves as a tool to outline the key functions and outcomes of cybersecurity programs overall and translates well to create and maintain a robust API security program. To build an “API security lifecycle,” organizations can mirror the six stages of the NIST framework. From an API security lens, this would look like:
Identify
When building an API security program, it’s important to catalog all APIs within the organization, including internal, external, and third-party APIs. Next, organizations need to conduct risk assessments to understand potential vulnerabilities.
To help with this stage, security and development teams should consider implementing automated tools to continuously discover and inventory all deployed APIs. Then, organizations can maintain an updated catalog of APIs, including multiple versions and endpoints. These tools can also identify unmanaged or “shadow” APIs that pose significant security risks.
Key stakeholders in this stage include the product, application security, and GRC teams.
Protect
After understanding the extent of APIs on the network, product and application security teams and API developers must require certain safety measures such as authentication, authorization, and encryption — on top of regular security testing.
Performing automated and manual application security testing (DAST) can help these teams identify runtime vulnerabilities and test API resilience against common threats. Organizations should also create a centralized management system to identify vulnerabilities and then prioritize them based on severity and impact. Then, security teams can implement remediation efforts to address any issues before deployment.
Detect
Next, the SOC, incident response, and anti-fraud teams, with the data protection officer, have to work together for the “Detect” phase. To detect and analyze potential attacks, these teams must track API activity in real-time, using logging and alerting mechanisms, and creating and storing detailed logs for any investigation.
The goal of the “Detect” phase is to monitor and log API activity to identify threats in real-time — preventing long dwell times and minimizing the risk of a threat actor accessing sensitive data. This includes capturing and analyzing API logs, proactively looking for indicators of compromise (IOCs) and using signature-based detection to identify known attack patterns.
Respond
Now that the organization has the ability to detect potential attacks, it’s important to have a plan to respond. After all, it is not a matter of if an attack is going to happen, but when. The SOC and incident response team must have a plan in place that ensures business continuity, can block malicious activity, and execute incident response protocols when an attack occurs.
The key to success in the “Respond” phase is configuring actionable alerts based on predefined terms and integrating them with incident management systems like security information and event management (SIEM) and security orchestration, automation, and response (SOAR) tools.
Recover
The SOC and incident response teams will also be the primary stakeholders once the dust has settled on API security attacks. Recovery is arguably one of the most important steps to restoring business operations and maintaining a business’ reputation.
It is critical for organizations to have a robust recovery process that ensures API functionality and security in the event of an incident. The “Recovery” phase includes a thorough investigation to determine the root cause of the attack, analyzing API sequences and traces to understand attack vectors, and collaborating with the right teams to implement corrective measures.
It’s important for organizations to learn from mistakes. Taking the time to document lessons learned, conduct tabletop exercises, and update security protocols can prevent a similar attack from happening in the future.
Govern
The final piece of the API Security Lifecycle is the “Govern” phase, which involves developing API security policies that are aligned with broader security and compliance requirements such as CCPA, GDPR, and HIPAA, all while implementing role-based access controls and continuous monitoring.
Enterprise architecture, product and application, and GRC teams have to work together to establish clear responsibilities for API security, ensure that all stakeholders are informed and processes are well-documented. This, in combination with a strong API security platform, will offer visibility, control, and report capabilities to keep enterprises safe, enforce policies, and demonstrate compliance.
To slow down attacks on APIs, organizations need to consider incorporating the “API Security Lifecycle” into their day-to-day operations. By clearly defining ownership across the teams and having a strong API security plan in place, organizations can have truly resilient APIs and reduce API-related risks, safeguard sensitive data, and provide seamless and secure digital experiences.
About the Author
Adam Arellano is the Field Chief Technology Officer (CTO) at Traceable by Harness, where he provides partnership and guidance to customers and the broader industry on API security. He is well known as a progressive and inventive technology executive offering over 15 years of success in championing mission-driven initiatives focused on cloud, AI, and information security innovation.
He has assembled a rich blend of technical prowess and business acumen, culminating with a talent for building effective cybersecurity programs and teams as a foundation for scalable and highly secure information architectures. He’s a pragmatic advisor and team leader who thrives when harnessing insights into interactions between people and systems to build genuinely unique technology solutions.
Adam is a devoted parent to six children living in Charlotte, NC, where he is a profoundly amateur cook with a strong aversion to cleaning the kitchen. As an analogue to his time in the Marine Corps, he is passionate about helping transitioning service members and promotes causes that offer foster care and adoption services to local community members.
