Clearly, information security has entered the era of big data. The fact that massive amounts of data are being generated is undeniable, but the real ability to successfully analyze all of it, produce actionable insights, in realistically useful time frames—that’s where the challenge (and, sometimes, the hype) lies.
Maybe information security practitioners believe there’s more hype than reality in big data analysis, but, for whatever reason, they have largely tended to focus on log files generated by security sensors (devices or applications that collect and report on threats in near-real time). They’ve all but ignored non-security or operational sources of data. This is particularly true of API data. And this omission is a mistake.
Data generated by API platforms includes operational—and likely security-relevant—information, including runtime detection reports, which can provide temporal analysis of volumes and traffic properties by dimensions that include: APIs; API products (a collection of API resources bundled for developers); apps; developers; and environments (network-accessible runtime deployment "containers" for APIs).
This operational data should be correlated against capabilities, which are also provided by an API platform, to detect threats, including:
IP address-based access restrictions
Correlations of operational data with threat protection data enables security professionals to rapidly assess risks to their organization’s API calls. The volume of such API calls can be enormous and of significant operational value (and risk) to an organization.
Snapchat’s API mistakes in late 2013 highlighted some basic security analytics capabilities that API platforms provide. While that’s a good starting point for information security practitioners, API security analytics opens up broader possibilities.
Those possibilities have to do with so-called big data efforts by security incident and event management (SIEM) platforms. As the traditional SIEM market reinvents itself into the security analytics market, vendors such as HP ArcSight, RSA Security Analytics, Splunk, and others all face a common problem.
With all of the information that those platforms need to analyze from all of the various security and operational sensors that are being used by organizations, collecting data gets tricky. There are literally hundreds of these security sensor companies, some of whom make their security point product data available via a common log format such as syslog, and others who make an API available for making their security point product data available.
That still leaves vast amounts of security data to be laboriously ingested into SIEM platforms, through the use of connectors or forwarders. This “forced data ingestion” is inflexible, very costly, and inefficient. There is no common API format for security vendors to write to; every vendor with an API has a proprietary format. The problem is compounded by the lack of a common log format. Even syslog, which is supposed to be a common log format, has multiple variations.
What if this problem could be brought under control by your API platform? What if it could be the common "clearinghouse" of security APIs? This would add tremendous value to the SIEM platforms and the numerous security sensor products available today. With your API platform “clearing” your security-product APIs on the consumption side, your platform becomes your first point of analysis for all big data security analytics.
Of course, integrating the exposure side of APIs into the SIEM platforms themselves allows these platforms to better analyze the massive quantities data they are purposefully designed to handle. Your API platform provides your “first alert” capability, and therefore itself becomes a powerful sensor to cue the SIEM on potential security threats. And that's a very good reason not to overlook API analytics when considering the security of your enterprise.