Sergey Nivens - Fotolia
Right now, someone around you is worrying about CVE-2015-7457, but not worrying about all the time they waste patching applications instead of embracing software as a service benefits.
CVE numbers are assigned to entries in the Common Vulnerabilities and Exposures database, essentially a big, government-sponsored catalog of security problems. CVE-2015-7457 is a particularly bad one, where a problem that lies deep in a Linux operating system library, glibc, exposes every application and program that uses DNS. An intentionally malformed DNS response can help someone break into your applications.
"DNS ... I've heard of that," you say, jokingly. But it's no joke.
This vulnerability has been in Linux for eight years, a long time in IT. Long enough to be present in all the underpinnings of everything that powers our enterprises and clouds. Whole economies and companies have come and gone in the time this problem has been stewing in our IT infrastructure. It's underneath everything that is Amazon Web Services, Rackspace, Digital Ocean and so on. And it's underneath most of our on-premises infrastructure, too.
Even more important than being in our infrastructure, this vulnerability is in our applications. The applications I run in my on-premises private cloud are affected. The applications I run in the public cloud are affected, just as if they were on premises. In fact, it's likely worse, since the applications in the cloud don't have as many security controls as my on-premises instances. On its face, infrastructure as a service (IaaS) doesn't save us from any of these issues. Because it is not software as a service (SaaS).
I often say that the journey to the cloud isn't a technological journey. It's a journey for the people in IT. People who have done it nod their heads knowingly; people who haven't think I'm crazy. While IaaS doesn't save us from the need to remediate critical security vulnerabilities, just like we did 10 years ago, it allows us to change our processes. That's because we can instantiate new containers, new virtual machines, and new operating system images in seconds, and we can treat those components as disposable. When something is wrong, we throw it away and get a new one. A security problem certainly qualifies as something wrong.
The big problem is that, with enterprise software, unlike SaaS, we can't just throw an instance away and deploy a new one. Software vendors like Oracle and Microsoft don't let us, or have no automation capabilities or no support for us even if we do get it working. So even when we do get into the cloud mindset for automating and deploying services, we're prohibited from the start.
So let's throw it all away. Truth is, IT is not a competitive advantage for most enterprises. When I get thinking about the dismal state of automation for enterprise software I start to think that perhaps we are clinging to the old ways too much. When virtualization first came about there were people derided as server huggers. They fought hard to keep their old ways. We've moved past that to application huggers, fighting hard against obvious software as a service benefits for the right to expend immense amounts of effort fruitlessly.
Consequently, it's not hard to imagine that SaaS is where it's at for most shops. Why are you running your own three-tier application when you could just buy the product in ready-made form? Imagine all the neat things we could do with SaaS APIs and integrations, building actual competitive advantages, if only we had time to do it. The time we spend patching and maintaining our old applications, which will never be anything but an anchor, are drowning us in the past.
Get over it, folks, and let's move on to more interesting parts of our lives. Take a look at the obvious software as a service benefits, and don't look back.
- Migrating from Manual Schedules to Totally Optimized Scheduling –IFS
- From Process Automation to IT Orchestration –Goverlan
- Ansible In Depth: A Playbook for Complex IT Orchestration –Red Hat
- Ansible Tower Demo: The Case for IT Orchestration –Red Hat