Enable breadcrumbs token at /includes/pageheader.html.twig

Weaponizing Automation Protects Cyber Systems

Unifying the military’s information network management would streamline defense protections.

Marines with Marine Corps Forces Cyberspace Command work in the cyber operations center at Lasswell Hall, Fort Meade, Maryland. MARFORCYBER Marines conduct offensive and defensive cyber operations in support of U.S. Cyber Command and operate, secure and defend the Marine Corps Enterprise Network. Credit: Staff Sgt. Jacob Osborne, USMC

Automation not only would increase the speed at which systems could operate but also support fast-changing military mission operations in a cyber secure manner. Credit: Shutterstock/sdecoret

U.S. service members and civilians, along with partner nation service members, work to improve tactical-level cyber operations skills against a live opposing force at the Joint Training Facility in Suffolk, Virginia, during a U.S. Cyber Command annual exercise.

Automation software tools are being under-utilized, especially in the U.S. Defense Department. While the department has purchased and used automated scanning tools for security and compliance, it has been slow to adopt automation for many other tasks that would benefit from the capability, such as easing software deployment and standardization and, once developed, increasing the speed of overall automation.

While automation is in its infancy within most Defense Department entities, the implementation of the technologies, a standardized Defense Department software architecture and departmentwide security information and event management (SIEM) are possible. These improvements would enable the U.S. government to remediate currently known risks, respond to future cyber threats, perform software updates and understand the risk landscape of the entire Department of Defense Information Network (DODIN) in near real time. Consequently, the cost and impact to resources that support Command Cyber Operational Readiness Inspections (CCORIs) could be greatly reduced.

Jimaye Sones, former director, DODIN Readiness and Security Inspections Directorate, says these inspections are necessary because they allow site commanders to “understand what impact the vulnerabilities found in a traditional [Command Cyber Readiness Inspection] have [uncovered] in terms of the threat to their mission if an adversary takes advantage of the vulnerabilities.” In addition, the CCORIs provide DODIN headquarters with a better understanding of the risk landscape.

If the DODIN leadership could automate most of the network assessments and security inspections performed during a CCORI, the remaining process could be completed much faster with much less impact on the day-to-day operations of the entities being inspected. For this automation idea to occur across the department’s information networks, some large changes will be required both in the way the DODIN is administered and compliance maintained.

This stronger, standardized and more automated system would be called the United DODIN. An entity such as the U.S. Cyber Command could manage it, and local components would maintain it, much like the current cybersecurity structure. However, the United DODIN management organization would either be performing or delegating roles that subordinate commands and components currently perform. Some of these roles include validating that patched software is deployable, mandating a standardized list of software for the United DODIN to ensure patches are universally accepted with automated deployments, and reviewing the feedback to produce a risk landscape to identify vulnerable software and configurations through tool automation such as an enterprise SIEM log correlation type deployment.

To ensure the United DODIN is successful, one of the initial tasks would be to prepare the DODIN for automation. For example, for an automation tool such as Ansible Tower to work properly within an environment, the environment must have a standardized software implementation. Although automation tools are great for repetitive actions, they do not scale as well with uniquely configured systems that are created either for a specific need or by a misconfiguration by the administrator.

When a uniquely configured system must be created, it should be treated as a special system and should be tagged as a special case then receive the appropriate attention. Any uniquely configured systems would need to be either created with United DODIN approval or in a separate forest with a one-way trust, which would allow the separation of the United DODIN from a command or component. Consequently, the command’s or component’s forest would trust the United DODIN, but the reverse would not be true.

Because the uniquely configured system would not be part of the United DODIN security remediation posture, the associated command or component would have to maintain it. The increased cost in maintenance would encourage these organizations to use more standardized deployments so they could take advantage of one of the benefits of having all systems and software standardized within the United DODIN: cost and time savings. Using automated scripts on any machine in the United DODIN would improve the development and deployment time for any recently created patch and the associated vulnerabilities via automation scripts, also known as playbooks.

The United DODIN manager or subordinate commands and components would create United DODIN manager-approved playbooks, which would have to support multiple vendors, such as both Windows and Linux operating systems. By limiting the vendors and versions deployed within the United DODIN, the Defense Department will save countless hours of automated script development and remediation, while allowing for more specialized understanding of the risk environment.

