Research

With vendor evaluations in hand, you are ready to make your decision, right? The answer is both yes and no. We know the importance of this decision – you are here because your first attempt at this project wasn’t as successful as it needed to be. After the vendor evaluation process you are in a position to distinguish innovative technologies from pigs with fresh lipstick. But now you need to see which of the vendors is actually the best fit for you! Successful decision-making on SIEM replacement goes beyond vendor evaluation – it entails evaluating yourself too. It is important to differentiate between the two because you cannot make a decision without taking a long hard look at yourself, your team, and your company. This is an area where many projects fail, so let’s break the decision down to ensure you can make a good recommendation and feel comfortable with it – from both internal and external perspectives. But remember the selection of the ‘right’ vendor may come down to more than matching needs against capabilities. The output of our Security Management 2.5 process is not really a decision – it’s more of a recommendation. The final decision will likely be made in the executive suite. That’s why we focused so much on gathering data (quantitative where possible) – you will need to defend your recommendation until the purchase order is signed. And probably afterwards. Defensible Position We won’t mince words. This decision generally isn’t about objective or technical facts – especially since most of you reading this have an incumbent in play, typically part of a big company with important relationships with heavies inside your shop. This could get political, or the decision might be entirely financial, so you need your ducks in a row and a compelling argument for any change. And even then you might not be able to push through a full replacement. In that case the answer might be to supplement. In this scenario you still aggregate information with the existing platform, but then you feed it to the new platform for analysis, reporting, forensics, etc. across the enterprise. Given the economic cost of running both, this is unacceptable for some organizations, but if your hands are tied on replacement, this kind of creative approach is worth considering. But that is still only the external part of the decision process. In many cases the (perceived) failure of your existing SIEM may be self-inflicted. So we also need to evaluate and explain the causes of the failure, with assurance that you can avoid those issues this time. If not your successor will be in the same boat in another 2-3 years. So before you put your neck on the chopping block and advocate for change (if that is what you decide), do some deep internal analysis as well. Looking in the mirror First, let’s make sure you really re-examined the existing platform in terms of the original goals. Did your original goals adequately map your needs at the time, or was there stuff you did not anticipate? How have your goals changed over time? Be honest! Do not let ego get in the way of doing what’s right, and take a hard and fresh look at the decision to ensure you don’t repeat previous mistakes. Did you kick off this process because you were pissed at the original vendor? Or because they got bought and seemed to forget about the platform? Do you know what it will take to get the incumbent where it needs to be – and whether that is even possible? Is it about throwing professional services at the issues? Is there a fundamental technology problem? Did you assess the issues critically the first time around? If it was a skills issue, have you successfully addressed it? Can your folks build and maintain the platform moving forward? Are you looking at a managed service to take that concern off the table? If it was a resource problem, do you now have enough staff for proper care and feeding? Yes, the new generation of platforms requires less expertise to keep operational, but don’t be naive – no matter what any sales rep says, you cannot simply set and forget them. Whatever you pick will require expertise to deploy, manage, tune, and analyze reports. These platforms are not self-aware – by a long shot. Remember, there are no right or wrong answers here, but the truth (and your commitment) will become clear when you need to sell something to management. Some of you may worry that management will see the need for replacement as “your fault” for choosing the incumbent, so make sure you have answers to these questions and that you aren’t falling into a self-delusional trap. You need your story straight and your motivations clear. Have a straightforward and honest assessment of what is going right and wrong, so you are not caught off guard when asked to justify changes and new expenses. Setting Expectations Revisiting requirements provides insight into what you need the security management platform to do. Remember, not everything is Priority #1, so pick your top three must-have items and prioritize the requirements. You can prioritize specific use cases (compliance, security, forensics, operations), and have a pretty good feeling about whether the new platform or incumbent will meet your expectations. If you love some new features of the challenger(s), will your organization leverage them? Firing off alerts faster won’t help if your team takes a week to investigate each issue, or cannot keep up with the increased demand. The new platform’s ability to look at application and database traffic doesn’t matter if your developers won’t help you understand normal behavior to build the rule set. Fancy network flow analysis can be a productivity sink if your DNS and directory infrastructure is a mess and you can’t reliably map an IP to user ID. Does your existing product have too many features? Yes, some organizations simply cannot take advantage of (or

