RSS

API Security News

These are the news items I've curated in my monitoring of the API space that have some relevance to the API security conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is security (or not) their API infrastructure, and addressing the biggest problem we face online today.

VersionEye SDK Security Notifications

I’ve written about VersionEye a couple of times. They help you monitor the 3rd party code you use, keeping an eye on dependencies, license violations, and security issues. I’ve written about the license portion of this equation, but they came up again while doing my API security research, and I wanted to make sure I revisited what they were up to in this aspect of the API lifecycle, floating them up on my radar.

VersionEye is keeping an eye on multiple security databases and helps you monitor the SDKs you are using in your application. Inversely, if you are an API provider generating SDKs for your API consumers to put to use, it seems like you should be proactively leverage VersionEye to help you be the eye on the security aspects of your SDK management. They even help developers within their existing CI/CD workflows, which is something that you should be considering as you plan, craft, and support your APIs. Making it as easy for you to leverage your APIs SDKs in your own workflow, and doing the same for your consumers, while also paying attention to security at each step, breaking your CI/CD process when security is breached.

I also wrote about how VersionEye has open sourced their APIs a while back, highlighting how you can also deploy into any environment you desire. I’m fascinated by the model VersionEye provides for the API space. They are offering valuable services that help us manage our crazy worlds, with a viable commercial and open source offering, that integrates with your existing CI/CD workflow. Next, I’m going to study the dependency portion of what VersionEye offer, then take some time to better understand their business model and pricing. VersionEye is pretty close to what I like to see in a service provider. They don’t have all the shine of a brand new startup, but they have all the important elements that really matter.


Admit It You Do Not Respect Your API Consumers And End Users

Just admit it, you could care less about your API consumers. You are just playing this whole API game because you read somewhere that this is what everyone should be doing now. You figured you can get some good press out of doing an API, get some free work from developers, and look like you are one of the cool kids for a while. You do the song and dance well, you have developed and deployed an API. It will look like the other APIs out there, but when it comes to supporting developers, or actually investing in the community, you really aren’t that interested in rolling up your sleeves and making a difference. You just don’t really care that much, as long as it looks like you are playing the API game.

Honestly, you’d do any trend that comes along, but this one has so many perks you couldn’t ignore it. Not only do you get to be API cool, you did all the right things, launched on Product Hunt, and you have a presence at all the right tech events. Developers are lining up to build applications, and are willing to work for free. Most of the apps that get built are worthless, but the SDKs you provide act as a vacuum for data. You’ve managed to double your budget by selling the data you acquire to your partners, and other data brokers. You could give away your API for free, and still make a killing, but hell, you have to keep charging just so you look legit, and don’t raise any alarm bells.

It is hard to respect developers who line up and work for free like this. And the users, they are so damn clueless regarding what is going on, they’ll hand over their address book and location in real-time without ever thinking twice. This is just to easy. APIs are such a great racket. You really don’t have to do anything but blog everyone once in a while, show up at events and drink beer, and make sure the API doesn’t break. What a sweet gig huh? No, not really, you are just a pretty sad excuse of a person, and it will catch up with you somewhere. You really represent everything wrong with technology right now, and are contributing to the world being a worse place than it already is–nice job!

Note: If my writing is a little dark this week, here is a little explainer–don’t worry, things will back to normal at API Evangelist soon.


The Reason For Your API Security Breach: You Did Nothing

You just got three separate calls, and countless emails alerting to the fact that you just had a major security breach. You don’t know the extent of the damage yet, but it looks like they got into your primary customer database via the APIs you depend on for all your mobile applications. You are sitting in your office chair, sweating, and trying to figure out how this happened. I will tell you, it is because you have done nothing. You have de-prioritized security at every turn, resulting in an open door for any hacker to walk through.

Not only have you done nothing, you actually worked against anyone who brought up the topic of API security. You would respond: We don’t have the time. We don’t have the budget. We don’t have the skills. You never listened to anyone of your staff, even that security lady (what was her name?) you had hired last year, and then resigned, with a letter containing over 25 security holes she had been trying to take care of, but because of the toxic environment you’ve created, she was unable to do anything and moved on. You have created an environment where anyone who brings up security concerns feels persecuted, and even that their job is in jeopardy, making “doing nothing” the standard mode across all operations.

You have eight separate mobile applications which all use APIs, and all of them using the customer database in question, which also stores credit cards, which is in violation of your PCI compliance–you know, those forms you sign off on each year? You felt these mobile APIs were secure because they were hidden behind your mobile applications, and your developers had given you a application security scan report last year. In this situation you would love to blame these developers, but all roads lead to you when it comes to responsibility for this situation. You begin to feel sick to your stomach thinking about the 345,633 credit cards and other PII that was leaked. You know the numbers, because you have real time reports on how many customers you have. You just don’t have any real time reports for anything to do with security.

API security was everyones first concern when you first pitched these projects starting back in 2010, and you have managed to run for seven years without any major incidents. Each year you have just been more emboldened in your do nothing strategy, but everything has caught up with you now. What do you do? You don’t have a breach action plan. You don’t have sort of protocol for this type of situation, despite saying that you did several times in meetings. You better get to work dealing with the technical fallout from all of this, because it will last weeks, if not months. Then you get to also start dealing with the business, legal, and political fallout from this breach. Hey, there is a bright spot. The chances are pretty high you might not even have a job after all of this is pretty high as well. Enjoy!

Note: If my writing is a little dark this week, here is a little explainer–don’t worry, things will back to normal at API Evangelist soon.


Considering How Machine Learning APIs Might Violate Privacy and Security

I was reading about how Carbon Black, an endpoint detection and response (EDR) service, was exposing customer data via a 3r party API service they were using. The endpoint detection and response provider allows customers to optionally scan system and program files using the VirusTotal service. Carbon Black did not realize that premium subscribers of the VirusTotal service get access to the submitted files, allowing an company or government agency with premium access to VirusTotal’s application programming interface (API) can mine those files for sensitive data.

It provides a pretty scary glimpse at the future of privacy and security in a world of 3rd party APIs if we don’t think deeply about the solutions we bake into our applications and services. Each API we bake into our applications should always be scrutinized for privacy and security concerns, making sure end-users aren’t being subjected to unnecessary situations. This situation sounds like it was both API provider and consumer contributing to the privacy violation, and adjusting platform access levels, and communicating with API consumers would be the best path forward.

