Security Manager's Journal: Enough of being the bad guy

April 21, 2008 (Computerworld) Security issues have a higher profile than they did a few short years ago, but too often, security managers still end up looking like the bad guy when they delay a project's go-live date.

Never mind that the real cause of the delay is the failure of project managers to give security a thought until just before they plan to roll out the new application to users. It's the security manager who says, "No, this can't be used in our environment without a security assessment." It's the security manager who seems to have no compunction about negating months of hard work with orders for reworks that mitigate the security problems.

I've talked before about how frustrating this sort of thing is for me. A couple of weeks ago, it happened again. A workflow application had been in motion for almost six months, but I wasn't briefed until T minus 10 seconds.

I hate being hit with the same problems again and again, and I try to avoid that by thinking of ways to change our processes. So, after I did my review of the workflow application, I tackled the project life-cycle management process.

First, I reviewed all the projects from the past couple of years and categorized them according to type. Next, I defined several high-level criteria that dictate whether a project needs security consideration.

I came up with 13 criteria, including projects that involve new applications, partner connectivity, a merger or acquisition, software as a service, new network architecture, and the handling and transfer of personal information or financial data. Project managers can look over the criteria when they initiate a new project and quickly determine whether it will require security attention. If it does, I should be included as a member of the project team.

Baked-in Security

I want the project team to be aware of what I expect before I sign off on a project. To this end, I created an easy-to-use spreadsheet of requirements that project managers can use to ensure that security is "baked in" early in the project's life cycle. (Both the list of criteria and a downloadable version of the spreadsheet are available here.)

Each requirement gets a tab in the spreadsheet and is as generic as possible so that it's highly adaptable. The requirements include application security controls, partner connectivity requirements, merger-and-acquisition due diligence items and security requirements for application service providers offering SaaS. I have columns for the risks associated with noncompliance and for the suggested test activity. The spreadsheet should make it easy for teams to self-inspect the security posture of their projects.