These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is testing their APIs, going beyond just monitoring and understand the details of each request and response.11 Oct 2017
I study the API universe every day of the week, looking for common patterns in the way people are using technology. I study almost 100 stops along the API lifecycle, looking for healthy practices that companies, organizations, institutions, and government agencies can follow when dialing in their API operations. Along the way I am also looking for patterns that aren’t so healthy, which are contributing to many of the problems we see across the API sector, but more importantly the applications and devices that they are delivering valuable data, content, media, and algorithms to.
One layer of my research is centered around studying API security, which also includes keeping up with vulnerabilities and breaches. I also pay attention to cybersecurity, which is a more theatrical version of regular security, with more drama, hype, and storytelling. I’ve been reading everything I can on the Equifax, Accenture, and other scary breaches, and like the other areas of the industry I track on, I’m beginning to see some common patterns emerge. It is something that starts with the way we use (or don’t use) technology, but then is significantly amplified by the human side of things.
There are a number of common patterns that contribute to these breaches on the technical side, such as not enough monitoring, logging, and redundancy in security practices. However, there are also many common patterns emerging from the business approach by leadership during security incidents, and breaches. These companies security practices are questionable, but I’d say the thing that is the most unacceptable about all of these is the communication around these security events. I feel like they demonstrate just how dysfunctional things are behind the scenes at these companies, but also demonstrate their complete lack of respect and concern for individuals who are impacted by these incidents.
I am pretty shocked by seeing how little some companies are investing in API security. The lack of conversation from API providers about their security practices, or lack of, demonstrates how much work we still have to do in the API space. It is something that leaves me concerned, but willing to work with folks to help find the best path forward. However, when I see companies do all of this, and then do not tell people for months, or years after a security breach, and obfuscate, and bungle the response to an incident, I find it difficult to muster up any compassion for the situations these companies have put themselves in. Their security practices are questionable, but their communication around security breaches is unacceptable.
I am working through the almost 100 federal government agency developer portals and the almost 500 APIs that exist across these agencies, looking for the good and bad of APIs in government at this level. One of interesting building blocks I’ve stumbled across, that I would like to shine a light on for other public and private sector API providers to consider in their own operations is a vulnerability disclosure.
I feel that 18F description of their vulnerability disclosure says it best:
As part of a U.S. government agency, the General Services Administration (GSA)’s Technology Transformation Service (TTS) takes seriously our responsibility to protect the public’s information, including financial and personal information, from unwarranted disclosure.
We want security researchers to feel comfortable reporting vulnerabilities they’ve discovered, as set out in this policy, so that we can fix them and keep our information safe.
This policy describes what systems and types of research are covered under this policy, how to send us vulnerability reports, and how long we ask security researchers to wait before publicly disclosing vulnerabilities.
This should be default across all federal, state, county, and municipal government agencies. Hell, it should be default across all companies, organizations, and institutions. One of the reasons we have so much dysfunction in the security realm that elevates the discussion to theatrical levels with cybersecurity is that we aren’t having honest conversations about the vulnerabilities that exist. Few platforms want these conversations to occur, let alone set the tone of the conversation in such an open way. Without any guidance, and fear of retaliation, developers and analysts who find vulnerabilities will continue to hold back on what they find.
Vulnerability disclosure seems like something that ALL API provides should possess. There is no reason you can’t fork the GSA vulnerability policy and share it as the official tone of the vulnerability disclosure conversation on your platform. Encouraging all API developers to understand what the tone of the conversation will look like when they stumble across a vulnerability while integrating with your API. I’m adding the concept of having a vulnerability disclosure to my API vulnerability research, and I am going to add GSA’s version as a tool in the API vulnerability toolbox, providing a template that other providers can put to work.
If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.