How security companies certify produts

We see all over the place, web facing payment applications. We buy everything online these days. Even in India, I don't remember the last time I got any tickets from a physical reservation window. We pay bills, buy groceries, transfer money, trade shares, manage savings, plan travel, etc etc over online systems which to the naked eye look safe. Now the question is how many of these are actually safe. Well, that is something subjective, but let me tell you this; Most companies spend less that 1% of the total development / deployment and maintinance cost on security. And most of this 1% is spent on generic systems, which protect network, firewall and maintain DMZs, Unix accounts, physical security.

But we as an industry do not spend on the security of the actual product. Don't get me wrong here, the money spent in security is necessary, but we must closely look at how we certify our products (web facing / Internet applications). In this blog, (over some parts) I'll try to enumrate security controls in our applications, and where are the loop holes.

1. Blacklisting Parameters: I see code all the time, a lot of it in most cases is of web facing apps. What I see that I do not like? Well, till now (even in modern spring and strusts frameworks) most models of SDLC still depend on blacklisting parameters, this is because security in most cases is an afterthought. Architects (and security experts) have come to accept the afterthought model of security. The problem is that repetative model of development does not improve security. But why is the practice not stopped, well lack of evidence. Most development model favour towards automated tests, this means that the art of hacking get compromised to an excercise in test case execution, completly ignoring context of the application.

Now I got to go, and do better things than ranting. I'll get back to the subject of the blog, once I get back to writing.