PCI and your API, part 3:  Know your Data »

(This is part 3 of our series on implications of PCI compliance for your API, including previous entries on Cloud computing and PCI and Pragmatic PCI. )

You’ve hardened your processes, separated environments, encrypted tables in your DBs, trained your developers and IT staff.  Then comes your audit and your auditors jump in and run a script against your DB.  Ding, ding, ding....  Left and right you start seeing things that look like Primary Account Numbers!  What? Where? How did this happen?

One of the challenges of PCI is that you’ll be focused on your cardholder environment and your payment processing tools and applications.  Meanwhile, you’ve got API’s, web forms, chat windows, log files, support tickets and any number of other places for data to hide.  Your customers, developers and employees will likely have innocently created a PCI Compliance risk. 

What other streams does data enter your system via?  Do you have a customer support or CRM tool?  Often customers, not so PCI saavy, will send you info they shouldn’t.  An email with a Credit Card number (aka PAN) in it asking for a refund, or a chat window or a comment in an API call.

You didn’t expect this channel of communication to be used to send credit card data, yet sure enough there are a magic 16 digits uncovered at the wrong time, during your assessment.

The antidote?  Know your data.  Know what information is flowing through your system, what information is stored and what might be masked on collection or display.  If you’re an API provider, this can mean watching your APIs for sensitive information passing through.  Not only PAN data, but other data can be useful to avoid storing unencrypted or storing at all.  Social Security Numbers are another sticky piece of data you’d like to avoid if possible.

Leveraging tools to help you discover your hidden vulnerabilities is one tactic as is encrypting vulnerable tables.  Eliminating those vulnerabilities is a better route.  As we shift towards an API Economy, knowing the data passing through your APIs grows ever important in achieving and maintaining PCI compliance.

Shameless Plug#1:  Ask us about Apigee PCI Gateway Policies and how we can help you know your data.

Shameless Plug #2:  For more on this topic, tomorrow we're hosting a live webinar on "Does your API need to be PCI Compliant"?   We'll send you the video if you can't make the live webinar.

PCI and APIs in the Cloud »

Previously we talked about Pragmatic PCI and applying just enough process to ensure you understand and execute your processes in a PCI compliant manner.  

What about when you inject “The Cloud” into the picture?  

PCI Compliance isn’t something that someone can sell you and even a PCI compliant environment can be misused - creating a hole in your assessment.

What is special about the cloud from a PCI perspective?  

First off, you don’t control the physical environment and therefore you are dependent upon your provider’s physical security measures to maintain compliance.  This doesn’t need to be a problem as there are numerous providers available now that can provide “bare metal” that is certified compliant for you to work from. 

You still are likely to have the responsibility of maintaining the virtual machine environment, updating operating systems, app servers, frameworks, applications and databases.   How do you offload that responsibility even further?  PCI is all about the cardholder environment and the protection of Primary Account Numbers (PANs).  

Cloud or on-premise, the guidelines are the same and keeping your exposure minimized is key to simplifying your PCI compliance.  

Isolating your cardholder environment and ensuring servers have a single purpose is key area of compliance and if you can leverage a cloud environment and a providers physical security to meet this goal, so much the better.

For more on PCI and how it might impact your API strategy, check out our live webinar this week - "Does your API need to be PCI compliant?"  If you can't catch the webinar we'll send you the video..

(And a shameless Plug: Apigee also offers a full managed PCI-compliant Cloud API management service. )

Next up, Knowing Your Data before the Auditors Do.

Pragmatic PCI Compliance and APIs: Just Enough Process »

“If the minimum wasn’t good enough, it wouldn’t be the minimum.”  - Keith W.

Wise words from one of my developers many years ago.  When it comes to tackling PCI Compliance, it is advice well worth taking.

With leaks of sensitive customer information in the news, there’s an increased focus on compliance as more services shift to cloud computing and APIs.  

If you are a merchant of any kind or deal with customer credit card information then you must be aware of PCI compliance regulations that are designed to protect consumer credit card information from exposure.

PCI compliance gets tricky as apps and services move to cloud services and APIs.   If you’re heading down the path of PCI compliance or just trying to position yourself, your APIs and your internal systems better for the future, keeping it simple will help you be successful.

First, Document your Process

The PCI Data Security Standards (PCI DSS) establish the “what” but not the “how” of achieving compliance. 

The how is up to you. But like most audit and process centric assessments, what is most important is being able to articulate what you do to support a particular DSS item - and then being able to show evidence to support that statement.

Identify all of the process standards that apply to you from the DSS and identify the proper owner of those processes as well.  Put together a simple Process Description Template that everyone uses to document their individual processes and adopt a naming convention that calls out the DSS section.  Centralize the storage of those documents and make sure everyone knows where they are. 

Just focus on capturing the “how” of your processes in as lean a manner as possible.  Your assessment team is not going to evaluate quality of the process or the documentation, only that it meets the requirements of the DSS.

With your processes documented "well enough" and easily mapped to the PCI DSS, you’ll discover gaps, strengths and you’ll make your assessors life easier and that makes your life easier.

Next, we'll talk about the special challenges with PCI in cloud computing and APIs, and practices that you can apply to reduce your risk.

Morgan Hall is a project manager with Apigee. Previously he was Director of Business Architecture at TransUnion.

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