This software standardization benefit has already been realized in the world of containerized software. It has greatly contributed to the speed at which a container that acts as a stripped-down operating system can be deployed with an application loaded on it.

Most technology users in the Defense Department agree that patching software within the department can be a slow process that involves notifying a command or component a software patch must be implemented. Then the patch must be downloaded, scanned, configured, rescanned, tested within the environment, remediated and approved by the cybersecurity branch prior to being approved to be deployed on the DODIN network segment. This process takes time, while leaving the component vulnerable to a threat.

By standardizing the department’s networks and using automated pipelines, this software validation process and later deployment time could be greatly reduced, with the goal of full automation and almost instantaneous results.

Within the Defense Department, software developers have been using continuous integration/continuous deployment pipelines for years. The pipelines automate the integration of new code into the existing code, test the code for both function and security, then deploy that code where it can be used within the applicable environment.

Having a larger scale continuous integration/continuous deployment process for software patches would allow for the United DODIN management team to distribute software patches to commands and components quickly while providing a fully deployable solution in the form of a playbook for deployment. Because the playbooks would reference a standardized Definitive Media Library (DML) location instead of a centralized repository, each organization would be able to update its DMLs with the associated software for local pulls. They could remediate future local cyber risks quickly using a combination of playbooks and the distributed DML, while providing feedback to the United DODIN management team.

While deploying patches as rapidly as possible is extremely important, the Defense Department would still have to improve its ability to monitor the distributions of the playbook deployments and patch remediation. The United DODIN would change how monitoring and correlation is performed. Instead of individual commands and components being alerted to vulnerabilities within their areas of responsibility and responding locally, the United DODIN would be able to perform much broader correlations.

When viewing the threat landscape from the local level, the big picture of the DODIN is lost, and commands and components see little to no immediate benefit from any lessons learned at the local level from other components or commands. However, if the United DODIN management approach were employed, the commands’ and components’ alert output would be standardized, so local SIEM deployments could be used to feed an overarching United DODIN SIEM capability, and the United DODIN SIEM would have a view of the entire DODIN.

Following the United DODIN naming convention, this larger SIEM could be called uSIEM. The uSIEM could receive alerts from every command and component in the department, correlate those alerts with ones from different commands and components, then produce a picture of how the United DODIN is being attacked. By ingesting only event logs that have already been identified by local SIEM capabilities, the uSIEM would not have to maintain the astronomical hardware requirements that a traditional DODIN-wide system log ingestion SIEM would require.

Splunk is an example of this technology. Local Splunk instances perform the ingest, correlation and alerting of data, but a software called Mothership is used to gather alerts from multiple Splunk standalone deployment entities and presents a higher-level picture of the now unified Splunk instances. Each local Splunk instance maintains the logs and provides the ability to dive much deeper into any alerts, as well as offers greater local network intelligence.

uSIEM not only would be capable of showing the overarching United DODIN threat but also would correlate the current playbook deployments as well as the current vulnerability and compliance scans associated with the playbook feedback loop. Having all of this data correlated will present an accurate, near real-time picture of the possible impact of a new attack on the United DODIN and allow the United DODIN management team to push out additional playbooks to respond to large cyber attacks properly.

Once this firm grasp on the ability to respond to threats to the United DODIN in near real time is established, the Defense Department needs to start incorporating other aspects of the network as well as machine learning algorithms with artificial intelligence technology to automate the defensive response further.

With the development of offensive cyber artificial intelligence against the United States, the military must take the hands-on human interaction out of the incident response because they would occur faster than any human can respond. In addition, most humans cannot monitor a low profile and slow attack to correlate the incidents and identify the attacker.

If the Defense Department does not push to automate its software and configurations, standardize the DODIN and automate its incident response, the United States will remain behind the power curve in defensive cyber operations.

Robert Hoffman, a security architect, is a proponent of technology that can be securely implemented if the proper environment is created. He also is the AFCEA International Young AFCEAN Awards co-chair, vice president of awards for the Pelican Chapter, and a 40 Under 40 award winner.