Intel recently awarded an unrestricted gift of $70,000 to Nathan Dautenhahn to help automate software security. The Rice University assistant professor of computer science proposed building a compiler that could digitally automate the representation, reasoning, and application of millions of human decisions regarding identity and access.
“When it comes to technology security, we have a clear problem and that’s over privilege,” said Dautenhahn. “We also have a clear solution: minimize privileges. But there is no systematic way to do that or even come close. The degree to which we don’t adhere to minimal access to data and systems is astronomical. Our proposed solution, Opportunistic Privilege Separation (OPS), is one way to automatically manage access control.”
The high cost of assigning “just enough permission, just in time” prompted a lack of discipline regarding access-management processes, resulting in continual exposure of sensitive data at increasing rates. Rather than complain about the issue, Dautenhahn decided to tackle the problem.
He said, “There are only two keys to my house. I have one, my wife has one. But what if my keys are mass-produced through an assembly and distribution line spanning continents? If 20 thousand people are involved in making and maintaining my two keys, any one of them might lose - or sell – a copy. The reality is that those 20,000 people have access to the keys to my house. Except for physical safety, I’d argue our digital lives have the most influence over our safety.”
Dautenhahn was troubled by what he viewed as a juxtaposition of the obvious best way to resolve software security issues and a complete disregard for even a good way of resolving the core of the issue by the technology industry.
“The gap between what is and what could be has inspired me to solve software security problems in fundamental ways,” he said. “My natural preference is for minimality. So as I started to learn about operating systems and the way they were organized and abused, the natural solution is to build for simplicity and remove gaps between software interfaces.”
“When I design machines or systems, I look for the simplest, most primitive solution. When it works, I put it in a box. Then I ask, what is the next thing needed to get the job done? The simplest solution is the best solution at each stage, linking box to box. Start with the smallest minimal thing, then build on it.”
Computing systems have traditionally been built to resemble hotel ballrooms, with partitions that can be adjusted to meet changing needs. Without rigid separation, problems ranging from foul odors to fire in one part of the ballroom can quickly impact the rest of the space.
Another analogy is the adjacent cells in the Titanic. The ship’s transverse bulkheads, vertical barriers dividing its hull into a series of sixteen cells from stem to stern, had no attached ceilings. As one end of the vessel sank deeper into the ocean, water filled up each cell and poured over the partial barrier to flood the next.
“Computing systems are like a modern-day Titanic,” said Dautenhahn. “It was a great vessel for navigating complex waters and had tremendous potential. Our advanced hardware today is similar to those complex waters and our software ships have two major problems. The outer shell is vulnerable and the internal structures are not set up to isolate penetration. With one tiny pinhole penetration, the whole thing sinks.”
Rather than focusing on hardware to solve separation issues, Dautenhahn looks at identity and access. What if the gaps in the Titanic were impervious to water but permitted air, equipment and crew members to pass?
“Now we’re talking about a compiler solution,” Dautenhahn said. “At this scale, we need a machine to manage the complexity of identification and permission control. A human simply can’t manage all those decisions about access. We haven’t yet built a machine to solve it, but I think we can forge a path to that kind of solution.”
Today’s machines can already build a graph identifying who should have access to what information, but the immense size and complexity of the graph makes it too costly for humans to extract appropriate models.
“The government does it, but their process is unsustainable for any non-national security environment,” Dautenhahn said. “The only way to bring the cost down to a reasonable figure is to change the way we think about access control.
“My team will focus on building the backend pieces that translate that kind of inference and reasoning to real systems. That’s where we need to represent, reason, and translate -- represent the access decisions, reason about the selection process, and translate the process into real systems.”
Dautenhahn is also concerned with how his team will fix things that break when their OPS compiler is deployed. The size of the model will make it difficult to visualize what the abstraction is actually doing on a granular level. Building models with metrics requires his team to quantify desired actions mathematically, then train the processes they want to retain in their system.
“Rigorous testing will help us gain confidence in our least-privilege solutions. But we can’t break existing systems,” he said.
“Limiting access may get in the way of ongoing systems or processes. If we break something, can we fix it without relaxing the new OPS protocols? We will have to quantify and describe the progress, keep the good stuff we‘ve made, and maintain compatibility with existing processes.”
This balancing act excites Dautenhahn, but he feels greater anticipation for the broader benefits of their solution. The problem of access has an impact on everyone who engages with technology systems, from software engineers to end users. No one wants to expose their part of the system, whether it is the engineer’s algorithms or the end user’s health or financial data.
Although each person has different goals, everyone wants to minimize exposure. According to Dautenhahn, the best way to satisfy the privacy concerns of all contributors and users is to bring down the cost of designing secure systems.
“We could stop data breaches at scale,” said Dautenhahn. “And there is already a technology precedent for creating a machine to do what humans could not. In the 1960s, everyone programmed in assembly languages. Programs were hard to optimize, too complex for humans to do it. But a compiler hacker said, ‘I can represent your problem in a way that the optimizer will do it.’ The first compiler made code optimized. That’s what I want to do for data access.”