The executive order on cybersecurity President Biden issued in May doesn’t radically change federal cybersecurity practices for now, but it lays the groundwork for significant changes in the future. The EO directs multiple federal agencies to develop new policies and processes to safeguard federal networks, and also to improve the overall cybersecurity posture of all Americans. You can read insights about the EO in this blog post by Julian Waits, GM of cyber business unit & public sector for Devo.
The EO acknowledges that the federal government must improve its cybersecurity by partnering with the private sector. At the heart of the EO is the need for data — lots of data — along with the ability to quickly sort, analyze and transform it into actionable information. This is exactly what Devo does, which is why we will be involved in the effort. This post examines how the EO will drive significant increases in cloud-based data operations and how Devo can support both federal and private sector security operations centers (SOC) through the EO’s implementation.
The Future Federal SOC
As a next-generation security information and event management (SIEM) solution provider, Devo is keenly focused on how the future federal SOC will function. The EO elevates the importance of each agency’s SOC to a primary defender of the agency. This will bring increased responsibilities and authorities.
Something the EO does not address is the worldwide shortage of trained cybersecurity professionals required to staff private sector and federal SOCs. Improved tools, automation, artificial intelligence, machine learning, and standardization will have to compensate for this talent scarcity.
Let’s examine three themes of the EO that directly impact the future federal SOC:
- Collect everything
- Automate everywhere
- Share widely
The EO could simply have directed every federal agency to collect every log possible for their networks and endpoints. Section 8 calls for enhanced logging in general, but we don’t yet know what the new logging directives will include. Two sections of the EO, 3 and 7, cover data collection. Section 3 directs the implementation of zero-trust architectures (ZTA). Section 7 directs the deployment of a government-wide endpoint detection and response (EDR) solution.
Zero trust, as defined in Section 10, “[E]liminates implicit trust in any one element, node, or service and instead requires continuous verification of the operational picture via real-time information from multiple sources to determine access and other system responses.”
Continuously monitoring every user and device requires logging. Not just device logs, logs of all of the network components to which every device connects. For devices that can support an EDR agent, the EDR solution will generate the logs and, unless compromised, it should be able to provide some control over each device’s behavior.
The challenge with ZTA is developing policies that actually reflect the least privilege required by a specific user, device or service. Effective ZTA means not all users, devices or services are treated equally. The challenge is how to implement ZTA when one or more components may be compromised. For example, if Device A is allowed to connect to Service A but not to Service B, how do you prevent the connection to Service B if Device A is compromised? While EDR on Device A may help, ZTA requires verification of Device A, which cannot be achieved if Device A must be treated as untrusted.
This is where logging and SIEM solutions, such as the Devo Security Operations application, are invaluable. A SIEM with access to the logs from Device A and Services A and B, and with rules in place that characterize their authorizations, can perform the required verification process. A SIEM will assist the SOC team in determining if any of the components have been potentially compromised and initiating investigations where necessary. Devo can pull in logs from the devices, the EDR solution, and any deployed asset discovery and management systems. Pulling in all of this data enables Devo to verify the trustworthiness of each component and of the behaviors they exhibit, so if components appear to be trustworthy but still violate the established least privilege, the SOC team can investigate.
The level of automation required to fully implement the goals outlined in the EO are staggering yet feasible, as paradoxical as that sounds. It is staggering because there are millions of federal users and tens of millions of devices — both managed and unmanaged — on federal networks.
Section 6 of the EO somewhat acknowledges this as it requires the development of a set of standard playbooks and their implementation across multiple federal agencies. This is an important first step toward automation and should allow for the best playbooks available to be used by agencies that lack the expertise to build their own.
Devo Security Operations can automate elements of the SOC workflow — such as playbooks — enabling consistent, standardized responses to specific threats. Using automation frees SOC analysts to apply their skills and experience to actively investigate and hunt threats. It helps reduce burnout by relieving analysts of tedious, repetitive work. Auto enrichment of events provides analysts with real-time, actionable data and rich context, enabling them to investigate and threat hunt more effectively and efficiently.
However, the automation required by the EO goes far beyond playbooks. Collecting everything is useless if the raw data cannot be transformed into evidence and then into insight. This goes beyond the traditional “find a needle in a haystack” problem and is more like finding related needles in multiple haystacks. While humans excel at pattern matching and analysis, there is simply too much data for any SOC team to sift through. Automation will be required to find those needles in multiple haystacks and prioritize the information for analysts.
Devo’s machine-learning capability provides critical support for this level of data analysis. However, this analysis is not static and must be updated constantly to reflect the latest threat intelligence. The Devo Machine Learning Workbench enables federal SOCs to build new analysis processes on their own, allowing the Devo Platform to learn from the SOC analysts. This dynamic capability enables the entire SOC to address the current threat. While machine learning is key to this, it is not a silver bullet. Machine learning and artificial intelligence are still a long way from replacing human analysts.
The concept of sharing information is woven throughout the EO. The future federal SOC will be expected to share:
- Within its own agency
- Across federal agencies
- With federal and state law enforcement agencies
- With the private sector
- With the intelligence community
- With other organizations such as academia, industry groups, etc.
Given the diversity of the sharing requirements, a future federal SOC must be able to share data by providing files, passing information through application programming interfaces (API), or providing select non-agency users with limited access to their platform. The actual sharing mechanism will depend on the specific requirement and use case.
Devo supports a wide range of sharing techniques including the creation of industry-standard files, integrations via APIs, or the addition of limited-access accounts. Devo’s cloud-native data analytics platform gives the federal government the ability to effectively handle all of the data generated by compliance with the EO. From collecting and retaining logs to deep cybersecurity analytics, the Devo Platform and Security Operations application provide agencies with critical tools to modernize their SOCs and comply with the EO.
Effective Security Operations
Security operations must have the right data and processes to sort, filter and process data to provide SOC operators with critical information in a timely manner. Devo does this through efficient log ingestion which makes near-real-time data available for immediate search. There is no delay between log collection and search, providing SOC analysts with immediate alerts related to new data and the ability to initiate an investigation as soon as Devo receives the data.
SOC operations are also about having the SIEM provide more signal and less noise to highlight alerts that are important to the organization. Devo accomplishes this through a robust set of out-of-the-box alerts which have been tuned for today’s SOC teams. The Devo Machine Learning Workbench enables senior analysts to leverage existing models or create new ones based on their experience, so every analyst on the team benefits from their know-how.
Finally, investigations — especially those involving nation-state actors — may involve reviewing an organization’s logs from a specific time in the past. Advanced persistent threats are designed to go undetected for a significant amount of time. Once there is an initial detection, the next question is when did the threat actor establish a foothold into the environment? By default, Devo stores 400 days of always-hot data so analysts can immediately search for critical answers.
As a cloud-native SaaS solution, Devo frees our customers from the burden of establishing and managing an on-premises data solution. Devo Relay is a software application that receives inbound events from data sources, applies processing rules and tagging to the events, and forwards them to the Devo Platform over a secure channel using SSL/TLS encryption. Relay provides customers an easier method of collecting the logs within their environment versus having to transmit them directly to the cloud.
In addition to Relay, Devo has a full suite of connectors for a variety of on-premises or cloud services that customers can configure to directly transmit logs to the Devo cloud, eliminating an on-premises data footprint when desired. This radically simplifies the Devo deployment process and enables customers to see value from Devo as soon as the first logs are ingested.
Superior Data Compression
Once ingested, Devo compresses log data using a proprietary algorithm. Compared to other vendors, Devo is typically able to compress logs with 10X efficiency. Given that Devo’s cost model is similar to other logging solutions and is based on GBs ingested, this immediately drives down operational costs for customers. It also enables organizations to send more log data to Devo, which would be cost-prohibitive with other vendor solutions.
Devo’s compression does not change the format of the data. All log data stored within Devo remains in its original format. Devo does not normalize or otherwise transform the data for storage.
Single Data Platform
On top of the platform, Devo has built powerful Security Operations and Service Operations applications that support the traditional SOC and network operations center (NOC) respectively. This approach enables both the SOC and NOC to use the same data and share it effectively across the organizations as required. This can be invaluable during an investigation if the indicators are consistent with either an attack or a misconfiguration/issue with a specific component. Having security and operations data in a single location enables SOC and NOC teams to triage and collaborate to find and implement the appropriate response — fast.
While the evolution of the federal SOC has been ongoing, the EO will accelerate it. The goal of the EO is to do everything possible to get ahead of threats in a consistent and technically sound manner. The EO is just a starting point; government and industry will start to see results over the next year as multiple agencies begin publishing new guidance and engaging with private-sector vendors to achieve the EO’s goals.
The true security posture of federal networks is dependent on the collection and analysis of a vast amount of log data. Cybersecurity is quickly becoming a large data problem and requires scalable solutions to turn that data into actionable intelligence. Devo’s cloud-native approach is well suited to meet the challenge.