With new initiatives, it's never too soon to think security

Computerworld -

Trouble Ticket

Issue: A project goes from idea to rollout with no security input.

Action plan: Put the brakes on, even if it means calling in the CIO.

"Early and often" is my mantra when it comes to considering the security aspects of any new initiative. More often than not, security is an afterthought, and that can cause delays and add costs. It's far better if I'm aware of each initiative as planning starts, so I can intervene early enough to head off any security issues.

I've been trying to build security checkpoints into our project life-cycle management program. But to date, I've only been able to get my name added to the list of managers who need to sign off on what our project management office (PMO) calls the Operational Readiness Review document.

The ORR is released just prior to deployment, and that's often too late. I need a chance to ensure that security is baked into a project during its early stages, since many of the security problems I'm likely to discover could require a redesign of the application. It should be clear to everyone involved that any delay in the project's go-live date is likely to have a negative effect on the business. But I can't tell you how many projects have come across my desk for an ORR sign-off with gaping security holes and unanswered questions.

Here's a recent example:

A couple of weeks ago, I got my first heads up about a new application that had already been deployed. I had been traveling when the project was initiated and couldn't attend any project meetings.

The application, ironically, had been implemented by the PMO to track projects and resources. We previously had been using a Microsoft SharePoint site and spreadsheets for that.

Many of the security pitfalls were so obvious that I spotted them in just three or four minutes, even before I could do a vulnerability assessment or an in-depth architecture review. First, all users share the same password. Second, users can modify one another's data. Third, there is no ability to audit or log any activity. And finally, the application is hosted externally and available to the world without encryption.

A lot of holes

When I approached the project manager for this initiative, he assured me that no critical data was stored in the application. But I had to scratch my head on this one. Of all the departments, I would expect the PMO to be the least likely to disregard the risk of not including security in the project life cycle.

I went down a list of items that typically accompany IT infrastructure projects: network architecture diagrams, critical design reviews, data flows, a product-selection matrix, ROI calculations. Wouldn't some of those be considered sensitive? No answer.

I then brought up the risks of letting users share passwords and manipulate one another's data. Finally, I reminded the manager that this application could be accessed from anywhere in the world. And since there was no integration with our Active Directory environment, ex-employees would have access to it.

As you can imagine, when it came time for me to sign off on the ORR, I had no option but to refuse. Normally, that would halt an initiative in its tracks. But this application had already been launched, and project managers had been told to start using it.

There was nothing I could do on my own; I had to bring the matter to the CIO's attention. I am responsible for all security-related incidents at my company. If a disgruntled employee were to start deleting or corrupting PMO data, it would be me — not the project manager — who would be sitting in front of the CIO.

I prepared a list of the risks I had uncovered and passed it on to the CIO. As I had hoped, he felt he couldn't sign off on a project with such unacceptable risks. The remediation work has begun.

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@ yahoo.com.

Join in

To join in the discussions about security, go to computerworld.com/blogs/security

Read more about security in Computerworld's Security Knowledge Center.