Research

Fall of 2009 marks the 20th anniversary of the start of my professional security career. That was the first day someone stuck a yellow shirt on my back and sent me into a crowd of drunk college football fans at the University of Colorado (later famous for its student riots). I’m pretty sure someone screwed up, since it was my first day on the job and I was assigned a rover position – which normally goes to someone who knows what the f&%$ they are doing, not some 18 year old, 135-lb kid right out of high school. And yes, I was breaking up fights on my first day (the stadium wasn’t dry until a few years later). If you asked me then, I never would have guessed I’d spend the next couple decades working through the security ranks, eventually letting my teenage geek/hacker side take over. Over that time I’ve come to rely on the following guiding principles in everything from designing my personal security to giving advice to clients: Don’t expect human behavior to change. Ever. You cannot survive with defense alone. Not all threats are equal, and all checklists are wrong. You cannot eliminate all vulnerabilities. You will be breached. There’s a positive side to each of these negative principles: Design security controls that account for human behavior. Study cognitive science and practical psychology to support your decisions. This is also critical for gaining support for security initiatives, not just design of individual controls. Engage in intelligence and counter-threat operations to the best of your ability. Once an attack has started, your first line of security has already failed. Use checklists to remember the simple stuff, but any real security must be designed using a risk-based approach. As a corollary, you can’t implement risk-based security if you don’t really understand the risks; and most people don’t understand the risks. Be the expert. Adopt anti-exploitation wherever possible. Vulnerability-driven security is always behind the threat. React faster and better. Incident response is more important than any other single security control. With one final piece of advice – keep it simple and pragmatic. And after 20 years, that’s all I’ve got… Share:

One of the more difficult aspects of medical research is correlating treatments/actions with outcomes. This is a core principle of science based medicine (if you’ve never worked in the medical field, you might be shocked at the lack of science at the practitioner level). When performing medical studies the results aren’t always clean cut. There are practical and ethical limits to how certain studies can be performed, and organisms like people are so complex, living in an uncontrolled environment, that results are rarely cut and dried. Three categories of studies are: Pre-clinical/biological: lab research on cells, animals, or other subsystems to test the basic science. For example, exposing a single cell to a drug to assess the response. Experimental/clinical: a broad classification for studies where treatments are tested on patients with control groups, specific monitoring criteria, and attempts to control and monitor for environmental effects. The classic double blind study is an example. Observational studies: observing, without testing specific treatments. For example, observational studies show that autism rates have not increased over time by measuring autism rates of different age groups using a single diagnostic criteria. With rates holding steady at 1% for all living age groups, the conclusion is that while there is a perception of increasing autism, at most it’s an increase in diagnosis rates, likely due to greater awareness and testing for autism. No single class of study is typically definitive, so much of medicine is based on correlating multiple studies to draw conclusions. A drug that works in the lab might not work in a clinical study, or one showing positive results in a clinical study might fail to show desired long-term outcomes. For example, the press was recently full of stories that the latest research showed little to no improvement in long-term patent outcomes due to routine mammograms for patients without risk factors before the age of 50. When studies focus on the effectiveness of mammograms detecting early tumors, they show positive results. But these results do not correlate with improvements in long-term patient outcomes. Touchy stuff, but there are many studies all over medicine and other areas of science where positive research results don’t necessarily correlate with positive outcomes. We face the same situation with security, and the recent debate over password rotation highlights (see a post here at Securosis, Russell Thomas’s more-detailed analysis, and Pete Lindstrom’s take). Read through the comments and you will see that we have good tools to measure how easy or hard it is to crack a password based on how it was encrypted/hashed, length, use of dictionary words, and so on, but none of those necessarily predict or correlate with outcomes. None of that research answers the question, “How often does 90 day password rotation prevent an incident, or in what percentage of incidents did lack of password rotation lead to exploitation?” Technically, even those questions don’t relate to outcomes, since we aren’t assessing the damage associated with the exploitation (due to the lack of password rotation), which is what we’d all really like to know. When evaluating security, I think wherever possible we should focus on correlating, to the best of our ability, security controls with outcomes. Studies like the Verizon Data Breach Report are starting to improve our ability to draw these conclusions and make more informed risk assessments. This isn’t one of those “you’re doing it wrong” posts. I believe that we have generally lacked the right data to take this approach, but that’s quickly changing, and we should take full advantage of the opportunity. Share:

On Friday I asked a simple question over Twitter and then let myself get dragged into a rat-hole of a debate that had people pulling out popcorn and checking the latest odds in Vegas. (Not the odds on who would win – that was clear – but rather on the potential for real bloodshed). And while the debate strayed from my original question, it highlighted a major problem we often have in the security industry (and probably the rest of life, but I’m not qualified to talk about that). A common logical fallacy is to assume that a possibility is a probability. That because something can happen, it will happen. It’s as if we tend to forget that the likelihood something will happen (under the circumstances in question) is essential to the risk equation – be it quantitative, qualitative, or whatever. Throughout the security industry we continually burn our intellectual capital by emphasizing low-probability events. “Mac malware might happen so all Mac users should buy antivirus or they’re smug and complacent”. Forgetting the fact that the odds of an average Mac user being infected by any type of malware are so low as to be unmeasurable, and lower than their system breaking due to problems with AV software. Sure, it might change. It will probably change; but we can’t predict that with any certainty and until then our response should match the actual (current) risk. Bluetooth attacks are another example. Possible? Sure. Probable? Not unless you’re at a security or hacker conference. There are times, especially during scenario planning, to assume that anything that can happen will happen. But when designing your actual security we can’t equate all threats. Possible isn’t probable. The mere possibility of something is rarely a good reason to make a security investment. Share:

I had one of those weird moments today where I found an unrelated part of my life unexpectedly influenced by my martial arts background. I was asked to critique a research paper by someone I haven’t worked with before. Without going into details, this particular paper had a fatal flaw. It opened with a negative position, then attempted to justify the positive. It started defensively, and in the process lent credence to the opposing view, as opposed to strengthening the author’s position. In other words, it started with, “here’s what you say about X, and why I think Y” as opposed to, “here is position Y, and why it is correct and X is wrong”. In advising the author, I remembered a lesson I learned when I first started teaching martial arts (traditional taekwondo). I was giving a class on unarmed restraint techniques, which adapted some experiences in physical security to martial arts. They’re similar to police restraint techniques, but adjusted for not having a firearm (police techniques involve protecting the firearm so the bad guy can’t grab it while being restrained) or handcuffs. In the class were two of my instructors, helping me learn to teach. I started by saying something like, “I’m no expert”, and one of them walked off right then and there. At a break he came back and asked if I knew why he had left. He told me to never start a lesson or debate by disqualifying myself as an authority. I essentially told the class they shouldn’t listen to me, because I didn’t know what the frack I was talking about. Self-deprecating humor, applied appropriately, is fine – but never start from a position of weakness. I was trying to be humble, but instead destroyed any reason someone would want to learn from me. Over time I expanded this lesson to “Never start with a negative when your goal is to prove a positive.” Essentially, that places the opposing view ahead of yours and forces you into a defensive position. If I’m writing research to show the value of DLP, I sure as heck better not start it with all the criticisms against DLP. It’s kind of like a fight. If you allow the opponent to control the ring and dictate the pace, your odds of winning are much lower. You can never win on defense alone. One important corollary is that you also shouldn’t expect someone to agree with your position based on your credentials alone. I get seriously annoyed by other analysts/pundits who make pronouncements, yet never back them with evidence. Start from a position of strength (assuming you are the expert), but also lead the reader, with evidence and logic, to reach your conclusions for themselves. Most black belts are crappy martial artists and teachers… if their techniques suck, find another one. Respect still needs to be earned. Enough with the preachy stuff… On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading article on What IBM’s Acquisition of Guardium Really Means. Rich was quoted on Scottrade regarding Rapid7. Adrian was quoted by Information Security Magazine, PC Magazine, The Boston Globe, Network World, and Dark Reading on IBM’s acquisition of Guardium. Rich was picked up a bunch on the Bit.ly security additions, including this mention at eWeek. Episode 175 of The Network Security Podcast. Favorite Securosis Posts Rich: Adrian on Top Questions Regarding Guardium Acquisition Adrian: Rich’s post on Coming Soon: Bit.ly Adding Real Time Security Scanning for All Links. Mort: Quick Thoughts on the Point of Sale Security Fail Lawsuit Meier: Quick Thoughts on the Point of Sale Security Fail Lawsuit – I’ve personally found a few PoS with card readers wide open at Mom ‘n’ Pop shops. Other Securosis Posts Sign Up To Drop Comment Moderation Cloud Risk Thoughts: Deciding What, When, and How to Move to the Cloud Serious Flaw in Clientless SSL VPNs & Clientless SSL VPN Redux Christmas Wish Guardium Acquired by IBM We Give Thanks M86 Acquires Finjan Microsoft IE Issues Reported Health Net Asked to Explain Disclosure Delay Project Quant for Databases: Project Quant: Database Security Planning, Part 2 (part 3) Project Quant: Database Security Planning (part 2) Project Quant: Database Security Process Framework (part 1) Favorite Outside Posts Rich: What the Black Screen of Death Story Says About Journalism. Serious fail on the part of PrevX – they should be ashamed, and have just destroyed any reason for people to trust them. Adrian: It’s Homeric in length for a blog post, but Hoff’s post The Cloud in Context is a great overview of Cloud computing. Mort: Real Security Is Threat-Centric. Not seeing this change anytime soon, alas. Meier: Used ATM Machines for sale on Craigslist. My new weekend hobby! Pepper: Recommendation: Disable Invisible Flash. Flash cookies are evil. Rich #2: This is a must-read article on how few breaches really get reported. The winning quote: “Of the thousands of cases that we’ve investigated, the public knows about a handful,” said Shawn Henry, assistant director for the Federal Bureau of Investigation’s Cyber Division. “There are million-dollar cases that nobody knows about.” Top News and Posts Google launches public DNS resolvers. I use EasyDNS for this myself, being a bit paranoid about the power Google is accumulating. But they do have an excellent privacy policy for this service. Researcher busts into Twitter via SSL reneg hole And they said it couldn’t be done! 79 million records exposed in government breaches. We were named one of the top analyst blogs. Two security tools for analyzing relationships in social networks. More on the Rybolov Information Security Management Model. Layer8: BSOFH: the roar of the packets, the smell of the cloud. True stupidity: woman calls in a fake bomb threat to delay a plane. From the TSA blog. Ray Wagner from Gartner on personal security at work. Hackers attempt to take $1.3M from small business account. If you are in security, and don’t understand the ACH system, it’s time to educate yourself. Users aren’t the weakest link if your security sucks. Cool password research from Microsoft. Blog Comment of the Week This week’s best comment comes from David in response to Quick Thoughts on the Point of Sale

