Open APIs

How do you trust the entity calling the API?

------------------------------
Paul Bradley
GEMALTO
------------------------------

Using oauth

------------------------------
Ashish Kumar
Telstra Corporation
------------------------------

Original Message:
Sent: 07-05-2017 20:36
From: Paul Bradley
Subject: API calls

How do you trust the entity calling the API?

------------------------------
Paul Bradley
GEMALTO
------------------------------

That seems like a very open ended question and a interesting topic of discussion.  It is fair to say that as security methods get more sophisticated so does the desire to break them.  The traditional methods of securing a API is to use something like:

* Static Strings;
* Dynamic tokens; or
* User delegated tokens (such as oAuth).

However while dynamic tokens and delegated tokens can offer protection against network sniffers etc, they can not protect against human engineering threats etc.  The other question is what is your API doing and where does it sit in your infrastructure.  A public API that is aimed for B2B transactions is going to be far more vulnerable than a internal API that is used for SOA communication between two internal systems.

To me there are things outside of trusting the API itself. What I mean is ensure that the API engages Single Responsibility Principle (SRP).  This will not guard against threats but it will ensure the damage that a uninvited intruder can cause is minimized.  Too often you see API's written that will give access or information to things that have nothing to do with the intention of the API.

Also I am weary of using third parties including certificate authorities for verification, yea that may be some paranoia playing out, but basically we are putting our business in the hands of a external entity in the hope that they will not be doing the right things in order to verify external entities.  If this is used in conjunction with other security measures (multi level security) then it is fine.  

Also if the damage that a potential intruder can cause is limited then that is also fine, but this should be audited when new features are added to the API.  Personally I am a believer in Authentication, Authorization and Auditing (AAA)   for API's.  There is no problem with using HTTPS to transmit JSON data and then enclose that data in a PGP certificate which is known to the host and the user.  Would love to hear what others feel about this topic.  With recent events it certainly is a hot one.

------------------------------
Aaron Spiteri
iiNet Limited
------------------------------

Original Message:
Sent: 07-05-2017 20:36
From: Paul Bradley
Subject: API calls

How do you trust the entity calling the API?

------------------------------
Paul Bradley
GEMALTO
------------------------------

I have been working recently on this topic for a big company in the Entertainment sector in France.
Here is a summary of what we defined, with the support of security consultants :
1) Trust of an API consumer should deal both whith authentification (ie. who are you and did I allow you to connect with me ?) and habilitation (ie. are you allowed to call that specific API ?). This is included in what we call a security policy.
2) This controls should be centralized in an infrastructure middleware, not directly into applications, for several reasons :
     - Ensure the security policy is applied in an homogeonous manner
     - Give a central view and supervision of all the security policies within the company
     - Organize a centralized governance of those security policies
     - Focus applications on business requirements
3) The appropriate middleware should be :
     - An enterprise service bus (ESB) for the calls within the company (eg. SoftwareAG webMethods, Tibco BW, IBM Datapower ...)
     - An API management gateway for the calls with external partners (eg. Axway API Management Platform, Apigee, CA/Layer7...)
4) Those policies can be instanciated through several standard protocols :
     - Authentification protocol (lightest to strongest) : HTTP Basic, Digest / HTTP Header /  IP trust / Oauth / API Keys /JSON Web Token (JWT)
     - Encryption through HTTPS
     - Refer to OWASP Guide 2.0.1 - Strong Authentication
5) The authentification and habilitation should be considered at the two levels
     - End user : authentification and habilitation of the end users is ensured by portals (through SSO, LDAP...), before any API call.
     - Application : the API middleware ensures authentification of the calling application, without any end user consideration

------------------------------
Matthieu LEMOINE
Senior Enterprise Architect
Sopra Steria - Telecom, Media & Entertainment
------------------------------

Original Message:
Sent: 07-06-2017 01:05
From: Aaron Spiteri
Subject: API calls

That seems like a very open ended question and a interesting topic of discussion.  It is fair to say that as security methods get more sophisticated so does the desire to break them.  The traditional methods of securing a API is to use something like:

* Static Strings;
* Dynamic tokens; or
* User delegated tokens (such as oAuth).

However while dynamic tokens and delegated tokens can offer protection against network sniffers etc, they can not protect against human engineering threats etc.  The other question is what is your API doing and where does it sit in your infrastructure.  A public API that is aimed for B2B transactions is going to be far more vulnerable than a internal API that is used for SOA communication between two internal systems.

To me there are things outside of trusting the API itself. What I mean is ensure that the API engages Single Responsibility Principle (SRP).  This will not guard against threats but it will ensure the damage that a uninvited intruder can cause is minimized.  Too often you see API's written that will give access or information to things that have nothing to do with the intention of the API.

