Oracle: Setting Security Standards

As an employee and security professional at a large enterprise software vendor, customers, partners and colleagues often ask me: “What are your top security concerns?” Although enterprise software security has evolved in the last decade, my security concerns have remained consistent, and are focused on three key areas: ensuring that people who design software include security principals in their designs; ensuring that people who implement those designs avoid security bugs when developing software; and ensuring that people who actually use the software install and configure that software securely. Designing and building secure software requires that there be standards for what ‘secure software’ means, that software professionals understand those standards and that they comply with them. My top concerns therefore include establishing standards for secure coding, ensuring that developers are trained on secure coding principals, and measuring and enforcing compliance with the those standards. In my experience, there are very few sectors in which business executives are not concerned about costs associated with software security, and in many businesses software security has become a top management concern. For software vendors, defining and enforcing effective secure coding standards is a core requirement to remain competitive.

Although most software professionals understand the objectives of security at a high level – that access to sensitive data and functional resources on a software system must be controlled, that the integrity of those resources must be protected and that availability of the resources to authorized users should not be denied by actions of unauthorized users – many software professionals don’t understand how to achieve those objectives in practice. Accreditation standards for computer science degree programs don’t require that students be trained in computer security, and therefore most university CS programs don’t require that students be trained in the principals of secure software development. In my experience, most companies have not defined secure coding standards for their developers. It’s not surprising that many developers write, customize or configure code that is not secure, since nobody has told most developers how to write secure code and how to avoid common security errors in code.

Establishing standards for secure product development, and ensuring that developers understand them, are two of my primary job concerns. Developing and maintaining secure coding standards is in itself a significant task. Certain secure design principals, such as least privilege, have been recognized for many years, and are essentially universal in applicability. Other design principals evolve over time, however, and detailed design and implementation guidance evolve relatively rapidly as software technology, deployment scenarios and regulations change. New security requirements may emerge when new hacking techniques are discovered. Old requirements may change when programming technologies or deployment models evolve (e.g. making back-office applications accessible via the web), or when new regulations or industry standards are imposed (e.g. PCI standards for credit card information).

Maintaining appropriate, up-to-date security standards is a significant task, and should be undertaken by security professionals. Companies who are primarily consumers of software may develop standards that are tailored to reflect the business models and risk environments in which those companies’ software operates. Security standards for software vendors need to be broader in scope, and ensure that software products developed by that vendor can be used effectively in any of the business and risk environments in which the vendors’ customers operate. Products that cannot be deployed securely in specific business/risk environments without extensive customization, or technical or procedural workarounds, will not be competitive with other vendors’ products in those environments, since customization and workarounds cost customers time and money.

Once a company defines software security standards, they need to ensure that the standards are followed. The first step in this process is to ensure that developers are aware of and understand the standards. If security standards are relatively simple and straightforward, it may be sufficient to require developers to read them. When security standards are large and complex documents, it is generally more effective to introduce developers to the standards via a security-training course. Like courses in any complex topic, an effective security-training course breaks the security standards content into discrete, manageable elements, and explains each element in turn. Companies can develop security training courses in-house, can rely on outside content from sources such as the Open Web Application Security Project (OWASP), or can use the services of organizations which specialize in security training such as the SANS Institute. In any case, companies should develop or choose training programs that reflect their own security standards.

Since my company is a software vendor, and has relatively complex security standards, some of which are specific to our products, we have chosen to develop our own security-training program, which my team develops and manages. We rely on web-based training for exposing a wide range of developers to basic secure coding standards, and instructor led hands-on training for more detailed, advanced and specialized topics.

Once a company has developed security standards and developed or selected an appropriate security-training program, they need to ensure that developers comply with security standards. Measuring compliance with my company’s standards is one of my key security concerns, since it’s not possible to manage what one cannot measure. Security compliance programs typically rely on both human review and automated tools.

Among the most effective automated mechanisms companies can use to test security compliance of software are code scanning and fuzzing tools. Source code analysis tools can be very effective at finding many types of potential insecure conditions in product source code while those products are in development. Moreover, fuzzing tools can find potential insecure conditions in software modules by exercising user and application programming interfaces to those modules, and determining if UIs or APIs are vulnerable to unexpected or malformed input. Commercial products are available to perform both source code analysis and fuzzing and can be very effective, though they generally require a certain amount of customization for a particular companies’ software environment and standards. In some cases it may be most effective for companies to implement their own specialized code analysis and/or fuzzing tools, particularly where those companies develop highly specialized software with nonstandard architectures, APIs or UIs.

Automated testing tools can perform basic security tests much more quickly and efficiently than human reviewers. Automated testing is not a substitute for human design analysis and penetration testing, however, since expert humans are still more effective than automated tools at identifying very subtle design flaws.

Human compliance management typically involves reviews of software functional and design specifications, as well as code walkthroughs. Peer or first level management reviews for security compliance can catch many obvious errors in design or implementation. It is also good idea to designate individuals within each development organization who develop special expertise in security standards and secure design principals, and who act as security experts for their development team. These experts can conduct in depth design reviews, and act as liaison with the corporate-level security team to monitor software security compliance. Companies may also choose to create a corporate-level team of security experts whose job is to review software designs and implementations for compliance with corporate policies, and/or conduct penetration testing exercises to identify vulnerabilities in software.

When security problems are identified in software, businesses must analyze the root cause. Specifically, they should determine whether security problems were due to omissions or lack of clarity in security standards or security training, or whether developers did not adhere to security standards and processes in the development process. In the former case, the corporate security team should update their standards or training as needed to ensure that associated problems do not occur in the future. In the latter case, businesses must ensure that there are appropriate sanctions for violation of corporate security policies. Employees who are responsible for software security problems through deliberate negligence must be held accountable if security problems are to be avoided.

Software security has become a top management concern since executives now recognize that problems in software cost them money, can affect business reputations, and can have a very real impact on company profitability. Companies can reduce security problems by defining secure software standards, ensuring their software professionals understand those standards and enforcing compliance with them.