Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Buildings don't fall down, why should network security

Tim Greene | May 14, 2014
Over the centuries the building trades have learned from their mistakes and set up complex systems of checks and balances that not only works but could serve as a model for network security, attendees at the Security Bsides Boston 2014 conference were told.

Over the centuries the building trades have learned from their mistakes and set up complex systems of checks and balances that not only works but could serve as a model for network security, attendees at the Security Bsides Boston 2014 conference were told.

Use of failure-mode effects analysis by the construction industry instills safety in the building process, something that could work to thwart network attackers by building in network protections in areas attackers have been known to exploit, said Michael Davis, CTO of Counter Tack during a Bsides keynote.

Network security pros should look at how security fails and what the consequences were, then build protections into future network designs, Davis said.

Failure Mode Effects Analysis was first used in the 1960s by NASA, he said, and has been employed in auto design. Cars have crumple zones less essential parts of the car that are designed to collapse during collisions in order to absorb the impact and protect passengers and more essential parts of the car.

That's a lesson network designers should emulate but don't, he said. "Nobody designs a network segment that can be turned over to the attacker entirely in order to save the rest of the network," he said.

Architects should study breaches, find the conditions that lead to failures and correct for them. This can be accomplished through analysis during design and implementing measures for mitigating the risks. Designers should ask, for example, what would it take to hit a particular server and what defenses would have to fail in order for an attacker to get through?

This methodology saved the Mars rover Spirit, whose flash became corrupted during its mission. Engineers had foreseen the possibility and instilled a secondary system in it that enabled controllers on the ground to re-flash and reboot the system, bringing the rover back to life, Davis said. The lesson? "Be prepared for the low-probability event with huge consequences," he said.

In network security the problems are extremely complex, he said. For instance, the Verizon Data Breach Investigation report says fixing nine security weaknesses can stop 95% of SQL injection attacks. But each of those nine problems connects to another nine that can ultimately lead to a successful breach. "You need to look at the chain of events, not just weaknesses in isolation," he says.

The complexity makes it extremely difficult to block all the problems, he said, so businesses need to calculate the business risk for each potential failure and address each in order of priority.

He proposes a formula for determining risk: Severity X Frequency X Detection = Risk Priority Number. Severity means the importance of the negative effect the attack can have on the environment (1 Not Severe, 10 Very Severe). Occurrence refers to the frequency with which a given cause occurs and results in failures and is based on historical data if possible (1 Not Likely, 10 Very Likely). Detection means the ability of the control scheme to detect and prevent a cause (1 Easy to Detect, 10 - Hard to Detect).

 

1  2  Next Page 

Sign up for CIO Asia eNewsletters.