Beyond just this situation, I wanted to write about this topic as a cautionary tale for the unfolding machine learning API landscape. Make sure we are thinking deeply about what data and content we are making available to platforms via artificial intelligence and machine learning APIs. Make sure we are asking the hard questions about the security and privacy of data and content we are running through machine learning APIs. Make sure we are thinking deeply about what data and content sets we are running through the machine learning APIs, and reducing any unnecessary exposure of personal data, content, and media.

It is easy to be captivated by the magic of artificial intelligence and machine learning APIs. It is easy to view APIs as something external, and not much of a privacy or security threat. However, with each API call we are inviting a 3rd party API into our databases, files, and other private systems. Let’s make sure we have an honest conversation with our API providers about how data and content is accessed, stored, cached, and used as part of any AI or ML process. Let’s make sure we get clarification on which partners, or other 3rd party providers are getting access to data and content that is indexed and executed as part of AI and ML API requests and responses. How long are videos or images stored? How long is data stored?

I’m seeing more discussion around dependencies going on in the API space. Which software libraries, and APIs are we depending on for our applications and services. I’m feeling like this conversation is going to continue expanding and security, privacy, and observability is going to become a more significant part of these dependency discussions. It will be a conversation that continues to push API deployment on-premise, and on-premise, being observable about how ML and AI API operations are being logged, stored, and track on. I’m going to keep watching how APIs are intentionally or unintentionally violating security and privacy like this, and keep an eye on the API dependency conversation to see how it evolves as part of this security and privacy discussion.


The ElasticSearch Security APIs

I was looking at the set of security APIs over at Elasticsearch as I was diving into my API security research recently. I thought the areas they provide security APIs for the search platform was worth noting and including in not just my API security research, but also search, deployment, and probably overlap with my authentication research.

  • Authenticate API - The Authenticate API enables you to submit a request with a basic auth header to authenticate a user and retrieve information about the authenticated user.
  • Clear Cache API - The Clear Cache API evicts users from the user cache. You can completely clear the cache or evict specific users.
  • User Management APIs - The user API enables you to create, read, update, and delete users from the native realm. These users are commonly referred to as native users.
  • Role Management APIs - The Roles API enables you to add, remove, and retrieve roles in the native realm. To use this API, you must have at least the manage_security cluster privilege.
  • Role Mapping APIs - The Role Mapping API enables you to add, remove, and retrieve role-mappings. To use this API, you must have at least the manage_security cluster privilege.
  • Privilege APIs - The has_privileges API allows you to determine whether the logged in user has a specified list of privileges.
  • Token Management APIs - The token API enables you to create and invalidate bearer tokens for access without requiring basic authentication. The get token API takes the same parameters as a typical OAuth 2.0 token API except for the use of a JSON request body.

Come to think of it, I’ll add this to my API management research as well. Much of this overlaps with what should be a common set of API management services as well. Like much of my research, there are many different dimensions to my API security research. I’m looking to see how API providers are securing their APIs, as well as how service providers are selling security services to APIs providers. I’m also keen on aggregating common API design patterns for security APIs, and quantity how they overlap with other stops along the API lifecycle.

While the cache API is pretty closely aligned with delivering a search API, I think all of these APIs provide a potential building block to think about when you are deploying any API, and represents the Venn diagram that is API authentication, management, and security. I’m going through the rest of the Elasticsearch platform looking for interesting approaches to ensuring their search solutions are secure. I don’t feel like there are any search specific characteristics of API security that I will need to include in my final API security industry guide, but Elasticsearch’s approach has re-enforced some of the existing security building blocks I already had on my list.


Patent Number 9325732: Computer Security Threat Sharing

The main reason that I tend to rail against API specific patents is that much of what I see being locks up reflects the parts and pieces that are making the web work. I see things like hypermedia, and other concepts that are inherently about sharing, collaboration, and reuse–something that should never be patented. This concept applies to other patents I’m seeing, but rather than being about the web, it is about trust, and sharing of information. Things that shouldn’t be locked up, and exist within realms where the concept of patents actually hurt the web and APIs.

Today’s patent is out of Amazon, who are prolific patenters of web and API concepts. This one though is about the sharing of security threat sharing. Outlining something that should be commonplace on the web.

Title - Computer security threat sharing
Number - 09325732
Owner - Amazon Technologies, Inc.
Abstract - A computer security threat sharing technology is described. A computer security threat is recognized at an organization. A partner network graph is queried for security nodes connected to a first security node representing the organization. The first security node is connected to at least a second security node representing a trusted security partner of the organization. The second security node is associated with identification information. The computer security threat recognized by the organization is communicated to the trusted security partner using the identification information associated with the second security node.

I’m sorry. I just do not see this as unique, original, or remotely a concept that should be patentable. Similar to a previous patent on trust, I just don’t think that sharing of security information needs to be locked up. The USPTO should recognize this. I feel like this type of patent shows how broken the patent process is, and how distorted company’s views on what is a patentable idea. Honestly, these types of patents feel lazy to me, and lack any creativity, skills, or sensible view of how the web works.

I feel like I should start rating these patents with some sort of Rotten Tomato score, and start giving companies some sort of patent ranking for their portfolio. Something that encompasses the scope, lack of creativity, originality, and damaging effects of the patent. This reminds me that I need to finish my work pulling court cases from the Court Listener API, and index them for any companies, and their patent portfolios. Ultimately this is where the real damage to APIs and the web will play out, similar to the Oracle vs. Google API copyright affair, but I will keep sharing stories of these ridiculous patents, and maybe even start ranking them all by how much they stink.


An Open Source API Security Intelligence Gathering, Processing, And Distribution Framework

I was reading about GOSINT, the open source intelligence gathering and processing framework over at Cisco. “GOSINT allows a security analyst to collect and standardize structured and unstructured threat intelligence. Applying threat intelligence to security operations enriches alert data with additional confidence, context, and co-occurrence. This means that you are applying research from third parties to your event data to identify similar, or identical, indicators of malicious behavior.” The framework is written in Go, with a front-end in JavaScript frontend, and usage of APIs as threat intelligence sources.

When you look at configuration section on the README for GOSINT, you’ll see information for setting up threat intelligence feeds, including Twitter API, Alien Vault the Open Threat Community API, VirusTotal API, and the Collaborative Research Into Threats (CRITS). GOSINT acts as an API aggregator for a variety of threat information, which then allows you to scour the information for threat indicators, which you can evolve over time, providing a pretty interesting model for not just threat information sharing, but also API driven aggregation, curation and sharing.

