Security at your table?

Information security professionals are a disgusting lot. They chew loudly and with their mouths open. They slurp when they drink and talk with their mouths full. They make no attempts to politely cover belches and they fart at the table. They don't wash their hands before or after eating, in fact, they rarely bathe at all.

How else do we explain the fact that security is often not invited to the table? Or if they are allowed a spot at the table, it is all too often so that they can bus the dirty dishes and clean up everyone else's mess.

If your organization is serious about security, give infosec a seat at the table at the start of the project planning process. Much has been written about the cost of adding security or fixing bugs late in the software development process. This is not new information.

If your company wants to develop more secure software, bring qualified security personnel to the table during the requirements gathering phase. Ask them to contribute to the project from start to finish. They should have input every step of the way. In addition to reviewing the customer's functional requirements, they should provide input on the system's security requirements.

After requirements have been gathered, include security in the planning phase of your project. Don't just ask security to review your plans, ask them to contribute to the planning process. Invite them to the planning meetings.

Ask security to help you with testing along the way. If you have a static code analysis tool use it early and often. You may save yourself days or weeks of refactoring if you discover insecure coding techniques early in the development process. Whether you have a static code analysis tool or not, you need to include security in your code review process.

Finishing your code and handing it off to security for a comprehensive review at the end without their involvement along the way is better than nothing, but it is less than ideal. Often as a project nears completion, delivery schedules are being made. Too often these delivery schedules are made without input from the security team. Developers and their managers underestimate the amount of time that will be required to review code. Do not make this mistake in your organization. Do your code reviews along the way and include security in that process as you go.

Once your development nears completion, begin planning your application penetration test. Obviously security needs to be included in the planning for the penetration test. I recently worked an application pen test where I was tasked with testing some changes to an existing application. Testing the changed functionality required three different types of accounts, yet when I was brought in to look at it, I hadn't been given a single account in the system. Due to the nature of the application, getting accounts created and properly setup took several days. All the while the clock was ticking on a scheduled delivery date. Fortunately for this organization, the test was completed successfully a day before the scheduled delivery date.

One more thing you should know, a successful penetration test will prove that your application has security problems. A failed penetration test does not prove that the application is secure. The best chance of building secure systems is to invite security to the table early and keep them engaged throughout the process.

Don't worry, when your system is compromised and someone makes a mess of things, you can still call security to have them clean up the mess.