Do US Gov Web APIs require "system interconnectivity agreements?"

[Brian A]

Hello!

Have a bit of an interesting issue - looking for validation/guidance on this subject. 

Background
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.

Issues
Based on Google-fu and the project's desired end-state, issues identified:

1. New information sharing agreement:
   With the success of the prototype, we are kicking up to a pilot state that increases the types of datasets made available for sharing - still up to sensitive.  This now gears up the policy folks to draft a new information sharing agreement and AUP.  This has begun the dropping the term of "system interconnectivity" agreements possibly being required.
   
   
2. Definition of "system interconnectivity agreements"
   This terminology falls back to NIST SP 800-47, Security Guide for Interconnecting Information Technology Systems:
   "A system interconnection is defined as the direct connection of two or more IT systems for the purpose of sharing data and other information resources (p. 2-1)."
   
   This NIST Special Publication guidance only applies to federal organization that process sensitive information.  However, a trend by some of these agencies in the chatter is to require these "system interconnectivity agreements" for all Web APIs for gov to gov communications.
   
   
3. References from NIST to OMB Circular A-130:
   NIST guidance was built with Office of Management and Budget (OMB) Circular A-130, Appendix III in mind.
   
   
4. Connection types:
   If you look at both OMB and NIST documents, they refer to persistently connected types of information systems as examples:  joining networks via LANs and backbone circuits, dedicated leased lines, VPNs.  No intermittent connections like Web APIs.
   
   
5. Pilot results == future policies?
   If the pilot is successful, it is expected for this model to grow to additional agencies and more public-based datasets - maybe even industry.  This means any agreements (common or per-agency) drafted from the pilot will highly likely roll into production APIs use.  This makes it possible for a more wide-spread requirement of "system interconnectivity agreements" to other areas of the US Gov Web API space. (Eek!)
   

Guidance/Validation Needed
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: 

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?

[Logan Powell]

OAuth?

http://en.wikipedia.org/wiki/OAuth

[Noah Kunin]

Disclaimer: not a lawyer or a CISO, but been thinking about this a lot. Hope the answers are helpful.

Answers:

1. No

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.

2. Probaby

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.

[Sean Herron]

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.

[Noah Kunin]

Sean -

I saw this:

 

then logically every connection to a .gov website by any visitor would require an interconnectivity agreement as well

...and lol'd for real. Exactly. 

[Kin Lane]

+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:

• API Definitions - Machine readable API definitions like Swagger, API Blueprint and RAML can provide templates that enforce / encourage common blueprints that providers can follow when publishing APIs to centralized or decentralized API management platforms, establishing base contracts for interoperability, as well as underlying data models.
  
• Terms of Use - Common terms of use can be established for management, allowing provides to contract their own TOS that is tailored for specific resources, but derived from common patterns. You see this emerging in private sector with Swedish API License.
  
• Licensing - Much like TOS, common licensing blueprints can be provided, allowing data and resource licensing to be tailored for resources, but pulled from existing licensing pools. Many API providers are providing a base stack of licensing arrangements that meet their needs as well as consumers.
  
• Service Level Agreements (SLA) - Same as TOS, service level agreements can be forged allowing API providers to meet expectations of consumers. Some SLAs are loose and some are tight, depending on goals.
  
• Security - Common tooling and practices around the security of APIs need to be established, using common approaches like API Keys, oAuth, SSO and other common standards already in use. As with API interface patterns, data models, etc, each API provider should not be allowed to bring their home brew security to the table.
  
• Service Composition - A practice referred to as “service composition” is a common part of all API management platforms currently available. Service composition allows API providers to build service tiers and compose products from API resources, establishing different levels of access and usage that can be designed for internal, partner or public access to resources. Ie. Service tier A allows read only access to APIs with specific rate limits, while service tier B allows read / write access with unlimited. Service composition reflects and extends the contract that an API is. 
  
• Analytics - Real-time metrics give API providers with living views into API registration and usage, allowing an organic view into how resources are truly being used, allowing for real-time adjustments, enforcements, and service level composition adjustments to be made. This will allow providers to respond to adverse conditions by tightening control and stimulate innovation by loosening control as needed.

All of these provider level building blocks work in concert to standardize design, deployment and management of common API resources. They provide a common backbone that make APIs a living contract, that is flexible enough to work with many different resources and agencies, without being too rigid—providing the ability to innovate, while still establishing desired levels of governance, which will vary from agency to agency and resource to resource.

At the API consumer level, you can enforce / encourage interoperability using common web api approaches:

• Portal - Each API will have one or many portals where you access the APIs and supporting documentation. The availability of a portal, whether its public or private can reflect access and interoperability goals for API providers. Portal availability is the gateway to interoperability enforcement / encouragement.
  
• Registration - Even if you have access to an API resource, and it is publicly available, most APIs require registration to obtain required application keys or obtain necessary oAuth credentials. Registration can be self-service, invite only or require approval, providing all levels of enforcement / encouragement of agreements.
  
• Security - Each API provider has designated appropriate API security levels derived from a common pool of tools and standards. Consumers are guided by API provider security standards, operate within API key restrictions, oAuth identity and access restrictions, and designated service composition frameworks that are linked to security access levels. Security is not just technology, it transcends business and politics of API interoperability.
  
• Terms of Service - Every API consumer is bound by the API TOS at the point of registration, and will be legally required to agree / adhere to future changes. 
  
• Best Practices - Best practices provide a plain english explanation of legal TOS for all API consumers, ensuring that all API consumers truly execute on TOS that are set forth, cause you know, nobody reads TOS.
  
• Service Level Agreements (SLA) -  - Service Level Agreements can be extended to all API consumers as part of their service level composition, registration and TOS. SLAs provide necessary real-time expectations of system performance.
  
• Analytics - Real-time metrics are provided to API consumers letting them know the reality of their  API consumption, where they exist within service level agreements, service composition, and other aspects of API interoperability and agreements.

All the building blocks listed above provide the two-sides of the web API coin. Modern API initiatives from Amazon, Google, Twitter and thousands of other companies are proving that loosely coupled, modular approaches to API design, deployment and management provide a flexible, agile approach to interoperability that isn't as rigid as classic API approaches or networking protocols.

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? 

NO!

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 )

YES!

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

-------