Project Management and Information Security

Many information security-related problems that face large organizations stem from the fact that security was not considered in the ground-up planning that went into many existing IT solutions. Recently, IT executives are beginning to realize this mistake and are challenged with providing a band-aid for poorly-implemented systems already in use, as well as finding ways to avoid such mistakes in the future. They realize that the only preventive solution is at the project management level, however their solutions often become just another facet of an implementation process already rife with holes. While an improvement, the problem is still not fully addressed. These implementation issues, which become security issues, can be traced to the very organization of many IT departments, and the only true resolution is a complete paradigm shift at the departmental level.

In my experience, IT solutions are implemented in a very decentralized manner - business lines will manage their own projects, pulling in assistance from different IT groups as necessary. Meanwhile, within the IT department, each technician is grouped in a silo with other like-minded and like-skilled technicians. DBA's exist in the database group, Unix admins are in the Unix group, etc. When a business-line IT project manager pulls in a Windows admin for assistance, the Windows admin won't necessarily know when a data storage expert should be pulled in to implement a storage area array, versus simply storing all the data locally. It's easy to see how security fits into this equation: IT engineers can't be experts at everything, and often InfoSec is misunderstood and not considered until the end.

I had a revelation a few months ago while thinking back to a co-oping job I had in college as an electrical engineer. I was on a team tasked with building a handheld electronic device that monitored water quality. The team was made up of a few electrical engineers, a few computer engineers, a mechanical engineer, and a project manager. We were all part of the pool of engineers for the company. When management decided to pursue a technology, a team consisting of one engineer of every major type was assembled under an available project manager. Engineers with each specialty were chosen based on their current work load and the anticipated work load of their role in the project. Rarely would any one engineer be working on only one project. Sometimes, an engineer's skills were of very limited use, like the mechanical engineer in my experience outlined above. But still, the entire team was held accountable for the successes or failures of the project, so attendance at all team meetings was good, and everyone worked to the same goal, even when their role was a small one. There was no concept of a "manager" for the mechanical engineers, and a "group" for electrical engineers. We were all part of the collective - the Borg, if you will - of engineers, and we were all allowed to focus on our area of expertise.

I surmise that IT project management should work on similar principles: when a business need is identified, it is assigned to a team including a specialist for every major body of knowledge (as defined by management), and handed to a project manager with the appropriate details and timelines. There would be no fights over territory between groups, as is often the case with information security and networking when dealing with firewall issues. Accountability would fall to the entire group, not just one or two individuals. When a solution is needed to support a specific technology - say, a new database must be deployed in support of the Unix group's centralized system logs - the project would not be led by a techie in that group with little to no project management skills. This happens all the time. A separate part of the IT division would be responsible for operational and support issues, meaning constant routing problems in Islamabad wouldn't delay a network infrastructure change in Istanbul. The operational groups would simply follow procedures created by the engineers implementing the technology. And security would be built in to every single project.

I am a bit of an idealist. I realize that a radical and fundamental change like this is not likely to happen except in the case of a dreadful reorganization. I've also been told that some companies are already organized in this manner. But for those that aren't, such an approach would not only increase the security of their IT solutions, it would streamline the department's overall response time and support of the critical business lines that make money for the company. This is a win-win situation.

No comments: