Blog Security When technology outpaces security compliance
June 10, 2019
4 min read

When technology outpaces security compliance

Where does today's tech transformation leave tomorrow's security compliance? A senior security analyst tackles the question.

signpost-sunset.jpg

For the past couple of years, security compliance frameworks have felt increasingly less representative of the technology of today, with good reason. Everything from computing to network security has experienced a continental shift.

It feels like just yesterday I was hunting for the best deal on T1 lines and a reliable, dedicated server host. And the design meetings held to put together an elaborate, hardened network perimeter feel fresh in my mind as well.

Now we can deploy infrastructure with a few clicks (or lines of code), with load balancers not requiring any pre-warming and content delivery networks (CDNs) effortlessly at our disposal. Serverless computing provisions compute resources just long enough for the job to finish, no system administration needed. On the software end, containerization has isolated applications from the environment they run in and removed reliance on the particulars of the infrastructure.

And zero trust – trust nothing in the network, always verify – is gaining traction as an alternative to the network perimeter model. At GitLab we're on our own journey toward zero trust, and as the technology supporting zero trust gets better and more accessible, adoption will likely continue.

How (and where) we work is changing, too

At GitLab, we’re all remote. In fact, I started writing this blog post in New Orleans for GitLab Contribute, then flew to Washington, DC for a graduation and finished the first rough draft, and now I’m at a Starbucks in the Seattle area adding the finishing touches.

So where does all this transformation leave security compliance? Well, the frameworks of five years ago were designed to help secure the technology of five years ago, which is much different than the technology used in the production environments of today. A security best practice now may have no representation in a framework designed for the security best practices of years prior, and the incredible things we’re doing for security may not be recognized by those frameworks. Because of advances and changing practices like remote work, physical security controls sometimes may not be applicable, for example.

The frameworks of five years ago were designed to help secure the technology of five years ago

In the past, technology has been outpacing security compliance, but the former is catching up thanks to individual and industry contributions and a strong enthusiasm for making security more sensible and accessible.

We're starting to see a steady adoption of the modern, changing technology landscape by compliance frameworks. Security compliance frameworks such as FedRAMP offer “a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services,” to simplify compliance in a cloud-first environment.

At GitLab, we're creating our own compliance controls framework and open sourcing it as we go. This gives other organizations a practical, real-world reference on how we at GitLab approach compliance as a cloud native, all-remote company.

Progress is ongoing

Compliance is changing along with the technology we use, so the story we tell of what we're doing, why, and how it aligns with compliance standards has to change along with it. At the same time, the standards have to evolve with us, so they can support and enable us as a driving force behind our efforts to protect the consumer.

I think both are happening at a pace that should positively surprise us all, but there’s a natural, appropriate, and intuitive expectation from the technology community at large that security compliance frameworks be more directly relevant and supportive of security itself. This raises the bar, while sending the message that we need to be more focused on protecting the consumer than on crafting wordsmith-quality justifications for our controls and mitigations to satisfy an auditor.

To end, I’d encourage everyone to think about what security compliance frameworks could be doing to help enable security and protect customers that isn’t happening already. Then, share your thoughts, struggles, ideas, and feedback to your network and get the conversation started. We’d love to hear from you in the comments below, too! When we collectively vocalize both our frustrations and solutions, we can work together to make incredible progress.

Photo by Javier Allegue Barros on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert