Abstract—The increasingly sophisticated Advanced Persistent
Threat (APT) attacks have become a serious challenge for enterprise IT security. Attack causality analysis, which tracks multi-hop
causal relationships between files and processes to diagnose attack
provenances and consequences, is the first step towards understanding APT attacks and taking appropriate responses. Since
attack causality analysis is a time-critical mission, it is essential
to design causality tracking systems that extract useful attack
information in a timely manner. However, prior work is limited
in serving this need. Existing approaches have largely focused on
pruning causal dependencies totally irrelevant to the attack, but
fail to differentiate and prioritize abnormal events from numerous
relevant, yet benign and complicated system operations, resulting
in long investigation time and slow responses.
To address this problem, we propose PRIOTRACKER, a backward and forward causality tracker that automatically prioritizes
the investigation of abnormal causal dependencies in the tracking
process. Specifically, to assess the priority of a system event, we
consider its rareness and topological features in the causality
graph. To distinguish unusual operations from normal system
events, we quantify the rareness of each event by developing
a reference model which records common routine activities in
corporate computer systems. We implement PRIOTRACKER, in
20K lines of Java code, and a reference model builder in 10K lines
of Java code. We evaluate our tool by deploying both systems in
a real enterprise IT environment, where we collect 1TB of 2.5
billion OS events from 150 machines in one week. Experimental
results show that PRIOTRACKER can capture attack traces that
are missed by existing trackers and reduce the analysis time by
up to two orders of magnitude.
Microsoft’s version of verified access.
Any security capability is inherently only as secure as the other systems
it trusts. The BeyondCorp project helped Google clearly define
and make access decisions around the platforms we trust, shifting
our security strategy from protecting services to protecting trusted platforms.
Previous BeyondCorp articles discussed the tooling Google uses to
confidently ascertain the provenance of a device, but we have not yet covered
the mechanics behind how we trust these devices.
Virtually every company today uses firewalls to enforce perimeter
security. However, this security model is problematic because, when
that perimeter is breached, an attacker has relatively easy access to a
company’s privileged intranet. As companies adopt mobile and cloud technologies,
the perimeter is becoming increasingly difficult to enforce. Google
is taking a different approach to network security. We are removing the
requirement for a privileged intranet and moving our corporate applications
to the Internet.
The goal of Google’s BeyondCorp initiative is to improve our security
with regard to how employees and devices access internal applications.
Unlike the conventional perimeter security model, BeyondCorp
doesn’t gate access to services and tools based on a user’s physical location
or the originating network; instead, access policies are based on information
about a device, its state, and its associated user. BeyondCorp considers both
internal networks and external networks to be completely untrusted, and
gates access to applications by dynamically asserting and enforcing levels, or
“tiers,” of access.
We present an overview of how Google transitioned from traditional security infrastructure
to the BeyondCorp model and the challenges we faced and the lessons we learned in the process.
For an architectural discussion of BeyondCorp, see .
Google’s employees are spread across the globe, and with job functions
ranging from software engineers to financial analysts, they require a broad
spectrum of technology to get their jobs done. As a result, we manage a fleet
of nearly a quarter-million computers (workstations and laptops) across four
operating systems (macOS, Windows, Linux, and Chrome OS).
Our colleagues often ask how we’re able to manage such a diverse fleet. Do
we have access to unlimited resources? Impose draconian security policies
on users? Shift the maintenance burden to our support staff?
The truth is that the bigger we get, the more we look for ways to increase
efficiency without sacrificing security or user productivity. We scale our
engineering teams by relying on reviewable, repeatable, and automated
backend processes and minimizing GUI-based configuration tools. Using and
developing open-source software saves money and provides us with a level
of flexibility that’s often missing from proprietary software and closed
systems. And we strike a careful balance between user uptime and security
by giving users freedom to get their work done while preventing them from
doing harm, like installing malware or exposing Google data.
This paper describes some of the tools and systems that we use to image,
manage, and secure our varied inventory of workstations and laptops . Some
tools were built by third parties—sometimes with our own modifications to
make them work for us. We also created several tools to meet our own
enterprise needs, often open sourcing them later for wider use. By sharing
this information, we hope to help others navigate some of the challenges
we’ve faced—and ultimately overcame—throughout our enterprise fleet
Previous articles in the BeyondCorp series discuss aspects of the
technical challenges we solved along the way [1–3]. Beyond its purely
technical features, the migration also had a human element: it was
vital to keep our users constantly in mind throughout this process. Our goal
was to keep the end user experience as seamless as possible. When things
did go wrong, we wanted users to know exactly how to proceed and where to
go for help. This article describes the experience of Google employees as they
work within the BeyondCorp model, from onboarding new employees and
setting up new devices, to what happens when users run into issues.