Why we created Syclops

Posted On // Leave a Comment
Syclops started out as an attempt to create a SSH proxy that would function as a primary network gateway appliance. The appliciance would allow for centralized management of a large number of SSH keys and server connections, without compromising the security of the individual keys.

As cloud consultants and providers of managed services for cloud infrastructure, we amassed a large number of SSH keys that controlled access to an even larger number of servers running critical workloads of our customers. We realized that unless we changed the way we handled and worked with these SSH keys, we would have tremendous difficulty in helping our customers meet their operational confidentiality and compliance guarantees required by law. This in turn would affect our customers' credibility with their customers. We wanted to ensure that any SSH access was only granted when relevant, and only to the degree of access needed for the job on hand, and provide detailed information to our customers regarding connection access, details of changes made during a session, etc.

As we spent more time researching possible solutions, we realized that cloud computing was completely changing the value proposition, and importance, of SSH and SSH Keys for enterprises. The rapid proliferation of cloud computing, and the ease with which vast numbers of servers can be launched and terminated anywhere in the world in shared datacenters, has completely changed the way applications are developed and deployed. Today, developers in organizations of all sizes have the power to quickly scale to a huge number of servers with a few mouse clicks, leading many organizations to resort to a fragmented and ad-hoc approach in managing their SSH server infrastructure.

Why Syclops is needed

  • Rapid proliferation of Cloud Computing and Services - The acceptance of cloud computing by developers and enterprises as a mainstream solution for application deployment has contributed to significant changes in the way companies operate today. IAAS platforms such Amazon Web Services, Microsoft Azure, OpenStack etc. have conditioned developers to treat servers as disposable, so applications are now built as multi-tiered stacks that are deployed across multiple global locations. Organizations are no longer reluctant to deploy parts of their stack across multiple vendors, giving rise to multiple systems and locations to manage, and user access rules to control.
  • Growth of distributed teams and remote working - Many organizations are adopting flexible work practices such as remote working, and even adopting virtual teams as their primary operational model, resulting in team members located in different parts of the world. This gives rise to challenges in ensuring secure access to internal resources despite the users connecting over public internet. Depending on the location and distribution of various resources involved, this can quickly scale out of hand and result in significant overhead in adminsitration and management.
  • Rise in outsourcing of critical functions & remote consultations - Outsourcing of core functions, including infrastructure management, complete development activities, etc. is a considered a viable operational model today. Consultants and other 3rd parties often require access to critical resources as part of the engagement, often times from remote locations, resulting in greater exposure to unauthorized access and security breaches, not including data loss and theft. Companies need a comprehensive mechanism to monitor and audit work done on these resources to ensure business continuity and mitigate risk.
  • Stricter regulatory standards and governance - The adoption and growth of the Internet has resulted in sweeping regulations across the world primarily related to data security and ensuring user privacy. In certain countries such as the USA, regulations related to IT practices have now been mandated as part of normal business governance (e.g. in SOX for accounting). Domain specific regulations (such as HIPAA for healthcare, PCI-DSS for credit card security, etc.) are now enforced with significant penalties for violations. The risks associated with violating any of these regulations are so high that companies need to be pro-active in enforcing strict control and auditing systems to ensure compliance.

Why we decided to change the way SSH Keys are used

Changing the way SSH Keys are used by users is central to how Syclops goes about tackling these challenges being faced today by companies using SSH-based infrastructure.

Think about the role SSH and SSH keys play in the cloud-powered Internet we have today

  • Most major cloud vendor and platform today uses SSH and SSH keys to authenticate remote access to the Linux/Unix command line of a cloud provisioned server instance.
  • GitHub, BitBucket, and many other industry leading SCM platforms and services use SSH to secure code repositories and validate user access.
  • DevOps is built on SSH. Every major automation platform, be it Puppet, Chef, Salt, Ansible, etc. uses SSH as the basis for communicating with remote servers when executing the automation sequences.
  • Auto-scaling systems and self-healing infrastructure such as AWS’ Auto-Scaling Groups deploy multiple copies of server images using the same SSH key, which allows companies like Amazon, NetFlix, FourSquare, etc. to rapidly scale functionality without worrying about differences in code and consequent behaviour in these servers (as their configuration is identical).
It’s not an understatement to say that SSH is the lifeline on which most of the current Internet is built on, especially the Linux/*nix powered part.

So what happens if you don’t take care to manage SSH and SSH keys effectively?

  • Your infrastructure is at risk of being compromised, and as a result any data stored on the compromised infrastructure as well.
  • Your source code and intellectual property can be compromised and stolen if the keys used to access your SCM platforms is compromised.
  • Application integrity is at risk as malicious/innocuous changes can be made by unauthorized persons, which can result in a significant amount of resources being required to diagnose and rectify problems, as often times the cause of the problem is not immediately evident.
  • When auto-scaling and replication are automated, access to one system can result in the entire system being compromised.
  • Meeting compliance and governance standards such as HIPAA, SAS70, ISO27001, etc. is much harder as no structured process/workflow is in place to streamline auditing and management of infrastructure access.
Essentially, your business credibility is at risk, as service downtime, and more importantly your infrastructure being compromised, can result in a major backlash from both existing and potential customers.

Yes, there are ways to address these issues, but they require significant overhead and administrative effort, not to mention some of these solutions involve making frequent changes/edits to the configuration of the remote servers. This defeats the purpose of snapshotting and imaging the servers, as their utility to allow for rapid recovery of services in case of server failure/downtime is lost if they contain stale configurations.

Syclops’s operational design puts it at the heart of all SSH communication between users and provisioned servers. Syclops is perfectly positioned to segregate the management of these two pieces into independent actions, and give trusted administrators and managers the power to control conditional access for users to servers, and revoke privileges WITHOUT having to alter or disrupt the servers themselves in any way. No key is EVER shared directly with a user, eliminating the risk of the keys ending up in the wrong hands.


Post a Comment