Research

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:

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:

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:

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 secure@microsoft.com. 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: