An inside job
When it comes to protecting data, organizations should focus on setting—and enforcing—security measures within their own teams.
Conventional wisdom suggests that the greatest threats to a project's security come from hackers and other external menaces. All too often, though, security breaches are shown to be “inside jobs,” rather than machines or ill-intended humans breaking in.
“Information leaks out of companies at every individual's interface to the outside world,” says Bill Horne, systems architect for William Warren Consulting of Sharon, Massachusetts, USA. “It's very rarely the machines—it's the people.”
For all the buzz about hackers breaking in, it's the project teams that are the true threat.
The percent of
Source: The Global State of Information Security,
PricewaterhouseCoopers. Results based on an
online May 2008 survey of 7,097 security and IT
professionals in 100 countries.
“The biggest cause of security failure is human error—closely followed by human laziness,” says Michael Miora, founder and chief executive of ContingenZ Corp., Los Angeles, California, USA, and contributor to Computer Security Handbook [John Wiley & Sons, 2002].
“It's usually not deliberate malice, but accidental,” he explains. “It's like the old story about passwords. Make them too complicated, and people will write them down and keep them under the keyboard.”
One major point of vulnerability comes down to access. Team members no longer with a project—or a company—have not been “de-provisioned,” or removed from access rights lists.
TIP Information security doesn't have to break the budget.
“I look for security measures that are appropriate,” says Francesco Metalli, a Voorburg, Netherlands-based group IT auditor at G4S, a security and protection firm.
“Security must make sense—and often it doesn't, as too many organizations either spend too much or spend badly,” he says. “In certain industries, for example, it's relatively common to discover instances where a lot of money has been spent protecting against external threats, whereas statistically speaking, it's internal threats that are the biggest vulnerability. In these sectors, there has traditionally been more focus on complex firewalls and anti-virus solutions than on areas like access controls.”
There's simply no excuse for not doing this, says Sonal Shah, PMP, a senior consultant at Solstice Consulting, an application development firm in Chicago, Illinois, USA.
“Know the identity and access-management strategy of your organization—and follow it,” she urges.
De-provisioning often fails to happen because no one is explicitly charged with making it happen or because no one is paying any attention. Amid the frenetic activity of any project, de-provisioning frequently takes a back seat.
Horror stories abound.
“There are many examples of contractors coming into an organization, helping to develop a system, leaving and then coming back several years later to find that their original passwords and access rights still remain active,” says Robert Grapes, chief technologist at Cloakware, an information security solution provider in Ottawa, Ontario, Canada. “Organizations need to become better at ensuring that access rights are role-based, and get recertified as job roles and projects change.”
Another potential opening lies in team members’ susceptibility to social engineering, when outsiders exploit contact with project members to trick them into revealing information.
“People will phone up, plausibly leverage a scrap or two of information that they might already have—such as the name of someone's boss or associate—and ask for a user ID and a password,” says Peter Yapp, London, England-based head of information security at global security advisors Control Risks. “Social engineering attacks can be very clever and very damaging.”
One social engineering exploit gaining in popularity involves going to an organization's premises claiming to be early for an appointment and then asking to use a conference room to do some road warriors work. “Once there, people have access to an internal phone book and an internal phone line on which they appear as an internal caller,” Mr. Yapp warns.
Even casual conversations can be equally revealing, adds Mr. Horne.
“Many people have no idea how much information they can inadvertently give out,” he warns. “They get careless, they get drunk, mistakes happen and information just oozes out of them…and it's easy for ill-intended outsiders to exploit that.”
For project managers who want to make sure that classified material stays confidential, Mr. Horne offers this sage advice: “Never tell anyone something that they don't need to know. If members of a project team ask for figures in order to prepare estimates, simply give them a retail price list and have them use that.”
NOT AS BAD AS YOU THINK
Virtually every organization is guilty of some form of security lapse, though most of them already have fairly effective defense systems, says Jim Huguelet, president of The Huguelet Group, an IT and project management consulting group in Bolingbrook, Illinois, USA.
“In most cases, the organization's existing IT infrastructure, security standards and policies will suffice,” he says. “A project has to be ultra-sensitive for security guidelines higher than those to be applicable.”
One example might be a team working on a major acquisition or a security investigation predicated on the assumption that an insider had breached internal security procedures.
Of course, organizations still have to make sure project teams actually use the secure corporate IT infrastructure and follow security policies in place.
“In smaller organizations, pressure of work means that security can be sidelined, but in larger organizations, project managers tend to convince themselves that someone else is doing it,” warns Robert Mackenzie, business and technology consulting partner at business advisors Scott Moncrieff, Edinburgh, Scotland. “It's assumed that someone from security will show up and fill the gap—but when they don't, no one is going to go looking for them.”
Project teams can't be tied to their desks. Inevitably they—and project data—head into the outside world, which opens up a whole gamut of new threats.
Mobile devices are much more secure than they were even four or five years ago, says Jim Huguelet, The Huguelet Group.
“These days, technologies like hard-disk encryption and two-factor authentication for log-in—where physical tokens or similar objects are required—have become mainstream, and are often already built into devices,” he says.
At aerospace manufacturer Meggitt Avionics of Fareham, Hampshire, England, for example, everything on the laptops used by the company's project managers is encrypted conforming to the U.S. government-backed encryption standard AES-256, says Stewart Gale, Meggitt Avionics’ network service manager.
“Users need to log onto the laptop when they switch it on, and two-factor authentication, profiled for individual laptops, is used whenever the computer is connected to our corporate network,” he explains. “What's more, our policy is that all data must be stored on our secure servers, rather than on the laptops.”
That said, handheld devices such as PDAs and smart phones are much more difficult to secure, warns Michael Miora, ContingenZ Corp.
“It's possible to ‘force’ laptops to comply with corporate security rules and policies in a way that just isn't possible with handheld devices,” he says. Worse, many users tend not to use even the limited set of security features that handheld devices do contain.
“A big factor is convenience, and lots of people don't even set a password—they just switch on and go,” says Mr. Miora.
involving a PDA
Source: The Global State of Information Security
Organizations also shouldn't overlook the physical security dimension, adds Harin Koshti, PMP, a project manager at software development company Gateway TechnoLabs, Ahmedabad, India. Although different stipulations will apply in different circumstances, some basic provisions constitute recognized good practice.
“Secure card-access areas, security personnel at building perimeters, computers configured so that external devices such as thumb drives can't be used, monitoring cameras recording who's entering and leaving project areas—the idea is to make data theft, or inappropriate access, as difficult as possible,” he says.
flows at the
start of a project
is critical for
—ANDREA DINIZ, PMP,
IBM, SÃO PAULO, BRAZIL
For more on
Mr. Koshti says Gateway Techno-Labs employs a variety of protective measures based on the requirements and wishes of its clients. The company also puts it all in writing.
“We sign non-disclosure agreements both with the client and with our employees working on the project, so that they are legally bound to keep client data secure and confidential,” Mr. Koshti says.
Be aware, though, that there's often a trade-off between security and work effectiveness.
“Barring Internet and external email access in a project can impact the mode and pace of information gathering,” warns B.G. Jayaram, PMP, associate vice president in the project management center of excellence at Infosys Technologies Ltd., Bangalore, India. “It may be appropriate for people to move away from the restricted network or location, and use an alternative network or machine, but of course, during that time they would not be at their usual place of work.”
With sound security processes and protocols in place, organizations just have to figure out what to protect. It's really not that tough. Basically, everything connected to a project should be secure—and not just data that might be used as part of the development or testing processes.
“Especially if you're developing something proprietary, protecting the privacy of source documents, algorithms and knowledge can be very important,” says John Locke, founder and manager, Freelock Computing LLC, an open source software company in Seattle, Washington, USA. “Often, organizations focus on just protecting any personally identifiable data, such as credit card numbers, social security numbers and medical records.”
But companies should be securing more than that. Source code, algorithms, planning documents and test strategies are all worthy candidates, but don't forget about team communications. At issue is who can access these communications and how they can be protected.
As much as possible, organizations should define communication flows at the outset, rather than let them evolve by default, says Andrea Diniz, PMP, globalization project manager at IBM, São Paulo, Brazil.
“Defining communication flows at the start of a project is critical for preventing information leakage,” she warns. “Stipulate who sees which reports, who has access to project documents, and where project files and documents are to be stored. It makes the life of the project manager much easier if secure project repositories are defined at the beginning.”
Yet far too often, companies don't consider security in the project plan.
“Security is often either not considered at all or tacked onto a project as an afterthought,” says Mr. Yapp.
Too often, that means trouble down the line as security breaches wreak havoc on timelines, budgets and outcomes. The upshot: security considerations—in the shape of physical security, best practices and threat awareness—should be built right into any IT project plan from the very beginning.
“Make security an integral part of the project and the project budget, rather than an activity—and a cost—that's accounted for separately,” Mr. Yapp says.
Making a project secure doesn't have to be expensive or complicated. Keeping an IT project safe from harm doesn't even require technological wizardry. In many cases, it boils down to common sense and effective enforcement. PM
PM NETWORK JULY 2009 WWW.PMI.ORG