Threat Stack Names Executives As Company Brings Innovative Cloud Security Service to Market

We're excited to announce today that we have added several key members to our management team.  Sam Bisbee has joined as CTO; Chris Gervais as VP, Engineering; and Pete Cheslock as Senior Director, Operations and Support.

“Threat Stack is at a really exciting point in time, as we come off a highly successful beta program and prepare to launch Cloud Sight into the market. Our management team has deep experience across enterprise, cloud, SaaS and security, and a track record for successfully bringing innovation to market.  Were thrilled to have attracted an all-star team.”

- Doug Cahill, CEO of Threat Stack

About the Executive Team

Sam Bisbee is a senior technologist that brings experience and expertise in delivering highly scalable distributed systems via SaaS.  Most recently Sam was CXO of Cloudant, a leader in Database as a Service (DBaaS) technology; before that he held key technology positions at Bocoup and Woopid.

Chris Gervais has led technology teams developing large, scalable, enterprise-grade solutions and bringing SaaS offerings to market.  Before Threat Stack, Chris was CTO and SVP, Engineering at LifeImage, a platform for securely sharing medical images; and VP, Engineering at Enservio, a SaaS application and analytics platform for insurance carriers.

Pete Cheslock has a record of supporting SaaS customers with highly reliable and scalable solutions.  Pete was previously Director of DevTools at Dyn, a provider of network traffic management and assurance solutions; and before that he was Director of Technical and Cloud Operations for Sonian, a cloud-based archiving platform.

“This team is a testament to Threat Stacks unique technology and the big problem that it addresses. Elastic and dynamic infrastructures, and the services that run on them, are really difficult to monitor and protect.  Threat Stack has cracked the code.” 

- Chris Lynch, Chairman of the Board and a partner at Atlas Venture

Our flagship product, Cloud Sight™, is the first and only intrusion detection SaaS offering purpose-built to provides elastic cloud infrastructure with comprehensive protection, detection and response against malicious threats.  Cloud Sight has been in a highly active beta program which resulted in multiple customer case studies, including Populi, a cloud-based college administration platform, and University of Hawaii at Manoa CollegeBeta participation ranged from SaaS vendors to MSPs and enterprises running in most major cloud service providers including Amazon Web Services and Rackspace, as well as in private and hybrid-cloud deployments. Cloud Sight will be commercially available this fall.

Interested in trying out Threat Stack? Request an invite to our beta: https://www.threatstack.com/request 

 

 

The Case for Continuous Security

By Pete Cheslock

This is the second post in our new series of weekly blog posts that dives into the role of SecDevOps. This series looks into why we need it in our lives, how we may go about implementing this methodology, and real life stories of how SecDevOps can save the Cloud.

DevOps is a term that has absolutely blown up in the last 5 years.  As someone who’s been involved with that community from the earlier days, it’s been interesting to watch the conversations around DevOps evolve over time.  For many people, they had an immediate adverse reaction towards Yet Another Buzzword -- especially when the core concepts that people described as being “DevOps” were things that many people had already been doing for years.  (I’m not going to bother getting into the specifics of “what is DevOps” since there is already a plethora of blog posts that you can easily find on it.)  

One of the core tenets of what people consider to be “DevOps” is to shorten the feedback loop in your development cycles.  By reducing the amount of time for those feedback loops, your teams can iterate more quickly on changes and ship those features to your customers sooner. This tenet ties in directly with Agile methodologies utilized by software engineering teams. With the advent of easily accessible cloud infrastructure, and with the various operational tooling around those new infrastructure providers reaching a new level of maturity, we are now seeing a world where “DevOps” is mainstream.  For companies starting new product development initiatives, using some form of Configuration Management is now table stakes to iterate quickly. Additionally, we see more and more companies shed their physical data center presence in order to leverage the flexibility and accessibility of public compute resources provided by companies like Amazon, Microsoft and Google.  

The inherent nature of these IaaS providers is to make it as easy as possible to provision systems to meet your infrastructure needs -- and to do so very quickly.  Speed to market is a major competitive advantage that many companies are leveraging through the concept of Infrastructure as Code.  Provisioning hundreds or thousands of compute instances in mere minutes is now considered an everyday activity.  Everyone wants to move fast.  

