Tag: secops

  • Flash Mob Inflection: Rugged DevOps Revolution

    Flash Mob Inflection: Rugged DevOps Revolution

    Truthfully, I was never a huge fan of the HBO series “The Sopranos.” It’s not that it wasn’t entertaining; I just didn’t agree with the “best ever” label that so many espoused during the show’s halcyon days.

    This had something to do with living in Hoboken, N.J., at the time and feeling the show was a heavily glamorized caricature of the real-life Mafioso I still perceived to be in my midst. More specifically, it’s hard for anything mob-related to stand up next to “Goodfellas” and “The Godfather”—among my favorite films, ever.

    Either way, I currently find myself identifying with the series’ defining sentiment (copped directly from The Godfather, but hammered home as The Sopranos main theme): “Just when I thought I was out … they pull me back in.”

    It wasn’t that I assumed that I’d never delve back into the domain of IT security after transitioning into the DevOps market last year; leveraging DevOps methodologies to improve security, policy compliance and related workflows stands as a core element of the overall movement.

    But, in recent months and weeks it has become increasingly obvious that the security facet of the larger DevOps revolution appears poised for explosion as the buzz around emerging best practices, business models and solutions providers grows from a low hum into a steady roar.

    After spending a few days talking DevOps security with Derek Weeks of Sonatype at CA World ’15 (we were booth neighbors and dinner mates) and giving more consideration to his company’s angle on securing the systems development life cycle (SDLC) supply chain, the internal gears really got spinning.

    Regardless of whether you buy into Sonatype’s security-heavy approach, the concept of aggressively and proactively addressing security across the DevOps spectrum makes infinite sense. The ultimate downfall of applications security has always been the challenge of securing all the underlying layers of code (and today, microservices), especially as applications are assembled using heavier doses of shared, open source componentry.

    As further evidence, nearly every major solutions vendor focused on the DevOps space—whether oriented toward the vibrant application performance management (APM), configuration management and continuous testing segments, among many others—seems to have launched some initiative aimed at integrating security into their products.

    The rise of security capabilities adjacent to—and supporting inclusion into—the DevOps world, such as container giant Docker’s Content Trust initiative, along with the advancement of related startups including Twistlock, Scalock and StackRoxs, offers more proof of this growing momentum. And that’s only the container security piece of the puzzle.

    Of course, there are also a number of emerging startups aimed at addressing the DevOps security opportunity, backed by well-known venture capitalists. A shortlist might include providers such as Immunio, Prevoty and UpGuard (formerly known as ScriptRock, which recently rebranded itself under the guise of a “DevOps security” provider), and we’re sure to see many more. And don’t forget the growing emphasis on DevOps security among established security industry stalwarts such as CyberArk, Snort and Tripwire, among others.

    For a comprehensive list of the various types of DevOps security best practices and tools that we should expect to see gain wider adoption, this October 2015 blog by noted security analyst Adrian Lane of Securosis serves as a basic framework. Each of the areas of focus that he cites clearly offers significant opportunity for both new and existing methodologies.

    Finally, one need look no further than this year’s RSA Security Conference, to be held in San Francisco at this end of this month, as tacit proof of the continued growth of what people now varyingly refer to as DevSecOps or Rugged DevOps (I prefer the latter as it just sounds cooler).

    In addition to multiple conference sessions, notably a “DevOps Throwdown” between security industry veterans Caleb Sima, Chris Wysopal and Gary McGraw, there’s also the 2nd Annual DevOps Connect: Rugged DevOps Edition. If last year’s event is any indication (standing room only, venue literally at max capacity), this daylong DevOps security track at RSA will be an even more high-profile element of the entire week.

    Further, if DevOps security—or, at the very least, the growing focus on adjacent segments such as container security—isn’t the unofficial theme of this year’s entire RSA show, I’d be extremely surprised.

    Meanwhile (self-serving), my employer CA Technologies absolutely has a lot going on that complements and contributes to this growing DevOps Security market momentum.

    For all of those reasons, here I find myself again, drawn closer back into the security space that I’ve called home for roughly the last decade. I guess that’s just how it goes, as DevOps and security are inarguably two of the most significant trends in IT these days and inextricably linked at their respective cores.

    There are definitely worse fates out there. But, just when you think you’re out …

  • Combining SecOps and DevOps

    Combining SecOps and DevOps

    Security has to be top of mind for most any company that is moving, or has moved, to the cloud. And, businesses know they need to act swiftly to ensure that any new products or services they’re dreaming up do not expose them to risk.

    How can they do that when the fast-moving nature of the cloud is leaving proper security practices in the dust? The problem today is that today’s security solutions are proprietary, too slow and take too many resources.

    Bottom line, the security model that has served most businesses well was never built for speed, and is simply unsustainable for opportunities in today’s cloud-centric world. Today, security solutions must be agile, lightweight, loosely coupled and extensible.

    On the front lines at various companies you’ll see a new type of cooperation –  where two teams most directly involved in a potential solution, development and security – are breaking down the traditional (and often opposing) silos and collaborating more openly to drive secure innovation from the start.

    We’re seeing a new “marriage” of SecOps and DevOps that creates a whole new mentality for driving innovation inside and outside of organizations. This new mentality allows security and DevOps to find common ground to make it easier for organizations to align their security goals with the delivery of their products at today’s rapid speed of business.

    While businesses are changing internal structures to address cloud security, there are also a number of new solutions that can be deployed against a company’s clouds and deliver security intelligence back to the DevOps teams.

    These kinds of tools are especially important for start-ups and SMBs that face unique challenges securing their businesses from cyber attacks and preventing data breaches.

    By encouraging greater collaboration between security and DevOps, and relying on outside solutions to assess and identify potential threats as new products and services are developed, businesses of all sizes can feel a higher level of confidence that they’re addressing security concerns by enforcing industry-leading security practices every step of the way.

    About the Author:/Tim Prendergast

    tim p Tim Prendergast co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level. After years of building, operating, and securing services in AWS, he set out to make security approachable and repeatable for companies of all sizes. Tim led technology teams at Adobe, Ingenuity, Ticketmaster, and McAfee.

  • Security and DevOps: the horses are finally here

    Security and DevOps: the horses are finally here

    It doesn’t seem like it was so long ago when it was actually difficult to find enterprises and experts who could speak – from experience – about having successfully managed security in a DevOps environment. Sure, they existed, but they were primarily the so-called “unicorns:” web-based enterprises that had little of the legacy infrastructure in place that also needed to be secured. Enterprises such as Netflix, Etsy, Google, Amazon, and others for who the cloud and virtualization management and DevOps practices are as natural as water.

    Fortunately, we’ve now experienced a year where stories about traditional enterprises having successfully made the DevOps leap are commonplace, from Macy’s and Target and others at the DevOps Enterprise Summit, while Nationwide and many others at IBM InterConnect.

    Like those conferences above, this year the annual RSA Conference (the information security industry’s biggest show), and some of the approximate satellite events this week, will have many sessions relating to DevOps and security. Our own DevOps Connect: SecOps Edition, being held Monday at the Moscone Center, is a daylong event highlighting the intersection of DevOps and information security.

    At DevOps Connect: SecOps Edition there are a number of must see sessions, for me, including David Mortman’s DevOps Myths Versus Real World Realities, Julie Tsai’s Windfall Wins: DevOps Empowers Agile Security and Compliance, and Jez Humble on Continuous Delivery.

    Also, throughout the week there are many DevOps and security sessions throughout the week in application security related tracks. There will be a lot of interesting news and developments coming from those sessions throughout the week.

    Here are some, for those interested in learning more about DevOps and security, that look very worthwhile:

    Continuous Security: 5 Ways DevOps Improves Security

    Joshua Corman, Chief Technical Officer, Sonatype and David Mortman, Chief Security Architect, Dell

    DevOps is upon you and no longer just the provenance of start-ups. Josh and David will discuss how things have changed and five ways security gets better as a result of other teams doing DevOps.

    Enterprise Cloud Security via DevSecOps

    Scott Kennedy, Chief Security Scientist, Intuit; Shannon Lietz, Sr. Manager, DevSecOps, Intuit

    Securing innovation at scale in a cloud environment can be quite challenging. The goal of our talk is to share the lessons we learned about operating under the DevSecOps model.

    How to Avoid the Top 10 Software Security Flaws

    Gary McGraw, Chief Technical Officer, Cigital

    DevOps and automation tools are changing both the breadth and speed at which risk propagates. This session will cover both how to monitor and respond to them without alienating your DevOps team.

     Is DevOps Breaking Your Company?

    Elizabeth Lawler, Chief Executive Officer / Founder, Conjur, Inc.

    DevOps and automation tools are changing both the breadth and speed at which risk propagates. This session will cover both how to monitor and respond to them without alienating your DevOps team.

      Containers vs. VMs for Secure Cloud Applications

    App developers and PaaS platforms are adopting containers to simplify app packaging, deployment and orchestration. But there has been no pause for thought about security and compliance.

    Participants:

    Simon Crosby – Chief Technical Officer, Bromium Inc

    Christofer Hoff – Vice President and Security Chief Technology Officer, Juniper Networks

    Mark Russinovich – Chief Technology Officer, Azure, Microsoft

    Scott Johnston – Senior Vice President Product, Docker

    How Security Can Be the Next Force Multiplier in DevOps

    Andrew Storms Vice President, Security Services, New Context

    DevOps is the hottest moving target when it comes to software development methodologies. Many people fear that this fast paced, barrier breaking movement will leave information security best practices.

    After the week is over, a great deal more security professionals in the industry should have a stronger grip on how to better incorporate security into DevOps practices and improve enterprise IT outcomes while reducing risk.

  • DevOps Security Talks At RSA USA 2015 Conference

    DevOps Security Talks At RSA USA 2015 Conference

    DevOps and security. Its a muddled mix of waters made even more confusing by the wet ink still on the concept of DevOps. There is no denying the popularity of DevOps and there is a lot of talk on how the DevOps movement functions alongside security teams.

    The annual USA RSA conference is just around the corner and its worth noting a handful of DevOps focused talks deserving of your attention.

    I am anticipating a lot of common themes around integrating DevOps and Security regarding tools, processes and culture. Given the history of these speakers, you can probably anticipate many of them to be on the bandwagon of security and DevOps folks better learn to work together and learn from each other or be prepared to find a new job.

    If I missed a talk that specifically covers the nexus of DevOps and Security at RSA USA this year, please leave a comment and I’ll be sure to get it included.

     

  • Security Should Be the Top Driver for DevOps

    Security Should Be the Top Driver for DevOps

    I’ve often said that the driving factor for many companies in adopting a comprehensive information security program are the dreaded “F” and “A” words – FUD and Audit. Technically FUD is an acronym for fear, uncertainty and doubt. And it might be better said that audit is the action used to hopefully demonstrate compliance and trust.

    Just a few years ago, the predominant drivers for security spending were regulatory and compliance requirements. While compliance remains a driver today, the primary moving force for many is the concern of cybercrime. Fear of being the next Sony, Target, Chase or countless other victims is driving information security budgets to be readdressed.

    In a recent CA survey the top obstacle (28%) to DevOps in their organization were security or compliance concerns. Yet, in the same study, a huge percentage (88%) already have or plan to adopt DevOps in the next 5 years. The dichotomy of the situation has not escaped me. Organizations are in a situation where they are actively spending money on DevOps and information security, but at the same time view these two initiatives as counter.

    The answer is simple, information security teams need to adopt DevOps principles.

    While a widely agreed upon definition of DevOps is still up for grabs, its safe to say that DevOps is generally inclusive of a few core tools and principles. First, DevOps promotes a culture of cooperation and sharing among different groups in an organization. Second, DevOps promotes the use of heavy automation, decreasing time to market and agile development.

    Information security’s goals are the CIA triad – confidentiality, integrity and availability. Security teams argue that DevOps is the antithesis of good security. Constant change, open culture and automation smack directly in the face of security’s tactics of compartmentalization and tight process control.

    Here is a little secret – DevOps is winning, information security is losing.

    DevOps teams are deploying code faster and faster. They are reducing time to market and increasing revenue. Information security teams, well, lets just say that they continue to be in the news for the wrong reasons.

    The second little secret – the companies which are really winning are using DevOps tools and principles everywhere in their organization. Even in information security. Imagine overseeing infrastructure configurations with code that ensures compliance 24×7 across an entire organization. Or picture being able to instrument thousands of data points to benchmark security performance over time. Conceptualize being in charge of an automatic closed-loop security system which automatically takes action to mitigate attacks based on shared threat intelligence. These are possible with DevOps.

    For all that DevOps provides, security should not be a hinderance to DevOps adoption. Instead, security should be a top driver for adopting DevOps. Using DevOps to create the next generation information security program might just be your only hope in combating the next cyber threat.

  • Moving Security To the Left In a DevOps World

    Moving Security To the Left In a DevOps World

    Moving security to the left has become a coined phrase meant to describe the process of getting the security team involved earlier in a process.  Most typically, the phrase is used in conjunction with IT or software development projects. One of the top suggestions for ensuring security in a DevOps world is to move security to the left in the process tool chain. But what exactly or how exactly can you move security to the left?

    Grab that Open Seat

    The new DevOps process pipeline created an opening for a seat at the table for security. Prior to DevOps, the development team owned the entire pipeline from plan to release.  The Ops team would historically receive the release from over the wall and then be responsible for the deployment and operating the software inside the production environment.  With the Ops team joining forces with Development in the process pipeline, that has opened a proverbial seat at the table. What I’ve started to witness are security teams taking advantage of the musical chairs to quickly grab the open spot.

    DevOpsProcessPipeline

     

    Taking a seat at the end of the development pipeline is not enough.  Too many security teams are still being relegated to positions too late in the process.  While running pen tests and security code reviews after a release is better then nothing, its still not ideal.  Security needs to find ways to add value to the process so they can act as a force for positive change instead of the after thought.

    Threat Vector Analysis

    Threat vector analysis is part science and part art and part trying to guess uncertainty. What is certain, however, is that most developers would rather be spending their time writing new functionality instead of trying to understand how an attacker could be break their code. The security team could offer a tremendous service to an organization by offering their expertise in this area.

    Continuous Integration Security Testing

    Continuous integration is a key component of DevOps. The security team can leverage the development chain to insert early yet important risk control tests. Those tests could be for example static or dynamic code analysis. Other tests could be simple yet known vulnerability checks in included libraries. The OWASP introduction to testing guide lists a plethora of application security tests that should be checked often and early.

    Author Micro Security Services

    Think about how great it would be if there was a group who specialized in authoring and delivering security related services into your application?  Proponents of services models generally promote splitting the development team up into groups that are organized around business capabilities.  For example, there are separate development groups for UI, middleware and DB.  What’s missing in most of those models is who is responsible for security services such as authentication, authorization and audit. Security has an opportunity just waiting for them to add incredible value while also ensuring the security services used pass muster.

    Summary

    Where we once had Ops fighting their way to be part of the entire development process, we now have security trying to do the same. Ops managed to garner their way into the club by coming to the table with invaluable skills and resources. Now its up to security to present their creative sweet spot in order to secure their own seat at the table.

    Further Reading

    Andi Mann on Ensuring security and managing risk in enterprise DevOps

  • Dev + Ops + ???

    Dev + Ops + ???

    If there’s one thing the DevOps cultural and professional movement taught us, it’s to question the status quo for the betterment of our customers, businesses, and ultimately, our teams. The combination of improved tooling, questioning structural barriers between teams, and a “shared outcome” culture have been powerful forces to date.

    Granted, we’ve seen the most demonstrated benefit in smaller organizations, but let’s face it… a big part of the movement is culture, and a set culture in a large organization is not easy to evolve. As we’ve mentioned before, you can’t sell DevOps. It will take time for large organizations to benefit from the movement.

    While we wait for the cultural evolution of large organizations to DevOps, it’s worthwhile to watch the continued professional and cultural evolutions of smaller organizations. The ones that first embraced DevOps from their start, what’s next for them?

    There are three ways I am currently exploring this question:

    • Dev + Ops + ???: Addition of a third functional pillar
    • DevOps evolution in parallel to Sales & Marketing evolution: Some interesting parallels
    • Org-wide evolution: DevOps cultural tenets deployed throughout the organization

    I would love to hear your observations as well.

    Dev + Ops + ???: As the title suggests, the most common finding thus far is another legacy functional silo having the structural, cultural and tooling barriers to collaboration torn down. These organizations have a solidly executing group of engineering and operator mindsets working closely together, and have actively embraced a third pillar of the organization. The most common I’ve found is the security team and the embrace of the term SecOps, though I’d love to find others. Do you fit this profile? Leave a comment below on your observations.

    DevOps evolution in parallel to Sales & Marketing evolution: In a small handful of organizations I’ve talked to, I’ve seen an interesting parallel evolution in the go-to-market teams to what was evolved in the technical teams.

    If DevOps tore down the fence where code was tossed over, and eliminated the “blame game” when things went wrong of “It’s not my servers, it’s your code” and “It’s not my code, it’s your servers”, there’s a remarkably similar parallel evolution happening in go-to-market teams… of course not about code, but instead about leads. To put it the most bluntly ableit controversially, there has been a long-standing tension between marketing, historically charged with generating leads for new customers, and sales, historically charged with engaging the leads and nurturing them into prospects and ultimately happy customers.

    Cue the blame game: “It’s not my leads, it’s your close” and “It’s not my close, it’s your leads”. Enabled by better tooling and visibility (e.g., customer relationship management software, marketing automation, etc.), progressive organizations are spending less time blaming each other, and more time collaborating on a shared outcome. Personally, I find the parallels between the evolution of technical teams and the evolution of go-to-market teams fascinating, and if you fit this profile, I’d love to hear your observations.

    Org-wide evolution: Our preceding two profiles are fundamentally about change from within; specific cultural, structural and tooling barriers being torn down between functions of an organization. We see examples of technology teams tearing down walls, and examples of go-to-market teams tearing down walls, but what about the many other key functions of an organization?

    Where’s finance? How about talent and human resources? Customer services and support? Product management? I would love to learn of more examples where cultural evolution is occuring not just in functional pockets of a comany, but across the entire organization at scale. If you fit this profile, I’d love to hear your observations.

  • Security in the operational relay race

    Security in the operational relay race

    If you’ve ever seen people run a relay race, you’ll notice that most of the risk happens when the baton is handed from one runner to the next.  In IT processes, there is also dramatically increased risk during handoffs.  Whether you’ve moving from one process phase to another, one “owner” to another, or one environment to another the risk is greatest during the phase transition.

    Security can play a strong role during these handoffs, whether you’re using DevOps or not.  Here are some principles that can help safeguard the handoffs and reduce the risk in the operational relay race.

    Reduce access

    They say too many cooks spoil the broth and that can apply to IT processes, as well.  Limit the number of people who can directly make changes in production and you have a shot at increasing security and defending availability by reducing random acts of deployment, as well as change collisions and mystery changes that just show up in production.  This is a key anchor for creating predictability and reducing change collisions.

    Create defensible “choke points”

    Reducing the number of ways things can be deployed into production will help you defend the integrity of the production environment.  This doesn’t necessarily mean preventing changes, it is more about controlling how changes enter the environment.  Focus on creating trustworthy repositories, deployment sources, automation tools, and service accounts that reduce the options for how deploys happen.  When you define clear swim lanes and you know what the expected path of deployment looks like, it is easier to detect unexpected activities and actions.

    Use choke points to enforce acceptance criteria to ensure that you are ready to take responsibility for the code, systems, and applications that being handed to you.

    This approach allows great freedom in how work gets done in autonomous teams, while enforcing more consistency through the release management and transition to Ops phases of the life cycle.

    Think like an air traffic controller

    When dealing with multiple streams of work that need to come together and interoperate in production, I think a mental model of an air traffic controller works well.  Airports allow a bunch of independent operators to come together in a shared environment in an orderly fashion, with minimal collisions and predictable throughput, and the air traffic controller plays a key role in making that happen.  In the IT context, this means leaning on people who have a broader perspective than any individual team so they can look at the big picture and coordinate activities holistically.

    This “zoomed out” perspective is critical in identifying risky activities and gaps, understanding dependencies that can break your security model, and stepping in to help mitigate dangerous conditions.  This approach also makes it easier to work with third-party providers, since you can focus on their results (outputs and handoffs) rather than getting caught up in the minutiae of their day-to-day activities.

    Monitor continuously to identify “trust gaps” and outliers

    DevOps is no stranger to continuous monitoring and instrumentation.  From a security perspective, continuous monitoring is about establishing a set of controls that allows you to quickly identify conditions that increase risk, and the elements above help you do that job more effectively.  For example:

    • Access limits and choke points enable you to quickly detect when someone has gone around your process and made changes directly in the production environment.
    • These elements also allow you to keep tabs on third-party contractors and providers to ensure that they play by your rules, and you know what they are up to all the time.
    • Defensible choke points enable you to sound the alarm if someone is tampering with your source repositories, automation scripts, or security monitoring components (such as disabling logging).
    • Study your indicators to find dark spots in your telemetry around handoffs, and ask how an attacker (internally or externally) could exploit any weaknesses in your handoffs.

    These are just a few examples of how these concepts can be applied.  When you recognize that handoffs are risky, you can quickly see how security can play a role in mitigating those risks and helping defend the reliability, safety, and trust of your production environment.

  • Continuous integration for better security

    Continuous integration for better security

    One of the big advantages to smaller deploys and continuous integration is that it can make it easier to provide more proactive security. In short, continuous integration (and the associated automated testing it enables) makes it easier to focus your security team on analyzing areas where the security risk is higher.

    If the notion of rapid development, rapid deployment, and continuous integration make your security team nervous you may be able to get them engaged by sharing proven ideas from companies who’ve made this approach work well in the real world.   For example, I was recently flipping through a presentation from Etsy on SlideShare, and discovered a clear explanation of how continuous integration enables better security.

    Slide34At right, you see slide 34 from this (very long but clear) deck. this is the first in a series of slides that talks about how you can identify high-risk areas of code, then use those designations to drive  automated checks for changes to those areas of code.  The power comes in when you automatically alert the security team that someone has just check in code which changes one of the high-risk areas.

    This seems like a commonsense way to focus high attention on high risk.

    Another positive benefit of this approach is that it forces the conversation upfront about what constitutes a high-risk area code. This is an opportunity to get security, ops, and the business on the same page about where risk is likely to occur. When you incorporate this approach with periodic reviews of where things stand, it allows you to refine your approach to automated analysis based on your experience. In other words, during post-incident review if you discover one of those”Gee I wish I’d known that I had of time” sorts of situations, you can add a check into the automation library that looks for those conditions in the future. This sort of continuous improvement model benefits everyone.

    Oh, by the way – one of the scenarios this approach can check for is the introduction of new third-party libraries. In today’s climate of elevated concern over third-party risk (as well as fears of security flaws in open-source components) having that capability can be a very good thing.

    What about you? How are you integrating continuous security checks into your continuous integration?

  • 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?