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.


Kevin Mitnick eat your heart out: Some jaw-dropping tales of hacking

Someone get the movie rights to this, we've got a real-life blockbuster on our hands: Kevin Poulsen of SecurityFocus reports today that a hacker had access to one or more T-Mobile servers for over a year, with complete access to innumerable accounts and data therein, including one of a Secret Service agent that exposed confidential information on ongoing investigations. This is the most spectacular hacking story I've ever read, with the Secret Service serving as both the victim and investigator, and even ties in with the AOL leak of 92 million email addresses investigated last year. What is especially disturbing is that, once again, it looks like someone convicted of hacking is being handed a career in Information Security. Supposedly, the Secret Service is offering leniency to the hacker for his help in other investigations. It's an interesting angle on the old problem of jail overcrowding: why not just hire people when they break the law? In all seriousness, it is all too often that high-profile virus writers and hackers get employed by agencies or security companies, while people involved in lower-profile and lower-impact incidents are punished severely under the auspices of "terrorism" according to the USA Patriot Act. Not only have these people proven they can't be trusted, this certainly isn't discouraging others from hacking. The message here is, hacking will land you in jail, but only if you don't have good hacker-fu.

A second revelation today involved GMail. Specially-crafted email messages reportedly will cause the contents of memory (which may include anything from other emails to usernames and passwords) to be delivered to the attacker in an email in their inbox. For months I've been ridiculed by my associates for not trusting GMail and sticking to my own home server, so this is a bit of vindication for me, but is bad news in general. In Google's defense, they have some of the biggest brains in the industry, so I'm sure this will be resolved quickly and will be the exception rather than the norm.

This last tidbit, irony and all, is from SANS NewsBytes:

--Hacker Gets Data on 32,000 Students and Staff at George Mason University
(11 January 2005)
A hacker compromised a Windows server and gained access to social security numbers and other private information of thousands of students and staff at George Mason University. The university is one of the Centers of Excellence in Information Security designated by the US government.

The sad part is that this undermines confidence in the government's Centers of Excellence in Information Security, even though such education programs are institutionally separate from the administration of the universities involved.


Microsoft's role in the battle against spyware

Today, Microsoft announced that it is releasing its own anti-spyware application. This is the first step in its endeavour into the world of anti-virus software, which it seems to be gearing up as part of its revenue stream. On the surface, it appears that Microsoft may finally be giving its users an overdue helping-hand, but the move marks the beginning of something that may be a security setback in the years to come.

In providing these tools - pro bono or for a fee - Microsoft is coming dangerously close to pushing band-aid solutions as an acceptable security recourse. The time and effort they're putting into a whole new product line would much better serve customers if it were spent performing more code reviews to proactively correct more security flaws. Second, if the rumors pan out and Microsoft does in fact start charging for the anti-virus software they develop, they will be profiting from a problem they created themselves. This is something that they may actually be able to sell to the consumer market, but the corporate world will most likely be wise to such shenanigans. What concerns me is that the naievite of the consumer market leaves them vulnerable to such a ploy, and it's been apparent that the Department of Justice isn't too concerned with protecting them either.

Microsoft could provide these tools free of charge, as they currently do with their firewall. This would be the best, and most ethical, approach in my opinion. But again there is a danger: given Microsoft's track record, it's likely that the software will be bundled with the operating system. With a built-in safety net, the motivation for Microsoft to produce higher-quality code is lessened, and the security of personal computers is all once again in the hands of a single vendor who has given the topic far too little consideration in the past.

In my opinion, this direction would largely serve to perpetuate the problems we currently see with Microsoft products, while giving users a false sense of security. But with Redmond, I tend to be a skeptic, so let's just hope it doesn't play out that way.