Granted Patent B2

US 12,730,917 · App. 18/339,035 · Granted Sep 8, 2026

Inventors: Nagendra Kumar Nainar (Morrisville, NC); Cesar Obediente (Apex, NC); David John Zacks (Vancouver, CA); Carlos M. Pignataro (Cary, NC); Thomas Szigeti (Vancouver, CA); Craig T. Hill (Sterling, VA)

Assignee: Cisco Technology, Inc.

G06F21/6218

Abstract

Claims (81)

1 . A controller, comprising:

one or more processors; and

one or more computer-readable non-transitory storage media coupled to the one or more processors and comprising instructions that, when executed by the one or more processors, cause the controller to perform operations comprising:

generating a security policy, wherein the security policy represents a user, site, or application specific policy;

converting the security policy into a chaos hypothesis;

initiating execution of the chaos hypothesis across a plurality of microservices within a technology stack;

receiving metrics associated with the execution of the chaos hypothesis across the plurality of microservices within the technology stack, wherein the metrics represent sensor paths that are used to validate the chaos hypothesis; and

determining, based on the metrics, whether the execution of the chaos hypothesis complied with the security policy.

2 . The controller of claim 1 , the operations further comprising communicating the chaos hypothesis to a plurality of full-stack observability (FSO) agents associated with the plurality of microservices.

3 . The controller of claim 2 , wherein the FSO agents comprise one or more of the following types of FSO agents:

endpoint agents;

enterprise agents;

end user monitoring (EUM) agents; and

real user monitoring (RUM) agents.

4 . The controller of claim 1 , wherein:

initiating the execution of the chaos hypothesis across the plurality of microservices within the technology stack comprises communicating the chaos hypothesis to an endpoint agent with instructions to execute the chaos hypothesis across the plurality of microservices within the technology stack; and

receiving the metrics associated with the execution of the chaos hypothesis across the plurality of microservices within the technology stack comprises receiving the metrics from the endpoint agent.

5 . The controller of claim 1 , the operations further comprising dynamically deriving different types of chaos hypotheses for observability and policy compliance.

6 . The controller of claim 1 , wherein the security policy is associated with one of the following actions:

denying a group of users access to an application;

denying site users access to a cloud application;

denying a transaction from a user to the application; or

denying a group of users access to the application during business hours.

7 . The controller of claim 1 , wherein the chaos hypothesis comprises:

a type;

a name;

a steady state;

a hypothesis;

one or more execution actions;

one or more execution metrics; and

execution logic.

8 . A method, comprising:

generating a security policy, wherein the security policy represents a user, site, or application specific policy;

converting the security policy into a chaos hypothesis;

initiating execution of the chaos hypothesis across a plurality of microservices within a technology stack;

receiving metrics associated with the execution of the chaos hypothesis across the plurality of microservices within the technology stack, wherein the metrics represent sensor paths that are used to validate the chaos hypothesis; and

determining, based on the metrics, whether the execution of the chaos hypothesis complied with the security policy.

9 . The method of claim 8 , further comprising communicating the chaos hypothesis to a plurality of full-stack observability (FSO) agents associated with the plurality of microservices.

10 . The method of claim 9 , wherein the FSO agents comprise one or more of the following types of FSO agents:

endpoint agents;

enterprise agents;

end user monitoring (EUM) agents; and

real user monitoring (RUM) agents.

11 . The method of claim 8 , wherein:

initiating the execution of the chaos hypothesis across the plurality of microservices within the technology stack comprises communicating the chaos hypothesis to an endpoint agent with instructions to execute the chaos hypothesis across the plurality of microservices within the technology stack; and

receiving the metrics associated with the execution of the chaos hypothesis across the plurality of microservices within the technology stack comprises receiving the metrics from the endpoint agent.

12 . The method of claim 8 , further comprising dynamically deriving different types of chaos hypotheses for observability and policy compliance.

13 . The method of claim 8 , wherein the security policy is associated with one of the following actions:

denying a group of users access to an application;

denying site users access to a cloud application;

denying a transaction from a user to the application; or

denying a group of users access to the application during business hours.

14 . The method of claim 8 , wherein the chaos hypothesis comprises:

a type;

a name;

a steady state;

a hypothesis;

one or more execution actions;

one or more execution metrics; and

execution logic.

15 . One or more computer-readable non-transitory storage media embodying instructions that, when executed by a processor, cause the processor to perform operations comprising:

generating a security policy, wherein the security policy represents a user, site, or application specific policy;

converting the security policy into a chaos hypothesis;

initiating execution of the chaos hypothesis across a plurality of microservices within a technology stack;

receiving metrics associated with the execution of the chaos hypothesis across the plurality of microservices within the technology stack, wherein the metrics represent sensor paths that are used to validate the chaos hypothesis; and

determining, based on the metrics, whether the execution of the chaos hypothesis complied with the security policy.

16 . The one or more computer-readable non-transitory storage media of claim 15 , the operations further comprising communicating the chaos hypothesis to a plurality of full-stack observability (FSO) agents associated with the plurality of microservices.

17 . The one or more computer-readable non-transitory storage media of claim 16 , wherein the FSO agents comprise one or more of the following types of FSO agents:

endpoint agents;

enterprise agents;

end user monitoring (EUM) agents; and

real user monitoring (RUM) agents.

18 . The one or more computer-readable non-transitory storage media of claim 15 , wherein:

initiating the execution of the chaos hypothesis across the plurality of microservices within the technology stack comprises communicating the chaos hypothesis to an endpoint agent with instructions to execute the chaos hypothesis across the plurality of microservices within the technology stack; and

receiving the metrics associated with the execution of the chaos hypothesis across the plurality of microservices within the technology stack comprises receiving the metrics from the endpoint agent.

19 . The one or more computer-readable non-transitory storage media of claim 15 , the operations further comprising dynamically deriving different types of chaos hypotheses for observability and policy compliance.

20 . The one or more computer-readable non-transitory storage media of claim 15 , wherein the security policy is associated with one of the following actions:

denying a group of users access to an application;

denying site users access to a cloud application;

denying a transaction from a user to the application; or

denying a group of users access to the application during business hours.

Assignments (1)

Continuity (1)

References Cited (19)