Part of the problem with securing hybrid IT is that many people are confused about what that even means. Furthermore, even those who understand what it means are unsure of how security policies should account for hybrid IT.
Why? Well, it’s complicated, literally.
At its core, hybrid IT is complex — IT infrastructure and applications running on-premises (in your own or a hosted data center) combined with anything in the cloud. It’s a mix of services completely owned and managed by an internal team plus services completely owned and managed by a third-party vendor.
In the most recent SolarWinds IT Trends Report (2016), 92% of IT professionals said adopting cloud technologies is important to their organizations’ long-term business success. While that may point to an all-cloud future, the reality is that you will be leveraging cloud as just part of your overall IT strategy, but not moving all your infrastructure to the cloud for some time, if ever. In fact, according to the report, 60% also said it’s unlikely that all of their organizations’ infrastructure will ever be migrated to the cloud.
This means you need to understand and develop security policies that account for a world with a mixed ownership model.
One of the key pieces to this mixed ownership model is Software-as-a-Service (SaaS). SaaS is a way of delivering software. It simply means that the consumer of the software doesn’t have to worry about the underlying details of the application or infrastructure, they just consume the business service, such as email or CRM. Similarly, in the enterprise, IT usually delivers applications as a service, often with monthly or quarterly bill back to the department or business unit consuming the service. And the past 10 years have seen the mass market adoption of public SaaS, which means we in IT now have even less to worry about in regards to getting applications to users. Of course, there are some challenges that come along with this.
When there’s a problem with the infrastructure or applications required to deliver a service that we don’t own or manage, we’re stuck opening a ticket and waiting to hear back like everyone else. Sure, there are a few things we can check — we can ensure our internal infrastructure is operating or that our next ISP isn’t experiencing any problems, but that’s about it.
This is the core challenge of hybrid IT — responsibility without control.
And of course, this isn’t just a problem for ensuring availability. The classic security model of confidentiality, availability, and integrity all look different in a hybrid IT world. By definition, hybrid IT takes data that was in your data center and spreads it out across the internet. How do you ensure confidentiality if your data is entered into a vendor’s application and that data is then shipped across the world to data centers with different local regulations on data security? Application-level encryption in transit, typically TLS, can help, but just because the data was transported securely doesn’t mean it will be stored securely.
The same thing applies to the integrity of your data. How do you ensure that the data stored out of your control doesn’t get modified? Even in complete on-premises deployments, I rarely see IT departments have a program in place to ensure and audit the integrity of the data they store. To be fair, it’s much easier to find news about data breaches from on-premises deployments than from public cloud or SaaS vendors. The point isn’t to argue that private is more secure than public or hybrid, but that as a supplier or consumer of these services, you need to understand how the confidentiality and integrity of your data is being managed.
Another security issue related to hybrid IT has to do with where certain components of an application are deployed in the cloud. For example, a database or message queue service. This is how many IT departments start when they want to migrate their existing applications to the cloud, particularly web services. Of course, net new applications also follow this path as well.
Whenever you do this, you need to ensure that you not only follow your internal security processes, but that those processes are updated to take into account the unique deployment nature of cloud-based services and how that changes your design. For example, it’s easy to spin up a Database-as-a-Service (DBaaS) instance and simply start using it. But just as you wouldn’t put your database server directly on the public internet, you need to ensure your network policies are in place such that only the required servers can access that service.
This is where I see a lot of people get tripped up. If you are using DBaaS, understand that it’s just one component. Remember, you still have to solve the connectivity and security problems just as you did when you deployed a database in your own data center. Complicating matters is that when it comes to anything “as-a-service,” there is often the expectation of very fast deployment, often at the expense of security. Although this speed vs. security issue has always been a problem, it’s exacerbated by the very nature of the cloud — easy deployment and sitting outside the existing security perimeter.
Whether you’re just getting started down the cloud path or are fully involved in a hybrid IT environment, your security policies and controls should clearly reflect the reality of a distributed, mixed ownership IT world. Wherever you’re at, it’s never too early or too late to ensure your hybrid IT plans position you to deliver secure and reliable services; just be sure to take the necessary time to fully understand how it changes your infrastructure, your team, and your approach to security.