Introduction

The views expressed in this blog are my own. Just to be clear, that means they are not the views of my employer, co-workers, family, friends, casual acquaintances, strangers, or anyone other than myself. 

There has been plenty of news coverage about the security flaws that have plagued Healthcare.gov since it went live in October 2013:

• Hackers: HealthCare.gov still riddled with potential security issues 
• Exclusive: Security Risks Seen at HealthCare.gov Ahead of Sign-Up Deadline 
• World’s greatest hacker calls Healthcare.gov security ‘shameful’ 

Yesterday I took the opportunity to watch two related House Committee hearings. The first was the House Oversight & Government Reform Committee hearing (chaired by Rep. Darrell Issa (CA)) to discuss the best ways to secure people’s private information on the Healthcare.gov website. The three witnesses appearing before the Committee were Kevin Charest, CISO at HHS, Teresa Fryer, CISO at CMS, and Frank Baitman, CIO at HHS. You can view it on C-SPAN here: http://www.c-spanvideo.org/event/230252

The second was the House Science, Space and Technology Committee hearing (chaired by Lamar Smith (TX)) to hear Cybersecurity expert testimony on information security of the Healthcare.gov website. The four witnesses appearing before this Committee were Waylon Krush, CEO of Lunarline, Inc., David Kennedy, CEO of TrustedSec, LLC., Michael Gregg, Founder and COO of Superior Solutions, Inc., and Dr. Larry Ponemon, Ph.D., Chairman and Founder of The Ponemon Institute. You can view it here: http://www.c-spanvideo.org/event/230248.

I’ll refer to these hearings as HOGRC and HSSTC going forward.

Why do I care?

I have a keen interest in this topic for a couple of reasons. First, these hearings highlight the issues facing government Certification and Accreditation (C&A) programs. During my time as an Air Force Officer, I spent several years at the Air Force Communications Agency (which then became the Air Force Network Integration Center) where I was the Chief of the Assessment and Validation Branch, Chief of the C&A Policy Branch, member of the Air Force C&A Process Technical Advisory Group and contributing author to the first USAF C&A instruction.

Second, this issue is directly related to securing healthcare exchanges, PII, and personal health information. Since I left the Air Force nearly four years ago I have been working as an Information Security Professional in the healthcare industry. In addition to developing, implementing and managing security assessment programs, I also have the opportunity to personally conduct application security assessments and penetration tests for all sorts of technologies — including mobile, web and desktop applications — on an everyday basis. I spend my spare time researching security topics and assisting well-known organizations to identify and remediate web and application security vulnerabilities. I’ve uncovered significant flaws in enterprise products that should have undergone both government and private sector security assessments.

I say all of this not to boast – in fact there are plenty of security pros out there that put my resume to shame, including several of those appearing before the aforementioned House Committee. Instead, I preface today’s post with this background information so you know that I understand and have genuine professional interest in the issues at hand – I understand FISMA security reporting requirements, NIST Security Controls and Risk Assessment processes and how government C&A works (or at least how it did at the time); I understand the security issues facing healthcare organizations and the risks and threats to patient data; and just as important, I understand the technical vulnerabilities, what it takes to find them, and what it takes to remediate them.

Two more points of clarification – Although as you read this, it may appear based on the arguments I support that I’m on one side of the political aisle, my post is in no way politically motivated. There’s only one side I’m on and that’s the side of Information Security. I have no interest in seeing the Healthcare.gov site fail whatsoever. In fact, I sincerely hope that the attention it’s garnering might eventually get it the security it needs to become a representative best practice that other government and private sector organizations can learn from. Second, I was not involved with the security design or testing of Healtcare.gov in any way and have no inside knowledge as to the current security control implementation. I am only commenting on the information derived from these two hearings and published documents to-date.

What did I learn?

