Comments (1)

By Mark Curphey, February 23, 2011

There is a lot of good chatter about what I have learned is being called OWASP 4.0. A fourth generation project no doubt! I posted here and Michael Coates posted here which seems to be stimulating some good debate.

Ahead of meeting Dinis Cruz for what will undoubtedly be too much beer tonight I wanted to jot down a few thoughts on how we could organize OWASP 4.0. There are only so many beer mats you can assemble into meaningful diagrams in a brewery! This is very similar to Michael Coates excellent suggestions but with some subtle and I think important differences.

First I think its important to have a community for people who are engaged in planning and managing software security. These people range from the CSO’s to the scrum masters. There are a lot of important topics not covered at OWASP to day ranging from broad sweeping like application security scorecards and metrics to detailed issues such as how to estimate security during Agile planning.

Second I think its important to have a community for the architects and software developers. In this track you would cover the software design issues such as how to to AuthN and AuthZ, how to design secure WS*’s etc as well as code level implementation topics.

Test should cover the traditional security testing but also include topics aligned to the much bigger and more mature software QA discipline.

Finally Operate would be for those whose primary role is in deploying, monitoring and defending against attacks. There are really important topics in deployment and monitoring that I don’t think are well represented today.

The taxonomy or nomenclature is both trivial and actually very important. People who are consuming content (educational, documentation or tools) need to be able to easily identify with their role and navigate to material that they relate to. There clearly needs to be co-ordination across the verticals and over-lap may occur but for the most part projects should fit.

Across each of the sub-communities you would have a collection of high value projects that could generally fit into people (or education projects), Process & Documentation projects and Tools / Technology projects. Coding guidelines for Ruby for instances would fit into the Design & Dev community under the Process & Documentation bucket. App HoneyPots would be in the Operate community under the monitoring focus area.

Some communities would have more of a bias to build tools (Design & Dev and Test for example) and others move of a bias on documentation and process (Plan & Manage).

Underpinning the buckets is a need for commonality and reuse. This is where guiding principles fit, taxonomies and definitions. This ensures some degree of uniformity across the OWASP community.

There are some obvious gaps such as where do browsers fit and what about R&D / security researchers? Security researchers would scare most software QA people IMHO but I don’t have any magical suggestions.

I will follow-up tomorrow with a detailed post of what I would specially drive inside the Design & Develop community. That would include a set of GitHub repo’s, a CI environment and a set of AWS instances to start with. Dev’s need dev stuff to code with!

Comments (13)

By Mark Curphey, February 19, 2011

It’s an amazing time to be writing about software and social change. I am sat in my favorite Seattle coffee shop with nothing but my MacBook (plus a coffee and chocolate croissant of course). Using nothing but my free Wi-Fi connection I can spawn up  a super-computer on the fly using Amazon Web Services. I was just chatting on my cell via Twitter to a guy in South Africa that I have known for years and would regard as a friend but have never met in person. The middle East is in violent protest, governments have been over-thrown, cyber spy novels are being played out online by hackers in the wake of Wiki-Leaks and Facebook is now worth an estimated $60B. Its a crazy, crazy, crazy world…and I love it.

When I started OWASP nearly a decade ago it was without a plan (or frankly even much thought) but it was with a premonition that the Internet was going to revolutionize the world, web technology would be at the forefront of the revolution and that security would be a critical attribute in the mix. I haven’t been actively involved in OWASP for a number of years but will always claim it as my baby and passionately watch it evolve. It is my social science lab. I had always hoped that the community would develop into a community of developers that were interested in security rather than a community of security people that were interested in software. I wanted to be part of a community that was driving WS* standards, deep in the guts of SAML and OAuth, framework (run-time) / language security and modern development practices like Agile and TDD rather than people seemingly obsessed by HTTP and web hacking techniques. Ask your average OWASP member how to federate identity across the Internet and reckon you will be met with a blank stare but ask them how to check for XSS and I bet you would be greeted with a smile. Thats a problem. That is not to say that people who live and breath HTTP security isn’t incredibly valuable but it wasn’t what I wanted or what I really care about. It like focusing on a patients cold sores when the patient has lung cancer. To someone with just cold sores they need research scientists developing medicine but I think there are bigger and more important problems in the world that I care about. Looking back in hind-sight it isn’t surprising that security people gravitated to the project. Lets face it the first call to action was sent out to a security mailing list that I was moderating at the time. Why would you expect anything different? When I look back to the early years it was when the likes of Ingo Struck, Zed Shaw, Steve Taylor and Alex Russell drifted away that the writing was on the wall for me and I walked away (well moved to the sidelines) shortly after. Those guys were hard-core developers. Over the years the project has grown to be the de-facto and de-jure online source for web security and I am very proud to have planted that seed (very proud indeed) but the desire to have a community for developers interested in the type of security I am interested in has never faded and as far as I am concerned no community exists today for people with this interest.

