Research

In the first post in our Application Control series we discussed why it is hard to protect endpoints, and some of the emerging alternative technologies that promise to help us do better. Mostly because it is probably impossible do a worse job of protecting endpoints, right? We described Application Control (also known as Application Whitelisting), one of these alternatives, while being candid about the perception and reality of this technology after years of use. Our conclusion was that Application Control makes a lot of sense in a variety of use cases, and can work in more general situations, if the organization is willing to make some tradeoffs. This post describes the “good fit” use cases and mentions some of the features & functions that can make a huge difference to security and usability. Use Cases Given the breadth of ways computing devices are used in a typical enterprise, trying to use a generic set of security controls for every device doesn’t make much sense. So first you spend some time profiling the main use models of these devices and defining some standard ‘profiles’, for which you can then design appropriate defenses. There are quite a few attributes you can use to define these use cases, but here are the main ones we usually see: Operating System: You protect Windows devices differently than Macs than Linux servers, because each has a different security model and different available controls. When deciding how to protect a device, operating system is a fundamental factor. Usage Model: Next look at how the device is used. Is it a desktop, kiosk, server, laptop, or mobile device? We protect personal desktops differently than kiosks, even if the hardware and operating system are the same. Application variability: Consider what kind of applications run on the device, as well as how often they change and are updated. Geographic distribution: Where is the device located? Do you have dedicated IT and/or security staff there? What is the culture and do you have the ability to monitor and lock it down? Some countries don’t allow device monitoring and some security controls require permission from government organizations, so this must be a consideration as well. Access to sensitive data: Do the users of these devices have access to sensitive and/or protected data? If so you may need to protect them differently. Likewise, a public device in an open area, with no access to corporate networks, may be able to do with much looser security controls. Using these types of attributes you should be able to define a handful (or two) of use cases, which you can use to determine the most appropriate means of protecting each device, trading off security against usability. Let’s list a few of the key use cases where application control fits well. OS Lockdown When an operating system is at the end of its life and no longer receiving security updates, it is a sitting duck. Attackers have free rein to continue finding exploitable defects with no fear of patches to ruin their plans. Windows XP security updates officially end April 2014 – after that organizations still using XP are out of luck. (Like luck has anything to do with it…) We know you wonder why on Earth any organization serious about security – or even not so serious – would still use XP. It is a legitimate question, with reasonable answers. For one, some legacy applications still only run on XP. It may not be worth the investment – or even possible, depending on legal/ownership issues – to migrate to a modern operating system, so on XP they stay. A similar situation arises with compliance requirements to have applications qualified by a government agency. We see this a lot in healthcare, where the OS cannot even be patched without going through a lengthy and painful qualification process. That doesn’t happen, so on XP it stays. Despite Microsoft’s best efforts, XP isn’t going away any time soon. Unfortunately that means XP will still be a common target for attackers, and organizations will have little choice but to protect vulnerable devices somehow. Locking them down may be one of the few viable options. In this situation using application control in default-deny mode, allowing only authorized applications to run, works well. Fixed Function Devices Another use case we see frequently for application control is fixed function devices, such as kiosks running embedded operating systems. Think an ATM or payment station, where you don’t see the underlying operating system. These devices only run a select few applications, built specifically for the device. In this scenario there is no reason for any software besides authorized applications to run. Customers shouldn’t be browsing the Internet on an ATM machine. So application control works well to lock down kiosks. Similarly, some desktop computers in places like call centers and factory floors only run very stable and small sets of applications. Locking them down to run provides protection both from malware and employees loading unauthorized software or stealing data. In both this use case and OS lockdown you will get little to no pushback from employees about their inability to load software. Nothing in their job description indicates they should be loading software or accessing anything but the applications they need to do their jobs. In these scenarios application control is an excellent fit. Servers Another clear use case for application control is on server devices. Servers tend to be dedicated to a handful of functions, so they can be locked down to those specific applications. Servers don’t call the Help Desk to request access to iTunes, and admins can be expected to understand and navigate the validation process when they have a legitimate need for new software. Locking down servers can work very well – especially appealing because servers, as the repository of most sensitive data, are the ultimate target of most attacks. General Purpose Devices There has always been a desire to lock down general-purpose devices, which are among the most frequently compromised.

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