It’s now widely accepted that APIs are a key enabler of digital agility and transformation. More and more enterprises are using them as strategic business assets to help deliver products and services in the format and location that the customer demands.
However, as you build out your portfolio of APIs (plus Services and Events) to support your digital initiatives, so does the complexity around how to ensure they are properly secured.
API security is likely (or should be) at the forefront of your mind. APIs expose data, and data is gold. So if you’re risking failing to secure your sensitive data properly – and ensuring it doesn’t get into the wrong hands – that’s bad news for your enterprise. Bad news because API security breaches can cause you trouble with the regulators – this article from CSO shows examples of how much large enterprises are forced to pay for data breaches.
The blow back from breaches also spans much further than regulatory fines. Organizations are putting their reputation on the line when capturing personal and private data. This data MUST be properly secured, governed, and accounted for. A small gap in security can lead to enterprises being forces to halt business entirely until operational teams can mitigate and manage the area of effect caused by a breach. Events that can lead Customers and Partners away from the Enterprise due to a break in trust and reputation.
API security is more important than ever
While it’s long been thought that sharing data through APIs is much safer than screen scraping and other older methods, API security attacks are becoming more prevalent and more sophisticated. In fact, in Salt Security’s API security report released earlier this year, over 90% of companies had at least 1 security incident in 2020. And of those companies who participated, over half only had a basic API security strategy in place.
In another investigation by Salt into a large financial institution that provides API services through its online platform, multiple vulnerabilities were discovered. These allowed researchers to launch attacks including reading financial records, deleting customer accounts, and taking over any account.
There are some API security best practices which are entry tickets for organizations, and we’ll touch on them briefly. But it’s time for security strategies to mature to cover two key areas:
- Security across the API lifecycle (design-time and run-time)
- Automated control, checking/validation, and resolution through a configurable governance model
API security best practices everyone should be implementing
These are some of the basic API security practices that all organizations who are leveraging APIs should be implementing:
- Awareness of new threats – Staying up to date and proactive to keep with industry security standards and awareness of new and evolving threats.
- Authentication and authorization – Strict authorization practices for internal & external access to systems, data, and services.
- Validation – Monitoring Infrastructure & Ecosystems to ensure all points of access are vetted and compliant.
- Rate/resource limiting – Proactively preventing improper or malicious use of Services and Applications.
- Monitoring: audit, logging, etc. – Capturing the actions and events within an Ecosystem to gain insights regarding usage & users, replicate errors, and leverage the data to make better decision going forward.
- API gateway(s) – The brokers between backend services and systems to clients and applications, allowing data to be aggregated and passed quickly and securely between Channels, Enterprises, Customers, and Devices.
Step 1 to maturing your API security strategy: focus on security across the API lifecycle
Leaders in API security are working on their strategies across the API lifecycle, and enabling collaboration between key roles involved. This extract from Cyber Protection Magazine summarizes the importance of a holistic approach to security:
“To achieve greater collaboration, centralization and consistency, API security can’t be viewed in isolation. Protecting APIs during runtime isn’t enough, and testing APIs during design isn’t enough. Each would give a fragmented perspective that risks both high false positives and false negatives, and most importantly – won’t enable security and development teams to be on the same page and share the responsibility.”
A solution like our ignite platform can help ensure security across the lifecycle. ignite helps create a single source of truth for the API across all stages of the lifecycle, with enablement for both security and development teams so that they can interact with the API and its security policies etc. directly. This lifecycle approach to security can then utilize user access and change management to a define process for Product Owners, Chief Architects – Approvers, and Developers that require model and metadata alignment, lifecycle, testing, and validation to take place before certain actions are available (like deployment of an API to a production environment).
Step 2 to maturing your API security strategy: automating configurable governance and validation
Within large organizations, we see issues arising when developers are hand-coding APIs. It’s difficult to ensure API security protocols (as well as general governance rules and standards) are being properly applied when working with manual review processes. Leaders are using automated and configurable governance (like that provided by the ignite platform) to ensure upfront checking, validation, and resolution of potential security issues before the API is deployed to the gateway.
If we look at the vulnerabilities exposed in Salt’s research into the financial services platform provider:
- broken object level authorization (BOLA)
- broken function level authorization (BFLA)
- susceptibility to parameter tampering
- improper input validation
automated governance rules could have been configured and used during the API design process to check for, and remediate the vulnerabilities.
An example of preventing security breaches using automated governance
Let’s now take one specific attack (detailed in American Banker’s coverage of the report also), that of being able to read financial records of any customer after receiving authentication as another customer:
“Salt researchers found that an API endpoint allowed for client-controlled parameters in the URL, which served as file locators in the back end. The API endpoint looked like the following:
“/customer/rest/api/document/file?type=<type>&file=<file>&id=<ID>”
Specifically, a GET request to this API endpoint could be made by adjusting the query parameter ID to some alphanumeric sequence that would be used to retrieve stored data in the back end. A couple other factors increased the security impact:
-
the ID parameter did not use sufficient randomness or entropy
-
the API endpoint lacked any resource or rate limiting
The recommended remedies could all be automatically checked through governance rules:
- The parameter format: you could configure a regex check to the endpoint and basepath configuration to meet formatting requirements
- The ID parameter not using sufficient randomness: you could configure a check that a model reference and pre-approved “ID” is being used in payloads (assuming you’re using an information model to design APIs with a universal “ID” standard – a best practice in itself)
- Resource or rate limiting: while this is already a best practice we’ve covered earlier that should be included when designing the API, you could configure a check that limiting has been applied correctly
The ignite platform ensures your APIs are high quality and secure
ignite provides the necessary end-to-end framework for enterprises to capture and proactively prevent security risks and gaps as API, Services, and Events are Designed, Built, Deployed, and Monitored across the ecosystem. With support for Multi-Cloud & Multi-Repository, CI/CD, and Runtime architectures, ignite uniquely stands as a source to capture complexity, ensure security standard are met, and boost enterprise agility by providing the structure to capture it all.
Taking that further, ignite allows organizations to harvest live data from up/downstream and peripheral applications and runtimes. Guaranteeing that services are kept true to security standards established in ignite, while also providing the ability to capture all the relative service data from external sources so that the enterprise gains a single source of truth for the service architecture – while greatly reducing the means to audit the enterprise ecosystems.
I imagine you’re curious to see this in action! If so, please reach out to schedule a demo!
