ActiveCyber Interview with Steve Orrin and Ned Miller — Security Leaders for Intel Security

Learn about Intel Security’s approach to dynamic defenses and being “Securely Connected” in this ActiveCyber interview with two top security leaders from Intel Security.

Intel Security has a long legacy in cybersecurity and continues to be a security innovator and consistent MQ leader for a variety of security product areas. Recently, I was able to get a glimpse at some of the recent offerings coming out of Intel Security and how they relate to dynamic defenses from a presentation provided by Steve Orrin – Chief Technologist for Intel Security Federal. Steve graciously accepted my interview request to do a deeper dive and enlisted the support of Ned Miller who heads Intel Security’s technical strategy for Public Sector. So learn the latest in active defense technologies from these two security leaders for Intel Security.

[Picture of Steve Orrin]

» Title: Steve Orrin – Chief Technologist for Intel Corp’s Federal Division & Intel Federal LLC; Ned Miller – Chief Technology Strategist for the Intel Security Group’s Public Sector Division
» Email: steve.orrin@intel.com; ned.miller@intel.com
» Website: http://www.intelsecurity.com/

Read their bios below.

March 12, 2016

Chris Daly, ActiveCyber: What are the goals behind the Intel strategy and vision 2020 – Securely Connected – and what customer benefits can be achieved by connecting to this strategy?

Steve Orrin/Ned Miller, Intel Security: The goal of security connected is to promote an open collaborative security ecosystem, active command and control, forge interoperability (plug-n-play) among distributed elements from disparate vendors and ensure consistency and speed of outcomes.

ActiveCyber: What is the Data Exchange Layer (DXL) and how does it fit into the Intel strategy for being “Securely Connected?” How does it work with other key Intel security components such as Threat Intelligence Exchange (TIE), ePolicy Orchestrator (ePO), endpoint security, and third party security solutions to enable collaborative and adaptive defenses?

Orrin/Miller: The Data Exchange Layer is Intel Security’s Foundation for enabling an adaptive security ecosystem. It is a near real-time, bi-directional communications fabric allowing security components to share relevant data between endpoint, network, and other IP-enabled systems. It provides near real time command and control options for otherwise inaccessible systems. It allows for automated response, greatly reduced response time, and better containment.

Traditionally, communication to endpoints and between network products has been API driven and dependent on call backs or bidirectional access. As threats have grown more sophisticated these models have become increasingly untenable. Minutes, if not hours, from detection to reaction to containment is simply no longer acceptable. To deal with this, security architectures must evolve too.

Shared threat information and synchronized real-time enforcement are becoming necessities, not luxuries. Until now, this has been seen only for specific products or single point to point integrations.

A use case for integration with a global threat intelligence model can be represented by the Intel Security Threat Intelligence Exchange which uses the data exchange layer as a bidirectional communication fabric enabling security intelligence and adaptive security through product integration simplicity and context sharing. Intel Security Threat Intelligence Exchange collects and shares reputation information and makes protective decisions over the wire in real time. The Intel Security Connected framework has always included automation and integration. Intel’s Threat Intelligence Exchange takes advantage of the data exchange layer to change the threat prevention dynamic through contextualization of expanded intelligence and real-time orchestration throughout the environment.

ActiveCyber: DXL implements a “messaging fabric.” What is a messaging fabric and what are the advantages of fabric over API-based integration for data exchange? How does DXL manage the state of the messaging fabric and ensure the reliability and cohesive functionality of the overall set of defenses?

Orrin/Miller: By utilizing a standards based messaging broker/fabric security professionals now have a high-performance system that integrates workflows and data to overcome silo operations. It shifts the model from firefighting to agile, intelligence-fueled threat prevention. Global, local, and third-party threat intelligence and organizational knowledge come together to make smarter execution-time decisions.

By sending contextual attack insights—what we call indicators of attack (IoA’s) to cross vector detection, containment, and remediation systems or sensors, security analysts can expect a sustainable advantage against advanced targeted attacks. By building on and integrating real-time communications into existing security investments and leveraging the DXL messaging fabric an organization can now cost effectively prevent compromises and close the coverage gap between encounter and containment

The DXL specification is structured in different layers, similarly to the SAML specification which are composed in order to tackle specific use cases:

• Messages and Payloads: DXL defines the message template for transporting different kinds of security data. This includes the format of message headers and body, using different data representations (e.g., JSON or XML)
• Protocols: DXL defines a way for messages to be exchanged on the messaging fabric. Currently, two distinct (messaging) protocols are defined: Publish/Subscribe (or event-oriented) and Request/Response (or service-oriented). Ad-hoc application-specific protocols can easily be layered on top of these patterns.
• Bindings: These are the mappings of DXL to standard messaging and communication protocols and fabrics. A concrete example is the mapping of DXL to MQTT
• Profiles: These are combinations of Messages, Protocols and Bindings that support very specific security use cases. A concrete example is TIE (Threat Intelligence Exchange), which uses the MQTT binding, a service-oriented protocol, and message formats that extend the base DXL specification to transport threat intelligence information.

The Data Exchange Layer has several advantages over classic API-based integration.

• Product integration simplicity — a single open API/SDK implementation allows integration with any product part of the data exchange layer (e.g. no more point-to-point integration).
• Open framework — the Data Exchange Layer was designed with openness to support the integration of any third-party product.
• Scalability — the Data Exchange Layer was designed to understand present and future needs (e.g. ubiquitous computing), scaling for an enterprise (millions of concurrently connected clients) with a low network footprint. It is also built to communicate with clients regardless of location (on network or off network).
• Secure — ensuring proper authentication, authorization, non-repudiation, confidentiality and other required security related features and capabilities.
• Flexibility – the Data Exchange Layer was designed to support a diverse set of use cases simultaneously on a given infrastructure deployment.

