I am sure most of you wont believe the reasons for my hiatus for almost 4 months. Let me try and explain. I was involved in a theater production very dear to my heart, so my evenings would be lost in that. I am pursuing a heavy writing assignment, which has been uber-demanding on the small space of time I have left and I actually took my vacation in September, when I had been to beautiful South Africa. Great place! You guys must all visit.
Anyway, enough with the chatter. This piece was prompted by a talk I heard at the Business Technology Summita few days ago. Of course, I blabbed about web app sec and scared the pants off a few nervous developers and architects, but it was mostly fun. The conference mostly focused on SOA ang governance, but there were a few pure tech talks. There was one talk, which I was quite impressed with, by a fellow Java man, Eben Hewitt. He spoke on a topic entitled "10 Things Software Architects must know", which is based on a book similarly entitled, except that the '10' has been replaced with '97'. The talk was mostly about concepts which software architects should keep in mind in order to be successful. While the talk didnt really have a specific security-related context, I applied some of those theories to the way software development companies can deal with security for the apps they develop. These are just my two cents. I am sure some of you can add more to it.
I have heard of several instances where software development companies have been severely criticized for writing non-secure code. Undoubtedly so. Several software development companies dont really take secure coding to be an important practice. Time is not spent developing security in the application from the beginning, which subsequently results in a non-secure web app. The most common excuse that most of these entities give in terms of security or any other functionality not implemented is "This type of security functionality was not laid out in our Requirements Specification" or "There was nothing in RFC specifying these security requirements" and blame is thrown right back at the customers or the business users of the application for their lack of foresight. It is as if we believe that customers who will be using the application or who are functional stakeholders of a web application are actually extremely clear about their requirements. The truth is very simple. They are as clueless as you are. In most cases, they will never really know what they want even functionally, unless they are given several ideas, security is quite a mile away in these circumstances. I believe that it is upto the company or the team developing the application to incorporate a risk assessment process to ensure that they capture all the critical information assets that will be stored, processed and transmitted by the application, threats and the impact of an attack on the application and subsequently on business, and then draw out security controls for the same. I have highlighted a detailed methodology for risk assessment for web apps, in my book "Secure Java for Web Application Development".It is wrong to assume that customers or business stakeholders will be able to provide the razor sharp clarity necessary to build security into an application. Software Development companies need to rise to the occasion and use their expertise to suggest solutions and functionality for security at the beginning of the application development lifecycle.
Which brings me to my second point. People reading my first point are going, "Yeah, but isnt that going to be more expensive than a regular application development effort, without going Mother Teresa on my customer?" Yes it will be a longer, probably marginally more expensive process, but Quality is a Feature. We all try and sort out all problems all the time. Let us not try to do that and examine reality. Software development companies focussed on a greater level of quality of their products must make it explicit. You have various product and service offerings today, but it is important to realize that all services and products will not be of the same quality. A restaurant on the roadside, will not be as focused on quality than a snazzy five star restaurant. Its high time that we understood that about code as well. And its also high time that software development companies that are taking the first point seriously, start making it explicit and derive as much benefit as possible. There may be customers out there (despite the recession) that may be willing to pay better for a better service that is accentuated and re-iterated by processes like Risk assessment, effective understanding security functionality at the start of the lifecycle, vulnerability assessments, security code reviews and practices delving into security. Superior quality, in my opinion is a feature by itself, which needs to be advertised, and made explicit and should not be spoken about or practiced like its a part of the proverbial 'package'.
Let me know what you think of this....
No comments:
Post a Comment