The growth of modern cloud computing has brought with it new security doctrines, notably among them the zero trust principle. “Zero trust” is an undeniably attractive tagline, evoking absolute precision in computer security — the sort of unhackable mega-system that would have an ensemble lineup of Clooneys and Pitts scratching their heads, unable to plan a heist.
In practice, zero trust is more of a heuristic (or even, as we have argued before, a meme). It acts as a guideline for which systems should be segmented and require login to verify an agent’s identity. This heuristic has become an increasingly central concept in managing access to modern decentralized cloud systems or VPN adaptations for a work-from-home environment. Even so, the principles of zero trust are impractical to implement with total rigor, and misconceptions about those principles can actually lead to weakened security.
At Sym, we want to work within the bounds of practicality to bring you the best possible security for your business. To do that, we have found ourselves rethinking the orthodoxy around zero trust, and wanted to share some of our insights and tools that might help improve your data safety. This article will also demo a particular use case with our product — managing AWS IAM Identity Center/SSO access via a Slack controller.
Often, when zero trust is being defined, the concept of a “perimeterless security system” comes up. That means there are no agents — inside or outside of a network — that are trusted by default. Here, trust is used to indicate that access is granted without authorization, to agents that don’t have to prove they are who they say they are. Demonstrating identity might look different for different agents, from supplying a .pem file to multi-factor authentication.
Data systems have become much more complex with the advent of cloud computing, and it is increasingly difficult to plug gaps that once didn’t exist when most networking was physically limited. Now, work-from-homers might access servers from any IP in the country, making it hard to whitelist access. Services distributed across load balancers, CDNs, or other dynamically updating services similarly make identity hard to verify.
The zero trust philosophy treats each transaction and access point as a potential gap, and flatly requires verification at each step. This eliminates loopholes based on leftover trust, and by emphasizing identity and identity verification, all transactions can be monitored and logged.
Zero trust has a strong intuition, then: modern problems require modern solutions. But the emphasis on “never trust; always verify” has a constant problem of ergonomics. Configuration files have to be jiggled, logs sanity checked, hanging deployments aborted. The repetitive minutiae of development mean that shortcuts will be taken, and in the end holes may develop.
One lesson we constantly encounter when discussing security with clients is that the greater the friction of an access control system, the more holes develop around it. If you asked every engineer at your company about the risks of poor security, every one of them would probably have a good understanding of the necessity of access control… and yet, each one would also probably have a story about cutting corners on an urgent or repetitive task.
Security that is too burdensome might be undermined by legitimate users.
It’s not that anyone wants to break the airtight bond of a zero trust system, but security systems that attempt to apply machine templates to human behavior will inevitably bump into dangerous edge cases (like a dev SSHing into a server on airport Wi-Fi to make some vital touchups before their two-week vacation).
In the end, if well-designed access controls cause such a burden to the function of a system that the system needs to undermine the access controls, then it does not actually have adequate access controls.
The absolute approach to trust, as we have seen, is to eliminate it entirely. This is rarely observed in systems in practice, however, and especially for companies that are growing faster than their security culture can match.
So, rather than thinking about trust in absolute terms, we like to regard it as a quantity that is ideally very small in a given system. By requiring identity verification in a minimally invasive way, we can achieve the bulk of the advantages that a zero trust implementation would, without the dragging effect that can serve to undercut production and security observance.
Using Sym to set up your access workflows, you can implement what might be called appropriately minimized trust. “Appropriate” is an important word in our space; SOC 2 auditors like to use it to indicate that a given security protocol is reasonable for its situation. Sym workflows route some — or, in stricter forms, all — access requests to managers and administrators through a painless Slack interface. Permission requests can be analyzed, granted or rejected, and recorded in seconds.
Sym allows the implementation of access management with a (security) infrastructure-as-code philosophy. With Sym, you implement access restrictions from a codebase, generating verifiable rules that are absolutely enforced. This means that the “perimeterlessness” of zero trust is easily observed in your access management. And even though the basis of decision making is still rigid — no permissions are allowed by default — the decision making itself is much more comfortable, amounting to little more than asking your team lead for temporary access while chatting in the break room.
New features allow for common-sense sanity checks, like automatically informing access managers of rare types of requests from a given user. By using Sym to minimize default access to a handful of high-level accounts, and by minimizing the actual time taken to grant access, the total quantity of stray trust in the system stays at a minimum. Furthermore, many of the core guidelines of a zero trust model, like intensive logging of access, are integrated out of the box with Sym.
Let’s take a look at how this plays out in one of Sym’s most popular use cases: AWS SSO authorization.
IAM Identity Center (formerly Single Sign On or SSO) is a key element of zero trust implementation in the AWS ecosystem, enabling identification of any user in your cloud. Most security designs are based on managing users in this framework, and fluency with the IAM Identity Center is crucial to running a secure cloud system.
Using Sym, it is easy to set up a flow for adjusting access in the IAM Identity Center at the level of either individual users or admin-defined groups. This means that trust can be zeroed out most of the time: that the default user and access group can have all permissions removed in the AWS environment. Only when access is requested — easily, through Slack — is permission escalated, and only for a duration defined by the manager granting access.
To quickly breeze through the setup for this IAM Identity Center/SSO permission manager, you will need:
Again, you can follow along with us in this tutorial. Start out by running symflow init in the directory where you want your flow to be stored.
You will also need an AWS config profile that enables access to your IAM Identity Center account. Running aws configure sso --profile sym-sso-provisioning will handle this – note that you will have to log in with your own IAM Identity Center user.
Once Sym is initialized and the appropriate AWS profile is set up, move the directory and run symflow generate --type aws-sso.
You will need to select how to manage your AWS SSO users. We will select AWS SSO permission sets. Be sure to enter the canonical name for the SSO permission set when the command line requests it.
Running terraform init & terraform plan will confirm that your setup is correct, and you will be able to use terraform apply to finally go live on Slack:
Requests that are submitted will appear in the #sym-requests Slack channel, where managers can approve or deny access requests.
We’ve shown how easy it is to set up a basic flow here, but there’s a whole world to explore with Sym. From automatic detection of anomalous access requests to building a robust system in advance of an audit, Sym can support your security development with next-level access management.
We’ve just talked about how to rethink zero trust as a philosophy and the advantages of improving the ergonomics of access controls. When security gets easier to enforce, it also becomes stronger, and Sym is a great tool for strengthening security while easing access.
In addition to the IAM Identity Center access flow we looked at here, Sym has dozens of other workflows to support tools you use. Integrations with services like Datadog, PagerDuty, and Segment are all available, as is the majority of the AWS ecosystem.
If you want to manage permissions through Slack, log access in a way you can read, and encode security using Terraform — enforcing a set of standard, clear rules that auditors love to see — Sym is the right tool for you.
To learn more, you can schedule a call with our founder, or run through our quickstart tutorial using our free tier.
