"I get paid to be paranoid," Charest said in the transcript. "And so I wanted to understand the exact controls in place, what environment, what procedures, what policies."
But the Centers for Medicare and Medicaid Services — the departmental division running the health care rollout — wasn't sharing.
"I was frustrated by a number of requests I made that I did not receive," Charest said. The requests were not just related to security, he said, but other operational issues as well.
He said he came to believe that CMS — as the division is known— was deliberately keeping information to itself. "I can't explain it," he said.
While he did not have direct chain-of-command authority over the rollout, "I have responsibility for incident control," Charest testified. "Putting my bad-guy hat on, this would be something I would think would be desirable for someone to want to attack."
HealthCare.gov has two major components: an electronic "back room" that got full operational and security certification and a consumer-facing "front room" that was temporarily certified Sept. 27.
The back room, known as the federal data services hub, pings government agencies to verify applicants' personal information. It does not store data.
But the front room does. That's where consumers in the 36 states served by the federal website create and save their accounts. Individual components of the front room did undergo security testing. But the system as a whole could not be tested because it was being worked on until late in the process — and it was also crashing.
Charest testified that security testing usually takes place on a fully built, stable system that represents real-world functionality.
The path followed by HealthCare.gov was "not typical," he said. "In a perfect world, the system is completely done when you test it."