BeyondCorp4 – Migrating (summer2017) Peck et al.pdf – Google Drive

If you’re familiar with the articles about Google’s BeyondCorp network
security model published in ;login: [1-3] over the past two years, you
may be thinking, “That all sounds good, but how does my organization
move from where we are today to a similar model? What do I need to do?
And what’s the potential impact on my company and my employees?” This
article discusses how we moved from our legacy network to the BeyondCorp model—changing the fundamentals of network access—without reducing the company’s productivity.



BeyondCorp – Tiered Access

Traditional security models use a binary, all-or-nothing access model where access is granted solely on the basis of machine, user, and service membership into an authentication authority, such as active directory or LDAP.

Google is taking a different approach and using tiered access as one tool to address these challenges. In contrast to traditional models, tiered access provides more granular control. The level of access given to a single user or a single device may change over time based on device measurements allowing security to set access policy that considers deviations from intended device state.

At Google, the Technical Infrastructure organization manages access for the devices used by more than 61,000 employees while protecting against sophisticated adversaries. Below we outline the model that Google has adopted and continues to evolve as it’s rolled out. The first phase of roll-out has enabled access from mobile devices, while subsequent phases will expand enrollment to cover the entire fleet of Google devices.


Automatically Inferring Malware Signatures for Anti-Virus Assisted Attacks

Although anti-virus software has significantly evolved over
the last decade, classic signature matching based on byte
patterns is still a prevalent concept for identifying security
threats. Anti-virus signatures are a simple and fast detection
mechanism that can complement more sophisticated analysis
strategies. However, if signatures are not designed with care,
they can turn from a defensive mechanism into an instrument
of attack. In this paper, we present a novel method for
automatically deriving signatures from anti-virus software
and discuss how the extracted signatures can be used to
attack sensible data with the aid of the virus scanner itself.
To this end, we study the practicability of our approach
using four commercial products and exemplary demonstrate
anti-virus assisted attacks in three different scenarios.


The Security Architecture of the Chromium Browser

Most current web browsers employ a monolithic architecture
that combines “the user” and “the web” into a single
protection domain. An attacker who exploits an arbitrary
code execution vulnerability in such a browser can steal sensitive
files or install malware. In this paper, we present the
security architecture of Chromium, the open-source browser
upon which Google Chrome is built. Chromium has two
modules in separate protection domains: a browser kernel,
which interacts with the operating system, and a rendering
engine, which runs with restricted privileges in a sandbox.
This architecture helps mitigate high-severity attacks without
sacrificing compatibility with existing web sites. We
define a threat model for browser exploits and evaluate how
the architecture would have mitigated past vulnerabilities.


A Study of Security Vulnerabilities on Docker Hub

Docker containers have recently become a popular approach
to provision multiple applications over shared physical hosts
in a more lightweight fashion than traditional virtual machines.
This popularity has led to the creation of the Docker
Hub registry, which distributes a large number of official and
community images. In this paper, we study the state of security
vulnerabilities in Docker Hub images. We create a
scalable Docker image vulnerability analysis (DIVA) framework
that automatically discovers, downloads, and analyzes
both official and community images on Docker Hub. Using
our framework, we have studied 356,218 images and made
the following findings: (1) both official and community images
contain more than 180 vulnerabilities on average when
considering all versions; (2) many images have not been updated
for hundreds of days; and (3) vulnerabilities commonly
propagate from parent images to child images. These findings
demonstrate a strong need for more automated and
systematic methods of applying security updates to Docker
images and our current Docker image analysis framework
provides a good foundation for such automatic security update.


Blocking-resistant communication through domain fronting

Abstract: We describe “domain fronting,” a versatile
censorship circumvention technique that hides the remote
endpoint of a communication. Domain fronting
works at the application layer, using HTTPS, to communicate
with a forbidden host while appearing to communicate
with some other host, permitted by the censor.
The key idea is the use of different domain names at
different layers of communication. One domain appears
on the “outside” of an HTTPS request—in the DNS request
and TLS Server Name Indication—while another
domain appears on the “inside”—in the HTTP Host
header, invisible to the censor under HTTPS encryption.
A censor, unable to distinguish fronted and nonfronted
traffic to a domain, must choose between allowing
circumvention traffic and blocking the domain entirely,
which results in expensive collateral damage. Domain
fronting is easy to deploy and use and does not require
special cooperation by network intermediaries. We
identify a number of hard-to-block web services, such as
content delivery networks, that support domain-fronted
connections and are useful for censorship circumvention.
Domain fronting, in various forms, is now a circumvention
workhorse. We describe several months of deployment
experience in the Tor, Lantern, and Psiphon circumvention
systems, whose domain-fronting transports
now connect thousands of users daily and transfer many
terabytes per month.


Examining the costs and causes of cyber incidents | Journal of Cybersecurity | Oxford Academic

In 2013, the US President signed an executive order designed to help secure the nation’s critical infrastructure from cyberattacks. As part of that order, he directed the National Institute for Standards and Technology (NIST) to develop a framework that would become an authoritative source for information security best practices. Because adoption of the framework is voluntary, it faces the challenge of incentivizing firms to follow along. Will frameworks such as that proposed by NIST really induce firms to adopt better security controls? And if not, why? This research seeks to examine the composition and costs of cyber events, and attempts to address whether or not there exist incentives for firms to improve their security practices and reduce the risk of attack. Specifically, we examine a sample of over 12 000 cyber events that include data breaches, security incidents, privacy violations, and phishing crimes. First, we analyze the characteristics of these breaches (such as causes and types of information compromised). We then examine the breach and litigation rate, by industry, and identify the industries that incur the greatest costs from cyber events. We then compare these costs to bad debts and fraud within other industries. The findings suggest that public concerns regarding the increasing rates of breaches and legal actions may be excessive compared to the relatively modest financial impact to firms that suffer these events. Public concerns regarding the increasing rates of breaches and legal actions, conflict, however, with our findings that show a much smaller financial impact to firms that suffer these events. Specifically, we find that the cost of a typical cyber incident in our sample is less than $200 000 (about the same as the firm’s annual IT security budget), and that this represents only 0.4% of their estimated annual revenues.