GOSINT also has the notion of behaving as a “transfer station”, where you can export refined data as CSV or CRITS format. Right here seems like an opportunity for some Github integration, adding continuous integration and deployment to open source intelligence and processing workflows. Making sure refined, relevant threat information is available where it is needed, via existing API deployment and integration workflows. Wouldn’t take much to publish CSV, YAML, and JSON files to Github which can then be used to drive distributed dashboards, visualizations, and other awareness building tools. Plus, the refined threat information is now published as CSV/JSON/YAML on Github where it can be ingested by any system of application with access to the Github repository.

GOSINT is just one of the interesting tooling I’m coming across as I turn up the volume on my API security research, thanks to the investment of ElasticBeam my API security partner. They’ve invested in an API security guide, as well as white paper, which is something that will generate a wealth of stories like this along the way, as I find interesting API security artifacts. I’m looking to map out the API security landscape, but I’m also interested in understanding open source API aggregation, analysis, and syndication platforms that integrate with existing CI/CD workflows, to help feed my existing human services API work, and other city, state, and federal government API projects I’m working on.


Open Sourcing Your API Like VersionEye

I’m always on the hunt for healthy patterns that I would like to see API providers, and API service providers consider when crafting their own strategies. It’s what I do as the API Evangelist. Find common patterns. Understand the good ones, and the bad ones. Tell stories about both, helping folks understand the possibilities, and what they should be thinking about as they plan their operations.

One very useful API that notifies you about security vulnerabilities, license violations and out-dated dependencies in your Git repositories, has a nice approach to delivering their API, as well as the other components of their stack. You can either use VersionEye in the cloud, or you can deploy on-premise:

VersionEye also has their entire stack available as Docker images, ready for deployment anywhere you need them. I wanted have a single post that I can reference when talking about possible open source, on-premise, continuous integration approaches to delivering API solutions, that actually have a sensible business model. VersionEye spans the areas that I think API providers should consider investing in, delivering SaaS or on-premise, while also delivering open source solutions, and generating sensible amounts of revenue.

Many APIs I come across do not have an open source version of their API. They may have open source SDKs, and other tooling on Github, but rarely does an API provider offer up an open source copy of their API, as well as Docker images. VersionEye’s approach to operating in the cloud, and on-premise, while leveraging open source and APIs, as well as dovetailing with existing continuous integration flows is worth bookmarking. I am feeling like this is the future of API deployment and consumption, but don’t get nervous, there is still plenty of money to be be made via the cloud services.


Randomize IoT Device Username And Password By Default

I am totally hooked on POLITICO’s Morning Cybersecurity email. I’m not an email newsletter guy, but this is government cybersecurity wonky enough to keep me engaged each day. One of the bits that recently grabbed my attention was regarding what should be considered Internet of Things common sense.

New America’s Open Technology Institute argued that IoT device makers should start equipping their products with basic security from the start - including by randomizing each device’s default username and password, making it much harder for hackers to locate and take over poorly configured devices. “The ability to modify login credentials should not be taken as a replacement for the implementation, where possible, of unique passwords for every device sold,” OTI wrote. Also on the common-sense front, OTI said that IoT devices “must be designed in such a way that they can be patched or updated.”

I wish this was the default for ANYTHING we connect to the Internet. I wish that IoT manufacturers would make this the default without the government stepping in. I’m guessing there is more money in selling insecure devices, and defending against them, then actually securing Internet connected devices in the first place. From the number of breaches I’m tracking on each week, I’m guessing business will be good for a small handful of Internet of Things manufacturers in this climate.


Open Sourcing Your API Like VersionEye

I’m always on the hunt for healthy patterns that I would like to see API providers, and API service providers consider when crafting their own strategies. It’s what I do as the API Evangelist. Find common patterns. Understand the good ones, and the bad ones. Tell stories about both, helping folks understand the possibilities, and what they should be thinking about as they plan their operations.

One very useful API that notifies you about security vulnerabilities, license violations and out-dated dependencies in your Git repositories, has a nice approach to delivering their API, as well as the other components of their stack. You can either use VersionEye in the cloud, or you can deploy on-premise:

VersionEye also has their entire stack available as Docker images, ready for deployment anywhere you need them. I wanted have a single post that I can reference when talking about possible open source, on-premise, continous integration approaches to delivering API solutions, that actually have a sensible business model. VersionEye spans the areas that I think API providers should consider investing in, delivering SaaS or on-premise, while also delivering open source solutions, and generating sensible amounts of revenue.

Many APIs I come across do not have an open source version of their API. They may have open source SDKs, and other tooling on Github, but rarely does an API provider offer up an open source copy of their API, as well as Docker images. VersionEye’s approach to operating in the cloud, and on-premise, while leveraging open source and APIs, as well as dovetailing with existing continous integration flows is worth bookmarking. I am feeling like this is the future of API deployment and consumption, but don’t get nervous, there is still plenty of money to be be made via the cloud services.


When You See API Rate Limiting As Security

I’m neck deep into my assessment of the world of API security this week, a process which always yields plenty of random thoughts, which end up becoming stories here on the blog. One aspect of API security I keep coming across in this research is the concept of API rate limiting as being security. This is something I’ve long attributed with API management service providers making their mark on the API landscape, but as I dig deeper I think there is more to this notion of what API security is (or isn’t). I think it has more to do with API providers, than companies selling their warez to these API providers.

The API management service providers have definitely set the tone for API security conversation(good), by standing up a gateway, and providing tools for limiting what access is available–I think many data, content, and algorithmic stewards are very narrowly focus on security being ONLY about limiting access to their valuable resources. Many folks I come across see their resources as valuable, when they begin doing APIs they have a significant amount of concern around putting their resources on the Internet, and once you secure and begin rate limiting things, all security concerns appear to have been dealt with. Competitors, and others just can’t get at your valuable resources, they have to come through the gate–API security done.

Many API providers I encounter have unrealistic views of the value of their data, content, and algorithms, and when you match this with their unrealistic views about how much others want access to this valuable content you end up with a vacuum which allows for some very narrow views of what API security is. To help support this type of thinking, I feel like the awareness generated from API management is often focused on generating revenue, and not always about understanding API abuse, and is also something can create blindspots when it comes to database, server, and DNS level logging and layers where security threats emerge. I’m assuming folks often feel comfortable that the API management layer is sufficiently securing things by rate limiting, and we can see all traffic through the analytics dashboard. I’m feeling that this one of the reasons folks aren’t looking up at the bigger API security picture.

