With the deadline for the Affordable Health Care Act website here, the performance issues of the website healthcare.gov seems to be addressed, at least partially. In a press release, HHS reported that over 400 bugs and fixes had been addressed and an influx of server hardware and software fixes to address the stability issues with the October 1st release. The repair consisted of the some of the following areas: • Made hundreds of software fixes, upgraded hardware and monitored the system to make improvements; • Stabilized the site at its original intended capacity; and • Improved overall metrics, which means the site is working well for most users. Out of all of the reports, there were no mention to security concerns or addressing the vulnerabilities identified in the healthcare.gov website. Recently, TrustedSec's CEO presented in front of Congress on the security concerns on the healthcare.gov website. A prior post plus written testimony can be downloaded here. Out of the concerns, a number of undisclosed exposures have still not been addressed and exist today. This includes exposures identified by TrustedSec and other independent security researchers like Bob Rich who reported exposures several months ago and Bob Simo who found additional exposures. Please note that TrustedSec performed no form of hacking, just passive analysis of the healthcare.gov website. One exposure identified is the ability to perform an open redirect, there are multiple open redirects still vulnerable on the healthcare.gov website and supporting sub-sites. As an example, below is a video from an exposure identified by Gillis Jones (independent security researcher). This exposure has since been fixed however very similar ones on the healthcare.gov and healthcare.gov sub-sites still exist. An example of what can happen in these scenarios is an attacker can send a targeted email to an individual that has signed up for healthcare.gov or is looking to and have it appear valid and legitimate and originate from the healthcare.gov website. Note that this one was on a sub-site however direct ones exist on healthcare.gov that still have not been addressed. Below is an example of going to the link and it redirecting to a malicious website that hacks the computer and takes complete control over it. Additionally, TrustedSec identified the ability to enumerate user information (first, last, email, userid, profile, etc.) through one of the sub-sites that directly integrates into the healthcare.gov website. Below is an example of a script that enumerates as many users as you want (please note all information has been redacted as to not expose the vulnerability until it is fixed). Tens of thousands of user-based data appears to be vulnerable on the specified website and has not been addressed. There are a number of other exposures that have been reported privately that continue to expose users of the healthcare.gov website. It appears that the release and launch date of the website was purely on the functional levels, not that of the security. These are just two examples of many others that are still present on the healthcare.gov website and the supporting infrastructure. While this is a heavily political topic, TrustedSec takes no stance politically period. This is purely a privacy and security concern issue and much larger concern for government security as a whole. Regardless of beliefs, political views, or stances, the website continues to incorporate poor security practices and should be addressed as soon as possible. What healthcare.gov has shown us is a much larger issue in the government procurement process around building security into applications. It is not specific to healthcare.gov alone, the state exchanges area of focus as Vermont just recently disclosed a security incident and the state exchanges appear to have even more systemic problems than its parent healthcare.gov. This issue spans both federal and state and should be a serious concern for everyone. In the private sector, many (not all) organizations have successfully integrated security into the development lifecycle of building the applications versus after the fact. Successful organizations such as Facebook, Microsoft, Twitter, and others are not impervious to flaws within software, but are much less susceptible and reduce the risk based on solid security practices. Security needs to be integrated into every aspect of development and infrastructure support on all levels of the government. Typically when contracts are selected, they are required to meet the Federal Information Security Management Act (FISMA) requirements and guidelines which is often left for interpretation, rarely specific, and often overly vague inside the contract language. The rules need to be tightened as we continue to see both federal and state websites defaced, compromised, and sensitive information stolen or posted online. It's time for the federal and state government to step up and invest in the appropriate controls to protect sensitive information that conforms to industry best practices and most importantly, practices that work. Until we move to a more secure development lifecycle in both the state and federal government, we will continue to see websites like healthcare.gov rise with little security controls in place.