Also I am weary of using third parties including certificate authorities for verification, yea that may be some paranoia playing out, but basically we are putting our business in the hands of a external entity in the hope that they will not be doing the right things in order to verify external entities.  If this is used in conjunction with other security measures (multi level security) then it is fine.  

Also if the damage that a potential intruder can cause is limited then that is also fine, but this should be audited when new features are added to the API.  Personally I am a believer in Authentication, Authorization and Auditing (AAA)   for API's.  There is no problem with using HTTPS to transmit JSON data and then enclose that data in a PGP certificate which is known to the host and the user.  Would love to hear what others feel about this topic.  With recent events it certainly is a hot one.

------------------------------
Aaron Spiteri
iiNet Limited
------------------------------

Original Message:
Sent: 07-05-2017 20:36
From: Paul Bradley
Subject: API calls

How do you trust the entity calling the API?

------------------------------
Paul Bradley
GEMALTO
------------------------------

Hi Matthieu,

That is great response.  I picked up some usful tips that.

------------------------------
Aaron Spiteri
iiNet Limited
------------------------------

Original Message:
Sent: 07-07-2017 04:07
From: Matthieu LEMOINE
Subject: API calls

I have been working recently on this topic for a big company in the Entertainment sector in France.
Here is a summary of what we defined, with the support of security consultants :
1) Trust of an API consumer should deal both whith authentification (ie. who are you and did I allow you to connect with me ?) and habilitation (ie. are you allowed to call that specific API ?). This is included in what we call a security policy.
2) This controls should be centralized in an infrastructure middleware, not directly into applications, for several reasons :
     - Ensure the security policy is applied in an homogeonous manner
     - Give a central view and supervision of all the security policies within the company
     - Organize a centralized governance of those security policies
     - Focus applications on business requirements
3) The appropriate middleware should be :
     - An enterprise service bus (ESB) for the calls within the company (eg. SoftwareAG webMethods, Tibco BW, IBM Datapower ...)
     - An API management gateway for the calls with external partners (eg. Axway API Management Platform, Apigee, CA/Layer7...)
4) Those policies can be instanciated through several standard protocols :
     - Authentification protocol (lightest to strongest) : HTTP Basic, Digest / HTTP Header /  IP trust / Oauth / API Keys /JSON Web Token (JWT)
     - Encryption through HTTPS
     - Refer to OWASP Guide 2.0.1 - Strong Authentication
5) The authentification and habilitation should be considered at the two levels
     - End user : authentification and habilitation of the end users is ensured by portals (through SSO, LDAP...), before any API call.
     - Application : the API middleware ensures authentification of the calling application, without any end user consideration

------------------------------
Matthieu LEMOINE
Senior Enterprise Architect
Sopra Steria - Telecom, Media & Entertainment
------------------------------

Original Message:
Sent: 07-06-2017 01:05
From: Aaron Spiteri
Subject: API calls

That seems like a very open ended question and a interesting topic of discussion.  It is fair to say that as security methods get more sophisticated so does the desire to break them.  The traditional methods of securing a API is to use something like:

* Static Strings;
* Dynamic tokens; or
* User delegated tokens (such as oAuth).

However while dynamic tokens and delegated tokens can offer protection against network sniffers etc, they can not protect against human engineering threats etc.  The other question is what is your API doing and where does it sit in your infrastructure.  A public API that is aimed for B2B transactions is going to be far more vulnerable than a internal API that is used for SOA communication between two internal systems.

To me there are things outside of trusting the API itself. What I mean is ensure that the API engages Single Responsibility Principle (SRP).  This will not guard against threats but it will ensure the damage that a uninvited intruder can cause is minimized.  Too often you see API's written that will give access or information to things that have nothing to do with the intention of the API.

Also I am weary of using third parties including certificate authorities for verification, yea that may be some paranoia playing out, but basically we are putting our business in the hands of a external entity in the hope that they will not be doing the right things in order to verify external entities.  If this is used in conjunction with other security measures (multi level security) then it is fine.  

Also if the damage that a potential intruder can cause is limited then that is also fine, but this should be audited when new features are added to the API.  Personally I am a believer in Authentication, Authorization and Auditing (AAA)   for API's.  There is no problem with using HTTPS to transmit JSON data and then enclose that data in a PGP certificate which is known to the host and the user.  Would love to hear what others feel about this topic.  With recent events it certainly is a hot one.

------------------------------
Aaron Spiteri
iiNet Limited
------------------------------

Original Message:
Sent: 07-05-2017 20:36
From: Paul Bradley
Subject: API calls

How do you trust the entity calling the API?

------------------------------
Paul Bradley
GEMALTO
------------------------------

Matthieu
​Very interesting post and quite complementary to some work we have just published from ZOOM  in Release 17
TR263D Platform Security and Policy Management R17.0.0
This is out for members' comment. It's likely we will do some update in Release 17-5 and I am wondering if some of the material posted here could be used as an example. The one used in the current version is the CSA Software Defined Perimeter (SDP) proposal but are aware that there are other possibilities some of which we listed.

