Research

If you made it this far we know your old platform is akin to an old junker automobile: every day you drive to work in a noisy, uncomfortable, costly vehicle that may or may not get you where you need to be, and every time you turn around you’re spending more money to fix something. With cars figuring out what you want, shopping, getting financing, and then dealing with car sales people is no picnic either, but in the end you do it to make you life a bit easier and yourself more comfortable. It is important to remember this because, at this stage of SIEM replacement, it feels like we have gone through a lot of work just so we can do more work to roll out the new platform. Let’s step back for a moment and focus on what’s important; getting stuff done as simply and easily as possible. Now that you are moving to something else, how do you get there? The migration process is not easy, and it takes effort to move from from the incumbent to the new platform. We have outlined a disciplined and objective process to determine whether it is worth moving to a new security management platform. Now we will outline a process for implementing the new platform and transitioning from the incumbent to the new SIEM. You need to implement, and migrate your existing environment to the new platform, while maintaining service levels, and without exposing your organization to additional risk. This may involve supporting two systems for a short while. Or in a hybrid architecture using two systems indefinitely. Either way, when a customer puts his/her head on the block to select a new platform, the migration needs to go smoothly. There is no such thing as a ‘flash’ cutover. We recommend you start deploying the new SIEM long before you get rid of the old. At best, you will deprecate portions of the older system after newer replacement capabilities are online, but you will likely want the older system as a fallback until all new functions have been vetted and tuned. We have learned the importance of this staging process the hard way. Ignore it at your own peril, keeping in mind that your security management platform supports several key business functions. Plan We offer a migration plan for moving to the new security management platform. It covers data collection as well as migrating/reviewing policies, reports, and deployment architectures. We break the migration process into two phases: planning and implementation. Your plan needs to be very clear and specific about when things get installed, how data gets migrated, when you cut over from old systems to new, and who performs the work. The Planning step leverages much of the work done up to this point in evaluating replacement options – you just need to adapt it for migration. Review: Go back through the documents you created earlier. First consider your platform evaluation documents, which will help you understand what the current system provides and key deficiencies to address. These documents become the priority list for the migration effort, the basis for your migration task list. Next leverage what you learned during the PoC. To evaluate your new security management platform provider you conducted a mini deployment. Use what you learned from that exercise – particularly what worked and didn’t – as input for subsequent planning, and address the issues you identified. Focus on incremental success: What do you install first? Do you work top down or bottom up? Will you keep both systems operational throughout the entire migration, or shut down portions of the old as each node migrates? We recommend using your deployment model as a guide. You can learn more about these models by checking out Understanding and Selecting a SIEM. When using a mesh deployment model, it is often easiest to make sure a single node/location is fully functional before moving on to the next. With ring architectures it is generally best to get the central SIEM platform operational, and then gradually add nodes around it until you reach the scalability limit of the central node. Hierarchal models are best deployed top-down, with the central server first, followed by regional aggregation nodes in order of criticality, down to the collector level. Break the project up to establish incremental successes and avoid dead ends. Allocate resources: Who does the work? When will they do it? How long will it take to deploy the platform, data collectors, and/or log management support system(s)? This is also the time to engage professional services and enlist the new vendor’s assistance. The vendor presumably does these implementations all day long so they should have expertise at estimating these timelines. You may also want to engage them to perform some (or all) of the work in tandem with your staff, at least for the first few locations until you get the process down. Define the timeline: Estimate the time it will take to deploy the servers, install the collectors, and implement your policies. Include time for testing and verification. There is likely to be some ‘guesstimation’, but you have some reasonable metrics to plan from, from the PoC and prior experience with SIEM. You did document the PoC, right? Plan the project commencement date and publish to the team. Solicit feedback and adjust before commencing because you need shared accountability with the operations team(s) to make sure everyone has a vested interest in success. Preparation: We recommend you do as much work as possible before you begin migration, including construction of the rules and policies you will rely on to generate alerts and reports. Specify in advance any policies, reports, user accounts, data filters, backup schedules, data encryption, and related services you can. You already have a rule base so leverage it to get going. Of course you’ll tune things as you go, but why reinvent the wheel or rush unnecessarily? Keep in mind that you will always find something you failed to

As I discussed last week, the beginning of the year is a time for ReNewal and taking a look at what you will do over the next 12 months. Part of that renewal process should be clearing out the old so the new has room to grow. It’s kind of like forest fires. The old dead stuff needs to burn down so the new can emerge. I am happy to say the Boss is on board with this concept of renewal – she has been on a rampage, reducing the clutter around the house. The fact is that we accumulate a lot of crap over the years, and at some point we kind of get overrun by stuff. Having been in our house almost 10 years, since the twins were infants, we have stuff everywhere. It’s just the way it happens. Your stuff expands to take up all available space. So we still have stuff from when the kids were small. Like FeltKids and lots of other games and toys that haven’t been touched in years. It’s time for that stuff to go. We have a niece a few years younger than our twins, and a set of nephews (yes, twins run rampant in our shop) who just turned 3, we have been able to get rid of some of the stuff. There is nothing more gratifying than showing up with a huge box of action figures that were gathering dust in our basement, and seeing the little guys’ eyes light up. When we delivered our care package over Thanksgiving, they played with the toys for hours. The benefit of decluttering is twofold. First it gets the stuff out of our house. It clears room for the next wave of stuff tweens need. I don’t quite know that that is because iOS games don’t seem to take up that much room. But I’m sure they will accumulate something now that we have more room. And it’s an ongoing process. If we can get through this stuff over the next couple months that will be awesome. As I said, you accumulate a bunch of crap over 10 years. The other benefit is the joy these things bring to others. We don’t use this stuff any more. It’s just sitting around. But another family without our good fortune could use this stuff. If these things bring half the joy and satisfaction they brought our kids, that’s a huge win. And it’s not just stuff that you have. XX1 collected over 1,000 books for her Mitzvah project to donate to Sheltering Books, a local charity that provides books to homeless people living in shelters. She and I loaded up the van with boxes and boxes of books on Sunday, and when we delivered them there was great satisfaction from knowing that these books, which folks kindly donated to declutter their homes, would go to good use with people in need. And the books were out of my garage. So it was truly a win-win-win. Karma points and a decluttered garage. I’ll take it. –Mike Photo credit: “home-office-reorganization-before-after” originally uploaded by Melanie Edwards 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. Reducing Attack Surface with Application Control The Double Edged Sword Security Management 2.5: You Buy a New SIEM Yet? Negotiation Selection Process The Decision Process Evaluating the Incumbent Revisiting Requirements Platform Evolution Changing Needs Introduction Advanced Endpoint and Server Protection Assessment Introduction Newly Published Papers What CISOs Need to Know about Cloud Computing 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 Don’t take it personally: Steven Covey has been gone for years, but his 7 habits live on and on. Our friend George Hulme did a piece for CSO Online detailing the 7 habits of effective security pros. The first is communication and the second is business acumen. I’m not sure you need to even get to #3. Without the ability to persuade folks that security is important, within the context of a critical business imperative – nothing else matters. Of course then you have squishy stuff like creativity and some repetitious stuff like “actively engaging with business stakeholders”. But that’s different than business acumen. I guess it wouldn’t have resonated as well if it was 5 habits, right? Another interesting one is problem solving. Again, not unique to security, but if you don’t like to investigate stuff and solve problems, security isn’t for you. One habit that isn’t on there is don’t take it personally. Security success depends on a bunch of other things going right, so even if you are blamed for a breach or outage, it is not necessarily your fault. Another might be “wear a mouthguard” because many security folks get kicked in the teeth pretty much every day. – MR Out-of-control ad frenzy: Safari on my iPad died three times Saturday am, and the culprit was advertisement plug-ins. My music stream halted when a McDonalds ad screeched at me from another site. I was not “lovin’ it!” The 20 megabit pipe into my home and a new iPad were unable to manage fast page loads because of the turd parade of third-party ads hogging my bandwidth. It seems that in marketers’ frenzy to know everything you do and push their crap on you, they forgot to serve you what you asked for. The yoast blog offers a nice analogy, comparing on-line ads to brick-and-mortar merchants tagging customers with stickers, but it’s more like carrying around a billboard. And that analogy

