Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why APIs are critical for security operations

public://pictures/marius.jpeg
Marius Iversen Senior Platform Engineer, KPN
 

Cyber attacks on enterprises generate thousands of alerts a day that security teams must monitor and analyze. As the number of such attacks continues to grow and their sophistication makes them more difficult to spot, security teams have turned to multiple tools and/or pre-built integrations to protect their organizations from penetration and compromise.

Both of these methods have problems, however, so another powerful alternative has emerged: the use of application programming interfaces (APIs). In conjunction with security information and event management (SIEM) systems, APIs are now essential to getting the most out of your security efforts.

Here's why you should leverage APIs to bolster your organization's security operations.

Traditional approaches

While using multiple tools has its advantages, it can have its drawbacks, too. If the tools aren't properly integrated, they can create workflow problems that hinder, rather than enhance, security. Without a unified way to manage tools, security analysts will find themselves hopping from tool to tool, which will result in a loss of visibility, speed, and efficiency.

Vendors aware of the integration problem have begun offering pre-built integrations in their products. But these may not always address the problem.

For example, the number of tools they integrate with, and the amount of functionality they provide, may be limited. Pre-built integrations are often closed, with features that can't be extended. Those gaps in coverage can create information silos that obstruct your security team's efforts.

In addition, you need to keep pre-built integrations up to date. That can be challenging for organizations that support integrations with a large number of vendors, especially when those vendors upgrade their software. One vendor's new release may break the integrations with software from other vendors.

One alternative to pre-built integrations is to use integration tools designed from scratch to be open, such as APIs. Such tools, especially when combined with an information hub such as a SIEM system, can greatly simplify the unification of disparate systems and products.

Security team's ally

APIs can be a security team's best friend because they offer a means for sharing information among the disparate security tools the team uses. Technically, an API is a set of functions and procedures that allows for the creation of applications that access the features or data of an operating system, application, or other service. That means the API can be used for system-to-system communication between the team's tools. The tools can talk to each other, and have direct access to platform functions and data.

By defining a common language that you can use to query and provide responses between applications, an API can be one of the best ways to extract information from a system or application. The API's creator can control what data is requested and what actions are executed with that data.

What's more, by permitting information to be shared and aggregated by security tools, APIs allow those tools to focus on what they were built for: data collection and storage, reporting, visualization, correlation, or alerting. This, in turn, can lead to faster and more accurate notification and investigation of significant events.

APIs coupled with SIEM software can be a powerful combo for security teams. In this scenario, all the parts of an organization's information infrastructure send data to the SIEM, which makes it the easiest place to access information for sharing.

The SIEM is a natural location for a data hub to align, unify, and integrate your security tools. It makes sense to use a SIEM tool to send information back to its data sources, as well as to communicate bidirectionally with security tools that can benefit from data from the SIEM's many sources.

Taking the grunt out of grunt work

Leveraging APIs at the SIEM level conveys several benefits to security teams.

The APIs can automate time-consuming tasks, including interactions among and responses from a team's security tools. In addition, if an organization such as an ISP is providing security services to multiple customers, many of the tasks for those customers—data gathering, reporting, and so forth—can be automated with APIs.

Automation can also free up security team members to do higher-level tasks, improve the overall efficiency of a security operations center, and reduce human error, which will ensure more consistent results.

An API can make situations easier to visualize, too. For example, let's say an analyst using a hunt tool finds a security event of interest flagged by a SIEM. With the aid of an API, the analyst can snatch more information about the event from the SIEM, as well as the source data around the event—all without leaving the hunt tool.

If the event poses a significant threat, the analyst might want to use it to trigger an automated workflow process or response to it. That can also be done without leaving the hunt app.

Moreover, the SIEM and its APIs can be leveraged to orchestrate the performance of a wide variety of tasks. The combination can eliminate the necessity of shifting from tool to tool, clicking different buttons, and pulling up multiple dashboards and screens to investigate or perform actions on events.

Mutual communication

APIs can also be used to create bidirectional communication between a SIEM and an orchestration technology such as SOAR (security operations, analytics, and reporting). They can allow the SOAR to automate actions on a SIEM and the SIEM to trigger actions on the SOAR.

For example, an analyst who wants to work only from a SOAR dashboard could use API-driven links to gain all the functionality needed directly from that dashboard. So if an event triggers an automatic mitigation response, the analyst could investigate further by using the API-driven links on the dashboard to call up logs from the SIEM, as well as to compare the logs to search results in another tool in order to determine if the event was contained or if it managed to spread.

Because an organization can create its own APIs, it can customize them to do exactly what it wants. This is an advantage over pre-built integrations, which can be a black box to security teams. Customization is especially useful for organizations that want to use their SIEM to give their customers visibility into security activity on those customers' systems. Typically that's done with a multi-tenant SIEM that monitors activity for all the organization's customers.

Without APIs, that could be tricky. Since the SIEM is at the core of an organization's network, the organization doesn't want to expose the SIEM to outsiders. APIs allow an organization to display real-time information tailored to a customer's needs without giving the customer access to the organization's core network.

With APIs, the organization has granular control over what's presented to the customer. So customers who log into their security portal on the web will only see information pertinent to them.

Need for interoperability

As promising as APIs are for delivering interoperability among a security team's tools, fulfilling that promise isn't always easy. A large part of the problem is openness. When developing a platform or tool, technology providers often focus on the internal workings of their offering. That includes APIs, which are used to continually improve, upgrade, broaden, and evolve their product.

Many times the APIs are there just for internal developers. The developers understand how the APIs work, so documentation can be sketchy, which makes it difficult for outsiders to navigate the intricacies of the APIs. That's why it's important for security teams, when adopting API solutions, to choose products incorporating open technologies that support high levels of interoperability.

Marius will be presenting on this topic at the Micro Focus Cybersecurity Summit, Sept 25-27

Keep learning

Read more articles about: SecurityInformation Security