The hacking of a U.S. military network that was made easier by a poorly written contract with Hewlett-Packard offers lessons on how negotiations between customer and service provider could lead to weakened security.
The HP contract with the military did not include securing a set of Navy Department databases that were later hacked, giving the attackers, believed to be from Iran, access to the Navy Marine Corps Intranet, The Wall Street Journal reported Thursday. Without proper updates, the Microsoft databases became vulnerable to an SQL injection, a common hacking technique.
Cleanup costs following the discovery of the breach cost the military $10 million and led to the Navy reviewing its security efforts, the Journal said. The unclassified network hosts websites, stores non-sensitive information and handles voice, video and data communications for 800,000 users in 2,500 locations.
HP declined comment, directing queries to the Navy spokesman in charge of talking to the media. He could not be reached for comment.
Contract negotiations between the government and tech vendors have a different set of requirements than talks between private companies and service providers. Nevertheless, there are lessons to be learned and important reminders from the military snafu.
First, screw-ups in contract negotiations happen often in the government and the private sector.
"These types of poorly written contracts are common," Edward Ferrara, analyst for Forrester Research, said. "Many vendors will interpret contracts in the strictest sense, and if the contract did not explicitly call for the remediation of these vulnerabilities, as the article seems to imply, then yes it is more than possible that the vendor would have allowed the vulnerabilities to continue and enable the resultant breach."
One way for companies to avoid missing systems in service contracts is to create a network schematic that both parties could reference, Al Pascual, analyst for Javelin Strategy & Research, said.
"Organizations looking to avoid a similar fate should ensure that the responsibility for securing systems is clearly specified in the contract," he said.
In the private sector, an organization's security pros are usually left out of contract negotiations, so security lapses are often discovered after the fact, Chris Camejo, director of assessment services at NTT Com Security, said.
"That's sort of the disease that leads to this whole problem," Camejo said. "Security tends to get involved in these sorts of contracts way, way too late in the process."
In Ferrara's opinion, the lesson learned from the Navy hacking is that specifying what is not in the contract is as important as what's covered.
"I always recommend clients build a detailed requirements traceability matrix to track the explicit requirements for each contract, defining the service to be performed, the service levels expected and the environment -- network, application, or host -- the service will be performed with or on," he said. "Liability and indemnification should be clearly defined."
Contracts should also have clearly defined processes for resolving problems and list the key decision makers.
"This is actually standard operating procedure for federal contracts," Ferrara said. "Commercial contracts have a tendency to be not as detailed, however."
Spelling out the responsibilities of both sides is pivotal in avoiding future problems, Roger Entner, analyst and founder of Recon Analytics, said.
"If you write a contract, you have to make it idiot proof, because the other side will follow it exactly to the letter and not more," Entner said. "Everybody is under a profit pressure."