Source author record

Adam Hastings

Adam Hastings appears in the imported research catalog. Authorship, coauthor and topic links are available while profile ownership is still unclaimed.

ResearcherUnclaimed source record

Catalog footprint

What is connected

3works
4topics
3close collaborators

Actions

Connect this record

Log in to claim

Research graph

See the researcher in context

Open full explorer

Inspect adjacent papers, topics, institutions and collaborators without losing the researcher page.

Building this map preview

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

3 published item(s)

preprint2022arXiv

COMMAND: Certifiable Open Measurable Mandates

Security mandates today are often in the form of checklists and are generally inflexible and slow to adapt to changing threats. This paper introduces an alternate approach called open mandates, which mandate that vendors must dedicate some amount of resources (e.g. system speed, energy, design cost, etc.) towards security but unlike checklist security does not prescribe specific controls that must be implemented. The goal of open mandates is to provide flexibility to vendors in implementing security controls that they see fit while requiring all vendors to commit to a certain level of security. In this paper, we first demonstrate the usefulness of open security mandates: for instance, we show that mandating 10% of resources towards security reduces defenders losses by 8% and forestalls attackers by 10%. We then show how open mandates can be implemented in practice. Specifically, we solve the problem of identifying a system's overhead due to security, a key problem towards making such an open mandate enforceable in practice. As examples we demonstrate our open mandate system -- COMMAND -- for two contemporary software hardening techniques and show that our methodology can predict security overheads to a very high degree of accuracy (<1% mean and median error) with low resource requirements. We also present experiments that quantify, in terms of dollars, how much end users value the performance lost to security, which help determine the costs of such a program. Taken together -- the usefulness of mandates, their enforceability, and their quantifiable costs -- make the case for an alternate resource-based mandate.

preprint2022arXiv

How Much is Performance Worth to Users? A Quantitative Approach

Architects and systems designers artfully balance multiple competing design constraints during the design process but are unable to translate between system metrics and end user experience. This work presents three methodologies to fill in this gap. The first is an incentive-compatible methodology that determines a "ground truth" measurement of users' value of speed in terms of US dollars, and find that users would accept a performance losses of 10%, 20%, and 30% to their personal computer in exchange for \$2.27, \$4.07, and \$4.43 per day, respectively. However, while highly accurate the methodology is a painstaking process and does not scale with large numbers of participants. To allow for scalability, we introduce a second methodology -- a lab-based simulation experiment -- which finds that users would accept a permanent performance loss of 10%, 20%, and 30% to their personal computer in exchange for \$127, \$169, and \$823, respectively. Finally, to allow for even greater scalability, we introduce a third methodology -- a survey -- and observe that the lack of incentive compatibility and the lack of hands-on experience with throttled device performance skews the results significantly, thus demonstrating the need for lab-based or incentive compatible study designs. By quantifying the tradeoff between user satisfaction and performance, we enable architects and systems designers to make more nuanced tradeoffs between design requirements.

preprint2020arXiv

A New Doctrine for Hardware Security

In this paper, we promote the idea that recent woes in hardware security are not because of a lack of technical solutions but rather because market forces and incentives prevent those with the ability to fix problems from doing so. At the root of the problem is the fact that hardware security comes at a cost; Present issues in hardware security can be seen as the result of the players in the game of hardware security finding ways of avoiding paying this cost. We formulate this idea into a doctrine of security, namely the Doctrine of Shared Burdens. Three cases studies---Rowhammer, Spectre, and Meltdown---are interpreted though the lens of this doctrine. Our doctrine illuminates why these problems and exist and what can be done about them.