Research

I’ve had a bit of a weird week. As I mentioned on Monday, I was driving to physical therapy (physio for my Australian and European friends) when there was an accident in front of me and I stopped to help out. Wednesday night I was coming home from PT and there was another accident right as I was going through the intersection. This one was far more serious. As soon as I heard the smash and saw the impact out of the corner of my eye, I pulled into the median, hit my hazard lights, and called 9-1-1. One of the advantages of working in the field for so long is that you learn an economy of words to describe a complex situation in just a sentence or two of the crucial information. My first call was: I’m on-scene of an injury accident at the corner of [x and y]. Two vehicles, with an unconscious unresponsive patient with a compromised airway. Patient is entrapped in the passenger side of the vehicle with access through the driver’s side door. I’m a former paramedic and need to go manage her airway There was a bit more jargon, but not much. The patient was unrestrained in the car with the airbag deployed, which probably meant she hit her head on the passenger window or strut since it was a side impact. There were a bunch of other bystanders and one came out and identified himself as a flight nurse. Her head was slumped over, which caused her difficulty breathing. The nurse jumped in the back of the car, we tilted her head to a normal position and stabilized her neck (one of the few times you’re allowed to move the neck after an accident). Her breathing got better, and she slowly started waking up, but clearly had a head injury, which we reported to 9-1-1. The fire department showed up a few minutes later, we got out of the way, and she was being loaded into the chopper as I drove off. That might be one of the only times I’ve stopped to help at an accident where my assistance may have mattered. Truth is, unless you’re on the ambulance or have advanced equipment with you, the most useful thing you can do is calm the patient and make sure there isn’t any more damage. The kinds of injuries you sustain in a major accident are rarely something even a highly trained bystander can help with. I didn’t even bother evaluating anything more than her breathing, since nothing else mattered. All you EMTs can skip that full survey if you’re helping as a bystander in an urban area. In this case her head position was keeping her from breathing well, making the situation worse. Just moving it so she could breathe more normally might have oxygenated her noggin a bit more and helped her wake up. Why the heck am I talking about this on a security geek blog? Because it’s one of those times where there are direct lessons we can apply to our world, and often forget. I’m a big fan of Rothman’s philosophy of REACT FASTER. The idea is that it’s more about how you respond to an incident than having the incident in the first place. Truth is in IT, as in life, bad stuff will happen no matter what you do. Systems will crash, hard drives will die, and hackers will break in. David Mortman is one of the other major proponents of this philosophy- incident response is just as important, if not more important, than incident prevention. That’s why I’m adding REACT BETTER. Emergency services are just like programming- a series of algorithms in a structured program flow. It all comes down to the A B Cs- Airway, Breathing, Circulation- in meat-space. Patient have any airway? Nope? Then nothing else matters until you fix that. Breathing? Check. Circulation okay? Then move on to spinal immobilization. It’s a recognition that you can’t jump from A to C and expect success. It’s exactly what we did to help that girl in the car, rather than focusing on the blood or other distractions. Don’t just react- have a response plan with specific steps you don’t jump over until they’re complete. Take the most critical thing first, fix it, move to the next, and so on until you’re done. Evaluate, prioritize, contain, fix, and clean. (You OODA fans should love this). And always remember the loudest patient is rarely the most important. If they’re screaming their head off, their airway is fine. It’s the quiet ones you have to watch out for. Share:

