News Article | December 11, 2019

Who Are The Bad Guys Anyway? – Part 2

Making a Case for Zero Trust

By Steve Lindsey, CIO/CTO LiveView Technologies,

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-premise 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 inter-communicate 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!  [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 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 Cloud(s) (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 lookout for while researching the risks of potential XaaS providers:

  1. 1. 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.
  2. 2. Load Balancers and Access Gateways should be used to front all service end-points.
  3. 3. Databases should never be accessible to the outside world.
  4. 4. Server Terminal/Command Line services like (SSH and Telnet) should never be accessible to the outside world.
  5. 5. 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 end-point.
  6. 6. Signed-Certificate Authentication standards like OpenIDConnect, OAuth2.0, and even SAML2.0 are musts for any cross-site SSO or authorization.  If the XaaS provider requires you to provide username and password credentials to access a dependant 3rd Party site, then Red Alert! Avoid that XaaS provider!
  7. 7. Multi-Factor Authentication (MFA) should be enforced on EVERYTHING.  This can be done through an IAM intermediary or each service better have MFA.
  8. 8. 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.
  9. 9. 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. See IAM and MFA points in the section below titled “Looking to the Future.”  

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 takes it seriously also.  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-premise 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 Identity and Access Management (IAM) system with MFA that in turn will single sign-on (SSO) 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 SAML2.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-premise 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 with certainty any electronic source 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(s) should be a partner 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 the XaaS’ core competency after all. So, save yourself the costs, overhead, and headaches.

Recent Posts

View All Posts