Cloud XaaS at your service
Due to the public accessibility of their services, many cloud-based XaaS providers are already built on zero trust architectures today. In fact, it is these XaaS providers that are aggressively contributing to the community by researching and implementing robust technologies and solutions in identity and access management as well as microservices architectures that are far more secure than their on-premises software counterparts. Combined with the benefits of flexibility, increased collaboration, lower cost of ownership, accessibility, better disaster recovery, and stronger security, it is no wonder that many companies are moving to true cloud-based XaaS providers for their future IT services.
So how do you choose an XaaS provider that does implement a robust zero trust architecture? The simple answer is to ask. Ask them to describe their system architecture at a high level (you don’t need the gory details and they probably won’t tell you the gory details). Do all of the software services reside in a single software stack or are they distributed across multiple servers or service containers (microservices)? Ask if authentication is required and always validated to allow those software services to intercommunicate with each other. Are there granular access-control list (ACL) policies that each software service enforces based on the identities of the other services trying to access it? If software services are inherently trusted up and down the stack or across the stack, then you probably want to stay away from that XaaS provider.
Nerd alert!
(Warning—this paragraph may cause headaches, extreme boredom, or the strong desire to think of something else like your celebrity crush.) I believe it is necessary to highlight a major difference in authentication (what we would call the act of “logging in”) that needs to be understood. Basic authentication (the good old-fashioned username and password) that has traditionally been deployed in software stacks for decades can easily be compromised. If the username and password credentials are known, access is automatically granted, often without any detection that the credentials have been compromised. On the other hand, using the modern method of encrypted key-pair identity tokens, devices and software services can now prove their identities in a much more secure and reliable manner that is nearly impossible to spoof. Therefore, if an XaaS provider uses simple username and password credentials to authenticate devices and software services, run for the hills! If their authentication is that ancient, their technology probably is too. (End of the boring paragraph.)
Further interrogation of your XaaS provider should include questions regarding network architecture. Ask if the XaaS provider places all software services into one or many virtual private clouds (VPCs). This can be accomplished with a single VPC or strategically segmented into multiple VPCs depending on the complexity of their architecture. The thing you want to understand is whether VPCs are used (a good thing) and whether or not other non-essential services or servers are cohabitating that VPC (a bad thing). No other devices, servers, or software services should exist in the VPC except for the core software services. There should be no possible way that human error can allow a Trojan horse into the VPC.
There is a lot more to the cyber security of an XaaS stack than I intend to get into detail here, but I do want to highlight some immediate and obvious red flags that can indicate a larger problem. For those of you who really want to geek out, the following is a list of red flags to look out for while researching the risks of potential XaaS providers:
- No IP addresses or service ports should be open to the outside world except for HTTPS and the necessary service ports required for the XaaS service.
- Load balancers and access gateways should be used to front all service endpoints.
- Databases should never be accessible to the outside world.
- Server terminal/command line services like (SSH and Telnet) should never be accessible to the outside world.
- Any necessary service ports open to the outside world must be hardened with a strong Identity authentication and access control gate keeper on the software service endpoint.
- Signed-certificate authentication standards like OpenID Connect, OAuth 2.0, and even SAML 2.0 are musts for any cross-site single sign-on (SSO) or authorization. If the XaaS provider requires you to provide username and password credentials to access a dependent third-party site, then red alert! Avoid that XaaS provider!
- Multi-factor authentication (MFA) should be enforced on EVERYTHING. This can be done through an identity and access management (IAM) intermediary or each service better have MFA.
- Code should never be directly deployed from developer computers to production servers. Instead, a rigorous continuous deployment (CI/CD) procedure and system should be used.
- System administrators and/or operators of the XaaS service should never have direct access to administration portals or core services without some form of MFA. To take this a step further, having an IAM intermediary that can handle lifecycle management of employees (zero day start and end) is ideal.”
After asking the XaaS the correct questions and getting the answers, it should be obvious at that point whether or not the XaaS provider in question has a robust zero trust architecture and roadmap. Cyber security is a BIG and NEVER-ENDING job so you should expect the XaaS to have a living roadmap for their zero trust architecture. Take cyber security seriously and ensure that your XaaS provider also takes it seriously. After all, it is in the best interest of the XaaS providers to do all they can to ensure cyber security is a core foundational part of their service offering. Otherwise, they won’t be in business very long.
Looking to the future
Migrating your current legacy systems to a zero trust architecture will take some time and some planning. However, don’t let that stop you or even slow you down. The good news with moving away from an on-premises system to an XaaS provider is that you know you are going to be future proof. Hopefully, this is the last time you have to make such a large migration. Put your efforts into a strong IAM system with MFA that in turn will single sign-on into your various XaaS providers (although password managers are useful and better than nothing, try to use true SSO signed-certificate authentication standards like OIDC or SAML 2.0). The IAM you select can make a huge difference moving forward. IAM providers to consider are Okta, Ping, Auth0, etc. Adding lifecycle management of employee identities with HR systems as the master source of truth will be a strong cyber security measure allowing you to provide zero day start and stop of employee access to the services they need.
While working through your migration plan, also start to make plans for your corporate network. With all of your on-premises software services moved to XaaS providers, your corporate network is now nothing more than an internet hotspot, like you would find at your nearest internet cafe. You will still want to implement best practices of firewalls, anti-virus/malware on workstations, private and guest networks, etc. However, remember that you can’t trust any electronic source with certainty, so you are not relying solely on the purity of your private network for protection. You are simply limiting your blast radius if an incident should arise.
At the end of the day, your company owns the liability for the cyber security of your company’s IT services. Although XaaS providers carry some responsibility for data protection and cyber security, you need to make sure your company has an active incident response plan that identifies potential threats, action items to either address those threats or know how to handle the threats should they arise, and then has a training program to educate employees within your organization on the incident response plan and your data protection policies. Your XaaS provider should take part in your incident response plan so you need to make sure you understand the XaaS provider’s incident response plan and have reasonable service level agreements (SLA) in place. The SLA should not be limited to just up times. The SLA should also include timeframes and actions the XaaS provider needs to take to give you all of the details should a cyber security incident arise. Remember, it’s not a matter of “IF” but “WHEN” a cyber security incident happens. Be prepared to respond as timely and decisively as possible.
Final thoughts
There is no need to be a recluse in today’s IT landscape. Being that IT tyrant that everyone in your company hates is not your lot in life. It is possible to provide accessibility, convenience, and security; they are not mutually exclusive as once thought. The cloud XaaS providers can definitely help with the transition. Make sure to find the right one!
Make your life easier and stop trying to duplicate the wheel. Know your core business and only put forth the capital IT resources needed to execute on that core business. If you are a police department, be a police department. If you are a dentist, be a dentist. If you are a security company, be a security company. Don’t build data centers and hire excess IT staff and software developers if that isn’t your core business. There are XaaS providers out there that probably already do what you are trying to do on your own. Odds are the XaaS can do it better and cheaper than you can do it. It is their core competency after all. So, save yourself the costs, overhead, and headaches.