From what I’m seeing, assumptions that the API management layer is securing things can leave blind spots in other areas like DNS, threat information gathering, aggregation, collaboration, and sharing. I’ve come across API providers who are focused in on API management, but don’t have visibility at the database, server, container, and web server logging levels, and are only paying attention to what their API management dashboard provides access to. I feel like API management opened up a new found awareness for API provides, something that has evolved and spread to API monitoring, API testing, and API performance. I feel like the next wave of awareness will be in the area of API security. I’m just trying to explore ways that I can help my readers and clients better understand how to expand their vision of API security beyond their current field of vision.


Craft An OpenAPI For An Existing Threat Intelligence Sharing API Specification

I wrote about the opportunity around developing an aggregate threat information API, and got some interest in both creating, as well as investing in some of the resulting products and services that would be derived from this security API work. As part of the feedback and interest on that post, I was pointed in the direction of the Structured Threat Information Expression (STIX), a structured language for cyber threat intelligence, and Trusted Automated Exchange of Intelligence Information (TAXII), and transport mechanism for sharing cyber threat intelligence.

This is why I write about my projects openly like this, so that my readers can help me identify existing approaches for tackling whatever I am focusing on. I prefer to never reinvent the wheel, and build on top of any existing work that is already available. I’m thinking the next step is to craft an OpenAPI fo TAXII, and STIX. Creating a machine readable blueprint for deploying, managing, and documenting a threat intelligence API. I couldn’t find any existing work on an OpenAPI definition, so this seems like a logical place to begin working to build on, and augment the work of the Cyber Threat Intelligence Technical Committee. Clearly, the working group has created a robust set of specifications, but I’d like to help move it closer to implementation with an OpenAPI.

I have created a Github organization to help organize any work on this project. I have forked the project for STIX and TAXII there, as well as started a planning repository to coordinate any work I’m contributing to the conversation. I have also created a repository for working on and publishing the OpenAPI that will define the project. Once we have this, I’d like to start thinking about the development of a handful of server side implementations in maybe Node.js, Python, PHP, or other common programming language. Here are the next steps I’d like to see occur around this project:

  • OpenAPI - Create an OpenAPI for STIX and TAXII to provide a single representation of a threat intelligence sharing API.
  • Threat List - Take the threat intelligence list I originally published, and identify how any of the sources would map to OpenAPI.
  • Storytelling - Tell stories throughout the process to attract the attention of other players, contributors, and investors, so that this project can live on.

I’m not looking to own this project 100%. I just don’t have the time and resources. However I do want to see an OpenAPI move forward, as well as a wealth of open source resources for deploying, integrating, and aggregating around threat intelligence sharing. This work is bigger than any single player, and is something that needs to be open, spanning thousands of providers, not controlled by a handful of gatekeepers. Players in the threat intelligence sharing game need to be able to decide who they consume and share threat intelligence with, something that will require a federated world of APIs that all speak in a common language. The Cyber Threat Intelligence Technical Committee is off to a great start. I just want to contribute with some cycles to help bring their work in alignment with what is going on in the mainstream world of APIs, while also beating a drum so that I can bring more attention to any work going on in this important area. Our world is going to need significant investment in the area of threat intelligence sharing if we are going to be successful online in coming years.


The Trusted Automated Exchange of Intelligence Information (TAXII)

I recently wrote about the opportunity around developing an aggregate threat information API, and got some interest in both creating, as well as investing in some of the resulting products and services that would be derived from this security API work. As part of the feedback and interest on that post, I was pointed in the direction of the Trusted Automated Exchange of Intelligence Information (TAXII), as one possible approach to defining a common set of API definitions and tooling for the exchange of threat intelligence.

The description of TAXII from the project website describes it well:

Trusted Automated Exchange of Intelligence Information (TAXII) is an application layer protocol for the communication of cyber threat information in a simple and scalable manner. TAXII is a protocol used to exchange cyber threat intelligence (CTI) over HTTPS. TAXII enables organizations to share CTI by defining an API that aligns with common sharing models. TAXII is specifically designed to support the exchange of CTI represented in STIX.

I breezed through the documentation for TAXII version 2.0, and it looks pretty robust, and a project that has made some significant inroads towards accomplishing what I’d like to see out there for sharing threat intelligence. I’m still understanding the overlap of TAXII, the transport mechanism for sharing cyber threat intelligence, and STIX, the structured language for cyber threat intelligence, but it looks like a robust, existing approach defining the schema and an API for sharing threat intelligence.

Next, I am going to gather my thoughts around both of these existing definitions, and look at establishing an OpenAPI that represents STIX and TAXII, providing a machine readable definition for sharing threat intelligence. I think having an OpenAPI will provide a blueprint that can be used to define a handful of server side implementations in a variety of programming languages. I was happy to be directed to this existing work, saving me significant time and energy when it comes to this conversation. Now I don’t have to jumpstart it, I just have to contribute to, and augment the work that is already going on.


Requiring ALL Platform Partners Use The API So There Is A Registered Application

I wrote a story about Twitter allowing users to check or uncheck a box regarding sharing data with select Twitter partners. While I am happy to see this move from Twitter, I feel the concept of information sharing being simply being a checkbox is unacceptable. I wanted to make sure I praised Twitter in my last post, but I’d like to expand upon what I’d like to see from Twitter, as well as ALL other platforms that I depend on in my personal and professional life.

There is no reason that EVERY platform we depend on couldn’t require ALL partners to use their API, resulting in every single application of our data be registered as an official OAuth application. The technology is out there, and there is no reason it can’t be the default mode for operations. There just hasn’t been the need amongst platform providers, as as no significant demand from platform users. Even if you don’t get full access to delete and adjust the details of the integration and partnership, I’d still like to see companies, share as many details as they possibly can regarding any partner sharing relationships that involve my data.

OAuth is not the answer to all of the problems on this front, but it is the best solution we have right now, and we need to have more talk about how we can make it is more intuitive, informative, and usable by the average end-users, as well as 3rd party developers, and platform operators. API plus OAuth is the lowest cost, widely adopted, standards based approach to establishing a pipeline for ALL data, content, and algorithms operate within that gives a platform the access and control they desire, while opening up access to 3rd party integrators and application developers, and most importantly, it gives a voice to end-users–we just need to continue discussing how we can keep amplifying this voice.