Regards

------------------------------
Dave Milham
TM Forum Chief Architect ZOOM SP engagement
------------------------------

Original Message:
Sent: 07-07-2017 04:07
From: Matthieu LEMOINE
Subject: API calls

I have been working recently on this topic for a big company in the Entertainment sector in France.
Here is a summary of what we defined, with the support of security consultants :
1) Trust of an API consumer should deal both whith authentification (ie. who are you and did I allow you to connect with me ?) and habilitation (ie. are you allowed to call that specific API ?). This is included in what we call a security policy.
2) This controls should be centralized in an infrastructure middleware, not directly into applications, for several reasons :
     - Ensure the security policy is applied in an homogeonous manner
     - Give a central view and supervision of all the security policies within the company
     - Organize a centralized governance of those security policies
     - Focus applications on business requirements
3) The appropriate middleware should be :
     - An enterprise service bus (ESB) for the calls within the company (eg. SoftwareAG webMethods, Tibco BW, IBM Datapower ...)
     - An API management gateway for the calls with external partners (eg. Axway API Management Platform, Apigee, CA/Layer7...)
4) Those policies can be instanciated through several standard protocols :
     - Authentification protocol (lightest to strongest) : HTTP Basic, Digest / HTTP Header /  IP trust / Oauth / API Keys /JSON Web Token (JWT)
     - Encryption through HTTPS
     - Refer to OWASP Guide 2.0.1 - Strong Authentication
5) The authentification and habilitation should be considered at the two levels
     - End user : authentification and habilitation of the end users is ensured by portals (through SSO, LDAP...), before any API call.
     - Application : the API middleware ensures authentification of the calling application, without any end user consideration

------------------------------
Matthieu LEMOINE
Senior Enterprise Architect
Sopra Steria - Telecom, Media & Entertainment
------------------------------

Original Message:
Sent: 07-06-2017 01:05
From: Aaron Spiteri
Subject: API calls

That seems like a very open ended question and a interesting topic of discussion.  It is fair to say that as security methods get more sophisticated so does the desire to break them.  The traditional methods of securing a API is to use something like:

* Static Strings;
* Dynamic tokens; or
* User delegated tokens (such as oAuth).

However while dynamic tokens and delegated tokens can offer protection against network sniffers etc, they can not protect against human engineering threats etc.  The other question is what is your API doing and where does it sit in your infrastructure.  A public API that is aimed for B2B transactions is going to be far more vulnerable than a internal API that is used for SOA communication between two internal systems.

To me there are things outside of trusting the API itself. What I mean is ensure that the API engages Single Responsibility Principle (SRP).  This will not guard against threats but it will ensure the damage that a uninvited intruder can cause is minimized.  Too often you see API's written that will give access or information to things that have nothing to do with the intention of the API.

Also I am weary of using third parties including certificate authorities for verification, yea that may be some paranoia playing out, but basically we are putting our business in the hands of a external entity in the hope that they will not be doing the right things in order to verify external entities.  If this is used in conjunction with other security measures (multi level security) then it is fine.  

Also if the damage that a potential intruder can cause is limited then that is also fine, but this should be audited when new features are added to the API.  Personally I am a believer in Authentication, Authorization and Auditing (AAA)   for API's.  There is no problem with using HTTPS to transmit JSON data and then enclose that data in a PGP certificate which is known to the host and the user.  Would love to hear what others feel about this topic.  With recent events it certainly is a hot one.

------------------------------
Aaron Spiteri
iiNet Limited
------------------------------

Original Message:
Sent: 07-05-2017 20:36
From: Paul Bradley
Subject: API calls

How do you trust the entity calling the API?

------------------------------
Paul Bradley
GEMALTO
------------------------------

As Dave mentioned, we encourage everybody to have a look at the Cloud Security Alliance's Software Defined Perimeter concept.
See https://en.wikipedia.org/wiki/Software_Defined_Perimeter and https://cloudsecurityalliance.org/group/software-defined-perimeter.

What this would give you In the context of this discussion is
- A central place to define policies. These policies can be dynamic, i.e. the authentication decision can take other things than just the access credentials into account (i.e. geolocation of IP, time of day, identity of originating device, etc.). Only access to authorized APIs will be provided.
- A central place for integration with the Identity and Access management (IAM) system.
- Enhanced security because SDP 'blackens' the network to non-authorized users (a portscan would not return anything). Authorized users will be only able to see the services that they are entitled to.
- Automatic establishment of encrypted communication channels between participants.

