API Security Part 2: Beyond the Basics – Giving Your Teams Better Peace of Mind
Blog: The Tibco Blog
Having all the right controls in place, separating development concerns from segmentation and security, and opening access to reporting and monitoring tools all go a long way toward keeping your data secure. But true security starts with the design of your APIs, and a more efficient and thorough analysis of the traffic patterns your program is seeing.
Is Your Data Leaking?
It seems like we hear of a new data breach every week. More often than not, these breaches are not due to some dark-hooded hacker breaking your cryptographic protocols, but due to the careless handling of data. It’s rare that the API is the culprit behind these breaches — the most egregious are often due to a copy of the database existing on a stolen developer’s laptop — but, when it does happen, it’s often because the API was exposing more information than intended to the wrong audiences.
Packaging your APIs as described in my previous post is the first step toward preventing this type of breach, but even that relies on a thorough understanding of the data structure of each endpoint that may not be well communicated to the program managers. API designs based on HTTP (e.g. REST, GraphQL, SOAP, etc.) have the capability to define their responses using custom MIME types and profiles. For example, RESTful APIs that present their data in the JSON format should already specify the MIME type “application/json” in the “Content-type” header of their response. Adding a custom profile provides more specific information that is not only useful to the end user; it can provide better information in your reports on exactly what data was shared with each customer.
To do this properly, you must first define all of the data objects each endpoint will be responsible for returning. For example, if you’re designing an e-commerce API, you may have a product endpoint that has one data profile for internal developers and another for external developers. Ideally, the same endpoint would serve both audiences, but they would be exposed through separate packages in your API management system with filters applied to remove data that external developers should not see, such as competitive information showing the company’s cost for the product, the profit margin, or other sensitive data.
The profile for each response should be named according to its purpose. Internal developers should see something like the following in the response header:
Content-type: application/json;profile= “vnd.example.product.internal”
The external developer will, instead, see something similar:
Content-type: application/json;profile= “vnd.example.product.external”
Before writing a single line of code for your APIs, you should define these profiles and the data they will expose and document them using the Open API Specification version 3.0 (which now allows for multiple response profiles for each endpoint). This not only becomes the contract between your API and consuming developers, it clearly outlines the intent of your responses and allows you to create automated tests to validate that what the APIs are exposing are what’s expected. The OAS also allows you to separate those data objects either into separate sections or separate files to allows for reuse across similar endpoints.
Event-Driven Monitoring and Automated Response
For optimal security, it’s critical to catch bad actions when they happen and respond immediately rather than forensically identify the damage and apply patches after they have ended. Applying automation to triage and potentially resolve these actions without human intervention adds a layer of confidence that allows your development and operations teams to focus on the bigger issues rather than chasing down every small fluctuation in the system.
The backend code that drives your APIs can fire relevant events to a monitoring system as calls are being made. These events may include basic information regarding the nature of the request, identify which additional services the code is accessing along with response times, or any unusual errors experienced during processing. Similar events can also be invoked by the API management system using streaming log APIs or similar mechanisms.
Evolution to Event-driven Application Architecture. Enterprises are increasing developing applications (and thus, APIs) that utilize asynchronous (or event-driven) patterns. This enables quicker development of microservices, real-time response via event-driven triggers, and looser coupling of architecture for future iterations.
API program managers and developers should identify potential event patterns that indicate unusual usage and continue to monitor the event logs to find those patterns and identify new ones. Visualization tools like TIBCO Spotfire can make this process easier and more intuitive.
But identifying these patterns is useless if you have no way to execute on them. Defining these patterns in a business event tracking application allows the system to automatically address bad actions by triggering a response defined by your team. Applying business process management rules allows you to assign and track actions to staff members if the response can’t be easily automated. In all cases, your support and management staff should be alerted when these processes are triggered so you can better understand and react to these situations when they arise.
Reducing Staff Burden with AI
An emerging class of monitoring tools automates not only the response to bad actions but helps identify potential patterns based on usage and performance statistics. These AI-driven monitoring tools can speed response to the point where a majority of your API consumers never see a performance issue and the security of your data is better ensured.
Though still in the early stages, companies like Ping Identity are placing heavy bets on this style of API monitoring as the future of security. While AI-driven monitoring significantly reduces the burden of monitoring and reacting on your human staff, your people should still consistently review the effectiveness of the solution and learn from the patterns it identifies to build better, more performant, and more secure APIs.
The Silver Bullet for API Security Is You
No one approach alone will guarantee the security of your APIs and your data, and no single staff member or team should be responsible. Instead, everyone within your organization with API-related responsibilities should understand the basics of API security and create and follow procedures designed to ensure best practices are being followed and bad actions are captured and addressed as quickly as possible. Good API management, followed by good API design can address as much as 80 percent of your security concerns. Additional tools can provide more peace of mind and reduce the workload of your staff, allowing them to take their mind off the worry of potential security breaches and focusing on developing APIs that best serve your customers and the goals of the business.
Try it for yourself, with a 30-day free trial of TIBCO Cloud™ Mashery.
Leave a Comment
You must be logged in to post a comment.