The problems of protecting endpoints are pretty well understood. As we described in The 2014 Guide to Endpoint Security, you have stuff (private data and/or intellectual property) that others want. On the other hand, you have employees who need to do their jobs and require access to said private data and/or intellectual property. Those employees have sensitive data on their devices, so you need to protect their endpoints. It’s not like this is anything new. Protecting endpoints has been a focus of security professionals since, well, always – with decidedly unimpressive results. Why is protecting endpoints so hard? It can’t be a matter of effort, right? Billions have been spent on research to identify better ways to protect these devices. Organizations have spent tens of billions on endpoint security products and services. Yet, every minute more devices are compromised, more data is stolen, and security folks keep having to answer senior management, regulators, and ultimately customers as to why this keeps happening. The lack of demonstrable progress comes down to two intertwined causes. First, devices are built using software that has defects attackers can exploit. Nothing is perfect, especially not software, so every line of code presents attack surface. Second, employees can be fooled into taking action (such as installing software or clicking a link) that results in a successful attack. These two causes can’t really be separated. If the device isn’t vulnerable, then nothing an employee does should result in a successful attack. And likewise, if the employee doesn’t allow delivery of the attack/exploit code by clicking things, having vulnerable software is less of an issue. So if you can disrupt either causes your endpoints will be far better protected. Of course this is much easier said than done. In this new series, “Reducing Attack Surface with Application Control,” we will dig into the good and bad of application control (also known as application white listing) technology, talking about how AppControl can stop malware in its tracks and mitigate the risks of both vulnerable software and gullible users. We won’t shy away from addressing head-on the perception issues of endpoint lockdown, which cause many organizations to disregard the technology as infeasible in their environments. Finally, we will discuss use cases where AppControl makes a lot of sense and how it can favorably impact security posture, both reducing the attack surface of vulnerable devices and protecting users from themselves. Accelerating Attacker Innovation We mentioned the billions of dollars being spent on research to protect endpoint devices more effectively. It is legitimate to ask why these efforts haven’t really worked. It comes back to attackers innovating faster than defenders. And even if technology emerges to protect devices more effectively, it takes years for new technologies to become pervasive enough to blunt the impact of attackers across a broad market. The reactive nature of traditional malware defenses – in terms of finding an attack, profiling it, and developing a signature to block it on the device – makes existing mitigations too little too late. Attackers now randomly change what attacks look like using polymorphic malware, so looking for malware files cannot solve the problem. Additionally, attackers have new and increasingly sophisticated means to contact their command and control (C&C) systems and obscure data during exfiltration, making detection all the harder. Attackers also do a lot more testing now to make sure their attacks work before they use them. Endpoint security technologies can be bought for a very small investment, so attackers refine their malware to ensure it works against a majority of the defenses in use. This causes security professionals to look at different ways of breaking the kill chain, as we described in The CISO’s Guide to Advanced Attackers. You can do this a couple different ways: Impede Delivery: If the attacker cannot deliver the attack to a vulnerable device, the chain is broken. This involves effectively stopping tactics like phishing, either by blocking the email before it gets to an employee or training employees not to click things that would result in malware delivery. Stop Compromise: Even if the attack does reach a device, if it cannot execute and exploit the device, the chain is broken. This involves a different approach to protecting endpoints, and will be the main focus of this series. Block C&C: If the device is compromised, but cannot contact the command and control infrastructure to receive instructions and additional attack code, the impact of the attack is reduced. This requires the ability to analyze all outbound network traffic for C&C patterns, as well as watching for contact with networks with bad reputations. We discussed many of these tactics in our Network-based Threat Intelligence research. Block Exfiltration: The last defense is to stop the exfiltration of data from your environment. Whether via data leak prevention technology or some other means of content or egress filtering to detect protected content, if you can stop data from leaving your environment there is no loss. The earlier you break the kill chain, the better. But in the real world, you are best served by a multi-faceted approach encompassing all the options listed above. Now let’s dig into the Stop Compromise strategy for breaking the kill chain, which is really where application control fits into the security control hierarchy. Stop Code Execution. Stop Malware. The main focus of anti-virus and anti-malware technology since the beginning has been to stop malicious code from executing on a device, thus stopping compromise. What has been evolving is how the malware is detected, and what parts of devices software can access. There are currently a handful of approaches. Block the Bad: This is the traditional AV approach of matching malware signatures against code executing on the device. The problem is scale because there is so much bad that you cannot possible expect an endpoint to check for every attack since the beginning of time. Improve Heuristics: It is impossible to block all malware because it is constantly changing, so you need to focus on what

