Mitigating Meltdowns | AHEAD

Mitigating Meltdowns

This post originally appeared on PM Network Magazine.

When a group of researchers at the Graz University of Technology in Graz, Austria tried to hack their own system in a security simulation, they made an astonishing discovery. The Intel processor chips used for many years in an overwhelming majority of computers in the world had two major flaws in their memory-management processes. Soon after the discovery, the research team submitted a bug report to Intel about both vulnerabilities—and helped kick-start a global conversation around how organizations should launch projects to address cybersecurity vulnerabilities.

The Meltdown flaw, which affects nearly every microprocessor made by Intel, allows malicious programs to gain access to parts of a computer’s memory. The other, called Spectre, steals passwords and other data from the memory of applications running on the machine.

In January, Intel and other developers began feverishly working on patches designed to fix the flaws. At the same time, IT teams around the world were rerouted from other projects to focus on shoring up vulnerabilities, which were considered threatening but not critical. Nearly 30 percent of large companies expected to spend 80-plus hours on projects intended to address Intel’s flaws, with 18 percent of companies assigning those projects budgets of more than US$50,000, according to a Spiceworks survey.

Approaches varied across industries as reports conflicted about whether to replace chips or install patches. Banks, for instance, are testing patches to see if they would impede computing performance, Greg Temm, chief information risk officer, Financial Services Information Sharing and Analysis Center, told Reuters. His organization works with large financial institutions. “It’s like getting a diagnosis of high blood pressure but not having a cardiac arrest,” Mr. Temm told Reuters. “We’re taking it seriously, but it’s not something that is killing us.”

Risk Register Longevity

For as much effort as organizations placed on shoring up security in response to Intel’s flaws, the breach also posed a new challenge for hardware and software manufacturers around the longevity of IT projects’ risk registers.

While patches might protect against risk for the moment, they don’t address a more systemic problem in how data security is handled in hardware and software projects, says Daniel Gruss, one of the Graz University of Technology researchers. “In every development project, security requires extra time and money. But stakeholders don’t always want to make those investments.”

A project plan might include security features at the outset, but if implementing those features interferes with performance, budgets or deadlines, sponsors often are swift to cut them loose. To avoid this scenario, Mr. Gruss encourages project teams to include security experts who can better understand and advocate for the security needs of specific projects.

Security experts also can help project owners understand when a seemingly innocuous risk will become a serious problem, says Steven Aiello, security and compliance solutions principal at IT consultancy AHEAD, Detroit, Michigan, USA. With the Intel chip, for instance, the original developers decided the performance gains that came from not fully “unmapping” the memory space were worth the risk. “It was a business decision,” Mr. Aiello says.

Tracking Threats

5,375 – The number of unique publicly disclosed vulnerabilities reported in the first three months of 2018—a slight increase over 2017.

3 out of 4 – of those reported vulnerabilities have a patch, proper workaround or fixed version. That leaves 1 in 4 unsecure.

Source: Vulnerability Quick View, Risk Based Security, 2018

At the time, there was no way to exploit the bits of data left behind, and the less-secure solution delivered measurable performance gains. Fast-forward 20 years, however, and hackers have gotten a lot more adept at finding and exploiting small flaws, making that seemingly logical choice a significant risk to millions of customers.

Of course, it’s nearly impossible to make a product impenetrable to threats that might not materialize for decades, but Mr. Aiello says it is possible to safeguard the future with a life cycle risk register that’s regularly reviewed by a risk auditor. “Risk registers shouldn’t die when the project is complete,” he says. “From a project management perspective, assumptions about risk have to be considered for as long as the product lasts.”

Once the IT development project is completed, the product owner, in collaboration with the IT and cybersecurity team, should revisit that risk register whenever the product is upgraded or there are major changes in the product landscape, says Mr. Aiello. He points to a common refrain among security professionals: Security is a process, not a product. —Sarah Fister Gale