Research

Our first post built a case for considering availability as an aspect of security context, rather than only confidentiality and integrity. This has been driven by Denial of Service (DoS) attacks, which are used by attackers in many different ways, including extortion (using the threat of an attack), obfuscation (to hide exfiltration), hacktivism (to draw attention to a particular cause), or even friendly fire (when a promotion goes a little too well). Understanding the adversary and their motivation is one part of the puzzle. Now let’s look at the types of DoS attacks you may face – attackers have many arrows in their quivers, and use them all depending on their objectives and targets. Flooding the Pipes The first kind of Denial of Service attack is really a blunt force object. It’s basically about trying to oversubscribe the bandwidth and computing resources of network (and increasingly server) devices to impact resource availability. These attacks aren’t very sophisticated, but as evidenced by the ongoing popularity of volume-based attacks, fairly effective effective. These tactics have been in use since before the Internet bubble, leveraging largely the same approach. But they have gotten easier with bots to do the heavy lifting. Of course, this kind of blasting must be done somewhat carefully to maintain the usefulness of the bot, so bot masters have developed sophisticated approaches to ensure their bots avoid ISPs penalty boxes. So you will see limited bursts of traffic from each bot and a bunch of IP address spoofing to make it harder to track down where the traffic is coming from, but even short bursts from 100,000+ bots can flood a pipe. Quite a few specific techniques have been developed for volumetric attacks, but most look like some kind of flood. In a network context, the attackers focus on overfilling the pipes. Floods target specific protocols (SYN, ICMP, UDP, etc.), and work by sending requests to a target using the chosen protocol, but not acknowledging the response. Enough of these outstanding requests limit the target’s ability to communicate. But attackers need to stay ahead of Moore’s Law, because targets’ ability to handle floods has improved with processing power. So network-based attacks may include encrypted traffic, forcing the target to devote additional computational resources to process massive amounts of SSL traffic. Given the resource-intensive nature of encryption, this type of attack can melt firewalls and even IPS devices unless they are configured specifically for large-scale SSL support. We also see some malformed protocol attacks, but these aren’t as effective nowadays, as even unsophisticated network security perimeter devices drop bad packets at wire speed. These volume-based attacks are climbing the stack as well, targeting web servers by actually completing connection requests and then making simple GET request and resetting the connection over and over again, with approximately the same impact as a volumetric attack – over-consumption of resources effectively knocking down servers. These attacks may also include a large payload to further consume bandwidth. The now famous Low Orbit Ion Cannon, a favorite tool of the hacktivist crowd, has undertaken a similar evolution, first targeting network resources and proceeding to now target web servers as well. It gets even better – these attacks can be magnified to increase their impact by simultaneously spoofing the target’s IP address and requesting sessions from thousands of other sites, which then bury the target in a deluge of misdirected replies, further consuming bandwidth and resources. Fortunately defending against these network-based tactics isn’t overly complicated, as we will discuss in the next post, but without a sufficiently large network device at the perimeter to block these attacks or an upstream service provider/traffic scrubber to dump offending traffic, devices fall over in short order. Overwhelming the Application But attackers don’t only attack the network – they increasingly attack the applications as well, following the rest of attackers up the stack. Your typical n-tier web application will have some termination point (usually a web server), an application server to handle application logic, and then a database to store the data. Attackers can target all tiers of the stack to impact application availability. So let’s dig into each layer to see how these attacks work. The termination point is usually the first target in application DoS attacks. They started with simple GET floods as described above, but quickly evolved to additional attack vectors. The best known application DoS attack is probably RSnake’s Slowloris, which consumes web server resources by sending partial HTTP requests, effectively opening connections and then leaving the sessions open by sending additional headers at regular intervals. This approach is far more efficient than the GET flood, requiring only hundreds of requests at regular intervals rather than constant thousands, and only requires one device to knock down a large site. These application attacks have evolved over time and now send complete HTTP requests to evade IDS and WAF devices looking for incomplete HTTP requests, but they tamper with payloads to confuse applications and consume resources. As defenders learn the attack vectors and deploy defenses, attackers evolve their attacks. The cycle continues. Web server based attacks can also target weaknesses in the web server platform. For example the Apache Killer attack sends a malformed HTTP range request to take advantage of an Apache vulnerability. The Apache folks quickly patched the code to address this issue, but it shows how attackers target weaknesses in the underlying application stack to knock the server over. And of course unpatched Apache servers are still vulnerable today at many organizations. Similarly, the RefRef attack leverages SQL injection to inject a rogue .js file onto a server, which then hammers a backend database into submission with seemingly legitimate traffic originating from an application server. Again, application and database server patches are available for the underlying infrastructure, but vulnerability remains if either patch is missing. Attackers can also target legitimate application functionality. One example of such an attack targets the search capability within a web site. If an attacker scripts a series of overly broad

Our days just keep getting longer and longer. When the kids were younger afternoons and early evenings were a blur of activities, homework, hygiene, meals, reading, and then bed. Most nights the kids were in bed by 8:30 and the Boss and I could eat in peace, watch a little TV, catch up, and basically take a breath. But since XX1 entered middle school, things have changed. The kids have adapted fine. The Boss and me, not so much. Now it’s all about dividing and conquering. I handle the early shift and get the twins ready for school. They are on the bus by 7:20 and then I usually head over to some coffee shop and start working. The Boss handles XX1 and has her on the bus at 8:10, and then she starts her day of working through all the crap that has to happen to keep the trains running. The twins get off the bus at 3pm or so. Then it’s homework time and shuttling them off to activities. XX2 isn’t home until 4:30; then some days she can get an hour or two of work in, and other days she can’t. Inevitably she gets home from dance and has to start her homework. She usually wraps up around 10, but I usually get enlisted to help with the writing or math. And there are nights when XX1 is up until 11 or even later trying to get everything done. So there is no peace and quiet. Ever. We find ourselves staying up past midnight because those 90 minutes after all the kids go to bed are the only time we have to catch up and figure out the logistics for the next day. Which assumes that I don’t have work I need to get done. I know Rich has it harder right now with his 2 (and soon to be 3) kids under 4. I remember those days, and don’t miss the sleep deprivation. And I’m sure he misses sleeping in on weekends. At least I get to do that – our kids want us to sleep as late a possible, so they can watch more crappy shows on Nick Jr. But I do miss the quiet evenings after the kids were sleeping. Those are likely gone for a little while. For the next 9 years or so, the kids own the night. –Mike Photo credits: We Own The Night originally uploaded by KJGarbutt Heavy Research We’re 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. Defending Against Denial of Service (DoS) Attacks Introduction Securing Big Data Architectural Issues Security Issues with Hadoop Incite 4 U Responsible is in the eye of the beholder: My personal views on disclosure have changed a lot over the years. If you haven’t changed your views in the last 10 years you are either a hermit or a religious zealot – the operating environment has changed a lot. And the longer I have watched (and participated) in the debate, the more I realize it seems to be more about egos than the good of the public. And I fully mean this on all sides – researchers, vendors, users (but less), government, and pundits. Take Richard Bejtlich’s latest post on vendors or researchers going public when they find command and control servers. He expresses the legitimate concern that whoever finds and publicizes this information may often be blowing a law enforcement or intelligence operation. On the other hand law enforcement and intelligence agencies sure don’t make it easy to report these findings, and researchers might be sitting there watching people get compromised (including their customers). This is a hard problem to solve – if we even can. Just ask the Stratfor guys who were materially damaged while the FBI was not only watching, but ‘assisting’ the attack via their confidential informant. Better communication and cooperation is probably the answer, but I have absolutely no confidence that can happen at scale, even if some companies (including Richard’s employer) have those ties. No, I don’t have an answer, but we all need open minds, and probably a bit less ego and dogma. – RM The mark of a mature market: You can joke about the SC Magazine reviews operation. How they rarely actually test products, but instead sit through WebEx demos run by experienced SEs who make every product seem totally awesome. And that may be true but it’s not the point. It’s about relative ratings as an indicator of a mature market. If you look at SC Mag’s recent group test on email security devices, you’ll see 9 out of 10 products graded higher than 4 1/4 stars (out of 5). That 10th product must really suck for 3 stars. But even if you deflate the ratings by a star (or two) you’ll see very little outward differentiation. Which means the product category has achieved a lowest common denominator around a base set of features. So how do you decide between largely undifferentiated offerings? Price, of course… – MR Progress, at a glacial pace: I disagree with Mike Mimoso about the Disconnect Between Application Development and Security Getting Wider. We have been talking about this problem for almost a decade with not much improvement, so it certainly can feel that way. But I can say from personal experience that 10 years ago even the companies who developed security software knew nothing about secure code development, while now these is a better than even chance that someone on the team knows a little security. Have their processes changed to embrace security? Only at a handful of firms. The issue, in my opinion, is and has been the invisible boundary around the dev team to shield them from outside influence. Developers are largely isolated to keep

There was a lot of big news this week in the security world, most of it bad. Even if you skip the intro, make sure you read the Top News section. Rich here, Growing up I was – and this might shock some of you – a bit of a nerd. I glommed onto computers and technology pretty much as soon as I had access to them, and when I didn’t I was reading books and watching shows that painted wonderful visions of the future. I was a hacker before I ever heard the word, constantly taking things apart to see how they worked, then building my own versions. Technology is thus very intuitive to me. I never had to learn it in the same way as people coming to computers and electronics later in life. I began programming so early in life that it keyed into the same (maybe) brain pathways that allow children to learn multiple languages with far more facility than adults. While my generational peers are far more comfortable with technology and computers than our parents, I generally still have a leg up due to my early immersion. I naturally assumed that the generations following me would grow up closer to my experiences than my less geeky peers. But much to my surprise, although they are very comfortable with computers, they don’t have the damnedest idea of how they work or how to bend them to their own will. Unless it involves cats and PowerPoint. Lacking teachers who understood tech, they grow up learning how to use Office, not to program or dig into technology beyond the shallowest surface levels. As I have started raising my own kids, I worry about how to get them interested in technology, and algorithmic thinking, in a world where iPads put the entire Disney repository a few taps away. I’m not talking about forcing them to become programmers, but taking advantage of their brain plasticity to reinforce logical thinking and problem solving, and at least convey a sense of deeper exploration. This really did worry me, but over the past few months I have realized that as a parent I have the opportunity to engage my children to degrees my parents couldn’t possibly imagine. It was a big deal when I got my first Radio Shack electronics kit. It was even a bigger deal when I made my first radio. My kids? This past weekend my 3.5 and 2 year old got to play with their first home-built LEGO robot. Yes, I did most of the building and all the programming, but I could see them learning the foundation of how it worked and what we could make it do. Building a robot to play with our cat is a hell of a lot more exciting than putting a picture of a cat in a PowerPoint. This is barely the start. I grew up pushing ASCII pixels on screens. They will grow up programming, and perhaps designing, autonomous flying drones with high-definition video feeds. I grew up making simple electric candles that would turn on in a dark room. They will be able to create wonderful microcontroller-based objects they then embed into 3-D printed housings. There’s no guarantee they will actually be interested in these things, but social engineering isn’t just for pen testing. Hopefully I can manipulate the crap out of them so they at least get the basics. And, if not, it means more stock fab material for me. I’m biased. I think most of my success in life is due to a combination of logical thinking, the exploratory drive of a hacker, and a modest facility with the written word. As a parent I now have tools to teach these skills to my children in ways our parents could only dream about. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted on the myth of cyberinsurance. Mike’s Security Intelligence post at Dark Reading. Favorite Securosis Posts Adrian Lane: My Security Fail (and Recovery) for the Week. Gave me a moment of panic. Mike Rothman: Securing Big Data: Architectural Issues. This series is critical for you to learn what’s coming. If it hasn’t already arrived. Rich: David Mortman’s Another Inflection Point. The more we let go of, the more we can do. Other Securosis Posts Defending Against DoS Attacks: The Attacks. Incite 9/27/2012: They Own the Night. New Research Paper: Pragmatic WAF Management. Favorite Outside Posts Adrian Lane: OAuth 2.0 – Google Learns to Crawl. For someone learning just how much I don’t know about authorization, this is a good overview of the high points of the OAuth security discussion. Mike Rothman: 25 Great Quotes from the Princess Bride. 25 YEARS! WTF? I don’t feel that old, but I guess I am. Take a trip down memory lane and remember one of the better movies ever filmed. IMHO, anyway. Rich: Connect with your inner grey hat. The title is a bit misleading, but the content is well stated. You need to change up your thinking constantly. Research Reports and Presentations Pragmatic WAF Management: Giving Web Apps a Fighting Chance. Understanding and Selecting Data Masking Solutions. Evolving Endpoint Malware Detection: Dealing with Advanced and Targeted Attacks. Implementing and Managing a Data Loss Prevention Solution. Defending Data on iOS. Malware Analysis Quant Report. Report: Understanding and Selecting a Database Security Platform. Top News and Posts The big news this week is the compromise and use of an Adobe code signing certificate in targeted attacks. Very serious indeed. Banks still fighting off the Iranian DDoS attacks. OpenBTS on Android. This is the software you use to fake a cell phone base tower. Smart grid control vendor hacked. Yes, they had deep access to their clients, why do you ask? An interview with the author of XKCD. Sudo read this article. PHPMyadmin backdoored. PPTP now really and truly dead. More Java 0day. Seriously, what the hell is going on this week? And to top everything off, a Sophos post

We are proud to announce a new research paper on Pragmatic Web Application Firewall Management. This paper has been a long time coming – we have been researching this topic for three years, looking for the right time to discuss WAF’s issues. Our key finding is that Web Application Firewalls can genuinely raise the bar on application security. Properly set up they block many attacks such as SQL injection and, just as importantly, ‘virtually’ patch applications faster than code fixes can be implemented. There is ample evidence that building security into applications from the get-go is more efficient, but unfortunately it may not be practical or even realistic. Most firms already have dozens – if not thousands – of vulnerable web apps that will take years to fix. So the real answer is both: “build security in” and “bolt security on”. And that is how WAFs help protect web applications when timely code fixes are not an option. During our research we heard a lot of negative feedback from various security practitioners – specifically pen testers – about how WAFs barely slow skilled attackers down. We heard many true horror stories, but they were not due to any specific deficiency in WAF technology. The common theme among critics was that problems stemmed from customers’ ineffective management practices in WAF deployment and tuning of rules. We also heard many stories about push-back from development teams who refused to wade through the reams of vulnerability output generated by WAFs. Some of this was due to poor report quality of WAF products, and some was due to internal politics and process issues. But in both cases we concluded from hundreds of conversations that WAF provides a unique value, and its issues can be mitigated through effective management. For more detailed information on our recommendations, as well as how we reached our conclusions, we encourage you to grab a copy of the white paper. Finally, Securosis provides the vast bulk of our research for free and without user registration. Our goal, as always, is to help organizations understand security issues and products, and to help get your job done with as little headache as possible. But it’s community support that enables us to produce our research, so we want to make special mention of those firms who have sponsored this paper: Alert Logic, Barracuda Networks, and Fortinet. We want to thank our sponsors as well as those of you who took time to discuss your WAF stories and provide feedback during this project! The paper is available to download: Pragmatic WAF Management (PDF). Share:

In the previous post we went to some length to define what big data is – because the architectural model is critical to understanding how it poses different security challenges than traditional databases, data warehouses, and massively parallel processing environments. What distinguishes big data environments is their fundamentally different deployment model. Highly distributed and elastic data repositories enabled by the Hadoop File System. A distributed file system provides many of the essential characteristics (distributed redundant storage across resources) and enables massively parallel computation. But specific aspects of how each layer of the stack integrates – such as how data nodes communicate with clients and resource management facilities – raise many concerns. For those of you not familiar with the model, this is the Hadoop architecture. Architectural Issues Distributed nodes: The idea that “Moving Computation is Cheaper than Moving Data” is key to the model. Data is processed anywhere processing resources are available, enabling massively parallel computation. It also creates a complicated environment with a large attack surface, and it’s harder to verify consistency of security across all nodes in a highly distributed cluster of possibly heterogeneous platforms. ‘Sharded’ data: Data within big data clusters is fluid, with multiple copies moving to and from different nodes to ensure redundancy and resiliency. This automated movement makes it very difficult to know precisely where data is located at any moment in time, or how many copies are available. This runs counter to traditional centralized data security models, when data is wrapped in various protections until it’s used for processing. Big data is replicated in many places and moves as needed. The ‘containerized’ data security model is missing – as are many other relational database concepts. Write once, read many: Big data clusters handle data differently than other data management systems. Rather than the classical “Insert, Update, Select, and Delete” set of basic operations, they focus on write (Insert) and read (Select). Some big data environments don’t offer delete or update capabilities at all. It’s a ‘write once, read many’ model, which is excellent for performance. And it’s a great way to collect a sequence of events and track changes over time, but removing and overwriting sensitive data can be problematic. Data management is optimized for performance of insertion and query processing, at the expense of content manipulation. Inter-node communication: Hadoop and the vast majority of available add-ons that extend core functions don’t communicate securely. TLS and SSL are rarely available. When they are – as with HDFS proxies – they only cover client-to-proxy communication, not proxy-to-node sessions. Cassandra does offer well-engineered TLS, but it’s the exception. Data access/ownership: Role-based access is central to most database security schemes. Relational and quasi-relational platforms include roles, groups, schemas, label security, and various other facilities for limiting user access, based on identity, to an authorized subset of the available data set. Most big data environments offer access limitations at the schema level, but no finer granularity than that. It is possible to mimic these more advanced capabilities in big data environments, but that requires the application designer to build these functions into applications and data storage. Client interaction: Clients interact with resource managers and nodes. While gateway services for loading data can be defined, clients communicate directly with both the master/name server and individual data nodes. The tradeoff this imposes is limited ability to protect nodes from clients, clients from nodes, and even name servers from nodes. Worse, the distribution of self-organizing nodes runs counter to many security tools such as gateways/firewalls/monitoring which require a ‘chokepoint’ deployment architecture. Security gateways assume linear processing, and become clunky or or overly restrictive in peer-to-peer clusters. NoSecurity: Finally, and perhaps most importantly, big data stacks build in almost no security. As of this writing – aside from service-level authorization, access control integration, and web proxy capabilities from YARN – no facilities are available to protect data stores, applications, or core Hadoop features. All big data installations are built upon a web services model, with few or no facilities for countering common web threats, (i.e. anything on the OWASP Top Ten) so most big data installations are vulnerable to well known attacks. There are a couple other issues with securing big data on an architectural level, which are not issues specifically with big data, but with security products in general. To add security capabilities into a big data environment, they need to scale with the data. Most ‘bolt-on’ security does not scale this way, and simply cannot keep up. Because the security controls are not built into the products, there is a classic impedance mismatch between NoSQL environments and aftermarket security tools. Most security vendors have adapted their existing offerings as well as they can – usually working at data load time – but only a handful of traditional security products can dynamically scale along with a Hadoop cluster. The next post will go into day to day operational security issues. Share:

I remember sitting at lunch with a friend and well-respected member of our security community as I described the architecture we used to protect our mail server. I’m not saying it’s perfect, but this person responded with, “that’s insane – I know people selling 0-days to governments that don’t go that far”. On another occasion I was talking with someone with vastly more network security knowledge and experience than me; someone who once protected a site attacked daily by very knowledgeable predators, and he was… confused as to why I architected the systems like I did. Yesterday, it saved my ass. Now I’m not 100% happy with our current security model on mail. There are aspects that are potentially flawed, but I’ve done my best to reduce the risk while still maintaining the usability we want. I actually have plans to close the last couple holes I’m not totally comfortable with, but our risk is still relatively low even with them. Here’s what happened. Back when we first set up our mail infrastructure we hit a problem with our VPN connections. Our mail is on a fully segregated network, and we had some problems with our ISP and IPSec-based VPNs even though I tried multiple back-end options. Timing-wise we hit a point where I had to move forward, so I set up PPTP and mandated strong passwords (as in I reviewed or set all of them myself). Only a handful of people have VPN access anyway, and, at the time, a properly-constructed PPTP password was still very secure. That delusion started dying this summer, and was fully buried yesterday thanks to a new, cloud-based, MS-CHAP cracking tool released by Moxie Marlinspike and David Hulton. The second I saw that article I shut down the VPN. But here’s how my paranoia saved my ass. As a fan of hyper-segregation, early on I decided to never trust the VPN. I put additional security hardware behind the VPN, with extremely restrictive policies. Connecting via the VPN gave you very little access to anything, with the mail server still completely walled off (a UTM dedicated only to the mail server). Heck, the only two things you could try to hack behind the VPN were the VPN server itself and the UTM… nothing else is directly connected to that network, and all that traffic is monitored and filtered. When I initially set things up people questioned my choice to put one security appliance behind another like that. But I didn’t want to have to rely on host security for the key assets if someone compromised anyone connected to our VPN. In this case, it worked out for me. Now I set all this up pre-cloud, but you can set up a similar architecture in many VPC or private cloud environments (you need two virtual NICs and a virtual UTM, although even simple firewall rules can go a long way to help). This is also motivation to finish the next part of my project, which involves yet another UTM and server. Share:

Rich Mogull recently posted a great stream of consciousness piece about how we are at an inflection point in information security. He covers how cloud and mobility are having, and will continue to have, a huge impact on how we practice security. Rich mentions four main areas of impact: Hyper-segregation Incident response Active defense Closing the action loop The post is short but very very dense. Read it a couple times, even – there’s a lot there. I would add another consequence of these changes that has already begun and will continue to manifest over the next five to ten years. That is the operationalization of security. This is partially because security is increasingly becoming a feature rather than a product itself. Over time we will see more and more of today’s dedicated security jobs evolving into responsibilities of other roles. We already see this with patch and AV management, which are increasingly owned by the Operations rather than Security teams. Similarly, we will see development and QA picking up functions that previously belonged to security folks. Dedicated security folks will still exist, but they will fall into a much smaller set of roles, including: Advisors/subject matter experts – architects and CISOs Penetration testers Incident responders And in the case of the latter two, they will increasingly be experts brought in to handle issues beyond the capabilities of regular teams, or to satisfy requirements for third-party assessment. In many ways this will be a return to how security was in the mid-90s. Yet another example of Hoff’s Hamster Sine Wave of Pain…. h/t to Gene Kim for feedback as I wrote this post. Share:

Adrian here … I had a few surgical procedures over the past few weeks. They corrected some vascular defects that were causing several problems, some of which had been coming on for such a long time I was unaware that there was an issue. The whole boiling frog in a beaker concept. And with the slow progression I was ignorant of the extent of the damage it was causing. The good news is that procedures were successful and their positive benefit was far greater than I anticipated. This whole series of events hammered home a concept that I have been intellectually aware of for a long time, but not lived out to this degree. Many people have blogged about how and why people make bad security tradeoffs. Instinct, fear, lower brain functions, and other ways we are wired to make some decisions and not others. Bruce Schneier has been talking about this for 10 years or more. But I think for the first time I really understand it at a basic level. When I was a kid I had a very strong vasovagal response. I get the lightheadedness, nausea, feeling of being extremely hot, and sweating. I don’t get the fuzziness, inability to speak, or weakness. But I only ever got it when I went to the eye doctor and they administered the glaucoma test. Nothing else has ever bugged me – until this recent surgery. For the first time I saw it in slow motion, with the internal conversation going something like this: The upper, rational part of my brain says: “I’m really looking forward to getting this stuff fixed and moving on with my life.” The lower part that’s wired into all critical infrastructure say: “Something’s wrong. Something bad is happening to your leg. Fix it!” The upper brain: “It’s okay, the doctor’s just fixing some veins. Don’t …” Lower brain: “NO, it’s not! Kick that F**ker in the head! Kick him then run like hell!” Lower brain wins. And all these years I just thought I hated my eye doctor. Who knew? But getting that very strange sensation again was both odd and educational. Being aware of the condition and watching yourself react as an adult is a whole different experience; you consciously witness two parts of your brain at odds. And I know how to work through it without passing out, but it involves the same stomach compression techniques jet pilots learn to combat G-forces. A great way to creep out the hospital staff too, but it kept me alert through the physical manifestations of the conflict to ‘witness’ the internal debate. No wonder we’re so flawed when if comes to making judgements when threats or fear are involved. I can be aware of it and still do very little about it. You body would rather shut down than deal with it. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading post on Encrypted Query Processing. Favorite Securosis Posts Mike Rothman: Inflection. Rich provides some food for thought on what the future of security looks like. Read it. Think about it. See what makes sense to you. Adrian Lane: It’s Time for Enterprises to Support a “Backup” Browser. No way to be secure with just one. And don’t get me started on browsing from mobile devices! Other Securosis Posts Incite 9/20/2012: Scabs. Securing Big Data: Security Issues with Hadoop Environments. Attend Gunnar’s Kick-A Mobile Security and Development Class. Friday Summary: September 14, 2012. Favorite Outside Posts Mike Rothman: Antivirus programs often poorly configured, study finds. In a “master of the obvious” research finding, the OPSWAT guys tell us that even if AV worked (which it doesn’t), most folks misconfigure their controls anyway and don’t have the right stuff turned on. And you wonder why the busiest guys in the industry are the folks tracking all the breaches? Adrian Lane: Looking Inside Your Screenshots. So many good posts this week, but I thought this was the most interesting. I have never been a big fan of digital watermarking – it’s too easy to detect and evade for images and music files, and we know it degrades content. But in this case it’s more difficult to detect and does not degrade the content – and it gives Blizzard a hammer to use in legal cases as they have solid user/client identity. Sneaky, and if you give it some thought, there are other practical applications of this approach. Rich: Compliance lessons from Lance at EmergentChaos. As the resident Securosis cycling fan there’s no way I wasn’t going to pick this one. Only difference is Lance previously, clearly, stated he didn’t dope… which isn’t the same as his recent comments more focused on ‘compliance’. Project Quant Posts Malware Analysis Quant: Index of Posts. Malware Analysis Quant: Metrics – Monitor for Reinfection. Malware Analysis Quant: Metrics – Remediate. Malware Analysis Quant: Metrics – Find Infected Devices. Research Reports and Presentations Understanding and Selecting Data Masking Solutions. Evolving Endpoint Malware Detection: Dealing with Advanced and Targeted Attacks. Implementing and Managing a Data Loss Prevention Solution. Defending Data on iOS. Top News and Posts OWASP ZAP – the Firefox of web security tools Coders Behind the Flame Malware Left Incriminating Clues on Control Servers. A fun read. And if most code received this level of scrutiny, we would have much better code! Attack Easily Cracks Oracle Database Passwords Internet Explorer Fix is available now Media Manipulation and Social Engineering Mobile Pwn2Own ownage Hacker Steals $140k From Lock Poker Account RSnake donated XSS filter cheat sheet to OWASP BSIMM 4 Released Petco Releases Coupon On Internet, Forgets How Internet Works Majority of companies suffered a web application security breach Massachusetts group to pay $1.5M HIPAA settlement. I would love to see the “corrective plan of action”. Web Cryptography API draft published Java zero-day leads to Internet Explorer zero-day Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best

You will probably read this on Thursday or even Friday, and that’s late. This week got all screwed up. It’s a little matter of a bunch of things happening at the same time, mostly personal, all good. So Monday was a holiday for me and starts the fall renewal process where I don’t set goals and don’t worry about what I’m striving for any more. It also turns out Monday night was the Falcons home opener. Many of my ATL buddies consider me a sinner for going to a football game on the High Holy Days. As I told the Boss, “Football is my other religion,” so there was never a question whether I would go. Normally I work late on Tuesday night, but we took XX2 to see a Ben Folds concert for her birthday. So up late Monday (I’ll get to that) and up late Tuesday. And a check-up for the kids Wednesday morning. Which means not a lot of time to actually, well, work. And I won’t even mention the road trip to go see the Giants play in Carolina on Thursday night. Yeah, I have a pretty sweet deal. Now back to Monday night. Everyone was amped up for the game. The Broncos and their rebuilt QB, Peyton Manning, were in town. The atmosphere was electric. Until about midway through the first quarter, when the replacement refs lost control of the game. I mean totally lost control. I have never seen anything like it. Penalties were reversed or not called. Fights broke out. The ball was spotted wrong. The first quarter took over an hour. Monday Night Football didn’t end until Tuesday morning. NFL referees are like security folks. Until they are gone and all hell breaks loose, you don’t even notice them. The NFL is taking a hard line about pensions, and they locked out the regular referees. I thought I had a sweet deal, but refs have it pretty good too. Some make as much as $120K a year to work maybe 20 games, including playoffs. Even based on the NFL’s latest offer, they’ll still get something like $15K contributed to retirement. But it’s not enough. Everyone always wants more. So the NFL finds replacement refs, most of whom do a good enough job. Some don’t (like the team on the field in ATL on Monday night). But at the end of the day, Steve Young was right. The NFL is in an inelastic demand situation, and how cool is it that a Hall of Fame QB talks about Econ 101 on national TV? The NFL will take a hard line because the fans will continue to show up. And we will. I’ll bitch and moan to my pals. The football talking heads (which is actually a much bigger echo chamber than security) will bitch and moan. The fans will keep showing up. As evidenced by my upcoming road trip to Charlotte. So the scabs will continue to be entrusted with keeping games on track and in control. Hopefully no one gets hurt and the games end fairly. Truth be told, scabs is a derogatory and unfair term for the replacement refs. It’s not their fault they are in deep water. It’s like taking a recent security graduate and asking them to defend something important from [name your favorite pen tester]. It’s going to end poorly. Ultimately the real refs will cave. It’s all about the leverage. It’s always about the leverage. The real refs have none. The NFL continues to have record ratings and record attendance and record activity in the NFL ecosystem, even with replacement refs. And once the refs realize they are very small cogs in a multi-billion-dollar wheel, they will pull off the scabs and get back to work. –Mike Photo credits: Scabs originally uploaded by Thomas Hawk Heavy Research We’re 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. Defending Against Denial of Service (DoS) Attacks Introduction Securing Big Data Security Issues with Hadoop Incite 4 U What makes an expert? Rob G levels a very uncharacteristic personal attack in his The know-nothings of cybersecurity, with the argument that someone who hasn’t actually configured a firewall or injected SQL cannot really be an expert. I reject that – it depends on what aspect of cybersecurity you’re talking about. A cybersecurity policy wonk probably hasn’t pwned devices using cool XSS code, but that doesn’t mean they don’t understand policies. And even if you are talking about technical expertise, it depends on who you’re talking to. Anyone can be an expert, if they are talking to n00bs. I’m no fan of generic statements that can’t be proven, nor am I a fan of the tons of charlatans claiming to be something they aren’t. But I don’t buy that there is only one kind of cybersecurity expert. – MR Mobile payments are HOT HOT HOT: Hat tip to Martin McKeay for bringing this up as we were recording this week’s Network Security Podcast. It looks like the PCI Council is going to release guidance on mobile payment applications. This is a big deal – a lot of apps tie into credit cards in some way, shape, or form. On one side are tools like Square payment card readers, but I suspect we might see other forms of apps tying to credit cards coming under scrutiny. It’s not something I would put money on – just something to watch. Think of all the QR-code based apps that use credit card somewhere on the back end. Then again, the PCI will do whatever they expect to piss off the smallest number of vendorsmembers, and Visa will end up making a blanket decision, anyway. – RM Estimates are like … never mind: There is a reason

Hang with me as I channel my inner Kerouac (minus the drugs, plus the page breaks) and go all stream of consciousness. To call this post an “incomplete thought” would be more than a little generous. I believe we are now deep in the early edge of a major inflection point in security. Not one based merely on evolving threats or new compliance regimes, but a fundamental transformation of the practice of security that will make it nearly unrecognizable when we finally emerge on the other side. For the past 5 years Hoff and I have discussed disruptive innovation in our annual RSA presentation. What we are seeing now is a disruptive conflagration, where multiple disruptive innovations are colliding and overlapping. It affects more than security, but that’s the only area about which I’m remotely qualified to pontificate. Perhaps that’s a bit of an exaggeration. All the core elements of what we will become are here today, and there are certain fundamentals that never change, but someone walking into the SOC or CISO role of tomorrow will find more different than the same unless they deliberately blind themselves. Unlike most of what I read out there, I don’t see these changes as merely things we in security are forced to react to. Our internal changes in practice and technology are every bit as significant contributing factors. One of the highlights of my career was once hanging out and having beers with Bruce Sterling. He said that his role as a futurist was to imagine the world 7 years out – effectively beyond the event horizon of predictability. What I am about to describe will occur over the next 5-10 years, with the most significant changes likely occurring in those last 7-10 years, but based on the roots we establish today. So this should be taken as much as science fiction as prediction. The last half of 2012 is the first 6 months of this transition. The end result, in 2022, will be far more change over 10 years than the evolution of the practice of security from 2002 through today. The first major set of disruptions includes the binary supernova of tech – cloud computing and mobility. This combination, in my mind, is more fundamentally disruptive than the initial emergence of the Internet. Think about it – for the most part the Internet was (at a technical level) merely an extension of our existing infrastructure. To this day we have tons of web applications that, through a variety of tiers, connect back to 30+-year-old mainframe applications. Consumption is still mostly tied to people sitting at computers at desks – especially conceptually. Cloud blows up the idea of merely extending existing architectures with a web portal, while mobility advances fundamentally redefine consumption of technology. Can you merely slop your plate of COBOL onto a plate of cloud? Certainly, right as you watch your competitors and customers speed past at relativistic speeds. Our tradition in security is to focus on the risks of these advances, but the more prescient among us are looking at the massive opportunities. Not that we can ignore the risks, but we won’t merely be defending these advances – our security will be defined and delivered by them. When I talk about security automation and abstraction I am not merely paying lip service to buzzwords – I honestly expect them to support new capabilities we can barely imagine today. When we leverage these tools – and we will – we move past our current static security model that relies (mostly) on following wires and plugs, and into a realm of programmatic security. Or, if you prefer, Software Defined Security. Programmers, not network engineers, become the dominant voices in our profession. Concurrently, four native security trends are poised to upend existing practice models. Today we focus tremendous effort on an infinitely escalating series of vulnerabilities and exploits. We have started to mitigate this somewhat with anti-exploitation, especially at the operating system level (thanks to Microsoft). The future of anti-exploitation is hyper segregation. iOS is an excellent example of the security benefits of heavily sandboxing the operating ecosystem. Emerging tools like Bromium and Invincea are applying even more advanced virtualization techniques to the same problem. Bromium goes so far as to effectively virtualize and isolate at a per task level. Calling this mere ‘segregation’ is trite at best. Cloud enables similar techniques at the network and application levels. When the network and infrastructure are defined in software, there is essentially zero capital cost for network and application component segregation. Even this blog, today, runs on a specially configured hyper-segregated server that’s managed at a per-process level. Hyper segregated environments – down, in some cases, to the individual process level – are rapidly becoming a practical reality, even in complex business environments with low tolerance for restriction. Although incident response has always technically been core to any security model, for the most part it was shoved to the back room – stuck at the kids’ table next to DRM, application security, and network segregation. No one wanted to make the case that no matter what we spent, our defenses could never eliminate risk. Like politicians, we were too frightened to tell our executives (our constituency) the truth. Especially those who were burned by ideological execs. Thanks to our friends in China and Eastern Europe (mostly), incident response is on the earliest edge of getting its due. Not the simple expedient of having an incident response plan, or even tools, but conceptually re-prioritizing and re-architecting our entire security programs – to focus as much or more on detection and response as on pure defense. We will finally use all those big screens hanging in the SOC to do more than impress prospects and visitors. My bold prediction? A focus on incident response, on more rapidly detecting and responding to attacker-driven incidents, will exceed our current checklist and vulnerability focused security model, affecting everything from technology decisions to budgeting and staffing. This doesn’t