So, what did I learn from watching over four hours of testimony? Primarily, that partisan political agendas on both sides of the aisle continue to overshadow the real issue – security of the public’s personal healthcare information. This was reinforced by uttered phrases such as “Her side of the aisle” and “Us Democrats” (coming from both parties). I purposefully did not include individual Representative’s political affiliations in this write-up, though if you watch the videos, it will unfortunately become all too apparent. Political motivations aside, it’s clear from hearing the expert testimony, that Healthcare.gov was not designed with security in mind and was rolled out before it was fully tested. While it sounds as if some additional security controls have been implemented since its inception, there is still work to be done. If there’s one thing I can say from watching these hearings it’s that an end-to-end security assessment must be conducted by an industry-recognized, third-party security and penetration testing firm and those results must be reviewed and remediation actions implemented.

Key Points from the Hearings

Below I try to summarize some of the main points from both hearings, though this certainly is not a comprehensive review. I encourage you to watch them both and draw your own conclusions. Here are some of the issues I keyed in on:

Where did things go wrong?

So how did the Healthcare.gov site get to the insecure state that it’s in today? I haven’t been following all of the related hearings but I have been reading various published articles and interviews and from these two hearings in particular, it’s clear that several problemscontributed to the current state. These are just a couple of the most glaring…

Processes weren’t followed

First, based on what I have heard and read, I would infer that security was not properly considered during the design and implementation of this site and it did not follow the C&A process as it was intended. One of the questions during the HSSTC hearing came from Rep. Donna Edwards (MD), directed at Mr Krush regarding the rigor of the Federal C&A process:

Edwards: “Is healthcare.gov…is the rigor attached to Healthcare.gov any different than any of these other Federal systems that you’ve indicated?”

Krush: “No this process is the same across the U.S. government.”

So that question and associated answer, while I suppose is technically true, is a bit misleading. The purpose of the Government C&A program is to implement standardized security requirements and processes for all agencies to follow. So yes, the process is supposed to be same. Whether that process is effective is up for debate. I can tell you that if implemented and followed as intended, a C&A process based on NIST controls can be effective. But realize that NIST controls and the associated risk assessment process, while sound guidance, still requires security engineering and testing procedures implemented by knowledgeable professionals to make it truly effective. You can hand anyone NIST Special Publication 800-53 and a set of DISA STIGs and still get a poorly implemented system.

Putting aside the debate on whether government C&A processes are effective for a moment, I think a key follow-up question that the Representative should have asked was whether or not the process was followed. Switching over to the HOGRC hearing, we in fact get an answer to that question, obtained from a Draft memo written (but never sent) by Ms. Teresa Fryer. [For reference, FFM stands for Federally Facilitated Marketplace, aka Healthcare.gov]

“FFM does not reasonably meet the CMS security requirements which are intended to minimize the CMS business risk, enterprise risk, and the FFM application risk.” … “Complete end-to-end testing of FFM never occurred. The majority of the testing efforts were focused on testing the expected functionality of the application, not security.” … “There is also no confidence that Personal Identifiable Information (PII) will be protected.” 

In fact, testimony showed that nearly half of the modules in the healthcare marketplace had not had completed security testing. 

During the HSSTC hearing, Mr. Gregg touched on a good point … security starts from inception of design, before implementation.

It’s clear that was not done here, which makes it even harder to fix after-the-fact. NIST and Federal Government C&A certainly has a framework for ensuring security is implemented from the very beginning and considered throughout the development and implementation lifecycle but of course it all comes down to execution. David Kennedy highlighted that in his testimony when referencing end-to-end testing and other best-of-breed security practices:

“I’m not saying that NIST doesn’t have those, they’re just loosely followed.” He continued on to say: “We have to focus on putting security in the very forefront, the very beginning stages of when we hire a contractor or we go after another organization”… “Healthcare.gov is a prime example of the failures of being able to implement security in a rigorous manner or in a process that includes security throughout the entire lifecycle.”

The site went live before it was fully tested

Directly related to the first point, even when it was known that the necessary processes weren’t followed, the site went live anyway. To support this assertion, look no further than the provisional Authority To Operate (ATO) issued on September 27^th despite security testing not being completed. 

Some pertinent quotes from that memo follow:

FISMA “…requires that the various Federally Facilitated Marketplace (FFM) systems … successfully undergo a Security Control Assessment (SCA). Due to system readiness issues, the SCA was only partly completed. This constitutes a risk that must be accepted and mitigated to support the Marketplace Day 1 operations”. … “From a security perspective, the aspects of the system that were not tested due to the ongoing development exposed a level of uncertainty that can be deemed as a high risk for FFM.”

It’s clear from this excerpt, that ensuring day 1 operations took priority over security. Mr. Krush acknowledged that perhaps the person that signed this memo (Marilyn Tavenner) may not have been the appropriate authority to accept the risk associated with early operation of the website. Whether this is true, I can’t say. However, his argument that the CISO should be the final approval authority is flawed and is not the practice in the Federal government for good reason. From my experience, an ATO does not just represent the security readiness of a system. In fact it goes beyond the realm of securtity to consider the interoperability, supportability, sustainability, and usability requirements of a system. It documents whether the risks identified in all of those areas, outweigh the operational need for the system. There may be times when non-security issues preclude issuance of an ATO just as there may be times when security issues are trumped by other operational needs and an ATO must be issued. This is why the CISO, while having a significant advisory role as to the security posture of a system (the “C” of C&A), should not be the final approval authority. The key to an effective authorization process is the appointment of a single, senior level Designated Approval Authority, with direct responsibility for the operation of the system and its mission that has the authority to accept all risks (security and otherwise) as well as the associated consequences resulting from realization of those risks.

In addition to the primary Healthcare.gov site, testimony during the HOGRC hearing revealed that 17 States did not have the appropriate approvals to connect for various reasons (including lack of security review) but that CMS accepted that risk on behalf of its Federal partners (including IRS) anyway.

The following question was posed to the witnesses regarding the issuance of the provisional ATO and the security state of the website at the time:

“Do any of you ever recall reviewing an ATO that listed the main risk for proceeding as a lack of complete security testing”.  … “Any others that were launched without doing the security assessment”

Ms. Fryers: “No sir.”

Is Healthcare.gov a target?

Interestingly, there was much debate as to whether Healthcare.gov was even a viable target for malicious actors. Rep. Donna Edwards (MD) and others made it a point to clarify that no personal medical record is stored on Healthcare.gov. While this is an important distinction when designing security controls, it certainly does not eliminate risk nor should it alleviate the need for independent end-to-end testing.

System interconnections, trusted or not, can introduce just as much risk. Whether the data sits in a database on the web server, resides on an internal network or is served by some interconnected system via a trusted web service, it’s still just a vulnerability or two away from unauthorized access. System interconnections are built on a trust model. If system A trusts system B (via identification and authentication) to access, send and/or receive data via a given interface and system B is subsequently compromised, so is that trust model. In such cases, the exploited vulnerability can be just as devastating as if it occurred within a single system environment. Ask any penetration tester how often they stop at the very first compromised system because it just so happened to house all of the interesting data they were after – I bet not too often. Though I haven’t seen any network or data flow diagrams, from what I understand, Healthcare.gov is a gateway to IRS, DHS, and other agency systems.

At about 01:00:00 into the HSSTC hearing Representative Neugebauer (TX) asked Mr. Michael Gregg about whether or not compromise of Healthcare.gov could result in inappropriate access to patient medical files:

Neugebauer: “Could a security breach, uh, of Healthcare.gov, uh, result in people’s medical files being accessed?”

Gregg: “Yes Sir, it could, uh, the information could be accessed and then the real damage would come afterwards.”

Also, the very notion that the site is a primary broker for so many interconnected systems speaks to its complexity, a mortal enemy of security. To that point, in addition to the main Healthcare.gov site, serious security issues are also being found in the interconnected state sites.

For some reason, during the HSSTC hearing, Mr. Kennedy, Mr Gregg, and Dr. Ponemon’s assertions that Healthcare.gov is a viable target (with plenty of money being made by attackers targeting the government space) was refuted by Mr. Krush, whose opposing stance is clearly shortsighted.Here is Mr. Krush’s viewpoint:

