Securosis

Research

We Give Thanks

I admit it’s not even 2:00 in the afternoon and my mind has already gone on vacation. Apple pies are in the oven, and pumpkin pies are queued up and waiting to go in. We decided to forgo the Friday summary this week because we are pretty sure no one would read it even if we wrote one, so we decided on a pre-Thanksgiving “What are we thankful for in security?” post instead. Rich: “I’m thankful for good, old-fashioned human behavior; especially its propensity to never change. Without it, I’d have to find a real job.” Adrian: “I am thankful most attackers exploit well known defects to penetrate defenses … they are so much harder to detect when they are clever. I am thankful for Mordac, Preventer of Information Services, who has created a face for our industry.” Mortman: “I’m thankful for people who think our capabilities are far better then they actually are and as a result don’t do certain things under the assumption that they’d get caught. Without them, I’d have to work much harder.” Chris: “I am thankful that I can get away with spending so little attention on personal security as a Mac user. I am pretty paranoid, but if I’d spent the same attention on securing Windows systems over the past 10 years, I would have been compromised many times. I’m thankful national breach disclosure laws are on the table.” Have a wonderful Thanksgiving holiday! We’ll be back Monday. Share:

Share:
Read Post

M86 Acquires Finjan

Given how much PR email I get on a daily basis – which does help keep me up to date on what’s happening in the market segments I cover – I seldom miss newsworthy security events. On occasion I totally miss something of interest, like the M86 acquisition of Finjan … three freakin’ weeks ago! For those of you interested in email and web security, big firms don’t offer a lot of interesting tidbits to write about, which makes the smaller firms more fun to watch. In a mature market segment like email and web security, small security businesses need to innovate with technology and sales. To compete with established players like Google and Symantec, where “follow the leader” is a bad business strategy, you need to employ creative thinking in order to survive. This acquisition makes me think M86 has a slightly different vision than their competitors. The Finjan product is an interesting mix of capabilities for web security. Primarily they sold appliances, sitting in the enterprise, acting as gateway servers for content security. Enterprise endpoints are configured to go through the gateway for screening. The product is focused on outbound content, with URL, anti-spyware and basic ‘DLP’ content screening (i.e., regular expression checks). The interesting aspects are the introduction of a proxy model not too long ago, sending remote users through a virtual gateway (in the cloud, of course) that screens and then routes requests. In essence they extend a virtual perimeter around the end point. This is sensible, as most firms will want to secure the endpoint and enforce usage policies regardless if the user is at home, on the road or in the office. Their ‘Vital Cloud’ gives users a pathway to a hybrid appliance/SaaS model, so they can leverage existing hardware while gaining access to additional features not supported by their existing hardware. This is not moving your data to the cloud, but instead offloading the service, which matters if your company worries about security of remote data storage. The remote client and SaaS feature, if I understand the technology correctly, is nothing more than a VPN connection to a virtual server with the client policies. Simple, but it should be effective. You have probably noticed that the M86 team has been aggressive with acquisitions, working to create a complete portfolio of features for web content. The merger between 8e6 and Marshal gave them the web and email security pieces needed to compete on a very basic level; those two features are the minimum requirements for entry. But the Avinti acquisition seemed out of place. Rather than a cloud or SaaS play like their competition, they bought a type of behavior analysis tool. Both a powerful and flexible approach to detecting malware in what I was calling virtual Habitrail, but certainly not a novice tool. It required some skill to use, and was not something to put into the hands of your typical 8e6/Marshal customer. What’s more, neither the deployment model nor functions quite fit market trends. But in light of the the Finjan acquisition (and I am guessing here), it looks as if M86 is trying to carve a niche as a managed service platform. For many SMB’s, content and email security is a problem they want to pay to have solved. It’s not just that they don’t want to worry about which box is the right one, but they cannot afford to hire specialists to understand threats, create policies, manage gateways, perform content analysis, create blacklists, detect malware, and all the rest. Managed service providers care less about the deployment, and more about leverage of effort. The merger of these products and deployment models would appeal to companies like Perot / Fishnet / Solutionary / SecureWorks, and so on. They would be able to deal with the complexities of Avinti and specifics of how to set up DLP. Being able to drop in an appliance and couple it with a virtual server in your data center for both monitoring and policy enforcement would be appropriate. Granted, Finjan gives M86 a hybrid deployment model previously missing (8e6 and Marshal were on-site appliance and software companies, respectively), allowing customers to stave off hardware obsolescence and still accommodate new features and overhead associated with new policies, but I still don’t think that’s where they are headed. They cannot compete head to head on uptime, pricing, SaaS options and scalability with Websense, Cisco and Proofpoint, but they can offer a depth of function that should be potent in the right hands. Share:

