Securosis

Research

Just a Spoonful of Obscurity Makes the DefCon Level Go down!

Rich, It feels heretical, but I can agree that obscurity can provide some security. The problem comes when people count on secrecy as their only or primary security. Jim: ā€œOh, we donā€™t have to encrypt passwords. Sniffing is hard!ā€ Bob: ā€œHey, thank you for those credit card numbers!ā€ Jim: ā€œWhat?ā€ Bob: ā€œHa ha, my friend Joe got a job at your ISP about a year ago, and started looking for goodies.ā€ Vendor: ā€œNobody will ever bother looking in the MySQL DB for the passwords.ā€ Cracker: ā€œ0WNED! Thank you, and letā€™s see how many of your users use the same passwords for their electronic banking!ā€ Vendor: ā€œBut nobody else has access to the server!ā€ Cracker: ā€œBut I found a hole in your PHP bulletin board. Game over, man!ā€ GeniousDood: ā€œI just invented a perfect encryption algorithm! Nobody will ever break it!ā€ Skeptic: ā€œHow do you know?ā€ GeniousDood: ā€œI checked. Itā€™s unbeatable.ā€ Skeptic: ā€œThanks, but Iā€™ll stick with something at least one disinterested person has confidence in ā€“ preferably Schneier.ā€ IT Droid: ā€œCheck out our new office webcam! Itā€™s at http://camera.example.com ā€ Paranoid: ā€œWhatā€™s the password?ā€ IT Droid: ā€œPassword? No-oneā€™s ever going to find it.ā€ Paranoid: ā€œGoogle did.ā€ I can accept that obscurity makes cracking attempts more difficult. This additional difficulty in breaking into a system might be enough to discourage attackers. Remember ā€“ you donā€™t have to outrun the bear, just your slowest friend! Also, if you have a short period before the fix is available, during which there is a gaping hole in your defenses, obviously itā€™s going to be easier for people to exploit if they have full details, so itā€™s hard to see how full disclosure could ever look like a good thing to a commercial vendor. On the other hand, open source projects are more likely to benefit from full disclosure, as it substantially widens the pool of people who can provide a patch, and open source communities attract people who want to deal with security problems themselves (certainly many more Linux & FreeBSD admins want to patch Sendmail or BIND, than Windows users want to patch IE or their DLLs). Security companies are like this too ā€“ they want enough info to protect their customers. Restricted access information is fine, as long as the security companies are on the list ā€“ such access becomes another asset for the security vendor. But back to obscurity: it can be used as one component in a layered defense, or it can be used as the only defense. One is useful, the other is dumb. Alternatively, obscurity can be used as a temporary barrier: ā€œIt will take them a few days to figure out how to break IE, so weā€™ll get a chance to distribute the patch before they can start attacking our users.ā€ This is a very different proposition than ā€œpermanent obscurityā€ as (hopefully part of) a defense. The problem, of course, is that not everybody gets the patch immediately. Some people donā€™t because they donā€™t know about it, others because they have important systems which they canā€™t change ā€“ perhaps because the risk of breakage is unacceptable, or the ā€œfixā€ is unacceptable. This may last a few days, or forever. Some people donā€™t have the bandwidth (full dot upgrades for Mac OS, and Service Packs for Windows, are large downloads), and may or may not get the upgrades another way. Some just donā€™t want to be bothered, and believe theyā€™re invulnerable. Others cannot afford the upgrades. So those people may have no defense aside from obscurity, and they are vulnerable; on the Windows side, they tend to get hacked. Obscurity is just not a good long-term defense, since most secrets leak eventually, and patches can be reverse-engineered to find the hole. This leads into the issue of vendors who donā€™t patch in a timely manner, but I have to leave something for Rich to rant aboutā€¦ Share:

Share:
Read Post

Encryption is Cheaper than Destruction

I like to think Richard Stiennon and I are good friends. He was at my wedding in Mexico. I took him and his son skiing up at Copper Mountain where I used to patrol. For a time he even rented space in my condo in Boulder while I was slowly moving to Phoenix. Weā€™d swap my car out at the airport parking lot; it was very convenient. But I never suspected he was so violent. Goes to show you that you can never really know someone. It all started with this post on his blog where he advocates smashing old hard drives rather than taking the risk of the data being later recovered. I thought, ā€œokay, heā€™s just trying to make a pointā€. But yesterday, over at Emergent Chaos, he expanded his violent tendencies towards cell phones in this post. Now Iā€™m worried. I mean this is a man Iā€™ve left in my home, who spent evenings in Mexico drinking with my family members. Iā€™ve even loaned him my cellphone for the occasional call! I feel lucky it came back in one piece. Maybe because I had it in silent mode or something. But hereā€™s some food for thought. I was talking to a client a while back about old hard drives. They were considering encryption since their SAN (Storage Area Network) was managed by their reseller who frequently swapped out failed drives. They looked at degaussing or smashing the drives- just as RIchard suggested. The cost? $8,000,000.00 a year. $8M a year. Wow. Thatā€™s a fair amount of cash, even with the weakened dollar. And those cell phones? The pollutants in them are pretty potent and many recycled phones end up in needy hands. So Richard might want to consider other options. We estimated that client would only need to pay $100,000-$200,000 to encrypt that SAN. Keys are stored externally so the data is unrecoverable. And portable devices? If thereā€™s something sensitive on them you should really be encrypting them anyway. People lose those things you know. Richard- I know a good anger management therapist. Call me, your friends are worried. Share:

Share:
Read Post

Dealing with Security Vendor Exaggerations

I generally donā€™t discuss ā€œindustryā€ issues here since thatā€™s what I get paid to do at my day job. And if I start offering for free here, what I get paid to do over there, I may find myself offered the opportunity to do it for free on a permanent basis. Mike Rothman runs one of the better industry-oriented blogs. He and I used to sit across the table when he ran marketing for one of the vendors I cover. I like Mike a lot better as an analyst. Heā€™s running an interesting debate on the problems with the security market. The debate started with an article in Dark Reading, moves to Mikeā€™s blog here, Alan Shimel responds, then Mike gets the last word (for now). At the crux of their debate is the honesty of vendors and the aggressiveness of their sales and marketing tactics. My opinion? I work with many excellent security vendors who are out to protect their customers and fairly make a little money on the way. But, every single day, either directly to me, or relayed by my clients, vendors misrepresent their products or outright lie about capabilities. Usually itā€™s the marketing or sales teams, not the product teams. Do all vendors lie? No, but the good vendors out there are frequently forced into bad positions by their less scrupulous competition. Yes, vendors lie. So does your Mom (remember the tooth fairy) but that doesnā€™t make her the embodiment of pure evil. Probably. And some of this is simply passion for their products. Everyone thinks their baby is the best looking, smartest, most talented in the world, but there are still a lot of dumb, ugly, couch potatoes. If you donā€™t believe in what you do you shouldnā€™t be doing it. So how do you cut through the crap? My self serving answer is use your friendly neighborhood analyst. The biggest part of our job, at least for those of us who are end user focused, is to help make appropriate buying decisions and separate hype from reality. Our testing lab is the production environment of our end user clients- if a product doesnā€™t work, weā€™ll eventually hear about it. But if you donā€™t trust or canā€™t afford an analyst firm just do what we do. Ask your vendors for customer references in production deployments; if a feature isnā€™t in production, with a reference-able client, it isnā€™t real. Then talk to your network and see what other companies like yours are doing and if any have deployed the product. Letā€™s be honest- most of you readers are either security-types, or at least have a passing interest in security. Itā€™s not like we trust anyone anyway. Share:

Share:
Read Post

What I Really Meant About Security Through Obscurity

Iā€™ve been publishing for in various formats for nearly 10 years now, and I have to admit Iā€™m really enjoying some of the features of blogging. Aside from writing in a more personal voice, I actually appreciate the near instant feedback- from anyone- anywhere- of the blogosphere. I actually enjoy having my ideas challenged and debated. A couple days ago I posted a somewhat lengthy rant on disclosure. Not that I think disclosure is bad, but that we arenā€™t always willing to discuss the deeper motivations of those involved, on all sides, and admit that in many cases the process can favor the bad guys. In the information security world we often state that ā€œsecurity through obscurityā€ never works and secrets always leak. I stated: But in the world of traditional security, obscurity sure as hell works. Not all bad guys are created equal, and the harder I make it for them to find the hole in my security system, the harder it is for a successful attack. Especially if I know where the hole is and fix it before they find it. Secrets can be good. And Martin Mckeay called me on it here. So did the ever-present Mike Rothman here. Martin stated: One more minor issue I have with the article is the use of security through obscurity: while this works for a while, security through obscurity is the most brittle of all types of security. All it takes is one hacker releasing his notes on your security vulnerability and what little security you had because of the lack of knowledge is gone. I sure donā€™t want my bank relying on security through obscurity to protect my bank account. Not that theyā€™d get much right now, a couple of days before the end of the month I agree completely. Martinā€™s bank funds are running a little low Security through obscurity only works for a limited amount of time. Eventually someone will reverse engineer the patch or figure out the vulnerability on their own. Also while it might now be important for every sysadmin to know the details of a flaw, itā€™s sure important for security vendors to get a peek before the bad guys so the good guys can try and shield any attacks. Mike says, Since most of the bad guys would just as soon take the path of least resistance, obscuring information about vulnerabilities is a short term strategy that works. And thatā€™s the point I meant to make. These days a few weeks can mean the difference between completely shielding and patching your environment, or getting nailed by the early exploits. This wasnā€™t true a few years ago, but itā€™s true today. Automated tools are making exploit development much easier and faster- we need to start dropping some obstacles. Weā€™re just trying to slow down the mass exploits and the script kiddies long enough to give us a fighting chance. That said product vendors need to work more with security vendors on ā€œstaged disclosureā€ (I like to make up phrases, later Iā€™ll make up an acronym just for the fun of it). Security vendors need more detailed vulnerability details to better tune their products before exploits appear. They shouldnā€™t have to reverse engineer product patches to do this. This also means those security vendors need to share vulnerability details instead of treating them like their own IP. Finally, product vendors need to provide their customers enough information for them to make an appropriate risk decision. Too much information helps the bad guys, but too little hurts the good guys. Then again, perhaps thatā€™s just responsible disclosureā€¦ (edited 9/1 ) Just to clarify- I, in no way, think security through obscurity alone is a meaningful security control on its own. I think it can be a useful tool to buy us time, but we should never rely on it. Itā€™s just too fragile. Share:

Share:
Read Post

Security is Like Dentistry

Guess where I spent the day? Iā€™ll warn you now, I have a bad habit of taking metaphors too far. Security is like dentistry: It costs more than you think it should. Itā€™s more painful than the providers ever tell you. If you donā€™t keep up with ongoing maintenance it costs A LOT more and is WAY more painful. Itā€™s really hard to find a good provider. Most vendors prey on fear. Some vendors sell a pretty smile, not that their products actually work. If you make decisions based only on financial Return On Investment youā€™ll really screw things up. and finally, < p style=ā€text-indent:20pt;ā€>8. No matter how many times you strap someone to a chair, shine a light in their face, and poke them with sharp objects until they bleed you canā€™t make them any smarter. Time to go rinseā€¦ (edited 8/31 adding point 7) Share:

Share:
Read Post

The 3 Dirty Little Secrets of Disclosure No One Wants to Talk About

As a child one of the first signs of my budding geekness was a strange interest in professional ā€œlingoā€. Maybe it was an odd side effect of learning to walk at a volunteer ambulance headquarters in Jersey. Who knows what debilitating effects I suffered due to extended childhood exposure to radon, the air imbued with the random chemicals endemic to Jersey, and the staccato language of the early Emergency Medical Technicians whose ranks I would feel compelled to join later in life. But this interest wasnā€™t limited to the realm of lights and sirens; it extended to professional subcultures ranging from emergency services, to astronauts, to the military, to professional photographers. As I aged and even joined some of these groups I continued to relish the mechanical patois reserved for those earning expertise in a domain. Lingo is often a compression of language; a tool for condensing vast knowledge or concepts into a sound byte easily communicated to a trained recipient, slicing through the restrictive ambiguity of generic language. But lingo is also used as a tool of exclusion or to mask complexity. The world of technology in general, and information security in particular, is as guilty of lingo abuse as any doctor, lawyer, or sanitation specialist. Nowhere is this more apparent than in our discussions of ā€œDisclosureā€. A simple term evoking religious fervor among hackers, dread among vendors, and misunderstanding among normal citizens and the media who wonder if itā€™s just a euphemism for online dating (now with photos!). Disclosure is a complex issue worthy of full treatment; but today Iā€™m going to focus on just 3 dirty little secrets. Iā€™ll cut through the lingo to focus on the three problems of disclosure that I believe create most of the complexity. After the jump that isā€¦ ā€œDisclosureā€ is a bizarre process nearly unique to the world of information technology. For those of you not in the industry, ā€œdisclosureā€ is the term we use to describe the process of releasing information about vulnerabilities (flaws in software and hardware that attackers use to hack your systems). These flaws arenā€™t always discovered by the vendors making the products. In fact, after a product is released they are usually discovered by outsiders who either accidentally or purposely find the vulnerabilities. Keeping with our theme of ā€œlingoā€ theyā€™re often described as ā€œwhite hatsā€, ā€œblack hatsā€, and ā€œagnostic transgender grey hatsā€. You can think of disclosure as a big-ass product recall where the vendor tells you ā€œmistakes were madeā€ and you need to fix your car with an updated part (except they donā€™t recall the product, you can only get the part if you have the right support contract and enough bandwidth, you have to pay all the costs of the mechanic (unless you do it yourself), you bear all responsibility for fixing your car the right way, if you donā€™t fix it or fix it wrong youā€™re responsible for any children killed, and the car manufacturer is in no way actually responsible for the car working before the fix, after the fix, or in any related dimensions where they may sell said product). Itā€™s really all your fault you know. Conceptually ā€œdisclosureā€ is the process of releasing information about the flaw. The theory is consumers of the product have a right to know thereā€™s a security problem, and with the right level of details can protect themselves. With ā€œfull disclosureā€ all information is released, sometimes before thereā€™s a patch, sometimes after; sometimes the discoverer works with the vendor (not always), but always with intense technical detail. ā€œResponsible disclosureā€ means the researcher has notified the vendor, provided them with details so they can build a fix, and doesnā€™t release any information to anyone until a patch is released or they find someone exploiting the flaw in the wild. Of course to some vendors use the concept of responsible disclosure as a tool to ā€œmanageā€ researchers looking at their products. ā€œGraphic disclosureā€ refers to either full disclosure with extreme prejudice, or online dating (now with photos!). Thereā€™s a lot of confusion, even within the industry, as to what we really mean by disclosure and it itā€™s good or bad to make this information public. Unlike many other industries we seem to feel itā€™s wrong for a vendor to fix a flaw without making it public. Some vendors even buy flaws in other vendors products; just look at the controversy around yesterdayā€™s announcement from TippingPoint. There was a great panel with all sides represented at the recent Black Hat conference. So what are the dirty little secrets? Full disclosure helps the bad guys Itā€™s about ego, control, and competition We need the threat of full disclosure or vendors will ignore security There. Iā€™ve said it. Full disclosure sucks, but many vendors would screw their customers and ignore security without it. Some of full disclosure originates with the concept that ā€œsecurity through obscurityā€ always fails. That if you keep a hole secret, the bad guys will always discover it eventually so itā€™s better to make it public so good guys can protect themselves. We find the roots of the security through obscurity concept in cryptography (early information security theory was dominated by cryptographers). Secret crypto techniques were bad, since they might not work; opening the mathematical equations to public scrutiny reduces the chances of flaws and improves security. As with many acts of creation itā€™s nearly impossible to accurately proof your own work [as my friend and unofficial editor Chris just pointed out]. But in the world of traditional security, obscurity sure as hell works. Not all bad guys are created equal, and the harder I make it for them to find the hole in my security system, the harder it is for a successful attack. Especially if I know where the hole is and fix it before they find it. Secrets can be good. The more we disclose, the easier we make life for the bad guys. ā€œFull disclosureā€ means we release all the little details. It

Share:
Read Post

Off Topic: A Little Perspective

This has nothing to do with security other than the fact Mike Rothman is a security analyst. Sometimes itā€™s worth sitting back and evaluating why youā€™re in the race in the first place. Itā€™s all too easy to get caught up in the insanity of day-to-day demands or the incredibly deceptive priorities of the corporate and government rat races. A few months ago I took a step back and decided to reduce travel, stay healthy, and start this blog. I wanted a more-personal outlet for writing on topics and in a style thatā€™s inappropriate at my day job (in other words, more fun). My challenge is running this site in a way that doesnā€™t create a conflict of interest with my employer, and thus I donā€™t publish anything here that I should be publishing there. Mike just went off and started his own company to support his real priorities. You should really read this. Share:

Share:
Read Post

Experiences with FileVault- Mac Encryption

Believe it or not, despite accusations that that my coverage of the Mac wireless hack is all part of some anti-Apple black PR conspiracy, Iā€™m a Mac user. One thatā€™s so addicted I bought my Mom one and had it shipped to me so I could ā€œconfigureā€ it. Okay, really I had to send mine in for service and I needed another Intel Mac so I could run it off an external hard drive with an image of my MacBook Pro. I mean I might have been without it for, like, 5-7 days and thatā€™s just not acceptable. How can I carry out my anti-Apple black PR conspiracy without a Mac to write my blog entries on? But I have something I need to admit. Itā€™s sort of embarrassing. But itā€™s time to share. You see, Iā€™m a security professional. Not just a security professional, but one that focuses on data security. The kind that gets paid to run around telling the media how stupid everyone is for not protecting their data and doing things like, uh, encrypting their hard drives. Not that Iā€¦ umā€¦ was encrypting my laptop. You see I was in a bit of denial. At first it was because I still used my corporate PC and didnā€™t have access to good encryption software that wouldnā€™t mess up my configuration. Which was really me just lying to myself. Later I told myself I was so good at physical security, and paranoid in general, that Iā€™d never let my laptop get stolen. Yep, another lie. Finally the ultimate in self deception, ā€œwell, I really donā€™t have anything sensitive on there in the first placeā€. Right. None of those ā€œnot for disclosureā€ Powerpoint presentations from vendors are really sensitive, are they? I mean how much personal stuff like social security numbers or credit card info could really be hiding in Outlook (in my Parallels virtual machine) or Mail.app? I mean really! When I decided to attend Black Hat and Defcon (home of the worldā€™s most hostile network) right after an international trip to Australia and China I figured it might be a good time to get off my ass and finally encrypt my laptop. For those of you not familiar with Macs, Appleā€™s included encryption in the OS X operating system for a few years know in a feature called FileVault. But thereā€™s been a lot of debate on how ā€œsafeā€ FileVault is; not from a security standpoint, but from a reliability/recovery standpoint. But in a recent thread in the TidBITS mailing list it didnā€™t seem to many people had much experience with FileVault, and perhaps some of the rumors were unfounded. Or not. Eventually the guilt caught up and it was time to take the encryption plunge. And so far FileVault is working like a 128-bit AES charm. (details after the jump) FileVault isnā€™t the whole-drive encryption I typically recommend to enterprise clients. Rather than encrypting the entire hard drive FileVault encrypts the entire home directory of the user. Itā€™s a model well suited for Unix-style operating systems like OS X where nearly any personal file or setting is in the home directory, as opposed to Windows systems where data tends to be more distributed throughout the OS. OS X also includes an option to encrypt the memory cache so even temporary files are protected. The combination of encrypting the home directory and all virtual memory isnā€™t perfect security, but good for most of us mere mortals worried about losing our laptop or hard drive. FileVault works by creating an encrypted disk image for your home folder (an encrypted sparse image file). When you log in the image mounts and data is transparently encrypted and decrypted using 128 bit AES (Advanced Encryption Standard) as it moves to and from disk. Log out and it unmounts, appearing as one big encrypted file. Thatā€™s where most peopleā€™s fears arise- your entire home directory, every file including photos, music, video, email, and everything else is all on one big file just waiting for a few corrupt bits to make it unreadable. If your system suddenly crashes and corrupts the image (yes, even Macs crash) thereā€™s the possibility of losing everything. For more details on the inner workings of FileVault check out this article at macdevcenter.com. After doing some research I took a few steps to prep my system. To help with performance I moved my iTunes library to /Users/Shared so theyā€™d be out of my home directory and keep the image file smaller. My photos were already on an external drive and I only have a few videos. That dropped around 30 GB from my home directory. I then created a new user account for running backups. I use the excellent SuperDuper to backup my Macs to external drives. By using a separate backup account the entire encrypted disk image is backed up and thus protected even on the external drive. Since SuperDuper creates bootable copies of hard drives you get the nice option of being able to run completely off the external drive, on any Mac, should you lose your primary drive or even the entire computer. No restore needed. At this point I also committed to backing up nightly instead of weekly. From there it was a simple matter of going into the Security Preference Pane, setting a master password (just in case I forget/screw up my primary), enabling virtual memory encryption, and turning on FileVault. An hour or so later it finished encrypting the drive and I was good to go. So how did it work? Good. Maybe even great. Iā€™ve been up for about 6 weeks now and havenā€™t had any problems. Performance seems as good as before, although I do have 2 GB of memory and a 7200 rpm hard drive. Even with a few system crashes I havenā€™t experienced any corruption. Whatā€™s also nice is since I do most of my work-related computing in a Windows XP Parallels virtual computer so now even my Windows

Share:
Read Post

Voting Machine Idiocy- and a Proposal for a Reasonable Standard

Ah Diebold, how weā€™ve missed you. In yet another example of gross negligence with our most sacred political process we find our favorite manufacturer of ATMs and voting machines yet again in the news. This time with a series of failures in the Alaskan primary. From Slashdot: http://rss.slashdot.org/~r/Slashdot/slashdot/~3/15859396/article.pl From Engadget: http://www.engadget.com/2006/08/24/diebold-machines-fail-in-alaska-primary/ For those of you that donā€™t follow the twist and turns of this seriously shady company, Diebold has a long history of insecure voting machines, battling any attempt to regulate better voting security, and attacking anyone that suggests they might have any teensy-weensy wittle problem that might let someone, you know, hijack an election. For more on the past check out the work by Black Box Voting and the very respected Avi Rubin. This really pisses me off. Voting, whatever your political party (except maybe you anarchists and fascists) is the ultimate expression of a democracy. If we canā€™t protect the voting process, we might as well give up and just sell the country to the highest bidder (and yes, I feel the same way about poll taxes, gerrymandering, and anything else that interferes with the right to vote). I have two simple suggestions to resolve this idiocy: Require a voter verified paper trail with random audits at the federal level for all elections (right now only certain states require it). Hold voting machines to the same security standards as gambling machines! Think about how highly secure gambling machines are. I first heard this suggestion from Ray Wagner (a fellow analyst at my day job) and it was so simple in concept it amazes me every time someone claims higher standards are just too hard. Heck, we already have testing labs, protocols, and procedures in place. Iā€™m not a conspiracy theorist, despite many hours dedicated to watching the X-Files, but sometimes ya just gotta wonderā€¦. Share:

Share:
Read Post

Home Security Tip of the Day: SpamSieve for Mac

One of the advantages of being a paranoid security geek is you slowly acquire a familiarity with consumer security tools to prevent any of the bad nastiness you comment on from happening to your own system. While Iā€™m sure some of my remotely hosted servers will get cracked on occasion since I donā€™t have full control over them Iā€™ve taken it as a personal point of honor to defend my personal computers from www.youvebeenhacked.ru to the bitter end. Every now and then on slow news days Iā€™ll highlight some of these tools and techniques to help readers protect their own systems. Since I use Macs, PCs, and even a dash of Linux there should be some good nuggets for all platforms. Disclaimer– I do not accept any advertising (or anything else) from any vendor, anywhere, end of story. If I discuss a vendor on this site itā€™s because I think the product is actually useful. I will also NEVER endorse any vendor I cover professionally on Securosis! And Iā€™m going to start with spam. I really hate spam. Seriously. And if you want to skip to the end just go buy SpamSieve (Mac only), which is one of those gems very familiar to you Mac geeks. But for those of you that like to readā€¦ Like everyone on the Internet not sending this crap I despise spam. I still remember the early days when commercial business was forbidden on the Internet. No spam. No popups. No phishing. No Amazon. No Google. No ThinkGeek. Noā€¦ oh wait, never mind. Spam is more than an annoyance, itā€™s a pretty serious security issue. Most phishing attacks, Internet fraud, and viruses spread using spam. While I donā€™t know the exact economics involved I suspect more spam today is for fraudulent businesses and goods than legitimate, but annoying, marketing. Sorry, even the porn spam guys. Spam is apparently so darn profitable that a serious chunk of the botnets today are dedicated to spreading it. But most of you already know this. For a while I was reasonably immune to spam. My work email was protected with a commercial server-based product and the not-too-bad Outlook junk mail filters. Yahoo does a good job, as do the other public servers where I keep accounts. The real problem was my long-time personal email on a private domain. This account was hard to guess and off the map for a long time and spam was where. What did make it through was caught by the server filter we used (SpamAssasin). But one tragic day I ended up on a political email list and my blissful childhood ended. One bad list administrator managed to get everyone on that list firmly in the sights of the evil spammers. Within weeks 70% of my email on my once-pristine account was spam. Until I finally downloaded SpamSieve. SpamSieve is whatā€™s known as a Bayesian filter- which means it uses all sorts of math Iā€™ll never understand to recognize patterns. I wonā€™t review it or dig into details. All you need to know is if you are on a Mac and have spam in your Inbox you need to go buy this. It took me only 5 days of the free 30 day trial before I whipped out the credit card and paid my $25.00 I get less than one spam message in my Inbox per week. Itā€™s only ever blocked one message I wanted to read (you can check). It takes a few days to a week to train, but thatā€™s really easy. Unlike most computer software it just works. ā€˜nuff said. 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.