US-12626168-B2 - Enhancing API access controls with Markov chains and hidden Markov models

Abstract

Disclosed are various approaches for using Markov chains and hidden Markov Models to enhance API access controls for secure data. Various embodiments disclosed in this application introduce an access control application between the APIs and a data store that uses Markov chains or hidden Markov models to validate, check, or verify that the data request meets expected security guidelines. These embodiments can enhance security for all requests for data. Additionally, these embodiments can serve as an additional, automated security defense when a developer misconfigures or fails to include the appropriate validation logic within an API.

Inventors

• Hiranmayi Palanki

Assignees

• AMERICAN EXPRESS TRAVEL RELATED SERVICES COMPANY, INC.

Dates

Publication Date

20260512

Application Date

20220520

Claims (20)

1. 1 . A system, comprising: a computing device comprising a processor and a memory; and machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least: receive a data request comprising a token; determine a predicted token validation response by processing the token through a hidden Markov model; obtain, if the predicted token validation response indicates the token is valid, data from a secure data store; and send a data response.
2. 2 . The system of claim 1 , wherein the machine-readable instruction that determine a predicted token validation response, when executed, cause the computing device to at least: identify token validation response probabilities based on a state of a token, wherein each of the token validation response probabilities corresponds to a token validation response; determine a first token validation response probability having a highest probability value among the token validation response probabilities; and choose the token validation response corresponding to the first token validation response probability.
3. 3 . The system of claim 1 , wherein the token comprises an expiration datetime.
4. 4 . The system of claim 3 , wherein the expiration datetime is expired and the predicted token validation response indicates that the token is invalid.
5. 5 . The system of claim 1 , wherein the predicted token validation response indicates that the token is misconfigured and invalid.
6. 6 . The system of claim 1 , wherein the data response comprises the data.
7. 7 . The system of claim 1 , wherein the data response comprises a response code, wherein the response code indicates the token was invalid.
8. 8 . A method, comprising: receiving a data request comprising a token; determining a predicted token validation response by processing the token through a hidden Markov model; obtaining, if the predicted token validation response indicates the token is valid, data from a secure data store; and sending a data response.
9. 9 . The method of claim 8 , wherein determining a predicted token validation response comprises: identifying token validation response probabilities based on a state of a token, wherein each of the token validation response probabilities corresponds to a token validation response; determining a first token validation response probability having a highest probability value among the token validation response probabilities; and choosing the token validation response corresponding to the first token validation response probability.
10. 10 . The method of claim 8 , wherein the token comprises an expiration datetime.
11. 11 . The method of claim 10 , wherein the expiration datetime is expired and the predicted token validation response indicates that the token is invalid.
12. 12 . The method of claim 8 , wherein the predicted token validation response indicates that the token is misconfigured and invalid.
13. 13 . The method of claim 8 , wherein the data response comprises the data.
14. 14 . The method of claim 8 , wherein the data response comprises a response code, wherein the response code indicates the token was invalid.
15. 15 . A method, comprising: receiving a token comprising one or more attributes; identifying a plurality of states for the token, wherein each state of the plurality of states comprises a validation rule and an access determination; determining, based at least on the one or more attributes of the token, a first state from the plurality of states; identifying state transition probabilities between the first state and the plurality of states; choosing a second state from the plurality of states; validating the token against the validation rule of the second state; and sending a response comprising the access determination of the second state.
16. 16 . The method of claim 15 , wherein at least one of the one or more attributes of the token include an expiration datetime and a scope of accessible materials.
17. 17 . The method of claim 15 , wherein the second state from the plurality of states is chosen based at least in part on a highest probability value of the state transition probabilities.
18. 18 . The method of claim 15 , wherein the first state is an unauthorized state, the second state is an authorized state, and the access determination of the authorized state indicates that the token is authorized to access data from the data store.
19. 19 . The method of claim 15 , wherein the first state is an authorized state, the second state is an unauthorized state, and the access determination of the unauthorized state indicates that the token is unauthorized to access data from the data store.
20. 20 . The method of claim 15 , wherein each of the state transition probabilities between the first state and the plurality of states is value inclusively between zero and one and a sum of each of the state transition probabilities between the first state and the plurality of states is equal to one.

Description

BACKGROUND Software systems can use a set of Application Programming Interfaces (APIs) as a way to access stored data. In many implementations, developers of each API can be responsible for determining whether a client's request to access the stored data is valid. In development teams having many developers writing and managing these APIs, the implementation of security measures can often be prone to error, misconfigured, or outdated from expected security guidelines. For instance, an API may have broken user authentication, broken object level authorization, broken function level authorization, excessive data exposure, or, generally, various security misconfigurations. BRIEF DESCRIPTION OF THE DRAWINGS Many aspects of the present disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, with emphasis instead being placed upon clearly illustrating the principles of the disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views. FIG. 1 is a drawing of a network environment according to various embodiments of the present disclosure. FIG. 2 is a drawing of an example Markov chain according to various embodiments of the present disclosure. FIG. 3 is a drawing of an example hidden Markov model according to various embodiments of the present disclosure. FIG. 4 is a flowchart illustrating one example of functionality implemented as portions of an application executed in a computing environment in the network environment of FIG. 1 according to various embodiments of the present disclosure. FIG. 5 is a flowchart illustrating one example of functionality implemented as portions of an application executed in a computing environment in the network environment of FIG. 1 according to various embodiments of the present disclosure. FIG. 6 is a sequence diagram illustrating one example of functionality implemented as in the network environment of FIG. 1 according to various embodiments of the present disclosure. FIG. 7 is a sequence diagram illustrating one example of functionality implemented as in the network environment of FIG. 1 according to various embodiments of the present disclosure. FIG. 8 is a flowchart illustrating one example of functionality implemented as portions of an application executed on application control application in the computing environment of FIG. 1 according to various embodiments of the present disclosure. FIG. 9 is a flowchart illustrating one example of functionality implemented as portions of an application executed on application control application in the computing environment of FIG. 1 according to various embodiments of the present disclosure. DETAILED DESCRIPTION Disclosed are various approaches for using Markov chains and hidden Markov Models to enhance API access controls for secure data. Software systems can use a set of Application Programming Interfaces (APIs) as an organized way to access stored data. In many implementations, developers of each API can be responsible for determining whether a client's request to access the stored data is valid. In development teams having many developers writing and managing these APIs, the implementation of security measures can often be prone to error, misconfigured, or outdated from expected security guidelines. For instance, an API may have broken user authentication, broken object level authorization, broken function level authorization, excessive data exposure, or, generally, various security misconfigurations. There are various industries, like healthcare and financial services, where these security concerns are critical problems due to the sensitive nature of the data stored. To solve these problems, various embodiments disclosed in this application introduce an access control application between the APIs and a data store that uses Markov chains or hidden Markov models to validate, check, or verify that the data request meets expected security guidelines. These embodiments can enhance security for all requests for data. Additionally, these embodiments can serve as an additional, automated security defense when a developer misconfigures or fails to include the appropriate validation logic within an API. In the following discussion, a general description of the systems and their components are provided, followed by a discussion of the operation of the same. Although the following discussion provides illustrative examples of the operation of various components of the present disclosure, the use of the following illustrative examples does not exclude other implementations that are consistent with the principals disclosed by the following illustrative examples. With reference to FIG. 1, shown is a network environment 100 according to various embodiments. The network environment 100 can include various devices in data communication with each other via a network 103, such devices including a client device