Okay, we have content in this thing. We promise. But we can’t stop staring at our new title video sequence. I mean, just look at it! This week Rich, Mike, and Adrian discuss Target, Snapchat, RSA, and why no one can get crisis communications correct. Sorry we hit technical difficulties with the live Q&A Friday, but we think we have the kinks worked out (I’d blame Mike if I were inclined to point fingers). Our plan is to record Friday again – keep an eye on our Google+ page for the details. Share:

Over the past few years I have spent a lot of time traveling the world, talking and teaching about cloud security. To back that up I have probably spent more time researching the technologies than any other topic since I moved from being a developer and consultant into the analyst role. Something seemed different at such a fundamental level that I was driven to put my hands on a keyboard and see what it looked and felt like. To be honest, even after spending a couple years at this, I still feel I am barely scratching the surface. But along the way I have learned a heck of a lot. I realized that many of my initial assumptions were wrong, and the cloud required a different lens to tease out the security implications. This paper is the culmination of that work. It attempts to break down the security implications of cloud computing, both positive and negative, and change how we approach the problem. In my travels I have found that security professionals are incredibly receptive to the differences between cloud and traditional infrastructure, but they simply don’t have the time to spend 3-4 years researching and playing with cloud platforms and services. I hope this work helps people think about cloud computing differently, providing practical examples of how to leverage and secure it today. I would like to thank CloudPassage for licensing the paper. This is something I have wanted to write for a long time, but it was hard to find a security company ready to take the plunge. Their financial support enables us to release this work for free. As always, the content was developed completely independently using our Totally Transparent Research process – this time it was actually developed on GitHub to facilitate public response. I would also like to thank the Cloud Security Alliance for reviewing and co-branding and co-hosting the paper. There are two versions. The Executive Summary is 2 pages of highlights from the main report. The Full Version includes an executive summary (formatted differently), as well as the full report. As always, if you have any feedback please leave it here or on the report’s permanent home page. Executive Summary: What CISOs Need to Know About Cloud Computing (PDF) Full Report: What CISOs Need to Know About Cloud Computing Share:

Rich here. A funny thing happened this week. As I wrote on Tuesday, someone hacked my Amazon Web Services account when I accidentally left my keys in code I pushed up to GitHub. The first line of my code was, This is a bit embarrassing to write. I take my role as a public figure in security pretty seriously. I am thankful every day that I get to do what I do (okay, maybe not the day I was in Kiev in December trying to find a menu I could understand). As an introvert it’s weird to be out there writing and speaking in public on security every day and have people actually read and listen. And to get paid for it. It is entirely too easy to let this go to one’s head, and I’m pretty sure any of you reading this can start counting off some of the names. In my mind I need to keep earning it every day. That means actually knowing what I’m talking about, taking security seriously, and setting an example. I expect to be hacked in the course of what I do, but I strive to avoid dumb mistakes. You know, practice what I preach. Well, I made a series of mistakes – I suppose I am human (or at least humanoid) after all. And I got popped. I always assume something like that will get out, so I might as well break the news myself, and spill the gory details so maybe someone can avoid screwing up like I did. I expected some criticism, but the exact opposite happened. The overwhelming support from the community was astounding. Nobody called me an idiot, and people recognized that I’m just a dude, trying my best, and making mistakes. Contrast this to the recent communications from Target, Snapchat, or any other company that gets breached or screws up. They try their best to cover things up, release as little information as possible, and hope people forget. It never works. Anyone with a modicum of crisis communications training knows that silence and obfuscation sow distrust and uncertainty. This isn’t rocket science. Coming clean was scary and initially painful, but if I expect people to trust me, I need to be open about those sorts of things. In the end, I was riding high all day on the incredible support from the community. From my community. The real lesson? I am totally going to screw some other things up on purpose and talk about it now. I mean, it has to work again next time, right? On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted in DBaaS article. Rich quoted in Dark Reading on speakers leaving the RSA conference. Rich quoted in Computerworld on the same issue. Dave Lewis (yes, our Dave Lewis) wrote up my little issue over at CSO. Another Dave article at CSO: Find security flaw, go to jail? Favorite Securosis Posts Adrian Lane: Firestarter: The NSA and RSA. Despite looking and sounding like I am being pulled into a 4th dimension, my favorite this week is the inaugural Securosis Firestarter. Mike Rothman: Firestarter: The NSA and RSA. Yeah, everyone is going to pick Rich’s $500 screw-up post. But I am really excited at how our video podcast turned out. As long as we keep it short it will be a lot of fun to do in 2014. Mort: My $500 Cloud Security Screwup – Updated. James Arlen: Rich Mogull is the Most Honest Man in Infosec. Editor’s note: not really! Rich: Incite 1/8/2014: ReNew Year. Yep, new stuff coming – can’t wait to get it out there and see what works! Other Securosis Posts Security Management 2.5: The Decision Process. Mikko Hypponen Still Speaking at the RSA Conference Updated. Security Management 2.5: Evaluating the Incumbent. Security Management 2.5: Revisiting Requirements. Firestarter: The NSA and RSA. Favorite Outside Posts Adrian Lane: So You Wanna Boycott RSA Conference 2014. Why write this post again? Bill said it better. Mike Rothman: Don’t Tell Me You’re Busy. Thanks to our pal Jen (@mediaphyter) for reminding me of this classic post. We are all busy. But no one is too busy to return a call or text from a friend. And if you are, your priorities are screwed up. Dave Lewis: The 7 best habits of effective security pros. Mort: On Getting Naked in Antarctica. It’s not security related, but in honor of this week being so damn cold in the midwest & northeast… James Arlen: Applied Crypto Hardening – PDF Rich: How Netflix Reversed Engineered Hollywood. Some interesting big data lessons in here. Research Reports and Presentations What CISOs Need to Know about Cloud Computing. Defending Against Application Denial of Service Attacks. Executive Guide to Pragmatic Network Security Management. Security Awareness Training Evolution. Firewall Management Essentials. A Practical Example of Software Defined Security. Continuous Security Monitoring. API Gateways: Where Security Enables Innovation. Identity and Access Management for Cloud Services. Dealing with Database Denial of Service. The 2014 Endpoint Security Buyer’s Guide. Top News and Posts Snapchat hack results in 4.6 million accounts being posted online. Yahoo! Spread Bitcoin Mining Botnet Malware Via Ads. Video tells children it’s okay for TSA to molest them. So bad it’s awesome! TSA uses animated dogs as characters – if you own dogs, you know “Stop, Scream, & Pee” is more likely. Firm Bankrupted by Cyberheist Sues Bank via Krebs. Inside TAO. How Worried Should We Be About the Alleged RSA-NSA Scheming? Office 365 Token Vulnerability. A couple weeks old but a good read. Infographic: ISO 27001:2013 Changes Skipfish Scanner Used In Financial Sector Attacks Five Product Security Questions Nobody At CES Wants You To Ask. Blog Comment of the Week This week’s best comment goes to Jay, in response to Security Management 2.5: Evaluating the Incumbent. More good stuff here and sound analysis. I think we’ve done a good job identifying where the SIEM market is or should be going. Hope you intend to provide some sort of

