NIST NVD 2006 Data - Ed Finkler

NIST NVD 2006 Data - Ed Finkler (Photo credit: tychay)

It’s about a year since I sat down, quite despondant and discouraged, faced with the seemingly insurmountable task of overcoming PHP’s culture where it concerns PHP Security. Over the previous couple of years I had accepted the status quo, trusted in PHP and its programmers to be secure, reported vulnerabilities responsibly, and made occassional forays into research concerning how well PHP programmers actually practiced security. All the while, my blog activity fell, my open source contributions diminished to piecemeal status, and I invented a new persona, Mr. Grumpy, with which to terrify my foes (and optionally dispatch them with fatal fits of laughter). Mixing humour and the deadly serious has produced some of my better writing.

It turns out that PHP Security is a time consuming topic and my return on investment was, shall we say, far from satisfactory. That experience was doubtlessly necessary. Once you start to dig around PHP Security in earnest, you begin to notice trends and patterns in how programmers behave and accumulate knowledge. The most obvious feature of PHP culture is that we do not have an active “leadership” in security. There is no appeal to authority in PHP security debates, only personal opinions informed by a nebulous entity called “They”. There are individuals that I have learned to trust and that’s about as far as we can go.

When I actually spent time considering my experiences, I realised I had been taking the wrong approach in trying to improve PHP Security by treading too lightly. PHP security problems are like the moving tide. You can stand on a beach and screech like a baboon all day long attempting to stop them. The tide won’t care. However, if by some miracle you could push the Moon itself into a higher orbit you might just make an impact. So, all one needs to do is accomplish the impossible. Of course, PHP Security is not quite that difficult (I think) but it does have its equivalent of a Moon. That Moon is Authorative Knowledge.

Authorative Knowledge is not fact-based, per se, but a social perception of what is and is not authorative. Therefore, it’s a function of the perceived reliability and correctness of the knowledge source. Is the source trusted? Is it an authority on the topic? How much support does it have among the community? All of these factors play into the creation of a source of Authorative Knowledge.

In the PHP community, the Authorative Knowedge for PHP Security is derived from a concensus. A concensus based on published articles, the practices of libraries and frameworks, printed books, and the vague meandering thoughts of whoever you follow on Twitter.

In other words, our current Authorative Knowledge is you. You’re writing source code. You’re tweeting. You’re probably blogging and may contribute to Devshed or something similar. And I don’t doubt that you talk to other people. Do YOU view yourself as an authority on PHP Security? Most of you probably do not, however, some of you will turn it over in your minds or quickly think YES. That, right there, is the true division of authority but that division has never been clearly established in the PHP community. As a result, nobody really knows in whom or where that authority sits.

That, my dear readers, is the root problem with PHP Security. Until the community can say “This is authorative” without doubt or hesitation, the concensus hivemind (it’s like a flock of sheep) will rule all of our security futures. Sheep are stupid animals. I should know, I spent enough time growing up on a sheep farm to form an authorative opinion of them ;) . They are STUPID.

The disadvantages of a concensus Authority are quite clear. Beliefs are often espoused in place of facts. Security practices are not subject to continual renewal and research. Insecure shortcuts to favour ease of development are tolerated. Security vulnerabilities are too frequently ignored, downplayed, and left unpatched. Security vulnerability reporters are treated with disdain (which discourages responsible disclosure). Change resistance far outweighs any impetus to correct problems. Security policies are ignored. And the list of problems goes on.

Establishing new Authorative Knowledge is desperately needed to displace that which we have endured to date. We need to undo the wrongheaded beliefs, the misconceptions, the false claims of authority, the lack of good practices and…it’s a long list. If we can successfully establish a new authorative figurehead, a group of responsible, knowledgeable and interested individuals, we’ll have what PHP Security is missing: the mysterious “leadership” quality I mentioned at the start of this article.

It all sounds very elitist at first (leadership?), and that’s the second part of creating new Authorative Knowledge. It needs to be capable of being accepted by the PHP community. The community must choose to accept it – not be forced to. Trust is the essential factor here. The figurehead would not be some fixed group, but a collaboration held to the ideals of a meritocracy. It would be open to anyone, welcoming of everyone, and whatever it chooses to be will be controlled by its open membership.

Teetering at the brink of existence, I’ll refer to it (in the absence of other members to contradict me) as the PHP Security Technical Group (SECTG). I use the phrase “Technical Group” deliberately. It’s a group of members who share a common interest in sharing information, performing research, publishing articles/newsletters, and generally taking advantage of resource pooling without giving up their individual interests – all towards accomplishing some common goal, i.e. creating or emphasising new Authorative Knowledge. The phrase “Unofficial” is implicit in the group name – this is not an official PHP entity.

Teetering slightly closer to the brink of existence:!forum/sectg

Yes, that is a mailing list for the SECTG. If you squint at it really really hard you can even see unicorns and moonbeams dancing around it inviting you to click the link and join the group. It’s almost hypnotic. Are you feeling an uncontrollable urge to obey? Good…

In any case, please give this article some serious thought and join the mailing list. Let’s practice what we preach by, you know, taking PHP Security seriously. In time there may be a website, a blog and all of that necessary stuff. For now, let’s just talk and discuss what the SECTG’s future might be and how it can help YOU.

Enhanced by Zemanta

Related posts:

  1. PHP Security: Default Vulnerabilities, Security Omissions and Framing Programmers?
  2. Storing Session Data In Cookies: Problems And Security Concerns To Be Aware Of
  3. The Framework Interoperability Group (FIG): Openness, Accountability and Community Involvement in PHP Standards
  4. Regex HTML Sanitisation: Off With Its Head!
  5. How Would You Engineer A PEAR2/Pyrus Distribution Architecture?