Internet's Security Woes are Not All Technical

BLACK HAT ASIA - Singapore - Technical shortcomings aren't the only flaws in today's Internet. Organizational structure and the balance of market power are also poking holes in an already fragile system.

Google engineer Halvar Flake discussed the actors, incentives, and industry challenges impeding Internet security as part of his keynote "Why We Are Not Building A Defendable Internet" here this week at Black Hat Asia 2017. Protected devices are part of the solution, but there's more to risk management, he said.

Flake began his discussion by describing the way businesses, security vendors, and customers should interact. Ideally, a business' CISO and their team develop security requirements and communicate their needs to the organization. Leaders make requests of vendors to provide products they need.

But in reality, that's not happening today. "This is not how purchasing works in any way, shape, or form," he explained. "The reality is, software vendors and the entire supply side for IT is entirely scale-driven."

The enterprise has little market power in shaping the design of security products they use, he noted. Few companies can give input to software or hardware vendors to influence the design process.

If businesses have little say in product features, CISOs have even less. Security leaders want to buy reliable products for their teams, but there aren't many available. Vendors and cyber insurance companies realize security leaders can't get exactly what they want, so they sell other products and services to fill the gap, he said.

Much of today's security tech exists to protect the CISO, Flake said. Functionality comes second. The biggest risk to the CISO is being perceived as missing a threat to the business. It doesn't matter whether the product performs; it simply has to seem like a reasonable choice. Purchasing security products often relies on marketing and manageability, he admitted.

"Security products may not help all that much, but they look like they could plausibly reduce the risk of the enterprise," Flake explained. "If you've bought a product, and the product fails to stop the risk, at least it's not your fault."

This contributes to the rise of cyber insurance, which offers to mitigate the cost of a breach and ensuing cleanup, he said. Cyber insurance is a new and evolving field. Many companies don't know policies often don't insure loss of reputational risk, user trust, or critical intellectual property.

There are a few ways cyber insurance could change the game for security teams, according to Flake. Insurers may need to acquire new levels of expertise to help differentiate good security products, or offer lower premiums to companies buying legitimately secure products.

That said, there are many cyber insurance factors that could lead to negative outcomes. Evaluating cyber-risk is hard because there is little historical data, he said. Technology changes so quickly that data collected years ago may not accurately predict risk today. Further, risks can be great. If a large breach occurs, "replace all devices" could be a feasible -- and expensive -- outcome.

All of this leads us to a bigger question: How to manage risk until better products come along. Flake notes how security leaders have adopted a defeatist attitude: "'Whatever we do, we'll always have many, many bugs.'"

This isn't actually true, though, he said. The ability to understand the attack surface and implement strong risk management are what sets apart experienced security pros.

One way to do this is to view IT infrastructure like a financial balance sheet, Flake said. As a whole, it provides daily benefits, but each component of the infrastructure has a risk of blowing up and becoming a liability. Installing software means incurring risk on your "balance sheet." Adding code to software is like adding risk to the balance sheet of each customer.

Most organizations don't know how to incentivize security. Employees are quick to add new software features because it will yield praise and promotions, but additional code broadens the attack surface, according to Flake.

Few people offer to reduce privileged code because it doesn't offer the same reward. The truth is, software has so many features and components that cutting code would be beneficial because it decreases the attack surface, he said.

"Too few people understand the equivalence between code and risk, or treat it as such," Flake said. Businesses need to recognize the role of incentive structure and pay to cut code where it's necessary.