To the folks who will DM, email, and Tweet at me after this story. I know it’s unrealistic and the platforms will never do business like this, but it is a future we could work towards. I want EVERY online service that I depend on to have an API. I want all of them to provide OAuth infrastructure to govern identify and access management for personally identifiable information. I want ALL platform partners to be required to use a platforms API, and register an application for any user who they are accessing data on behalf. I want all internal platform projects to also be registered as an application in my OAuth management area. Crazy talk? Well, Google does it for (most of) their internal applications, why can’t others? Platform apps, partner apps, and 3rd party apps all side by side.

The fact that this post will be viewed as crazy talk by most who work in the technology space demonstrates the imbalance that exists. The technology exists for doing this. Doing this would improve privacy and security. The only reason we do not do it is because the platforms, their partners and ivnestors are too worried about being this observable across operations. There is no reason why APIs plus OAuth application can’t be universal across ALL platforms online, with ALL partners being required to access personally identifiable information through an API, with end-uses at least involved in the conversaiton, if not given full control over whether or not personally identifiable information is shared, or not.


More Investment In API Security

I’m getting some investment from ElasticBeam to turn up the volume on my API security research, so I will be telling more stories on the subject, and publishing an industry guide, as well as a white paper in coming weeks. I want my API security to become a first class area of my API research, along side definitions, design, deployment, management, monitoring, testing, and performance.

Much of my API security research is built on top of OWASP’s hard work, but honestly I haven’t gotten very far along in it. I’ve managed to curated a handful of companies who I’ve come across in my research, but haven’t had time to dive in deeper, or fully process all the news I’ve curated there. It takes time to stay in tune with what companies are up to, and I’m thankful for ElasticBeam’s investment to help me pay the bills while I’m heads down doing this work.

I am hoping that my API security research will also help encourage you to invest more into API security. As I do with my other partners, I will find ways of weaving ElasticBeam into the conversation, but my stories, guides, and white papers will be about the wider space–which Elastic Beam fits in. I’m hoping they’ll compliment Runscope as my partner when it comes to monitoring, testing, and performance (see how I did that, I worked Runscope in too), adding the security dimension to these critical layers of operating a reliable API.

One thing that attracted me to conversations with ElasticBeam was that they were developing a solution that could augment existing API management solutions like 3Scale and Amazon Web Services. I’ll have a talk with the team about integrating with Tyk, DreamFactory, and Restlet–my other partners. Damn I’m good. I got them all in here! Seriously though, I’m thankful for these partners investing in what I do, and helping me tell more stories on the blog, and produce more guides and papers.

I feel like 3Scale has long represented what I’ve been doing over seven years–a focus on API management. Restlet, DreamFactory, and Tyk represent the maturing and evolution of this layer. While Runscope really reflects the awareness that has been generated at the API management layer, but evolving to serve not just API providers, but also API consumers. I feel like ElasticBeam reflects the next critical piece of the puzzle, moving the API security conversation beyond the authentication and rate limiting of API management, or limiting the known threats, and making it about identifying the unknown threats our API infrastructure faces today.


Opportunity To Develop A Threat Intelligence Aggregation API

I came across this valuable list of threat intelligence resources and think that the section on information sources should be aggregated and provided as a single threat intelligence API. When I come across valuable information repos like this my first impulse is to go through them, standardize and upload as JSON and YAML to Github, making all of this data forkable, and available via an API.

Of course if I responded to every impulse like this I would never get any of my normal work done, and actually pay my bills. A second option for me is to put things out there publicly in hopes that a) someone will pay me to do the work, or b) someone else who has more time, and the rent paid will tackle the work. With this in mind, this list of sources should be standardized, and publish to Github and as an API:

</table>