As we described in the introduction to the Advanced Endpoint and Server Protection series, given the inability of most traditional security controls to defend against advanced attacks, it is time to reimagine how we do threat management. This new process has 5 phases; we call the first phase Assessment. We described it as: Assessment: The first step is gaining visibility into all devices, data sources, and applications that present risk to your environment. And you need to understand the current security posture of anything to know how to protect it. You need to know what you have, how vulnerable, and how exposed it is. With this information you can prioritize and design a set of security controls to protect it. What’s at Risk? As we described in the CISO’s Guide to Advanced Attackers, you need to understand what attackers would be trying to access in your environment and why. Before you go into a long monologue about how you don’t have anything to steal, forget it. Every organization has something that is interesting to some adversary. If could be as simple as compromising devices to launch attacks on other sites, or as focused as gaining access to your environment to steal the schematics to your latest project. You cannot afford to assume adversaries will not use advanced attacks – you need to be prepared either way. We call this Mission Assessment, and it involves figuring out what’s important in your environment. This leads you to identify interesting targets most likely to be targeted by attackers. When trying to understand what an advanced attacker will probably be looking for, there is a pretty short list: Intellectual property Protected customer data Business operational data (proposals, logistics, etc.) Everything else To learn where this data is within the organization, you need to get out from behind your desk and talk to senior management and your peers. Once you understand the potential targets, you can begin to profile adversaries likely to be interested in them. Again, we can put together a short list of likely attackers: Unsophisticated: These folks favor smash and grab attacks, where they use publicly available exploits (perhaps leveraging attack tools such as Metasploit and the Social Engineer’s Toolkit) or packaged attack kits they buy on the Internet. They are opportunists who take what they can get. Organized Crime: The next step up the food chain is organized criminals. They invest in security research, test their exploits, and always have a plan to exfiltrate and monetize what they find. They are also opportunistic but can be quite sophisticated in attacking payment processors and large-scale retailers. They tend to be most interested in financial data but have been known to steal intellectual property if they can sell it and/or use brute force approaches like DDoS threats for extortion. Competitor: Competitors sometimes use underhanded means to gain advantage in product development and competitive bids. They tend to be most interested in intellectual property and business operations. State-sponsored: Of course we all hear the familiar fretting about alleged Chinese military attackers, but you can bet every large nation-state has a team practicing offensive tactics. They are all interested in stealing all sorts of data – from both commercial and government entities. And some of them don’t care much about concealing their presence. Understanding likely attackers provides insight into their tactics, which enables you to design and implement security controls to address the risk. But before you can design the security control set you need to understand where the devices are, as well as the vulnerabilities of devices within your environment. Those are the next two steps in the Assessment phase. Discovery This process finds the endpoints and servers on your network, and makes sure everything is accounted for. When performed early in the endpoint and server protection process, this helps avoid “oh crap” moments. It is no good when you stumble over a bunch of unknown devices – with no idea what they are, what they have access to, or whether they are steaming piles of malware. Additionally, an ongoing discovery process can shorten the window between something popping up on your network, you discovering it, and figuring out whether it has been compromised. There are a number of techniques for discovery, including actively scanning your entire address space for devices and profiling what you find. This works well enough and is traditionally the main way to do initial discovery. You can supplement active discovery with a passive discovery capability, which monitors network traffic and identifies new devices based on network communications. Depending on the sophistication of the passive analysis, devices can be profiled and vulnerabilities can be identified (as we will discuss below), but the primary goal of passive monitoring is to find new unmanaged devices faster. Passive discovery is also helpful for identifying devices hidden behind firewalls and on protected segments which active discovery cannot reach. Finally, another complicating factor for discovery – especially for servers – is cloud computing. With the ability to spin up and take down virtual instances – perhaps outside your data center – your platform needs to both track and assess cloud resources, which requires some means of accessing cloud console(s) and figuring out what instances are in use. Finally, make sure to also pull data from existing asset repositories such as your CMDB, which Operations presumably uses to track all the stuff they think is out there. It is difficult to keep these data stores current so this is no substitute for an active scan, but it provides a cross-check on what’s in your environment. Determine Security Posture Once you know what’s out there you need to figure out whether it’s secure. Or more realistically, how vulnerable it is. That typically requires some kind of vulnerability scan on the devices you discovered. There are many aspects to vulnerability scanning – at the endpoint, server, and application layers – so we won’t rehash all the research from Vulnerability Management Evolution. Check it out to understand how a

