Sym on OWASP: Codify Workflows for Security and Speed
Last month Jon and Yasyf joined Stefania Chaplin and Shinesa Cambric on OWASP DevSlop to discuss the challenges and benefits of codifying security workflows. They drew on examples from their backgrounds running engineering organizations in healthtech companies as well as lessons they’ve learned at Sym, helping our customers automate security workflows. Below is a summary of some of the key points from their conversation.
Security-workflow-as-code? Check out yesterday's show with Yasyf & Jon from @symops . In this short 2 mins clip, Yasyf explains the security workflow he created in a previous role that inspired Sym! Replay with hosts @devstefops & @Gleauxbalsecur1 : https://t.co/YgofHdePtL pic.twitter.com/RlVTdmZPiA— OWASP DevSlop (@Owasp_DevSlop) June 8, 2021
Move fast or be secure?
Engineering leaders are feeling increasing pressure to improve their secure posture despite a relentless pace of feature development. This is particularly intense in heavily regulated industries such as healthcare, where HIPAA’s Privacy and Security Rules require companies to take many steps to protect PHI. Implementing security controls to comply with regulations slows down organizations by requiring them to create new workflows and cumbersome modifications to existing processes. For example, you watch in horror as your SDLC gets bogged down while safeguards are rolled out—approvals to run queries, deploy code or gain access to production systems, to name a few. As CTO of his own heathtech startup, Yasyf felt this pressure mount as his company grew. He knew that automation was the only way to avoid trading speed for security. Today, as CEO of Sym, Yasyf is bringing many of the lessons he learned successfully codifying security workflows in the healthtech world to Sym’s customers so they too can have the best of both security and speed.
Why is codifying security workflows so hard?
First, let’s define what we mean by “security workflow.” Security workflows are governance processes associated with security and compliance matters such as access management, incident reviews and risk management. Getting them set up usually begins with rolling out manual processes involving tools such as spreadsheets, word docs and ticket queues.
A concrete example could be an approval process for just-in-time-access (JIT). Let’s say your organization wants to remove long-standing credentials that grant access to production systems. Your ops team may set up a Jira ticket queue for engineers to request a limited duration of access. Suddenly there are extra steps for engineers to request access to production, extra steps for administrator to update your directory service or secrets manager to grant that access and even more work to remember to revoke access and make sure everything is properly recorded for audit time. These painful, error-prone, tasks are now candidates for automation (to see an example of a well-automated version of this process, checkout how Sym can help automate approvals for Hashicorp Vault).
Most companies begin to incorporate their own automation into these workflows, but few successfully automate security workflows end-to-end. It always ends up more difficult than people think.
Implementations get stuck
Before developers can start building the bots, scripts, services and jobs to help automate security workflows, someone in the organization needs to figure out who will build them, how long it will take and which features get pushed out to make room. This is where things usually get stuck.
Stuck between preventative care and emergency fixes
Automating internal processes is the type of preventative care that developers and product managers are not always motivated to prioritize. Once the true cost of building a comprehensive software solution (including writing code, testing, deploying, scanning and monitoring) is scoped, that five minute process will suddenly seem like something the team could probably live with for a few more months. Good luck getting that work on the backlog.
On the flip side, when your manual process, or lack of process, inevitably results in human error that precipitates an incident response, the remedy is often reactionary and overkill. These are not the times when teams are in the creative headspace to implement an elegant solution. Efforts to fix security process gaps in the wake of an emergency often result in creating more overhead rather than more automation.
Stuck between organizational boundaries
The compliance and governance people at your company know which policies are critical to implement but they often don’t have access to the resources required to automate them. At his previous company, Yasyf was able to codify many of the workflows required to keep his company’s patient data safe only because he had both the skills and autonomy. His background in compilers, contributions to Ruby on Rails, knowledge of HIPAA and status as CTO allowed him to avoid coordination challenges. He just built it all himself. But not every organization has that luxury. The difficulty of getting one department’s priorities scheduled on another department’s backlog is the cause of many stuck projects and this is the situation most companies find themselves when it comes to security workflows.
Stuck between system boundaries
Automating security workflows usually involves integrating with a large number of systems which, along with hosted products and cloud infrastructure, can include your own product, code and internal tools. Each system has its own API, auth scheme and release lifecycle. It’s tough to glue together systems that are so heterogeneous and continually changing. But the biggest culprit of “stuck implementations” just might be organizational dependencies associated with integrating with internal systems. It’s tough to decide whether to spend time integrating with the legacy solution that everyone actually uses or wait for the new shiny solution that has been “almost done” for the past few quarters.
So, how do we get these workflows codified?
In 2021, with only a few lines of configuration, developers can define a complete CI/CD pipeline or provision a new relational database but the tooling isn’t quite there to do the same in the security world. If we could fast forward a few years to a time when it will be as easy to create workflows to protect infrastructure as it is to create the infrastructure itself, what would those enabling tools look like?
At Sym, we believe that logic which defines a security workflow can be best expressed with imperative code. But we also realize that code itself carries its own maintenance burden and that leveraging abstractions over common functionality can help reduce that burden. We’ve developed a way to treat the common components of security workflows as infrastructure and provision them the same way you would a server, database or VPN on AWS. We’ve found this usually covers 80% of the logic of a given workflow, leaving the remaining 20% of custom logic to be defined in a common programming language.
Concretely, this means that our customers can define a security workflow with a few lines of Terraform and a few lines of Python. The declarative nature of Terraform allows our customers to provision a high level workflow in Sym and include Python to define custom logic at specific points in that workflow.
We considered other approaches to automating security workflows such as no-code or low code solutions as well as web-UI based implementations but we found that using code to automate security workflows seems to be the best approach to mitigate risks of stuck implementations. There are a couple reasons why we find this works.
It’s important to meet developers where they are
Implementations are more successful when developers can use their own tools. For example, if a team has invested in an infrastructure as code (IaC) pipeline, they’ll already have tooling, processes and best practices they can use to also manage our security-workflows-as-code approach. In fact, we’ve found that if solutions are available to incorporate into their existing toolset, developers will often proactively adopt them without InfoSec spending effort to get the same tasks prioritized.
Code is actually the right tool for the job
The biggest reason that code is the answer is that it truly seems to be the right tool for the job. From thirty thousand feet these workflows may look the same across companies, but once you zoom in you’ll see massive variance resulting from the combinatorial explosion of systems, org structures and policies. Code enables developers to implement the exact logic they need to keep their company and customers safe. Halfway through Jon and Yasyf’s session, the OWASP audience already had their own ideas of what logic they would build with the freedom that security-workflows-as-code offers.
Automate it all away?
Just because you can now automate security workflows doesn’t mean you can replace your security team. Your security teammates wake up everyday thinking about how to keep the company, employees and customers safe. They know the regulations and know the best way for your company to comply with them. In short, you need them. Having the right primitives available to your engineering team to codify security workflows simply provides a way for engineering and security to better collaborate. The best companies will find a way to break down those silos.
Thanks OWASP DevSlop!
Automating manual processes to go faster and be more secure fits in well with the DevSecOps ethos. Jon and Yasyf had a great time chatting with Stefania and Shinesa and spreading the word that you don’t need to compromise on speed in order to be secure. Thanks OWASP and you’ll be hearing from Sym again soon!