Ideally, [each source on this list](https://github.com/hslatman/awesome-threat-intelligence) would be publishing a forkable version of their data on Github and/or deploying a simple web API, but alas it isn't the world we live in. Part of the process to standardardize and normalize the threat intelligence from all of these source would be to reach out to each provider, and take their temperature regarding working together to improve the data source by itself, as well as part of an aggregated set of data and API sources.

Similar to what I'm trying to do across many of the top business sectors being impacted by APIs, we need to to work aggregating all the existing sources of threat intelligence, and begin identifying a common schema that any new player could adopt. We need an open data schema, API definition, as well as suite of open source server and client tooling to emerge, if we are going to stay ahead of the cybersecurity storm that has engulfed us, and will continue to surround us until we work together to push it back.

Alexa Top 1 Million sites Probable Whitelist of the top 1 Million sites from Amazon(Alexa).
APT Groups and Operations A spreadsheet containing information and intelligence about APT groups, operations and tactics.
AutoShun A public service offering at most 2000 malicious IPs and some more resources.
BGP Ranking Ranking of ASNs having the most malicious content.
Botnet Tracker Tracks several active botnets.
BruteForceBlocker BruteForceBlocker is a perl script that monitors a server's sshd logs and identifies brute force attacks, which it then uses to automatically configure firewall blocking rules and submit those IPs back to the project site, http://danger.rulez.sk/projects/bruteforceblocker/blist.php.
C&C Tracker A feed of known, active and non-sinkholed C&C IP addresses, from Bambenek Consulting.
CI Army List A subset of the commercial CINS Score list, focused on poorly rated IPs that are not currently present on other threatlists.
Cisco Umbrella Probable Whitelist of the top 1 million sites resolved by Cisco Umbrella (was OpenDNS).
Critical Stack Intel The free threat intelligence parsed and aggregated by Critical Stack is ready for use in any Bro production system. You can specify which feeds you trust and want to ingest.
C1fApp C1fApp is a threat feed aggregation application, providing a single feed, both Open Source and private. Provides statistics dashboard, open API for search and is been running for a few years now. Searches are on historical data.
Cymon Cymon is an aggregator of indicators from multiple sources with history, so you have a single interface to multiple threat feeds. It also provides an API to search a database along with a pretty web interface.
Deepviz Threat Intel Deepviz offers a sandbox for analyzing malware and has an API available with threat intelligence harvested from the sandbox.
Emerging Threats Firewall Rules A collection of rules for several types of firewalls, including iptables, PF and PIX.
Emerging Threats IDS Rules A collection of Snort and Suricata rules files that can be used for alerting or blocking.
ExoneraTor The ExoneraTor service maintains a database of IP addresses that have been part of the Tor network. It answers the question whether there was a Tor relay running on a given IP address on a given date.
Exploitalert Listing of latest exploits released.
ZeuS Tracker The Feodo Tracker abuse.ch tracks the Feodo trojan.
FireHOL IP Lists 400+ publicly available IP Feeds analysed to document their evolution, geo-map, age of IPs, retention policy, overlaps. The site focuses on cyber crime (attacks, abuse, malware).
FraudGuard FraudGuard is a service designed to provide an easy way to validate usage by continuously collecting and analyzing real-time internet traffic.
Hail a TAXII Hail a TAXII.com is a repository of Open Source Cyber Threat Intelligence feeds in STIX format. They offer several feeds, including some that are listed here already in a different format, like the Emerging Threats rules and PhishTank feeds.
I-Blocklist I-Blocklist maintains several types of lists containing IP addresses belonging to various categories. Some of these main categories include countries, ISPs and organizations. Other lists include web attacks, TOR, spyware and proxies. Many are free to use, and available in various formats.
Majestic Million Probable Whitelist of the top 1 million web sites, as ranked by Majestic. Sites are ordered by the number of referring subnets. More about the ranking can be found on their blog.
MalShare.com The MalShare Project is a public malware repository that provides researchers free access to samples.
MalwareDomains.com The DNS-BH project creates and maintains a listing of domains that are known to be used to propagate malware and spyware. These can be used for detection as well as prevention (sinkholing DNS requests).
Metadefender.com Metadefender Cloud Threat Intelligence Feeds contains top new malware hash signatures, including MD5, SHA1, and SHA256. These new malicious hashes have been spotted by Metadefender Cloud within the last 24 hours. The feeds are updated daily with newly detected and reported malware to provide actionable and timely threat intelligence.
NormShield Services NormShield Services provide thousands of domain information (including whois information) that potential phishing attacks may come from. Breach and blacklist services also available. There is free sign up for public services for continuous monitoring.
OpenBL.org A feed of IP addresses found to be attempting brute-force logins on services such as SSH, FTP, IMAP and phpMyAdmin and other web applications.
OpenPhish Feeds OpenPhish receives URLs from multiple streams and analyzes them using its proprietary phishing detection algorithms. There are free and commercial offerings available.
PhishTank PhishTank delivers a list of suspected phishing URLs. Their data comes from human reports, but they also ingest external feeds where possible. It's a free service, but registering for an API key is sometimes necessary.
Ransomware Tracker The Ransomware Tracker by abuse.ch tracks and monitors the status of domain names, IP addresses and URLs that are associated with Ransomware, such as Botnet C∓C servers, distribution sites and payment sites.
SANS ICS Suspicious Domains The Suspicious Domains Threat Lists by SANS ICS tracks suspicious domains. It offers 3 lists categorized as either high, medium or low sensitivity, where the high sensitivity list has fewer false positives, whereas the low sensitivty list with more false positives. There is also an approved whitelist of domains.
Finally, there is a suggested IP blocklist from DShield.
signature-base A database of signatures used in other tools by Neo23x0.
The Spamhaus project The Spamhaus Project contains multiple threatlists associated with spam and malware activity.
SSL Blacklist SSL Blacklist (SSLBL) is a project maintained by abuse.ch. The goal is to provide a list of "bad" SSL certificates identified by abuse.ch to be associated with malware or botnet activities. SSLBL relies on SHA1 fingerprints of malicious SSL certificates and offers various blacklists
Statvoo Top 1 Million Sites Probable Whitelist of the top 1 million web sites, as ranked by Statvoo.
Strongarm, by Percipient Networks Strongarm is a DNS blackhole that takes action on indicators of compromise by blocking malware command and control. Strongarm aggregates free indicator feeds, integrates with commercial feeds, utilizes Percipient's IOC feeds, and operates DNS resolvers and APIs for you to use to protect your network and business. Strongarm is free for personal use.
Talos Aspis Project Aspis is a closed collaboration between Talos and hosting providers to identify and deter major threat actors. Talos shares its expertise, resources, and capabilities including network and system forensics, reverse engineering, and threat intelligence at no cost to the provider.
Threatglass An online tool for sharing, browsing and analyzing web-based malware. Threatglass allows users to graphically browse website infections by viewing screenshots of the stages of infection, as well as by analyzing network characteristics such as host relationships and packet captures.
ThreatMiner ThreatMiner has been created to free analysts from data collection and to provide them a portal on which they can carry out their tasks, from reading reports to pivoting and data enrichment. The emphasis of ThreatMiner isn't just about indicators of compromise (IoC) but also to provide analysts with contextual information related to the IoC they are looking at.
VirusShare VirusShare.com is a repository of malware samples to provide security researchers, incident responders, forensic analysts, and the morbidly curious access to samples of malicious code. Access to the site is granted via invitation only.
Yara-Rules An open source repository with different Yara signatures that are compiled, classified and kept as up to date as possible.
ZeuS Tracker The ZeuS Tracker by abuse.ch tracks ZeuS Command & Control servers (hosts) around the world and provides you a domain- and a IP-blocklist.

Does Your API Sandbox Have Malicious Users?

I have been going through my API virtualization research, expanding the number of companies I’m paying attention to, and taking a look at industry specific sandboxes, mock APIs, and other approaches to virtualizing APIs, and the data and content they serve up. I’m playing around with some banking API sandboxes, getting familiar with PSD2, and learning about how banks are approaches their API virtualization–providing me with an example within a heavily regulated industry.

AS I’m looking through Open Bank Project’s PSD2 Sandbox, and playing with services that are targeting the banking industry with sandbox solution, I find myself thinking about Netflix’s Chaos Monkey, which is “a resiliency tool that helps applications tolerate random instance failures.” Now I am wondering if there are any API sandboxes out there that have simulated threats built in, pushing developers to build more stable and secure applications with API resources.

There are threat detection solutions that have APIs, and some interesting sandboxes for analyzing malware that have APIs, but I don’t find any API sandboxes that just have general threats available in them. If you know of any sandboxes that provide simulations, or sample data, please let me know. Also if you know of any APIs that specifically provide API security threats in their sandbox environments so that developers can harden their apps–I’d love to hear more about it. I depend on my readers to let me know of the interesting details from API operations like this.

I’m on the hunt for APIs that have sandboxes that assist application developers think about the resiliancy and security of their applications built on top of an API. Eventually I’d also love to see a sandbox emerge to emerge that could help API providers think about the resiliancy and security of their APIs. I’m feeling like this aspect of API virtualization is going to become just as critical as guidance on API design best practices, but helping API operaters better understand the threats they face as API operators, and quantify them against their API in a virtualized and simulated environment that isn’t going to freak them out about the availability of their production environment.

I’ll keep an eye out for more examples of this in the wild–if you know of anything please let me know–thanks!


Making An Account Activity API The Default

I was reading an informative post about the Twitter Account Activity API, which seems like something that should be the default for ALL platforms. In today’s cyber insecure environment, we should have the option to subscribe to a handful of events regarding our account or be able to sign up for a service that can subscribe and help us make sense of our account activity.

An account activity API should be the default for ALL the platforms we depend on. There should be a wealth of certified aggregate activity services that can help us audit and understand what is going on with our platform account activity. We should be able to look at, understand, and react to the good and bad activity via our accounts. If there are applications doing things that don’t make sense, we should be able to suspend access, until more is understood.

The Twitter Account Activity API Callback request contains three level of details:

  • direct_message_events: An array of Direct Message Event objects.
  • users: An object containing hydrated user objects keyed by user ID.
  • apps: An object containing hydrated application objects keyed by app ID.

The Twitter Account Activity API provides a nice blueprint other API providers can follow when thinking about their own solution. While the schema returned will vary between providers, it seems like the API definition, and the webhook driven process can be standardized and shared across providers.

The Twitter Account Activity API is in beta, but I will keep an eye on it. Now that I have the concept in my head, I’ll also look for this type of API available on other platforms. It is one of those ideas I think will be sticky, and if I can kick up enough dust, maybe other API providers will consider. I would love to have this level of control over my accounts, and it is also good to see Twitter still rolling out new APIs like this.


Making An Account Activity API The Default

I was reading an informative post about the Twitter Account Activity API, which seems like something that should be the default for ALL platforms. In today’s cyber insecure environment, we should have the option to subscribe to a handful of events regarding our account or be able to sign up for a service that can subscribe and help us make sense of our account activity.

An account activity API should be the default for ALL the platforms we depend on. There should be a wealth of certified aggregate activity services that can help us audit and understand what is going on with our platform account activity. We should be able to look at, understand, and react to the good and bad activity via our accounts. If there are applications doing things that don’t make sense, we should be able to suspend access, until more is understood.

The Twitter Account Activity API Callback request contains three level of details:

  • direct_message_events: An array of Direct Message Event objects.
  • users: An object containing hydrated user objects keyed by user ID.
  • apps: An object containing hydrated application objects keyed by app ID.

The Twitter Account Activity API provides a nice blueprint other API providers can follow when thinking about their own solution. While the schema returned will vary between providers, it seems like the API definition, and the webhook driven process can be standardized and shared across providers.

The Twitter Account Activity API is in beta, but I will keep an eye on it. Now that I have the concept in my head, I’ll also look for this type of API available on other platforms. It is one of those ideas I think will be sticky, and if I can kick up enough dust, maybe other API providers will consider. I would love to have this level of control over my accounts, and it is also good to see Twitter still rolling out new APIs like this.


Validating My API Schema As Part of My API Security Practices

I am spending more time thinking about the unknown unknowns when it comes to API security. This means thinking beyond the usual suspects when thinking about API security like encryption, API keys, and OAuth. As I monitor the API space I’m keeping an eye out for examples of what might be security concerns that not every API provider is thinking about. [I found one recently in ARS Technica, about the Federal Communication Commission (FCC) leaking the email addresses through the CC API for anyone who submitted feedback as part of any issues like the recent Net Neutrality discussion.

It sounds like the breach with the FCC API was unintentional, but it provides a pretty interesting example of a security risk that could probably be mitigated with some basic API testing and monitoring, using common services like Runscope, or Restlet Client. Adding a testing and monitoring layer to your API operations helps you look beyond just an API being up or down. You should be validating that each endpoint is returning the intended/expected schema. Just this little step of setting up a more detailed monitor can give you that brief moment to think a little more deeply about your schema–the little things like whether or not you should be sharing the email addresses of thousands, or even millions of users.

I’m working on a JSON Schema for my Open Referral Human Services API right now. I want to be able to easily validate any API as human services compliant, but I also want to be able to setup testing and monitoring, as well as security checkups by validating the schema. When it comes to human services data I want to be able to validate every field present, ensuring only what is required gets out via the API. I am validating primarily to ensure an API and the resulting schema is compliant with HSDS/A standards but seeing this breach at the FCC has reminded me that taking the time to validate the schema for our APIs can also contribute to API security–for those attacks that don’t come from outside, but from within.

Disclosure: Restlet Client and Runscope are API Evangelist partners.


I Am Working With Elastic Beam To Help Define API Security

Security is the number one concern companies, organizations, institutions, and government agencies have when I’m talking with them about doing APIs. Strangely it is also one of the most deficient, and underinvested areas of API operations. Companies are just learning to design, deploy, and manage their APIs, and monitoring, testing, and security are still on the future road map for many API providers I know.

Security is one of the important areas I’ve been trying to find more time and resources to invest into my research, and I’ve been on the hunt for interesting providers to partner with when it comes to defining security as it applies to APIs. There are a number of web and infrastructure security companies out there, but there aren’t enough that are only focused on just APIs. With the number of APIs increasing, we need more eyeballs on the problem, and even more services and tools to stay ahead of the curve.

I finally found a worthwhile partner to help explore API security as part of my regular work as the API Evangelist, a new API security focused startup called Elastic Beam. They are a brand new effort exclusively focused on API security, who are hitting all the buzzworthy areas of the tech space (Artificial Intelligence, Machine Learning, etc), while also doing one thing and doing it well–API security. ElasticBeams core products are:

I’ve seen Elastic Beam in action, and have a copy to play with as I’m exploring a variety of scenarios in alignment with my API security research. Elastic Beam is going to invest in API Evangelist so I can pay attention to API security more, producing stories, guides, and white papers, and I’m going to help translate what it is they are offering, and help keep them focused on API security, and doing it well.

Elastic Beam is live. If you want to talk to them about security let me know, or just head over to their website. Also, if there are any specific areas of my API security research you’d like me to focus on, let me know. I’ve been having weekly calls with their team and advising them on their release. We’ll see where the relationship goes, but I’m stoked to finally have someone I can partner with to focus on API security. It is an area that needs more research, discussion, as well as storytelling, to help bring awareness to API providers–this stuff takes time, and we need more smart people on the case as soon as possible.

From the time I’ve spent with them, the Elastic Beam team seems to get the problem, and have invested in the right technology. I’m looking forward to working with them to continue to map out the API security space, identify and share information on the most common threats facing API providers. Stay tuned for more about API security, thanks to the Elastic Beam team.


The Unknown Unknowns Of API Security

I am trying to wrap my head around the next steps in the evolution of API security. I am trying to help separate some of the layers of what we collectively call API security, into some specific building blocks I can reference in my storytelling. I’m ramping up my API security research as I onboard a new API service provider partner, and will have more resources to invest in the API security discussion.

Let’s start with the easy “Known Knowns”:

  • Encryption - Using encryption across all aspects of API operations from portal to base URL.
  • API Keys - Making sure everyone who is accessing an API is keying up and passing along with each request.
  • OAuth - Getting more granular with access by applying OAuth when there is access to 3rd party data and content.
  • Rate Limiting - Limiting how much of a resource any single API consumer can access using rate limiting.

These are the first things that come to mind when the topic of API security is brought up. I’d say most conversation begin with encryption, but as someone progresses on their API journey they begin to understand how they can key things up, using OAuth, rate limiting, and other aspects of API management to secure their API operations.

Next, I want to think about some the “Known Unknowns”, things like:

  • Freeloaders - People with multiple accounts, and generally aren’t healthy consumers.
  • Errors - Errors, misconfigured, and malformed requests, responses, and anything that generally gums up the gears of operations.
  • Vulnerabilities - Making sure all known software and hardware vulnerabilities are patched and communicated as part of operations.
  • Attacks - Defending against the known attacks, staying in tune with OWASP and other groups who are actively identifying, studying, and sharing attacks.

These are the things we might not totally understand or have implemented, but they are known(ish). With the right amount of resources and expertise, any API team should be able to mitigate against these areas of security. There is always a lot of work to turn the unknowns into knowns in this area, but they are doable.

Now I want to think a little about the “Unknown Unknowns”, likes like:

  • DNS - What is happening at the DNS level as it pertains to my API security?
  • Relationship - Relationship between requests, even if they are using different keys, IP addresses, and other elements–where is the overlap?
  • Threats - What information is available to me regarding new and emerging threats that I’m only beginning to see, or maybe my partners and others in same space are seeing?
  • Sharing - Are there opportunities to share information and see a bigger picture when it comes to vulnerabilities and threats?

These are just a handful of my initial thoughts on what the unknown unknowns might be. Things that are currently off the radar of my known API security practices. API management seems to dominate and in some cases terminate the API security conversation, but I have the feeling there are numerous other considerations out there that we are not seeing. I’m just looking to begin defining this new bucket of security considerations so I can keep adding items to it as I’m doing my research.

From your perspective, what are the biggest threats out there for API security that many API providers are completely unaware of? I’m looking to keep expanding on this frontline of API security and turn up the heat beneath my research while I have the resources to do so. I feel like the API security conversation has kind of stagnated after the last wave of API management growth, leaving many providers thinking they have everything covered.


Patent US9462011: Determining trustworthiness of API requests

I’m always fascinated by the patents that get filed related to APIs. Most just have an API that is part of the equation, but some of the patents are directly for an API process. It’s no secret that I’m a patent skeptic. I’m not anti-patent, I just think the process is broken when it comes to the digital world, and specifically when it comes to APIs and interoperability. Here is one of those API patents that show just how broken things are:

Title: Determining trustworthiness of API requests based on source computer applications’ responses to attack messages Number: US9462011 Owner: CA, Inc.

Abstract: A method includes receiving an application programming interface (API) request from a source computer application that is directed to a destination computer application. An attack response message that is configured to trigger operation of a defined action by the source computer application is sent to the source computer application. Deliverability of the API request to the destination computer application is controlled based on whether the attack response message triggered operation of the defined action. Related operations by API request risk assessment systems are disclosed.

I get that you might want to patent some of the secret sauce behind this process, but when it comes to APIs, and API security I’m thinking we need to keep thinks open, reusable, and interoperable. Obviously, this is just my not so the business savvy view of the world, but from my tech savvy view of how we secure APIs, patented process help nobody.

When it comes to API security you gain an advantage by providing actual solutions and doing it better than anyone else. Then you do not need to defend anything, everyone will be standing in line to buy your services because securing your APIs is critical to doing business in 2017.


In The Future Our Current Views Of Personal Data Will Be Shocking


Thinking About The Privacy And Security Of Public Data Using API Management

When I suggest modern approaches to API management be applied to public data I always get a few open data folks who push back saying that public data shouldn’t be locked up, and needs to always be publicly available–as the open data gods intended. I get it, and I agree that public data should be easily accessible, but there are increasingly a number of unintended consequences that data stewards need to consider before they publish public data to the web in 2017.

I’m going through this exercise with my recommendations and guidance for municipal 211 operators when it comes to implementing Open Referral’s Human Services Data API (HSDA). The schema and API definition centers around the storage and access to organizations, locations, services, contacts, and other key data for human services offered in any city–things like mental health resources, suicide assistance, food banks, and other things we humans need on a day to day basis.

This data should be publicly available, and easy to access. We want people to find the resources they need at the local level–this is the mission. However, once you get to know the data, you start understanding the importance of not everything being 100% public by default. When you come across listings Muslim faith, and LGBTQ services, or possibly domestic violence shelters, and needle exchanges. They are numerous types of listings where we need to be having sincere discussions around security and privacy concerns, and possibly think twice about publishing all or part of a dataset.

This is where modern approaches to API management can lend a hand. Where we can design specific endpoints, that pull specialized information for specific groups of people, and define who has access through API rate limiting. Right now my HSDA implementation has two access groups, public and private. Every GET path is publicly available, and if you want to POST, PUT, or DELETE data you will need an API key. As I consider my API management guidance for implementors, I’m adding a healthy dose of the how and why of privacy and security using existing API management solutions and practice.

I am not interested in playing decider when it comes to what data is public, private, and requires approval before getting access. I’m merely thinking about how API management can be applied in the name of privacy and security when it comes to public data, and how I can put tools in the hands of data stewards, and API providers that help them make the decision about what is public, private, and more tightly controlled. The trick with all of this is how transparent should providers be with the limits and restrictions imposed, and communicate the offical stance with all stakeholders appropriately when it comes to public data privacy and security.


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.