Timely and interesting read online here: http://gigaom.com/2008/06/30/10-of-the-biggest-platform-development-mistakes/, listing the 10 most commonly observed platform development mistakes. A few items in the list particularly caught my attention:
- Confusing product release with product success. I'm familiar with the huge sigh of relief that goes out when the development and implementation is completed. However, measure of success should be when the system is proven to function and has been accepted by your customers.
- Not having a business continuity plan/disaster recovery plan. I'm frankly amazed that this still needs to be stated as a requirement, and more so that I still hear of people getting push-back. An aquaintance informs me that as soon as he raised this issue when taking on a new job, his management told him that it was out of scope for information security.
- Relying on QA to find your mistakes. I like the point made in the article that you "cannot test quality into a system."
I'd like to add one more item to the list
11. Failing to consider and define security requirements. We need to understand the system and it's components, and know where data is intended to flow and be stored, Then we can understand the potential risks and the best controls. I like to set, and get agreement on a list of high level requirements at an early stage in the project.
Comments (1)
I would like to comment on the following:
**Relying on QA to find your mistakes. I like the point made in the article that you "cannot test quality into a system."**
I do not think that "you cannot test quality into a system" means not relying on QA to find your mistakes. The quote in question does not negate QA as a medium to detect improvement opportunities.
What this statement means is that, you do not check or inspect quality into products. Instead, you build quality into products and services. It also means that trying to inspect quality in products will cost organizations more than what they would spend building quality into products and services.
And because quality encompasses security, it follows that trying to inspect security in products is a fallacy and an engineering aberration. Security must be built into applications. Unfortunately, the pressure to deliver under tight budgetary and time constraints has led many development teams to sacrifice quality and security for expediency.
There used to be a time when security was a total "stranger" to the whole of software engineering. Business didn't think security until something terrible had happened and forced the organization to come out and publicly address the issue that threatened the organization's raison d'etre. However, following 9/11, Information Assurance has become the new buzz word, and debates over InfoSec/IA issues have increasingly gained visibility in corporate boardrooms. As a result of this paradigm shift, the old saw, build fast and first, then check later is now a thing of the past. And building secure applications means incorporating security into the system development life cycle. It means making security requirements an integral segment of the overall application requirements.
The bottom line is that you should not plan on inspect security into a finished product. Instead, development teams should strive to build, or engineer security into applications.
Jean-Pierre E. Mbei, MBAIS/MS
Posted by Jean-Pierre E. Mbei | July 14, 2009 6:20 PM
Posted on July 14, 2009 18:20