I’ve been a car audio enthusiast my whole life. I remember my first car stereo system, a Pioneer receiver, JL Audio subwoofers, Rockford Fosgate amps, Alpine speakers, and a sweet Viper car alarm system to protect it all.

In the 1990s, I wasn’t the only one; people started putting expensive systems into their cars, and the rate of car theft went up significantly. We saw the rise, transformation, and fall of the bolted-on car alarm, which was supposed to detect and prevent car thefts.

Today I spend my time in the cybersecurity world and not the car audio world, but nevertheless, the lessons apply to both. Security in the Cloud continue to be a hot topic. More and more organizations are moving to the cloud, more sensitive data is moving to the cloud, and data theft is on the rise.

Some may argue that Intrusion Detection Systems (IDS) are the solution, but I believe that future security will be driven by the Cloud Service Providers (CSPs), and not the IDS companies of today.

A few months ago, the Cloud Security Alliance released “Improving Metrics in Cyber Resiliency,” a whitepaper that proposed key metrics designed to help measure security risks and response. They introduced two core metrics – how long it takes to identify a threat—Elapsed Time to Identify Threat (ETIT); and how long does it take to identify a failure—Elapsed Time to Identify Failure – ETIF.

When analyzing breaches in 2017, many ETIF rates have been up to a woefully inadequate year or more. Imagine that: many companies don’t even realize that there is an issue for a YEAR! Because these metrics have been tracked haphazardly and inconsistently by victim organizations, the paper further proposes that responsibility for tracking and publishing ETIF and ETIT befall upon IDS companies in the future to establish a superior and consistent reporting schema, while also putting the spotlight and pressure on these companies to ultimately arrive at reduced intervals. I disagree.

Putting the future of cloud security in the hands of IDS makers is like putting the theft of automobiles in the hands of the car alarm manufacturers. It is short sighted and will not scale at the pace of innovation of the CSPs. The solution is to accelerate the standardization, APIs, and nomenclature of the CSPs, not the IDS providers. Why? Let’s check out the lessons from car alarms.

Lesson 1: People break into cars to steal what’s in the cars, not just the cars themselves. If you want to prevent people from smashing your window, don’t buy stronger windows, put your items in the trunk. Cloud providers have known this and developed several ways to “hide” your valuable data including encryption, segmentation, and anonymization. These are not typical solutions from IDS vendors today.

Lesson 2: You have to be able to react to the alarm. It’s not helpful to get an alert that people are breaking in when you can do nothing about it because you are far away/out of town. For IDS systems to become valuable and turn into Intrusion Prevention Systems (IPS) systems, they must have access to the environment and the ability to make decisions (with human or automated rules) to stop an attack midway. Because every cloud environment is different and becoming more complicated every day, the IDS vendors have a losing battle.

Lesson 3: It’s going to be commoditized, and the value will be in future features. Nearly every car alarm today is also a remote unlocking system, remote engine starter, and GPS tracking device. To do what needs to be done to prevent the bad guys from getting in, you need access under the hood (hypervisor, code, etc.). Each CSP has certain IDS vendors that do a better job than others. These vendors (or a subset of them) will be the future of cloud security. There will be a massive consolidation, and people will just “expect” the Cloud to come with built-in IDS, just as you “expect” that most new cars have remote unlock and car alarms built in. It’s not a bolted-on solution; it will be baked in.

Consider, for example, highly publicized data exposures attributable to Amazon Web Services S3 Buckets data repository in 2017. Amazon got a bad rap in the news because customers were exposing millions of sensitive records to the world, and IDS systems were not working.

However, it wasn’t even AWS fault—they provided a locked down database and companies proactively re-configured the systems to the internet. AWS had to respond by updating their customer interfaces to figuratively shout at their customers, saying: “Are you REALLY sure you want to open this up to the world?” The solution, burden, and reputation relied on the Cloud provider, and not the IDS vendors.

There is no one “car alarm” for security, and today’s current IDS vendors will still be relevant for some time. However, over time the “IDS Enthusiasts” will diminish over time and will be replaced with increased security from the cloud providers. They will always have features and benefits that will differ from their cloud counterparts, but it’s a losing battle.

Car alarms of the past were useful for their intended purpose—keeping in mind what that purpose and scope truly were, just as IDS has a purpose, application and scope. Both, however, have their limits and future applications.

Hopefully, today’s cybersecurity experts can learn from the car audiophiles of the 1990s. Let’s focus our efforts on building better platforms, and less on the bolt-on solutions that are the stop gap.