Death, Taxes, and M&A

Ben Franklin was a pretty smart dude. My favorite quote of his is: “In this world nothing is certain but death and taxes.” For a couple hundred years, that was pretty good. But at this point, I’ll add mergers and acquisitions as the third certainty in this world. Maybe also that your NCAA bracket will get busted by some college you’ve never heard of (WTF VCU?). We saw this over the weekend. AT&T figures it’s easier and cheaper to drop $39 billion buying T-mobile than build their own network (great analysis by GigaOm) or gain market share one customer at a time. And in security, there are always plenty of deals happening or about to happen. Remember, security isn’t a standalone market over time, so pretty much all security companies will be folded into something or other. Take, for instance, WebSense trying to sell for $1 billion. And no, I’m not going to comment on whether WBSN is worth a billion. That’s another story for another day. Or the fact that given Intel’s balance sheet, McAfee will likely start taking down bigger targets. All we can count on is that there will be more M&A. But let’s take a look at why deals tend to be the path of least resistance for most companies. Outsourced R&D: Anyone who’s ever worked in a large company knows how hard it is to innovate internally. There is a lot of inertia and politics to overcome to get anything done. In many cases it’s easier to just buying some interesting technology, since the buyer has a snowball’s chance in hell of building it in-house. Distribution leverage: There are clear economies of scale in most businesses. So the more stuff in a rep’s bag and the bigger their market share, the more likely they’ll be able to sell something to someone. That’s what’s driving Big IT to continue buying everything. This also drive deals like AT&T/T-Mobile, because they are buying not just the network, but also the customers. Two drunks holding each other up: Yep, we also see deals involving two struggling companies, basically throwing a hail mary pass in hopes of surviving. That doesn’t usually work out too well. And those are just off the top of my head. I’m sure there are another 5-10 reasonable justifications, but from an end-user standpoint let’s cover some of the planning you have to make for the inevitable M&As. We will break the world up into BD (before deal) and AD (after deal). Before Deal: Assess vendor viability: First assess all your security vendors. Rank them on a scale from low viability (likely to be acquired or go out of business) to rock solid. Assess product criticality: Next look at all your security products and rate them on a scale from non-critical to “life is over if it goes down.” Group into quadrants: Using vendor viability and product criticality, you can group all your products into a few buckets. I recommend 4 because it’s easy. This chart should give you a good feel for what I’m talking about. Define contingency plans: For products in the “Get Plan B now” bucket, make sure you have clear contingency plans. For the other quadrants, think about what you’d do if there was M&A activity for those offerings, but they are less urgent than having a plan for the critical & fragile items. After Deal: Call your rep: Odds are your rep will be a pretty busy guy/gal in the days after a deal is announced. And there is a high likelihood they won’t know any more than you. But get in line and hear the corporate line about how nothing will change. Yada yada yada. Then, depending how much leverage you have, ask for a meeting with the buyer’s account team. And then extract either some pricing or product concessions. The first renewal right after a deal closes is the best time to act. They want to keep you (or the deal looks like crap), so squeeze and squeeze hard. Call the competition: Yes, the competition will be very interested in getting back in, hoping they can use the deal’s uncertainty as a wedge. Whether you are open to swapping out the vendor or not, bring the other guys in to provide additional leverage. Revisit contingency plans: You might have to pull the trigger even if you don’t want to, so it’s time to take the theoretical plan you defined before the deal, and adjust it for reality now that the deal has occurred. Evaluate what it would take to switch, assess the potential disruption, and get a very clear feel for how tough it would be to move. Don’t to share that information with vendors, but you need it. None of this stuff is novel, but it’s usually a good reminder of the things you should do, but may not get around to. Given the number of deals we have seen already this year, and the inevitably accelerating deal flow, it’s better to be safe than sorry. Share:

Read Post

FAM: Core Features and Administration, Part 1

Now that we understand the technical architecture, let’s look at the principal features seen across most File Activity Monitoring tools. Entitlement (Permission/Rights) Analysis and Management One of the most important features in most FAM products is entitlement (permission) analysis. The tool collects all the file and directory permissions for the repository, ties them back to users and groups via directory integration, and generates a variety of reports. Knowing that an IP address tried to access a file might be somewhat useful but practical usefulness requires that policies be able to account for users, roles, and their mappings to real-world contexts such as business units. As we mentioned in the technical architecture section; all FAM products integrate with directory servers to gather user, group, and role information. This is the only way tools can gather sufficient context to support security requirements, such as tracing activity back to a real employee rather than just a username that might not indicate the person behind it. (Not that FAM is magic – if your directories don’t contain sufficient information for these mappings you still might have a lot of work to trace back identities). At the most basic level a FAM tool uses this integration to perform at least some minimal analysis on users and groups. The most common is permission analysis – providing complete reports on which users and groups have rights to which directories/repositories/files. This is often a primary driver for buying the FAM tool in the first place, as such reports are often required for compliance. Some tools include more advanced analysis to identify entitlement issues – especially rights conflicts. For example, you may be able to identify which users in accounting also have engineering rights. Or list users with multiple roles that violate conflict of interest policies. While useful for security, these capabilities can be crucial for finding and fixing compliance issues. A typical rights analysis will collect existing rights, map them to users and groups, help identify excessive permissions, and identify unneeded rights. Some examples are: Determine which users outside engineering have rights to engineering documents. Find which users with access to healthcare records also have access to change privileges, but aren’t in an administrative group. Identify all files and repositories the accounting group has access to, and then which other groups also have access to those files. Identify dormant users in the directory who still have access to files. Finally, the tool may allow you to manage permissions internally so you don’t have to manually connect to servers in order to make entitlement changes. Secure Aggregation and Correlation As useful as FAM is for a single repository, its real power becomes clear as you monitor larger swaths of your organization and can centrally manage permissions, activities, and policies. FAM tools use a similar architecture to Database Activity Monitoring – with multiple sensors, of different types, sending data back to the central management server. This information is normalized, stored in a secure repository, and available for a variety of analyses and reports. As a real-time tool the information is also analyzed for policy violations and (possible) enforcement actions, which we will discuss later. The tools don’t care if one server is a NAS, another a Windows server, and the last a supported document management system – it’s capable of reviewing all their contents consistently. This aggregation also supports correlation – meaning you can build policies based on activities occurring across different repositories and users. For example, you can alert on unusual activity by a single user across multiple file servers, or on multiple user accounts all accessing a single file in one location. Essentially, the FAM tool gives you a big picture view of all file activity across monitored repositories, with various ways of building alerts and analyzing the data, from a central management server. If your product supports multiple file protocols, it will present this in a consistent, activity-based format (e.g., open, delete, privilege change, etc.). Activity Analysis While understanding permissions and collecting activity are great, and may be all you need for a compliance project, the real power of FAM is its capability to monitor all file activity (at the repository level) in real time, and generate alerts, or block activity, based on security policies. Going back to our technical architecture: activity is collected via network monitoring, software agent, or other application integration. The management server then analyzes this activity for policy violations/warnings such as: A user accessing a repository they have access to, but have not accessed within the past 180 days. A sales employee downloading more than 5 customer files in a single day. Any administrator account accessing files in a sensitive repository. A new user (or group) being given rights to a sensitive directory. Any user account copying an entire directory from an engineering server. A service account accessing files. Some tools allow you to define policies based on a sensitivity tag for the repository and user groups (or business units), instead of having to manually build policies on a per-repository or per-directory level. This analysis doesn’t necessarily need to happen in real time – it can also be done on a scheduled or ad hoc basis to support a specific requirement, such as an auditor who wants to know who accessed a file, or as part of an incident investigation. We’ll talk more about reporting later. Data Owner Identification Although every file has an ‘owner’, translating that to an actual person is often a herculean process. Another primary driver of File Activity Monitoring is to help organizations identify file owners. This is typically done through a combination of privilege and activity analysis. Privileges might reveal a file owner, but activity may be more useful. You could build a report showing the users who most often access a file, then correlate that to who also has ownership permissions, and the odds are they will help quickly identify the file owner. This is, of course, much simpler if the tool was already monitoring a repository and can identify who initially created the file.

Read Post

RSA Releases (Almost) More Information

As this is posting, RSA is releasing a new SecureCare note and FAQ for their clients (Login required). This provides more specific prioritized information on what mitigations they recommend SecurID clients take. To be honest they really should just come clean at this point. With the level of detail in the support documents it’s fairly obvious what’s going on. These notes are equivalent to saying, “we can’t tell you it’s an elephant, but we can confirm that it is large, grey, and capable of crushing your skull if you lay down in front of it. Oh yeah, and it has a trunk and hates mice.” So let’s update what we know, what we don’t, what you should do, and the open questions from our first post: What we know Based on the updated information… not much we didn’t before. But I believe RSA understands the strict definition of APT and isn’t using the term to indicate a random, sophisticated attack. So we can infer who the actor is – China – but RSA isn’t saying and we don’t have confirmation. In terms of what was lost, the answer is, “an elephant” even if they don’t want to say so. This means either customer token records or something similar, and I can’t think of what else it could be. Here’s a quote from them that makes it almost obvious: To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful attack, someone would need to have possession of all this information. If it were a compromise of the authentication server software itself, that statement wouldn’t be accurate. Also, one of their top recommendations is to use long, complex PINs. They wouldn’t say that if the server was compromised, which means it pretty much has to be related to customer token records. This also leads us to understand the nature of a potential attack. The attacker would need to know the username, password/PIN, and probably the individual assigned token. Plus they need some time and luck. While extremely serious for high-value targets, this does limit potential exposure. This also explains their recommendations on social engineering, hardening the authentication server, setting PIN lockouts, and checking logs for ongoing bad token/authentication requests. I think his name is Babar. What we don’t know We don’t have any confirmation of anything at this point, which is frankly silly unless we are missing some major piece of the puzzle. Until then it’s reasonable to assume a single sophisticated attacker (with a very tasty national cuisine), and compromise of token seeds/records. This reduces the target pool and means most people should be in good shape with the practices we previously recommended (updated below). One big unknown is when this happened. That’s important, especially for high-value targets, as it could mean they have been under attack for a while, and opponents might have harvested some credentials via social engineering or other means already. We also don’t know why RSA isn’t simply telling us what they lost. With all these recommendations it’s clear that the attacker still needs to be sophisticated to pull off more attacks with the SecurID data, and needs to have that data, which means customer risk is unlikely to increase if they reveal more. This isn’t like a 0-day vulnerability, where merely knowing it’s out there is a path to exploitation. More information now will only reduce customer risk. What you need to do Here are our updated recommendations: Remember that SecurID is the second factor in a two-factor system… you aren’t stripped naked (unless you’re going through airport security). Assuming it’s completely useless now, here is what you can do: Don’t panic. Although we don’t know a lot more, we have a strong sense of the attacker and the vulnerability. Most of you aren’t at risk if you follow RSA’s recommendations. Many of you aren’t on the target list at all. Talk to your RSA representative and pressure them for increased disclosure. Read the RSA SecureCare documentation. Among other things, it provides the specific things to look for in your logs. Let your users with SecurIDs know something is up and not to reveal any information about their tokens. Assume SecureID is no longer effective. Review passwords/PINs tied to SecurID accounts and make sure they are strong (if possible). If you change settings to use long PINs, you need to get an update script from RSA (depending on your product version) so the update pushes out properly. If you are a high-value target, force a password change for any accounts with privileges that could be seriously damaging (e.g., admins). Consider disabling accounts that don’t use a password or PIN. Set authentication attempt lockouts (3 tries to lock an account, or similar). The biggest changes are a little more detail on what to look for, which supports our previous assumptions. That and my belief their use of the term APT is accurate. Open questions I will add in my own answers where we have them: While we don’t need all the details, we do need to know something about the attacker to evaluate our risk. Can you (RSA) reveal more details? Not answered, but reading between the lines this looks like true APT. How is SecurID affected and will you be making mitigations public? Partially answered. More specific mitigations are now published, but we still don’t have full information. Are all customers affected or only certain product versions and/or configurations? Answered – see the SecureCare documentation, but it seems to be all current versions. What is the potential vector of attack? Unknown, so we are still assuming it’s lost token records/seeds, which means the attacker needs to gather other information to successfully make an improper authentication request. Will you, after any investigation is complete, release details so the rest of us can learn from your victimization? Answered. An RSA contact told me they have every

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.