The API Security Conversation that the Verizon Data Breach Report Missed - Security Boulevard

The API Security Conversation that the Verizon Data Breach Report Missed

It’s out. The annual Verizon Data Breach Incident Report. 115 pages. Thousands and thousands of words. Eye-popping graphics. Zero mentions of API. No mentions of the term Application Programming Interface. One mention of the word programming, deep within an industry-specific section. Why no discussion on APIs as an Incident Classification alongside web application attacks? My speculative answer – APIs are plumbing. When you have a leak, your immediate concern is the damage and how to mitigate it. The “broken pipe” is not necessarily top of mind.

Using the Incident Classifications from the report and the OWASP API Security Top 10, here are some thoughts on how APIs may have been a factor behind the scenes, along with recommendations on how to address the security risk. Note that three Incident Classifications (social engineering, lost and stolen assets, everything else) were left out of the conversation as they have little to no direct connection to APIs.

VBIR Incident Classification Potential Risk to Your APIs  API Security Recommendations
Basic Web Application Attacks: Attacks with a small number of steps/additional actions after the initial web application compromise. Today’s modern web apps are usually supported by APIs that connect forms and microservices directly to application servers, databases or other microservices. Attackers can exploit insecurely built public-facing APIs to exfiltrate such information, without having to break into servers or the corporate network. This means that any one of the OWASP API Security Top 10 Threats could have been the root cause for such incidents or breaches. Monitor and protect your public-facing APIs as well as the servers, networks and kiosks mentioned in the report.

  • Create an inventory of all your public-facing APIs – including shadow and third-party.
  • Analyze and remediate those with misconfigured authentication and authorization parameters.
  • Determine which APIs are exposing sensitive data and address them immediately.

 

System Intrusion: Complex attacks that leverage Malware and/or Hacking to achieve their objectives including deploying ransomware. As with basic web attacks, there are many possible API-related avenues for threat actors to access network resources. Most commonly found are authentication and authorization errors (OWASP API19 #1 & #2, (Broken object level authorization and Broken user authentication). From an API perspective, system intrusion and privilege misuse go hand in hand. To protect your APIs from both of these risks, start first by making sure all parties fully understand the API authentication and authorization workflow.

  • Ensure access to elevated privileges is gated by strong Multi-Factor Authentication.
  • Eliminate or minimize error messages that can be used as education by threat actors.
  • Use a combination of whitelisting and blacklisting to protect resources.
  • Finally, implement API function-level, security-specific test cases, beyond scalability and pen-testing to ensure APIs are secure.
Privilege Misuse: Incidents predominantly driven by unapproved or malicious use of legitimate privileges. The most common avenue to gaining access to elevated privileges is poorly implemented authentication and authorization, as highlighted by their respective #1 & #2 placement in the OWASP API Security Top 10 list.
Denial of Service: Attacks intended to compromise the availability of networks and systems. Includes both network and application-layer attacks. The dark side of APIs are the ease with which it can be attacked at scale. Without backend resource and rate limiting (#8 on the OWASP list), the API can be easily targeted for a DoS/DDoS attack. During the design phase, development, business groups and security should document and look for ways to enforce the following:

·       Rate limits for API calls and client notifications (e.g., resets, lockout, etc.).

·       Resource consumption limits and server-side validation for response size (e.g., # of records, etc.).

·       Implementing controls on the backend can help act as an added line of defense during high volume spikes or large-scale attacks.

Miscellaneous Errors: Incidents where unintentional actions directly compromised a security attribute of an information asset. This does not include lost devices, which is grouped with theft instead. Outside of authentication and authorization errors discussed above, the most applicable entry on the OWASP API Security Top 10 list would be #7, security misconfiguration. Group collaboration should document and enforce the following:

  • How each API should handle resource configurations.
  • Which HTTP headers and HTTP methods should be used.
  • Minimize or eliminate permissive Cross-Origin resource sharing (CORS) and verbose error messages.
  • Building consistency into an API development methodology can help eliminate gaps that lead to security incidents.

Improving your API security posture is best done using a combination of documented best practices and technology to monitor and enforce policies. The OWASP API Security Top 10 list is a great place to start and you can see how Cequence Security can help enforce your best practices with comprehensive runtime API security. Check out the webinar, Demystifying the OWASP API Security Top 10, where we took a threat actor (Jason Kent, our Hacker in Residence) vs. protector (Subbu Iyer, VP of Products) approach of defining each of the attacks on the list, discussing the ways threat actors will use the security weakness, prevention tips, and how the Cequence Application Security Platform can augment your API coding best practices.

 

 

The post The API Security Conversation that the Verizon Data Breach Report Missed appeared first on Cequence.

*** This is a Security Bloggers Network syndicated blog from Cequence authored by Brittany Sterling. Read the original post at: https://www.cequence.ai/blog/the-api-security-conversation-that-the-verizon-data-breach-report-missed/