Our customer is a leading CMM Level 5-certified software development enterprise. When it was engaged by a Fortune 500 company to develop a custom application, security was a major concern. The software organization approached Paladion to provide the necessary security control and safety measures.

We worked with the development team from the requirement analysis stage to the project signoff by the customer.

Once 'proof of concept' of the application was approved by the end customer, the project kicked off with the first stage: requirement analysis. Paladion started its involvement in the project with a workshop on application and code security. The training gave the project manager and key developers an overview of application security, and the need for secure code development.

In the requirement analysis stage the development team gathered the functional requirements, while we worked with the customer team in gathering the security requirements for the application. The customer provided us with most of the explicit requirements (like 'user should be authenticated before being allowed access to the database', 'all transactions should be logged', etc).

Through discussions with the application owners and the development team, and a study of the functional requirements, we identified other security requirements (such as 'passwords should not be logged', 'user id should be suspended after three unsuccessful login attempts', etc). The requirements we identified became part of the 'customer requirement analysis document'.

In the design phase the overall application design, database structure, individual modules, and the communications between the modules were reviewed from a security angle. This ensured secure communications between modules, prevented data leak between sessions, and secured database access.

A secure design is the basis of a secure application, because many security holes are related to programmer expectations that the flow of the program remain uninterrupted. To avoid these errors, exception-checking requirements were incorporated in the detailed design. Also, other security considerations were added to the design (code that needs file-system access should not be run with administrator privilege, return codes of system calls must be validated, etc).

While a secure design provides good planning for a secure application, secure coding ensures the execution of the plan. So, before the development phase commenced, we developed a best-practices checklist and a process for secure coding. Security flaws can occur because of programming error, and sometimes the computing environment and languages have inherent security exposure. The processes we developed reduced the probability of these errors.

The code review process checked the developed code against the design specifications and the best-practices guidelines. From a security point of view, among others, the following parameters were verified:

If not checked, these errors could lead to serious consequences, including buffer overflows. Our philosophy of secure programming is that a secure program should know what it expects, and reject any other input or invalid condition. Making a list of bad inputs of exceptional conditions is not the way to go; the lists cannot be complete or foolproof.

Apart from the code, the program's documentation was also reviewed to ensure that all the security features and considerations were captured properly.