SOC 2 compliance is one of the most common customer use cases we come across here at Threat Stack. Developed by the American Institute of CPAs (AICPA), the framework is designed for service providers storing customer data in the cloud, and SaaS companies among others often turn to us as they begin to feel overwhelmed by the requirements.

Many organizations struggle with how and when to deploy software. I’ve worked at some companies where we had a “deploy week.” This was at least a week (or sometimes even longer) that was completely devoted to deploying huge amounts of software. The changes were so large and complex that deploying them would cause massive amounts of pain and suffering. It took hours every night for a week to deploy them, and it was too difficult to test all the changes one by one. So engineering and operations teams — not to mention customers — had to deal with broken updates until we could fix each one.

Additionally, because of the sheer volume of changes being deployed, the code was difficult to test. Systems would break in unforeseen ways, which led to distractions for engineering teams that would get called in to fix the issues. Imagine losing your entire engineering organization for an entire week every time you push out new software and updates! If this happens once a month, every month, it gets unsustainable fast.

Because I’d experienced this pain firsthand, I wanted Threat Stack to be different when it came to how and when we deploy code. That’s why we worked hard to embed DevOps best practices in our organization from the very beginning, starting with engineering for rapid change. In this post, I’ll walk you through what this means and why it is essential to doing DevOps well. Read more “How Threat Stack Does DevOps (Part II): Engineering for Rapid Change”

One of my long-time pet peeves has been the abuse of the term “DevOps.” You can be a DevOps engineer, you can be a Director of DevOps, you can buy DevOps tools. But when people ask me “How does Threat Stack ‘do’ DevOps?”, I imagine them saying “How do you run Technical Operations?” See, it’s my belief that people often struggle at implementing DevOps because they don’t understand the complexity of technical operations. By this I mean managing the complexity of cloud environments, distributed systems, open source and home-built applications — and engineering them all for uptime and availability for customers. This is the crux of what it means to do DevOps well. Read more “How Threat Stack Does DevOps (Part I): Best Practices in the Wild”

Our recent survey found that over 50% of companies admit to cutting back on security measures to meet a business deadline or objective. As long as companies are willing to sacrifice security at the altar of speed, the long-held dream of marrying DevOps and security simply won’t become reality.

At Threat Stack, we use our own intrusion detection platform to protect Threat Stack. This gives us critical visibility into security events and alerts tied to our AWS infrastructure and instances, an all too popular target. But our infrastructure extends beyond AWS into additional vendor-managed solutions such as Cloudflare, SalesForce, corporate email, and others. So a key question is: How can we not only monitor those platforms, but also use the data from these logs to drive security priorities?

With that in mind, we set out to create a new custom internal app that can receive, store, and perform actions on information from all of these different sources. We opted to build this internal pipeline (some would call this security orchestration) instead of buying an off-the-shelf product because our security team indexes so highly on engineering and programming. We felt we could take an event-driven framework in a language we all knew and easily extend it to meet our needs, incorporating our internal detection and automated response frameworks, a choice we would not have made if our team or organization looked different.Read more “High Visibility Ahead: Building and Using Orchestration to Set Security Priorities”

At Threat Stack, we often talk about visibility. We have promoted visibility from an operations perspective and have given our customers visibility into their environments through our intrusion detection platform. But when it comes to change management, how do we give ourselves the same level of visibility into our internal process changes at Threat Stack? This became a very real question as we decided to roll out our Type 2 SOC 2 program over the last year, and the answer turned out to be sockembot — an automated SOC 2 compliance checking bot that we describe in this blog post.Read more “sockembot: How Threat Stack Added Automation & Visibility to its SOC 2 Change Management Process”

Good CEOs are committed to moving their companies forward, increasing revenue, and ensuring that their teams are productive. When business challenges arise, they approach them with the best intentions. After all, it’s the CEO’s job to have the company’s best interests in mind.

Live Thursday, March 1 at 1:00 p.m. EST (18:00:00 UTC)

Overview

A recent Threat Stack survey finds that over 50% of companies admit to cutting back on security measures to meet a business deadline or objective. As long as companies are willing to sacrifice security to gain speed, the long-held dream of marrying DevOps and security won’t come true.

Who & What

Join this webinar to hear Pete Cheslock, Threat Stack Senior Director of Operations, and Franklin Mosley, PagerDuty Senior Application Security Engineer, discuss the current status of SecOps along with critical gaps and obstacles.

Here are a few of the survey findings:

68% of companies say their CEO demands that DevOps and security teams do nothing to slow the business down

57% percent say their Operations team pushes back on security best practices

44% of developers aren’t trained to code securely

When

SOC 2, which was developed by the American Institute of CPAs (AICPA), is specifically designed for service providers storing customer data in the cloud, which means that it applies to nearly every SaaS company operating today.

So, what is SOC 2 exactly? While the framework is a technical audit, it goes above and beyond this to require that companies establish and follow strict information security policies and procedures. The criteria for developing these policies and procedures is based on five “trust service principles” to ensure:

Security

Availability

Processing integrity

Confidentiality

Privacy of customer data

Compliance can be evaluated by independent auditors who assess a company’s ability to comply with these five principles.

SOC 2 is one of the more common requirements that SaaS companies must meet, but that doesn’t make compliance any simpler or dealing with an audit any less exacting. In this post we have laid out the most important requirements and the steps you should take to become compliant quickly in order to stay out of trouble with auditors and compete in a crowded SaaS market.Read more “How to Get Your SaaS Company SOC 2 Compliant With Minimal Headaches”