The Data Exchange Layer powers the evolution and delivers on the security connected vision. Customers benefit from significant operational cost savings, reduced complexity with unmatched operational effectiveness.

ActiveCyber: DXL leverages MQTT for message transport. Why MQTT for the messaging layer? Is the intent to also provide support for IoT since MQTT is lightweight protocol suited for high latency and low bandwidth networks that IoT environments may experience? How do you avoid duplicative messages being sent between sender and receivers without significantly increasing the overhead using MQTT?

Orrin/Miller: MQTT was chosen for its ability to scale. DXL is designed with IoT in mind. Intel has made several enhancements to the MQTT/DXL platform to address performance and security.

ActiveCyber: MQTT supports a publish/subscribe model for messaging based on the use of topics. How are topics established, how are they managed, and how are subscriptions to topics by clients controlled using DXL?

Orrin/Miller: DXL can transfer message payloads in two main ways: 1) pub/sub, and 2) service-oriented or point-to-point. On the first, DXL clients just subscribe to topics of interest, and when an event is available on that topic the clients are notified. Events can be generated/published by other DXL clients or by the system itself. On the later, DXL clients send message payloads to a specific target (typically a service), thus providing a request/response-like interaction on top of the fabric. Each messaging abstraction is useful in distinct scenarios. For instance, when there are multiple interested parties on a message (e.g., threat alert that needs to be communicated immediately to clients), a pub/sub mechanism is preferred since it decouples the publishers from the subscribers. On the other hand, when there is a need to invoke a particular function or method on a service for a very specific purpose (e.g., retrieving the reputation for a particular asset using a very specific service provider), then the service-oriented messaging abstraction is a better fit.

DXL provides a set of management APIs to create and manage topics, define identity integrations with external identity providers, define access control rules and integrate with external access control protocols (in a PEP/PDP fashion) and more. This management abstraction is one of the cornerstones of the DXL specification.

ActiveCyber: DXL-MQTT is one binding supported as part of the feature set for DXL. Are there other bindings planned? Will Intel allow the vendor ecosystem to develop new bindings with DXL? Are there any plans to publish the DXL specification?

Orrin/Miller: Yes, yes and yes. Intel Security has created a set of bindings for DXL over MQTT, based on customer requirements such as memory footprint and impact to network traffic. Other broker and protocol bindings may be created for other user cases such as high volume of data and stream processing of events and log entries on a massive scale across fabrics that may not be federated (e.g., cloud processing of log entries across multiple tenants)

ActiveCyber: How does Intel use an open Common Information Model (CIM) to support its Securely Connected strategy? Where does this CIM reside and what type of underlying information model is used – OWL/RDF? IF-MAP? How is context and policy enhanced using the CIM for propagation to other security capabilities on the fabric? How do policy managers interact with the CIM?

Orrin/Miller: Intel Security is working on the information model for DXL and the Security Connected strategy. Intel Security will be working with our partners and the ecosystem to define and implement a CIM that meets the needs of our customers and partners.

ActiveCyber: What are “convictions” produced by TIE and how do convictions get translated into policy enforcement actions to enable adaptive defenses?

Orrin/Miller: Threat Intelligence Exchange provides innovative endpoint security through the use of a McAfee Threat Intelligence Exchange VirusScan Enterprise Module. By using configurable rules, the module makes accurate file execution decisions and leverages the combined intelligence from local endpoint context (e.g., file, process, and environmental attributes) and the current available collective threat intelligence (e.g., organizational prevalence, age, reputation, etc.).

TIE enables customization of threat intelligence, such as custom lists of publisher certificates, file hashes, and risk tolerance decisions based on organizational preferences. McAfee is the only company enabling dynamic tuning based on real-time synthesis of local, custom intelligence with third-party services. TIE connects threat intelligence and acts bi-directionally across all defense layers: endpoint, network, and security components. TIE and our Advanced Threat Detection engine (ATD) performs dynamic and static analysis and classification of “gray” (potentially risky) files submitted by a full range of security components. Endpoints are protected based on malware detected by network gateways, while network gateways block access based on endpoint convictions.

ActiveCyber: What is the target deployment scenario for TIE/DXL? Is it designed to work operationally in the cloud as a service, as a cloud broker, on premise?

Orrin/Miller: TIE is targeted towards an on premise solution and is connected to our GTI (Intel Security’s Global Threat Intelligence service). TIE can be configured in a cloud environment. The deployment architecture is dependent upon the customer environment and network latency overhead and requirements.

ActiveCyber: What components of the Securely Connected strategy are available today? Where can my audience find more information about TIE/DXL and “Securely Connected?”

Orrin/Miller: All of the components of the security connected strategy are available today. You can find more information about the Intel Security Connected strategy on our website http://www.intelsecurity.com/

Thanks Steve and Ned for sharing these updates about the latest by Intel Security with ActiveCyber and our audience of readers. It is becoming apparent that a messaging fabric along with a strong advocacy for open standards within the security ecosystem are critical to accelerating the cyber OODA loop and getting threat intel synchronized with the rest of the security infrastructure – whether it reside in the cloud, the enterprise, or as part of the Internet of Things.

And thanks for checking out ActiveCyber.net! Please give us your feedback because we’d love to know some topics you’d like to hear about in the area of active cyber defenses. Also, email marketing@activecyber.net if you’re interested in interviewing or advertising with us at ActiveCyber.