The CloudSec Chicken or the DevOps Egg?

I am on a plane headed home after a couple days of business development meetings in Northern California, and I am starting to notice a bit of a chasm in the cloud security world. Companies, for good reason, tend to be wary of investing in new products and features before they smell customer demand (the dream-build-pray contingent exempted). The winners of the game invest just enough ahead of the curve that they don’t lose out too badly to a competitor, but they don’t pay too much for shiny toys on the shelf. Or they wait and buy a startup. This is having an interesting inhibiting effect on the security industry, particularly in terms of the cloud. Security companies tend to sell to security buyers. Security buyers, as a group, are not overly informed on the nitty-gritty details of cloud security and operations. So demand from traditional security buying centers is somewhat limited. Dev and Ops, however, are deep in the muck of cloud. They are the ones tasked with building and maintaining this infrastructure. They buy from different vendors and have different priorities, but are often still tasked with meeting security policy requirements (if they exist). They have the knowledge and tools, and in many cases (such as identity, access, and entitlement management), the implementation ball is in their court. The result is that Dev and Ops are the ones spending on cloud management tools, many of which include security features. Security vendors aren’t necessarily seeing these deals, and thus the demand. Also, their sales forces are poorly aligned to talk to the right buying centers, in the right language, which inhibits opportunities. Because they don’t see the opportunity they don’t have the motivation to build solutions. It’s better to cloudwash, spin the marketing brochures, and wait. My concern is that we see more security functionality being pushed into the DevOps tool sets. Not that I care who is selling and buying as long as the job gets done, but my suspicion is that this is inhibiting at least some of the security development we need, as cloud adoption continues and we start moving into more advanced deployment scenarios. There are certainly some successes out there, but especially on the public cloud and the programmatic/software defined security side, advancement is lacking (specifically more API support for security automation and orchestration). There are reasonable odds that both security teams and security vendors will fall behind, and there are some things DevOps simply will not do, which may result in a cloud security gap – as we have seen in application security and other fast-moving areas that broke ‘traditional’ models. It will probably also mean missed opportunities for some security vendors, especially as infrastructure vendors eat their lunch. This isn’t an easy problem for the vendors to solve – they need to tap into the right buying centers and align sales forces before they will see enough demand – and their tools will need to offer more than pure security, to appeal to the DevOps problem space. The problem is easier for security pros – educate yourself on cloud, understand the technical nuances and differences from traditional infrastructure and operating models, and get engaged with DevOps beyond setting policies that break with operational realities. Or maybe I’m just bored on an airplane, and spent too much time driving rental cars the past few days. Share:

Read Post

Friday Summary: December 13, 2012—You, Me, and Twitter

I have an on again / off again, love/hate relationship with Twitter. Those of you who follow me might have noticed I suddenly went from barely posting to fully re-engaging with the community. Sometimes I find myself getting fed up with the navel gazing of the echo chamber, as we seem to rehash the same issues over and over again, looking for grammatical and logical gotchas in 140 characters. Twitter lacks context and nuance, and so all too easily degrades into little more than a political talk show. When I’m in a bad mood, or am drowning at work, it’s one of the first things to go. But Twitter also plays a powerful, positive role in my life. It connects me to people in a unique manner unlike any other social media. As someone who works at home alone, Twitter is my water cooler, serving up personal and professional interactions across organizational and geographic boundaries. It isn’t a substitute for human proximity, but satisfies part of that need while providing a stunning scope and scale. Twitter, for me, isn’t a substitute for physical socialization, but is instead an enhancer that extends and augments our reach. When a plane disgorges me in some foreign city, any city, it is Twitter that guarantees I can find someone to have a beer or coffee with. It’s probably good that it wasn’t invented until I was a little older, a little more responsible, and a lot married. As a researcher it is also one of the most powerful tools in the arsenal. Need a contact at a company? Done. Have a question on some obscure aspect of security or coding? Done. Need to find some references using a product? Done. It’s a real-time asynchronous peer network – which is why it is so much better for this stuff than LinkedIn or Facebook. But as a professional, and technically an executive (albeit on a very small scale) Twitter challenges me to decide where to draw the line between personal and professional. Twitter today is as much, or more, a media tool as a social network. It is an essential outlet for our digital personas, and plays a critical role in shaping public perceptions. This is as true for a small-scale security analyst as for the Hollywood elite or the Pope. What we tweet defines what people think of us, like it or not. For myself I made the decision a long time ago that Twitter should reflect who I am. I decided on honesty instead of a crafted facade. This is a much bigger professional risk than you might think. I regularly post items that could offend customers, prospects, or anyone listening. It also reveals more about me than I am sometimes comfortable with in public. For example, I know my tweet stream is monitored by PR and AR handlers from companies of all sizes. They now know my propensity for foul language, the trials and tribulations of my family life, my favorite beers, health and workout histories, travel schedules, and more. I don’t put my entire life up there, but that’s a lot more than I want in an analyst database (yes, they exist). One day Twitter will help me fill a cancelled meeting on a business development trip, and the next it will draw legal threats or lose me a deal. Tweets also have a tendency to reflect what’s on my mind at a point in time, but completely out of context. Take this morning for example: I tweeted out my frustration at the part of the industry and community that spends inordinate time knocking others down in the furtherment of its own egos and agendas. But I failed to capture the nuance of my thought, and the tweet unfortunately referred to the entire industry. That wasn’t my intention, and I tried to clarify, but additional context is a poor substitute for initial clarity. My choice was to be honest or crafted. Either Twitter reflects who I am, or I create a digital persona not necessarily aligned with my real self. I decided I would rather reveal too much about who I am than play politician and rely on a ‘managed’ image. Twitter is never exactly who I am, but neither is any form of writing or public interaction. This explains my relationship with Twitter. It reflects who I am, and when I’m down and out I see (and use) Twitter as an extension of my frustration. When I’m on top Twitter is a source of inspiration and connection. It really isn’t any different than physical social interaction. As an introvert, when I’m in a bad mood, the last thing I want is to sit in a crowded room listening to random discussions. When I’m flying high (metaphorically – I’m not into that stuff despite any legalization) I have no problem engaging in spirited debate on even the most inane subjects, without concern for the consequences. For me, Twitter is an extension of the real world, bringing the same benefits and consequences. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading post on Big Data Security Recommendations. Rich quoted on DLP at TechTarget. Favorite Securosis Posts Mike Rothman (and David Mortman): The CloudSec Chicken or the DevOps Egg. I had a very similar conversation regarding the impact of SDN on network security this week. It’s hard to balance being ahead of the market and showing ‘thought leadership’ against building something the market won’t like. Most of the network security players are waiting for VMWare to define the interfaces and interactions before they commit to much of anything. Adrian Lane: Can we effectively monitor big data?. Yes, it’s my post, but I think DAM needs to be re-engineered to accommodate big data. Rich: Building an Early Warning System: Deploying the EWS. Mike is taking a very cool approach with this series. Other Securosis Posts Selecting an Enterprise Key Manager. Incite 12/12/2012: Love the Grind. Building an Early Warning System: Determining

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.