Although many engineers consider product-usage security an IT or operations team task, the engineering team should play the major role in creating a secure product. Consequently, you must make security an integral part of your development process. The most effective way to do this is to review security elements as programmers develop the code and as QA tests it.
Security often becomes a high-priority development issue when some driving event occurs—a customer asks questions about security before buying the product, a certifying organization requires a security audit, or a hacker breaks into the system. Don't wait until a driving event occurs. Instead, secure your product before being asked to do so, either by hiring an outside consultant or assigning the project to a team member. Whatever your choice, select one member from engineering and QA as the security gurus for their respective teams. Then ask them to spend time learning about security practices and testing methodologies.
Software security requires continuous focus during every development cycle. By assigning a software engineer to review the code for security flaws before QA tests the code, you can find problems earlier and improve security with less impact on cost and time. Security flaws found late in the development process can be very costly to fix.
Making security a priority in your system requires that you take extra measures. Consider acquiring security analysis tools appropriate for your product or system, and use them for every release. In critical systems, use a security consultant to review your system and identify problems. The additional costs are always justifiable by the results—problems identified before the product is released.
When determining how much to budget for the security effort, consider the types of security failures, the costs of each, and the probabilities of each. These costs will vary considerably based on the type of industry the product supports and the nature of the product. Devise a development plan in which sufficient money is spent on security to bring the failure probability multiplied by the cost down to a reasonable level.
Most companies do not spend enough time and effort building secure products or systems. More important, the effort spent is often at the wrong time in the development cycle—during testing or post-release recovery. But testing and repairing security in a built system is very expensive and sometimes impossible. As a practice, establish security requirements at the beginning, and then ensure they are considered and reviewed during the design.
Do not wait until an audit or hacker forces you into action, because your team will have a much greater problem improving security after the software has been built. Take software security seriously, because the damage done by poor security can be impossible to repair later.