“Software Vendors Give Us What We Want but Not What We Need” (Beautiful Security)
All requirements for a application are important, explicit as well as implicit. Certainly a question becomes, ‘what is the cost; what makes the cost effective for a profitable package?’ Explicit requirements are obvious: those that fulfill a customer need. Implicit is not something always considered other than added ‘bells and whistles’. The author offers three examples of how implicit requirements can be powerful: The Burger, The Book, and The Software Application. The vendor, if not acceptable to the buyer as advertised, replaces the burger and the book, in order to maintain the reputation of the vendor. In software application, the implicit understanding has to do with functioning as advertised. Security, while an implicit requirement in today’s world, does not provide any additional functionality. In fact, the customer may not find the existence of a security flaw for some time after purchasing that application package.
There are a number of security-vulnerability detection tools. “There is no standard way of assessing software security.” Many of the available assessment are to uncover vulnerabilities from a specific perspective, such as SQL/database, Web services, or a specific type of malware. In addition, the threats continue to change. The changes in security features to software are only as protective as the latest set of vulnerability attributes. This presents a question, ‘Can security measures depend on a model of security threats that can capture the majority of intrusions techniques and methods?’
“Unsurprisingly, recent trends in security threat data clearly show the migration of hacker exploits away from network perimeters (routers, switches, firewalls, etc.) to the web application layer.”
A good developer checks out the functionality of their package before presenting that application on the market. Subsystem tests and system tests verify functionality and the product integrates all the functions without errors. This begins with initial design before any development begins. Changes after the start often incur increase costs, causing the potential for project shut down. This holds true for any change. “… 50% of software vulnerabilities are based on defects in the architecture, not the code itself.” Including security as part of the initial design can address security problems in the software early in the lifecycle
The more complex a design may mean more resources and more cost to develop. The complexity of security intrusions adds complexity in the software design. Certainly planning in a design for known places that open the doors for intrusions is an important design step. There are a growing number of tools to help discover some of the loopholes in the design. A couple a noted below:
· CLASP (Comprehensive, Lightweight Application Security Process)
While static tools a important consideration should be given to software that interacts with the newly developed software. Verify is one package available. Verify provides useful information for the interfaced software vendors, and a level of trust for an organizations software application.
The author suggests two fundamental reasons for security controls in the software development process:
· Security flaws are likely to be discovered in design, in the security and authorization architecture, in the actual software code, and in the configuration settings of the devices supporting the application. Therefore, multiple controls at different phases are essential.
· Identification and remediation of vulnerabilities earlier in the software lifecycle lowers operating costs.
References and Some Interesting Articles:
Top 10 2010-A1-Injection
McAfee, Inc. Research Reveals Mothers Rate Cyber Dangers as High as Drunk Driving or Experimenting With Drugs
Oram, Andy, Viega, John. Beautiful Security. Publisher: O'Reilly Media, Inc., Pub. Date: April 28, 2009