Securosis

Research

The Question of Agile’s Success

10 years since the creation of the Manifesto for Agile Software Development, Paul Krill of Developer World asks: Did it deliver? Unfortunately I don’t think he adequately answered the question in his article. So let me say that the answer is an emphatic “Yes”, as it has provided several templates and tools for solving problems with people and process. And it has to be judged a success because it has provided a means to conquer problems other development methodologies could not. That said, I can’t really blame Mr. Krill for meandering around the answer. Even Kent Beck waffled on the benefits: “I don’t have a sound-bite answer for you on that.” … and said Agile has … “… contributed to people thinking more carefully about how they develop software, … There’s still a tendency for some people to look for a list of commandments” It’s tough to cast a black or white judgement like “Success” or Failure” on Agile software development. This is partially because Agile is really a broad concept with different implementations – by design – to address different organizational problems. And it is also because each model can be improperly deployed, or applied to situations it is not suited to. Oh, and let’s not forget your Agile process could be run by morons. All these are impediments to success. Of course ‘Agile’ does not fix every problem every time. There are plenty of Agile projects that failed – usually despite Agile tools that can spotlight the problems facing the development team. And make no mistake – Agile is there to address your screwy organizational problems, both inside and outside the development team. Kent Beck’s quotes capture the spirit of this ongoing discussion – for many of the Scrum advocates I meet there is a quasi-religious exactitude with which they follow Ken Schwaber’s outline. To me, Agile has always been a form of object oriented process, and I mix and match the pieces I need. The principal point I am trying to make in my “Agile Development, Security Fail” presentation is that failure to adapt Agile for security makes it harder to develop secure code. Share:

Share:
Read Post

Please Read: Major Change to the Securosis Feeds

For those of you who don’t want to read the full post, we’re changing our feeds. Click here to subscribe to the new feed with all the content you are used to. Our existing blog feed will include ‘highlights’ only as of next week. Back when I started this blog, it was nothing more than my own personal site to rant and rave about the security industry, cleaning litter boxes, and hippies (they suck). Since then we have added a bunch of people and a ton of content. But more isn’t always better, despite what those Enzyte commercials say. At least not for everyone. A couple months ago I was looking at our feed and realized we might be overloading everyone with all the content. Especially when we are running multiple deep research projects as series of long posts. We asked a few people (you know – Twitter), and the general conclusion was that some people preferred only seeing our lighter posts, while others enjoyed the insight into all our major research. We try to please everyone, so we decided to make some changes to the site, what we write, and our feeds: We realized we weren’t posting as much on the latest news as we used to, because that was landing in the Incite or the Friday Summary. We are going back to the way we used to do things, and will return to daily news/events analysis. We’ll be putting most of the vendor/market oriented snark into the Incite, with what we call “drive-by posts” focusing more on what security practitioners might be interested in. We have split the site into two views – the Highlights view will contain the Firestarter, Incite, Friday Summary, and general posts and analysis. The Complete view adds Project Quant and all our heavy/deep research. Most of our big multipart series are moving into the Complete feed (for example, the current React Faster and Better series on monitoring and incident response). To be honest, we hope most of you stick with the complete content, because we really appreciate public review of all our research. We will still highlight important parts of these projects in the Highlights view, just not every post. We made the same split in our RSS feeds. The current feed will become the Highlights feed next week. If you want to switch to the highlights, you don’t need to change anything. For everything, subscribe to the Complete feed (available immediately). That’s it. We’re making a big effort to ramp our daily analysis back up while still producing the deep research we’ve been more focused on lately. With the view and feed splits, we hope to meet your needs better. As always, please send us any feedback. And since I made the code changes myself, odds are high that it’s all broken now anyway. The Research Library feed still exists, for all our substantive completed content, organized by topic so you don’t have to search for it. Share:

Share:
Read Post

Download the Securosis 2010 Data Security Survey Report (and Raw Data!)

Guess what? Back in September we promised to release both the full Data Security Survey results and the raw data, and today is the day. This report is chock full of data security goodness. As mentioned in our original post, here are some highlights: We received over 1,100 responses with a completion rate of over 70%, representing all major vertical markets and company sizes. On average, most data security controls are in at least some stage of deployment in 50% of responding organizations. Deployed controls tend to have been in use for 2 years or more. Most responding organizations still rely heavily on ‘traditional’ security controls such as system hardening, email filtering, access management, and network segregation to protect data. When deployed, 40-50% of participants rate most data security controls as completely eliminating or significantly reducing security incident occurrence. The same controls rated slightly lower for reducing incident severity when incidents occur, and still lower for reducing compliance costs. 88% of survey participants must meet at least 1 regulatory or contractual compliance requirement, with many required to comply with multiple regulations. Despite this, “to improve security” is the most cited primary driver for deploying data security controls, followed by direct compliance requirements and audit deficiencies. 46% of participants reported about the same number of security incidents in the last 12 months compared to the previous 12, with 27% reporting fewer incidents, and only 12% reporting an increase. Over the next 12 months, organizations are most likely to deploy USB/portable media encryption and device control or Data Loss Prevention. Email filtering is the single most commonly used control, and the one cited as least effective. Unlike… well, pretty much anyone else, we prefer to release an anonymized version of our raw data to keep ourselves honest. The only things missing from the data are anything that could identify a respondent. This research was performed completely independently, and special thanks to Imperva for licensing the report. Visit the permanent landing page for the report and data, or use the direct links: Report: The Securosis 2010 Data Security Survey report (PDF) Anonymized Survey Data: Zipped CSV Zipped .xlsx Share:

Share:
Read Post

Storytellers

Last week I was in Toronto, speaking at the SecTor conference. My remote hypnotic trance must have worked, because they gave me a lunch keynote and let me loose on a crowd of a couple hundred Canucks stuffing their faces. Of course, not having anything interesting to say myself, I hijacked one of Rich’s presentations called “Involuntary Case Studies in Data Breaches.” It’s basically a great history of data breaches, including some data about what went wrong and what folks are doing now. The idea is to learn from our mistakes and take some lessons from other folks’ pain. You know, the definition of a genius: someone who learns from other people’s mishaps. Ah, the best laid plans. The presentation took on a life of its own and I think it’s worthwhile to document some of what I said before my senile old brain forgets. Truth be told, I’m never quite sure where a presentation is going to go once I get rolling. And odds are I couldn’t deliver the same pitch twice, even if I tried. Especially when I started off by mentioning masturbating gorillas. Yes, really. I said that out loud to an audience of a couple hundred folks. And to the credit of my Canadian friends, they let me keep talking. We can talk about data breaches all day long. We can decompose what happened technically, understand the attack vectors, and adapt our defenses to make sure we don’t get nailed by a copycat script kiddie (yeah, that’s probably too many metaphors for one sentence). But that would be missing the point. You see, the biggest issue most security folks have is getting support and funding for the initiatives that will make a difference to an organization’s security posture. Security is an overhead function, and that means it will be minimized by definition – always. So given what we know is a huge problem – getting funding for our projects – how can we leverage a deck like Rich’s, with chapter and verse on many of the major data breaches of the past 30 years, to our advantage? We can use that data to tell a story about what is at risk. That was my epiphany on stage in Toronto. I’ve been talking about communications (and how much the average security practitioner sucks at it) for years. In fact, the Pragmatic CSO is more about communications than anything else. But that was still pretty orthogonal to our day to day existence. Great, we get an audience with the CIO or some other C-level suit: what then? We need to take a page from Sales 101 and tell a story. Get the listener involved in what we are telling them. Give them a vested interest in the outcome, and then swoop in for the close. I know, I know: you all hate sales. The thought of buying a car and dealing with a sales person makes you sick. You can’t stand all the smooth talking folks who come visit every six months with a new business card and a fancier widget to sell you. But don’t get lost in that. We all need to sell our priorities and our agendas up the line – unless you enjoy having your budget cut every year. Getting Ready So what do we do? Basically you need to do some homework before you build your story, in a few short steps: Know what’s important: What are the most critical information resources you need to protect? Yes, I know I have mentioned this a number of times over the past few weeks. Clearly it’s a hot button of mine. Pull the compliance card: Can you use compliance as an easier argument to get funding? If so, do that. But don’t count on it. It’s usually the close to your story anyway. Quantify downside: Senior executives like data and they understand economic loss. So you need to build a plausible model of what you will lose if something bad happens. Yes, some of it is speculation, and you aren’t going to build your entire story on it, but it’s data to swing things in your favor. Know the answer: It’s not enough to point out the problem – you need to offer an answer. What are you selling? Whether it’s a widget or a different process, understand what it will take to solve the problem. Know what it will cost: Even if they agree in concept to your solution, they’ll need to understand the economic impact of what you are suggesting. Yes, this is all the homework you have to do before you are ready to put on your Aesop costume and start writing. Building the Story You know the feeling you get when you see a great movie? You are engaged. You are pulling for the characters. You envision yourself in that situation. The time just flies and then it’s over. What about a crappy movie? You keep checking your watch to figure out when you can leave. You think about your to-do list. Maybe you map out a few blog posts (or is that only me?). Basically, you would rather be anywhere else. If you are a senior exec, which bucket do you think most meetings with security folks fall into? So unleash your inner Woody Allen and write some compelling dialog: Describe what’s at risk: You know what’s important from your homework. You know the downside. Now you need to paint a picture of what can happen. Not in a Chicken Little sense, but from a cold, calculated, and realistic point of view. There is little interpretation. This is what’s important, and these are the risks. You aren’t judging or pulling a fire alarm. You are like Joe Friday, telling them just the facts. Substantiate the risk: Most organizations don’t want to be the first to do anything because it’s too risky. You can play on that tendency by using anecdotes of other issues that other organizations (hopefully not yours) have suffered. The anecdote makes the situation real. All this data breach stuff is very abstract, unless you can point

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.