David Wheeler used his freedom of speech to express: > We've had a "reliability vs. security" definition debate before. > I guess what I'd contribute is that software developers need to > examine the intended environment & determine the best trade-off BEFORE > the software is developed. If there's no single answer for the intended > market/user base, the code needs to be configurable so that > the user/administrator can select the best response to the circumstance. You have just pointed out a truly problematic trend, not only in security software companies, but all software companies. You state that "software developers need to examine the intended environment", however the real case is hte fact that the software developers get their marching orders, for the most part, from marketing and the sales force. These two organizations traditionally communicate to develpment, what will sell, and what needs to be there, obviously the CTO weighs in on this, but he/she too has to keep the quicker buck in mind, and balance that the technological requirements. But most times, if a customer comes in and says they want XYZ and they will pay $ABC Million for it.... profit wins out. I have seen that most developers of security products, have never, and will never use their software in the "real world", therefore they rely on those who write the MRD's (Marketing Requirement Documents) to truly understand the customers need. Yet most marketers or sales folks have never been in an operational security position either. This makes for a slow evolutionary cycle of commercial software, with still a decent life-span for those products that will fall to natural selection. The natural ,albeit indirect, predator of the company that cant see beyond its next customer requirement, is the open source community, as well as what may be termed the purists and practitioners in our midst. When these two forces represent themselves in the market place, they act indirectly to impact companies that "dont get it". Those companies that do "get it" will beg, borrow, and steal from the free information that has gained acceptance with early adopters. So, as for an answer to the problem of kludgey security software, the only way for a software company, security or otherwise, to clean house while at the same time producing robust tools, is to remember the first phase of the software design cylce... "Specification". In this cycle, you are supposed to not only write your specification with your customer, but also share it with your colleagues to see where the flaws might be. This means colleagues who understand the problem that is attempting to be solved. Our developers need more insight into how the software is used, and why, as well as an experiential understanding of what its like to be the end-user. -blue0ne
This archive was generated by hypermail 2b30 : Tue May 22 2001 - 12:49:21 PDT