Continuous Integration. Continuous Deployment.  But who (or what) is continually monitoring the state of your operational security?

We now have a world where your junior system administrator is able to make a small change to a Chef Recipe, Puppet Manifest, or maybe an Ansible Playbook, and deploy it to production within minutes.  But what is the scope of that change?  System Administrators don’t want to be slowed down by the security team.  They don’t want their configuration management changes to be passed through a Change Control Board.  They want to change a variable, open a pull request, and once merged, they want their operational tooling to do the rest.  They want their change to hit production servers as soon as possible.  

Screen Shot 2014-07-16 at 2.19.35 PM.png

This is where SecDevOps, or SecOps, comes into play. (Let’s ignore the fact that it’s just as silly of a buzzword as “DevOps”). If DevOps seeks to value empathy between teams that traditionally had different incentives for their positions (Devs valuing constant change, Ops valuing stability), SecDevOps seeks to evoke the same outcome with your Security teams and the rest of the business.  

When you are in a world where you are continually deploying change, you need to move towards a world where you are continually monitoring the security implications for those operational changes.  Often times, there is no single person at your company that is able to say with absolute certainty which changes to your infrastructure have additional risks towards your security posture.  And if you have a traditional network security organization that is manually reviewing and approving changes to production, you’ve now introduced the newest bottleneck in your organization.  

It’s this conversation that excites me the most about joining Threat Stack.  As a technical operations veteran of the last 15 years, this is the most important (and exciting) problem to solve in many organizations.  Having the opportunity to help build a product that will enable companies to continue to break down operational silos while improving the speed in which they are able to track and respond to security incidents is an absolute dream job for me.

I see SecDevOps as the qualifier for this discussion.  How do you improve your security monitoring and response times, while maintaining your ability to continually deploy changes? These are hard problems to solve, and we are all excited to be in this unique position where can actively help companies solve this problem.  

Stay tuned next Wednesday for our third installment in this series as we dive deeper into the technical integrations that make SecDevOps happen. And in case you missed it, you can check out our inaugural post here.

About Pete

Pete Cheslock is the Senior Director of Operations and Support at Threat Stack.  Previously, he was the head of automation and release engineering at Dyn, managing and deploying to mission critical global DNS infrastructure.  Prior to Dyn, Pete was the Director of Technical Operations for Amazon-Backed cloud archiving company Sonian. You can follow Pete at @petecheslock on Twitter.

 

 

 

Why SecDevOps Will Save The Cloud

This is the first part of a new series of weekly posts that will dive into the role of SecDevOps. This series looks into why we need it in our lives, how we may go about implementing this methodology, and real life stories of how SecDevOps can save the Cloud.

The world has changed. I feel it in the water, I feel it in the Earth. I feel it in the packet loss. This is the age of “the Cloud”. We were not without our skeptics, but we knew what was happening. A revolution was on our doorstep, and we wanted it all. We wanted it yesterday.

Configuration management, automation, orchestration, continuous integration and delivery. New concepts were born, titles were given, and philosophies of win floated around the web like confetti after a New Years Eve celebration. We weren’t sure where we were going, but we knew where we didn’t want to be: Configuration drift, tedious provisioning of systems, lack of acceptance and unit tests. Our fears were real, and we sought answers.

DevOps is born. “This is the solution we’ve been searching for,” we proclaimed! As if millions of voices suddenly cried out in terror, and were suddenly silenced… The end is far from nigh. In fact, it has only just begun.

Screen Shot 2014-07-09 at 8.29.56 AM.png

“What is a DevOp?” you may ask. We’ve all heard the jargon, the marketing pitches, but what is it really? The answer, at its core, is quite simple. “DevOps” is not a team, nor is it an organizational role. “DevOps” is a philosophy of collaboration.

“In the long history of humankind (and animal kind, too) those who learned to collaborate and improvise most effectively have prevailed." Charles Darwin

For years we sectioned off teams. Developers to the left, Operations to the right. Security teams... where did they hide? Who knows, really? (Reports have been made of Security Engineers haunting the halls of office buildings, lamenting about zero-day exploits and security patch upgrades.) Applications and services were developed and passed over the wall to the Operations team where they did what they could to piece things together and create a working environment. It was how we “got shit done.” Yet, something had always been missing. Where was the bottleneck? How do we optimize our development and deployment pipelines? Things need to be faster! Mush! Mush! Fellow Engineers!

