Demystifying the API (Using Threat Grid as an Example)

Let’s talk about API usage. An API is a means of interacting with a program via another program. Just like a UI is a User Interface, an API is an Application Program Interface. Cisco is committed to providing practical, robust, scalable APIs across the Advanced Threat Solutions product space, in keeping with our commitment to fostering network programmability. The ability to utilize the functions of a piece of software in a programmatic way of your own, provides you with a very powerful way to integrate data and actions into your own tools or programs.

However, many network and SOC operators do not come from a development background, and perceive an API as something for the exclusive use of application developers. This is not the case, and a mature and well designed security product API can be of great value to security personnel regardless of development background.

I will use the Threat Grid API to demonstrate.

The Threat Grid API offers broad functionality, primarily in the areas of

• user and organization account management
• sample management
• sample analysis data collection
• threat intelligence harvesting

Of course, an easy way to use an API is to use a product that leverages that API. And the above functionality has allowed many applications to integrate with Threat Grid for various purposes. For a list of Cisco-approved third party Threat Grid integrations, click here.

But for those of us who want the flexibility of using the API directly, and are not application developers, read on…

Any RESTful API can be operated by anyone who can construct a web URI. If you can understand the parts of a URI such as the following, then you are ready to start:

http://ift.tt/2DDbyC2

In fact, if you have a Threat Grid Portal account, you can start a session by logging in, and then examine and click on this link:

https://panacea.threatgrid.com/api/v2/iocs/feeds/ips?limit=10&after=2018-01-18T00:00:00&before=2018-01-18T02:00:00&confidence=75&severity=75

Congratulations! You just used the Threat Grid API, without writing a line of code. What you did specifically, was request the first 10 IP addresses that Threat Grid saw samples communicate with during analysis, in the first two hours of January 18th (UTC time), where those communications triggered a Behavior Indicator that had both a confidence and severity equal to or higher than 75.

If your organization submits samples to Threat Grid, you could easily tailor that to a list of IPs (or domains, or URLs, file hashes, etc) that had been seen in analysis of only your own organization’s submitted samples.

With only minor variations on the intuitive URL above and a simple shell script that calls wget or curl, launched from a cron job, you could have a near-real-time feed of network resources and/or file hashes that have been seen in suspicious activity performed by samples that have targeted your organization. This could in turn be fed into the SIEM or NGIPS of your choice for high-fidelity, targeted alerting on matches.

More and more products in the security space, especially in the advanced threat protection and malware analysis markets, are including APIs for customers to access, both in on premise and cloud solutions. If you are not making use of these features, you are shorting yourself and missing opportunities to get even more for your budget.

This is only one example of the capabilities of API usage that are well within the reach of anyone with even limited scripting knowledge. For more information:

• See the recently released Learning Labs module here to get a self-paced, guided tutorial on interacting with the Threat Grid API.
• Attend my upcoming DevNet talk on the topic at Cisco Live Barcelona.
• Stay tuned here for information on my upcoming related talks at
• To dive right in, see the API help documentation in the portal here.

Thanks for reading, and watch this space for future updates!

Tags:

from Cisco Blog » Security http://ift.tt/2EdpVOB