Driving the Next Generation of Audit and Compliance Solutions with Zero Trust Networks Kevin Saucier Compliance Practice Lead Conventus Corporation
About Me Compliance Practice Lead at Conventus Corporation 10+ years in IT Security and Compliance Various roles including software engineer, trainer, incident response and disaster recovery Based out of Connecticut
Agenda What are Zero Trust Networks? Practical Example: Google s BeyondCorp Why Compliance and Audit personnel should be pushing for ZTNs
Three Lines of Defense IIA Recommended Practice: Risk and control functions operating at the different lines should appropriately share knowledge and information to assist all functions in better accomplishing their roles in an efficient manner.
Committee on Oversight and Government Reform U.S. House of Representatives 114th Congress The OPM Data Breach: How the Government Jeopardized Our National Security for More than a Generation - September 7, 2016 Photo/Image Here Recommendation 2: Reprioritize Federal Information Security Efforts Toward a Zero Trust Model To combat the advanced persistent threats seeking to compromise or exploit federal government IT networks, agencies should move toward a "zero trust" model of information security and IT architecture. The zero trust model centers on the concept that users inside a network are no more trustworthy than users outside a network
Problems with Traditional Security M&M Security Hard on the outside, soft on inside Majority of time/money/effort is spent on the perimeter of the network Tiered network designs make it difficult to implement dynamic segmented network security models
Problems with Traditional Security Why do perimeter first models not work anymore? Networks are bigger easy to find blind spots Data is mobile perimeters are nonexistent Mobility increases chance of theft and/or loss Trust occurs, but verify is not followed up on Malicious insiders, intentional or unintentional
Traditional Network Design
Traditional Network Design
Zero Trust Network Model Developed by Forrester in 2009 as a vendor and industry neutral security model Trust, but verify becomes verify and never trust Start with the data that needs to be protected and/or compliant and building the network from that perspective Basic principles: All network traffic is untrusted packets are not people! All network traffic should be secured regardless of location Implement a least privilege strategy to limit user access All network traffic should be logged and inspected
Zero Trust Network Model What is needed to build a Zero Trust Network? 1. Identify and classify the organizational data 2. Understand how data flows through the environment for each application/asset 3. Build the Zero Trust Network around those data flows boundaries and trust tiers 4. Create automated rules around the network to control access and inspection policies 5. Log all traffic, both internal and external 6. Centrally manage the network controls and logging
Zero Trust Network Model
Zero Trust Network Model
Positives with the ZTN Model 1. Platform agnostic - Different platforms, same type of traffic 2. Reduces cost of implementing and maintaining Compliance due to network simplification and segmentation 3. Scales with organization and future use cases 4. Foundation of multitenant environments - naturally segmented 5. Modular design allows for easy load balancing and upgrades 6. Can be added to existing older network models
Challenges with ZTN Model 1. Could require significant reengineering of network - Micro-segmentation of the network YMMV 2. Right idea, wrong technology with existing segmentation strategies VLANs and Switch ACLs = Limited Isolation with no enforcement of network policy 3. Asset management and visibility is assumed 4. Functional business data quality is assumed
ZTN: A Practical Example Google s BeyondCorp initiative: A complete redesign of Google s internal security Practical implementation of ZTN that illustrates some of the limitations of the ZTN model A working model for other organizations that want to move towards ZTN models
Google s BeyondCorp Initiative
Google s BeyondCorp Initiative Theory Reality Integrated Segmentation Gateway
Google s BeyondCorp Initiative Access is organized into Trust Tiers by the Trust Inferer and assigned to each device Trust Tier decisions are informed by data collected by the Device Inventory Service which aggregates device data from across the environment When user attempts to access any device, the Access Control Engine uses the DIS and Access Policy to determine the context specific access level Access Policy determines minimum trust level required for data and resource access
Google s BeyondCorp Initiative Device Inventory Service: An accurate and actively updated asset inventory was considered a primary prerequisite to the deployment of any other component in the BeyondCorp ZTN model
Device Inventory Service Types of data are collected can include: Observed: The last time a security scan was performed on the device, in addition to the results of the scan The last-synced policies and timestamp from Active Directory OS version and patch level Any installed software Prescribed: The assigned owner of the device Users and groups allowed to access the device DNS and DHCP assignments Explicit access to particular VLANs
Device Inventory Service Once aggregated, the observed and proscribed data is then: Transformed into a common data format Matched with existing asset records If necessary, a new record is created Google's biggest challenges while creating this service: Defining what constitutes a device Accuracy of the data especially manually entered data Amount of updates necessary to maintain accuracy
Trust Inferer Once the Device Inventory Service is populated: Trust Inferer makes decisions concerning trust tiers on a per-device basis based on the current state data in the DIS A reevaluation is triggered as new information for a device becomes available to the DIS This reduces the amount of data that needs to be pushed downstream to various access gateways Ensures that all access systems are using a consistent dataset for access decisions
Trust Inferer As an example: Access Policy dictates that only devices with the highest trust tier (A1) can access PII data The highest trust tier (A1) would contain the following requirements: Antivirus enabled and been recently scanned Have the latest patches installed Have a vulnerability scan completed in the last 2 weeks If the device did not meet any of those requirements, then the device is assigned a lower trust tier (B2) and is blocked by the Access Control Engine from querying a protected PII database (requirement of A1 minimum)
The Meaning of Context BeyondCorp Initiative can be seen as a move towards the idea of contextualized security: Siloed security groups have led to siloed information stores Narrowing specializations within IT organizations have given rise to IT tools with increasingly specialized focus For most organizations, the challenge is not the creation of more data or even the gathering of existing data The struggle is to find easy and consistent methods of contextualizing existing data for various internal and external stakeholders IT SecOps, Compliance, Audit, Management
The Need for Context
The Need for Context
The Need for Context
The Need for Context Helps to define effectiveness and scope of specific controls Specialized devices FDA controlled Medical Devices Manufacturing systems POS systems ATMs IoT Devices Rogue Devices Once the scope of controls on assets has been established: Compensating Controls Risk Acceptance Remediation Prioritize future spending
Why Compliance and Audit cares about context? Some Challenges to Compliance and Audit Reporting: Siloed IT departments means access to all the necessary data for reporting becomes a challenge in communication and organization Much of this data is collected manually and Compliance and Audit personnel are left to correlate the data according regulatory or business needs Compliance and Audit personnel typically do not have the raw technical knowledge to translate received data into business language Inadequate personnel or technology to perform audits in required time frames Difficulties in linking audit findings back to business function
Why Compliance and Audit cares about context? ZTNs unintentionally creating the next generation of Compliance and Audit tools? Device Inventory Service: Automated data collection Aggregation from disparate data sources Security and Business Transformed into clean agreed upon format Searchable Updated automatically Accessible to Reporting tools natively or via API Easily extensible for new devices and sources Trust Inferer: Repository for regulatory policy and logic Trust Tiers can structured around Compliance requirements as well as data access Trust Tiers can easily be deconstructed for gap analysis and overlap Stronger link between requirements and actual access Changes to regulations can modeled and introduced as new trust tiers without affecting existing access
Looking Forward Google built most of the code for BeyondCorp from the ground up Organizations looking to work towards a ZTN model should consider the following: Automation and Orchestration are critical for IT Security tools APIs Manually tracked data causes disproportionate amount of data validation issues Data can be accessed from surprising places Hidden operational data Non-security IT systems
Looking Forward Some products within the IT security space have the capability to provide some of the foundation for Device Inventory Service, Trust Inferer, and the Integrated Segmentation Gateway Even if an organization does not move to a ZTN model, components like DIS and Trust Inferer can still be leveraged as standalone services Software Defined Networking is virtually a requirement for ZTNs Scope of ZTN can be applied to identities and non-technical data User s access to PHI data containing systems is contingent in on the completion of PHI data handling training
THANK YOU! Questions? KSaucier@conventus.com This Presentation is powered by