DevOps unite: Infrastructure as code took the community by storm. Various Configuration Management solutions started making themselves available, code was written, and progress was made. But something was still missing -- something of incredible value. With all of these new tools at our disposal, teams began pushing out code changes faster than ever before, but something was astray.

Security! Where have you been, where have you gone? Were we foolish enough to believe that these progressive methodologies would save us from something so integral to our success? Why have we forsaken you?

Screen Shot 2014-07-09 at 8.31.25 AM.png

The cloud has left us questioning our surroundings. Who has access, what are the controls, what services are publicly available and which are safely kept behind “locked” doors? What is our risk, and how efficiently was it assessed? If you have yet to ask yourself these questions, it will only be a matter of time before you are one of the Lost.

Suddenly, a new methodology appeared in the distance… SecDevOps. What is it? Where did it come from? Is this just another silly marketing initiative? No, this is natural progression. The move to the Cloud leaves many of us with questions, and the most important one of them being: Without complete ownership of our systems and their supporting environments, how do we protect ourselves?

SecDevOps, or SecOps, is a natural extension of DevOps. The rate of change we see today leaves very little room for Security teams to properly assess risk in our application and infrastructure code. While the mission of our Security colleagues has never been to slow down the process, without bringing them into the fold, we will continue to be at risk of ever-looming threats.

By integrating our Security tool-chains into our DevOps pipeline, we can effectively mitigate our risks and continue our journey towards a secure, automated infrastructure.

In next Wednesday's follow up post, we will start to explore some of the basic principles of the SecDevOps methodology and how it can be operationalized for fun and profit. Over the course of the series, we will hear from a few notable guests on their experiences, and get their take on the SecDevOps movement and why we need it.

Threat Stack Introducing SecDevOps at AWS Summit New York

Next Thursday, we will be at the AWS Summit 2014 in New York meeting with AWS users from across the country -- many of which are our own customers -- as well as leading the discussion around the intersection of Security, Development and Operations and what that means for continuous monitoring in EC2.

As EC2 users increasingly look to incorporate security into their DevOps deployment practices, Threat Stack’s continuous monitoring plays a critical role in protecting cloud deployments. By integrating security best practices and DevOps activities, we’ve come to a new methodology: SecDevOps. A natural extension of DevOps, it will improve the security of entire EC2 environments. We’re looking forward to sharing our best practices at this summer’s AWS Summit in New York.

Going to the summit? Simply email us your availability for July 10th and we’ll schedule a dedicated time with you to discuss best practices for securing your Linux environment with SecDevOps.

Threat Stack + AWS

awspartner.png
 

After speaking with AWS customers across the country, it’s clear that businesses using AWS not only want but need technologies like Threat Stack’s Cloud Sight that are built specifically for the cloud in order to fulfill their portion of the shared responsibility security model. It’s business-critical today to have solutions that solve multiple needs, providing visibility across an entire cloud environment. Heterogeneous cloud solutions like Cloud Sight allow companies working in or moving to the cloud to do so with confidence. We’ll show you how at the Summit.  

Email us your availability to schedule a meeting with our team.

Event Details

AWS Summit 2014: New York

When: July 10 from 11:00am to 7:00pm

Where: Booth #331 at the Javits Convention Center, 655 W 34th St, New York, NY

What: Talk with our founding team and see demonstrations of our cloud security monitoring platform, Cloud Sight.

At Booth #331, you’ll learn how Cloud Sight:

  • Is a security solution built for the needs of both Operations and Security

  • Provides intrusion detection, purpose built for EC2

  • Eliminates the need for multiple point tools

Book your meeting with us now -- space is limited!

 

Behavioral Threat Monitoring Without Models

One of the great things about the cloud is the ability for companies to grow and shrink their infrastructure elastically to meet varying levels of demand. What many people don’t think about is how to secure this sprawl of cloud compute instances. As new systems are deployed, how do you enforce a policy on them? How do you look for anomalous behavior when an instance hasn’t been up long enough to determine a baseline?

