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.
Read the rest at ComputerWorld.