“Healthcare.gov is not the one getting attacked. Most cybercriminals and especially those with advanced capabilities they go where the money is right? They’re gonna go after the Target’s, they’re gonna go after the Nieman Marcus, they’re gonna go after these places that contain lots of data related to intellectual property, because it just makes fiscal sense right? If the U.S. Governments spends billions of dollars on our research and development and we don’t protect it and some other country takes that, you just saved them billions of dollars.”

To me, this is incorrectly confining Healthcare.gov to a particular threat space. While it might not be the website of a large retailer or fit the profile of a traditional “APT” target (if there is such a thing), Healthcare.gov could very well be a lucrative target for those wanting to steal and resell large databases of information or those that want access to other interconnected systems. It also might be the prime target of a politically motivated, anti-Obamacare group, which by the way, was something that was confirmed and highlighted during the HOGRC hearing.

In general, healthcare organizations are a target for a number of reasons (Identity theft, Insurance fraud, financial Information theft, ransomware attacks, etc). For a small sample of healthcare organizations that have been victims to hacking or other IT incidents, you don’t have to look any further than OCR’s Breach “Wall of Fame” website (see those classified as “Hacking/IT Incident”). Personally, I’d be interested to see the threat model data on which Mr. Krush based his assertion that Healthcare.gov is not a lucrative target.

You can hear Mr. Kennedy’s rebuttal to the assertion that Healthcare.gov is not a target at about 01:02:00 of the HSSTC hearing where he highlights the possibilities of political motivations, organized crime, black market sale of compromised infrastructures, identity theft, and state sponsored attacks. Of course, if that’s not enough, just refer to the testimony of Mr. Charest, CISO of HHS during the HOGRC hearing where he testified that “There’s attempts all the time” to hack Healthcare.gov.

In the end, the argument as to whether it truly is a legitimate target may be moot. As Rep Buschon (IN) put it,

“It really doesn’t matter if Healthcare.gov is a low-propensity target by some hackers out there. In the minds of the American people when you mention their healthcare, this is the biggest target in the Federal government in their minds. Whether that’s real or perceived doesn’t really make a difference.”

Misinformation and Red Herrings

There were several instances of head-slappers and inaccurate statements being made in both hearings. Here are a few that I found most interesting and/or appalling.

Healthcare.gov hasn’t been hacked yet so it must be secure

This flawed argument was repeated several times by multiple individuals. For example, Rep. Eddie Johnson (TX) went through a laundry list of recent breaches including Snapchat, Facebook, LinkedIn, Yahoo, and Neiman Marcus in order to support the following point:

“However do you know one system that has not been successfully hacked since the last hearing? Healthcare.gov.”

First, how do you know, especially since a mature monitoring capability was not implemented until at least November? How long did it take Google or RSA to detect their respective breaches?

Second, what does that prove? Is it a testament to the site’s supposed security or rather a testament to good luck, poor monitoring and detection capabilities, or the skill of the malicious actors already inside the system? Should we wait for something bad to happen before we do something about it? Forget security…anyone that knows anything about deductive reasoning understands that this argument is flawed. 

Ms. Johnson went on to say: 

“I hope that the committee meeting will be last of this topic absent some actual allegations of wrongdoing so that we can focus on legitimate oversight issues facing the country”

“Legitimate” issues? Is protection of Americans Personal and Healthcare information not legitimate?

The Confusion Over Passive Reconnaissance

Mr. Kennedy submitted a collection of letters from some of the top minds in the Information Security space attesting to the risks posed by vulnerabilities uncovered via passive reconnaissance. Unfortunately, this concept was lost on some. At about 00:47:50 into the HSSTC hearing, Mr. Krush, when discussing incident reporting, equates scanning a website to passive enumeration:  

“Most government websites literally are enumerated passively, meaning, and this is still considered an incident via DHS, if you go through and you do scans on a website meaning that you’re looking for open ports, protocols, and services, that is considered an incident.” … “I got a call last night from actually a news reporter, and they called me up to talk about Mr. Kennedy’s um, you know, analysis he had done on the website and I just want to be clear that, you know, if him and his security researchers actually did go to a .gov, they did passively enumerate and actually pull data in an unauthorized manner, than that is a very significant issue”. … “I went to the course while I was in the military, uh for the FBI, and I can tell you that that is a great concern to us when anybody goes out to a Federal government, a website without permission, and is actually passively enumerating then executing something to pull data off that website.”

So you went to a course Mr Krush? I bet they didn’t cover passive enumeration because you clearly don’t understand what it means. To that end, I think my next post will be on passive reconnaissance techniques so others don’t operate under the same misconceptions.  

The Misrepresentation of Honeypots and “Enhanced security” measures

A “funny-if-it-weren’t-so-sad” moment came at 01:55:00 in the HSSTC hearing when Rep. Robin Kelly (IL) directed her line of questioning to Mr. Krush. It started when Mr. Krush brought up the concept of using honeypots to gather information and build security countermeasures.

Kelly: “I’ve also been told that a site security team will leave the appearance of a weakness in place so that hackers will waste their time and other times as I understand it, seeming weaknesses are purposely put in place…like you just said honeypots, where a genuine hacker or even a white hat hacker gets caught trying to penetrate a system and you just said that that was true. Do you imagine, with um, Healthcare.gov, that honeypots are in place?

Krush : “So Ms. Kelly, because I didn’t set up the honeypot, I can’t speculate on that either but it is a very normal practice and best practice in the government to set up honeypots…”

Kelly: “The Healthcare.gov site uses remote authentication to help verify the users are who they claim they are in order to help cut down on medical fraud. These sorts of security practices can sometimes make websites clunky and the user interface problematic. Can you address this issue for us? Is it possible that these sorts of kinks and glitches experienced on Healthcare.gov were due to its enhanced security measures by any chance?” 

Krush: “To answer your question, that is a possibility, but I didn’t actually do the identity management system so once again I can’t really talk to that fact”.

So in other words, the site is so secure, it just appears to be insecure? Give me a break. Shame on both of them for insinuating that the security issues thus far identified by researchers are really the result of honeypots and other “enhanced” security measures.

Blatant, inappropriate attempts to discredit witnesses and their arguments

I was pretty frustrated by a few Committee members in both hearings, possibly none more so than Rep. Donna Edwards (MD) – who used part of her time in the HSSTC hearing, not to talk about security, but rather to question whether Mr. Kennedy had completed the appropriate financial disclosure paperwork before appearing before them. Even after it was clearly established that it was not a requirement, she and other members of the Committee continued to bring it up in an effort to have his testimony “stricken from the record” (see 01:28:00 of the HSSTC hearing).

Interestingly, while she and others focused on this seemingly inconsequential piece of information, Ms. Edwards did not pick up on the fact that Mr. Krush cited himself as a co-author of NIST SP 800-53A. I was not able to find him as a credited author in the most recent version (Rev 1 released in June 2010). His name does appear in the July 2008  version, where he was not credited as an author, but rather was acknowledged by the authors as being a participant in the Assessment Case Development Project that appears in Appendix J. Does that by itself mean he’s not qualified to be a witness? Absolutely not; but it’s certainly more relevant to his asserted expertise than a paperwork technicality.

Dr. Ponemon highlighted the impact of identity theft, medical identity theft, and credit card theft and how the loss of one’s identity can destroy a person’s wealth, reputation and in some cases even their health. He also called attention to the fact that tools such as credit reporting do not track medical identity theft, making it harder to detect. He personalized the issue and tied it to healthcare by telling a quick story about his 88-year old mother was admitted to a hospital last year. During her hospital stay, an identity thief made copies of her driver’s license, debit/credit cards, and other info, and proceeded to wipe out her back account and charge thousands of dollars to her stolen cards. It was a small but relevant example of how identity and credit card theft relate can relate to healthcare service providers but of course the message was lost on some — namely Rep. Edwards who for some reason felt the need to clarify that Dr. Ponemon’s mother’s identity was not stolen via Healthcare.gov — even though he never said it or implied it (and it was clearly not the point). 

What security controls have been implemented to-date?

According to Ms. Fryer’s testimony, independent security contractors completed a security assessment of the FFM on December 18^th with no open High findings.

“This security control assessment met all industry standards, was an end-to-end test and was conducted in a stable environment that allowed for testing to be completed in the allotted time”.

Also, CMS has since established a dedicated security team

“to monitor, track, and ensure the activities in the ATO memo are completed. This team is responsible for the weekly testing of the border devices and internet-facing web servers and scans using continuous monitoring tools. Ongoing vulnerability assessments of the FFM network infrastructure and internet facing web servers are conducted through penetration testing which involves simulated attacks to breach the security defense of the website and continuous monitoring of marketplace related systems to alert security professionals of any new vulnerabilities that may exist due to recent changes or maintenance.”

From what we’re hearing from Mr. Dave Kennedy and his colleagues, since November 19^th, of the 17 previously disclosed vulnerabilities, only ½ of a single vulnerability has been addressed and 20 additional exposures have been identified: https://www.trustedsec.com/news-and-events/

As concerning as this might be, it’s still only a limited view of the overall security risk picture. I think that the new controls implemented since November and tested in December should be presented to the same security professionals being called as expert witnesses by the HSSTC in order to obtain their feedback and recommendations. 

Despite whatever controls may have been put in place, towards the end of the HSSTC hearing, two of the four witnesses asserted that the site is not was not currently secure (see 01:50:00). A third, Dr. Ponemon, while acknowledging that he is not a security expert stated

“As a citizen of this country, I’m concerned, I’m not happy with what I’m hearing here”.

Only Mr. Krush believed the site was secure enough to process his own personal data, though there was some indecisiveness. When initially asked by Rep. Chris Collins (NY) whether he thought the site was secure, his response was:

“None of us worked on healthcare.gov so speculating that it’s either secure or not is just not something I’m willing to say.”

But, his stance quickly changed…

Collins: “So you would say today, you would not state affirmatively to the American public that it is secure?”

Krush: “Based on the information that I have read, a risk based decision was made, there was a mitigation strategy that was very clear, they are doing weekly scans, they’re doing daily scans, they’re doing mitigation and remediation…I would say, that’s pretty secure”.

Collins: “So you are stating yes, it is secure?”

Krush: “I am stating based on the information I have right now, I would say it’s secure”. 

One of the most memorable (and scariest) exchanges came at the very end of the HOGRC hearing between Rep. Chaffetz (UT) and Ms Fryer, the CISO of CMS:

Chaffetz : “Let me ask you, um, when it was launched Ms Fryer, what percentage of the data transfers to the local servers was done over a Secure Socket Layer?”

Fryer: “I can’t answer that question, I was not involved in the operational day to day security and the details of that.”

Chaffetz: “But you are the Chief Security Officer, aren’t you not for this? What percentage today of the data transfer is done over a secure socket layer?”

Fryer: “Again, that’s the operational, I’m not involved in the development and implementation of the…”

Chaffetz: “But you are in charge of the review of it, correct?”

Fryer: “I’m in charge of the review of the findings during the security control assessment, that the independent security control assessments that are conducted.”

Chaffetz: “Are any of you aware [addressing all three testifying members], what percentage of the data that goes from the computer to the server is done over a secure socket layer?” [pause] “None of you know the answer to that question?” [pause] “How much of this data as it’s transferred is encrypted?”

Fryer: “The data is encrypted. It is a requirement…”

Chaffetz: “What percentage of the data is encrypted?”

Fryer: “It is encrypted.”

Chaffetz: “What percentage of it?”

Fryer: “It would be 100 percent of the data.”

Chaffetz: “But you just said you don’t know what percentage was done over an SSL.”

Fryer: “You’re asking what percentage during testing”

Chaffetz: “No, I wanna know of the actual live site when somebody in Missouri signs up and they’re sending that information is it all done over an SSL?”

Fryer: “They don’t send the information over…it depends on if it’s a state-based marketplace or are they accessing…”

Chaffetz: “If you’re using Healthcare.gov is it, is that information encrypted or not?”

Fryer: “Yes”

Chaffetz: “What percentage of it?”

Fryer: “It’s encrypted, it’s 100 percent.”

Chaffetz: Was it on day one?

Fryer: “Yes, that was the requirement to be in place.”

Chaffetz: “But you don’t know what percentage was done over a secure socket layer which is somewhat similar to saying is it encrypted or not and you said you didn’t know.”

Fryer: “Again, I don’t know the technology, I’m not involved in the operational day-to-day security. I have almost 200 FISMA systems in CMS I don’t…that’s why we have Information…”

Chaffetz: “So if I have questions about JavaScript and how you encrypt some of that, you wouldn’t know the answer to that?”

Fryer: “I know the technical, I don’t know of every system in CMS, I don’t know the technical details.”

Chaffetz: “We’re talking about Healthcare.gov, it’s probably the most visible…who does know the answer to that question?”

Fryer: “The Information Systems Security Officer is the group for the day-to-day development and implementaiotn of security requirements for Healthcare.gov”

Chaffetz: “It scares the living daylights out of me that none of the three of you know the definitive answer…”

Me too…

How could these hearings have served us better?

While I’m certainly glad the issue of security is getting national attention, I was disappointed that instead of getting the most out of their time with these industry and agency experts, some of the Representatives used the opportunity for political grandstanding.

From the HOGRC hearing, I would have like to have gotten definitive answers to the following questions to better understand the current level of risk with Healthcare.gov:

• What was the scope of the original security test plan for the site, was it followed, and what type of testing was conducted (hands-on penetration tests, control assessments, etc)?
• Has there been recent end-to-end, third-party testing and if so, did it validate remediation of all of the previously identified vulnerabilities? If not, what is the plan to remediate the remaining issues?
• Do you have plans to communicate with Mr. David Kennedy and the other security professionals that have reviewed the vulnerabilities discovered via passive reconnaissance to ensure those findings will be incorporated into the existing remediation plan, as well as to determine if your current testing process can be improved to identify similar issues?
• How do the individual state marketplaces tie into the Healthcare.gov site (interconnections) and what level of coordinated and standardized security testing was conducted for each of those sites prior to their integration with Healthcare.gov?
• What other systems does Healthcare.gov interface with and what types of data is stored/processed by these systems?

For the HSSTC hearing, the Representatives could have better used the time by asking some very basic questions:

• What can we (the government, CMS, etc) learn from you as seasoned security professionals in order to 1) fix the current problems with the site, and 2) ensure they never happen again.

And then just be quiet, listen, and take copious notes…

I think that all of the witnesses tried to get these points across as best they could but more time could have been spent picking their brains rather than trying to discredit their assertions.

What are the next steps?

If you listen to the testimony of Mr. Kennedy, Mr. Gregg, and Dr. Ponemon, it’s clear that none are indicating that Healthcare.gov is a hopeless cause. Refer to Mr. Kennedy’s published written testimony and you’ll clearly see he is advocating fixing the current site while concurrently developing a more secure solution via a SecSDLC process. Mr. Gregg was quoted as saying: “There’s no doubt that Healthcare.gov can be fixed if the right people are given the chance to test it.”

Obviously, these problems can’t be fixed overnight but there’s no questions as to whether or not they can be properly addressed if the right people are involved. Based on what I heard during the hearings, these would be my recommendations (most of which were echoed by the expert witnesses). 

Conduct independent, end-to-end testing and validation activities

Based on what I heard in the HOGRC hearing, it sounds like third-party end-to-end testing may be happening (or already has happened). These test results and any associated mitigation plan should be reviewed by internal (CMS) and trusted external parties to ensure they are reasonable and take into account appropriate threats/risk.

Fix the identified vulnerabilities

While looking back on what happened to learn from past mistakes is important Healthcare.gov is now live and operational, so timely fixes of existing vulnerabilities is a must. Based on testimony from the HOGRC hearing, it sounds as if this is happening, though there are still an undetermined number of open findings, including those identified by Mr. Kennedy and reviewed by his colleagues. These should also find their way into the remediation plan.

Provide some level of assurance to the public

Anyone that has security or risk management background would understand that there is no way to guarantee absolute security of any system. As Mr. Krush pointed out, it will always come down to a Risk Management decision. The key is to provide the individual making that decision with a complete and accurate security information.

In addition, some assurances have to be provided to the end-users. I’m not at all advocating that the prior or existing vulnerabilities be published publicly, as some of the Committee members seem to be suggesting. Non-disclosure agreements are an important part of our business and sometimes it’s better to avoid publicizing vulnerability details. That being said, users of the site are entitled to assurances that the appropriate security controls have been implemented and tested and that identified vulnerabilities have been remediated.

These points were made by Representatives and expert Witnesses alike. Rep Buschon (IN) a former practicing physician and proponent of electronic medical records stated:

“To argue that this website is going to be secure and that nothing is going to happen I think is a false argument” … “I think all of us in hearings like this and across government, uh, in the administration, in both political parties need to recognize the fact we need to do whatever we can to regain the confidence of the American people, that we’re protecting their personal information as best we can.”

Fix the existing process so this does not happen again

This can be a very useful lessons-learned opportunity. If the existing processes can be improved to prevent this from happening again, future system deployments will benefit. The application/system design process must include security from the start, with iterative, testing both pre and post-implementation and continuous monitoring and security testing throughout the lifecycle. To be honest, most if not all of these best practices are already codified in existing NIST standards. The processes simply need to be documented, refined and most importantly, followed. The devil is in the details and the execution!

Get the right personnel involved

This ties directly to the previous recommendation. A good process requires quality people to execute it correctly. Some of what I heard during the testimony was concerning. In many cases I was impressed with the witnesses that appeared before the two Committees yesterday.

Kevin Charest seemed to be fairly well versed on the operational processes under his control. Likewise, I’m familiar with the work of Mr. Kennedy and Dr. Ponemon and I applaud the Committee’s decision to seek their guidance. I would suggest that they make an effort to get these experts (or others like them) more involved so they can go beyond providing expert opinions based solely on a limited data set.

There were other witnesses whose testimony was concerning to me. I have to be honest, I don’t know Ms. Fryer or her qualifications but I’m always worried when I hear a Chief Information Security Office state “I don’t know the technology” and insinuate that she isn’t aware of technical details because she has “almost 200 FISMA systems in CMS”. I hate to be viewed as an armchair quarterback and maybe it’s a workload issue, but someone should investigate whether she needs additional resources.

I also hadn’t heard of Mr. Krush until yesterday, but it appears he is deeply involved in government security contracts. Maybe it was nerves, maybe it was the short amount of allocated time, but he did not seem to have a clear grasp on some basic information security topics and his assertion that Healthcare.gov is secure without any direct involvement in the testing or review of existing vulnerabilities is definitely concerning. Unfortunately, he seemed to be more of a political plant than a representative of the information security community so I discounted the value of his testimony.

Conclusion

Hopefully you found this post interesting enough to learn more about the current situation with Healthcare.gov but ultimately I hope that you walk away with the understanding that it’s so much bigger than a single website. For us security professionals, this issue highlights the importance of security in the development and implementation of a large-scale application on a national stage. It’s a lesson to both government and private industry that security must be a consideration throughout the system lifecycle and failure to do so is way too costly.  

I’ll leave you with a quote from Mr. David Kennedy that sums up the current status of Healthcare.gov:

‘It’s not a question as to whether or not it’s insecure, it’s what we need to do to fix it.”

The views expressed in this blog are my own. Just to be clear, that means they are not the views of my employer, co-workers, family, friends, casual acquaintances, strangers, or anyone other than myself. 

Follow @SecuritySift