By this point you appreciate the difference large gap between what you need and what you have, so it’s time to dip your toes in the water to see what other platform vendors offer. But how? You need to figure out which vendors are worth investigating for their advantages, despite any disadvantages. Much of defining evaluation criteria and potential candidates involves wading objectively through vendor hyperbole to see what each offering actually does vs. drug-induced optimism in the vendor’s marketing department. As technology markets mature (and SIEM is pretty mature), the base capabilities of the platforms converge, making them all look alike. Complicating the issue, vendors adopt similar messaging regardless of actual features, making it increasingly difficult to differentiate between the platforms. But you still need to do it, because given your unhappiness with your current platform (or you wouldn’t be reading this, right?), you need to distill what a platform does and doesn’t do, as early in the process as you can. And make no mistake – there are significant differences! We divide the vendor evaluation process into two phases. First we will help you define a short list of potential replacements. Maybe you use a formal Request for Proposals or Information (RFP/RFI) to cull the 15 companies left in the space down to 3-5, or perhaps you don’t. You will see soon enough why you can’t run 10 vendors through even the first stage of the evaluation, so you need a way to narrow down the field to get started. At the conclusion of the short list exercise you will need to test one or two new platforms during a proof of concept (PoC), which we will detail. We don’t recommend skipping directly to the PoC, by the way. Each platform has strengths and weaknesses, and just landing in the upper-right quadrant of a magical chart doesn’t make a vendor the right choice for you. And the RFP process usually unearths items you had not considered, so the process is valuable for its own sake. It is time to do your homework. All of it. Even if you don’t feel like it. The Short List The goal at this point is to whittle the list down to 3-5 vendors who appear to meet your needs, based upon the results of the RFIs or RFPs you sent vendors. Their answers should quickly disqualify a few who lack critical capabilities. The next step, for the remaining vendors, is to get a little better sense of their products and firms. Your main tool at this stage is what we call the dog and pony show. The vendor brings in their sales folks and sales engineers (SEs) to tell you how their product is awesome and will solve every problem you have. Of course they won’t be ready (unless they read this paper as well) for the intensity of your KGB-style interrogation techniques. You know what is important to you, and you need confidence that any vendor passing through this gauntlet to the PoC can meet your requirements. Let’s talk a bit about tactics for getting the answers you need, based on deficiencies in your existing product (from your platform evaluation). You need detailed answers at these meetings to objectively evaluate any new platform. You don’t want a 30-slide PowerPoint walkthrough and a generic demo. Make sure the challenger understands those expectations ahead of the meeting so they have the right folks in the room. If they bring the wrong people cross them off. It’s as simple as that – it’s not like you have a lot of time to waste, right? We recommend defining a set of use cases/scenarios for the vendor to walk you through. Then their skilled folks with expertise using the tool can show you how they would solve the problem you mapped out. This forces them to think about your problems rather than their scripted demo and shows off the tool’s relevant capabilities, instead of the smoothness of the folks staging the demo. You don’t want to buy from the best presenter – you want to identify the product that best meets your needs, and that means making the vendor do what you need – not what shows off their product best. Here are a few scenarios to help guide you on how to set up these meetings. Prioritize this list based on your own needs, but this should get you 90% of the way through narrowing down the list. Security: The first scenario should focus on security. That’s what this ultimately boils down to, right? You want to understand how they would detect an attack based on their information sources, as well as how they configure rule sets and alerts. Make it detailed but not ridiculous. Basically, simplify your existing environment a bit and run them through an attack scenario you saw recently. This will be a good exercise for seeing how the data they collect solves a major use case, detecting an emerging attack quickly. Have the SE walk you through setting up and customizing a rule because you will often need to do both. Use your own scenario to reduce the likelihood of the SE having a pre-built rule. You want to really understand how the rules work because you will spend a lot of time configuring your rules, so it’s useful to see how easy it is for an expert create new policies. Compliance: Next you need to understand how much automation is available for compliance. Ask the SE to show you the process of preparing for an audit. And no, showing you a list of 2,000 reports, most called “PCI X.X”, is not sufficient. Nor is a drop-down list of 200 checkboxes with obscure names going to help you. Ask them to produce samples for a handful of critical reports you rely upon to see how closely they hit the mark – you can see the difference between reports developed by an engineer and those created by an auditor. You need to

