But can you hold the API to the SLA? »

Great article by Jonathon Feldman in Information Week recently with some steps for CIOs to take before getting into cloud computing.   One is to insist on SLAs from cloud providers, especially considering the natural tension from the provider's perspective between high-availability and low-cost operations.

Absolutely agree.  But to build on this - remember that scene from Seinfeld where Jerry is at the car rental counter -  "Anybody can *take* a reservation, the important part is to *hold* the reservation."

Often, cloud and API providers will agree to SLAs, but have limited means to enforce or verify the SLA is held. Many SLAs are just 'on paper' with minimal enforcement or monitoring.  This gets especially tricky if you need to discuss financial penalties. 

Consider how you will monitor, meter, and audit API traffic and content between you and your partners - from your side - in order to pinpoint problems, protect your organization, and especially if you need to enforce penalties based on SLA misses. 

API threat protection pack: 10 XML attack types to guard against »

The cost of IT security breaches has almost doubled from 2008 according to this piece via ComputerWorld Canada.

While we'd love to tell you this is just a problem for our Canadian friends - unfortunately we all need to understand API attack types.

(Remember in our Cloud security tech talks last week we saw that for breaches over a certain size you may even need to issue a press release!)

Here are 10 threats that we cover in our API threat protection policy pack. 

1. Malicious Code Injection:  exploits backend services that use SQL/LDAP/ XPATH/ XQuery statements from user-supplied input.  Servicenet ‘s Malicous Code Injection Detection policy can filter SQL,LDAP, XPATH, XQUERY injection or use Custom Regular Expression, XPATH and XSD technologies to filter the request further.   It also can integrate with anti-virus products to scan for virus in the API requests especially in the attachements or mime contents.
 
2. DOS Attacks: Denial of Service (DoS) intends to prevent an API or Service from serving normal user activity. These malicious attacks includes mega-message and entities attack, recursive element attack, request flooding, larger volume of  invalid requests etc.  The ServiceNet Message Payload protection policy detects various kind of DOS attacks and protect the backend from the attacker.
 
3. Service Information Leakage:  APIs can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of service errors.  For example verbose and informative error messages may result in data leakage, and the information revealed could be used to formulate the next level of attack. ServiceNet response Message control policies can customize fault/response message reaching the client which can weed out this attack.

4. Broken Authentication, Session id and Keys: Proper authentication, API key and session management is critical to service security. Flaws in this area most frequently involve the failure to authenticate (weak or multiple adhoc authentication schemes), weak session/key tokens that helps attacker to replay or fake the keys or tokens.   ServiceNet’s authentication and API key management policies  provides single point strong authentications and key generation techniques that frees-up API developer from attack risks.

5. Failure to protect API and corresponding Data access: Frequently, authorization is based only on base URI or operation of API.  An attacker can try passing various parameters to this API operation and get access to the data that he not authorized to access.  ServiceNet fle xible authorization policies supports authorization based on various request parameters/data not just URI or Operation name.

6  API Data snooping: Failure to encrypt sensitive API communications means that an attacker who can sniff traffic from the network will be able to access the conversation, including any credentials or sensitive information transmitted. Servicenet’s SSL or XML encryption policies can be used to secure the API data from getting snooped in the communication path.

7. API Request and Response tampering: The API data tampering attack is based on the manipulation of API request and response parameters exchanged between client and services in order to modify application data, such as user credentials and permissions, price and quantity of products, etc. Usually, this information is part of HTTP URI or Header or Body(XML or non-xml).  Servicenet’s SSL or XML signature policies can be used to secure the API request and response message from getting tampered in the communication path.

8. Request Burst: Spikes in API requests might bring down the backend server. Spike Arresting and caching helps the backend services to perform better under various load conditions.

9.  Auditing: If your API is going to be handling money, you may be required by law to adhere to certain security practices and regulations.  One important regulation is auditing every (full or part of) request or response from authorized and unauthorized users.  ServiceNet auditing policy supports very flexible way to log API audit data in various formats to different destinations like Local disk, NFS, Syslog, JMS or Web Services.

10. Threat Detection and Analysis:  Analyzing the threat data is important to find the failures and fix those failures on the API infrastructure. ServiceNet’s analytics policy provides capability to visualize and analyze various API errors or failures. It can also provide various patterns or rates of these failures that help an architect or developer to fix the problem in his or her API.

For more on API security and threat protection, check out our compliation of API roadmap issues - Is your API Naked?  And let us know if you like to see the demo of this policy pack in action.

(Senthil Doraiswamy is a product manager at Sonoa Systems.)

(And thanks misocrazy to for the photo..)

Show me the money: API Monetization »

(Next in our series on API roadmap considerations and following our last entry on "API business models")

At some point most API product managers are on the hook to demonstrate how the API results in downstream revenue.

And even if you never intend to charge for your API, you may be surprised by unexpected opportunities.

I used to be responsible for a number of ‘free open, take-it-or-leave-it APIs’ at a large Web portal. After a few months, the team was surprised to get a ton of calls from big companies that wanted to pay (a lot) for use of the API within their commercial products. 

One small detail -  they expected that the API could support some of the basic business terms of any commercial deal.  For example – could we:

• Meter service and give them a bill every month?
• Enforce a special rate limit give them an “SLA” (service level agreement)?
• Insert extra data fields if they were willing to pay for more licensed content?

We also needed some other basics:

• SOX compliant audit logs for each deal.
• Reporting on the cost of the data served by the API. (because we were licensing it from another company)
• The means to enforce similar terms on a ‘package’ of multiple APIs together in one deal

Unfortunately, all of these needed to be coded as they came up, so it was a big strain on development, PM and BD to tough to lock down and execute deals in time.

So – even if your API business model is already covered and baked in your API – you may want at least the option to support a slightly tailored or customized relationship.   You may need to quickly tailor the APIs syntax, protocol, priority, or content to a specific opportunity.

Once you have partners using an API, your business managers and partners will put your team under a lot of pressure - dollars are lost each day a business policy change takes to make.

So consider if you’ll ever need to abstract these policies – the difference between the API content and features that and the commercial business and operational terms of each deal – in an a separate API policy layer that you can manage quickly and independently of development cycles.  Or to make a single change across multiple APIs. (here's a case study on an API policy layer.)

Therefore, some questions to ask for your API roadmap might include:

General business and partner model questions:

• How is your business and revenue model supported by your API?  (are you looking for distribution and awareness only? Does the API drive a monetized transaction?  Will you ever charge for ‘pay by the API drink’?)
• How are your costs reflected in your API?  Do you pay for any of the data you are serving up?  If so, how do you keep track of this for the business and partner?
• Will large partners or deals surface where your team will need to change the API content, SLA, protocol or content?   Is there a partner that might want to pay enough and who is large enough to drive your team to move a way from “one size fits all?”
• Will you need to create ‘service tiers”?

Enforcing unique business and operational terms

• How will you meter service like a utility, so that you can bill partners and report data costs?
• What regulatory compliance will you need to support?  Do you need SOX-compliant audit trails by partner?  HIPPA?  PCI?
• How would you create and enforce a partner specific SLA, rate limit, or offer ‘priority access’ to a priority partner?
• If the partner wants any change in the API protocol or content – do you need to support a different API code-base?   Is there a way to create a transformation layer to handle and scale this?
• Do you need to buffer up or queue incoming requests?

Next time: API User management and onboarding

(and thanks to unhinderedbytalent for the photo - check out the detail on the full pic..)