This article is a part of a series describing the essential criteria of a Security Automation and Orchestration platform.
The automation editor of a Security Automation and Orchestration (SA&O) platform is where an analyst or manager codifies their processes into automation playbooks. The predecessor to a visual automation editor is the basic source code editor. Editing automated playbooks exclusively in a source code editor makes constructing playbooks a tedious and difficult process; only achievable by a relatively small group of programmers. A visual automation editor enables many more security experts to construct comprehensive and sophisticated playbooks. Ideally, the visual editor should adhere to Business Process Model and Notation (BPMN) standards, a graphical notation standard for specifying business processes. BPMN supports intuitive symbols for business users, while providing technical users with an ability to represent highly complex processes.
User Interface Elements
The user interface elements should start with a canvas where visual playbooks can be constructed. This part of the interface should provide an area where a desired security action can be specified (e.g. block_ip or file_reputation). Once an action is selected, additional parameters are typically required to properly configure the action. The interface should provide the ability to either manually enter the parameter(s) or select them from a list. Alert data and/or action result data might also be used as parameters.
The interface should also have a location where testing and debug can take place, allowing the seamless workflow transition from edit mode to test mode. Finally, a source code view should be accessible from the visual editor, in the event a user wants to see the source code for the automated playbook.
Block-Based Representation of Code
Using blocks to represent meaningful steps in the automation platform allows users to write comprehensive, complex playbooks without touching the underlying source code. Blocks should be connected in a one-to-one, one-to-many, or many-to-one fashion to dictate the order of execution. Visually, a user should be able to build a playbook that includes action executions, platform API calls, conditional statements (if/then), and branching statements that connect one playbook to another.
Inserting Humans into the Decision Process
Supervised automation support is a common requirement, which is the case where a human can be inserted into an automation sequence to approve, review, or augment a playbook’s continued execution. The automation editor should support this human supervision step by inserting approval point(s) in a playbook adjacent to one or multiple security actions. A playbook author should have the ability to specify which individual(s) will be inserted in the automation loop, along with the type of notification or approval desired. The playbook editor and underlying platform should be able to define error handling logic that would bring a human into the automation loop as well, like when one or more reputation services is not available to support decision making.
Information Exchange of Action Results
The automation editor interface should allow for new information resulting from preceding action executions to be available as inputs (i.e. parameters) to downstream actions or decision blocks. The action results of preceding actions should be accessible visually from a drop-down list when populating the parameters of downstream action block.
Access to Playbook Source Code
While constructing the playbook in a visual editor, the source code for a resulting playbook should be generated in real time and easily viewable by the author. Some users may prefer to construct all or part of the playbook via a traditional source code method. The interface should allow the ability to collapse the visual editor and replace it with a source code editor. Switching between visual and source code modes should be seamless and effortless.
Simultaneous Visual and Non-Visual Playbook Construction
When working with a playbook’s source code, the automation editor should allow the author to modify the playbook at the source code level and retain the ability to modify the playbook at the visual block level. There are times where the author requires individual blocks (e.g. actions, decision blocks) to be modified at the source code level for customizations beyond the scope of the visual editor. When these modifications are done, a user should still have the ability to modify the playbook visually.
Built-In Testing, Debugging, and Runtime Logging
Integrated Development Environments (IDEs) typically provide execution and debug capabilities. In the case of an SA&O platform, a user should be able to execute the playbook against a security alert and observe the execution activity and results. Logging and error codes should be displayed in a debug window that can be displayed simultaneously with the visual block editor or source code editor, if the author prefers source code. The objective is to enable the author to quickly edit, test, and debug playbooks within one interface.
An automation editor should also provide a safe mode for new playbooks that need pre-production testing. This mode simulates the execution on automation targets without effecting change on them. Once an author or other platform user has gained sufficient confidence in the playbook’s logic, this safe mode can be disabled and the playbook can begin to function in the normal manner.
A robust automation editor within an SA&O platform helps your team efficiently codify Standard Operating Procedures (SOPs) and maximize the utility of the platform. The 2.1 release of the Phantom Platform includes all of the automation editor criteria mentioned in this blog post. Give the Phantom Platform a test drive today and see how the platform’s visual automation IDE is one way it helps you work smarter.