10 Reasons to Trust Your Enterprise APIs

Recently one of the big-three consumer credit bureaus fixed an issue that allowed an ordinary user to obtain the credit score of tens of millions of Americans just by providing their name and mailing address.  The connective tissue making this data exposure possible was an Application Programming Interface or API. An API enables two pieces of software to communicate with each other. Just think about the different ways you interface with software. You might open a web interface to access email or launch your favorite social media app to connect with friends. Each of these workflows is more than likely using an API and has a distinct “interface” or way in which you achieve a particular task. Instead of humans interfacing with software, software interfaces with software. Rather than having a human point and click through a workflow, an API exposes functionality to another application.  This interaction happens more than you think and is most often free.  According to the latest Cisco Annual Internet report, there will be 29.3 billion networked devices by 2023.  A majority of the web traffic from those networked devices is primarily made up of API calls.  This massive explosion in device growth will increase reliance on APIs which brings increased security risk.

Besides unauthorized data exposure from the earlier example, unsecured APIs are ripe for all the risks outlined in the OWASP API Top 10 list. This list was originally compiled as a standard awareness document for developers and web application security practitioners. It represents a broad consensus about the most critical security risks to APIs.  Using this list as a backdrop the following best practices are presented as a call to action to help organizations take a proactive approach at addressing API security risk.  Whether you are a Chief Information Security Officer (CISO), software developer, or an everyday-API-consumer, following these best practices will allow you to better verify and trust each API interaction.  You may find that many of these best practices are already in use across your organization.  Completing the first three steps will accelerate an organization’s ability to complete the entire list.  I recommend working the list top down.  Be sure to check out the bonus tip at the end of the blog and share in the comments other ways your organization is successfully securing APIs.

1. Build a strong team responsible for understanding and securing your API infrastructure to drive business value. This team may already exist in the form of the DevOps or web application security group.  Arm your team with the skills and competencies necessary to adapt to the ever-changing API landscape.  This includes understanding API standards, tools, vulnerabilities, shadow applications, adversary behaviors, and mitigations.  Your team many find the resources and community support on Cisco DevNet as a great way to connect, secure, and automate APIs.
2. Once you have an accountable team, make a plan, and communicate it throughout the organization. Creating and regularly sharing an API governance strategy is critical now more than ever with API traffic and attacks trending upwards.  Know how each API in use brings value to the business. Can your stable of APIs be used to reduce inefficient use of resources, reduce the failure of IT initiatives, align IT with the business, reduce redundancy, or improve your competitive position?  This plan document is the perfect addition to an existing governance policy.  Ensure the plan covers public, private, and partner APIs.  Be sure to also include relevant sections in your incident response plan.  Maps to API1-API10
3. Inventory and patch your APIs. By using an API catalog in tandem with perimeter scans many of the visibility and privacy concerns can be addressed through tabletop exercises.  Here is a look at some of the Cisco API catalogs.  Begin by focusing on publicly available APIs.  With the team building, planning, and inventory steps behind you a good area of focus is to prioritize critical API software patches.  To minimize unplanned work and wasted effort, prioritize those vulnerabilities that are seeing active exploitation. Maps to API1-API10
4. Use strong authentication and authorization. With the rise in data breaches no organization can afford to leave the API door wide open.  Use a flexible security policy which accurately identifies API calls that misuse the latest vulnerabilities and automatically protects against this threat by terminating the API session. Leverage the capabilities offered by frameworks like OAuth 2.0 and protocols like OpenID Connect to secure the sharing of sensitive company and user information. Use short-lived access tokens, proper password storage, multi-factor authentication (MFA), and always authenticate your apps.  In the event of an unauthorized access event, do your API’s require sufficient access control for the level of sensitive data shared?  Consider an API gateway for an extra level of visibility and protection. Maps to API1,API2,API5, and API6
5. Apply the principle of least privilege. The principle of least privilege is an information security concept, which enforces the idea that users and applications should be granted the minimum level of access needed to perform required tasks. Always deny all API access by default.  Associated API users, processes, programs, systems, and devices should be granted only the minimum necessary access to complete a stated function. Take advantage of role-based access-controls when available. Maps API1 and API5
6. Encrypt sensitive traffic using Transport Layer Security (TLS). Not all APIs require encryption, but always use TLS when an API exchanges login credentials, credit card, social security, banking, health, or other sensitive information. This practice helps prevent eavesdropping, tampering, and man-in-the-middle attacks. Maps to API7
7. Remove non-essential public facing content and overexposed data from your API’s. Incorporate regular API audits and scans to address any leftover keys, passwords, or other backdoors that should have been removed by the API developer.  This practice is best implemented before making any API public facing.  Remember that some APIs begin as a development sandbox that may have not been thoroughly sanitized. Identify all the sensitive data or personally identifiable information (PII) and justify its use. Do your APIs expose more data types and volume than is necessary?  Monitor and enforce data access controls at the API level along with obfuscating API responses that contain confidential data. Automate locating API configuration flaws and disable unnecessary features. Maps to API3 and API7
8. Parse and validate input. Unauthorized users should never be able to modify API object properties they are not supposed to. Strictly define all input data, such as schemas, types, and string patterns, and enforce them at runtime. Validate, filter, and sanitize all incoming data. Use the readOnly property set to true in object schemas for all properties that can be retrieved through APIs but should never be modified. Parse multiple data formats, such as JSON, XML,GraphQL, and gRPC.  This step should align with existing web security best practices such as having a web or API firewall which can parse and validate traffic. Maps to API6,API7, and API8
9. Use API rate limiting, restrictions, and quotas. To ensure the availability of key API resources consider short and long-term restrictions on the size or number of resources that can be requested by the client/user. Quotas and rate limits work by tracking the number of requests each API user makes within a defined time period and then taking some action when a user exceeds the limit.  Quotas are identified per -tenant or at the customer level.  Rate-limits function at the ip address, api key, or user_id level. Actions may include rejecting the request with a 429 Too Many Requests status code, sending a warning email, adding a surcharge, among other things.  Many open API keys come with built in rate-limits such as an hourly request limit by unique IP address. Consider lockout policies where it makes sense. As part of step 10 capture API traffic metadata such as error rates, message sizes, token, and key exchanges to determine if volumetric traffic rate limiting or quotas need to be enforced.  Considerations should be made for both incoming and outgoing API traffic. Maps to API4.
10. Monitor, Audit and Log – Assess the findings of the API inventory in step 3 to ensure proper logging and monitoring takes place. Apply sufficient log retention policies.  Audit logs to ensure proper visibility and readiness for troubleshooting.  Ensure the capability exists to log full request and response bodies as needed. Do you have visibility per API user, per IP, per token, and API?  Do your API logs sufficiently identify application-specific data, security incidents, policy violations, traffic baselines, and API vulnerability exploitation? Note that not all API standards use the same data protocol.  REST and GraphQL APIs use JSON, SOAP uses XML, and gRPC leverages Protobuf. See your logging documentation for more detailed information on how to log a given format.  Maps to API10

Review security intelligence feeds associated with your digital footprint to ensure they cover the exposure and sale of stolen API credentials on paste sites and dark web forums.  These credentials are often referred to as “fullz” when searching for “full credentials.”  These same intelligence feeds can be used to understand API abuse.  It is not uncommon for APIs to be used to exfiltrate stolen data and facilitate hacker command-and-control channels

Share: