Part 4 – Cooperative cybersecurity protection for large-scale infrastructure

Building a collective platform

Any commercial platform to support collective security operations must have certain functional attributes and operational capabilities to work properly in practice. In this section, we lay out the salient aspects of such a platform, trying to maintain some degree of generic design. Enterprise security teams considering use of a platform supporting sharing and cooperation between participants in a given industry sector can thus use this framework to evaluate such systems.

How should a platform supporting collective sharing work?

Any platform for supporting data collection and analytics must focus on serving cyber threat hunters, analysts, and other security practitioners. Telemetry must be collected from sensors that are deployed across the enterprise at key locations to collect full packet capture, which can then be analyzed for key potential threat attributes and combined with collected metadata to create an enriched view of activity presented to the platform backend for further analysis.

Backend capabilities must also directly serve the threat hunter, who might choose to integrate metadata with other telemetry and data analytics on complementary platforms running in their Security Operations Center (SOC). Such backends must also render event information to into analyst visualization tools in order to allow SOC operators to effective to conduct and coordinate detection, prevention, and response activities both within their organization as well as with peers participating in the collective defense platform.

**Figure 4-1. Collective Platform Processing Flow**

The overall processing flow must include functional components required to translate raw network data into actionable intelligence. This, ultimately, is the overarching goal of any live defensive protection system for large-scale infrastructure. A key design objective in any such system is therefore to minimize the time between collection and interpretation, and to simplify each of the interfaces, ensuring an open design so that third-party systems, such as hunt platforms, can be easily integrated into the process flow.

The overall processing flow includes functional components required to translate raw network data into actionable intelligence.

What functions must be supported by an analytics engine?

The analytics components that ought be included in any platform for collective cyber operations need to support the following real-time functional and process objectives for the SOC team:

Applying Advanced Behavioral Analytics – The behavioral analytics used by any collective platform must be driven by predictive behavioral models developed by experts who understand the specifics of how these models relate to cyberthreats.
Driving Key Decisions – An expert or cognitive system should be included to conduct contextual data analysis based on tradecraft insights and risk determinations that would typically be made by human analysts in a SOC, allowing those analysts to instead simply leverage the platform to obtain the core insights of the experts who built it.
Focusing Detection Priorities – The expert or cognitive system should also provide useful context to any mathematics-only solution, because while a true-positive might be detected, it might not necessarily be of local interest. Adware attacks, for example, might produce a positive detection, but might not be a high priority to the local team while nonetheless being an relatively important issue to consider on a larger scale.
Support for Hunt – The tool must also provide rapid, easy access to packet-level data and other contextual information for a SOC hunter to rapidly move through their investigative case work and identify potential threats to take action against.

Some of the major functional advantages of an analytics-rich processing environment include detection of threats at scale, which is important for infrastructure, where visibility and identification of otherwise unknown threats can be a challenge. Collection of data from key north-south and east-west collection points expands this visibility aperture and enables better response. The tradecraft insights embedded in the behavioral algorithms also help ensure that good mitigation and response decisions are made.

How should collective defense work?

The purpose of any collective defense platform is to create and support a cooperative collective cyber defensive system based on the live sharing of anomaly and event information for members. The collective group is inherently built from willing peers, presumably enterprise and government organizations, who understand the need to belong to a trusted group that can expand the attack visibility surface beyond their own perimeters and enterprise networks.

One advantage of this arrangement is faster time-to-detection rate for a member and the identification of threats that might have gone unnoticed in a single environment. In addition, members avoid the challenge of working in isolation against nation-state adversaries that likely leverages similar offensive playbooks against a sector. The collective defense approach seeks to address this asymmetry. Here is the normal detection time for an enterprise, usually about 70-80 days from breach to awareness:

**Figure 4-2. Breach Detection Time for an Organization in Isolation**

When a SOC team has access to detection flow information from multiple enterprise teams in a collective defense organization, the potential emerges for threat warnings to arrive much more quickly. If two organizations are vulnerable to a given breach capability, then the possibility arises that one might detect it more quickly and can notify the other. The result is a reduction in time-to-detection for the organization being notified, as shown below:

**Figure 4-2. Reducing Breach Detection Time Through Cooperative Notification**

The advantages of such cooperation should be obvious, and the platform infrastructure in such collective defense organizations must be set up to support this type of mutual sharing. It includes mechanisms to support the following important goals for cooperative cyberdefense:

Industry-Wide Threat Visibility – This aspect of any platform solution allows participants to obtain shared analytic event summaries for security awareness and provides specific threat insights across communities that have comparable risk profiles. Because all events are being shared across the entire community, this mechanism provides both the capability to create a common operational picture within a given industry as well as the ability to offer collective defense and response capabilities.
Community Triage – Collective defense platforms must also leverage shared insights from machine analysis and peer human analysis from individual SOCs to detect broad or targeted campaigns that would not be easily detected by a single participant in isolation. This aggregation capability can also work across different sectors or risk profiles and can include the ability to share live data and insights as an incident is taking place.
Automated Machine-Speed Sharing – A collective defense platform must automatically share sector-based and cross-sector threat insights from multiple participants and support the maintenance of near-real-time threat analysis across the various participants.
Cross-Sector Defense – Ultimately, a collective defense platform must supports a cross-sector defense for participants through exchanges across different industries, regions, and even national organizations. While various industries, regions, or nations may not share the same (or even similar) threat profiles, and may have significantly different approaches to potential responsive actions, the sharing of data and creation of a cross-sector collective defense platform can still result is a powerful, integrated cyberdefense capability.

As was described above in our discussion on analytics, these capabilities also obviously rely on shareable events being passed securely and anonymously to the collective cloud infrastructure, where an analytics engine stores and processes the information. Feedback is then shared with a collective of multiple companies, which is essentially a trusted collective that benefits from the scored events, correlations, notifications, and suspicious behavioral reports provided by the correlation engine.

Are there any hurdles to developing a large-scale collective?

The greatest hurdle to large-scale collective defense is that many organizations have a long-held, built-in hesitation to share threat and vulnerability information externally. This is a reasonable concern, because capable adversaries covet knowledge of IT infrastructure, network design, deployed applications, and security architectures in designing a targeted offensive. Information sharing in the past has exposed this data to external entities, and might therefore cascade to an adversary.

The design goals that can minimize information sharing concerns amongst participants include the following requirements:

Participant Anonymity – When a participant shares vulnerability information with a group, the attribution should be sufficient to provide context around the shared item, but should not require an organization to allow a shared item to be traced back directly to their infrastructure. To that end, anonymity options must be available and embedded in the sharing infrastructure, presumably using encryption or blinding as part of the protocol.
Secure Storage – The means for storing shared threat data must be trusted to be highly secure. If external, untrusted actors can find their way into shared databases, this can significantly undermine trust within the group. Secure storage techniques are therefore key, and should include implementation of other best-in-class cybersecurity capabilities, procedures, and policies.
Trusted Groups – The sharing community should involve participants who are mutually trusted to handle information, maintain discretion, share sufficient information to understand what is ingested, and to be a helpful partner to others in the group when an incident arises. Trusted groups are easier to develop when small, but context increases with the size of the group. A proper balance between size and efficacy is therefore key and the ability of platforms to allow for the creation of ad hoc groupings at a moment’s notice is can be another key differentiator.

Any practical collective defense organization must include support for these important requirements, and embeds the associated functional support directly into the platform. It should be obvious, however, that despite any functional measure put in place, the most important aspect of any cooperative, collective cyberdefense is the mutual trust that exists between participants. For this reason, great care must be taken in fostering such trust and ensuring that all participants agree to the nature and scope of the sharing group before joining a given collective defense organization – whether within a sector or across multiple sectors.

Part 5 will appear on Aug. 6.