I recently went through the process of deploying a project into a production environment. Along the way all the great processes were utilized. Documents were created and the best part Corporate Security took part in all of the initial steps with the high level design documents being properly approved.
It was here where the tradional Corporate Security Representatives dropped the ball. After the documents were published and approved they moved on to the next item in their to do list. The project went and all of its developers carried on as well as if they had been blessed by the gods. The two sides never met again. After four to five months passed and all the QA testing took place the project was set to be deployed. It was here that someone invited the Corporate Security to return to a conference call. On this call, the project fell apart. Not because of some new detail but because Corporate Security suddenly realized what they had given permission to so long ago and now they wanted to change requirements, alter the deployment, and ultimately delayed the work.
I doubt this story is unusual. I still come across it far more often than I ever should. It is about time that the Corporate Security take a greater role in project development. This need can be further emphasized by all the major project management tools now involving security specific products. IBM buying Watchfire is just one example.
Surprisingly Microsoft has written some good books on this very problem.
I usually work from the point of view of the development team. I prefer this to working on the project level.
From the debacle I think that I learned to continually invite the Corporate Security team to be involved. Try to validate that more than one person understands the project from the security team. Push for the position of Security Steward. This is a position that is not utilized enough. In the last ten years I know of only one company and it was the U.S. Government that used the Security Steward position and it worked very well.