Securosis

Research

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:

Share:
Read Post

Latest to notice

In response to this SC Magazine article (thanks @pauljudge), I tweeted: An important distinction to keep in mind when you read these articles. Share:

Share:
Read Post

New Paper: Understanding and Selecting a Key Management Solution

Yep – we are doing our very best to overload you with research this year. Here’s my latest. From the paper’s home page: Between new initiatives such as cloud computing, and new mandates driven by the continuous onslaught of compliance, managing encryption keys is evolving from something only big banks worry about into something which pops up at organizations of all sizes and shapes. Whether it is to protect customer data in a new web application, or to ensure that a lost backup tape doesn’t force you to file a breach report, more and more organizations are encrypting more data in more places than ever before. And behind all of this is the ever-present shadow of managing all those keys. Data encryption can be a tricky problem, especially at scale. Actually all cryptographic operations can be tricky; but we will limit ourselves to encrypting data rather than digital signing, certificate management, or other uses of cryptography. The more diverse your keys, the better your security and granularity, but the greater the complexity. While rudimentary key management is built into a variety of products – including full disk encryption, backup tools, and databases – at some point many security professionals find they need a little more power than what’s embedded in the application stack. This paper digs into the features, functions, and a selection process for key managers. Understanding and Selecting a Key Manager (PDF) Special thanks to Thales for licensing the content. Share:

Share:
Read Post

Great security analysis of the Evasi0n iOS jailbreak

Thanks to your friends at Accuvant labs. Very worth reading for security pros. Peter Morgan, Ryan Smith, Braden Thomas, and Josh Thomas did an excellent job breaking it down. Here’s the security risk: One important point to make is that unlike the previous jailbreakme.com exploits, which could be used against an unwitting victim, jailbreaks that require USB tethering have a lower security impact, and are usually only useful to the phone’s owner. Attackers are less interested because iPhones with a passcode set will refuse to communicate over USB if they are locked, unless they have previously paired with the connecting computer. So your phone is stolen and it’s locked, attackers won’t be able to jailbreak it. Therefore, only malicious code already running on your computer can leverage USB jailbreaks nefariously. In case you didn’t know, iOS devices that pair with a computer will re-pair with other user accounts on that computer. It is device-based, not user account based. Share:

Share:
Read Post

RSA Conference Guide 2013: Key Themes

It’s that time of year again. Time to get ready for a week of mayhem, debauchery, and the hunt for tchotchkes. OK, there isn’t a lot of debauchery at the RSA Conference besides the Barracuda party at the Gold Club, which we hear is an establishment of high repute. Realistically, you’ll spend most of your week fending off sales droids, gawking at booth babes (much to the chagrin of the security echo chamber), and maybe learning something about what’s new and exciting in security. As in previous years, your pals at Securosis have put together our 4th annual RSA Guide to give you some perspective on what to expect at the show and some of our key trends for the upcoming year. And we even include the snark for free. These themes are compiled and written by the entire Securosis team, so don’t pay too much attention to the posting author when you call us out. We’ll give you blog-reading faithful an early look, over the next 10 days, at what we expect to see at the show. So today we start with the key themes… Anti-Malware Everywhere Security folks have been dealing with malicious software since the days when your networking gear came with a swoosh on it. Yes, you young whippersnappers – back when sneakernet was the distribution vector for viruses. But what’s old is new again, and driven by advanced attackers who figured out that employees like to click on things, we expect almost every vendor at the show to be highlighting their ability to not block advanced attacks. Oh, was that a Freudian slip? Yes, you’ll hear a lot about newfangled approaches to stop advanced malware. The reality remains that sophisticated attackers can and will penetrate your defenses, regardless of how many shiny objects you buy to stop them. That doesn’t mean you should use 5-year-old technology to check the compliance box, but that’s another story for another day. Of course, kidding aside, there will be some innovative technologies in play to deal with this malware stuff. The ability to leverage cloud-based sandboxes that block malware on the network, advanced endpoint agents that look an awful lot like HIPS that works better, and threat intelligence services to learn who else got pwned and by what, are poised to improve detection. Of course these new tools aren’t a panacea, but they aren’t the flaming pile of uselessness that traditional AV has become. Many of the emerging products and services are quite young, so there won’t be much substantiation beyond outrageous claims about blocking this attack or that attack. So leave your checkbook at home but spend some time learning about the different approaches to stopping advanced malware. This will be an area of great interest to everyone through 2013. BYOD Is No BS We may not all be Anonymous, but we are certainly all consumers. It seems a little fruit company in Cupertino sparked the imaginations of technology users everywhere, so now the rest of us have to put out the fire. Technology used to be something you used at work, but now it is embedded into the fabric of our daily lives. So we shouldn’t be surprised as the workforce continually demands work tools that keep up with the things the kids are playing with in the back seat. While consumerization of IT is the trend of people bringing consumer-class devices and services into the workplace, BYOD encompasses the policies, processes, and technologies to safely enable this usage. In the past year we have moved beyond the hype stage, and we see more and more companies either developing or implementing their BYOD and general consumerization strategies. This trend won’t go away, you can’t stop it, and if you think you can block it you will get to find a new job. Even the government and financial services companies are starting to crack and take hard looks at supporting consumer devices and services. On the device side we see the core as Mobile Device Management, but MDM is merely the hook to enable all the other interesting technologies and controls. The constantly changing nature of BYOD and varied enterprise cultures will likely keep the market from ever maturing around a small set of options. We will see a huge range of options, from the mostly-mature MDM, to network access gateways (the rebirth of NAC), to containerized apps and security wrappers, to new approaches to encryption and DRM. And each of them is right… for someone. There is no silver bullet, but wandering the show floor is a great opportunity to see all the different approaches in one place and think about where they fit into your strategy and culture. Are you lockdown artists? Free-loving tech hippies? Odds are you can find the pieces to meet your requirements, but it definitely isn’t all completely there yet, regardless of what the sales droids say. The main thing to focus on is whether the approach is really designed for BYOD, or whether it’s just marketed as BYOD. There is a huge difference, and a fair number of vendors haven’t yet adjusted their products to this new reality beyond cosmetic changes. Think hard about which controls and deployment models will fit your corporate culture and, especially, workflows. Don’t look at approaches that take these wonderful consumer experiences and suck the life out of them, reverting to the crappy corporate tech you know you hate yourself. Yes, there will be a lot of hype, but this is a situation where we see more demand than supply at this point. Viva la revolucion! Security Big Data In the past two years at RSA we have heard a lot about risk management and risk reduction, which basically mean efficiently deploying security to focus on threats you face – rather than hypothetical threat scenarios or buying more protection than you need. This year’s risk management will be security analytics. Analytics is about risk identification, but the idea is that big data clusters mine the sea

Share:
Read Post

The Data Breach Triangle in Action

I refer back to Rich’s Data Breach Triangle over and over again. It’s such a clear and concise way to describe a data breach – past or potential. And we continue to see examples of how focusing on breaking one leg of the triangle works. From How the RSA Attackers Swung and Missed at Lockheed Martin on Threatpost: “But instead of closing the door and shutting the attackers out, Lockheed’s team began monitoring their activities to see what they were doing, where they were going and what tactics they used.” The typical incident response playbook involves finding a compromised device and fixing it, but with today’s advanced attacks you can’t be sure you actually have eliminated the threat with a single remediation activity. So in some cases it makes more sense to observe the attackers, rather than [trying to] clean them up immediately. “The lesson, Adegbite said, is that preventing attackers from getting anything useful off a network is far more important than trying to prevent every attacker from getting in. “The investment to stop people from coming in is too high,” he said.” Break the egress leg of the triangle and there is no breach. And that’s why we focus on egress filtering and active protections like DLP in an effort to prevent exfiltration. Share:

Share:
Read Post

Understanding IAM for Cloud Services: Architecture and Design

This post will discuss the architecture and deployment models for identity and access management for cloud services. This is obviously complex – we are covering three different cloud service models (SaaS, PaaS, & IaaS); in three different deployment options (public, private, & hybrid); with a variety of communication protocols to address authentication, authorization, and provisioning. The Cloud Security Alliance has cataloged many different identity ‘standards’, but the fact that we have dozens of standards to choose from illustrates how unresolved this whole field is. Worse, each cloud provider’s standards support is likely to vary (incompatibly) from others in the field – so you will likely need custom code to connect and share identity information. The point is that discussion of IAM ‘standards’ is often a starting point for companies considering cloud identity. But standards alone should not drive architecture – projects are much better driven by use cases and risk. Our goal is to define an overall architecture which fits your organization, and apply appropriate communication standards after that. To help disentangle design from implementation standards, we will introduce design patters to describe the architecture. A design pattern is a universal model that both abstracts and simplifies the structure from underlying environmental complexities. For each use case we will describe a design pattern that address the core challenges of propagating identity information across multiple services. Then we will discuss how IAM technology standards fit within those models. As previously discussed, there are three core cloud IAM use cases: Single Sign-on (SSO), Provisioning, and Attribute Exchange. Delivering on these use cases requires a number of architectural decisions and workarounds for various issues. SSO Architecture and Design: Learning from the Pin Factory One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head: to make the head requires two or three distinct operations: to put it on is a particular business, to whiten the pins is another … and the important business of making a pin is, in this manner, divided into about eighteen distinct operations, which in some manufactories are all performed by distinct hands, though in others the same man will sometime perform two or three of them.”- Adam Smith, 1776 SSO is often implemented using a ‘federation’ model, under which each user’s identity and associated attributes are stored across multiple distinct identity management systems. Which identity management repository within the larger federated group determines whether to validate a user is determined dynamically at request time. Federated identity is tailor-made for the cloud because it cleanly separates responsibilities between the enterprise and the cloud provider. As in Adam Smith’s pin factory, each participant can specialize in the areas they are best able handle, and the identity protocol establishes the mode of exchange between participants. SAML has been the dominant standard in this area, used by enterprises and cloud providers to coordinate SSO. SSO architectures implement one or more Identity Providers (IDPs) which act as authoritative sources for account information. The IDP is generally on the enterprise side, but may also be kept in a separate external IDP cloud. While SAML is the runtime identity protocol for SSO exchanges, the IDP is the linkage point between the service provider (the external application) and the provisioning services which manage the accounts (typically the HR database). The Relying Party (RP) is generally implemented on the cloud provider side; its task is to consume and verify identity assertions and ensure proper access rights to the cloud application. The agreement point between the IDP and the RP defines the identity protocol, how it is initiated (from enterprise the and/or cloud provider side), the schema, which attributes are sent, and any additional details. Federated Identity enables the enterprise, as the party with the freshest and most accurate user information, to control and manage accounts. The cloud provider controls the application side, and can consume and use assertions from the enterprise without the burden of user management. Federation enables Single Sign On for an open, interactive application architecture. The technologies that deliver these services place a premium on uptime (measured in “multiple 9s”) and robust performance because of the importance of timely and accurate information from trusted identity source. Given the heavily reliance of cloud services on high-bandwidth low-latency network access, integration with browsers and clients is necessary. Any standard used for federation must be resilient in the face of privacy and integrity attacks, at both browser and protocol layers. Provisioning Architecture and Design: Process Automation Provisioning systems are architected very differently than the SSO/federated systems discussed above. Provisioning is less about architecture and more about process, with a focus on how and when systems communicate. Provisioning systems don’t need real-time synchronization – they often run in batch mode, perhaps hourly or even daily. Provisioning systems are used as back-office support applications, so design requirements center around integration – largely having to do with the byzantine protocols necessary to communicate with directories and vendor packages. The good news in terms of security is that these services are less exposed than other systems, requiring neither browser integration nor direct exposure to users. Provisioning processes such as ‘onboarding’ new users, updating accounts, and managing users, are highly automated. The back-end processes to update and synchronize data are critical in traditional on-premise IAM systems, to ensure users don’t unwarranted access to data, and that former employees do not retain system access rights. Extending these functions beyond the corporate IT perimeter is inherently difficult. Like football referees, these systems are only visible to users when they fail. The unique aspect of provisioning cloud applications is its focus on process automation across a least two companies – the enterprise and the cloud provider. We don’t hear many success stories of process automation across multiple companies. Fortunately the handoff of accounts to the cloud provider is relatively simple. There are tree key architecture decisions for provisioning systems, but in the end they all come down to

Share:
Read Post

If Not Java, What?

You have probably noticed some security issues with Java lately. Some vendors – including Apple – are blocking Java in order to close known and unforeseen security problems. And the claim that open source Java frameworks pose a business risk. But through this latest flame war, I have not seen an answer to the basic question: If not Java, what? If you’re going to get Java out of the enterprise to address a security risk and replace it with something else, what would you select? Do we really have evidence that platforms like Ruby, JSON, or Node.js are more secure? Clojure and Scala rely on a JVM and the same frameworks as Java, so they cannot be more secure than the shared JVM. And remember, Java also does a few things very well, which is why it has become so popular over the last 15 years. It has a very good object model. Cross-platform compatibility. Easy to learn syntax. Extensible. Tons of tools. Easy integration. All reasons why I think we have proven C++ and C# are not replacements. I really don’t have an answer for this question. But I think I can say, in the same way that we can’t go back and rewrite all insecure code because there is is not enough time or money to do it, we are not going to throw Java out because it’s insecure. We can make a decision to block it from the browser, but that does not address the myriad ways Java is used in the enterprise. In fact I don’t even see an alternative that would enable us to begin migrating off. Share:

Share:
Read Post

Improving the Hype Cycle

Gartner’s Hype Cycle is one of my favorite market models. It very succinctly describes the ridiculous way PR and other external hype factors make more of a technology than it really is. When many of us show up at the RSA Conference at the end of the month, we will get our best view of the Hype Cycle in action. Most of the stuff very hyped at the show tends to be (roughly) 12 to 18 months from hitting, if it ever does. But as with any industry research, where something lands in the Hype Cycle is open to interpretation and opinion. It’s as squishy as can be – there are no real attributes that can pinpoint where in the hype cycle any technology fits. These factors may exist, but the Big G certainly doesn’t talk about them. And when I see someone saying an over-hyped technology like Big Data has hit the “trough of disillusionment”, I scratch my head. Gartner Inc. said that Big Data has fallen into a “trough of disillusionment,” due to its complexity. The research firm said current obstacles to adoption could be eliminated, though, as Big Data tools such as Hadoop are integrated into mainstream analytic applications. You can’t really disagree with that statement, but I’d still say Big Data is closer to the peak of inflated expectations than to the trough. It’s not like a zillion companies have tried and failed at their Big Data deployments. These folks are still trying to figure out what Hadoop and MapReduce are. This kind of pronouncement is meant to push the market along, facilitate the integration that needs to happen over time to provide more demonstrable and sustainable value to customers. But there is still something missing from this kind of analysis. It would be very helpful to overlay some kind of growth and/or market size numbers onto the Hype Cycle. So when a technology is climbing the cycle, market size is relatively small but growth is off the chart. As it descends into the trough the number of customers grows, but market growth slows as companies struggle to effectively institutionalize the technology. And then as it exits the trough into the plateau of productivity, revenues start to grow again significantly but at a more predictable rate. But public revenue and growth metrics for private companies are about as much hype as these technologies. But that’s the missing piece (IMO) to really understand where these markets are in their development. Or am I still hammered from yesterday’s Super Bowl festivities and talking nonsense? Photo credit: “Hype” originally uploaded by nouspique Share:

Share:
Read Post

Prepare for an iOS update in 5… 4… 3…

Evad3rs releases an iOS 6.1 jailbreak for all devices. Update: According to @drscjmm this will not work when a passcode is set, which means we are still in pretty good shape from a security standpoint. Untethered, which means you still need to plug the device into a computer, but the jailbreak lasts across reboots (this is not remotely executable at this time). This means all iOS devices are exposed to hands-on forensics, even with a passcode. Data protection still needs to be broken, but an attacker can jailbreak and install a back door to sniff your password if they have physical control of the device for long enough. if you lose your phone and recover it, wipe it and restore from a known unjailbroken backup. From the jailbreak notes: Please disable the lock passcode of your iOS device before using evasi0n. It can cause issues. I can’t test right now, but will be interesting if a passcode prevents the jailbreak, or is sometimes just an obstacle. Please leave comments if you know or find out. Update: As we said above, a passcode appears to block this jailbreak, which is good. (Hat tip to The Verge for the link). Share:

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.