You made your decision and kicked it up the food chain – now the fun begins. Well, fun for some people, anyway. For the first half of this discussion we will assume you have decided to move to a new platform and offer tactics for negotiating for a replacement platform. But some people decide not to move, using the possible switch for negotiating leverage. It is no bad thing to stay with your existing platform, so long as you have done the work to know it can meet your requirements. We are writing this paper for the people who keep telling us about their unhappiness, and how their evolving requirements have not been met. So after asking all the right questions, if the best answer is to stay put, that’s a less disruptive path anyway. Replacement tactics For now, though, let’s assume your current platform won’t get you there. Now your job is to get the best price for the new offering. Here are a few tips to leverage for the best deal: Time the buy: Yes, this is Negotiation 101. Wait until the end of the quarter and squeeze your sales rep for the best deal to get the PO in by the last day of the month. Sometimes it works, sometimes it doesn’t. But it’s worth trying. The rep may ask for your commitment that the deal will, in fact, get done that quarter. Make sure you can get it done if you pull this card. Tell the incumbent they lost the deal: Next get the incumbent involved. Once you put in a call letting them know you are going in a different direction, they will usually respond. Not always, but generally the incumbent will try to save the deal. And then you can go back to the challenger and tell them they need to do a bit better because you got this great offer from their entrenched competition. Just like when buying a car, to use this tactic you must be willing to walk away from the challenger and stay with the incumbent. Look at non-cash add-ons: Sometimes the challenger can’t discount any more. But you can ask for additional professional services, modules, boxes, licenses, whatever. With new data analytics, maybe your team lacks some in-house skills for a successful transition – the vendor can help. Remember, the incremental cost of software is zero, zilch, nada – so vendors can often bundle in a little more to get the deal when pushed to the wall. Revisit service levels: Another non-cash sweetener could be an enhanced level of service. Maybe it’s a dedicated project manager to get your migration done. Maybe it’s the Platinum level of support, even if you pay for Bronze. Given the amount of care and feeding required to keep any security management platform tuned and optimized, a deeper service relationship could come in handy. Dealing with your boss’s boss: One last thing: be prepared for your recommendation to be challenged, especially if the incumbent sells a lot of other gear to your company. This entire process has prepared you for that call, so just work through the logic of your decision once more, making clear that your recommendation is best for the organization. But expect the incumbent to go over your head – especially if they sell a lot of storage or servers to your company. Negotiating with the incumbent Customers also need to consider that maybe staying is the best option for their organization, so knowing how to leverage both sides helps you make a better deal. Dealing with an incumbent who doesn’t want to lose business adds a layer of complexity to the decision, so customers need to be prepared for incumbent vendors trying to save the business; fortunately there are ways to leverage that behavior as the decision process comes to a conclusion. It would be naive to not prepare in case the decision goes the other way – due to pricing, politics, or any other reason beyond your control. So if you have to make the status quo work and keep the incumbent, here are some ideas for making lemonade from the proverbial lemon: Tell the incumbent they are losing the deal: We know it is not totally above-board – but all’s fair in love, war, and sales. If the incumbent didn’t already know they were at risk, it can’t hurt to tell them. Some vendors (especially the big ones) don’t care, which is probably one reason you were looking at new stuff anyway. Others will get the wake-up call and try to make you happy. That’s the time to revisit your platform evaluation and figure out what needs fixing. Get services: If you have to make do with what you have, at least force the vendor’s hand to make your systems work better. Asking a vendor for feature enhancement commitments will only add to your disappointment, but there are many options at your disposal. If your issue is not getting proper value from the system, push to have the incumbent provide some professional services to improve the implementation. Maybe send your folks to training. Have their team set up a new set of rules and do knowledge transfer. We have seen organizations literally start over, which may make sense if your initial implementation is sufficiently screwed up. Scale up (at lower prices): If scalability is the issue, confront that directly with the incumbent and request additional hardware and/or licenses to address the issue. Of course this may not be enough but every little bit helps, and if moving to a new platform isn’t an option, at least you can ease the problem a bit. Especially when the incumbent knows you were looking at new gear because of a scaling problem. Add use cases: Another way to get additional value is to request additional modules thrown into a renewal or expansion deal. Maybe add the identity module or look at configuration auditing. Or work with the team to add database