I have always believed that in order for security to become an inherent part of software development it must come from within the development community itself.

We can’t have security people who know development. We must have developers who know security. There is a fundamental difference and it is important.

Last week I noticed some tweets coming from the OWASP Summit in Portugal that got me very concerned about the state of OWASP. The summit is an awesome idea. OWASP gathers a bunch of bright people from around the world into a hotel on the Algarve once a year and they drive projects, ideas and have fun. The tweet that caught my eye was “Developers don’t know shit about security“. After a few mails to a few people and a few off-line discussions I started to wonder if actually OWASP is at a Tipping Point where it will either evolve to the project I had always originally hoped or a new project will emerge made up of “developers who know security”.

I hope it is the former and I certainly don’t want to encourage revolution (just evolution) but in order for this evolution to happen at OWASP rather than another community forming (which I am hearing mutterings of on the grapevine) I think OWASP needs to adapt pretty dramatically. Before you read my suggestions (which are very direct and generally negative) remember that I think OWASP rocks. I 100% get that some people will be offended and maybe hurt by these comments but they are not personal. Read to the end before firing of poop-o-grams to me!

1. Manage the Project Portfolio – When I look at the OWASP site today its hard to see it as anything else but a “bric-a-brac” shop of random projects. There are no doubt some absolute gems in there like ESAPI but the quality of those projects is totally undermined by projects like the Secure Web Application Framework Manifesto. When I first looked I honestly thought this project was a spoof or a joke. Its been created by people who in my opinion have no idea about what development frameworks do, how they are created and certainly no idea about how to get requirements into engineering teams developing them. If you really think an important thing a development framework should do is to provide support for pluggable anti-automation (whatever that really is) then seriously …… If you go to the engineering team of a major framework with that document you won’t get far. The OWASP Guide also hasn’t been updated since 2005 and the .NET guide is a bunch of broken links or seriously outdated advice! These are key documents that are integrated into many corporate application security policies yet the Guide hasn’t been updated for 5 years. Thats .NET 1.1 / 2.0 and Java 1.5 people!

OWASP has to put controls in place over project quality and develop a project portfolio strategy. It has to focus on quality and not quantity and has to kill a large number of projects that have been created today if it wants to remain credible. It has to focus its key resources on key projects.

2. Industry Engagement  and Communications – Over the years I have had many frustrating dialogs with people at OWASP about the way they have engaged with me as a corporate sponsor (direct sponsor or behind the scenes). I have seen random email after email come in, many contradicting each other or written in a tone that frankly no company would want to partner with. I totally get that there is no one voice but when an active community member openly criticizes a company they are speaking on behalf of “OWASP” wether you like it or not. There have been so many cases I have heard about where the project seems to be biting the hand that they are asking to fed it. I don’t get it. Why ask and complain in the same hand. Take a stance cause. You can’t have your cake and eat it to. One year I heard grumblings that OWASP were very frustrated that they couldn’t navigate a big software company so offered to help. After two reminders of the offer the only time I then heard from them was a year later asking for money to renew membership. Serious partnership could be made with serious funding  that could drive serious projects if it was approached in the right way. Hand-outs is not the way, partnership is.

OWASP has to re-think its engagement and communication model to get to the next stage in it’s evolution.

3. Ethics / Code of Conduct – The O in OWASP is for Open. Open + Source, Open + Respectful and Open WhatEverIsAppropriate. That was a cornerstone of the project from day one. In the early days I fought with a few individuals who in my opinion were trying to circumvent the power of the project for their own personal agenda. It was a fight I was happy to make and would do so again in a heart-beat. An individual who shall remain nameless wanted OWASP to recommend a specific tool that wasn’t licensed with an OSI license. I dug in and refused; in fact I doubled-down and set guidelines on vendors abusing the brand project. That person banded together with a few other lily-livered sheep and tried to have me banned from moderating a mailing list I ran. They probably don’t know it but I have the copy of the mail they sent complaining to the company that hosted the list. I know who they were and exactly what they said. The same people later decided to form their own project that they controlled. I have a copy of a private email between a few of them in which they talk about “…..beating OWASP at its own game so we can influence the messaging that app scanning really is effective” (for completeness that mail forwarded to me by someone on the thread in disgust is in an archive somewhere and so I am paraphrasing). It was a set of douche-bag moves by people with douche-bag standards but the blood and guts have and will remain private as they have no possible positive part to play on the project. There is clearly a balance in ensuring that people who contribute to the project are rewarded. They should be and should be allowed to get something back for their hard work but the mechanism in how that happens is important and will always be a gray area. I have been amply rewarded in my career by my association with OWASP. I have been invited to speak all over the world, been asked to contribute to books and been able to talk to an incredible set of people. I have had jobs as a direct result of OWASP. When I formally transferred OWASP to it new leadership I was compensated for money I had spent in the initial years on hosting, significant personal travel and other things. In those days we never had sponsorship and I funded it all from my own pocket. I still don’t know if I feel 100% good about that but I do feel good that I only got back what I had put in (my wife tracked it meticulously) and I turned down a more than six figure offer at the time to turn over the project to a security firm that I know didn’t have the communities interest at heart. I feel very good about that! OWASP was never mine to sell but that didn’t stop other OSS projects like Nessus.

Ethics is a tough topic and riddled with subjective opinions. It’s a minefield. From an individual perspective its probably easy. Can you look at yourself in the mirror and feel good about what you have done? What pains me today is that I see people riding the OWASP band-wagon that I struggle to understand how they look at themselves and answer that question with a “yes”. Let’s take Cenzic as an example. This is a firm that was founded by the same people that founded HB Gary. Yes the same firm that has been exposed to have been plotting a campaign to discredit wiki-leaks. Cenzic also have a patent for web fuzzing. Now I am not a lawyer but this patent appears that it could be applied against OWASP projects like WebScarab at any time. This is the same firm that used to claim in their marketing that they scan for the OWASP Top Ten. Thats right using HTTP they scanned for insecure crypto! These are my personal opinion but this is not a firm with good ethics yet is actively involved in OWASP.

When I was at OWASP EU in Amsterdam earlier in the year I hears stories about a firm in the far east that was using the OWASP name to organize very well attended chapter meetings and essentially turning them into sales events for their technology. I heard several OWASP community members tell me that they felt that OWASP has lost its way and been hi-jacked by people who are serving their own interests (personal or company) and not those of the project.

For several years I have been concerned that the people speaking at conferences are not the same people that are actively working hard on projects and in some cases have been the very same people who wanted to “beat OWASP at it’s own game”. This is not a good thing for the community. Its rewarding the wrong behavior and the wrong people. So how does an open project rationalize those things and let them sponsor events yet alone contribute to projects? How can you trust that their contribution will be impartial or ethical? Its a tough one and I don’t claim to have any magic answers but I do know that the current ethics and code of conduct appear to be broken.

OWASP has to re-think its ethics policy and code of conduct.

4. Engaging Developers – If you have gotten this far then you will want to know the guy who pricked my conscious to write this post in the first place is called Jon Wilander. I have never met him but I know we would get on well. He gets on well with people I like (Dinis) and from what I can tell from his writing we are very similar. He has recently taken a job with a bank in the development team. I once moved my office from the security building to the development building to sit with the developers. Good patterns are timeless! His post talks about how to engage with developers and given a number of twitter comments and emails I am hearing about a growing tidal wave of people that think OWASP needs to be by developers for developers. My original vision. Maybe its coming full circle ?

There are huge gaps in OWASP today for developers. Where is the advice on writing security related BDD tests, integrating security into Agile, tools that plug into CI servers and IDE’s ?

I can see several ways of doing this but am adamant that this is not a matter of trying to heard the security people to develop content and projects for developers. The definition of insanity is to do the same things twice and expect a different result and while OWASP has made  amazing strides in the security industry I think we need to acknowledge that security is not a Pri0 agenda item in the development culture after a decade of the project.

I think a different approach is needed and it is time for a change.

The good news I think is that I think there is room for both approaches and I think OWASP could play a leading role in both camps. Maybe Software Security is for developers and Application Security is for security people. The first persona is the builder and the second persona the breaker. One is concerned with assessing security posture and the other architecting and creating secure software. OWASP could easily pivot its work (and web site) around those two key personas. Developers best understand what they need and want, security people best understand what they need and want. Maybe the Security Web Application Framework Manifesto that I think is not well conceived (as a builder) is really useful for breakers.

I genuinely hope that what I see as a Tipping Point means OWASP will evolve rather than break apart. It’s an awesome project with awesome people.

- Mark

Comments (0)

By Mark Curphey, January 21, 2011

Summary
=======
On January 16th, 2011 at 10PM PST Heroku was notified of a
security vulnerability by David E. Chen, a long-time customer.
We deployed a fix to our production environment the following
day, January 17th, 2011 at 2pm PST.

We have done extensive analysis and have no reason to suspect
this vulnerability was exploited.  However, we believe it is
important to let the community know about the situation and what
we are doing to prevent similar issues in the future. As a
precaution, we are working with add-on providers to change all
credentials.  We also recommend that users should change any
manually set credentials in their apps as well.

Details on Vulnerability
========================
The vulnerability was a window through which an unauthorized
user could potentially gain read-only access to an app’s deployed
code and configuration variables.

We confirmed the vulnerability, determining that it was
introduced on December 28th. The underlying bug was fixed on
Monday January 17th, the day after we learned about it. It is no
longer possible to exploit this vulnerability. We do not believe
that any customer data was accessed or changed. We have
thoroughly audited our logs for that period and have found no
evidence that anyone exploited this vulnerability.

Consistent with best practices for security incidents, to
minimize the risk of a 0-day exploit, we waited 5 days to notify
the community and work with our add-on providers on a
precautionary mitigation plan.

Precautionary Actions
=====================
We believe it is important to take all prudent steps to ensure
the safety of apps. Heroku uses environment variables to provide
configuration information to apps. These variables often include
things like database passwords, API tokens, and credentials that
are used to access add-ons or other third-party services.
Although there is no evidence that these were compromised, we are
taking additional steps to protect users.

Actions Heroku Is Taking
————————

Our add-on partners have been notified of the problem and advised
to update the credentials for all Heroku apps. You can track the
status of credential changes for all add-on providers
at http://status.heroku.com/20110116-credentials. We expect all
add-on credentials to be updated within the next week.
We have already started rolling credentials for all Heroku hosted
PostgreSQL databases and expect to complete the update
this weekend.

The process of updating credentials will require restarting all
apps.  While we do not expect any apps will have issues with the
update, if you do run into any issues please open an urgent
support ticket at <http://support.heroku.com>.

Actions App Developers Must Take
——————————–

Some apps may make use of hard-coded credentials in either their
source code or manually set configuration variables. As a
precautionary measure, we recommend that you update these
credentials.

Some examples of hard-coded credentials may include:

* Amazon RDS credentials - http://docs.heroku.com/amazon_rds#changing-your-credential
* Amazon S3 credentials - http://docs.heroku.com/s3#updating-your-s3-credentials
* Heroku username and password, often used by automatic scaling plugins. Visit <https://api.heroku.com/account> to change your password.

We have enabled advanced releases (http://docs.heroku.com/releases)
on all apps for free for the next 2 weeks, providing rollback
capabilities and a log of changes made to your app. To use,
update to the latest gem (`sudo gem update heroku`) and run
`heroku releases`.

If you need help or have further questions about the incident,
contact us at <http://support.heroku.com/>

Preventative Changes
====================

We are making several changes to our process and technology
architecture in an effort to prevent this type of security
regression in the future. First, we have introduced automated
regression testing to specifically check for permission issues.
Second, we have expanded our security audit review process for
all changes on the platform. Third, we are increasing the
frequency of both internal and external security reviews to help
ensure that we are continually following the industry best
practices. Finally, we are testing a new environment for
isolating customer processes from one another that will provide
a second layer of protection beyond filesystem permissions.

Reporting Security Issues
=========================

We want to thank David E. Chen for his contribution to our
community by helping us to identify this issue and working with
us to resolve it.  Heroku is committed to continued improvements
to our trust and transparency.  Any individuals who believe
they’ve identified a security issue within Heroku should contact
us at security@heroku.com

Sincerely
- Heroku Security Team

================================
This email was sent to mark@curphey.com.
If you do not wish to receive service notices you can unsubscribe:
http://lists.heroku.com/t/r/u/ydtlujy/tkolylyh/

Comments (3)

By Mark Curphey, October 19, 2010

Best practice
An idea that has no evidence to support its merits, and that probably doesn’t work, but that you can attribute to someone else when things go horribly, horribly wrong.

Sample Usage: Don’t worry about the noise from that flaky Geiger counter; this plant complies with all best practices.

Comments (0)

By Mark Curphey, October 19, 2010

The original article was published in Interface in December 2001.

Scene one. You are picnicking by a river. You notice someone in distress in the water. You jump in and pull the person out. The mayor is nearby and pins a medal on you. You return to your picnic.

A few minutes later you spy a second person in the water. You perform a second rescue and receive a second medal.

A few minutes later, a third person, a third rescue, and a third medal. And so on through the day.

By sunset, you are weighed down with medals and honors. You are a hero. Of course, somewhere in the back of your mind there is a sneaking suspicion that you should have walked upriver to find out why people were falling in all day. Then again, that wouldn’t have earned you as many awards.

Scene two. You are sitting at your computer. You find a bug. Your manager is nearby and pins a “bug-finder” award on you. A few minutes later you find a second bug. And so on.

By the end of the day, you are weighed down with “bug-finder” awards and all your colleagues are congratulating you. You are a hero. If the thought pops up in your mind that maybe you should help prevent those bugs from getting into the system, you squash it. Bug prevention doesn’t win nearly as many awards as bug hunting.

What you measure is what you get

B.F. Skinner told us fifty years ago that rats and people tend to perform those actions for which they are rewarded. It is still true today. In our world, as soon as developers find out that a metric is being used to evaluate them, they strive mightily to improve their performance relative to that metric—even if their actions don’t actually help the project. If your testers find out that you value finding bugs, you will end up with a team of bug-finders. If prevention is not valued, prevention will not be practiced.

Comments (0)

By Mark Curphey, October 19, 2010

S = ƒ(°WFF)

Degrees of Warm Fuzzy Feeling

S=f(p,d)+Rn

(Prayer, Denial) + Number of Days till Retirement

S=f(n)

Where n is the number of security guys you know

S=f(1/n)

Where n is the number of security standards documents you have read

S = ƒ(#B*#FCA)

Number of people you can blame multiplied by the number of friends you have that can cover your back-side

S = ƒ(Bu : Br)

Builders : Breakers

Feel free to add your own by way of comments!

- Mark Curphey

Comments (1)

By Mark Curphey, October 19, 2010

[Originally posted on my securitybuddha blog on 6/11/2007]

I am writing the first draft of the OWASP Web Security Evaluation Criteria this month and need to consider the role of the web application firewall or WAF. I have long been troubled by the marketing surrounding web application firewalls and especially troubled by the PCI DSS’s implicit endorsement of them. They make an assertion that  is just plain wrong by implying that a web application firewall is comparable to a code review. You can choose to have either with the PCI DSS. Because of this and the “vendor fest” that has ensued around PCI DSS, I have been expecting mails like this one on the webappsec mailing list for a while. It is misguided at best.

The view of a respected VC investor given to me in private was this. ‘The market never materialized the way people thought, the enterprise  and CSO’s doesn’t like or believe in them; the network teams do but don’t control the applications and when Cisco, Juniper, CheckPoint and anyone else that matters don’t seem to think its important enough to buy one then we are left with a lot of small niche firms and unhappy moneymen. That said the PCI (DSS) may just be the savior everyone is hoping for but most people still seem to think its like putting a plaster over a flesh wound.’

Ivan Ristic, the creator of ModSecurity gave an accurate view of web application firewalls at an OWASP London meeting a few years back. It was a pleasure to listen to such a balanced and articulate view from someone who clearly understands the technology, market space and has a big personal stake in the game. He essentially put forward a view that they can have a place to play in protecting from a specific set of web application security attacks but are nor ever will be a panacea. My view is similar, they could be a useful part of a defense in depth strategy but you need to understand their limitations.

Cut through the marketing BS and you will find in general there are two types of WAF; protocol analyzers that operate on HTTP traffic looking for signatures in the data stream and a new breed that additionally operate on the application stack at run-time. The second approach has some clear advantages but still has practical limitations.

If you take a step back and look at the range of web security issues we are facing you can order them into a security frame like the one below.

• Authentication  -How users and components authenticate
• Authorization – How authorization decisions are made
• User Management – How are passwords stored, reset etc
• Data Validation -How is data validated to protect from XSS, SQL injection etc
• Data Protection – How is data stored and passed around securely
• Security Monitoring – What is written to logs, how are exceptions handled
• Infrastructure Management – The OS, FW etc
• Configuration Management – CAS, JRE etc

I am not going to cast everyone with the same brush but in general what I see is that what much of the WAF marketing assumes is that the attack vector for all attacks come in the front door and that a web application is likely a single or small cluster of hosts.

Here is a dose of reality. An enterprise web site usually look like this.

<image here>

A single checkpoint security pattern (see Yoder) will not give you a high level of assurance. Ignoring the vast range of attack patterns, attack vectors and the reality of modern architectures (I have not even touched on the implications of SOA and REST here) would leave business with a false sense of security.

In the OWASP Web Security Certification Criteria we will be calling a “fig a fig”. A WAF can have a place to play in protecting from a specific set of web application security attacks but are nor ever will be a panacea.

Side-story: I had dinner a few weeks back with a guy from a well known code review tools company. Actually he invited me for dinner and then his credit card was rejected so I ended up reaching into my pocket which was a fitting end to a disappointing dinner. He stated blatantly with a smug smile (para-phrasing as I can’t remember the exact words) ‘we think PCI is fantastic, we have both a web application firewall and code review tools so either way we get to make a sale’. I lost all respect I had for that company that night.  I thought they had a pedigree and could be trusted in the software security space.

Comments (0)

By Mark Curphey, October 19, 2010

[Originally posted on my securitybuddha blog on 8/05/2007]

My last post The Long Tail of Information Security (Part 1) described why I think information security exhibits Long Tail economic characteristics, outlined the three forces of long tail markets and discussed the first, democratization of tools for production. The intent is to provide an insight into what the future of information security may look like. Part 2 discussed the Democratization of Tools for Distribution and The Connection of Supply and Demand.

Democratization of Tools for Distribution

We all know there is no shortage of security information on offer. Mailing lists, BBS’s, blogs, community sites and professionally authored content is abound. There is also no shortage of technology with open source and commercial tools competing for security dollars produced by professional teams and hobbyists alike. In today’s economy the distribution of information is key. Making information relevant is a primary objective and one of the key forces behind the success of Google, iTunes and Amazon. This is especially true in a world where the blur between what was traditionally called professionally authored and amateur created content is not clear.

For a long time I have been dropping reading articles in the like of eWeek. Why?  The press generally writes articles so they can sell more advertising. Bloggers generally write articles so people will read them. That is a subtle but important difference. If I read an article in the press chances are there is commentary from an “industry insider”. Usually these are people who tell the reporter what they want to hear and almost always they aren’t people that I want to hear the opinions of. Blogging allows people to filter their views to the people they trust.

This trend is of course prevalent throughout the new economy and will become more and more important to information security. A practitioner at the heart of the industry is better at reporting (more knowledgeable and more in tune) than an observer.

The Connection of Supply and Demand

Perhaps the biggest changes we will be in how “security next.o” connects people, process and technology. Search, ontology (information architecture)  and communities will all play important roles.

In 2000 I started the Open Web Application Security Project OWASP. Today it has half a million page views a month and several thousand people meet up all over the world every month to exchange ideas. This “crowd sourcing” will play a big part in the future of information security. The advice from the Long Tail is that people will tell you what they like and don’t like.  Don’t predict, measure and respond.

Of course recommendations, reviews and ranking are key components of what is called the reputation economy. These filters help people find things and present them in a contextually useful way. Today few information security tools attempt to provide contextually useful information. What we will likely see emerge are tools that combine these techniques. A code review tool that finds a potentially vulnerability may match it to crowd-sourced advice which is itself ranked by the crowd and then provides contextual information like “50% of people who found this vulnerability also had Y vulnerability”. Filters like ratings and ranking will help connect the mass supply of information with the demand.

Long tail markets rarely are bound by geography and perhaps the biggest changes may come when someone finds a low cost distribution method for services. Today when you call a 1800 number you may well find yourself talking to a call center in Bangalore. In the future low cost distribution and technologies that connect supply and demand may automatically route the IDS alert of the vulnerability alert may be automatically routed half way across the world to an analyst based on cost, speed or quality. A system may process a code vulnerability and determine that Heinz in Germany is the highest ranked user in the world for providing code workaround for esoteric issues in .NEt 6.5 code.

These two posts have been somewhat thrown together. My apologies. I simply don’t have the time at present to organize my thoughts. They also only touch upon what the future may bring. Long Tail economics has gripped me for a few weeks and I wholeheartedly recommend you read the book. I think it has compelling theories and may have a significant impact on the future of the information security industry.

Again don’t forget to link to these posts to create a long tail!

- Mark Curphey

Comments (0)

By Mark Curphey, October 19, 2010

I have just finished reading the Long Tail by Chris Anderson (editor of Wired). It is brilliant and the best book I have read in several years. Its in the same class as Freakonomics and The Tipping Point.  I highly recommend anyone who reads my blog reads the Long Tail if they haven’t already done so. I think it is extremely important when its theories are considered along-side the information security industry. It presents an insight into opportunities for the future, product strategies and opportunities and even presents a glimpse of what the future itself will look like.

In this post I am not going to summarize the theory beyond an amount needed to explain the context to information security. There are many sites that provide good summaries including Chris Andersons own blog The Long Tail, Wikipedia’s Page, and the original article that appeared in Wired. I want to instead highlight some of the books key points and suggest ways they may explain or influence information security trends.

The Long Tail theory suggests that a distribution curve for products and services looks like the image to the left. It shows there is actually a greater total demand for products and services considered to be niches and not main stream (the yellow)that hits (the red). This explains iTunes, blogging, YouTube, social networking and many other Internet economy trends. Again I recommend reading the book cover to cover.

I fundamentally believe information security is a long tail market. Three facts support this statement;

- every business has multiple processes

- processes that are similar in name between business are actually highly customized (i.e no two businesses are the same)

- there is a large number of processes unique to small clusters of users

One focus of the book is the notion that there are three main forces that explain long tail markets, there are;

- Democratization of Tools for Production

- Democratization of Tools for Distribution

- The Connection of Supply and Demand

Part 1 (this part) covers the introduction and Tools for Production and Part 2 covers Distribution and Connecting Supply and Demand.

Democratization of Tools for Production

Like blogging tools have democratized publishing  and Garage Band has democratized music production, tools will democratize information security. In fact blogging tools already have a significant affect. Just today I read a blog post from the Matasano Chargen folks about the facts of the Black Hat debates over rootkits which provided a much clearer picture than an article in eWeek quoted a so called security analyst who was claiming they hadn’t done their homework.

Tools differentiate mankind and new types of tools have the power to advance the information security industry significantly. What will they look like? First lets consider the key characteristics of other tools that have have democratized production in long tail markets.

Microchunking is a term used where products are designed to be delivered to the user in the way the user wants them. The book uses the example of music that used to be delivered in CD form only. These days its CD, online, ringtone and re-mixes.  Microchunking is at work in security tools today. In tomorrows world users will of course want to be able to run software online or installed but will want to be able to remix. They may want the best scanning engine from vendor “A” combined with the best set of signatures from Vendor “B”.

Customers are looking for “And” not “Or”. An underlying trend for tools is that one size does not fit all. This is a common theme from almost all corporate security people I talk to today. Lets take a hypothetical threat modeling tool. The key to mass appeal will be to support all types of threat modeling methodologies right up to and including the users own. Tools that force a user to do something a very specific way will have a very limited appeal.  Plotting geo-data overlaid with vulnerabilities and processed with visualization tools might help us see hotspots in a complex virtual world; “the wood from the trees”.  Alexa type tools overlaid with vulnerability information may help us make better risk decisions based on business performance data. In an industry with a  notoriously high noise and low signal ratio we will likely see tools that can better produce high signal strength information faster, cheaper and more efficiently than ever before.  I have been dreaming up an idea to build a security advice distribution tool that can help analysts process information from the mass sources more efficiently for instance.

What this says is that the key to tools will be platforms. By definition a “platform” is a system that can be reprogrammed and therefore customized by outside developers and users and so it can be adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated, much less had time to accommodate. A security platform will allow people to build the tools they want to solve the problems they have.

If you link to this blog post you will be creating a Long Tail about Long Tails. Please do! Ironically if you buy the book which you should you will be further creating a best seller or “hit” which is partially what the book is about dispelling!

- Mark Curphey

Comments (0)

By Mark Curphey, October 19, 2010

[Originally posted on my securitybuddha blog on 1/30/2008]

On Sundays it’s a British tradition to wake up with a hangover, get a copy of the Sunday Times and watch the morning politics shows on the beeb. This Sunday past was traditional for me. Data breaches and privacy are hot political topics in the UK after the national fiasco overseen by Alistair Darling. I do feel a sarcastic letter coming on “Dear Mr. Darling, your name is such an Irony” but I will leave that for Wine’O'Clock sometime. The last but few national fiascos was this;

Two compact discs containing bank details and addresses of 9.5 million parents and the names, dates of birth and National Insurance numbers of all 15.5 million children in the country went missing after a junior employee of HM Revenue and Customs sent them in the mail, unrecorded and unregistered.

Rumours on the grid are that the doppy bastard forgot to send the disk, lied to his boss to cover his tracks and within days a storm in a tea-cup was well and truly the size of Amy Winehouse’s drug habit.  The police are looking for the man in the photo. The MOD then lost records of 600,000 people who were interested in becoming canon fodder in the middle east and now to to pit all the national institution Marks and Spencer’s has fallen victim. For my American friends M&S is where everyones granny buys their knickers and slippers but has always sold fantastic food. The “Gastro Pub Steak and Ale Pie” and the “Goan Prawn Curry” are my current favourites.

All of a sudden experts (pronounced “ex” as in past and “spurt” as in drip) offer an array of advice on the TV about how to secure data and how simple it is to take basic measures. It’s a media frenzy and I plan to keep my head right down for fear the industry will accelerate into FUD Factor 4 and people thing I am part of it.

I am however pleased to say we have may have now turned a corner and data loss may no longer in vogue.

It is being replaced by RISK MANAGEMENT.

Yes it seems the UK tax authority have recommended that thousands of high profile people should not submit their tax returns online. This has caused up roar among some who think everyone should be treated the same. Consumer groups are complaining and security experts I have never heard of are crawling from the woodwork to claim their 15 mins of fame.

It’s bloody common sense. Is basic risk management. People with a higher profile or with more money will be at a greater risk and so appropriate controls should be applied. If that means pulling the plug (it seems extreme but but so be it), get over yourselves. The decision clearly doesn’t mean that Stan the milkman from Wolverhampton shouldn’t be “safe enough”. News Flash: Very few businesses are in business to be secure, they are in business to be secure enough. Few people live to be secure, they want to be secure enough. We are all different. That’s what makes the world go around don’t you know.

This does however bring me to the salacious title of this blog post. It’s hard for anyone to disagree that Risk Management is the holy grail of information security. The challenge has always been and always will be bridging common real life scenarios to security controls via the discipline of risk management. We have all seen or heard about risk assessments that everyone agrees with but are effectively useless academic exercises because the analyst couldn’t tie the findings to consequences and actions.And so to my point, Risk Management is like eating lettuce. Until my wife comes up with a tangible formula such as “eat 5 leaves a day and your blood pressure will improve by 2% and you will loose 2 lbs in 4 weeks” I am happy to acknowledge that lettuce is probably good for you and it makes sense to eat it but I will still continue to pick it out of my sandwiches whenever I find it.

Note: There are some interesting frameworks evolving like FAIR that are attempting to bridge the gap.