Patent Application
20230153084
There are many methods for processing events in a computer-based distributed network. Workflows and other business logic are used to perform special processes in companies that use software for performing business processes within the company. Unfortunately, it is a difficult process to manually create such workflows and other business logic, as such programming necessitates skilled programming people with diverse security and infrastructure experience, many of whom are in short supply.
It is appreciated that it would be beneficial to provide a platform for programming common cybersecurity and productivity workflows as pieces of IT infrastructure that can be provisioned alongside other pieces of infrastructure using an infrastructure-as-code paradigm. More particularly, it is appreciated that many DevSecOps workflows in software companies, such as gating sensitive data or IT infrastructure behind access control schemes, follow an 80/20 paradigm where 80% of the effort is spent on implementing workflow primitives that are common among companies, while the remaining 20% of the effort is spent on implementing logics that are specific to the use case and system architecture of the company. Thus it is appreciated by the inventors that this paradigm creates a need for a workflow provisioning system that is generic enough to capture the commonalities across different companies' implementations, while also customizable enough to fit the exact needs of each company.
Specifically, in some embodiments, one or more event sources may be used to trigger the instantiation of workflows which perform certain actions. These event sources may be any type of entity that exists in the distributed network. Depending on the type of event source, a workflow element may be provided that processes a particular type of event. In some embodiments, these workflow elements may include templates that may be customized to process particular events. Such events, may be, for example, command line interface (CLI) input, message from messaging services such as Slack or MS Team, SMS messages, request from HTTP API endpoints, or any other type of event.
In some embodiments, common workflow primitives are provided in the form of templates, which are abstractions of the workflows that can be instantiated by an implementer in the form of flows. The templates, in some implementations, may be analogous to abstract classes in object-oriented programing, while the flows are analogous to fully defined and parameterized classes that inherit from the abstract templates. Events received from one or more systems are processed by a workflow component that is instantiated based on the type of event.
In some embodiments, the workflow elements may be combined to create a complex workflow. In some embodiments, workflow elements may be arranged in a hierarchy where one workflow can trigger another workflow. Further, in some implementations, different types of templates may be provided to perform various actions, such as, for example, an approval template that defines one or more access methods for accessing a resource of a particular type. In some embodiments, a resource in a company's system can be a sensitive database, a piece of the infrastructure that a user may request access via the system, or any other computing resource. Types of accesses that may be performed include reading, viewing, modifying, writing, execution, or other operation relating to the particular resource.
Other types of templates may be provided such as a risk assessment template. For instance, a risk assessment template may be provided that defines one or more workflows that are configured to identify an affected risk assessment datasheet based on a change in a customer's computing infrastructure. Also, a notification and review template may be provided. For example, a notification and review template may define one or more workflows that are configured to notify a user to take a certain action as part of a security-based workflow. Also, a data leak prevention template may be provided. In one example, a data leak prevention template may define one or more workflows that are configured to identify data accesses within the customer computing infrastructure. Other templates may be provided that define different actions within the computing infrastructure.
According to one aspect, a system is provided. The system comprises of a plurality of predefined workflow elements, each of the predefined workflow elements including a configurable template for accessing one or more resource types in a distributed computer system, providing for a user to selectively implement at least one of the plurality of predefined workflow elements, the at least one workflow element including a configured template, to access at least one resource of a selected resource type, and a processor configured to instantiate a runtime workflow element based on the configured template.
According to one embodiment, the configured template comprises at least one of a group comprising of a declaration of a workflow, resource information identifying the at least one resource, and logic for accessing the at least one resource. According to one embodiment, at least one resource is a computer-based entity, and wherein the processor provides access control functions to the at least one resource. According to one embodiment, at least one resource comprises a database, storage, a service, and a processing entity. According to one embodiment, the processor is configured to execute a strategy element associated with the runtime workflow element, the strategy element defining a process for accessing the at least one resource element.
According to one embodiment, the strategy element is a subcomponent of the runtime workflow element. According to one embodiment, the system further comprises a target element including information defining the at least one resource element to be accessed. According to one embodiment, the target element is a subcomponent of the runtime workflow element. According to one embodiment, the processor is configured to execute a handler element associated with the runtime workflow element, the handler element defining custom logic for executing the runtime workflow element.
According to one embodiment, the handler element includes a reducer element configured to receive an event and return a value. According to one embodiment, the handler element includes a hook element configured to alter a control flow by overriding a default behavior of the configurable template. According to one embodiment, the handler element includes an action element configured to subscribe to an event and cause an action to occur responsive to the subscribed event. According to one embodiment, the system is adapted to define a plurality of user role type for configuring how the processor creates and manages runtime workflow elements, the plurality of user role types comprising of a regular user type that uses a runtime workflow element to access the at least one resource, an integrator user type that provides integration elements for accessing a plurality of resources in an organization, and an implementer user type that is permitted to create and manage runtime workflow elements executed by the system.
According to one embodiment, the configurable template includes an approval template that defines one or more access methods for accessing the at least one resource. According to one embodiment, the system further comprises of a template interpretation engine configured to interpret a configuration definition.
According to one embodiment, the processor is adapted to receive and process a plurality of events from one or more event sources. According to one embodiment, the one or more event sources comprise at least one of a group comprising a message originated through a messaging platform, an API, a command line interface, a programmatic interface, an intersystem communication and a communication protocol message. According to one embodiment, the processor further comprises a queuer element configured to receive and queue the plurality of received events. According to one embodiment, the processor is adapted to process at least one of the plurality of received events from the queue. According to one embodiment, the processor is adapted to identify, responsive to the at least one of the plurality of received events, a workflow triggered by the event.
According to one embodiment, the processor is further adapted to instantiate a runtime workflow element and execute logic defined within the runtime workflow element. According to one embodiment, the logic defined within the runtime workflow element includes a handler element. According to one embodiment, the handler element includes a reducer element configured to receive an event and return a value. According to one embodiment, the handler element includes a hook element configured to alter a control flow by overriding a default behavior of the configurable template. According to one embodiment, the handler element includes an action element configured to subscribe to an event and cause an action to occur responsive to the subscribed event.
Still other aspects, examples, and advantages of these exemplary aspects and examples, are discussed in detail below. Moreover, it is to be understood that both the foregoing information and the following detailed description are merely illustrative examples of various aspects and examples and are intended to provide an overview or framework for understanding the nature and character of the claimed aspects and examples. Any example disclosed herein may be combined with any other example in any manner consistent with at least one of the objects, aims, and needs disclosed herein, and references to “an example,” “some examples,” “an alternate example,” “various examples,” “one example,” “at least one example,” “this and other examples” or the like are not necessarily mutually exclusive and are intended to indicate that a particular feature, structure, or characteristic described in connection with the example may be included in at least one example. The appearances of such terms herein are not necessarily all referring to the same example.
Various aspects of at least one embodiment are discussed herein with reference to the accompanying figures, which are not intended to be drawn to scale. The figures are included to provide illustration and a further understanding of the various aspects and embodiments and are incorporated in and constitute a part of this specification but are not intended as a definition of the limits of the invention. Where technical features in the figures, detailed description or any claim are followed by reference signs, the reference signs have been included for the sole purpose of increasing the intelligibility of the figures, detailed description, and/or claims. Accordingly, neither the reference signs nor their absence are intended to have any limiting effect on the scope of any claim elements. In the figures, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every figure. In the figures:
As discussed, some embodiments relate to a platform that enable users to create workflows for processing events of various types. In particular, users are provided templates for performing common cybersecurity and productivity operations that are able to be provisioned in real time. In some embodiments, these templates may process different types of events of various kinds, and deploying them reduces the effort required for creating and maintaining new workflows.
Received events are processed by a workflow execution engine (e.g., engine 101) which instantiates one or more workflows responsive to the received events. The workflows are instantiated based on templates (e.g., workflow templates 105) which are configured for particular types of events and resource types. The workflows include handler code that determines how the event is handled.
In some embodiments, the executed code performs actions on one or more infrastructure elements (e.g., infrastructure elements 106) in the distributed system 100. In some embodiments described herein, an infrastructure-as-code paradigm is used wherein infrastructure is provisioned and accessed through software via declarative code rather than have to manually configure custom code for specific deployments (e.g., within a cloud-based implementation). Such environments include, for example, cloud-based systems such as Terraform Cloud available from HashiCorp, although it is appreciated that there are other environments that may be used.
In some embodiments, workflows may be used to access resources such as databases, data elements, physical systems or other types of resources (e.g., resources 104), and such workflows may be provided to enable business processes that use these resources. To this end, certain templates may be provided to access and otherwise perform operations using these resources.
At block 402, the system received an event. A runtime workflow element is instantiated as discussed above, and the instantiated workflow processes the event (e.g., at block 403). As discussed, the workflow element may be configured to perform an action on one or more infrastructure elements (e.g., at block 404). Further, the system may be configured to send a notification and/or message responsive to the event. For example, an SMS or Slack message may be sent to one or more users, or any other type of message. Also, the system may perform one or more logging or auditing functions (e.g., at block 406). For instance, the system may write to a log file, database, or other auditing system. Further, the system may trigger one or more events (e.g., at block 407), which may lead to other workflow elements being created. A programmer user may also be permitted to create and execute defined logic (e.g., custom logic provided by the user and/or standard logic defined in the template). The system may continually scan for events and process them (e.g., at block 409, the system determines whether there are any additional events). Process 400 ends at block 410.
Such events may include or be originated from, for example, messages 506, an API 507, command line interface (CLI) 508, external processes via interprocess communication 509, external system events 510, an application program 511, protocol messages 512 or other signal types, workflow components (e.g., other workflows), among other computing entities and/or signal types. In short, workflow execution engine 502 may be configured to respond to many different types of signals and/or data occurring at various locations within distributed system 500. In some embodiments, it is appreciated that in infrastructure may be provided that permits users to quickly develop workflows that respond to many different types of events (e.g., events 501) for the purpose of performing various functions throughout distributed system 500. In some embodiments, such events may trigger processes that perform actions on infrastructure 504 and/or resources 505 of distributed system 500.
In some implementations, there are at least three types of user types (or personas) who interact with the system (or Sym platform of “Sym”) in different ways. These are:
One example implementation is a workflow template for approval which functions as a just-in-time access to sensitive resources. In some embodiments, other templates may be defined with different behaviors which process and handle different events. Integrators may be permitted to define and customize their own templates to expand and customize the system.
In some implementations described herein, the Sym infrastructure acts as an event bus, where incoming requests from various event sources, including CLI, messaging services like Slack or MS Team, HTTP API endpoints, etc. are processed by the Sym infrastructure according to the logic defined in the corresponding flow. The Sym infrastructure includes an API (e.g., the Sym Platform API 702), a workflow engine (e.g., Symflows engine 703), and a reporting component 704. In some embodiments, to access customer resources (e.g., customer A resources 707), the system also employs a runtime that uses a cross-account IAM role and one or more API keys. The Sym infrastructure may be capable of supporting multiple customers and deploying multiple workflows at various premises.
For instance, the Sym infrastructure may support accessing customer A resources 707 via a customer A Sym runtime 705, accessing customer B resources 708 via a customer B Sym runtime 706, and customer C resources 711 via a customer C Sym runtime 710. Notably, customer C Sym runtime may be implemented within a customer's AWS account whereby the API keys never leave their account. Inherently, the system is secure as the Sym infrastructure is processed through the Sym API.
The Sym platform receives the incoming Event, identifies the specific Step of a Flow that the Event is supposed to trigger, creates a RunTask that encapsulates the execution that needs to happen for that Step, and sends the RunTask to the Sym Runtime via an InternalMessage. The Runtime then executes the logic in the RunTask. The Runtime is the component of the Sym system that is responsible for executing handlers. Because of this, it is also the only component of Sym that has the credentials and ability to interact directly with client resources. The execution for each RunTask is done in a new Runtime lambda instance. These Runtimes may be either hosted within the Sym infrastructure or hosted in the customer's infrastructure for enhanced security and separation.
Because the system provides much of the logic of these workflows are pre-implemented in the system-provided libraries. For example, if a customer wants to implement a workflow where users can request access to a sensitive AWS S3 bucket by making a request through Slack, they would otherwise have to implement their own Slack bot, figure out how to programmatically change permission settings on AWS, build a database to keep track of who has request access to what, etc. However, because the system provides a predetermined template for implementing this same workflow, the implementer user would merely have to provide the requisite access credentials for AWS and Slack, define who should be able to request or approve a request, and the rest will be handled by the system. If the customer desires to modify the default behavior of the workflow defined in the template, they can write handlers (e.g., in Python) to execute some custom logic.
The Queuer 756 is a lightweight service that parses events that come in from inputs such as a Sym Slack app and puts them onto a queue 759 (e.g., a RabbitMQ queue). In some embodiments, the Queuer-Processor architecture ensures that the Queuer 756 can always be available to clients without getting bogged down on slow-running tasks. Meanwhile, the Processor 757 can be parallelized to run the async tasks.
In some embodiments, the Processor 757 is a celery worker that consumes the events from the RabbitMQ queue enqueued by the Queuer 756 and figures out which step of which flow the event triggers. Once the correct step of the correct flow is identified, the Processor 757 creates a RunTask object and sends the RunTask in an InternalMessage object to the Runtime (e.g., In-Cluster Runtime 765). The Runtime would then execute the specific logic defined in the handler associated with the RunTask. Both the Queuer and the Processor interact with a database interfacing application which provides the database models, serializers, and parsers for the Sym API Queuer and Processor.
According to some embodiments, the Sym account assumes a role within a customer account. In particular, within the Sym-hosted runtime, the role used to interface with other components of the Sym infrastructure and the role used to execute the customer-defined handlers is separated. This ensures that the handler execution is not permitted to write back to Sym in any unintended ways. Further, it allows for the handler role be defined in potentially a different account from the Sym execution role. Therefore, an implementer could use the hosted runtime, but still provision a handler role in their account. Finally, separating out the handler role enables a single Lambda deployment that is still safely multi-tenant.
For example,
In the example shown in
As discussed above with reference to
The system may then provision Sym flows 1310 within the Sym AWS account which are executed by hosted runtimes 1311. Similarly, from the customer AWS account, the self-hosted runtime may execute Sym flows which depends on runtime dependencies 1314 stored in the customer's secret configuration 1307.
The following example illustrates how Sym may integrate with third party services such as Pagerduty. As described above with respect to Sym personas, Integrators are the people who deploy the Sym platform at a company. They are responsible for configuring Integrations so that the platform can interact with the company's existing system components. Implementers are people who author new Flows. A person is a Sym Implementer if their company has set up Sym and wants to use it to roll out a new workflow.
In this example of a “PagerDuty” function integration, the Integrator is responsible for installing PagerDuty integration, which involves getting an API token from PagerDuty and declaring a “sym_integration” Terraform resource for this integration so that Implementers can refer to it in their flows. The sym_integration resource includes a setting for the secret where the API token is stored. The Implementer can then use the PagerDuty integration ID (referring to a sym_integration Terraform resource) as part of their flow definition.
As discussed above, Sym may be used as an event bus for handling different types of events. More particularly, Sym may provide a secure API channel that authenticates the user and receives programmatic requests to the Sym platform. This API channel allows the Sym system to act as a central event bus for handling types of events according to behaviors customized in Flows. As shown in
Sym platform 1505 receives events via this API channel 1504 and passes off messages to be processed by runtime 1506. In turn, runtime 1506 accesses one or more resources (customer, third party, etc.) for the purpose of performing various functions. Some of these resources include, for example, notification services 1507, cloud computing instances 1508, email/messaging services 1509, temporary authentication 1510, arbitrary HTTP integrations 1511, among other types of resources.
Use of this API event bus is discussed below in relation to example implementations.
In emergency situations, it may be needed for an engineer or other user to be able to take immediate actions on a system instead of waiting for approvals. To deal with these special situations, an Implementer can write a handler for a sym:approve Flow that checks for the “urgency” field of an event and allow for self-approval in the case of emergency. Just like under normal conditions, Sym could be configured to log these approval requests to the audit log, so that auditors can inspect the circumstances of the approval after the emergency and hold the requester accountable. It is also possible to implement in the Flow handler a logic to trigger a post-incident review once the emergency is over. The following code is an example code that implements an emergency approval:
In some cases, not all approval requests need to be manually approved by human reviewers. Instead, automatic approval based on a pre-specified set of rules would suffice. The following are a few examples of auto-approval logics that can be implemented with the Sym Python SDK.
In the above code sample, an Implementer can easily implement an auto-approve process for users who are on-call. The on_request( ) function is a customer-defined hook handler that checks if the user making a request is on-call and automatically yields an approval if so. For users who are not on-call, the on_request( ) hook would do nothing, while the get_approvers( ) reducer handler handles the standard logic of notifying the on-call managers about the access request.
Implementers can also implement auto-approvals that check with some external HTTP API endpoint. For example, there may be a scenario where a user is only allowed to take a certain action if they have completed the requisite training.
In the code sample above, the on_request( ) hook handler makes an HTTP call to a customer-specified API endpoint, which returns the training status of the user. Then, the handler is able to make an automatic rejection if the user has not completed the requisite training.
Another common use case is to base the approval decision on the role of the employee making the request or find the relevant set of approvers based on the employee's department. For example, a company may wish to implement a rule where only members of a specific engineering team shall have access to the cloud computing instances related to that team's work. For these use cases, Sym can be integrated with a directory provider such as Azure's Active Directory.
In the following code sample, the get_approvers( ) reducer is implemented such that it checks for the requesting user's department from Azure and finds the oncall manager for that department. Then it messages the group of oncall managers on Slack for approval.
Sometimes, it takes too much time and effort to manually review every access request, but we also don't want the auto-approval to be entirely based on static variables such as the user's job title. Instead, it's possible to use Sym to implement an auto-approval logic that factors in dynamic variables such as how often the user has accessed this resource in the past, the most recent time the user requested access to the resource, whether other people on the team that the user belongs to has frequently accessed the resource, etc.
In order to implement such a flow, the implementer would first need to configure a data source to read the past access history of the user. Then, the implementer can implement the logic for processing the input variables and making the auto-approve decision in the on_request( ) handler using Sym's Python SDK.
The data source could be configured in a variety of ways. In a basic implementation, the access history can be simply read from the access logs generated by Sym that logs every access request on a resource. For better performance, the implementer can also configure an intermediate data table that pre-computes the access frequency and stores the access frequency for each given user and resource directly.
In terms of the logic for determining whether a request should be auto-approved or require manual review, either a hard-coded set of policy or a machine learning algorithm that is trained on the results of manual reviews can be used. It's also potentially useful to add some randomness to the decision, so that every access request would have some non-zero probability of requiring manual review, and the probability of such can be based on a risk score outputted by a risk assessment algorithm.
From a game theory perspective, the problem of allocating limited time and effort to selectively conduct manual review on access requests can be modeled as a Stackelberg Security Game, where the attacker tries to attack some resource and the defender can only defend a subset of all resources. In such a situation, it can be shown that a “mixed strategy” where the defender stochastically chooses the set of resources to defend at a given time is more effective than a “pure strategy” where the defender chooses the set of resources to defend based on deterministic logic. An algorithm that is used to solve the Stackelberg Security Game can be potentially useful for the purpose of deciding whether to require manual review on a given access request.
SSH access to sensitive machines is often needed by engineers to do their jobs, but it carries a risk of being compromised. Using Sym to implement just-in-time SSH access can help reduce the default scope of access while allowing the engineers to get access quickly when they need it. As shown in the example process 1600 in
The get_approver( ) reducer lets the Implementer define the method by which to determine the appropriate channels for approval. In this code sample, if the requested resource is in the “prod” (production) environment, then it sends Slack DM to the list of people in the “data-security” group as specified in the Okta identity provider; if the resource is not in the sensitive prod environment, then it simply routes the request to the “ops” channel on Slack where anyone in that channel can approve.
User impersonation is a common way to provide customer support but is vulnerable to attackers who wish to abuse the mechanism. Implementers can use Sym to create just-in-time access to user impersonation Flows to add an additional layer of security as shown in the example flow 1700 shown in
In terms of implementation, a Sym-provided module (e.g., sym.django module) may provide a simple request decorator which wraps the customer's admin dashboard view that would otherwise establish a new user impersonation session (e.g., by setting a cookie). When a user visits the Sym-wrapped page (e.g., a display 1800 as shown by way of example in
The sym.django module is one example of a Sym frontend UI integration with web frameworks (in the example, Python Django). The module makes calls to the Sym API event bus mentioned previously to send impersonation approval requests to the Sym platform.
Engineers and other users may need to access sensitive data from time to time but granting default access to sensitive databases raises security and privacy concerns.
One possible flow to reduce the risk of sensitive data access is shown by way of example in
The following code sample basically implements a simplified version of the logic described above. The get_approvers( ) reducers checks for whether the request is regarding a S3 bucket, and the on_request( ) hook auto approves the user if the user is oncall.
Secrets management refers to the access control around sensitive credentials such as tokens, passwords, certificates, encryption keys for protecting secrets and other sensitive data. Implementers can use Sym to gate the access to these secrets. One potential way to implement such a workflow is to integrate Sym with a secret store service such as Hashicorp Vault.
In the workflow 2000 shown in
The flow for gating access to HashiCorp Vault can be implemented with the following sample of Python and Terraform code. In the Python implementation, the get_approver( ) reducer defines the logic for identifying the appropriate approvers and approving channels to grant the access.
In the Terraform implementation code sample below, the “sym_target” block declares the “breakglass” credential path that is managed by HashiCorp Vault (declared via the type=“vault” statement). The “sym_strategy” block declares the set of targets to include the “breakglass” target that we defined here, in addition to referencing the integration_id of the HashiCorp Vault integration.
From the user's perspective, if the user initiates the request to read the secret (e.g., using using the Sym CLI), the following is an example of how the Sym CLI would prompt the user to provide a reason for the request, wait for approval, and, when approval is granted, show the secrets in the terminal.
Sometimes, engineers or customer support representatives in a company may need a small amount of specific data from a privileged database. Sym enables the implementation of one-off query execution Flow that can quickly unblock teams without granting the ability to run arbitrary queries against the sensitive database. In the workflow 2100 shown in
The following code sample summarizes the implementation of the Flow using our Python SDK. As shown in previous use cases, the get_approver( ) reducer finds the appropriate set of approvers to approve the request. In the on_escalate( ) hook, the sql.exec( ) function from the sym.sdk.integrations package executes the query in the event against the specified database (event.params[‘db’]).
In situations where the existing set of integrations with third party services do not cover the full range of use cases, customers can integrate with tools or custom services via HTTP API endpoints. The following is an example of how a customer might integrate Sym with a custom Identity Provider (IDP) via HTTP as part of an approval flow. In the workflow 2200 shown in
In the following code sample, the get_approvers( ) reducer makes an HTTP request to “https://people.healthy-health.co” with a email parameter, and is then able to read the HTTP response where there's a boolean field “is_manager” that indicates whether the user is a manager or not. If the user is a manager, then it returns the user as a self-approver to their own request.
In situations where the primary method of gaining approval fails for some reason, implementers can write error handling logic using Sym's Python SDK in order to define fallback methods of approval. In the following code sample, the get_approver( ) reducer first tries to check PagerDuty to see if the user is oncall. If the call to PagerDuty fails, then it checks if the request corresponds to an emergency issue. If so, it allows for self approval. Finally, it tries to get the set of oncall managers and ask them for approval. If PagerDuty raises another error for some reason, it catches the error and returns the FALLBACK_APPROVERS as last resort.
The error handling mechanisms illustrated here allows for more dynamic control logic.
An AWS Lambda escalation strategy enables Sym to trigger an AWS Lambda execution when a request is approved. One way customers may want to interface with the Sym platform is to use Sym as an event bus that takes incoming requests from a Sym API endpoint, let the Sym platform parse the event according to a relatively lightweight logic defined in a Flow using Sym's Python SDK, and then trigger an AWS Lambda instance (or some other serverless cloud service) to execute some logic that is isolated from Sym. Such an escalation strategy would have multiple advantages:
There are many reasons why a user may need to be notified or reminded to take a certain action as part of a security workflow. For example, there may be some online training course that employees are required to complete, and a company's administrator may wish to notify and remind their employees to complete the training. Alternatively, a security administrator may need to be notified to review a security incident when it occurs.
While the sym:approval Template provides some basic notification functionalities such as messaging users on Slack, a dedicated notification and review Template is needed to handle some more complex aspects of notification, such as the ability to snooze a notification or schedule a notification to be sent out at some time in the future. To handle these additional complexities, Sym provides the “sym:nag” Template, which follows the following steps:
For regulatory compliance standards such as HIPAA, it may be necessary to conduct risk assessment surveys whenever a major change is made in the system. In order to stay compliant and secure, Sym may provide a Risk Assessment Template that facilitates the manual risk analysis process that security administrators have to undergo whenever a change is made to the system architecture.
The risk assessment Template example includes the following steps:
In organizations that keep a lot of their sensitive documents on cloud platforms such as Google Docs, GitHub, or Coda, it is important to have processes in place that can monitor the system to ensure that sensitive information is not made public accidentally. There are a variety of third-party tools on the market (e.g., Splunk, Panther, or other file monitoring/security systems) that can integrate with these document repositories and provide file system monitoring functionalities.
In flow 2300, the data-leak-prevention template follows the following steps:
The above-described embodiments can be implemented in any of numerous ways. For example, the embodiments may be implemented using hardware, software or a combination thereof. When implemented in software, the software code can be executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers. It should be understood that any component or collection of components that perform the functions described above can be generically considered as one or more controllers that control the above-discussed functions. The one or more controllers can be implemented in numerous ways, such as with dedicated hardware or with one or more processors programmed using microcode or software to perform the functions recited above.
In this respect, it should be understood that one implementation of the embodiments of the present invention comprises at least one non-transitory computer-readable storage medium (e.g., a computer memory, a portable memory, a compact disk, etc.) encoded with a computer program (i.e., a plurality of instructions), which, when executed on a processor, performs the above-discussed functions of the embodiments of the present invention. The computer-readable storage medium can be transportable such that the program stored thereon can be loaded onto any computer resource to implement the aspects of the present invention discussed herein. In addition, it should be understood that the reference to a computer program which, when executed, performs the above-discussed functions, is not limited to an application program running on a host computer. Rather, the term computer program is used herein in a generic sense to reference any type of computer code (e.g., software or microcode) that can be employed to program a processor to implement the above-discussed aspects of the present invention.
Various aspects of the present invention may be used alone, in combination, or in a variety of arrangements not specifically discussed in the embodiments described in the foregoing and are therefore not limited in their application to the details and arrangement of components set forth in the foregoing description or illustrated in the drawings. For example, aspects described in one embodiment may be combined in any manner with aspects described in other embodiments.
Also, embodiments of the invention may be implemented as one or more methods, of which an example has been provided. The acts performed as part of the method(s) may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.
Use of ordinal terms such as “first,” “second,” “third,” etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed. Such terms are used merely as labels to distinguish one claim element having a certain name from another element having the same name (but for use of the ordinal term).
The phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” “having,” “containing”, “involving”, and variations thereof, is meant to encompass the items listed thereafter and additional items.
Having described several embodiments of the invention in detail, various modifications and improvements will readily occur to those skilled in the art. Such modifications and improvements are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description is by way of example only, and is not intended as limiting. The invention is limited only as defined by the following claims and the equivalents thereto.
