|Do US Gov Web APIs require "system interconnectivity agreements?"||Brian A||2/10/14 10:59 PM|
Have a bit of an interesting issue - looking for validation/guidance on this subject.
The project is a pilot to prove that you can use common, standardized Web based APIs to provide an informational sharing framework between Federal agencies for up to sensitive, non-Public information (no individuals - no PII or HIPPA!). Embraces Web based APIs on Private Gov web servers to free data from its silos, leveraging existing policy directives on the info sharing side to a common agreement, baking in access controls on users and resources, and wrapped in common federal/open security technologies to secure.
For our prototype, agencies signed an single information sharing agreement together that defines what each party provides to the table and that they will also use the community's APIs and data formats (no specific agency formats!). An additional common Acceptable Use Policy (AUP) then also encased the users who access these APIs to what they can do with them, have IA training, its a US gov system, etc. Both agreements are big on policy, less on technology.
Based on Google-fu and the project's desired end-state, issues identified:
Luckily, my parent agency has policies that are clear on this - Web APIs are explicitly defined as not being system interconnections. Its convincing other agencies the same and begs the following questions for validation and guidance:
|Re: Do US Gov Web APIs require "system interconnectivity agreements?"||Logan||2/11/14 5:43 AM|
|Re: Do US Gov Web APIs require "system interconnectivity agreements?"||Noah Kunin||2/11/14 9:18 AM|
Disclaimer: not a lawyer or a CISO, but been thinking about this a lot. Hope the answers are helpful.
NIST SP 800-47 absolutely should not apply to APIs. APIs exist to avoid many of the thorny issues by actually laying fiber, setting up VPNs/VPCs etc.
Individuals reading this document should understand it was written in 2002. I haven't read it in its entirety in a few months (I will do so and come back here this weekend) but re-scanning it, it's mainly referring to physical network architecture and its software defined proxies.
APIs do not create system interconnectivity as described here. Each API request is just that - a request. As you said, intermittent is the key word here. API requests may be denied at any time for any reason (keys, throttling, etc). Under a system interconnectivity agreement, the expectation is that we set up policies and procedures beforehand and those interactions persist for a long time because we are now both trusted users on the same network or system. There might be authentication or authorization layers, but that's often it which is why you need the agreement beforehand. An API enforces that the resource I'm GETing or POSTing is in the right form. If I have a direct system connection, I could access a share drive and just dump a huge folder of all sorts of stuff.
They are two entirely different use cases that should be under two totally different models of guidance. We are just now starting a process for security guidance for federal APIs - whether or not that eventually turns into a NIST special publication, I can't say and don't know.
I know many of us would love to help the other agency stakeholders or CISOs understand and support this distinction. We need guidance around API security, but 800-47 is not the answer.
I'm certainly moving in this direction and I think there is broad support for it. Devil is in the details and all that, but this is my expectation for the future.
3. None that I know of...yet
Since agency-to-agency APIs are still rather rare, no one has created "prevention" policy yet. In my mind this would be wrapped up in the affirmative policy. "Do this...so you don't have to do this." If anyone can stop or slow down agency-to agency system interconnectivity agreements, please do so. Please help get the message out that API requests are self-enforcing. Agencies don't need to sign an agreement, they need to publish the documentation and security standards of their APIs and make clear that requests that do not conform are rejected - full stop.
@Brian: I'm optimistic that air support on these issues is coming soon. But if you need more urgent help in engaging the other agencies you speak of, please reach out.
|Re: Do US Gov Web APIs require "system interconnectivity agreements?"||Sean Herron||2/11/14 10:16 AM|
To reinforce Noah's point - if an HTTP API requires a system interconnectivity agreement, then logically every connection to a .gov website by any visitor would require an interconnectivity agreement as well. The best way I've found to express what an API does to people who bring up arguments like the above mentioned is that an API is identical to a HTML webpage, except the formatting looks a little bit different.
This is especially true when talking about public-facing systems. I could imagine interagency APIs that exchange private data through authenticated means would need some sort of agreement in place, specifically around data usage policy and access controls. I don't think that agreement would look like what is in 800-47.
|Re: Do US Gov Web APIs require "system interconnectivity agreements?"||Noah Kunin||2/11/14 12:45 PM|
I saw this:
...and lol'd for real. Exactly.
|Re: Do US Gov Web APIs require "system interconnectivity agreements?"||Kin Lane||2/11/14 1:17 PM|
+1 for Noah and Sean on web / http APIs not fitting into “system interconnectivity agreements”. This represents the technical and fundamental shift between network connections, SOAP APIs and this new world of web APIs.
Web APIs were successful in part because of the loosely coupled nature of HTTP, leveraging a client / server and request / response. There is interconnectivity, but not the tight coupling and governance of previous network protocols and APIs.
As my friend Daniel Jacobson at Netflix (formerly NPR) says, the API is the contract. Each API endpoint provides access to a resource, then with accompanying management building blocks, you dial in that contract.
At the API provider level, you can enforce / encourage interoperability using common web api approaches:
At the API consumer level, you can enforce / encourage interoperability using common web api approaches:
All of these building blocks work in concert to orchestrate interoperability that protects the interest of API providers and consumers, and even 3rd party intermediaries. You even seen this approach to interoperability move from the technical, to meaningful reciprocity across providers, as we've seen with newer generation of automation providers like If This Then That and Zapier—building on legacy ETL concepts, but bringing into a new global, Internet era.
We have to establish case studies that will shift decision makers away from more rigid approaches. Without them we won't be able to achieve the flexibility that web APIs bring, and are left with a heavy handed Tech + Legal governance.
So to directly answer your questions:
1) Do US Gov Web APIs *require* system interconnectivity agreements? Which policies and conditions?
2) Can system interconnectivity agreements be mitigated to a common agreement instead of agency-specific? (i.e. single information sharing agreement, and/or Acceptable Use Policies, common Terms of Service per API provider )
3) Which policies/guidance can be leveraged prevent the specific use of "system interconnectivity agreements" into the rest of the US Gov Web API space?
The patterns exist in private sector and are slowly emerging in government. We just need to work to identify, standardardized and establish the case studies we need to steer away from the specific use of "system interconnectivity agreements".
Thanks - Kin Lane