Tag: Andrew Storms

  • It’s time security pros shake their DevOps fear, uncertainly, and doubt

    It’s time security pros shake their DevOps fear, uncertainly, and doubt

    There’s been considerable discussion recently about how to make certain good security practices remain integrated within DevOps-driven environments. To get the scoop from a security pro who is experienced working on delivering security programs in development environments, I turned to Andrew Storms for some insight. Storms has been leading IT, security and compliance teams for the past 20 years and his multidisciplinary background includes product management, quality assurance, and software engineering.

    Storms is also a CISSP, a member of Infragard, and a graduate of the FBI Citizens’ Academy. Currently, Storms is vice president of security services at New Context. Previously, he was the senior director of DevOps for CloudPassage and the director of security operations for nCircle (acquired by Tripwire). At nCircle, he was responsible for the definition and enforcement of the security programs, delivering EAL3 certification and SOC2 audits, and managed the company’s PCI ASV program.

    Storms recently gave a talk at the RSA Conference, How Security Can Be the Next Force Multiplier in DevOps, where he shared his thoughts on how security teams should integrate themselves as business enablers within fast-paced DevOps enterprises.

     

    devopsy.kinsta.cloud: What’s your take on DevOps being a force multiplier and enhancing security?

    Storms: Much of it [the concern around DevOps] really is rooted in fear. People see that the organization has brought together the developer and the operations team and they fear that everything will become the Wild West. However, we’ve shown over and over through the years that bringing these teams together actually has huge positive impact.

    Unfortunately, too many people in security view it differently. They think that they’ve lost control of a situation that they barely had control over to begin with.

     

    devopsy.kinsta.cloud: What are the best approaches for integrating security with DevOps?

    Storms: There are two approaches to this. One of the best ways to bring DevOps and security together is to utilize the tools and the processes that DevOps really excels at and apply them to security – things like automation, orchestration, and instrumentation. Let’s use those tools to build these closed-loop security systems where everything’s automated and everything’s predictable. That’s a way we actually can fulfill the security requirements in an automated fashion with fewer resources.

    Another is to treat security more as an enabler. Security has fallen into the pitfall that, instead of being an enabler to the organization, it is all about ‘No.’ There’s pushback on new initiatives for fear of falling out of regulatory compliance, or being breached. Instead, the organization needs to take a different approach. It should view security as a business enabler, just like IT and operations.

    In this way, it can secure new initiatives and actually enable people to focus on their core competencies and allow the company to take educated risks. At the end of the day, that helps to provide more of what the business needs to do, whether that is increase revenue or decrease time to market, or whatever it may be that the company needs.

     

    devopsy.kinsta.cloud: Done right, people say that security needs to be integrated throughout all of the processes, but that’s seldom reality. What do you say to security teams about this?

    Storms: That’s the approach that I take here with the integration of DevOps and security. Really, if we think about it, the integration of Dev and Ops together in DevOps has actually opened the door for security to come in and do something very similar – to come in and work more collaboratively and integrate itself more closely with the rest of IT.

    What security professionals need to recognize here, but often don’t, is that DevOps is an opening. Take it. That is to say: Don’t fear DevOps; embrace it. Address the fear, and then learn about DevOps, and see where you can integrate security people, processes, and technology.

     

    devopsy.kinsta.cloud: When integrating the people, processes, and technologies that help forward security interests in DevOps, I imagine it takes time and effort to go back and review a lot of those controls, to make sure that they’re up to speed with the way people actually work today.

    Storms: I think that’s one aspect. I think the other aspect is, if we look at the manifest of Agile, which is the ability to take and see change and adapt, all of those controls, to some degree, still make sense. They just need to be adapted to the modern way that code is developed.

    One of the great examples I like to share is a health care company I worked with. It is deep into continuous deployment but has all kinds of compliance requirements. So, it can’t just centrally deploy code at any time it wants without all the compliance check-offs that have to happen.

    It has to run application security and compliance checks. So, it automated them, to the point where the auditors are happy. When their code gets pulled in to master, it runs it through many types of integration and security tests.

     

    devopsy.kinsta.cloud: What happens if there is an issue; how is it resolved?

    Storms: The company has put in automated checks. Think of it as kind of a speed bump; for example, when an event happens, there’s a message that is sent to the chat room [See: ChatOps, Communicating at the Speed of DevOps], and there’s a Hubot that watches the messages. The Hubot has logic that says, right before they’re ready to go, you need to stop and alert the chat room that this event needs to happen, and it needs N number of people to approve it.

    For example, it may require that there be a product manager, there must be a security manager, there must be an ops manager, and so on. And they’ve got logic in there that says if the right number of people in the chat room all respond with a keyword – let’s just call it “yes” – then let’s actually capture all of that, enter a log message to go ahead and approve the release, and push it out automatically.

    If an issue is found in the tests or in the approval processes, then it has to be resolved, and is then moved forward along the pipeline.

    With this continuous pipeline, the company actually has all of the steps, all the compliance requirements, and the audit log. Thus, it still can maintain compliance requirements, and security. That’s what DevOps and security should be all about.

  • SecDevOps: the new black of IT

    SecDevOps: the new black of IT

    Much has been written about the role of Security in a DevOps culture. Almost universally the thought is that DevOps can help improve security.

    Why?

    How?

    Really?

    An old friend of mine from the security world Andrew Storms and I will discuss this and other issues around DevOps and security on June 11th at 1pm eastern time, 10am pacific time on a webinar entitled “SecDevOps: the new black of IT“.

    Andrew is the Sr. Director of DevOps at CloudPassage. Prior to that Andrew headed up the security research team at nCircle. He is oft cited in the security press and highly respected.  Andrew and I ill discuss how just when DevOps is catching on, adding to security to the mix can make it even more powerful. How can security help DevOps to succeed? How can DevOps help us with better security?

    We will discuss what this means in terms of different kinds of security tools and services, the cloud and more.

    If you are interested in security and DevOps register now and  tune in to the webinar next Tuesday

  • Using AWS CloudWatch for Anomaly Detection

    Using AWS CloudWatch for Anomaly Detection

    Based on my unscientific poll of friends, one of the least used and most overlooked features of AWS is CloudWatch.  Not only can CloudWatch be used to monitor the availability of your AWS services, but it can also be used as anomaly an detection tool. Did I mention that these feature are free?

    Since the holy grail of DevOps is to bring  the security and the operations teams together to meet the same goals in an automated fashion; Cloud Watch is a perfect DevOps tool. In fact, once it’s implemented for your environment  you are one step closer to the exalted state of SecDevOps.

    If you aren’t familiar with AWS CloudWatch then head on over to https://aws.amazon.com/cloudwatch/. As a quick introduction, here’s how AWS website describes the service:

    “Amazon CloudWatch provides monitoring for AWS cloud resources and the applications customers run on AWS. Developers and system administrators can use it to collect and track metrics, gain insight, and react immediately to keep their applications and businesses running smoothly. Amazon CloudWatch monitors AWS resources such as Amazon EC2 and Amazon RDS DB instances, and can also monitor custom metrics generated by a customer’s applications and services. With Amazon CloudWatch, you gain system-wide visibility into resource utilization, application performance, and operational health.”

    Let’s assume that both security and Ops teams need to be aware when weird things are happening with their servers and applications.  Events outside the norm (aka weird things) can be either be related to security or operational events; either way they may merit investigation. Here’s a simple CloudWatch  monitoring process you can use  to give you a heads up on events that could indicate someone is trying to exfiltrate data from your systems.

    Opening Scene

    Think about what kind of information attackers are after.  They want your intellectual property and your customer data because it can be converted to cold, hard cash.  Next, consider the architecture of your systems and where that data is stored. Most likely your treasures are stored in databases or Git repositories.

    Guess what? Attackers know that so that’s exactly what they are looking for.  Take a few minutes and think like an attacker bent on exfiltrating your data.  Obviously, the first thing you should do is carefully monitor your egress traffic for suspicious activity.  In addition, look for anomalies in traffic flows – they can also help determine if suspicious events are happening.  Amazon CloudWatch can help you do  both of these things.(Note: This process assumes you haven’t already been breached.)

     1. Enable CloudWatch

    2. Establish a baseline

    Review the historical data on a daily, weekly and monthly basis.  Soon you will start to see a trend in your egress bandwidth usage.  Start with eyeballing the min, max and average usage over time.  Put these in your favorite tracking tool (text file, spreadsheet, abacus, whatever).

    3. Configure alerts

    When you feel comfortable with your baseline, configure your first alert to send an email if traffic usage goes over the baseline.  Consider how “chatty” you want this event to be.  For example, alerting over the average baseline will often generate more alerts than alerts over maximum usage.  This is a tricky balance and you’ll need to make trade offs between missing problems and the time spent responding to potential false positives.

    4. Respond

    However you choose to respond is up to you.  I suggest you start with automatically opening a ticket in your tracking system so that someone will be sure to review the alert and make notes on their findings.

    5. Tune as needed

    Make a plan to review the alerts and the data on a regular basis.  Architecture and other changes to the system are going to change the baseline and the alerts may need to be reconfigured.

    Building and automating security into DevOps is a requirement that everyone should be working toward. It’s a theme I’m going to be returning to in future posts because it’s really important.

    AWS Cloudwatch is a free tool that you can help you get started automating security right now, so what are you waiting for?