The Fifth Annual Securosis Disaster Recovery Breakfast

Game on! It’s hard to imagine, but this year we are hosting the Fifth Annual RSA Conference Disaster Recovery Breakfast, in partnership with SchwartzMSL and Kulesa Faul (and possibly one more surprise guest). When we started this we had no idea how popular it would be. Much to our surprise it seems that not everyone wants to spend all their time roaming a glitzy show floor or bopping their heads to 110 decibels in some swanky club with a bunch of coworkers wearing logo shirts and dragging around conference bags. (Seriously, what is up with that?!?) As always, the breakfast will be Thursday morning from 8-11 at Jillian’s in the Metreon. It’s an open door – come and leave as you want. We’ll have food, beverages, and assorted recovery items to ease your day (non-prescription only). Remember what the DR Breakfast is all about. No marketing, no spin, just a quiet place to relax and have muddled conversations with folks you know, or maybe even go out on a limb and meet someone new. After three nights of RSA Conference shenanigans, it’s an oasis in a morass of hyperbole, booth babes, and tchotchke hunters. Invite below. See you there. To help us estimate numbers please RSVP to rsvp (at) securosis (dot) com. I (Rich) won’t actually be there this year (probably) or at RSA at all. It seems my wife decided to have a baby that week, so unless the little bugger comes pretty early I’ll be at home for my first RSA in many years. So have one or two for me on Wednesday night, then a few aspirin and Tums for me on Thursday morning at the breakfast. Share:

Read Post

The Problem with Android Patches

At the Kaspersky summit in San Juan, Puerto Rico, Chris Soghoian discussed the problem of Android user’s not updating their mobile devices to current software revisions. From Threatpost: “With Android, the situation is worse than a joke, it’s a crisis,” … “With Android, you get updates when the carrier and hardware manufacturers want them to go out. Usually, that’s not often because the hardware vendor has thin [profit] margins. Whenever Google updates Android, engineers have to modify it for each phone, chip, radio card that relies on the OS. Hardware vendors must make a unique version for each device and they have scarce resources. Engineers are usually focused on the current version, and devices that are coming out in the next year.” The core of the issue is that the mobile carriers are not eager to have every one of their mobile users downloading hundreds of megabytes across their networks for patches and OS updates to extend the value of their old phones. For them it’s pure overhead, so they don’t prioritize updates. And the results are pretty staggering, with adoption rates of new iOS software approaching 50% in a week, whereas Android … well, see for yourself. Every mobile security presentation I have been to over the last 18 months devolves into a debate between “Android Security is Better” vs. “iOS security is superior”. But the debate is somewhat meaningless to most consumers, who only carry one or the other, and rarely choose phones based on security. General users don’t go out of their way to patch, and most users (who say they care about security when asked) don’t put much effort into security – including patching. So platform patches are mostly interesting to IT Operations at large enterprises dealing with BYOD, who are trying to keep their employees from becoming infected with mobile malware. Our research shows this has been a primary reason some of the Fortune 1000 don’t allow Android in the enterprise. Just as bad, as Mr. Soghoian points out, carriers also arbitrarily restrict – or ‘cripple’ – device features. There is no clear solution to these problems yet, so good for Chris for drawing attention to the issue – hopefully it will resonate beyond the security community. Share:

Read Post

Network-based Threat Intelligence: Understanding the Kill Chain

Our recently published Early Warning paper put forth the idea of leveraging external threat intelligence to better utilize internal data collection, further shortening the window between weaponized attack and ability to detect said attack. But of course, the Devil is in the details and taking this concept to reality means delving into actually putting these ideas into practice. There are number of different types of “threat intelligence” that can (and should) be utilized in an Early Warning context. We’ve already documented a detailed process map and metric model to undertaking malware analysis (check out our Malware Analysis Quant research). Being able to identify and search for those specific indicators of compromise on your devices can be invaluable to determine the extent of an outbreak. But what can be done to identify malicious activity, if you don’t have the specific IoCs for the malware in question? That’s when we can look at the network to yield information about what may be a problem, even if the controls on the specific device fail. Why look at the network? Obviously it’s very hard to stage attacks, move laterally within an organization, and achieve the objective of data exfiltration without relying on the network. This means the attackers will necessarily leave a trail of bits on the network, which can provide a powerful indication of the kinds of attacks you’re seeing and which devices on your network are already compromised. In Network-based Threat Intelligence: Searching for the Smoking Gun, we’ll going to dig into these network-based indicators and share tactics to leverage these indicators quickly to identify compromised devices. Hopefully shortening this detection window helps to contain imminent damage and prevent data loss. Finally we’ll discuss how this approach allows you to iterate towards a true Early Warning System. We’d like to thank our friends at Damballa for licensing the content at the end of the project, but as always we’ll be developing the research independently in accordance with our Totally Transparent Research methodology. With that pre-amble done, in order to understand how to detect signs of malware on your network, you need to understand how malware gains a presence in a network, spreads within that network, and finally moves the data outside of the network. That’s become known in industry parlance as The Kill Chain. Describing the Attack There has been plenty of research done through the years about how malware does it’s nefarious dealings. The best description of the Kill Chain we’ve seen was done back in 2009 by Mike Cloppert, which we recommend you check out for yourself. To highlight Mike’s terminology, let’s describe (at a high level) how malware works. Source: Security Intelligence: Attacking the Kill Chain Reconnaissance: The attackers first profile their targets. Understanding how the target organization is structured, gleaning information about the control set, and assembling information that can be used in social engineering attacks. Weaponization: Next comes preparing malware to exploit a vulnerability on the device. This involves the R&D efforts to find these exploits, which allow the attacker to gain control of the victim’s device, and the development of a delivery system to get the exploit onto the target device. Delivery: Once the exploit is weaponized, it needs to be delivered to the target. This usually means some kind of effort to get the target to take an action (usually clicking on a link or using an application attack) that would render a web page to deliver the malware. Exploitation: This is the actual running of the exploit code on the target device to provide the attacker with control of the device. This can be a pretty complicated process and take advantage of known or unknown vulnerabilities in either the operating system or application code. Nowadays this tends to be a multi-stage process where a downloader gains control of the machine and then downloads additional exploit code. Another focus of this step is obfuscation of the attack to hide the trail of the attackers and stay below the radar. C2: Known nowadays as Command and Control, this is the process of the newly compromised device establishing contact with the network to receive further instructions. Exfiltration: Once the attackers achieve their goals of their mission, they must package up the spoils and move it to a place where they can pick it up. Again, this can be a rather sophisticated endeavor to evade detection of the stolen data leaving the organization. There has been significant innovation in a number of the aspects of the kill chain, but overall the process remains largely the same. Let’s talk a bit about how each step in the process has evolved over the past 3 years. Let’s start with reconnaissance, since that’s become far easier now that lots of targets seem to publish their life story and sordid details on public social networks. There are tools today (like Maltego) that can automatically assemble a fairly detailed profile of a person by mining social networks. Despite the protestations of many security professionals, folks aren’t going to stop sharing their information on social networks, and that is going to make the attackers recon efforts that much easier. In terms of weaponization, we’ve seen increasing sophistication and maturity in terms of how the exploits are developed and updated. Besides a third party market for good exploits creating a significant economic opportunity for those willing to sell their exploits, you see attackers using modern software development techniques like Agile programming, as well as undertaking sophisticated testing of the attack against not only the targets, but the majority of security software products designed to stop the attack. Finally, attackers now package up their code into “kits” foruse by anyone with a checkbook (or BitCoin account). So sophisticated malware is now within reach of unsophisticated attackers. Awesome. In terms of the delivery step, as mentioned above, given the rapid change inherent to malware many attackers opt to deliver a very small downloader onto the compromised device. Once C&C contact is established, the downloader will receive a

Read Post

Incite 2/6/2013: The Void

It’s over. Sunday night, when the confetti fell on the Ravens and we finished cleaning up the residual mess from the Super Bowl party, the reality set in. No NFL for months. Yeah, people will start getting fired up about spring training, but baseball just isn’t my thing. Not as a spectator sport. I can take some comfort that in the NFL being a 12-month enterprise now. In a few weeks the combine will give us a look at the next generation of football stars. Then we’ll start following free agency in early March to see who is going to be in and who is out. It’s like Project Runway, but with much higher stakes (and no Tim Gunn). I guess there are other sports to follow, like NCAA Basketball. The March Madness tournament is always fun. Until I’m blown out of all my brackets – then it’s not so fun anymore. But it’s not football. There will be flurries of activity throughout the year. Like when the schedule makers publish the 2013 NFL matchups in mid-April. I dutifully spend a morning putting all the games in my calendar. If only to make sure I don’t schedule business travel around those times. Lord knows, I only get 10-12 opportunities a year to see NFL football live, and no business trip is going to impact that. A man must have his priorities. Then the draft happens at the end of April. Between free agency and the draft you can start to envision what your favorite team will look like next season. Even through the void of no games, there are always shiny football objects to obsess about. If you are a Patriots fan, you can live vicariously through the Gronk throughout the offseason. First he’s making out with some girl, then he’s doing some wacky dance and falling on his $54 million forearm. It’s good to be the Gronk, evidently. Though you figure if he’s making $9MM a year, he could afford a T-shirt, right? There is also an NFL punditry machine that never sleeps. It’s like the security echo chamber times eleventy billion. Hundreds of bloggers, writers, and ponitificators stirring the pot every day. They tweet incessantly and keep our attention focused on even the most minute details. If they aren’t covering the exploits of the Gronk, they are worrying about this guy’s contract negotiations, that guy’s salary cap number, which sap ended up on the waiver wire, some new dude’s endorsement deal, or that other guy’s rehab. No detail is too small to be tweeted and retweeted 20 times in the offseason. Then the real void sets in. After the draft analysis and re-analysis finishes up sometime in May, and they do the OTAs and other activities, things go dead until August. But by that point summer has begun, the kids are off at camp, and life is good. I’m trying to live more in the present, so taking a respite and maybe getting some work done won’t be a bad thing. Before we blink it will be time for training camp in August. At least it’s not hot in Atlanta that time of year. But we persevere anyway and pack up the car, lather on the sunscreen, and watch our modern-day gladiators installing new plays and scheming up ways to keep us on the edge of our seats for another season. We’ll wait in line to get the signature of some 3rd-string linebacker and be ecstatic. Why? Because it means the void will be ending soon. And soon enough Labor Day will usher in another season. –Mike Photo credits: Void originally uploaded by Jyotsna Sonawane Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Understanding Identity Management for Cloud Services Architecture and Design Integration Newly Published Papers Building an Early Warning System Implementing and Managing Patch and Configuration Management Defending Against Denial of Service Attacks Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments Pragmatic WAF Management: Giving Web Apps a Fighting Chance Incite 4 U Remembering the basics: Peter Wayner offers a great set of code development security tips. The cynic in me immediately asked, “Where do you get the time to implement these tips?” and “When does the time come to build tools, or when is it time to spend money on security testing products?” But when you look closer, he has chosen tips which are simply good development practices that make code most robust and more stable … they lead to higher-quality code. Rigorous input testing, modular (read: insulated) design, avoiding too many trust assumptions, building on certified code libraries, and so on, are all simply good programming methods. This advice is not “bolt security on”, but instead to embrace good design and implementation techniques to improve security. Good stuff! – AL A new disclosure FAIL: Imagine you are a product vendor who actually cares about security. Someone reports a very serious exploit, says it’s being used in common exploit kits, and it could allow attackers to bypass all your security controls and pwn whoever they want. Not a good day. But you are a proactive type, so you engage your product security incident team and get cracking. Except, as recently discussed by Adobe, all you have is a video of the exploit, no vulnerability details, and eventually the researchers cut off contact. Alrighty then, what next? Rather than forgetting about it, Adobe tried their best to run down potential exploit options and bump up some security fixes that may or may not fix the potential problem, which may or may not be real. I give Adobe a ton of crap for all the security problems in their products, but the security folks definitely deserve some credit for trying their best

Read Post

RSA Conference Guide 2013: Data Security

Between WikiLeaks imploding, the LulzSec crew going to jail, and APT becoming business as usual, you might think data security was just so 2011, but the war isn’t over yet. Throughout 2012 we saw data security slowly moving deeper into the market, driven largely by mobile and cloud adoption. And slow is the name of the game – with two of our trends continuing from last year, and fewer major shifts than we have seen in some other years. You might mistake this for maturity, but it is more a factor of the longer buying cycles (9 to 18 months on average) we see for data security tools. Not counting the post-breach panic buys, of course. Cloud. Again. ‘Nuff Said? Yes, rumor is strong that enterprises are only using private cloud – but it’s wrong. And yes, cloud will be splattered on every booth like a henchman in the new Aaarnoold movies (he’s back). And yes, we wrote about this in last year’s guide. But some trends are here to stay, and we suspect securing cloud data will appear in this guide for at least another couple years. The big push this year will be in three main areas – encrypting storage volumes for Infrastructure as a Service; a bit of encryption for Dropbox,, and similar cloud storage; and proxy encryption for Software as a Service. You will also see a few security vendors pop off their own versions of Dropbox/, touting their encryption features. The products for IaaS (public and private) data protection are somewhat mature – many are extensions of existing encryption tools. The main thing to keep in mind is that, in a public cloud, you can’t really encrypt boot volumes yet so you need to dig in and understand your application architecture and where data is exposed before you can decide between options. And don’t get hung up on FIPS certification if you don’t need FIPS, or will you limit your options excessively. As for file sharing, mobile is the name of the game. If you don’t have an iOS app, your Dropbox/Box/whatever solution/replacement is deader than Ishtar II: The Musical. We will get back to this one in a moment. There are three key things to look for when evaluating cloud encryption. First, is it manageable? The cloud is a much more dynamic environment than old-school infrastructure, and even if you aren’t exercising these elastic on-demand capabilities today, your developers will tomorrow. Can it enable you keep track of thousands of keys (or more), changing constantly? Is everything logged for those pesky auditors? Second, will it keep up as you change? If you adopt a SaaS encryption proxy, will your encryption hamper upgrades from your SaaS provider? Will your Dropbox encryption enable or hamper employee workflows? Finally, can it keep up with the elasticity of the cloud? If, for example, you have hundreds of instances connecting to a key manager, does it support enough network sockets to handle a distributed deployment? If encryption gets in the way, you know what will happen. Is that my data in your pocket? BYOD is here to stay, as we discussed in the Key Themes post, which means all those mobile devices you hate to admit are totally awesome will be around for a while. The vendors are actually lagging a bit here – our research shows that no-one has really nailed what customers want from mobile data protection. This has never stopped a marketing team in the history of the Universe. And we don’t expect it to start now. Data security for BYOD will be all over the show floor. From network filters, to Enterprise DRM, with everything in between. Heck, we see some MDM tools marketed under the banner of data security. Since most organizations we talk to have some sort of mobile/BYOD/consumerization support project in play, this won’t all be hype. Just mostly. There are two things to look for. First, as we mentioned in Key Themes, it helps to know how people plan to use mobile and personal devices in your workplace. Ideally you can offer them a secure path to do what they need to solve their business problems, because if you merely block they they will find ways around you. Second, pay close attention to how the technology works. Do you need a captive network? What platforms does it support? How does it hook into the mobile OS? For example, we very often see features that work differently on different platforms, which has a major impact on enterprise effectiveness. When it comes to data security, the main components that seem to be working well are container/sandboxed apps using corporate data, cloud-enhanced DRM for inter-enterprise document sharing, and containerized messaging (email/calendar) apps. Encryption for Dropbox/ is getting better, but you really need to understand whether and how it will fit your workflows (e.g., does it allow personal and corporate use of Dropbox?). And vendors? Enough of supporting iOS and Windows only. You do realize that if someone is supporting iOS, odds are they have to deal with Macs, don’t you? Shhh. Size does matter Last year we warned you not to get Ha-duped, and good advice never dies. There will be no shortage of Big Data hype this year, and we will warn you about it continually throughout the guide. Some of it will be powering security with Big Data (which is actually pretty nifty), some of it will be about securing Big Data itself, and the rest will confuse Big Data with a good deal on 4tb hard drives. Powering security with Big Data falls into other sections of this Guide, and isn’t necessarily about data security, so we’ll skip it for now. But securing Big Data itself is a tougher problem. Big Data platforms aren’t architected for security, and some even lacking effective access controls. Additionally, Big Data is inherently about collecting massive sets of heterogenous data for advanced analytics – it’s not like you could just encrypt a single column.

Read Post

Bamital botnet shut down

Microsoft and Symantec today announced they have jointly taken down the command and control infrastructure of the Bamital botnet, which managed a massive click-fraud scheme. From Yahoo news: The companies said that the Bamital operation hijacked search results and engaged in other schemes that the companies said fraudulently charge businesses for online advertisement clicks. Bamital’s organizers also had the ability to take control of infected PCs, installing other types of computer viruses that could engage in identity theft, recruit PCs into networks that attack websites and conduct other types of computer crimes. Now that the servers have been shut down, users of infected PCs will be directed to a site informing them that their machines are infected with malicious software when they attempt to search the web. While they had judicial approval to perform the takedown, it’s interesting that they have rendered upwards of a million PCs unable to use the Internet. Click-fraud is technically easy and amazingly profitable, but it’s not something I have often seen law enforcement go after. Some additional details are on the Microsoft blog, and malware cleanup tools are available on the Microsoft Support Site in case your machine was infected. Share:

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.