In our last post we finished our review of DLP content discovery best practices by discussion rolling out and maintaining your deployment. Today we’re going to focus on a couple of use cases that illustrate how it all works together. I’m writing these as fake case studies, which is probably really obvious considering my lack of creativity in the names. DLP Content Discovery for Risk Reduction and to Support PCI Audit RetailSportsCo is a mid-sized online and brick-and-mortar sporting goods retailer, with about 4,000 headquarters employees and another 2,000 retail employees, across 50 locations. They classify as a Level 2 merchant due to their credit card transaction volume and are currently PCI complaint, but struggled through the process and ended up getting a series of compensating controls approved by their auditor, but only for their first year. During the audit it was discovered that credit card information had proliferated uncontrolled throughout the organization. It was scattered through hundreds of files on dozens of servers; mostly Excel spreadsheets and Access databases used, and later ignored, by different business units. Since storage of unencrypted credit card numbers is prohibited by PCI, their auditor required them to remove or secure these files. Audit costs for the first year increased significantly due to the time spent by the auditor validating that the information was destroyed or secured. RetailSportsCo purchased a DLP solution and created a discovery policy to locate credit card information across all storage repositories and employee systems. The policy was initially deployed against the customer relations business unit servers, where over 75 files containing credit card numbers were discovered. After consultation with the manager of the department and employee notification, the tool was switched into enforcement mode and all these files were quarantined back into an encrypted repository. In phase 2 of the project, DLP endpoint agents were installed on the laptops of sales and customer relations employees (about 100 employees). Users and managers were educated, and the tool discovered and removed approximately 150 additional files. Phase 3 added coverage of all known storage repositories at corporate headquarters. Phase 4 expanded scanning to storage at retail locations, over a period of 5 months. The final phase will add coverage of all employee systems in the first few months of the coming year, leveraging their workstation configuration management system for a scaled deployment. Audit reports were generated showing exactly which systems were scanned, what was found, and how it was removed or protected. Their auditor accepted the report, which reduced audit time and costs materially (more than the total cost of the DLP solution). One goal of the project is to scan the entire enterprise at least once a quarter, with critical systems scanned on either a daily or weekly basis. RetailSportsCo has improved security and reduced risk by reducing the potential number of targets, and reduced compliance costs by being able to provide auditors with acceptable reports demonstrating compliance. DLP Content Discovery to Reduce Competitive Risk (Industrial Espionage) EngineeringCo is a large high-technology manufacturer of consumer goods with 51,000 employees. In the past they’ve suffered from industrial espionage, when the engineering plans for new and existing products were stolen. They also suffered a rash of unintentional exposures and product plans were accidentally placed in public locations, including the corporate website. EngineeringCo acquired a DLP content discovery solution to reduce these exposure risks and protect their intellectual property. Their initial goal was to reduce the risk of exposure of engineering and product plans. Unlike RetailSportsCo, they decided to start with endpoints, then move into scanning enterprise storage repositories. Since copies of all engineering and product plans reside in the enterprise content management system, they chose a DLP solution that could integrate and continuously monitor selected locations and automatically build partial-document matching policies for all documents. The policy was tested and refined to ignore common language in the files, such as corporate headers and footers, which initially caused every document using the corporate template to register in the DLP tool. EngineeringCo started with a phased deployment to install the DLP endpoint discovery agent on all corporate systems. In phase 1, the tool was rolled out to 100 systems per week, starting with product development teams. The initial policy allowed those teams access to the sensitive information, but documented what was on their systems. Those reports were later mated to their encryption tool to ensure that no unencrypted laptops hold the sensitive data. Phase 2 expanded deployment to the broader enterprise, initially in alerting mode. After 90 days the product was switched into enforcement mode and any identified content outside of the product development teams was quarantined with an alert sent to the user, who could request an exemption. Initial alert rates were high, but user education reduced levels to only a dozen or so “violations” a week during the 90-day grace period. In the coming year EngineeringCo plans to refine their policy to restrict product development employees from placing registered documents onto portable storage. The network component of their DLP tool already restricts emailing and other file transfers outside of the enterprise. They also plan on adding policies to protect employee healthcare information and customer account information. These are, of course, fictional best practices examples, but they’re drawn from discussions with dozens of DLP clients. The key takeaways are: Start small, with a few simple policies and a limited scanning footprint. Grow deployments as you reduce incidents/violations to keep your incident queue under control and educate employees. Start with monitoring/alerting and employee educations, then move on to enforcement. This is risk reduction, not risk elimination. Use the tool to identify and reduce exposures but don’t expect it to magically solve all your data security problems. When you add new policies, test first with a limited audience before rolling them out to the entire scope, even if you are already covering the entire enterprise with other policies. Share:

Chris Pepper, Master Editor, pointed out something I missed. If you memorize an encrypted network, your iPhone won’t connect to an unencrypted one with the same name, or one with a different password. Thus unless the bad guy knows your WPA passphrase (you’re not dumb enough to use WEP, are you?), you can memorize your home network and not worry about accidentally connecting while wandering around, even if it’s still called “tsunami”. Share:

In Part 3 of our series we finished our review of the technical architecture and selection; now we’re going to delve into best practices for deployment. We will focus on setting expectations, prioritization, and defining your internal processes. The main obstacle to successful deployments isn’t a technology weakness, but rather the failure of the enterprise to understand what to protect, decide how to protect it, and recognize what’s reasonable in a real-world environment. Setting Expectations The single most important factor for any successful DLP deployment – content discovery or otherwise – is properly setting expectations at the start of the project. DLP tools are powerful, but far from a magic bullet or black box that makes all data completely secure. When setting expectations you need to pull key stakeholders together in a single room and define what’s achievable with your solution. All discussion at this point assumes you’ve already selected a tool. Some of these practices deliberately overlap steps during the selection process since at this point you’ll have a much clearer understanding of the capabilities of your chosen tool. In this phase, you discuss and define the following: What kinds of content you can protect, based on the content analysis capabilities of your tool. Expected accuracy rates for those different kinds of content; for example, you’ll have a much higher false positive rate with statistical/conceptual techniques than partial document or database matching. Protection options: Can you encrypt? Move files? Change access controls? Performance, based on scanning techniques. How much of the infrastructure you’d like to cover (which servers, endpoints, and other storage repositories). Scanning frequency (days? hours? near continuous?). Reporting and workflow capabilities. It’s extremely important to start defining a phased implementation. It’s completely unrealistic to expect to monitor every nook and cranny of your infrastructure with your initial rollout. Nearly every organization finds they are more successful with a controlled, staged rollout that slowly expands breadth of infrastructure coverage and types of content to protect. Prioritization If you haven’t already prioritized your information during the selection process, you need to pull all major stakeholders together (business units, legal, compliance, security, IT, HR, etc.) and determine which kinds of information are more important, and which to protect first. I recommend you first rank major information types (e.g., customer PII, employee PII, engineering plans, corporate financials), then re-order them based on priority for monitoring/protecting within your DLP content discovery tool. In an ideal world your prioritization should directly align with the order of protection, but while some data might be more important to the organization (engineering plans) other data may need to be protected first due to exposure or regulatory requirements (PII). You’ll also need to tweak the order based on the capabilities of your tool. After your prioritize information types to protect, run through and determine approximate timelines for deploying content policies for each type. Be realistic, and understand that you’ll need to both tune new policies and leave time for the organizational to become comfortable with any required business changes. We’ll look further at how to roll out policies and what to expect in terms of deployment times later in this series. Define Process DLP tools are, by their very nature, intrusive. Not in terms of breaking things, but intrusive in terms of the depth and breadth of what they find. Organizations are strongly advised to define their business processes for dealing with DLP policy creation and violations before turning on the tools. Here’s a sample of a process for defining new policies: Business unit requests policy from DLP team to protect content type. DLP team meets with business unit to determine goals and protection requirements. DLP team engages with legal/compliance to determine any legal or contractual requirements or limitations. DLP team defines draft policy. Draft policy tested in monitoring (alert only) mode without full workflow and tuned to acceptable accuracy. DLP team defines workflow for selected policy. DLP team reviews final policy and workflow with business unit to confirm needs have been met. Appropriate business units notified of new policy and any required changes in business processes. Policy deployed in production environment in monitoring mode, but will full workflow enabled. Protection certified as stable. Protection/enforcement actions enabled. And here’s one for policy violations: Violation detected; appears in incident handling queue. Incident handler confirms incident and severity. If action required, incident handler escalates and opens investigation. Business unit contact for triggered policy notified. Incident evaluated. Protective actions taken. If file moved/protected, notify user and drop placeholder file with contact information. Notify employee manager and HR if corrective actions required. Perform required employee education. Close incident. These are, of course, just rough samples in text form, but they should give you a good idea of where to start. Share:

I was driving around listening to Car Talk on NPR this weekend, and it was an incredibly insightful lesson on risk tolerance and risk perception. I tend to do a lot of errands over the weekend around that time, so I usually catch 20-40 minutes of it every week as I’m in and out of stores. Pretty much every week you’ll hear things like: Caller: My car’s making this grinding noise when I accelerate. CT: How long has this been going on? Caller: About a year or so. CT: And why didn’t you take it in? Caller: I’m worried it will be too expensive to fix. Gee, that sounds familiar. Or these calls: Caller: My engine feels like it’s running slow or something. CT: Is the check engine light on? Caller: Why yes, how did you know? CT: And let me guess, it’s been on for three months? Caller: Okay, who called and told you? CT: No one [Click and Clack laugh]. So why didn’t you check the engine? Caller: I’m scared it will be expensive. Then there are these calls: [long discussion figuring out the problem] Caller: So I just need to take it in and get it fixed? CT: Yep, that’s it. Caller: Will it be expensive? CT: Maybe, about [x dollars], but it will be a lot more expensive later if you don’t. Caller: Oh, that’s a lot. Do you think I’ll be okay if I don’t get it fixed? CT: As long as you don’t need a car, you’ll be fine. Think about all those cavities you could have avoided by going to the dentist on a regular basis, or that big air conditioning repair you could have skipped if you just performed the annual maintenance on time. Then stop complaining that your users “just don’t get it,” or stop whining about the business ignoring you. Share:

Update: See Update To The iPhone Security Tip. Encrypted networks are safe to remember. The other day I was wandering around San Francisco on a work trip, and I freaked out when I noticed the WiFi indicator on my iPhone was showing an active connection to some random network. I never have my phone set to connect to unknown networks, so I quickly jumped into the settings to see what the heck was going on. Turns out I was connected to “tsunami” which is a common default name on Cisco wireless gear. Like the Cisco gear in our community center, which just a week or so before I was playing with. And that got me thinking. Many of you probably connect to wireless networks with common names- like Linksys, 2WIRExx, tsunami, or whatever. In other words, either default networks, or names (like those used at conferences and airports) that are in common use or easy to find. But when you remember those on your iPhone (or computer for that sake), it only remembers the network ID (SSID), not that actual network! Your iPhone doesn’t know the difference between “tsunami” in your community center, “tsunami” in an office building, and “tsunami” running on some bad guy’s laptop to see what naive fools will connect to it. When you trust a network you’re just trusting a name anyone can use, not something really unique to that network. Your iPhone will then connect to any network using that name. Why is that bad? Go read this article I wrote at Dark Reading. An attacker can set up his or her laptop to broadcast that name, then perform a man in the middle attack to anyone who connects. They can sniff and modify any traffic going to your iPhone. Why is this more serious on an iPhone than your laptop? Because you walk around with your phone all the time, often checking things like email in the background. Another problem with the iPhone is that its VPN doesn’t automatically reconnect if the connection drops. Thus, even if you connect via a secure VPN, you might find your connection got dropped and your phone happily continues, sending all your traffic unencrypted. Here are my best practices for iPhone wireless security: Turn on “Ask to join networks”. If you have a home wireless network, use an obscure name with some random numbers in it. This reduces the odds you’ll ever hit another one with the same name unless someone specifically targets you. On your home network, don’t broadcast the SSID (sure, easy to figure out, but we’re just trying to reduce our risks). If you need to connect to a public wireless network, use a VPN to protect your traffic. In the VPN settings, after you configure your connection, turn on the “Send all traffic” option. When you’re done with the network, click on the “Forget this network” button in your WiFi settings. On my phone I only have it set to connect at home (a weird name), and I use AT&T EDGE when I’m out of my house. I have a VPN server set up at home for those rare occasions I connect from a conference network. The good news is that your iPhone doesn’t send out “probes” for known networks. This would be an easy way for a bad guy to know even those obscure SSIDs you use at home. Good move on Apple’s part- now I just want them to make the VPN connections persistent. Share:

Had another one of those real world experiences today that was just begging for a blog post. A couple hours ago I was driving down the highway on my way to my physical therapy appointment when I saw a rollover car accident on the side of the road near an on-ramp. There were a bunch of bystanders, but the first police officer was just pulling up and there was no fire or ambulance in sight. There is some good news and some bad news if you get in an accident by that particular on-ramp. The good news is it’s right down the road from the Mayo clinic. The bad news is a lot of doctors drive on and off that ramp at any given moment. Very few of them work in the emergency department. I first became an EMT in 1990, went on to become a full-time paramedic, and have dabbled in everything from ski patrol to mountain rescue to HAZMAT over the years. I’m still an EMT, although not doing much with it since moving to Phoenix. If I’d knocked someone up when I got certified they’d be getting ready for college right about now. That is, to be honest, a little scary. Since no responders were on scene yet I identified myself and asked if they needed help. The other bystanders, including the first doctor, stepped back (she was calling the patient’s parents). The patient was looking okay, but not great, crying and complaining about neck and head pain. She did not remember the accident. The next bit went like this: DAD (Dumb Ass Doctor): Here, let’s put this under her head [holding rolled-up jacket] Me: Sir, we don’t want to do that. DAD: I’m a doctor. It’s fine, she was walking around [Note, most patients who scramble out of their overturned car through the missing windshield wander around a little bit until someone sits them down.] Me: What kind of doctor? DAD: Anesthesiologist. Trauma anesthesiologist. It’s fine. [Note, that means he puts trauma patients to sleep in an operating room so a surgeon can fix them.] Me: Sir, we have a patient complaining of head and neck pain with a loss of consciousness; you do NOT want to manipulate her head. DAD: I’m a doctor [inserts pillow, as patient cries out from the pain]. Gee [other doc’s name] don’t you remember that emergency training and the chain of command? Me: You’re the doctor, can you gossip with your friends and stand over there now while I make sure she can still move? For the record, I’ve never met an ER doctor in the world that will clear a patient’s c-spine in the field with that mechanism (a rollover) and pain on touch and movement. I would never pretend to be able to anesthetize a patient, but this bozo, like many doctors, thinks he’s fully capable of directing field treatment completely outside his experience. Here’s the thing;as professionals we train hard at becoming experts in a particular domain. This doesn’t make us experts in adjacent domains. For example, I may be a security expert, but despite some broad knowledge I’ve specialized in certain areas, like information-centric security. If, for example, you needed me to read your IDS logs or deploy your UTM I’d send you to someone with practical network security knowledge. When doing risk assessments or practical, on-the-ground security, make sure you engage the right domain experts before you break something. You may have kung-fu, but that doesn’t mean you aren’t a total freaking idiot. Share:

It took a little longer than expected, thanks to me being totally swamped post-surgery until now, but let’s congratulate our winners of a free year of Debix identity theft protection: myemailisvalid, Jay, and Brett. Thanks for participating, and you’ll be hearing from us via email. Share:

I was reading one of Alan’s posts over at StillSecure, based on the Lending Tree debacle. He starts with a bit I totally agree with: This sort of stealing your competitors information has been going on for decades, well before computers and cybercrime were around. However, this is a great example of some things not going out of style. Obtaining your competitors information is a great motive, computers are just the container where the information is kept. This is something I’ve been harping on for a while- the only new thing about cybercrime is the vector; nearly every crime we see has a corollary in the physical world. Why? Because we’ve been screwing each other over since before we were technically humans. We’ve been taking things that don’t belong to us since far before we had any concept of commerce or society. That’s tens of thousands, if not hundreds of thousands, of years of criminal refinement. Nigerian 419 scam? It’s the Spanish Prisoner. DoS? It’s sabotage or a protection racket. You name the cybercrime, and I can name the pre-cyber-crime. Now how does this practically apply to how security professionals do their job? Focus on the crime, not the tech. When you’re piecing together your defenses, monitoring for incidents, or cleaning up a mess, always remember that someone attacked for a reason. If they didn’t steal something, hijack an asset for their own use, trespass for the fun of it, or vandalize/break something, keep looking. Odds are you still haven’t figured out why they are there, and what the real target is, and your day ain’t over yet. A person may change, but people don’t. Share:

I know what’s running through your head right now. “WTF?!? Mogull’s totally lost it. Isn’t he that data/information-centric security dude?” Yes I am (the info-centric guy, not the insane bit), and here’s the thing: The concept that you can run around, analyze, and tag your data throughout the enterprise, then keep it current through changing business contexts and requirements, is totally ridiculous. Sure, we have tools today that can scan our environment and tag files based on policies, but that just applies a static classification in a dynamic environment. I have yet to talk with a customer that really does enterprise-wide data classification successfully except for a few, discrete bits of data (like credit card numbers). The truth is that’s data identification, not data classification. Enterprise content is just too volatile for static tags to really represent its value. Even those of you in defense/intelligence don’t really do granular data classification. You just hit things with a big sledgehammer. “Is it Top Secret? Then we keep it totally isolated. What, this bit isn’t Top Secret but it’s on a Top Secret server? Frack it, we’ll just make it all Top Secret and be done with it. Need to pull it out? Go fill out this form.” This post was inspired by a conversation yesterday where another information-centric wonk criticized the idea that data can be self-describing in any meaningful way, part of my principles of information centric security. While he caught the first point, he missed my meaning in the second point (policies and controls must account for business context) which means that the data self describes in such a way that business context can then be applied to determine value in that situation. I know it sounds like science fiction, but we’re starting to see real-world scenarios, and I’ll be the first to admit this is going to be a big area of advance over the next few years. Now there is one piece of data classification that isn’t dead (I like sensational headlines just like the next person). That’s the business process of prioritizing information. That’s where you sit down with business executives and determine what information is more valuable than other information for your organization. It will drive all the protective strategies and dynamic protections we talk about when applying information-centric security. That’s absolutely vital to successful information security. Thus we prioritize and identify information, but this is different than data classification, which is the concept that after these two steps, we can apply static labels as a way of protecting information. That, my friend, is not only dead, it was never really alive. Share: