Computerworld -
A really great idea may be a matter of timing more than anything else. Take the one that the leader of our project management department approached me with last week.
His suggestion for how to handle security requirements for new projects would have struck me as unfeasible a year ago. Essentially, he argued that we could save everybody a lot of time if we documented all the security measures that my team might require before any new IT project could go live.
It's true that my team is swamped with project work, and we spend a good chunk of our time sitting in project meetings with representatives from lots of other IT departments, trying to understand the technical architecture and think of everything we would need to make the project reasonably secure.
Nonetheless, if not for recent events, I probably would have shrugged off this idea and clung to the belief that we need to fully understand what the business is trying to do before we can mandate how to do it securely.
What is different, of course, is that we have gone through a significant staff reduction, and both the IT department and my security team have been cut drastically. We have to do the best we can with the few people who are left. At the very least, this idea suggested one way to do that.
And after further thought, I realized that it's also true that we have a set of fairly consistent security requirements for specific areas.
For example, if a project involves PII, or personally identifiable information, that invariably leads us to one security procedure: encryption. But we constantly find ourselves having to justify the need for encryption. If we can standardize our encryption requirements for PII, we may be able to cut some arguments short.
We can start with the rules, standards and regulations that apply to personal data, move on to our internal security policies, and then say where and when encryption will be needed. Both file encryption and transport encryption can be covered by these requirements, depending on where and how the information is stored and where it is transmitted and received.
To make this into something that can be handed out to project managers as a general guideline, I'll have to think of all the possible combinations of data classifications, transport types and storage locations and detail what needs to be done in each case.
Free Insider GuideCopyright © 1994 - 2012 Computerworld Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Computerworld Inc. is prohibited. Computerworld and Computerworld.com and the respective logos are trademarks of International Data Group Inc.
