Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/55—Detecting local intrusion or implementing counter-measures
  • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
  • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
  • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
  • G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
  • G06F3/0482—Interaction with lists of selectable items, e.g. menus
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
  • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
  • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
  • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
  • G06F3/04842—Selection of displayed objects or displayed text elements
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
  • G06T11/00—Two-dimensional [2D] image generation
  • G06T11/20—Drawing from basic elements
  • G06T11/26—Drawing of charts or graphs
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
  • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
  • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
  • G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
  • G06F3/0483—Interaction with page-structured environments, e.g. book metaphor
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
  • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
  • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
  • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
  • G06F3/0486—Drag-and-drop
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
  • H04L63/0227—Filtering policies
  • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic

Definitions

• the technology described herein relates to the creation of threat response actions within a computer network and, more particularly, to the use of a graphical user interface in the form of process workflow representation tools that are used to build response actions.
• Cyber-security detection and response systems may be configured to aggregate and unify data from multiple devices, components, and platforms on a computer network.
• Security administrators often design and implement a standard operating procedure of device- actions taken by security individuals in response to a security incident. Based on the nature of a particular threat, the cyber-security system may initiate an action plan that is tailored to the security operations center and its operating procedures to protect potentially impacted components and network resources.
• the goal of cyber-security systems is to provide rapid and reliable, enterprise-wide threat responses, e.g., to mitigate threats, survive breaches, and maintain operations during attacks.
• security administrators often program preconfigured response plans for implementation upon recognition of a cyber- security threat.
• the cyber-security system can thus provide system configuration instructions to defend against threats originating both external to and internal to the network.
• the technology disclosed herein provides a graphical user interface through which users, generally network security administrators, can quickly and easily create one or more courses of action for automatic response to a network threat.
• the courses of action are hardware and system agnostic, which allows a common response task to be implemented by an underlying response engine for any or multiple similar-function devices regardless of brand or version.
• the course of action builder allows the administrator to use a simple, graphic-based, business modeling concept to craft and design security response processes rather than having to hard code response routines specific to each piece of hardware on the network.
• the graphic interface model allows the user of the threat response software incorporating the course of action builder to easily understand the overall flow and paths the response may take, as well as understand the data requirements and dependencies that will be evaluated.
• Fig. 1 is a schematic diagram of an exemplary course of action representation built in a graphical user interface for creating automated network security threat response action protocols.
• Fig. 2 is a flow diagram of a process implemented through a graphical user interface for building a course of action for an automated network security threat response.
• Fig. 3 is an exemplary screenshot of a plugin interface within a course of action builder for selection of available network device plugins and registration with network devices.
• Fig. 4 is an exemplary screenshot of an interface for defining input parameter values specific to a command implemented by a network device plug-in.
• Fig. 5 is a schematic diagram of a process for registration of network device interface plugins with network devices.
• Fig. 6A is an exemplary screenshot of a workflow palate provided by a graphical user interface in a course of action builder with an array of stencil icons.
• Fig. 6B is an exemplary screenshot of a workflow palate provided by a graphical user interface in a course of action builder with a start node and an initial task
• Fig. 7 is an exemplary screenshot of a task configuration window opening within the workflow plate to provide an interface for configuring the task.
• Fig. 8 is an exemplary screenshot of additional layers of the task configuration window of Fig. 7.
• Fig. 9A is an exemplary screenshot of a parameter selection element of the task configuration window of Fig. 7.
• Fig. 9B is an exemplary screenshot of a completed parameter selection of the task configuration window of Fig. 7.
• Fig. 10 is an exemplary course of action workflow created with the course of action builder graphical user interface.
• Fig. 11 is schematic diagram of a special purpose computer configured to implement a course of action builder module for building a course of action for an automated network security threat response.
• a cyber-security response system allows a user to agnostically configure appropriate threat responses by multiple devices, components, and platforms on a computer network.
• Security administrators can utilize the solution to design and implement a workflow of device-actions to be automatically implemented in response to a security incident.
• the cyber-security response system may initiate an action plan that is tailored to the security operations center (SOC) and its operating procedures to protect potentially impacted components and network resources.
• SOC security operations center
• the cyber-security system Upon recognition of a cyber-security threat, through preconfigured activation workflow plans, the cyber-security system automatically provides system configuration instructions to defend against threats originating both external to and internal to the network.
• a course of action can be represented in the GUI as a workflow or a sequence of tasks can be generated by the workflow.
• a CoA response may be built via an intuitive GUI that provides drag and drop base elements in combination with configuration features that transform the graphic elements into specific command or task representations linked to implementable instructions to control devices on the network.
• Particular network devices are identified during build-out of the CoA and are associated with device plug-ins.
• the device plug-ins are built to interact with the specific application program interface (API) of the network device and are configured with specific activation routines that can activate or configure the network device in ways that are helpful to blocking or remediating a network security threat.
• API application program interface
• the device plug-ins receive device configuration information from the CoA, identify input parameter information necessary to control the particular device to perform a specific task or action, and identify output information generated by the device when performing the action.
• a CoA visually depicts the flow of tasks (also referred to herein as "workflow") that can occur when a particular cyber security event occurs and allows users to manage the event response.
• the tasks represented in the CoA are implemented in response to a threat event by a separate but integrated application layer of the cyber-security response system referred to herein as the "Orchestration Engine.”
• the Orchestration Engine executes the instructions identified by the CoA when processing inbound events to automatically remediate threats.
• the Orchestration Engine reads the tasks in the CoA, calls on the particular plug-ins associated with network devices identified in the CoA task to provide device-specific action instructions, passes the necessary input and output parameters to and from the CoA, the plug- ins, and the devices, and processes the CoA workflow in the designed order.
• each CoA is device and platform agnostic.
• the CoA may be represented in extensible markup language (XML) and the XML file for a CoA defining a response to a threat can be shared from one organization to another that also have a compatible cyber-security response system. While the response management system needs to be compatible, the network configuration and devices thereon can be entirely different between organizations, and the CoA can still work. For example, one organization may have two firewall components while a second organization has ten firewall components. The firewall devices may be made by different manufacturers.
• the CoA can generically state that the task is to activate or configure a firewall in a certain way.
• the underlying Orchestration Engine can thus recognize which device plug-ins correspond to firewall devices that have been registered with the cyber-security response system and then use the values in the generic input parameters received from the CoA to configure the plug-ins to actuate the devices and manage the threat response.
• a library of courses of actions (actionable workflows, sequence of actions, or sequence of tasks) so processes are centrally managed and executed in a high-confidence, repeatable fashion via a graphical user interface.
• Such a library may be maintained as a repository of automated response procedures that can be updated at any time. This gives organizations a single place to go to update a process where it can take effect with zero variation due to it being automated. Any CoAs within a library can be consumed by the Orchestration Engine and automatically executed as soon as they are updated. This leaves zero lag time between the implementation or update of a process and the execution of it.
• a benefit of a CoA library is that effective threat response processes can be stored to reduce loss of human created know-how when human resources leave.
• FIG. 1 An exemplary, generic course of action workflow for a threat response that may be designed in the CoA Builder module is depicted in Fig. 1.
• the CoA 100 is built using a graphical user interface. The purpose is to detail the sequence of tasks necessary for a threat response and make references to the plug-in and calls to its components needed for the desired device action.
• the CoA may be stored as a JavaScript Object Notation (JSON) object or other similar data-interchange format.
• JSON JavaScript Object Notation
• the CoA does not store code, but instead stores references to the plug-in data and maintains the sequence, order, and conditions by which each task is executed.
• the CoA 100 also records what input parameters are available based on the tasks chosen and displays the possible output parameters of those tasks based on the existing references to the plug-in data.
• the start node 102 of any given CoA 100 is intended to serve as a trigger event.
• the trigger event is used to create context around the CoA 100 since the sequence of steps is in response to the inbound event.
• the start node 102 can ask the user to select an "adapter."
• the adapter could be anything that would serve as the source of the event requiring response, such as an email, or a sys.log message from a security information and event management (SIEM) application.
• SIEM security information and event management
• the user can create a trigger condition associated with the start node 102, which is an evaluation of the incoming data. If the condition is met, the CoA 100 can execute. If the condition is not met, the CoA 100 cannot execute.
• the trigger condition serves as the business justification for execution of the CoA 100.
• a specific adapter can be the start node 102 of more than one CoA 100.
• the second step to configuring the start node 102 is to select the specific output parameters from the adapter that you wish to make available to the downstream tasks in the CoA 100. Since the instantiation of the adapter in a particular CoA 100 is specific to the trigger condition, the user may also select any data elements considered important for the particular CoA 100 to output as output parameters. This can be contextually different for each CoA into which the adapter is incorporated since the instantiation of the particular CoA is specific to the trigger condition. The output parameters can be selected in the CoA building process. The result of this step is the definition of trigger or start conditions and output parameters from the adapter event.
• one or more tasks 104 are then configured to build the workflow of the CoA 100.
• Configuration of a task 104 involves selecting the following: a device plug-In, a command, and input parameters for the command.
• the CoA Builder application knows the available devices due to a reference provided in a device table. Plug-in and device registration can be described in detail later herein in association with Figs. 3-5.
• the plug-in registration information the associated commands are then presented to the user to select. Once the user selects the command to execute, the plug-in registration information is once again called to provide prompts for the user to enter the input parameters into the task 104.
• the CoA Builder may allow the user to input the required input parameters by either selecting from the available ones output from an upstream adapter or task 104. Alternatively, the CoA Builder may allow the user to create a custom parameter value with operators such as "begins with,” “contains,” etc. This provides the flexibility to define a parameter not previously pulled in the workflow, or define something "hard coded” rather than variable.
• the configuration of the task 104 is complete.
• the output parameters are automatically output and made available to the downstream CoA tasks so they may also consume or evaluate them.
• the CoA 100 may additionally include decision points 106, 112 in paths of the flow to determine whether additional tasks in the workflow should be performed or to choose between alternate tasks.
• Configuration of a decision point 106, 112 works similarly to a task 104, except that a specific plug-in is not input.
• the decision point 106, 112 is used to perform an evaluation to determine if the path should continue.
• Configuration of the decision point 106, 112 also utilizes the graphical user interface to allow the user to construct a conditional statement that can be evaluated to be true or false. For example, if a parameter value is "true,” the path may continue; alternatively, if a parameter value is "false,” the path may not continue. Any data that has been output from start node 102 or task 104 can be available for evaluation.
• Sub-processes 108 can also be incorporated in to CoA 100. This provides the ability to maintain a highly repeatable sequence of tasks and add it in to another CoA without having to recreate it multiple times or maintain multiple instantiations of the same sequence.
• specific input parameters for the sub-CoA 108 are also defined.
• those input parameters from the parent CoA 100 can be mapped similarly to a task 104 so all the individual tasks within that sub-CoA 08 can run.
• a sub-CoA 108 can be designed to run either as an automated action sequence or to run when manually initiated by a user. The latter may require an approval step within a separate authorization tool whereby the sub-CoA 108 can be "recommended" to run and the user may choose to activate it by clicking on it.
• End points 110, 114 simply define the end of the CoA 100 and signal to the Orchestration Engine that no further tasks need to be performed.
• Fig. 2 depicts an exemplary process 200 for allowing a user to configure a CoA using the CoA Builder GUI tools.
• the steps in Fig. 2 can further be explained with reference to Figs. 3-9.
• a preliminary step 202 in configuring a CoA is to register and appropriate device plug-ins within the cyber-security response system that correspond to network components or appliances on the network to be protected.
• a library 300 with a section 316 for device plug-ins 302 may be provided as part of CoA Builder platform.
• a plug-in 302 (or connector) is an integration to a third party product (device) that is used to either extract information or modify a policy.
• Plug-ins 302 are code packs that allow the application to communicate with external devices and applications.
• the plug-ins 302 allow for communication with network devices and appliances to occur with specific protocols and technologies necessary based on the application protocol interface (API) dictated by the external device.
• API application protocol interface
• Each third party product has an available library of commands which they make available to call devices via an API.
• Plug-ins 302 developed for the CoA Builder module are provided with commands that serve a purpose in cyber security or network management policies. All plug-ins 302 developed for one or more cyber security applications are delivered with at least one command. Plug-in commands generally correlate directly with a "task" that one would see in a standard operating procedure for security response. Therefore, for a plug-in associated with a firewall, a highly utilized command would be to block an IP Address. Different vendors may call the command something different. One may call it "block IP” and another may call it “BlockIP,” whereas another may use a ID number like "8012A". There is no standard naming convention from product to product, or from one vendor to another.
• the plug-in commands are aliased to a common and easy to understand action, such as Block IP Address.
• the alias would be displayed so the user can quickly understand the task and select it.
• Aliasing of commands is a technique used throughout the CoA Builder so users can quickly understand the content on the screen and proceed with their operation more efficiently and accurately.
• a plug-in 302 is often related to a specific product, for example, a Cisco ® ASA Firewall, Microsoft ® Active Directory, or iSight Threatscape.
• a plug-in when a plug- in is selected, such as selected plug-in 304, an interface 306 may be provided to configure the selected plug-in 304.
• Each plug-in can have at least one command 308.
• the commands button 308 is highlighted and a number of specific commands 312 associated with the selected plugin 304 are presented.
• Commands 308 are functions that can leverage an API to perform some kind of action on the network asset/device/appliance.
• Commands 308 are also incorporated in to CoA workflows as "tasks" performed within the CoA.
• Each command 308 may have a predefined set of input parameters 310 that are required for the plug-in command 312 to start/run.
• Each command can also have a predefined set of output parameters that are the result of the command running.
• the particular input parameters 404 associated with the selected command 402 can be presented for review in a plug-in registration window 400 and possible population by the user.
• the user can select a separate parameters button 310 to review all of the parameters associated with the selected plug-in 304 directly, without reference to a particular command 312.
• Input parameters are tagged with a name or alias, as well as a type which indicates the kind of data required such as number, date, etc.
• Some input parameters 408 may require population (e.g., device identification and password parameters), while other parameters 406 may either be populated at this time if the value is static or may instead be populated by output parameter data generated by an upstream task in a CoA. These output data elements can be consumed by tasks downstream in the workflow. The result of one task can become an input to the start of another task. This makes the process of building a CoA very simple.
• the abstracted parameters create interoperability between disparate devices within the network and security system of an organization.
• Entities may have more than one instance of a particular product or device. These instances can each have discrete configurations based upon, for example, differences in model number, port, IP address, or other network location and specific password information to access the device. Each instance is considered a device which may be registered as further described below and stored in a section of the library 300, accessible through the GUI by selecting the device section tab 318. Similarly, start nodes or "adapters" once configured and saved may be accessed from a section of the library 300 through the GUI by selecting the device section tab 320.
• the library 300 and functionality of interface 306 in Figs. 3 and 4 is also shown schematically in Fig. 5.
• the library 502 may have sections for storage of plug-ins 504, devices 506 (i.e., an instantiation of a plug-in configured for a particular device), and adapters 508 (i.e., specific trigger conditions to be used as start nodes in a CoA). These library sections correspond to the tabbed display windows 316, 318, and 320, respectively, in Fig. 3.
• Each plug-in 512 in the library 504 has a specific plug-in architecture 510 including one or more commands 514 that the plug-in 512 can instantiate to activate or configure a type of network appliance.
• the commands 514 are built to interface with the API of the specific network appliance to be controlled by a task in a CoA.
• Each command 514 has associated parameters 516 including input parameters 518 needed to populate the command 514 to perform and action and output parameters 520 that may be generated by the network device after completion of the tasked action and returned to the plugin through the API for further use in the CoA.
• the output parameters 520 of one command may be used as input parameters 518 for other commands triggered by downstream tasks in the CoA.
• Device specific input parameters 518 may include model number, port, IP address, or other network location.
• a plug-in 512 is configured with information specific to a particular device, a device 526 is then registered and the device registry information 522 is stored in a device section 506 of the library 502.
• the device registry information 522 includes the device identification parameters and a reference pointer 524 to the plug-in 512 used to control the functionality if that specific device. Note that parameters 416 for commands 414 associated with a particular type of plug-in 512 does not have to be stored with each instantiation of a device 526.
• a user can begin to develop a CoA using the CoA Builder GUI module.
• the CoA Builder can visually depict the flow of tasks that occurs, and also account for workflow elements such as the following: trigger and start conditions; branching and decision logic; parallel processing of tasks; e-mail notification with templates; recommended tasks; extended wait tasks; scheduled tasks; assignment, escalation and user workflow; and looping.
• these exemplary tasks include input and output parameter definitions. Each one can be simplified by displaying parameters when configuring.
• the CoA Builder module initially presents a workflow palate with task icons as indicated in operation 204.
• An exemplary implementation of a workflow palate 600 is presented in Figs. 6A and 6B with a number of stencils (also referred to herein as "task stencils", or "objects") available to a user to build a CoA.
• a start node 602 representing a selected adapter from the adapter library is provided on the palate 600.
• the start node 062 could be blank and configured from the palate stencil by selection.
• a number of other stencil options may appear to assist the user in building a course of action.
• These stencils may include the following: a task stencil 604, a path toll stencil 606, a gateway stencil 608, a delete stencil 610, and an end node stencil 612.
• the task stencil 604 is under consideration for selection (e.g., the user's computer mouse or other pointer may be hovering over the stencil).
• Initial selection of a particular stencil may be indicated by a change in appearance of the selected stencil.
• the task stencil 604 is larger than the other stencils and is circumscribed by an annular ring.
• all of the stencils may disappear from the palate 600 and a workflow instantiation of the selected stencil may be automatically connected to the prior workflow element by a path.
• Fig. 6B wherein an instantiation of a task 614 is presented in the GUI linked to the start node 602 by a path 616.
• the user may drag the task 614 (or any other workflow element) to any position on the screen to best present and visualize the CoA workflow.
• the path 616 can automatically follow the task 614 regardless of where it is placed and maintain the connection with the start node 602.
• a user can independently select the path 616 to change its connection points and associations.
• a user can select a gateway 606 to place in the middle of a path to split the path, e.g., to build two or more different tasks to operate in parallel ingesting the same input parameter data.
• the gateway stencil 608 can also be used to place a gateway to rejoin two independent paths.
• the path stencil 608 may be used to draw additional flow paths between gateways, tasks, and nodes.
• the paths may further be conditional, i.e., the paths may be configured with decisions or conditions that can be met before the CoA continues down that path, e.g., a parameter value meets a certain threshold.
• the palate 600 may also include an end node stencil 610 that can be used to place an end node in along a particular flow path, e.g., after the completion of a task or of a series of tasks, to indicate the end of the CoA.
• the palate 600 may provide a delete stencil 612. Selection of the delete stencil 612 can delete the workflow element selected and immediately preceding the stencil array. For example, in Fig. 6A, the start node 602 is selected, thus causing the stencil array to appear. If the delete stencil 612 is selected at this time, the start node 602 would be deleted from the palate 600. Similarly, as shown in Fig. 7, the task 614 has been selected and the stencil array 704 is presented by the GUI of the CoA Builder module. If the delete stencil were selected from the stencil array 704 at this point, the task 614 would be deleted from the palate 600.
• a task configuration window 702 is presented to associate a plug-in, a command, and necessary input parameters with the task 614.
• the steps of configuring a task in this manner are indicated in Fig. 2.
• the configuration process begins as indicated in Fig. 2 with the provision of plug-in selections in operation 206.
• This operation is further represented in Fig. 8 which depicts a plug-in selection list 802. As indicated in operation 208 in Fig.
• an API may be provided to access the command and parameter information directly from the master plug-in application associated with the device selected and pass agnostic field information to the CoA Builder to request selection of appropriate commands and input parameters needed to properly instantiate the plug-in in the context of the CoA.
• Plug-Ins are delivered with pre-configured input and output parameter data. This can be modified in the plug-In configuration page described above with respect to Fig. 3 and 4. Parameter definitions associated with the selected plug-ins can determine what data is actually available for configuration in the CoA Builder. This simplifies the user experience when configuring the CoA because in some situations, only a small portion of data are handled to find the right parameter for the task being configured, while in other situations, other data can be processed. A lot of data may be returned with each task execution and certain elements can be treated as "parameters" available for downstream consumption depending upon the input parameters needed by another plug-in associated with a downstream task in the CoA.
• a plug-in may be associated with more than one device on the network. Therefore, when a plug-in is selected from the plug-in list 802 as indicated in Fig. 8, a further device list 804 of network devices registered with that plug-in is generated from all of the registered device plug-ins stored in the device library as indicated in operation 210 of Fig. 2.
• the device registrations do not include all of the information related to a plug-in, and can include the information specific to the device needed to identify and access the device. Further recall that the plug-ins may include multiple different command options and that each of the options may require different input parameters. Thus, as indicated in operation 212 of Fig.
• the CoA Builder provides a command list 806 of commands associated with the plug-in for the selected device as indicated in Fig. 8. Once a command is selected from the command list 806, the task box 706 is populated by a shorthand command string 808 of the selected plug-in and command for the task 614.
• the CoA Builder can provide a selection of input parameters available to execute the command as indicated in operation 214 of Fig. 2 and graphically represented in the GUI of Fig. 9A in which the parameters section 708 of the task configuration window 702 becomes active.
• the input parameters are specific to the command, and predefined at the plug-in command configuration level.
• the user may select the parameter values to input.
• there may be options for selection of a parameter value.
• the input parameter for the present command may be selected from output parameters generated from tasks previously executed upstream in the workflow or the values may be custom input by the user. These options are indicated in the flow diagram of Fig. 2 and graphically presented in the GUI presentations of Figs. 9A and 9B.
• the CoA Builder abstracts, categorizes, tags, and filters all the potential parameters within the instant CoA that could be selected for each input parameter to the new command as provided in operation 218 of Fig. 2. Pertinent parameters can be available for selection; other data can be filtered out as indicated in operation 220.
• mapping tasks within the CoA Builder each subsequent task can request input data (a parameter) that it can use to process its related command. Without this specification much control and flexibility to the system is lost.
• executing a task or plug-in command s some of the data can be used in decision making and downstream task management, while other data will not be so used. Most of the data is erroneous to the processing needs of the CoA.
• a task to pull a reputation of an IP address, to then make a decision based on that score may be executed.
• the decision may be to permanently block the IP address or put it on a temporary block.
• Embodiments here describe a sophisticated technique of allowing the configuration to occur, while keeping it simple to the user.
• the CoA Builder interface can, in some situations, make data elements available as input parameters that are already predetermined to be essential to consumption by the remainder of the flow. It does not make all the data returned via a command available for selection because most of it is erroneous. This subsequent experience simplifies the design achieved with the CoA Builder GUI and benefits the user. Users do not need to sift through rows of data to pick out the important data and map it to the next step. In some cases there can be one option and the single parameter can be pre-selected as an input to a task. In other cases there can be more than one option, and the list for selection as input can represent a small percentage of the overall data transmitted through the entire CoA.
• the screenshot in Fig. 9A illustrates this functionality.
• the lookup box 906a under the parameters section 708 has been limited to parameter values having IP addresses. This can be the type of input parameter used for the command string 808 in the task box 706.
• the available parameters for the previously selected command based upon all output parameters previously generated or otherwise available in this sample course of action 908 have been distilled to two parameters 910.
• the parameters are IP addresses (e.g., a destination IP address or a source IP address) as noted.
• the source and type of the parameter selected are represented in a shorthand data string in the lookup box 906b as shown in Fig. 9B.
• Such reorganization, modification, and addition of tasks is easy because of the drag and drop functionality of the palate and the parameter definition associated with each task, which is served up to the GUI via a CoA Builder application protocol interface (API), which is used to pull information from the plug-in registration tables up to the CoA builder GUI.
• API CoA Builder application protocol interface
• the CoA Builder module can also allow for simple incorporation of additional parameters not previously defined by an upstream plug-in task.
• a "custom" parameter can be incorporated as indicated in operation 222 in Fig. 2.
• the option of providing a custom parameter is shown in Fig. 9A as a custom value selection option 912. This value would be hard coded rather than selecting a CoA parameter which would be more contextual to the specific security incident being remediated.
• the configured task is saved in the CoA workflow, e.g., as an XML file, as indicated in operation 224.
• all output parameter information is referenced as part of the CoA as well, as indicated in operation 226, and is made available to any downstream tasks in the CoA when configuring those tasks.
• the output parameters are pre-determined based on plug-in command setup.
• the output parameters are the data available to downstream CoA tasks to incorporate in to either inputs to their commands or condition statements for evaluation and path determination. The result of one task becomes an input to the start of another task.
• An integral piece to the CoA Builder module is the normalization and simplification of data within the task, which is one level deeper than the data aliasing described in the previous section. This creates interoperability between different devices by linking the output parameters of one plug-in to input parameters of another.
• the CoA API normalizes and serves the data up into the XML data layer underlying the user interface to simplify this process.
• the CoA API is designed to pull information from the plug-in registration tables. When doing so it pulls and maintains in memory all the available output parameters for configured tasks. When configuring a new task, the input parameters for that task as well as their type are also known.
• the CoA API filters and displays only the output parameters that are of the correct type for input in to the input parameter of the new task.
• Fig. 10 is a flow diagram of an exemplary CoA 1000 presented on a workflow palate that may be executed in by the Orchestration Engine to screen a potentially suspicious e-mail based upon the qualities of the proposed recipient.
• the CoA 1000 begins at a start node 1002 which includes a Start Event Data file 1004 for populating the tasks and conditions in the CoA 1000.
• the start event data 1004 may include significantly more data or parameters than is made available to the user when building the CoA 1000 in the GUI.
• the CoA Builder filters the data stored within the CoA 1000 and presents the relevant data usable by a command underlying a task for selection during the construction of the CoA 1000.
• the first task is to determine the identity of a network user addressee of an e- mail as represented by the determine user task 1008.
• the determine user task 1008 can have a single input parameter 1006, namely the E-mailAddress of the user.
• a gateway element 1016 is the next activity in the CoA 1000.
• the gateway element 1016 is conditioned to determine whether the user recipient of the e-mail message is "greater than grade 18" in a grade structure in the organization. To determine the grade level, the input parameter 1014 provided to the gateway element 1016 is limited to the Grade data output as a parameter from the first task 1008. If the determination is that the user recipient is above grade 18, the path diverts to a quarantine user task 1020.
• the input parameter 1018 for the quarantine user task 1020 is one of the output parameters 1012 from the determine user task 1008.
• the command underlying the quarantine user task 1020 actuates a plug-in associated with the e-mail server to prevent the potential recipient (the user) from receiving the e-mail.
• the CoA 1000 then terminates at end node 1022.
• an e-mail user task 1026 is provided to pass the e-mail in question to the user.
• the input parameter 1024 for the e-mail user task 1026 is the E- mailAddress value provided in the Start Event Data 1004 at with the start node 1002.
• the command underlying the e-mail user task 1026 actuates a plug-in associated with the e-mail server authorizing the e-mail server to send the e-mail to the user.
• the CoA 1000 then terminates at end node 1028.
• the sample data interchange file structure presented below, for example, as a JSON file is an exemplary representation of a single task. The task representation defines such things as operation sequence, next task, specific plug-in details referenced, and parameter configuration.
• the several tags and corresponding values in the exemplary task file are explained further as follows: (1) The "outgoing" string defines the next step in the path of the CoA. If there is more than one path leading outbound from this task, then multiple outgoing values would be defined.
• the "commandld” string identifies the command ID for specific operation (possibly out of several) provided by a plug-in that relates to this task.
• the "pluginld” string identifies the ID for the plug-in being used in this task.
• the "deviceld” string identifies the specific device instantiation of a plug-in for this task.
• the "input" string defines the configuration of input parameters for the task commands to use when run.
• the "parameter” section stores each of the input parameters required for input to run the task commands.
• the "type” string defines the type of data required for input.
• the "value” string defines the location of the value to be input, either from the CoA or a custom value manually input.
• the Orchestration Engine is able to consume the format and recognize exactly what plug-in operations to execute, in what sequence, and where to locate the data need to execute the task.
• the computer system 1100 of user of the CoA Builder may be a personal computer (PC), a workstation connected with a server, a notebook or portable computer, a tablet PC, a handheld media player (e.g., an MP3 player), a smart phone device, or other device with internal processing and memory components as well as interface components for connection with external input, output, storage, network, and other types of peripheral devices.
• Internal components of the computer system in FIG. 11 are shown within the dashed line and external components are shown outside of the dashed line. Components that may be internal or external are shown straddling the dashed line.
• the computer system 1100 instantiating the CoA Builder application may be in the form of any of a server, a mainframe computer, a distributed computer, an Internet appliance, or other computer devices, or combinations thereof.
• the computer system 1100 includes a processor 1102 and a system memory 1106 connected by a system bus 1104 that also operatively couples various system components.
• processors 1102 e.g., a single central processing unit (CPU), or a plurality of processing units, commonly referred to as a parallel processing environment (for example, a dual-core, quad-core, or other multi-core processing device).
• the system bus 1104 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, a switched-fabric, point-to-point connection, and a local bus using any of a variety of bus architectures.
• the system memory 1106 includes read only memory (ROM) 1108 and random access memory (RAM) 1110.
• ROM read only memory
• RAM random access memory
• a basic input/output system (BIOS) 1112 containing the basic routines that help to transfer information between elements within the computer system 1100, such as during start-up, is stored in ROM 1108.
• a cache 1114 may be set aside in RAM 1110 to provide a high speed memory store for frequently accessed data.
• a memory drive interface 1116 may be connected with the system bus 1104 to provide read and write access to a non-volatile data storage device 1118, e.g., a hard disk drive or solid state drive, for nonvolatile storage of applications, files, and data.
• a non-volatile data storage device 1118 e.g., a hard disk drive or solid state drive
• a number of program modules and other data may be stored on the data storage device 1118, including an operating system 1120, one or more application programs 1122, and data files 1124.
• the hard disk drive 1118 may store the course of action builder module 1164, the orchestration engine 1166, the network device plug-ins and related APIs 1168, and the libraries 1170 and related data, e.g., of courses of action, plug-in commands and associated parameters, device registrations, etc.
• the data storage device 1118 may be either an internal component or an external component of the computer system 1100 as indicated by the data storage device 1118 straddling the dashed line in FIG. 11. In some configurations, there may be both an internal and an external data storage device 1118.
• the computer system 1100 may further include an external memory drive 1130 for reading from or writing to a removable magnetic disk 1132, tape, or other magnetic media, or solid state media such as flash memory. Additionally or alternatively, an optical disk drive 1136 for reading from or writing to a removable optical disk 1138 such as a CD ROM or other optical media may be included in the computer system 1 100.
• the external memory drive 1130 and optical disk drive 1 136 may be connected with the system bus 1 104 via an external storage interface 1 128 to provide read and write access to the external memory drive 1130 or the optical disk drive 1136 initiated by other components or applications within the computer system 1100.
• the magnetic disk drive 1 130 and optical disk drive 1136, and the associated computer-readable media may be used to provide nonvolatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1 100.
• a display device 1142 e.g., a monitor, a television, or a projector, or other type of presentation device may also be connected to the system bus 1 104 via an interface, such as a video adapter 1 140 or video card.
• audio devices for example, external speakers or a microphone (not shown), may be connected to the system bus 1 104 through an audio card or other audio interface (not shown).
• the computer system 1 100 may include other peripheral input and output devices, which are often connected to the processor 1 102 and memory 1106 through the serial port interface 1 144 that is coupled to the system bus 1 106. Input and output devices may also or alternately be connected with the system bus 1 104 by other interfaces, for example, a universal serial bus (USB), an IEEE 1394 interface (“Firewire”), a parallel port, or a game port.
• USB universal serial bus
• IEEE 1394 interface IEEE 1394 interface
• a user may enter commands and information into the computer system 1100 through various input devices including, for example, a keyboard 1 146 and pointing device 1148, for example, a mouse.
• Other input devices may include, for example, a stylus pad, a joystick, a game pad, a tablet, a touch screen device, a satellite dish, a scanner, a facsimile machine, a microphone, a digital camera, and a digital video camera.
• Output devices may include a printer 1150 and one or more loudspeakers 1170.
• Other output devices may include, for example, a plotter, a photocopier, a photo printer, a 3-D printer, a facsimile machine, and a press.
• several of these input and output devices may be combined into single devices, for example, a printer/scanner/fax/photocopier.
• other types of computer- readable media and associated drives for storing data for example, magnetic cassettes or flash memory drives, may be accessed by the computer system 1100 via the serial port interface 1 144 (e.g., USB) or similar port interface.
• the computer system 1 100 may operate in a networked environment using logical connections through a network interface 1152 coupled with the system bus 1 104 to communicate with one or more remote devices.
• the logical connections depicted in FIG. 1 1 include a local-area network (LAN) 1154 and a wide-area network (WAN) 1160.
• LAN local-area network
• WAN wide-area network
• Such networking environments are commonplace in home networks, office networks, enterprise- wide computer networks, and intranets. These logical connections may be achieved by a communication device coupled to or integral with the computer system 1 100. As depicted in FIG.
• the LAN 1 154 may use a router 1156 or hub, either wired or wireless, internal or external, to connect with remote devices, e.g., a remote computer server 1158 or network appliance devices 1157 (e.g., routers, firewalls, etc.) similarly connected on the LAN 1154.
• remote devices e.g., a remote computer server 1158 or network appliance devices 1157 (e.g., routers, firewalls, etc.) similarly connected on the LAN 1154.
• the Orchestration Engine 1166 operating on the special purpose computer 1 100 to execute a course of action can communicate instructions or actions from a plug-in identified in a task over the LAN 1 154 to such network appliance devices 1 157 to mitigate a cyber security threat on the LAN 1154.
• the remote computer 1158 connected via the LAN 1 154 may be another personal computer, a laptop, a tablet, a smartphone, a server, a client, a peer device, or other common network node, and typically includes many or all of the elements described above relative to the computer system 1 100.
• the computer system 1100 typically includes a modem 1 162 for establishing communications over the WAN 1160.
• the WAN 1160 may be the Internet.
• the WAN 1 160 may be a large private network spread among multiple locations, or a virtual private network (VPN).
• the modem 1 162 may be a telephone modem, a high speed modem (e.g., a digital subscriber line (DSL) modem), a cable modem, or similar type of communications device.
• the modem 1 162 which may be internal or external, is connected to the system bus 1 104 via the network interface 1 152. In alternate embodiments the modem 1 162 may be connected via the serial port interface 1144.
• the network connections shown are exemplary and other means of and communications devices for establishing a network communications link between the computer system and other devices or networks may be used.
• the technology described herein may be implemented as logical operations and/or modules in one or more systems.
• the logical operations may be implemented as a sequence of processor-implemented steps executing in one or more computer systems and as interconnected machine or circuit modules within one or more computer systems.
• the descriptions of various component modules may be provided in terms of operations executed or effected by the modules.
• the resulting implementation is a matter of choice, dependent on the performance requirements of the underlying system implementing the described technology.
• the logical operations making up the embodiments of the technology described herein are referred to variously as operations, steps, objects, or modules.
• logical operations may be performed in any order, unless explicitly claimed otherwise or a specific order is inherently necessitated by the claim language.
• articles of manufacture are provided as computer program products that cause the instantiation of operations on a computer system to implement the procedural operations.
• One implementation of a computer program product provides a non- transitory computer program storage medium readable by a computer system and encoding a computer program. It should further be understood that the described technology may be employed in special purpose devices independent of a personal computer.
• Some embodiments described herein relate to a computer storage product with a non- transitory computer-readable medium (also can be referred to as a non-transitory processor- readable medium) having instructions or computer code thereon for performing various computer-implemented operations.
• the computer-readable medium or processor-readable medium
• the media and computer code may be those designed and constructed for the specific purpose or purposes.
• non-transitory computer-readable media include, but are not limited to: magnetic storage media such as hard disks, floppy disks, and magnetic tape; optical storage media such as Compact Disc/Digital Video Discs (CD/DVDs), Compact Disc-Read Only Memories (CD- ROMs), and holographic devices; magneto-optical storage media such as optical disks; carrier wave signal processing modules; and hardware devices that are specially configured to store and execute program code, such as Application-Specific Integrated Circuits (ASICs), Programmable Logic Devices (PLDs), Read-Only Memory (ROM) and Random-Access Memory (RAM) devices.
• ASICs Application-Specific Integrated Circuits
• PLDs Programmable Logic Devices
• ROM Read-Only Memory
• RAM Random-Access Memory
• Other embodiments described herein relate to a computer program product, which can include, for example, the instructions and/or computer code discussed herein.
• Examples of computer code include, but are not limited to, micro-code or microinstructions, machine instructions, such as produced by a compiler, code used to produce a web service, and files containing higher-level instructions that are executed by a computer using an interpreter.
• embodiments may be implemented using imperative programming languages (e.g., C, Fortran, etc.), functional programming languages (Haskell, Erlang, etc.), logical programming languages (e.g., Prolog), object-oriented programming languages (e.g., Java, C++, etc.) or other suitable programming languages and/or development tools.
• Additional examples of computer code include, but are not limited to, control signals, encrypted code, and compressed code.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• General Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• Software Systems (AREA)
• General Physics & Mathematics (AREA)
• Physics & Mathematics (AREA)
• Human Computer Interaction (AREA)
• Computing Systems (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer And Data Communications (AREA)
• Stored Programmes (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (2)

Publications (3)

Family

ID=57586231

Family Applications (1)

Country Status (3)

Families Citing this family (17)

Family Cites Families (46)

• 2016
  • 2016-06-22 US US15/190,028 patent/US10536484B2/en active Active
  • 2016-06-22 EP EP16815237.9A patent/EP3311301B1/de active Active
  • 2016-06-22 WO PCT/US2016/038809 patent/WO2016209993A1/en not_active Ceased
• 2019
  • 2019-12-18 US US16/718,928 patent/US10986134B2/en active Active
  • 2019-12-18 US US16/718,990 patent/US11063985B2/en active Active

Also Published As

Similar Documents

Legal Events