Security Basics mailing list archives
A Question of Quality
From: "Yousef Syed" <yousef.syed () gmail com>
Date: Fri, 31 Oct 2008 01:55:31 +0100
Why isn't Quality Assumed? Why isn't Security Assumed? Why are these concepts thought of as add ons to Applications and Services? Why do they need to be specified, when they should be taken for granted? - Input Validation - Boundary Conditions - Encrypt Data as necessary - Least Privilege Access - White lists are better than Black lists I'm approaching this from more of a development/services perspective, but I'm sure it applies to others. So why should the need for any of the above genuinely need to be stipulated? The knowledge is out there. The tools are out there. And it doesn't take a huge effort to do - but can save a huge effort in the future. I realize that this is a bit of a rant, but I really do believe that software quality and our expectations surrounding software quality is worth talking about. During the development life-cycle of a product, various requirements are stipulated; however, all quality and security seems to get ignored unless each specific matter has been added to the requirements. Architects and designers don't push back on requirements due to quality or security issues; but rather, due to the difficulty to implement it. Code reviews don't through back client code with username/passwords embedded, but they do throw it back because it doesn't follow the stipulated coding/naming standards. Testing and reviewing have their place in this, but I do feel that our focus is often on some of the wrong things. I'll leave it there for now so you guys can comment. ys -- Yousef Syed CISSP http://www.linkedin.com/in/musashi
Current thread:
- A Question of Quality Yousef Syed (Oct 31)