I’ve been working with the Cloud Security Alliance on the next revision of their official Security Guidance document, and we decided to include a short note on risk in the beginning, to help add some context. Although we are deep in the editorial process, I realized this is the sort of thing I should put out for some public comment, as it’s at the beginning of the document and will help frame how it’s read. With so many different cloud deployment options – including SaaS vs. PaaS vs. IaaS, public vs. private, internal vs. external, and various hybrid scenarios – no list of security controls can cover all circumstances. As with any security area, organizations should adopt a risk-based approach to moving to the cloud and selecting security options. The following is a simple framework to help evaluate initial cloud risks and inform security decisions. This process is not a full risk assessment framework, nor a methodology for determining all your security requirements. It’s a quick mechanism for evaluating your tolerance for moving an asset to various different cloud computing models. There is a full section on risk management in the Guidance, and I’m also working on a data security specific post to mesh with the other cloud data security content I’m developing. Identify the asset for the cloud deployment At the simplest, assets supported by the cloud fall into two general buckets: Data Applications/Functions/Processes We are either moving information into the cloud, or transactions/processing (from partial functions, all the way up to full applications). With cloud computing our data and applications don’t need to reside in the same location, and we can even shift only parts of functions to the cloud. For example, we can host our application and data in our own data center, while still outsourcing a portion of its functionality to the cloud through a Platform as a Service. The first step in evaluating risk for the cloud is to determine exactly what data or function is being considered for the cloud. This should include potential uses of the asset once it moves to the cloud, to account for scope creep. Data and transaction volumes are often higher than expected, and cloud deployments often scale higher than anticipated. Evaluate the asset The next step is to determine how important the data or function is to the organization. You don’t need to perform a detailed valuation exercise unless your organization has a process for that, but you do need at least a rough assessment of how sensitive an asset is, and how important an application/function/process is. For each asset, ask the following questions: How would we be harmed if the asset became public and widely distributed? How would we be harmed if an employee of our cloud provider accessed the asset? How would we be harmed if the process or function was manipulated by an outsider? How would we be harmed if the process or function failed to provide expected results? How would we be harmed if the information/data was unexpectedly changed? How would we be harmed if the asset was unavailable for a period of time? Essentially we are assessing confidentiality, integrity, and availability requirements for the asset; and how those are affected if all or part of the asset is handled in the cloud. It’s very similar to assessing a potential outsourcing project, except that with cloud computing we also have a wider array of deployment options including internal models. Map the asset to potential cloud deployment models Now we should have an understanding of the asset’s importance. Our next step is to determine which deployment models we are comfortable with. Before we start looking at potential providers, we should know if we can accept the risks implicit to the various deployment models – private, public, community, or hybrid and internal vs. external options. For the asset, determine if you are willing to accept the following options: Public. Private, internal/on-premises. Private, external (including dedicated or shared infrastructure). Community; taking into account the hosting location, service provider, and identification of other community members. Hybrid. To effectively evaluate a potential hybrid deployment, you must to have at least a rough architecture of where components, functions, and data will reside. At this stage you should have a good idea of your comfort level for transitioning to the cloud, and which deployment models and locations best fit your security and risk requirements. Evaluate potential cloud service models In this step focus on the degree of control you’ll have at each SPI tier (Software, Platform, or Infrastructure as a Service) to implement any required risk management. If you are evaluating a specific offering, at this point you might switch to a fuller risk assessment. Your focus will be on the degree of control you have to implement risk mitigations in the different SPI tiers. If you already have specific requirements (e.g., for handling of PCI regulated data) you can include them in the evaluation. Sketch the potential data flow If you are evaluating a specific deployment option, map out the data flow between your organization, the cloud service, and any customers/other nodes. While most of these steps have been high-level, before making a final decision it’s absolutely essential to understand whether, and how, data can move in and out of the cloud. If you have yet to decide on a particular offering, you’ll want to sketch out the rough data flow for any options on your acceptable list. This is to insure that as you make final decisions, you’ll be able to identify risk exposure points. Document Conclusions You should now understand the importance of what you are considering moving to the cloud, your risk tolerance (at least at a high level), and which combinations of deployment and service models are acceptable. You’ll also have a rough idea of potential exposure points for sensitive information and operations. These together should give you sufficient context to evaluate any other security controls. For low-value assets you don’t need the same level of security controls and can skip many of

Let the games begin. It seems that Radiant Systems, a point of sale terminal company, and Computer World, the company that sold and maintained the Radiant system, are in a bit of a pickle. Seven restaurants are suing them for producing insecure systems that led to security breaches, which led to fines for the breached companies, chargebacks, card replacement costs, and investigative costs. These are real costs, people, none of that silly “lost business and reputation” garbage. The credit card companies forced him to hire a forensic team to investigate the breach, which cost him $19,000. Visa then fined his business $5,000 after the forensic investigators found that the Radiant Aloha system was non-compliant. MasterCard levied a $100,000 fine against his restaurant, but opted to waive the fine, due to the circumstances. Then the chargebacks started arriving. Bond says the thieves racked up $30,000 on 19 card accounts. He had to pay $20,000 and managed to get the remainder dropped. In total, the breach has cost him about $50,000, and he says his fellow plaintiffs have borne similar costs. The breaches seemed to result from two failures – one by Radiant (who makes the system), and one by Computer World (who installed and maintained it). The Radiant system stored magnetic track data unencrypted, a violation of PCI standards. Computer World enabled remote access for the system (the control server on premise) using a default username and password. While I’ve railed against PCI at times, this is an example of how the system can work. By defining a baseline that can be used in civil cases, it really does force the PoS vendors to improve security. This is peripheral to the intent and function of PCI, but beneficial nonetheless. This case also highlights how these issues can affect smaller businesses. If you read the source article, you can feel the anger of the merchants at the system and costs thrust on them by the card companies. Keep in mind, they are already pissed since they have to pay 2-5% on every transaction so you can get your airline miles, fake diamond bracelets, and cheap gift cards. The quote from the vendor is priceless, and if the accusations in the lawsuit are even close to accurate, totally baseless: “What we can say is that Radiant takes data security very seriously and that our products are among the most secure in the industry,” Paul Langenbahn, president of Radiant’s hospitality division, told the Atlanta Journal-Constitution. “We believe the allegations against Radiant are without merit, and we intend to vigorously defend ourselves.” Maybe they can go join a certain ex-governor from Illinois on the next season of The Celebrity Apprentice, since they are reading from the same playbook. There are a few lessons in this situation: The lines have moved, and PCI now affects civil liability and government regulation. PCI compliance, and Internet-based cardholder security, now affect even small merchants, even those without an Internet presence. We have a growing body of direct loss measurements (time to revise my Data Breach Costs model). We are seeing product liability in action… by the courts, not legislation. As with many other breaches, following the most basic security principles could have prevented these. I think this last quote sums up the merchant side perfectly: “Radiant just basically hung us out to dry,” he says. “It’s quite obvious to me that they’re at fault… . When you buy a system for $20,000, you feel like you’re getting a state-of-the-art sytem. Then three to four months after I bought the sytem I’m hacked into.” Share:

