There is an age old saying - "You can take the horse to the water but you cannot force the horse to drink". Reflecting on this I could think of two reasons either The horse isn't thirsty or .....
It's common knowledge that web applications today are the prime targets for an attacker. Across all reports you will easily see them taking the honours. Now consider the fact that knowledge about the type of attacks and the remediation measures are available across the net to an extent that was never seen before. Handy tutorials and remediation guide exists to assist developers in their fight against hackers. Trusted reusable components are available to avoid reinventing the wheel and shorten the development time. Scanners and tools are available which can be used to perform line by line by code reviews or testing with latest rulepacks.
Yet we see applications been brought down. Yet we see badly written code making it to production. Yet we see insecure applications been doled out.
If we analyse the reasons, I could list some of them below:
- Lack of awarenss amongst developers - With so much information available the only reason I could fathom was that developers are not aware what is available in their armor. Alternatively there is so much available that you don't know what to take and what to ignore. Or else I simply choose to ignore. Functionality and Performance are my prime targets. If I get time will also add security as taste enhancers.
- Lack of willingness to invest - License subscriptions are costly. Do we have anything available in open source for free? Engaging security consultants throughout SDLC will inflate my already struggling budget. Who will foot the bill?
- Business comes first - Fine. I need to write secure code but then what good is security if I am not able to roll out the application in time to grab the market. What was that Risk Acceptance Document created for? Wasn't it mean to help me document the risks, accept them and get over with this?
- Lack of skils - Security consultants are endangered species. Where will I get them for my project? There are other priority projects going on. Aren't senior team members supposed to wear multiple hats? How about an architect who can be groomed to play the security role? I get more bargain when the deployment arrives.
- Lost skills - I train people, invest in them and the quit. I don't have time to invest in trainings again. Knowledge repository - Whats that?
Not a complete list but I am sure most of these items can be checked. And yes, I only have problem list for you. No solutions. However look closely and you will see a common trend. Forget application security and if you apply to this any security domain or to any other non security domain - They all fit the bill. Ask a performance team and they will see this applicable to them as well. Even our deveopmen experieces are plagued by the same problem.
If I were to use a common Indian slang then we are now used to "Juggards" or the art of management. We manage incidents, we manage deployments, we manage patches, we manage stakeholders, we manage compliances.
So to conclude, I will say the horse isn't thirsty. It has an attitude problem. And as long as that problem is not fixed, the horse will continue to refuse to drink .... Give it a shot I would say
Views expressed by Salim Kadiwar
Disclaimer: "The post are my own views and don't necessarily represent positions, strategies or opinions of the organizations that I currently work or have worked for in the past."