Cloud Sight has solved this problem from day 1 with our policy framework. Our policies encompass all attributes of an instance’s security posture: alert rules, file integrity rules, firewall rules, so many rules! But also, each policy has a unique, learned behavior model associated with it. For example, an Apache web server process doesn't usually fork /bin/sh. When our agent is activated, the instance’s baseline is already established from its peers which enables us to immediately start watching for anomalies.

Since we automate a lot of our own infrastructure (as do many of our customers) we realized it’d be useful to put an agent into a policy (and subsequently activate it) when the agent is deployed. So we got to work and a sprint or two later, we hammered it out.

See how it works below:

deployagentwithpolicy.jpg

Choosing a policy will append the policy argument to the deployment key at the end of the URL, and you’re off to the races.

To begin selecting your own policy, login now. Have a question? Send us an email

Introducing the Cloud Sight API

We're excited to introduce the initial release of the Cloud Sight API. When we first launched Cloud Sight, we started by solving the problem of heterogeneous cloud security monitoring. At the same time, we baked the API into the core of our product to deliver the most flexible cloud security solution available.

The Cloud Sight API provides a read-only RESTful interface into our backend, allowing you to query a variety of data. This data includes: agents, alerts, policies, organizations, and audit logs.

The API enables a number of different use cases. For instance, let's say you want to pull a list of alerts and integrate them with a SIEM. Or perhaps you need to export the audit logs to Splunk. Want to grab a list of agents and compare with the AWS instances you've got running? No problem.  With the API, we make integrating with external applications as simple as possible.  

Getting Started

You can access all you need to get up and running with the API by navigating to the Configuration panel, and clicking on "API Settings" at the top. 

We’re excited for you to try out the Cloud Sight API and can’t wait for your feedback as we continue to enhance it. Login to get started today or sign up for our beta to try it out!

Below are a few examples to get you started:

(Note: Be sure to replace API_KEY with your real API key from the "API Settings" page!)

First something simple. Let's show the number of alerts:

aaron@mbook:~$ curl -sH "Authorization: API_KEY"  https://cloudsight.threatstack.com/api/v1/alerts | jq 'length'
6

Now let's list the alert IDs themselves:

aaron@mbook:~$ curl -sH "Authorization: API_KEY"  https://cloudsight.threatstack.com/api/v1/alerts | jq '.[] | .id'
"537e59cadc95f40f1b0034cc"
"534d845eff07df8f6b004799"
"53448b4aff07df8f6b002ab3"
"533dccdfff07df8f6b001625"
"533dccdfff07df8f6b001622"
"533dccdfff07df8f6b001623"

This shows the detail of a specific alert, complete with the events that triggered it:

