Airbags and steel frames

January 11, 2016 by Konstantin Ryabitsev

In my keynote to the 2015 Linux Kernel Summit I compared the way we
currently approach IT security to the way car makers approached
automotive design in the 1960s. Back in the day, car companies
concentrated on adding more engine power, improving vehicle reliability
and tweaking the overall body design so it was both pleasing to the eye
and comfortable to drive -- all at an affordable price. They were so
successful at doing this, that we now describe that whole era as
“America’s love affair with the automobile,” and this era is far from
over yet.

But, as the auto industry was celebrating its successes, several voices
started sounding an alarm. People were spending more and more time
behind the wheel, driving longer distances and at much faster speeds.
Meanwhile, safety features offered in cars were still designed for the
era where most drivers were either professionals or drove for leisure,
at slow speeds, and on poor quality roads with few other vehicles.
With the advent of suburbs, highways, four-lane traffic interchanges and
speeds in excess of 70 miles per hour, the safety features designed to
keep humans safe were no longer adequate. What used to be a minor
fender-bender at 30 miles per hour was likely to become a fatal accident
at highway speeds. Offering merely seat belts and a padded dashboard was
no longer seen as acceptable. We needed front, side, and passenger
airbags. We needed crumple zones, anti-lock braking systems, and solid
steel frames.

We, as the IT industry, are going through the same growing pains. The
computing reality of 2015 is wholly different than 10, or even 5 years
ago, but our approach to IT security is still based on the assumption
that critical IT systems will be run by professionals who will take care
of safeguarding the OS for us. These professionals will set up
firewalls, virus scanners, web filters -- and will apply security
patches if critical bugs are discovered and fixed in the OS itself.

However, today’s is the world of millions upon millions of smartphones,
tablets, and other handheld devices. Today’s is the world where your TV
set and your security camera have an IP address -- and tomorrow it will
be your light bulbs, your water heater, and your front door lock.
Today’s is the world where your 2-year-old smartphone may stop receiving
security updates because the phone company is more interested in selling
you a new device than keeping the older one safe. Today’s is the world
where the Internet of Things gadgets can’t reasonably be patched at all
due to limited computing capabilities. And, as we are transitioning to
IPv6, more and more of these devices will no longer be tucked away
behind NAT routers, but will be globally accessible due to configuration
errors and insufficient network isolation. Are we truly ready for that?

As IT professionals, we need to ask ourselves some hard questions. What
approach should we be taking if we cannot reasonably expect that devices
will receive timely security updates? How can we teach the OS to
recognize when it is under attack so it can take necessary measures to
minimize the impact? What technologies do we need to develop and put
into our software that will be our equivalent of driver and passenger
airbags that will auto-deploy to protect our users from harm? Yes, even
if it’s all their own fault. We all make mistakes.

This is a conversation that all IT professionals should be having,
whether they are working on Linux, Windows, iOS, or any other operating
system used on consumer devices. Neither should it be a conversation
limited to the core OS developers. Systems administrators, end-user app
designers, network engineers -- everyone across the IT spectrum should
work to design systems that expect human mistakes or deliberate
malicious actions and then fail in the safest way possible in order to
protect the device operator.

Security is not a technology -- it’s a process and a mindset. Hopefully,
if we can change the mindset, the necessary changes to the process will
follow.