Expanding On The 3rd Party Analysis Of Security Threats
11 Oct 2016
I was learning from the Splunk's analysis of the Mirai Botnet, which was behind the massive attack against Krebs on Security, implemented via common Internet of Things devices like security cameras, and printers. I've been reading several of these types of security event analysis, which is something I think is extremely important in helping the industry deal with the increasing number of security events that are occurring across the online landscape.
The sharing of log files from compromised systems in this way is super important. We need as many eyes as we can get on these attacks, helping analyze what happened, and maybe possibly who was behind it. Of course, there are some scenarios where you might want to be cautious in opening up this data to the general public, but using common approaches to API deployment and management, this can be managed sensibly--while also adding another logging layer to the conversation, keeping track of who joins participates in the analysis.
At a minimum, the DNS, application, and server logs should be made available via Github, leveraging it's Git core, as well as the Github API as part of the evaluation and analysis of the attack information. Ideally, key aspects of the data, attack vector, and other elements should also be added to some sort of shared API infrastructure for continued community security threat analysis. In addition to the growing number of attacks, and analysis by leading analysts like Splunk, I'm also seeing increased discussion around the sharing of threat data in a standardized way--APIs can act as a distributed engine for this operation.
I learn a lot from the analysis that occurs on security events like this. I know that other security analysts learn from this as well. With digital security being such a critical issue, right along with environmental events like hurricanes, or health care concerns like the Zika virus, I'm suggesting that APIs be employed in a standardized way. We should have a common checklist for making log files from these security events accessible via APIs to help guide future release. We should also have a common set of API definitions and schema for making it available so that we can begin to standardize the client tooling we use to sense of each event.
We have a lot of work ahead of us when it comes to putting APIs to work when it comes to online security. It is another area I will continue to evangelize as I see more API and open data patterns emerge. I am looking to help stimulate 3rd party analysis of cybersecurity, and security events. In my opinion, it is the only way we are going to make sense of such a massively complex problem.