Last week I wrote up my near epic fail on Amazon Web Services where I ‘let’ someone launch a bunch of Litecoin mining instances in my account. Since then I received some questions on my forensics process, so I figure this is a good time to write up the process in more detail. Specifically, how to take a snapshot and use it for forensic analysis. I won’t cover all the steps at the AWS account layer – this post focuses on what you should do for a specific instance, not your entire management plane. Metadata The first step, which I skipped, is to collect all the metadata associated with the instance. There is an easy way, a hard way (walk through the web UI and take notes manually), and the way I’m building into my nifty tool for all this that I will release at RSA (or sooner, if you know where to look). The best way is to use the AWS command line tools for your operating system. Then run the command aws ec2 describe-instances –instance-ids i-5203422c (inserting your instance ID). Note that you need to follow the instructions linked above to properly configure the tool and your credentials. I suggest piping the output to a file (e.g., aws ec2 describe-instances –instance-ids i-5203422c > forensic-metadata.log) for later examination. You should also get the console output, which is stored by AWS for a short period on boot/reboot/termination. aws ec2 get-console-output –instance-id i-5203422c. This might include a bit more information if the attacker mucked with logs inside the instance, but won’t be useful for a hacked instance because it is only a boot log. This is a good reason to use a tool that collects instance logs outside AWS. That is the basics of the metadata for an instance. Those two pieces collect the most important bits. The best option would be CloudTrail logs, but that is fodder for a future post. Instance Forensics Now on to the instance itself. While you might log into it and poke around, I focused on classical storage forensics. There are four steps: Take a snapshot of all storage volumes. Launch an instance to examine the volumes. Attach the volumes. Perform your investigation. If you want to test any of this, feel free to use the snapshot of the hacked instance that was running in my account (well, one of 10 instances). The snapshot ID you will need is snap-ccd3e9c6. Snapshot the storage volumes I will show all this using the web interface, but you can also manage all of it using the command line or API (which is how I now do it, but that code wasn’t ready when I had my incident). There is a slightly shorter way to do this in the web UI by going straight to volumes, but that way is easier to botch, so I will show the long way and you can figure out the shorter alternative yourself. Click Instances in your EC2 management console, then check the instance to examine. Look at the details on the bottom, click the Block Devices, then each entry. Pull the Volume ID for every attached volume. Switch to Volumes and then snapshot each volume you identified in the steps above. Label each snapshot so you remember it. I suggest date and time, “Forensics”, and perhaps the instance ID. You can also add a name to your instance, then skip direct to Volumes and search for volumes attached to it. Remember, once you take a snapshot, it is read-only – you can create as many copies as you like to work on without destroying the original. When you create a volume from an instance it doesn’t overwrite the snapshot, it gets another copy injected into storage. Snapshots don’t capture volatile memory, so if you need RAM you need to either play with the instance itself or create a new image from that instance and launch it – perhaps the memory will provide more clues. That is a different process for another day. Launch a forensics instance Launch the operating system of your choice, in the same region as your snapshot. Load it with whatever tools you want. I did just a basic analysis by poking around. Attach the storage volumes Go to Snapshots in the management console. Click the one you want, right-click, and then “Create Volume from Snapshot”. Make sure you choose the same Availability Zone as your forensics instance. Seriously, make sure you choose the same Availability Zone as your instance. People always mess this up. (By ‘people’, I of course mean ‘I’). Go back to Volumes. Select the new volume when it is ready, and right click/attach. Select your forensics instance. (Mine is stopped in the screenshot – ignore that). Set a mount point you will remember. Perform your investigation Create a mount point for the new storage volumes, which are effectively external hard drives. For example, sudo mkdir /forensics. Mount the new drive, e.g., sudo mount /dev/xvdf1 /forensics. Amazon may change the device mapping when you attach the drive (technically your operating system does that, not AWS, and you get a warning when you attach). Remember, use sudo bash (or the appropriate equivalent for your OS) if you want to peek into a user account in the attached volume. And that’s it. Remember you can mess with the volume all you want, then attach a new one from the snapshot again for another pristine copy. If you need a legal trail my process probably isn’t rigorous enough, but there should be enough here that you can easily adapt. Again, try it with my snapshot if you want some practice on something with interesting data inside. And after RSA check back for a tool which automates nearly all of this. Share:

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