Share:
Read Post

Health Net Asked to Explain Disclosure Delay

There was a tiny blurb in the Sunday Arizona Republic regarding a request by the Arizona Attorney General to Health Net regarding a data breach notification. It seems they delayed telling anyone that data was stolen or missing for six months or so: Attorney General Terry Goddard wants a Connecticut-based insurance company to tell Arizona policyholders whether their personal, medical or financial information was lost or stolen in a security breach six months ago. Goddard’s office says a hard drive containing personal data on 316,000 current and former Health Net policyholders from Arizona has been missing since May from the company’s headquarters in Shelton, Conn. He says the company did not notify the Arizona Department of Insurance until Wednesday. It’s not clear whether this has anything to do with the breach reported back in February, but from the details provided this appears unrelated, as that was a case of inadvertent disclosure. I did a little more digging and it appears a few other states are getting the same letter, as mentioned in this Computerworld post Health Net says 1.5M medical records lost in data breach: Connecticut A.G. calls six-month delay in reporting loss ‘incomprehensible’. A hard drive with seven years’ worth of personal financial and medical information on about 1.5 million customers of Health Net of the Northeast Inc. was reported missing to state officials yesterday – six months after the drive went missing. Excuse me, but what the $%(@ were the details of 1.5 million Health Net customers doing on a portable device? Is there really a major U.S. firm out there without laptop & media encryption mandated? This comes right on the heels of the BofA data compromise I mentioned last Friday, which also does not appear to have been disclosed. And if Health Net’s attorney’s interpreted Arizona’s law the same way I did, it’s not clear they felt compelled to. If you didn’t read Rich’s post on The Anonymization of Losses: A Market Forces Failure , or Bruce Schneier’s post Security in a Reputation Economy, now is a good time. Both are excellent and both discuss the hidden costs of lax security such as this, along with the lack of market forces necessary to avoid stupid @$$ stuff with patient data. It appears that whatever checks and balances are supposed to be in place to prod health organizations into securing personal, financial, and medical data are absent. If there is no penalty, why change? Share:

Share:
Read Post

Microsoft IE Issues Reported

Over the weekend 0-day exploit was reported in Microsoft Internet Explorer 6 and 7. Both Threatpost and Heise Security posted that the getElementsByTagName() JavaScript method within Microsoft’s HTML viewer has a dangling pointer. This leaves the browser susceptible to code injection; which in the best case crashes the browser, and in a worse case directs you to a malicious site. In first tests by heise Security, Internet Explorer crashed when trying to access the HTML page. Security firm Symantec confirms that, while the current zero day exploit is unreliable, more stable exploit code which will present a real threat is expected to appear in the near future. French security firm VUPEN managed to reproduce the security problem in Internet Explorer 6 and 7 on Windows XP SP3, warning that this allows attackers to inject arbitrary code and infect a system with malicious code. Microsoft has not yet commented on the problem. The workaround is to disable JavaScript until the patch is available. Yeah, yeah, I know, you have heard this before. And this means half the web pages you visit won’t work and every piece of online meeting software is completely hosed, so you will leave it enabled anyway. It was worth a shot. Be careful until you have patched. Another post on the Hackademix site discusses a flaw with the IE 8 XSS filter. … it’s way worse than a simple implementation bug. Its root is a flawed design choice: when a potential XSS attack is detected, IE 8 modifies the response (the content of the target page) in order to neuter the malicious code. This is, incidentally, the only significant departure from the NoScript approach, which modifies the request (the data sent by the client) instead, and is therefore immune. … IE 8’s response-changing mechanism can be easily exploited to turn a normally innocuous fragment of the victim page into a XSS injection. I will update this post when I have additional information from Microsoft on either issue. Share:

Share:
Read Post

Friday Summary – November 20, 2009

Ironically, I was calling to activate my new credit card yesterday – as the number was considered compromised by BofA – when I read about the credit card scam in Spain. Very little information is coming out about the EU Credit Card Breach. Seems to be Visa specific; some 100k cards are being recalled in Germany, and police efforts are focused in Spain. And it seems every news agency and security blog in the country is reliant on this tiny amount of data provided by the BBC. Given this is a multi-country effort, I would have bet some tangible news would have slipped out somewhere, but nothing more than these nuggets of almost nothing yet. On the home front it is pretty much the same: no news of what happened. I was pretty sure that BofA recalling the Visa card meant a serious breach because this is a card I have not used in more than a year. Yes, I am making some assumptions here, but this was not an issue with skimming at a local restaurant or gas station. So someone was breached; going back through two years of records of very limited use, as there are two large firms who had this number in their databases (without my consent) and I am guessing one of them leaked it. This is not directly related to the Citigroup/BofA breach. I was trying to find out what their disclosure responsibilities were here in Arizona, but you could drive a big truck full o’ sensitive data through the holes in the Breach Notification Bill. And the BofA Disclosure Page basically says “we don’t know ‘nuthin ‘bout ‘nuthin’”, but don’t worry, your money will be returned to you. Let’s hope the Europeans get more data than we do. On a more lighthearted note, this video is pretty funny, but I bring it up because I want a third opinion. Do you think a crime was committed? The Mogull pointed something out to me after I watched this … that the girl in the white shirt appears to shoplift in the video. I was skeptical but I think he’s right. At 2:14 in, the girl drops a shopping bag off he shoulder, grabs something off the table, and it places into the bag. She then shoves what looks like a pad of paper on top, pulls the strap back on her shoulder, dancing the entire time. She even performs this maneuver the moment the rest of the ‘dance troupe’ has their backs turned. She is one of a few without a badge and so I assume she was not an employee. Anyway, the whole thing is a little like a car wreck … it’s hard to look away. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s post on A Peek at Transparent Database Encryption. Rich quoted on InZero launch. The dog ate my podcast. No, really! Sorry Martin! Adrian on Encryption ‘Gotchas’ that hinder implementation. (Podcast) Rich and Adrian on Truth, Lies and Fiction with Data Encryption. Favorite Securosis Posts Rich: The Anonymization of Losses: A Market Forces Failure. Adrian: Why You Should Take the Adobe Flash Origin Issues Seriously. Meier: Microsoft Encryption and the Cloud Mort: Ur C0de Sux. Other Securosis Posts What the Renegotiation Bug Means to You Critical Infrastructure, 60 Minutes, and Missing the Point Three acquisitions, two visions ADMP Market Acceptance Why Successful Risk Management is Still a Failure New Thoughts On The CIO Is Your Friend Favorite Outside Posts Rich: Not security-specific, but lasers on fighter jets! Adrian: Not really a single post, but a collection of posts on Microsoft Azure. It’s probably just me, but this feels like 1997, when MS did an about-face on their acceptance of the Internet … only this time they are a little late to the Cloud party. Mort: Google Books Settlement 2.0: Evaluating the Pros and Cons. Meier: Whose customers are they? Pepper: Researcher busts into Twitter via SSL reneg hole. Top News and Posts Verizon admits employees sold private data. Most security products fail to perform. Good analysis by Larry Walsh on Fortinet IPO and some market risks, and for those of you tracking these things, the current stock price. Incite Rides Again. NIST updates infosec guidelines. Four in UK sentenced in connection to banking trojan. Inside the botnet hunters. Metasploit 3.3 released. Hoff launches A6 working group for cloud audits/assessments. Brazilian power company hacked (for real this time). Background checks in an iPhone app. Pentesting Adobe Flex Applications with a Custom AMF Client. Customers have a unique way of capturing your product’s nuances. Blog Comment of the Week It was hard to pick this week, but this week’s best comment comes from our own David Mortman’s in response to David Meier’s post What the Renegotiation Bug Means to You: Okay I tried it: openssl s_client -connect ebay.com:443 -ssl2 New, SSLv2, Cipher is DES-CBC3-MD5 Server public key is 1024 bit SSL-Session: Protocol : SSLv2 Cipher : DES-CBC3-MD5 Session-ID: D5F3FA4A3750154014CE495E96E36139 Session-ID-ctx: Master-Key: 35F5ED93B6FC890AA84EBFCE849E9EE54919C8D3FA38D35F Key-Arg : 63826612A872A6AD Start Time: 1258654301 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) So something thinks it can speak sslv2, however if I force my browser to use only sslv2 it loops before dying so there’s some business logic stopping it. On the other hand, yahoo and hotmail/live.com both allow ssl2 connections no problem as does twitter and lenovo. Btw, so does Bank of America and Fidelity. So while clearly some folks are getting it (because of PCI?), there are some major players who don’t. Btw even the security vendors don’t do it right, McAfee allows SSLv2 only connections (Symantec doesn’t) as does HiTrust (gotta love an organization dedicated to security that screws it up). And my all time favorite, the IRS allows SSLv2 connections and has an invalid cert. So lots of potentially vulnerable sites, which in general make MitM attacks much easier, renegotiation bug or not. Share:

Share:
Read Post

Microsoft Encryption and the Cloud

I was reading PC Magazine’s recap of Ray Ozzie’s announcement of the Azure cloud computing platform. The vision of Azure, said Ozzie, is “… three screens and a cloud,” meaning Internet-based data and software that plays equally well on PCs, mobile devices, and TVs. I am already at a stage where almost everything I want to do on the road I can accomplish with my smartphone. Any heavy lifting on the desktop. I am sure we will quickly reach a point where there is no longer a substantial barrier, and I can perform most tasks (with varying degrees of agility) with whatever device I have handy. “We’re moving into an era of solutions that are experienced by users across PCs, phones and the Web, and that are delivered from datacenters we refer to as private clouds and public clouds. But I read this just after combing through the BitLocker specifications, and the dichotomy of the old school model and new cloud vision seemed at odds. With cloud computing we are going to see data encryption become common. We are going to be pushing data into the cloud, where we do know what security will be provided, and we may not have thoroughly screened the contents prior to moving it. Encryption, especially when the data is stored separately from the keys and encryption engine, is a very good approach to keeping data private and secure. But given the generic nature of the computing infrastructure, the solutions will need to be flexible enough to support many different environments. Microsoft’s data security solution set includes several ways to encrypt data: BitLocker is available for full drive encryption on laptops and workstations. Windows Mobile Device Manager will manage security on your mobile storage and mobile application data encryption. Exchange can manage email and TLS encryption. SQL Server offers transparent and API-level encryption. But BitLocker’s architecture seems a little odd when compared to the others, especially in light of the cloud based vision. It has hardware and BIOS requirements to run. BitLocker has different key management, key recovery, and backup interfaces than laptops and other mobile devices and applications. BitLocker’s architecture does not seem like it could be stretched to support other mobile devices. Given that this is a major new launch, something a little more platform-neutral would make sense. If you are an IT manager, do you care? Is it acceptable to you? Does your device security belong to a different group than platform security? The offerings seem scattered to me. Rich does not see this as an issue, as each solves a specific problem relevant to the device in question and key management is localized. I would love to hear your thoughts on this. I also learned that there is no current plan for Transparent Database Encryption with SQL Azure. That means developers using SQL Azure who want data encryption will need to take on the burden at the application level. This is fine, provided your key management and encryption engine is not in the cloud. But as this is being geared to use with the Azure application platform, you will probably have that in the cloud as well. Be careful. Share:

Share:
Read Post

Three acquisitions, two visions

I had to laugh when I read Alan Shimel’s post “Where does Tipping Point fit in the post-3Com ProCurve”? His comment: I found it insightful that nowhere among all of this did security or Tipping Point get a mention at all. Does HP realize it is part of this deal? Which was exactly what I was thinking when reading the press releases. One of 3Com’s three pillars is completely absent from the HP press clippings I’ve come across in the last couple days. Usually there is some mention of everything, to assuage any fears of the employees and avoid having half the headcount leave for ‘new opportunities’. And the product line does not include the all-important cloud or SaaS based models so many firms are looking for, so selling off is a plausible course of action. It was easy to see why Barracuda purchased Purewire. It filled the biggest hole in their product line. And the entire market has been moving to a hybrid model, outsourcing many of the resource intensive features & functions, and keeping the core email and web security functions in house. This allows customers to reduce cost with the SaaS service and increase the longevity of existing investments. Cisco’s acquisition of ScanSafe is similar in that it provides customers with a hybrid model to keep existing IronPort customers happy, as well as a pure SaaS web security offering. I could see this being a standard security option for cloud-based services, ultimately a cloud component, and part of a much larger vision than Barracuda’s. Which gets me back to Tipping Point and Alan’s question “Will they just spin it out, so as not to upset some of their security partners”? My guess is not. If I was king in charge, I would roll this up with the EDS division acquired earlier this year for a comprehensive managed security services offering. Tipping Point is well entrenched and respected as a product, and both do a lot of business with the government. My guess is this is what they will do. But they need to have the engineering team working on a SaaS offering, and I would like to see them leverage their content analysis capabilities more, and perhaps offer what BlueLane did for VMWare. Share:

Share:
Read Post

Critical Infrastructure, 60 Minutes, and Missing the Point

Here’s the thing about that 60 Minutes report on cybersecurity from the other week. Yes, some of the facts were clearly wrong. Yes, there are massive political fights under way to see who ‘controls’ cybersecurity, and how much money they get. Some .gov types might have steered the reporters/producers in the wrong direction. The Brazilian power outage probably wasn’t caused by hackers. But so what? Here’s what I do know: A penetration tester I know who works on power systems recently told me he has a 100% success rate. Multiple large enterprises tell me that hackers, quite possibly from China, are all over their networks stealing sensitive data. They keep as many out as they can, but cannot completely get rid of them. Large-scale financial cybercrime is costing us hundreds of millions of dollars – and those are just the ones we know about (some of that is recovered, so I don’t know the true total on an annual basis). Any other security professional with contacts throughout the industry talks to the same people I do, and has the same information. The world isn’t ending, but even though the story has some of the facts wrong, the central argument isn’t that far off the mark. Nick Selby did a great write-up on this, and a bunch of the comments are focused on the nits. While we shouldn’t excuse sloppy journalism, some incorrect facts don’t make the entire story wrong. Share:

Share:
Read Post

What the Renegotiation Bug Means to You

A few weeks ago a new TLS and SSLv3 renegotiation vulnerability was disclosed, and there’s been a fair bit of confusion around it. When the first reports of the bug hit the wire, my initial impression was that the exploit was too complex to be practical, but as more information comes to light I’m starting to think it’s worth paying attention to. Since every web browser and most other kinds of encrypted Internet connections – such as between mail servers – use TLS or SSLv3 to protect traffic, the potential scope for this is massive. The problem is that TLS and SSLv3 allow renegotiation outside of an established TLS connection, creating a small window of opportunity for an attacker to sit in the middle and, at a particular phase of a connection, inject arbitrary data. The key bits are that the attacker must be in the middle, and there’s only a specific window for data injection. The encryption itself isn’t cracked, and the attacker can’t read the encrypted data, but the attacker now has a hole to inject something which could allow unanticipated actions, such as sending a command to a web application a user is connected to. A lot of people are comparing this to Cross Site Request Forgery (CSRF), where a malicious website tricks the browser into doing something on a trusted site the user is logged into, like changing their password. This is a bit similar because we’re injecting something into a trusted connection, but the main differentiator is where the problem lies. CSRF happens way up at the application layer, and to hit it all we need to do is trick the user (or their browser) to get access. This new flaw is at a networking layer, so we have a lot less context or feedback. For the TLS/SSL attack to work, the attacker has to be within the same local network (broadcast domain) as the victim, because the exploit is at the “transport” layer. This alone decreases the risk significantly right out of the gate. Is this a viable exploit tactic? Absolutely, but within the bounds of a local network, and within the limits of what you can do with injection. This attack vector is most useful in situations where there is easy access to networks: unsecured WiFi and large network segments that aren’t protected from man in the middle (MITM) attacks. The more significant cause for concern is if you are running an Internet facing web application that is: Vulnerable to the TLS/SSL renegotiation vulnerability as described and either… Running a web app that doesn’t have any built in application layer protections (anti-CSRF, session state, etc.). Running a web app that allows users to store and retrieve things using simple POST requests (such as Twitter). Or using TLS/SSLv3 as transport security for something else, such as IMAP/SSL, POP/SSL, or SMTP/TLS… In those cases, if an attacker can get on the same network as one of your users, they can inject data and potentially cause bad things to happen, possibly even redirecting your user to a new, malicious site. One recent example (since fixed) showed how an attacker could trick Twitter into posting the user’s account credentials. Currently the draft of the fix binds a renegotiation handshake to a particular already established TLS channel, which closes the hole. Unfortunately, since SSLv3 does not support extensions there is no possible way for a secure renegotiation to happen; thus the death of SSL is nigh, and long live (a fixed) TLS. Share:

Share:
Read Post

Why Successful Risk Management is Still a Failure

Thanks to my wife’s job at a hospital, yesterday I was able to finally get my H1N1 flu shot. While driving down, I was also listening to a science podcast talking about the problems when the government last rolled out a big flu vaccine program in the 1970s. The epidemic never really hit, and there was a much higher than usual complication rate with that vaccine (don’t let this scare you off – we’ve had 30 years of improvement since then). The public was justifiably angry, and the Ford administration took a major hit over the situation.   Recently I also read an article about the Y2K “scare”, and how none of the fears panned out. Actually, I think it was a movie review for 2012, so perhaps I shouldn’t take it too seriously. In many years of being involved with risk-based careers, from mountain rescue and emergency medicine to my current geeky stuff, I’ve noticed a constant trend by majorities to see risk management successes as failures. Rather than believing that the hype was real and we actually succeeded in preventing a major negative event, most people merely interpret the situation as an overhyped fear that failed to manifest. They thus focus on the inconvenience and cost of the risk mitigation, as opposed to its success. Y2K is probably one of the best examples. I know of many cases where we would have experienced major failures if it weren’t for the hard work of programmers and IT staff. We faced a huge problem, worked our assess off, and got the job done. (BTW – if you are a runner, this Nike Y2K commercial is probably the most awesomest thing ever.) This behavior is something we constantly wrestle with in security. The better we do our job, the less intrusive we (and the bad guys) are, and the more invisible our successes. I’ve always felt that security should never be in the spotlight – our job is to disappear and not be noticed. Our ultimate achievement is absolute normalcy. In fact, our most noticeable achievements are failures. When we swoop in to clean up a major breach, or are dangling on the end of a rope hanging off a cliff, we’ve failed. We failed to prevent a negative event, and are now merely cleaning up. Successful risk management is a failure because the more we succeed, the more we are seen as irrelevant. Share:

Share:
Read Post
dinosaur-sidebar

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.