Open APIs

 View Only
Back to discussions
Expand all | Collapse all

Consuming TMForum Open APIs from Channels and passing PII data via Filters

  • 1.  Consuming TMForum Open APIs from Channels and passing PII data via Filters

    Posted Oct 09, 2023 07:13

    We are in the process of establishing standardised APIs for channel applications such as App, Chatbot, Web, and more, leveraging the TM Forum Open APIs framework. Looking at TMF637 – Product Inventory - GET /product; our intention is to implement filtering mechanism as outlined in TMF630 to facilitate the retrieval of a product information using the MSISDN. The specific API call for this purpose would be:

     GET /product?filter=productCharacteristic[?(@.name=="MSISDN" && @.value==<value>)].

    It is worth noting that each product will possess a distinct identifier, typically represented as a GUID.

    However, it is crucial to acknowledge that this approach carries a potential security risk, particularly concerning Personally Identifiable Information (PII) data, as the MSISDN may be exposed through a query parameter when the API is accessed over the internet. We are interested in learning from the experiences of others who may have encountered similar challenges when exposing TM Forum APIs externally.

    What strategies or best practices have been employed to effectively mitigate this security risk while maintaining the usability and functionality of the API? Your insights and guidance would be greatly appreciated in addressing this concern.



    ------------------------------
    Willie Marais
    Vodacom (Pty) Ltd.
    ------------------------------


  • 2.  RE: Consuming TMForum Open APIs from Channels and passing PII data via Filters

    Posted Oct 10, 2023 11:50
    Edited by David Robinson Oct 10, 2023 11:55
    If the API is setup on a webserver using TLS ( https ) the query parameters will be encrypted and would not be visible to an outside attacker. You must ensure that the API is only reachable via https to ensure that an attacker cannot perform a https downgrade attack and force the webserver to expose the API over http.
     
    The logs for the API webserver will contain the query parameters so logs will needs to be treated as PII data.
     
    To solve the log issue, you could either run all logs through some sort of "scrubbing" program to remove the PII. Or depending on how MSISDNs are used and stored in your business systems, its possible that you could run the MSISDN through a cryptographic hash function such as one of the SHA-2 variants or BLAKE3 and store the resulting hash in your database along with the product record. 
     
    For example, assuming the MSISDN is 447123456789. Prepend a random "key" to the MSISDN. I will use the string "6aVYWFwUpYJNDyl7oRfC" for the example. Prepend the key to the MSISDN and run it through a cryptographic hash function.
     
    echo -n '6aVYWFwUpYJNDyl7oRfC447123456789' | sha256sum
    a24ef48d72bf43e085866cfa3677d6061b8a5654c864bdee91de01a5173ba8d4
     
     
    Now you can store the hash result, "a24ef48d72bf43e085866cfa3677d6061b8a5654c864bdee91de01a5173ba8d4" in the database as part of the product records. The API can then use the hashed version of the MSISDN to perform the search. Since the hash cannot be converted back to a MSISDN the webserver logs will not contain the MSISDN. 
     
    The "key" would have to be known to all users of the API, since it is required to calculate the MSISDN lookup hash. If the API is only of internal use, this could work. If its going to be a public API it would not be practical since you don't want the public to know the value of the "key".



    ------------------------------
    David Robinson
    Ingenuity Solutions, Inc.
    ------------------------------



Related Content