When you’re driving your car, you view it as something completely protected. You’re driving it, and if you’ve maintained it, it’s going to likely drive as it should. I recently spoke with a friend who said he views his car as a ‘black box’; he drives it, but he relies on his mechanic to tell him if something is wrong with it. The unfortunate reality is that now, even while you’re driving, your car could potentially be taken over by a rogue hacker.
While it may sound like something out of a spy thriller or sci-fi novel, over the last few years, hackers have found numerous ways to hack into a vehicle, from taking over the on-board navigation system through an unsecured WiFi network designed to look like a public network, to hacking into a local mechanic’s diagnostic system then using that system to access the car’s on-board diagnostics.
In fact, as far back as 2011, researchers were finding ways of hacking into cars as weird as giving a car driver a free CD that could remotely take over the vehicle. While all the methodologies discussed have been proof-of-concepts and shared with the automakers, the fact remains that no system that relies upon any sort of network – internal or external – is safe from potential hacking.
While it isn’t true for some businesses, many businesses view their internal servers just like my friend does with his car – like a black box. Maybe they have some protection software, be it an antivirus, a vulnerability detector, or even a more robust system such as Security Information and Event Management (SIEM). But no mix of these things can prevent against what the hackers did in some of the ways they took over cars – they took advantage of a trusting consumer (or user, as the case may be), or they used another more vulnerable system to hack into a protected one.
Fortunately, there are ways to protect against these sorts of hacks. Let’s consider the example of the mechanic computer that was easily breached, then used to hack into the cars on-board computer. If there were a way for the car (or the on-board computer) to only allow access to what the mechanic computer needed access to, the situation would be prevented. Now consider a driver (or employee) being given a USB drive (or CD). They could put it in their computer, but not be able to do anything; even if code were deployed, it would never be able to get beyond the local device, because the car (or server) would essentially say “Woah. You’re not supposed to be here.”
This is, albeit simplified, what Attribute-Based Access Control (ABAC) is designed for. ABAC allows for companies to intelligently control what parts of their IT infrastructure are able to be accessed based off of attributes, not users. The ‘old-school’ methodology of Role Based Access Control (RBAC) wouldn’t prevent against the situation of a mechanic computer interfacing with a car computer. But with an attribute-based system in place, the computer (or network) now has a lot more flexibility to make determinations as towards not just who can access the system, but what parts of the system they can access, their privilege levels, and much more. Combined with a real-time system-wide methodology such as Dynamic Authorization, companies can get one step closer to closing the gaps in their system most traditional vulnerability management solutions leave behind.