Security can no longer be an afterthought, nor can IT leaders rely on security through obscurity. Here's how to incorporate security into IT products and initiatives from the start.
A major security breach that made news recently is the hack of a Jeep Grand Cherokee. Far less abstract than a data theft, the video included with the Wired article shows two mild-mannered engineers remotely controlling a Jeep vehicle miles away, with the hapless reporter at the wheel. The hacks start mildly enough, with the HVAC system being activated and the radio turned to full volume, and ultimately ends with the engine being turned off on the highway and the brakes being disabled. Even for the least IT savvy person, this video clearly demonstrates the risk of security breaches in a very real sense.
See on CNET: Fiat Chrysler to recall 1.4 million vehicles following remote hack and Fiat Chrysler waited 18 months to tell regulators about hacking risk
Security as an afterthought rather than as a feature
Security is largely an afterthought in most IT initiatives. While the need for security is always acknowledged, actually implementing that security is usually reserved for later stages of a project; in the worst case, it's assumed that the platform is far enough away from hackers' tentacles that security can be ignored or vastly simplified — the old concept of security through obscurity.
There are seemingly good reasons for waiting to implement security until the end of a project.
Security is difficult and can interfere with development and testing.
Most projects seek to get systems and code connected and talking in the simplest manner before worrying about securing it.
The project team assumes that proprietary systems and networks represent security that's "good enough," and well-meaning intentions to add security later are pushed off the roadmap when deadlines loom.
The main problem with this approach is that security becomes regarded as an additional layer that's applied atop a system that is tested and functional, or pushed to a future update since the obscurity of the platform is perceived as security itself. The logic goes that you get the underlying system "right" and then slap security on top when you can, usually at the final testing phases. This approach is obviously flawed, so rather than regarding security as a separate layer, regard it as a critical path feature that should be implemented early.
Test early and often
Just as the features and functions of a platform that are implemented earliest usually get the most rigorous testing, security that is implemented early will receive more rigorous testing and become more thoroughly integrated with the overall product. This can also mitigate the urge to add more security later; if security is a feature that's implemented early, the product can't progress until the security models are implemented and unit tested.
Security testing, often done as one of the last phases of the implementation, should be cyclical, and included in every phase of product testing. This not only improves the product's overall security, but it can ultimately save time and money, since you'll identify fundamental flaws in your security model that may impact other portions of the product. Security-related or not, it's better to discover a fundamental flaw in a system and correct it early, rather than identifying it at the last moment and realizing there is a cascade of dependencies that must be modified and retested as well.
Communicate the risk
IT security has long been perceived as a game of Chicken Little, with someone from IT expounding on the need for more security, while others are nervously looking at their calendars and the short remaining time for delivery. The problem with past approaches is that they focused on the technical aspects of security, rather than the direct business impact. For Jeep, the impact is painfully demonstrated in the video above; fixing security flaws that result in a customer's car being disabled or unable to brake is worth tens of millions of dollars in lawsuit avoidance alone.
IT leaders need to communicate the cost and timeline for integrating security as a key feature, as well as the varying levels of security that can be implemented, and the business risks they mitigate. Focus less on doomsday scenarios, and more about what risk mitigation additional time and money buys. There's a sweet spot between cost and risk that should be articulated and agreed on.
Get a little help from your friends
Many of these exploits have been identified by outside engineers and so-called white hats who attempt to hack systems to identify defects rather than do damage. Some may seek publicity or bragging rights, while others may seek cash outright. In either case, tapping into these resources can be a great way to augment internal or vendor-provided security services, and result in a better, more secure product overall.
While you may not be developing automotive systems, housing financial data, or storing secret government information, it's critical that security be a feature of any IT-driven product or project, rather than an afterthought and inconvenience. Failure to do so may not result in cars driving off the road, but it will certainly hinder your career from staying on its track.
No comments:
Post a Comment