In addition to the Auth/AuthZ discussion I'd like to add that it seems very important to do a threat analysis on all (especially the externally exposed) APIs:
- Is it a good idea to have this API in the first place?
- If so, who should be authorized to access it? (*)
- Should there be different access levels for different user types?
- Is more information exposed than what is absolutely necessary for the API to fulfill its function (see Aaron's comment)?
- Is there a need to context-based access restrictions?

Best regards,
Alexander

(*) The standard bad example here is SS7: If there would have been some kind of threat analysis before the MAP extensions where introduced, it would have been obvious that it's probably not a good idea to allow operators that are neither the home network or the roaming network access location information of subscribers.

------------------------------
Alexander Rockel
Oracle Corporation
------------------------------

Original Message:
Sent: 07-12-2017 04:06
From: Dave Milham
Subject: API calls

Matthieu
​Very interesting post and quite complementary to some work we have just published from ZOOM  in Release 17
TR263D Platform Security and Policy Management R17.0.0
This is out for members' comment. It's likely we will do some update in Release 17-5 and I am wondering if some of the material posted here could be used as an example. The one used in the current version is the CSA Software Defined Perimeter (SDP) proposal but are aware that there are other possibilities some of which we listed.

Regards

------------------------------
Dave Milham
TM Forum Chief Architect ZOOM SP engagement
------------------------------

Original Message:
Sent: 07-07-2017 04:07
From: Matthieu LEMOINE
Subject: API calls

I have been working recently on this topic for a big company in the Entertainment sector in France.
Here is a summary of what we defined, with the support of security consultants :
1) Trust of an API consumer should deal both whith authentification (ie. who are you and did I allow you to connect with me ?) and habilitation (ie. are you allowed to call that specific API ?). This is included in what we call a security policy.
2) This controls should be centralized in an infrastructure middleware, not directly into applications, for several reasons :
     - Ensure the security policy is applied in an homogeonous manner
     - Give a central view and supervision of all the security policies within the company
     - Organize a centralized governance of those security policies
     - Focus applications on business requirements
3) The appropriate middleware should be :
     - An enterprise service bus (ESB) for the calls within the company (eg. SoftwareAG webMethods, Tibco BW, IBM Datapower ...)
     - An API management gateway for the calls with external partners (eg. Axway API Management Platform, Apigee, CA/Layer7...)
4) Those policies can be instanciated through several standard protocols :
     - Authentification protocol (lightest to strongest) : HTTP Basic, Digest / HTTP Header /  IP trust / Oauth / API Keys /JSON Web Token (JWT)
     - Encryption through HTTPS
     - Refer to OWASP Guide 2.0.1 - Strong Authentication
5) The authentification and habilitation should be considered at the two levels
     - End user : authentification and habilitation of the end users is ensured by portals (through SSO, LDAP...), before any API call.
     - Application : the API middleware ensures authentification of the calling application, without any end user consideration

------------------------------
Matthieu LEMOINE
Senior Enterprise Architect
Sopra Steria - Telecom, Media & Entertainment
------------------------------

Original Message:
Sent: 07-06-2017 01:05
From: Aaron Spiteri
Subject: API calls

That seems like a very open ended question and a interesting topic of discussion.  It is fair to say that as security methods get more sophisticated so does the desire to break them.  The traditional methods of securing a API is to use something like:

* Static Strings;
* Dynamic tokens; or
* User delegated tokens (such as oAuth).

However while dynamic tokens and delegated tokens can offer protection against network sniffers etc, they can not protect against human engineering threats etc.  The other question is what is your API doing and where does it sit in your infrastructure.  A public API that is aimed for B2B transactions is going to be far more vulnerable than a internal API that is used for SOA communication between two internal systems.

To me there are things outside of trusting the API itself. What I mean is ensure that the API engages Single Responsibility Principle (SRP).  This will not guard against threats but it will ensure the damage that a uninvited intruder can cause is minimized.  Too often you see API's written that will give access or information to things that have nothing to do with the intention of the API.

Also I am weary of using third parties including certificate authorities for verification, yea that may be some paranoia playing out, but basically we are putting our business in the hands of a external entity in the hope that they will not be doing the right things in order to verify external entities.  If this is used in conjunction with other security measures (multi level security) then it is fine.  

Also if the damage that a potential intruder can cause is limited then that is also fine, but this should be audited when new features are added to the API.  Personally I am a believer in Authentication, Authorization and Auditing (AAA)   for API's.  There is no problem with using HTTPS to transmit JSON data and then enclose that data in a PGP certificate which is known to the host and the user.  Would love to hear what others feel about this topic.  With recent events it certainly is a hot one.

------------------------------
Aaron Spiteri
iiNet Limited
------------------------------

Original Message:
Sent: 07-05-2017 20:36
From: Paul Bradley
Subject: API calls

How do you trust the entity calling the API?

------------------------------
Paul Bradley
GEMALTO
------------------------------