Research

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

Given the evolution of SIEM technology and the security challenges facing organizations, it is time to revisit requirements and use cases. This is an essential part of the evaluation process. You need a fresh and critical look at your security management environment to understand what you need today, how that will change tomorrow, and what kinds of resources and expertise you can harness – unconstrained by your current state. While some requirements may not have changed all that much (such as ease of management and compliance reporting), as we described earlier in this series, the way we use these systems has changed dramatically. That is our way of saying it is good to start with a laundry list of things you would like to be able to do, but cannot with your current system. And while you are thinking about shiny new capabilities, don’t forget the basic day-to-day operational stuff a SIEM does. Finally, you need to consider what is coming down the road in terms of business challenges (and the resulting security issues) that will emerge over the next couple years. None of us has a crystal ball, but critical business imperatives should give you a foundation for figuring out how things need to change. A fresh start Some organizations choose to take a fresh look at their security management infrastructure every so often, while others have the choice thrust upon them. For instance if your organization was breached or infected by malware and your SIEM platform failed to detect it, you need to take a critical look at your security management environment. The current platform may be adequate, or it might be a dog – and you personally might not have even chosen it – but keep in mind that your success is linked to how well your platform meets your requirements. If things go south, blaming your predecessor for choosing a mediocre SIEM won’t save your job. You also need to face the reality that other groups within the organization have differing needs for the SIEM. Operations only cares that they get the metrics they need, compliance teams only care about getting their reports, and upper management only cares about pushing blame downhill when the company is pwned by hackers. It’s time to roll up your sleeves and figure out what you need. Every so often it makes sense to critically look at what works and what doesn’t from the standpoint of security management. To find out the best path forward, we recommend starting with the proverbial blank slate. It is helpful to consider the your priorities when you selected the system in the first place, to illuminate how your environment has changed over time and help understand the amount of change to expect in the future. To be more specific, use this opportunity to revisit the priorities of your requirements and use cases for each of the three main drivers for security management spending: improving security, increasing efficiency, and automating compliance. It’s all about me Setting requirements is all about you, right? It’s about what you need to get done. It’s about how you want to work. It’s about what you can’t do – at least easily – today. Well, not quite. We jest to make a point: you need to start with a look inward at what your company needs – rather than getting distracted by what the market is offering today. This requires taking a look at your organization, and the other internal teams that use the SIEM. Once your team is clear abou your own requirements, start to discuss requirements with external influencers. Assuming you work in security, you should consult ops teams, business users, compliance, and perhaps the general counsel, about their various requirements. This should confirm the priorities you established earlier, and set the stage for enlisting support if you decide to move to a new platform. Our research has shown that organizational needs remain constant, as mentioned above: improve security, improve efficiency, and support compliance. But none of these goals has gotten easier. The scale of the problem has grown, so if you have stood still and have not added new capabilities… you actually lost ground. For example, perhaps you first implemented a Log Management capability to crank out compliance reports. We see that as a common initial driver. But as your organization grew and you did more stuff online, you collected more events, and now need a much larger platform to aggregate and analyze all that data. Or perhaps you just finished cleaning up a messy security incident which your existing SIEM missed. If so you probably now want to make sure correlation and monitoring work better, and that you have some kind of threat intelligence to help you know what to look for. Increasingly SIEM platforms monitor up the stack – collecting additional data types including identity, Database Activity Monitoring, application support, and configuration management. That additional data helps isolate infrastructure attacks, but you cannot afford to stop there. As attacks target higher-level business processes and the systems that automate them, you will need visibility beyond core infrastructure. So your security management platform needs to detect attacks in the context of business threats. Don’t forget about advanced forensics – it would be folly to count on blocking every attack. So you will probably rely on your security management platform to help React Faster and Better with incident response. You might also be looking for a more integrated user experience across a number of security functions to improve efficiency. For example you might have separate vendors for change detection, vulnerability management, firewall and IDS monitoring, and Database Activity Monitoring. You may be wearing out your swivel chair switching between all those consoles, and simplification through vendor consolidation might be a key driver as you revisit your requirements. Don’t be hung up on what you have – figure out what you need now. Do a little thinking about what would make your life a lot easier, and use those ideas

Hey everyone. It’s a new year and time for new stuff from your pals here at Securosis. We used to run a Monday-morning ‘Firestarter’ post to get people thinking for the week. We decided to revive it with a twist. We are restarting the Firestarter as a weekly short video (15 minutes or so is our target). As we work out the details we also plan to push it out as a podcast, and once every month or so we will run a longer episode to dig deeper into a topic. We pre-recorded this version, but as you’ll see we ran it on Google Hangouts. When possible, we will post our recording times up there so you can participate (sorry, via text only) as we record. This week we decided to cover the NSA/RSA controversy and the… interesting… decision by some to pull out of the RSA conference over it. Share: