Research

I’m happy to say the holiday season was pretty eventful for the Boss and her family. Her brother (and his wife) welcomed twin boys into the world right after Xmas. The whole process of creating life still astounds, and the idea of two at a time boggles the mind – even if you’ve been through it. Turns out we were up North when the new guys showed up (a week early), so we got to meet them in person. We live 600 miles apart, so that was an unexpected bonus. It also meant there was no shot at all of us attending the Bris. 8-day-old boys provide a little donation to the gods and everybody eats. It’s a festive occasion (for us – for the babies, not so much) and we hated the economic reality that we couldn’t travel to attend in person. But then over the hills we saw a glimmer of hope. Was it a plane? Nope. 5 tickets are just too much money. A train? Nope. Can’t take a day to go back and forth. It’s video conferencing. Sure, Skype is fun to do a little video conference with the grandparents from time to time. It’s also critical when traveling abroad, unless you like $2,000 phone bills. In this case, video allowed us to be at the Bris, from the comfort of our home office. The kids were off from school, and my brother in law set up his web cam to overlook the ceremony. So we all crouched around the computer and watched the ritual. We got to wave a lot and they did a great job of including us in the ceremony. Of course it wasn’t exactly like being there, but it was a hell of a lot better than seeing a few pictures three days later. When my kids were born, our option to do something similar was a $30,000 video conferencing system. You could fly in on the Concorde for less. And my brother in law would have needed a compatible systems as well. Through the wonders of Moore’s Law and the kindness of the bandwidth gods, now we can be anywhere in the world at any time. Now a Bris is not something you need (or even want) to see via a higher fidelity telepresence type environment. But seeing the entire family gathered, and being able to participate ourselves from Atlanta, was amazing. And that’s why the world is getting to be a smaller place every day. Of course I don’t do much video, because Rich and Adrian know what I look like (pretty as that is) and I’d rather not everybody see my 6-day stubble and bunny slippers (my usual work attire). But the technology is invaluable for connecting with those you like (and perhaps especially those you don’t like), when a phone call seems a bit 2-dimensional. Whether Apple’s FaceTime commercials bring a tear to your eye or not, you can’t disregard the experience. Video conferencing is going to happen, and I saw why on Monday. -Mike Photo credits: “It’s a Small World!” originally uploaded by Thomas Hawk Incite 4 U Pen testing obsolete? Hardly… Val Smith laid out some bait regarding whether pen testing is rapidly becoming obsolete. I guess that depends on how you define pen testing. The traditional unsophisticated run of Core or Metasploit with a bunch of glorified monkeys to check the compliance boxes is actually alive and well. PCI will ensure that for years to come. But that clearly not-so-useful practice will become more automated and cheaper, like every other competitive commodity function. But Val’s point at the end is that pen testing is evolving and needs to provide organizations with “a new type of service which tests their infrastructures and security postures in a different way”. That I agree with. There will always be a role for sophisticated white hats to try to break stuff. Maybe we stop calling that pen testing, which is fine by me. As long as you keep trying to break your stuff, call it whatever you want. – MR Don’t hack me, bro! Mocana made news this week when they announced they hacked into Internet TV set top boxes. I don’t think anyone is really surprised by this. The entire set top box / TV as Internet market is the poster boy for feature advancement land grab, with companies furiously vying for a share of Internet TV audiences. But really, who wants to worry about security when all you want is frackin’ TV! Can’t we all just get along? Well, no, not really. I am willing to bet that any security measure beyond a password and some rudimentary session-based encryption never came up in the product design meetings. “Winning the market” is about features, and the winner can clean up the mess later. Or at least that is the attitude I see. But these devices are stripped-down computers. And they use standard networking protocols. In most cases with reduced-footprint variants of standard operating systems. And it’s now attached to your home network. To me, Mocana is just pointing out the obvious, which is that these freakin’ things lack basic security. And it probably did not take anything more than a MitM attack to intercept the credit card, but I am willing to bet they are susceptible to injection as well. Granted, Mocana sells security products to help developers and designers secure these devices, so their PR is self-serving (of course), but this whole segment needs a wake-up call. – AL The name of the game? Reduce scope! I did a customer advisory board meeting for a client last year, and one of the attendees mentioned his specific goal was to reduce his PCI in-scope devices to zero. Right, he wanted to transition all protected data (and the associated processes) to external service providers and make PCI their problem. Certainly a noble goal, but not sure how realistic that is for most organizations. Clearly the trend is towards higher segmentation

As we discussed in our first Mobile Device Security post (I can haz your mobile), supporting smartphones isn’t really an choice. You aren’t going to tell your CEO or any other exec 5-6 pay grades above you that they can’t use their iPad to access the deal documents on that multi-billion dollar acquisition. You know it’s much easier to read an iPad on the can, than to lug the laptop around when taking care of business, right? If you are like most security professionals, your first instinct is to blurt out a resounding no, when presented with a request to connect an Android phone to your network. But your instincts are wrong. That wasn’t a question. It was an order – or soon will be. So your best bet is to practice the deep breathing exercises your meditation guru suggested. Once you’ve gotten your pulse back to a manageable 130, then you can and must have a constructive discussion about what resources are needed on the smartphone and why. User Profiles Are Your Friend The (sometimes fatal) mistake we see most often is treating every user as equivalent to every other user with the same device. This leads to providing the same level of access, regardless of who the user is. Allow us to suggest an alternative: profile users based on what they need to get, define 3-4 user types, and build your policies based on what they need, not what devices they have. For instance, you might have three user types: Executive: These folks can crush you with a stroke of their pen. Okay – a pen is old school. How about a click of their mouse? These people get what they want because saying no is not an option. They should be configured for email and document access, with a VPN client so they can access the corporate network (from the can). Connected Users: There will be another group of users who might have compromising pictures of the executives. Or maybe they actually provide tangible value to your organization. Either way, these folks need access, but probably not to everything. Design the policy to give them only what they need, and nothing more. Everyone else: If a person doesn’t fit into either of the other two buckets, then you give them access, but not enough that they can hurt themselves (or you). That means email, but probably not VPN access to the corporate network. These buckets are just examples – you’ll need to go through the use cases for each type of job function and see what levels of access make sense for your organization. Yes, but… As we mentioned above, your first instinct is likely to say ‘no’ when asked to support smartphones. But let’s tune the verbiage a bit and say “Yes, but” instead. After this easy mantra, go into all the reasons why it’s a bad idea for the user to have smartphone access to the organization’s sensitive stuff. You aren’t telling them no, but you are trying to convince them it’s a bad idea. But let’s acknowledge the truth: you’ll lose and the requestor will get access. The goal of this exercise isn’t necessarily to win the argument (though being able to block someone’s every so often access is good for your self-esteem), but instead to get folks put into the right user profile buckets. Everyone wants access to everything. But we know that’s a bad idea, so success is really more about how many users (as a percentage of all smartphone users) have limited access. That number will vary based on organization, but if it approaches 0% you need to practice “yes, but” a lot more. Cover Your Hind Section The last suggestion we’ll make relative to process is to ensure that you have documented the risks of supporting these devices. It’s critical to understand that our job as security professionals isn’t to stop business from happening – it’s to provide information to the decision makers so they can make rational, educated decisions. That means you need to inform them of the risks of whatever action they are going to take and push them to acknowledge the risk. If you fail to do this, you’ll be the one thrown out of the car at high speed when something goes wrong. Without ensuring clearly, and in writing, that everyone understands all the things that can go wrong by taking a particular action; you’ll end up in the proverbial creek without a paddle. Acknowledge that you won’t like all the decisions. Your job is to protect information and that requires reducing risk. Every company needs to take risks to continue to execute on their business plans. These two goals are diametrically opposed, but at the end of the day, it’s not our job to decide what risks make sense for your business. It’s our job to make sure everyone is clear on what those risks are, and enforce the decisions. As helpful as it is to put users in specific profiles, there are still a number of things you can do technically to protect your organization from the iPocalypse. As we wrap up this series, we’ll go through a few and provide ideas for how to protect your smartphone wielding employees from themselves. Share:

In New Data for New Attacks we discussed why there is usually too much data early in the process. Then we talked about leveraging the right data to alert and trigger the investigative process. But once the incident response process kicks in too much data is rarely the problem, so now let’s dig deeper into the most useful data for the initial stages of incident response. At this early stage, when we don’t yet know what we are dealing with, it’s all about triaging the problem. That usually means confirming the issue with additional data sources and helping to isolate the root cause. We assume that at this stage of investigation a relatively unsophisticated analyst is doing the work. So these investigation patterns can and should be somewhat standard and based on common tools. At this point the analyst is trying to figure out what is being attacked, how the attack is happening, how many devices are involved, and ultimately whether (and what kind of) escalation is required. Once you understand the general concept behind the attack, you can dig a lot deeper with cool forensics tools. But at this point we are trying to figure out where to dig. The best way to stage this discussion is to focus on the initial alert and then what kinds of data would validate the issue and provide the what, how, and how many answers we need at this stage. There are plenty of places we might see the first alert, so let’s go through each in turn. Network If one of your network alerts fires, what then? It becomes all about triangulating the data to pinpoint what devices are in play and what the attack is doing. This kind of process isn’t comprehensive, but should represent the kinds of additional data you’d look for and why. Attack path: The first thing you’ll do is check out the network map and figure out if there is a geographic or segment focus to the network alerts. Basically you are trying to figure out what is under attack and how. Is this a targeted attack, where only specific addresses are generating the funky network traffic? Or is it reconnaissance that may indicate some kind of worm proliferating? Or is it command and control traffic, which might indicate zombies or persistent attackers? Device events/logs/configurations: Once we know what IP addresses are in play, we can dig into those specific devices and figure out what is happening and/or what changed. At this stage of investigation we are looking for obvious stuff. New accounts or executables, or configuration changes, are typical indications of some kind of issue with the device. For the sake of both automation and integrity, this data tends to be centrally stored in one or more system management platforms (SIEM, CMDB, Endpoint Protection Platform, Database Activity Monitor, etc.). Egress path and data: Finally, we want to figure out what information is leaving your network and (presumably) going into the hands of the bad guys, and how. While we aren’t concerned with a full analysis of every line item, we want a general sense of what’s headed out the door and an understanding of how it’s being exfiltrated. Endpoint The endpoint may alert first if it’s some kind of drive-by download or targeted social engineering attack. You also can have this kind of activity in the event of a mobile device doing something bad outside your network, then connecting to your internal network and wreaking havoc. Endpoint logs/configurations: Once you receive an alert that there is something funky happening on an endpoint, the first thing you do is investigate the device to figure out what’s happening. You are looking for new executables on the device or a configuration change that indicates a compromise. Network traffic: Another place to look when you get an endpoint alert is the network traffic originating from and terminating on the device. Analyzing that traffic can give you an idea of what is being targeted. Is it a back-end data store? Is it other devices? How and where is the device is getting instructions? Also be aware of exfiltration activities, which indicate not only a successful compromise, but also a breach. The objective is to profile the attack and understand the objective and tactics. Application targets: Likewise, if it’s obvious a back-end datastore is being targeted, you can look at the transaction stream to decipher what the objective is and how widely has the attack spread. You also need to understand the target to figure out whether and how remediation should occur. Upper Layers If the first indication of an attack happens at the application layer (including databases, application servers, DLP, etc.) – which happens more and more, due to the nature of application-oriented attacks – then it’s about quickly understanding the degree of compromise and watching for data loss. Network traffic: Application attacks are often all about stealing data, so at the network layer you are looking primarily for signs of exfiltration. Secondarily, understanding the attack path will help discover which devices are compromised, and understand short and longer term remediation options. Application changes Is your application functioning normally? Or is the bad guy inserting malware on pages to compromise your customers? While you won’t perform a full application assessment at this point, you need to look for key indicators of the bad guy’s activities that might not show up through network monitoring. Device events/logs/configurations: As with the other scenarios, understanding to what degree the devices involved in the application stack are compromised is important for damage assessment. Content monitors: Given the focus of most application attacks on data theft, you’ll want to consult your content monitors (DLP, as well as outbound web and email filters) to gauge whether the attack has compromised data and to what degree. This information is critical for determining the amount of escalation required. Incident Playbook Obviously there are infinite combinations of data you can look at to figure out what is going on (and