RSA Acquires Aveksa

EMC has announced the acquisition of Aveksa, one of the burgeoning players in the identity management space. Aveksa will be moved into the RSA security division, and no doubt merged with existing authentication products. From the Aveksa blog: … business demands and the threat landscape continue to evolve, and organizations now expect even more value from IAM platforms. As a standalone company, Aveksa began this journey by connecting our IAM platform to DLP and SIEM solutions – allowing organizations to connect identity context, access policies, and business processes to these parts of the security infrastructure. This has been successful, and also led us to recognize the massive and untapped potential for IAM as part of a broader security platform – one that includes Adaptive Authentication, GRC, Federation, and Security Analytics. At first blush it looks like RSA made a good move, identifying their weakest solutions areas and acquiring a firm that provides many of the missing pieces they need to compete. RSA has been trailing in this space, focusing most of its resources on authentication issues and filling gaps with partnerships rather than building their own. They have been trailing in provisioning, user management, granular role-based access, and – to a lesser extent – governance. Some of RSA’s recent product advancements, such as risk-based access control, directly address customer pain points. But what happens after authentication is the real question, and that the question this purchase is intended to answer. Customers have been looking for platforms that offer the back-end plumbing needed to link together existing business systems, and the Aveksa acquisition correctly targets the areas RSA needs to bolster. It looks like EMC has addressed a need with a proven solution, and acquired a reasonable customer base for their money. We expect to see move moves like this in the mid-term as more customers struggle to coalesce authentication, authorization, and identity management issues – which have been turned on their heads by cloud and mobile computing demands – into more unified product suites. Share:

Read Post

Multitenancy is the Least Interesting Security Property of Cloud Computing

Today I was mildly snarky on the Security Metrics email list when a few people suggested that instead of talking about cloud computing we should talk about shared infrastructure. In their minds, ‘shared’ = ‘cloud’. I fully acknowledge that I may be misinterpreting their point, but this is a common thread I hear. Worse yet, very frequently when I discuss security risks, other security professionals key in on multitenancy as their biggest concern in cloud computing. To be honest it may be the least interesting aspect of the cloud from a security perspective. Shared infrastructure and applications are definitely a concern – I don’t mean to say they do not pose any risk. But multitenancy is more an emergent property of cloud computing rather than an essential characteristic – and yes, I am deliberately using NIST terms. In my humble opinion – please tell me if I’m wrong in the comments – the combination of resource pooling (via abstraction) and orchestration/automation creates the greatest security risk. This is primarily for IaaS and PaaS, but also can apply to SaaS when it isn’t just a standard web app. With abstraction and automation we add a management layer that effectively network-enables direct infrastructure management. Want to wipe out someone’s entire cloud with a short bash script? Not a problem if they don’t segregate their cloud management and harden admin systems. Want to instantly copy the entire database and make it public? That might take a little PHP or Ruby code, but well under 100 lines. In neither of those cases is relying on shared resources a factor – it is the combination of APIs, orchestration, and abstraction. These aren’t fully obvious until you start really spending time using and studying the cloud directly – as opposed to reading articles and research reports. Even our cloud security class only starts to scratch the surface, although we are considering running a longer version where we spend a bunch more time on it. The good news is that these are also very powerful security enablers, as you will see later today or tomorrow when I get up some demo code I have been working on. Share:

Read Post

How Not to Handle a Malware Outbreak

Malware is a pervasive problem in enterprises today. It can often be insidious as hell and difficult to ferret out. But sometimes the response to a malware outbreak defies basic common sense. The CIO for the Economic Development Administration (EDA) thought a scorched earth policy was the best approach… From the Depart of Commerce audit report (.pdf): EDA’s CIO concluded that the risk, or potential risk, of extremely persistent malware and nation-state activity (which did not exist) was great enough to necessitate the physical destruction of all of EDA’s IT components. 20 EDA’s management agreed with this risk assessment and EDA initially destroyed more than $170,000 worth of its IT components,21 including desktops, printers, TVs, cameras, computer mice, and keyboards. By August 1, 2012, EDA had exhausted funds for this effort and therefore halted the destruction of its remaining IT components, valued at over $3 million. EDA intended to resume this activity once funds were available. However, the destruction of IT components was clearly unnecessary because only common malware was present on EDA’s IT systems. And there was this: Not only was EDA’s CIO unable to substantiate his assertion with credible evidence, EDA’s IT staff did not support the assertion of an infection in the e-mail server There are no words to express my complete amazement at this abjectly irresponsible waste of taxpayer dollars. The real rub from the report: There was no widespread malware infection There was no indication of an infection in the e-mail server The fundamental disconnect here is mind-boggling. Share:

Read Post

Kudos: Microsoft’s App Store Security Policy

Today on the Microsoft Security Response Center Blog: Under the policy, developers will have a maximum of 180 days to submit an updated app for security vulnerabilities that are not under active attack and are rated Critical or Important according to the Microsoft Security Response Center rating system. The updated app must be submitted to the store within 180 days of the first report that reproduces the issue. Microsoft reserves the right to take swift action in all cases, which may include immediate removal of the app from the store, and will exercise its discretion on a case-by-case basis. But the best part: If you have discovered a vulnerability in a store application and have unsuccessfully attempted to work with the developer to address it, you can request assistance by contacting Clear, concise, and puts users first. My understanding is that Apple is also pretty tight on suspending vulnerable apps, but they don’t have it formalized into visible policy, with a single contact point. If anyone knows Google’s policy (formal or otherwise), please drop it in the comments, but that is clearly a different ecosystem. 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.