Since I’m on the East Coast of the US, when the ball drops in Times Square that’s it. The old year is done. The new year begins. With some of Dublin’s finest coursing through my veins, I get a little nostalgic. I don’t think about years in terms of “good” or “bad” anymore – instead I realize that 2013 is now merely a memory that will inevitably fade away. The new year brings a time of renewal. A time to thoughtfully consider the possibilities of the coming 12 months because 2014 is a blank slate. Not exactly blank because my responsibilities didn’t disappear as the ball descended – nor have yours. But we have the power to make 2014 whatever we want. That’s exciting to me. I don’t fear change, I embrace change. Which is a good thing because change always comes every year without fail. You grow. You evolve. You change. I can’t wait to try new stuff. As Rich said in Thank You, we will do new things in 2014. Some of the will work, and some won’t. I don’t have the foggiest idea which will fall into each category. Uncertainty makes some folks uncomfortable. Not me. The idea of a certain future is not interesting at all. That would mean not getting an unexpected call to work on something that could be very very cool. But I also might not get any calls at all. You just don’t know. And that’s what makes it exciting. I can’t wait to learn new things. About technology,because security continues to evolve quickly, which means that if you sit still you are actually falling behind. I am also learning a lot about myself, which is kind of strange for a guy in his mid-40s, but it’s true. In researching the Neuro-Hacking talk I’m doing with JJ at RSA, I am adding to my current practices to improve as a person. Like everyone else, I find that being reminded of my ideals helps keep them at the forefront of my mind. So over the holiday, I treated myself to a few Hugh McLeod prints to hang in my office. The first is called Abundance and the quote on the picture is: “Abundance begins with gratitude.” It’s true. I need to remain thankful for what I have. That appreciation and a dedication to helping others will keep me on a path to achieve bigger things. The other is One Day is Dead, which is a reminder to make the most of every day and focus on living right now. This has been a frequently theme in my writing lately and will remain. I write the weekly Incite for me as much as for anyone else. It is a public journal of my thoughts and ideas each week. I also spent some time looking back through some of the archives, and it’s fascinating to see how I have changed over the past few years. But not half as fascinating as imagining how much I’ll change over the next few. So I jump into 2014 with both feet. Happy ReNew Year. –Mike Photo credit: “Renewing shoe” originally uploaded by Adam Fagen Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Security Management 2.5: You Buy a New SIEM Yet? Evaluating the Incumbent Revisiting Requirements Platform Evolution Changing Needs Introduction Advanced Endpoint and Server Protection Introduction What CISOs Need to Know about Cloud Computing Adapting Security for Cloud Computing How the Cloud is Different for Security Introduction Newly Published Papers Defending Against Application Denial of Service Security Awareness Training Evolution Firewall Management Essentials Continuous Security Monitoring API Gateways Threat Intelligence for Ecosystem Risk Management Dealing with Database Denial of Service Identity and Access Management for Cloud Services The 2014 Endpoint Security Buyer’s Guide The CISO’s Guide to Advanced Attackers Incite 4 U FireEye’s Incident Response Play: Of course the one day I decide to take vacation over the holidays, the FireEye folks buy Mandiant for a cool billion-ish. Lots of folks have weighed in on the deal already so I won’t repeat their analysis. Clearly FireEye realizes they need to become more than just a malware detection box/service, because only a broad network security platform player could provide the revenue to support their current valuation. Obviously this won’t be their last deal. Were there other things they could have bought for less money that would have fit better? Probably. But Mandiant brings a ton of expertise and a security brand juggernaut to FireEye. Was it worth $1 BILLION? That depends on whether you think FireEye was worth $5 billion before the deal, because the price was mostly in FireEye stock, which is, uh, generously valued. The question is whether forensics (both services and products) has become a sustainable mega-growth segment of security. That will depend on whether the technology becomes simple enough for companies without a dedicated forensics staff to use. It ain’t there yet. – MR Me Too: It’s Tuesday as I write this, right after Mike harassed me to get my Incites in. I open up Pocket to check out what stories I have collected over the past couple weeks. Number four on my list is a post by Luke Chadwick on how his Amazon Web Services account was hacked when he accidentally left his Access Keys in some code he published online. That seems strangely familiar. It seems bad guys are indeed scraping online code repositories to find cloud service keys and then use them for mining Litecoins. It also seems even security-aware developers and analysts like myself, despite our best efforts, can mess up and accidentally make life easy for attackers. I encapsulated my lessons in my post, but the thing I learned all of two minutes ago is

This speaks for itself: An Open Letter to the Chiefs of EMC and RSA and Securing Smart Machines: Where We Are, Where We Want to Be, and Challenges I have confirmed from multiple sources that the session is still on the schedule, and he has not cancelled yet. Update: Mykko updated his post and he is now pulling out of all talks. He also says: While I am glad to see that many other speakers have decided to cancel their appearances at RSA 2014 in protest, I don’t want to portray myself as a leader of a boycott. I did what I felt I had to do. Others are making their own decisions. I’m glad he cleared that up. Share:

Update: Amazon reached out to me and reversed the charges, without me asking or complaining (or in any way contacting them). I accept full responsibility and didn’t post this to get a refund, but I’m sure not going to complain – neither is Mike. This is a bit embarrassing to write. I take security pretty seriously. Okay, that seems silly to say, but we all know a lot of people who speak publicly on security don’t practice what they preach. I know I’m not perfect – far from it – but I really try to ensure that when I’m hacked, whoever gets me will have earned it. That said, I’m also human, and sometimes make sacrifices for convenience. But when I do so, I try to make darn sure they are deliberate, if misguided, decisions. And there is the list of things I know I need to fix but haven’t had time to get to. Last night, I managed to screw both those up. It’s important to fess up, and I learned (the hard way) some interesting conclusions about a new attack trend that probably needs its own post. And, as is often the case, I made three moderately small errors that combined to an epic FAIL. I was on the couch, finishing up an episode of Marvel’s Agents of S.H.I.E.L.D. (no, it isn’t very good, but I can’t help myself; if they kill off 90% of the cast and replace them with Buffy vets it could totally rock, though). Anyway… after the show I checked my email before heading to bed. This is what I saw: Dear AWS Customer, Your security is important to us. We recently became aware that your AWS Access Key (ending with 3KFA) along with your Secret Key are publicly available on github.com . This poses a security risk to you, could lead to excessive charges from unauthorized activity or abuse, and violates the AWS Customer Agreement. We also believe that this credential exposure led to unauthorized EC2 instances launched in your account. Please log into your account and check that all EC2 instances are legitimate (please check all regions – to switch between regions use the drop-down in the top-right corner of the management console screen). Delete all unauthorized resources and then delete or rotate the access keys. We strongly suggest that you take steps to prevent any new credentials from being published in this manner again. Please ensure the exposed credentials are deleted or rotated and the unauthorized instances are stopped in all regions before 11-Jan-2014. NOTE: If the exposed credentials have not been deleted or rotated by the date specified, in accordance with the AWS Customer Agreement, we will suspend your AWS account. Detailed instructions are included below for your convenience. CHECK FOR UNAUTHORIZED USAGE To check the usage, please log into your AWS Management Console and go to each service page to see what resources are being used. Please pay special attention to the running EC2 instances and IAM users, roles, and groups. You can also check “This Month’s Activity” section on the “Account Activity” page. You can use the dropdown in the top-right corner of the console screen to switch between regions (unauthorized resources can be running in any region). DELETE THE KEY If are not using the access key, you can simply delete it. To delete the exposed key, visit the “Security Credentials” page. Your keys will be listed in the “Access Credentials” section. To delete a key, you must first make it inactive, and then delete it. ROTATE THE KEY If your application uses the access key, you need to replace the exposed key with a new one. To do this, first create a second key (at that point both keys will be active) and modify your application to use the new key. Then disable (but not delete) the first key. If there are any problems with your application, you can make the first key active again. When your application is fully functional with the first key inactive, you can delete the first key. This last step is necessary – leaving the exposed key disabled is not acceptable. Best regards, Alex R. aws.amazon.com Crap. I bolted off the couch, mumbling to my wife, “my Amazon’s been hacked”, and disappeared into my office. I immediately logged into AWS and GitHub to see what happened. Lately I have been expanding the technical work I did for my Black Hat presentation, I am building a proof of concept tool to show some DevOps-style Software Defined Security techniques. Yes, I’m an industry analyst, and we aren’t supposed to touch anything other than PowerPoint, but I realized a while ago that no one was actually demonstrating how to leverage the cloud and DevOps for defensive security. Talking about it wasn’t enough – I needed to show people. The code is still super basic but evolving nicely, and will be done in plenty of time for RSA. I put it up on GitHub to keep track of it, and because I plan to release it after the talk. It’s actually public now because I don’t really care if anyone sees it early. The Ruby program currently connects to AWS and a Chef server I have running, and thus needs credentials. Stop smirking – I’m not that stupid, and the creds are in a separate configuration file that I keep locally. My first thought was that I screwed up the .gitignore and somehow accidentally published that file. Nope, all good. But it took all of 15 seconds to realize that a second test.rb file I used to test smaller code blocks still had my Access Key and Secret Key in a line I commented out. When I validated my code before checking it in, I saw the section for pulling from the configuration file, but missed the commented code containing my keys. Crap. Delete. Back to AWS. I first jumped into my Security Credentials section and revoked the key. Fortunately I didn’t see any other

