If encryption gets short shrift from IT, it's not because it's a low priority -- it's because encryption can be so complicated to manage. Questions about how to manage encryption keys, how to search encrypted archives, or where to deploy the technology continue to dog encryption initiatives.
But whether they think encryption is complicated, expensive, or unnecessary, many IT departments are being forced into deployment by various state and federal regulations governing data privacy or long-term archiving.
So where to begin with data encryption? Perhaps sensing all the user uncertainty on the technology, vendors are responding with encryption options up and down their product lines. (See Vendors Roll Out New Security Software for Mobile Devices, Seagate Unveils Encrypted Notebook Drive, and Strategic Security: Developing a Secure Email Strategy.)
The good news is there's no need to blanket the enterprise with it. Pick your spots, say experts. Many IT organizations have taken this to mean laptops and backup tapes -- any place where data is portable and at risk. Others also encrypt specific applications like email, or business processes like payroll and benefits.
"It makes sense to encrypt anywhere there's material risk to data being stolen," says John Rotchford, managing director, of Strategic Advisory Services International, Encinitas, Calif. "Laptops are a no-brainer, but encrypting data at rest in a data center doesn't make as much sense, since the chances of someone ripping open a storage array is probably pretty low."
Companies need to consider not just how they encrypt at wireline speed, but how to bring intelligence into the equation. IT has to be able to manage encrypted data, both in flight and at rest. And that means encrypted data must remain easily searchable, which requires a bit more forethought, said Eric Ogren, security analyst, with the Enterprise Strategy Group, Milford, Mass.
"You can still get full searchability through the indices, so the idea that you can't search them is a bit offbase," he notes. But it also requires users and IT personnel to agree on what's to be in the metadata and keyword tags so that searches are done on words or phrases the system knows how to spot.
Still, what about those hundreds, if not thousands, of laptops in use at any given moment -- or if you prefer, backup tapes being shuffled between locations? If one goes missing, how does the user or the enterprise get its encrypted data back? "That's the piece that makes it hard -- key management and keeping it simple and reliable. But that's what needs to happen," Ogren says. (See Multivendor Management Locked Up.)
IT will slog through these issues, but for those enterprises that aren't obligated, it's the early adopters that will sort out these management and administrative headaches. "A big sledge hammer is being used now [where encryption is concerned], but in the future it will be a lot more intelligent and surgical in its use," Rotchford adds.
You can blame this one on software developers, but the onus is on the security organization to press them to build more secure software.
Even seemingly minor coding errors in software can cause big-time security headaches down the line for enterprises that deploy the buggy software. Many developers -- both internal programmers and third-party software companies -- don't properly code their operating systems, applications, and network device software with security in mind from the get-go. And enterprises that install the resulting software eventually pay the price. (See CERT Seeks Secure Coding Input and Secure Coding Catches Fire.)
Vulnerabilities and attacks would be less pervasive if developers had better processes for identifying coding problems and other bugs that lead to security woes, experts say.
"There's not a lot of pressure [on vendors] to securely code things. Customers don't demand it," says Consilium1's Kelly. "Until organizations really start incorporating and integrating security into their development processes," there won't be much change, he says, although regulatory compliance demands are helping.
Robert Seacord, senior vulnerability analyst at CERT, concurs. "When and if customers elect to purchase products that are more secure over products that have more features, software vendors will develop and deliver more secure products."
Seacord heads up CERT's Secure Coding Initiative effort to build standards for developers to create safer and less error-prone software. The program tries to help developers do so while also "decreasing overall costs," Seacord says.
Microsoft is the most high-profile developer to embrace a secure coding program, its Trustworthy Computing initiative, of which Windows Vista will be one of the first graduates. (See The Vista-Forefront Security Two-Step.)
"Because of Microsoft's position in the software product market as a platform provider, it is significant that they have launched a broad security initiative," CERT's Seacord says. And Microsoft has already made one contribution: The ISO/IEC WG14 working group for the programming language C is developing standards based on a Microsoft library that remediates common programming errors, he says.
Meanwhile, enterprises must balance what features they need versus what security risks they can assume, Seacord says. "Attackers will naturally use the easiest route they can find. If that attack vector cannot be adequately defended because of other requirements, it makes little sense to expend significant resources eliminating one attack vector while leaving another vulnerable."
In other words, it doesn't make sense to lock your door if your window is rolled down, he says.
And although secure coding is ultimately up to the developers, IT managers, CIOs, and purchasing managers should include security as a primary concern in their purchasing and design decisions, Seacord says.