aaron@mbook:~$ curl -sH "Authorization: API_KEY"  https://cloudsight.threatstack.com/api/v1/alerts/537e59cadc95f40f1b0034cc | jq '.'
{
  "rule_id": "52ab6e553ff95a68050001ad",
  "dismissed": false,
  "type": "rule",
  "title": "Process Network Activity: /bin/nc.openbsd ran by root",
  "count": 9,
  "key": "52ab6e553ff95a68050001ad-531f6b9115b4f7a16e000012-2f495034f551e8c990f860f1b60e1b621bedb293fa60bf8d4f96b844c947ac07",
  "last_updated_at": "2014-05-22T20:12:00.342Z",
  "expires_at": 716508583,
  "created_at": 630108583,
  "active": true,
  "unread": true,
  "severity": 2,
  "id": "537e59cadc95f40f1b0034cc",
  "latest_events": [
    {
      "args": [],
      "user": "root",
      "group": "root",
      "path": [],
      "exe": "/bin/nc.openbsd",
      "timestamp": 630179667,
      "type": "connect",
      "syscall": "connect",
      "command": "nc",
      "ppid": 11807,
      "connection": {
        "addr": "74.125.226.212",
        "port": 80,
        "version": 4,
        "domain": "lga15s28-in-f20.1e100.net"
      },
      "_insert_time": 1400789518,
      "agent_id": "531f6b9115b4f7a16e000012",
      "organization_id": "52ab6e553ff95a68050001ab",
      "_type": "audit",
      "_id": "5450d856-e1ed-11e3-8caf-4f7b50a3a8f4",
      "event_type": "audit",
      "pid": 11856,
      "tty": "pts2",
      "session": 10,
      "exit": 0,
      "egid": 0,
      "gid": 0,
      "euid": 0,
      "uid": 0
    },
    {
      "args": [],
      "user": "root",
      "group": "root",
      "path": [],
      "exe": "/bin/nc.openbsd",
      "timestamp": 630179667,
      "type": "connect",
      "syscall": "connect",
      "command": "nc",
      "ppid": 11807,
      "connection": {
        "addr": "74.125.226.209",
        "port": 80,
        "version": 4,
        "domain": "lga15s28-in-f17.1e100.net"
      },
      "_insert_time": 1400789518,
      "agent_id": "531f6b9115b4f7a16e000012",
      "organization_id": "52ab6e553ff95a68050001ab",
      "_type": "audit",
      "_id": "5450d855-e1ed-11e3-8caf-4f7b50a3a8f4",
      "event_type": "audit",
      "pid": 11856,
      "tty": "pts2",
      "session": 10,
      "exit": 0,
      "egid": 0,
      "gid": 0,
      "euid": 0,
      "uid": 0
    },
    {
      "args": [],
      "user": "root",
      "group": "root",
      "path": [],
      "exe": "/bin/nc.openbsd",
      "timestamp": 630179667,
      "type": "connect",
      "syscall": "connect",
      "command": "nc",
      "ppid": 11807,
      "connection": {
        "addr": "74.125.226.211",
        "port": 80,
        "version": 4,
        "domain": "lga15s28-in-f19.1e100.net"
      },
      "_insert_time": 1400789518,
      "agent_id": "531f6b9115b4f7a16e000012",
      "organization_id": "52ab6e553ff95a68050001ab",
      "_type": "audit",
      "_id": "5450d854-e1ed-11e3-8caf-4f7b50a3a8f4",
      "event_type": "audit",
      "pid": 11856,
      "tty": "pts2",
      "session": 10,
      "exit": 0,
      "egid": 0,
      "gid": 0,
      "euid": 0,
      "uid": 0
    },
    {
      "args": [],
      "user": "root",
      "group": "root",
      "path": [],
      "exe": "/bin/nc.openbsd",
      "timestamp": 630179667,
      "type": "connect",
      "syscall": "connect",
      "command": "nc",
      "ppid": 11807,
      "connection": {
        "addr": "74.125.226.210",
        "port": 80,
        "version": 4,
        "domain": "lga15s28-in-f18.1e100.net"
      },
      "_insert_time": 1400789518,
      "agent_id": "531f6b9115b4f7a16e000012",
      "organization_id": "52ab6e553ff95a68050001ab",
      "_type": "audit",
      "_id": "5450d853-e1ed-11e3-8caf-4f7b50a3a8f4",
      "event_type": "audit",
      "pid": 11856,
      "tty": "pts2",
      "session": 10,
      "exit": 0,
      "egid": 0,
      "gid": 0,
      "euid": 0,
      "uid": 0
    }
  ],
  "rule": {
    "id": "52ab6e553ff95a68050001ad",
    "type": "audit",
    "exclusions": [
      "exe = \"/usr/sbin/sshd\" and user = \"root\"",
      "exe = \"/usr/libexec/postfix/pickup\" and user = \"root\"",
      "exe = \"/usr/lib/postfix/smtpd\" and user = \"postfix\"",
      "exe = \"/usr/lib/dovecot/imap-login\" and user = \"dovenull\"",
      "exe = \"/usr/bin/python\" and user = \"root\""
    ],
    "aggregate_fields": [
      "exe",
      "user"
    ],
    "threshold": 1,
    "window_seconds": 86400,
    "anomalous_only": false,
    "description": "Network Activity was observed by a process on this machine. We recommend you review the history of network activity for this process, and make sure it is valid for this machine. Unexpected network activity from a process can be an early indicator of compromise.",
    "filter": "connection.addr != null and connection.addr != \"127.0.0.1\"",
    "title": "Process Network Activity: {{exe}} ran by {{user}}",
    "auto_suppress": true,
    "created_at": "2013-12-13T20:30:13.000Z",
    "updated_at": "2013-12-13T20:30:13.000Z",
    "enabled": true,
    "severity": 2
  },
  "alert_policy_id": "52ab6e553ff95a68050001ac",
  "agent_id": "531f6b9115b4f7a16e000012"
}