To explain the importance of picking a platform, rather than a product, our last post compared Log Management to SIEM, like the difference between using kitchen appliances and running a machine shop. One is easy to use, but limited in applicability; the other requires more work on your part, but can accomplish much more. Our goal was to contrast use cases and levels of expectations between the two product classes; despite lower overall platform satisfaction and the greater amount of work required, SIEM is what many customers need to get their work done. Pushing the boundaries of what is possible involves some pain. Customers grumble about the tremendous growth in event collection driven by all these new devices, but they need to collect nearly every event type, and often believe they need real-time response. The product had better be fast and provide detailed forensic audits. Customers depend on compliance reports for their non-technical audience, along with detailed operational reports for IT. SIEM customers have a daily yin/yang battle – between automation and generic results; between efficiency and speed; between easy and useful. Again, dissatisfaction is to be expected, but this exercise is to get real work done with a balky product. SIEMulation To illustrate why customers go through the re-evaluation process, here are some excerpts from customer conversations: “We had some data leakage a couple years ago; nothing serious, but it was a partner who discovered the issue. It took some time to determine why we did not see the activity with SIEM and other internal security systems. Needless to say our executive team was not happy, and wanted us to justify our security expenditures. Actually they said “Why did we not see this? What the hell are we paying for?” Our goal is to be able to get detection working the way we need it to work, and that means full packet capture and analysis. As you know, that means a lot more data, and we need longer retention periods as well.” “We upgraded from log management to SIEM two years ago in order to help with malware detection and to scale up general security awareness. The new platform is supposed to scale, but we don’t actually know if it does scale yet because we are still rolling it out. Talk to me again in a couple years – I ought to have it done by then.” “I want security analytics. I have systems to measure supply chain efficiency. I have business risk analysis systems. I want the same view into operational and security risk, but I can’t blend the analysis capabilities from these other platforms with the SIEM data. Our goal is to have the same type of analysis everywhere, and eventually a more unified system.” When it comes to evaluating your current platform, you need to think about the issue from two perspectives. First formally evaluate how well your platform addresses your current and foreseeable requirements in order to quantify critical features you depend on and identify significant deficiencies. Second, look at evolving use cases and the impact of newer platforms on operations and deployment – both good and bad. Just because another vendor offers more features and performance does not mean you should replace your SIEM. The grass is not always greener on the other side. The former is critical for the decision process later in this series; the latter is essential for analyzing the ramifications of a replacement decision. Sizing up the incumbent The first step in the evaluation process uses the catalog of requirements you built already to critically assess how the current SIEM platform achieves your needs. This means spelling out each business function, how critical it is, and whether the current platform gets it done. You will need to discuss these questions with stakeholders from operations, security, compliance, and any other organizations that participate in the management of SIEM or take advantage of it. You cannot make this decision in a vacuum, and lining up support early in the process will pay dividends later on. Trust us on this. Operations will be the best judge of whether the platform is easy to maintain and the complexity of implementing new policies. Security will have the best understanding of the product or service’s forensic auditing capabilities. Compliance teams can judge suitability of reports for audit preparation. And an increasingly common contributor is risk and/or data analysts who mine information and help prioritize allocation of resources. Each audience provides a unique perspective on the criticality of some function and the effectiveness of the current platform. At this point you have already examined your requirements so you should understand what you have, what you want, and the difference between the two. In some cases you will find that the incumbent platform simply does not fill a hard requirement – which makes the analysis easy. In other cases the system works perfectly, but is a nightmare in terms of maintenance and care & feeding for any system or rule changes. Performance may be less than ideal, but it’s not necessarily clear what that really means, because any system could always be faster when investigating a possible breach. It may turn out the SIEM functions as designed but lacks the capacity to keep up with all the events you need to collect, or takes too long to generate actionable reports. Act like a detective, collecting these tidbits of information, no matter how small, to build the story of the existing SIEM platform in your environment. This information will come into play later when you weigh options, and we recommend using a format that makes it easy to compare and contrast issues. Security, compliance, management, integration, reporting, analysis, performance, scalability, correlation, and forensic analysis are all areas you need to evaluate in terms of your revised requirements. Prioritization of existing and desired features helps streamline the analysis. We reiterate the importance of staying focused on critical items to avoid “shiny object syndrome” driving you to select the pretty new