How many security issues could we avoid if we knew the answer to “has this person ever done this thing before?” I’ve asked around, and the answer is: a lot. Sym makes it really easy to answer this question, and a whole bunch of related ones, with our new Historical Context release.
With a single get_event_count primitive, Sym implementers can implement a whole new range of guardrails and automations. All using rules that are simple to express in low-code event handlers, managed by your SDLC.
get_event_count provides a clean way to check for first-time access and respond differently:
On the opposite extreme from flagging requests for extra scrutiny, you can also use get_event_count to fast-track repeat requests.
You could set up your temporary access system to grant people access for a week, or a month. But this means that people may hold on to access for longer than they really need to do their job. You can really tighten your grant windows by using get_event_count to see when the last time the user was approved for access, and fast tracking their access in this case.
Historical Context is another important milestone for Sym as we work to help teams build least privilege controls that actually work. “Actually work” means - your velocity stays high, you’ve mitigated the risk of over-provisioned access, you’ve increased visibility and participation in your security culture, you can manage controls with your SDLC, and your teams don’t need to implement workarounds to get stuff done.
The way Sym helps you solve your least privilege challenges is by letting implementers easily surface and integrate context in our SDK. If you want to reduce the default scope of access on your team, you need to also be able to efficiently increase someone’s access scope when their task requires it. You need the right context to make these access decisions, either automatically or with human review. Historical Context is a new flavor of context that is based on a user’s previous behavior working with Sym.
You can create powerful customizations with get_event_count because we’ve exposed these features in our SDK. You can use the filter_on parameter to check if someone has ever been approved for a specific target in your flow as opposed to the flow overall:
For our auto-approve example, what if you don’t want this re-approval cycle to go on indefinitely? You can check how many grants the user has had overall in the past month, for example, and cut off approvals after N grants:
There is a fleeting but joyful time for parents when you can convince kids that something needs to happen simply “because it’s a rule”. Now you can experience this for the first time or anew with Sym! A practical alternative to training machine learning models is to develop rules-based systems. Rules can be sophisticated, adaptive, and make improvements to processes that often have a ton of low-hanging fruit to optimize.
In The Authorization Game, I used the blueprint of Turing’s famous argument for thinking machines to make a case for Sym’s approach to dynamic, context-based authorization. Using “thinking machines” themselves, however, is typically a premature optimization. Security practitioners are understandably wary about how to apply AI to security problems. Using technology that is probabilistic in nature is problematic when we need to implement processes that are provably correct. The potential upside of AI from an efficiency perspective is real, but it will take some time to really understand how to apply all this safely in security contexts.
Luckily there is plenty of room to make security processes more efficient without AI. Jumping to AI solutions presupposes that our security processes have a baseline of optimization. We don’t need AI, however, to tell us that someone who is new to a process should probably get some extra training or review before they jump into it. We don’t need AI to implement a policy that if someone has already been approved to do something in the morning, they can do it again in the afternoon.
We’ve got a bunch more releases teed up in the next few weeks that will further develop our support for least privilege and zero trust, so stay tuned.
Speaking for all us history majors out there, I appreciate that Max named this feature Historical Context rather than something about, I don’t know, events or users? History, as a rule, is great.