We hate that we have to moderate comments, but the spammers are relentless and there’s no way we’ll let those jerks ruin our site. I realized I can disable moderation on a per-account basis without having to give you editing or moderation rights. All you have to do is register with the site, and drop us an email with your username at info@securosis.com. We’ll add you to our super secret group, and you can login and skip all that moderation silliness. A few of you comment on the blog pretty regularly, and we hate that we have to review everything first and slow the discussion down. Hopefully this will help ease the problem. Share:

Like many of you, for a long time I really couldn’t see the use of those URL shortener service thingies. Sure, when I was designing sites I tried to avoid long, ugly URLs, but I never saw slapping some random characters after a common base URL as being any more useful. I considered my awareness of the existence of these obscure services as an aberration induced by my geek genes, rather than validation of their existence or popularity. Then came Twitter, and the world of URLs was never the same. Twitter firmly swapped URL shorteners out of the occasionally useful into the pretty darn essential column. That magical 140 character limit, combined with the propensity of major sites to use URLs nearly as long as their software user agreements, thrust shorteners in front of millions of new eyeballs. One issue, pointed out by more than a few security pundits and rickrolling victims, is that these shorteners completely obscure the underlying URL. It’s trivial for a malicious attacker to hide a link and redirect a user to any sort of malicious site. It didn’t take long for phishers and drive-by malware attacks to take advantage of the growing popularity of these obfuscation services. Some of the more popular Twitter clients, like Tweetie, added optional URL previews to show users the full link before clicking through to the site. In part, this was enabled by shorteners like bit.ly enabling previews through their APIs. A nice feature, but it’s not one that most users enable, and it isn’t available in most web interfaces or even all standalone Twitter clients. Bit.ly announced today that they are taking things one major step further and will soon be scanning all links, in real time, using multiple security services. Bit.ly will be using a collection of databases and scanning services to check both new and existing links as users access them. Websense’s cloud-based scanner is one of the services (the one that pre-briefed me), and bit.ly will use at least one other commercial service as well as some free/open databases. Update: according to the bit.ly blog, VeriSign and Sophos are the other scanning/database engines. In the case of Websense, bit.ly will tie directly into their content scanning service to check links in real time as they are added to the bit.ly database. Websense uses a mix of real time scans (for things like malware and certain phishing techniques) and their database of known bad sites. The system won’t rely only on the database of previously-detected bad sites, but will also check them at access time. If a link is suspected of being malicious, Websense marks it and bit.ly will redirect users to a warning page instead of directly to the site. Users can still click through, and I’m sure plenty will, but at least those of us with a little common sense are less likely to be exploited. Bit.ly won’t only be scanning new links added to the database, but will be checking existing links in case they’ve become compromised. This also reduces the chances of the bad guys gaming the system by adding a clean version of their site for an initial scan, then sneaking in malware for future visits. I like bit.ly’s approach of checking existing links in case they get compromised, rather than only scanning new links as they are added. This will make it harder for bad guys to game the system. This solution is a lot better than the anti-phishing built into browsers and some search engines, since those rely only on databases of previously-discovered known bad sites. It’s also a two-way system, and although Websense is being paid for the scanning, they gain the additional benefit of now leveraging the results once millions of new (and old) links start flowing through their service. Every bad website Wensense finds when a user submits a link to bit.ly is added to the database used by all their other products. Finally, there’s nothing that says we’re only allowed to use bit.ly for Twitter. The entire Internet now gains a real-time security scanning service… for free. Have a questionable link? Shorten it through bit.ly and it’s scanned by Websense and at least one other commercial service, as well as all the free/open/cheap databases bit.ly uses (sorry, I don’t know what they are). This isn’t to say that any of the individual scans, or all of them together, can identify every malicious link they encounter, but this is a significant advance in web services security. It’s a perfect example of cloud computing enhancing security, rather than creating new risks. Links sent through bit.ly will now be safer than the original links viewed directly. This isn’t live yet, but should be by the end of the year. Share:

Here’s the thing about that 60 Minutes report on cybersecurity from the other week. Yes, some of the facts were clearly wrong. Yes, there are massive political fights under way to see who ‘controls’ cybersecurity, and how much money they get. Some .gov types might have steered the reporters/producers in the wrong direction. The Brazilian power outage probably wasn’t caused by hackers. But so what? Here’s what I do know: A penetration tester I know who works on power systems recently told me he has a 100% success rate. Multiple large enterprises tell me that hackers, quite possibly from China, are all over their networks stealing sensitive data. They keep as many out as they can, but cannot completely get rid of them. Large-scale financial cybercrime is costing us hundreds of millions of dollars – and those are just the ones we know about (some of that is recovered, so I don’t know the true total on an annual basis). Any other security professional with contacts throughout the industry talks to the same people I do, and has the same information. The world isn’t ending, but even though the story has some of the facts wrong, the central argument isn’t that far off the mark. Nick Selby did a great write-up on this, and a bunch of the comments are focused on the nits. While we shouldn’t excuse sloppy journalism, some incorrect facts don’t make the entire story wrong. Share:

Thanks to my wife’s job at a hospital, yesterday I was able to finally get my H1N1 flu shot. While driving down, I was also listening to a science podcast talking about the problems when the government last rolled out a big flu vaccine program in the 1970s. The epidemic never really hit, and there was a much higher than usual complication rate with that vaccine (don’t let this scare you off – we’ve had 30 years of improvement since then). The public was justifiably angry, and the Ford administration took a major hit over the situation.   Recently I also read an article about the Y2K “scare”, and how none of the fears panned out. Actually, I think it was a movie review for 2012, so perhaps I shouldn’t take it too seriously. In many years of being involved with risk-based careers, from mountain rescue and emergency medicine to my current geeky stuff, I’ve noticed a constant trend by majorities to see risk management successes as failures. Rather than believing that the hype was real and we actually succeeded in preventing a major negative event, most people merely interpret the situation as an overhyped fear that failed to manifest. They thus focus on the inconvenience and cost of the risk mitigation, as opposed to its success. Y2K is probably one of the best examples. I know of many cases where we would have experienced major failures if it weren’t for the hard work of programmers and IT staff. We faced a huge problem, worked our assess off, and got the job done. (BTW – if you are a runner, this Nike Y2K commercial is probably the most awesomest thing ever.) This behavior is something we constantly wrestle with in security. The better we do our job, the less intrusive we (and the bad guys) are, and the more invisible our successes. I’ve always felt that security should never be in the spotlight – our job is to disappear and not be noticed. Our ultimate achievement is absolute normalcy. In fact, our most noticeable achievements are failures. When we swoop in to clean up a major breach, or are dangling on the end of a rope hanging off a cliff, we’ve failed. We failed to prevent a negative event, and are now merely cleaning up. Successful risk management is a failure because the more we succeed, the more we are seen as irrelevant. Share: