Johns Hopkins expert Avi Rubin testifies about healthcare.gov security

Avi Rubin, professor of computer science at Johns Hopkins University and technical director of JHU Information Security Institute, testified in a Capitol Hill hearing Tuesday on the security of healthcare.gov before the House Subcommittee on Science, Space, and Technology.

"Healthcare.gov does not collect nor store electronic medical records, but it does collect whatever personal information is needed for enrollment," Rubin said in a prepared statement submitted to the panel. "This information, in the wrong hands, could potentially be used for identity theft attacks."

Rubin expressed concern that adequate security measures might not have been incorporated into the site from the beginning.

"One cannot build a system and add security later any more than you can construct a building and then add the plumbing and duct work afterwards," he said.

But he added, "In practice, systems require some post-production 'bolting on' of security features and retrofitting security solutions despite any efforts to build security in at the outset. Ongoing vigilance and response are needed to properly maintain a secure Web installation."

Rubin, an expert in network security, said he has followed news reports of the healthcare.gov's rocky rollout on Oct. 1. The site has been plagued by technical glitches, preventing many potential enrollees from signing up for coverage.

"As far as I can tell, so far all of the security problems that have been publicized were easy to fix and have been remedied," he said. "Assessing whether there are any deep, architectural security flaws will require an in-depth design review by security specialists."

Rubin offered six recommendations for ensuring the securing of healthcare.gov:

+­ Outside, independent experts should review the security of the system annually, including design review, code review, and red team exercises

• Security reviews should focus on the interfaces among the components and across systems

+­ User authentication mechanisms should be reviewed, and two-factor authentication should be employed wherever practical

• Security reviews should check for known standard vulnerabilities such as SQL injection attacks, sanitization of user inputs, Cross Site Scripting vulnerabilities, and other standard checks

+­ Data at rest should be encrypted, and keys should be cleared from memory when they are not in use

• Implement mandatory incident reporting, even of suspected and unconfirmed incidents, and contingency plans should be designed for conceivable scenarios.