VMware exec Tony Scott named new Federal CIO

The White House announced on February 5 that Tony Scott will become the new Chief Information Officer for the federal government, filling a position within the Office of Management and Budget (OMB) that has been vacant since Steven VanRoekel resigned the post last fall. The appointment of Scott – who comes to OMB from virtualization technology market-leader VMware, where he was senior VP and CIO – provides a clear indication that the administration remains serious about modernizing the way it invests in and manages its information technology resources, particularly including the use of cloud computing services.

Scott will presumably be tasked with continuing the work of his immediate predecessors, including Vivek Kundra, who as the Obama administration’s first federal CIO established the government’s “cloud first” strategy and oversaw the creation of the Federal Risk and Authorization Management Program (FedRAMP) that enabled cloud service providers to demonstrate the implementation of security measures sufficient to satisfy federal government requirements. After a brief stint in academia at Harvard’s Kennedy School, Kundra showed he believed in the value of the FedRAMP program by joining software-as-a-service powerhouse Salesforce.com, which attained an authorization to operate (ATO) under the FedRAMP program in May 2104.

HealthCare.gov shares consumer data with lots of third parties

Update: Less than a week after the AP, EFF and multiple media outlets brought to light the data sharing described below, the government appears to have altered the website code on HealthCare.gov so that no personal data is now shared with third-party tracking sites. Presumably the government has a continuing business interest in measuring the performance of the website and collecting aggregate statistics about its usage, and will continue to get some information of this type through Akamai and other web infrastructure vendors associated with the site.


As reported by the Associated Press this week and confirmed through testing by the Electronic Frontier Foundation (EFF), some personal information provided by users of the government’s HealthCare.gov website is automatically collected and sent to more than a dozen third-party companies, including online advertising and social media sites. According to the EFF, among the personal attributes sent to third-party sites are age, zip code, income, and self-reported status for things such as whether a consumer is a parent, a smoker, or pregnant. These data elements are all items that consumers enter on the insurance exchange site as part of the process of either determining eligibility for coverage or actually applying for insurance through the federal marketplace. Once a user has created an account on HealthCare.gov, but before anything other than demographic data is requested, the site presents and requires users to agree with a privacy statement that begins, “We’ll keep your information private as required by law. Your answers on this form will only be used to determine eligibility for health coverage or help paying for coverage.”

Consumers visiting HealthCare.gov are directed to multiple privacy notices, including the HealthCare.gov privacy policy, an individual Privacy Act statement, and a sort of frequently-asked-questions page explaining how individual information collected on the site is used. These pages also make reference to two privacy-related documents that the government is required to publish under current regulations: a privacy impact assessment (PIA) and a system of records notice (SORN). While a copy of the SORN covering the health insurance exchanges established under the Affordable Care Act is available online, the PIA is not, since the most recent PIA information for all systems maintained by the Department of Health and Human Services (HHS) is from the fourth fiscal quarter of 2012. None of these sources of HealthCare.gov privacy information mentions sharing consumer data with commercial third-party organizations, although one – the site’s privacy policy – refers to the use of “Web measurement software tools” that continuously collect information from site visitors. The privacy policy, however, states in bold text that “No personally identifiable information is collected by these tools.”

The EFF and others examining this data sharing behavior seem to accept as a given that the data being “quietly” shared (that is, without any explicit notice to consumers) is personal health-related information that should presumably be protected by existing regulations and restrictions on information sharing. In responses to questions from AP, the administration chose to defend the information sharing by noting that the third parties receiving the data are prohibited from using the data for purposes other than serving consumers on HealthCare.gov, although it’s not clear what the basis of such prohibition would be, since these commercial firms are not bound by either the Privacy Act or HIPAA. It is possible that each of the third-party organizations with which the government is sharing consumer details has executed a data use agreement or entered into another type of contractual agreement with the Centers for Medicare and Medicaid Services (CMS), the HHS agency responsible for administering the insurance marketplace. Such contractual obligations would augment existing regulations constraining the secondary use of information collected by federal agencies (including the restrictions on marketing added to HIPAA by the HITECH Act). What seems strange is that none of the many privacy notices and descriptions of information sharing practices provided by the government actually address sharing the kind of data that AP and the EFF identified.

The legality of this undisclosed information sharing hinges on whether the data in question actually fall under the definition of personally identifiable information (PII). The official government definition of PII comes from OMB Memorandum 07-16, which says PII is “information which can be used to distinguish or trace an individual’s identity, such as their name, social security number, biometric records, etc. alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual.” Although the government has not offered an assertion to this effect, the argument could be made that the attributes being shared are not personally identifiable information because they cannot be used to individually identify anyone. It is the second part of the government’s PII definition that is troublesome for the HealthCare.gov data sharing, because many of the third parties receiving the data already have in their possession large quantities of consumer information that could presumably be matched with the data coming from HealthCare.gov. The government should be acutely aware of this possibility, since one of its long-time privacy advisers is a leading researcher in “re-identification,” and because HHS’ Office of the National Coordinator for Health IT has funded research about re-identifying individuals from datasets that have purportedly been de-identified. Even if the data elements sent to major web analytics, advertising, and social media companies are not personally attributable as transmitted, it should not be very challenging for these firms to combine HealthCare.gov data with other public or commercial data sources (including their own databases). If such matching is feasible for even one of the third parties, then HealthCare.gov is not only failing to comply with its own privacy policies, but possibly violating several federal privacy regulations.

Changes coming for federal infosec managers

Information security managers in federal government agencies should expect to see new obligations and rules on security management practices in 2015, with changes brought about by the Federal Information Security Modernization Act (FISMA) that became law at the end of 2014 and from updates to key guidance from NIST, OMB, and DHS. The most relevant changes include:

  • Implementing and maintaining continuous monitoring, likely enlisting the assistance of DHS and its Continuous Diagnostics and Mitigation (CDM) program, which is available to all agencies under a GSA-managed blanket purchase agreement. Each agency was supposed to have developed and submitted to OMB their information security continuous monitoring strategy (ISCM) last year, so with strategies in place, execution is the focus for 2015.
  • Updating incident notification and reporting practices, to comply with requirements issued by US-CERT and to meet new requirements (particularly for reporting to Congress) included in the 2014 update to FISMA.
  • Modifying security control assessment procedures following guidance in NIST Special Publication 800-53A Revision 4, released in December. Compared to the prior version, the revised assessment procedures break down security objectives (derived from security control descriptions in Special Publication 800-53) into a more fine-grained and explicit set of criteria to be used in security control assessments. The new guidance also includes assessment procedures for the privacy controls first added by NIST in April 2013 with 800-53 rev. 4.
  • Adapting security management reporting procedures to satisfy new OMB and DHS requirements, including still to-be-determined changes to OMB Circular A-130, Management of Federal Information Resources, called for in the new FISMA law “to eliminate inefficient or wasteful reporting.” These revisions to A-130 may not be made until much later in the year, but they are expected to substantially alter the documentation and checklist-driven practices associated with system certification and accreditation under the current A-130 Appendix III, which was last updated in 2000.

Collectively, these anticipated changes (plus whatever prescriptive guidance DHS may issue under its newly codified authority over agency security operations) will make 2015 a year of transition for federal system owners and program managers (and their contractors) as the government tries to mature its information security management practices.

Newly arriving from DHS: binding operational directives

The Federal Information Security Modernization Act of 2014 introduces a new term to the federal security management lexicon: binding operational directive. The text of the law defines binding operational directive as “a compulsory direction to an agency that is for purposes of safeguarding Federal information and information systems from a known or reasonably suspected information security threat, vulnerability, or risk.” While somewhat common in financial and military contexts – both the World Bank and the U.S. Department of Defense, for example, frequently use the term operational directive in official documents – its appearance in FISMA 2014 seems novel, at least for federal legislation. Its purpose here appears to be directly tied to the responsibility that the Act assigns to the Secretary of the Department of Homeland Security (DHS) to issue, in consultation with the Director of the Office of Management and Budget (OMB), mandatory instructions to agencies about implementing security measures and practices called for in FISMA or in policies, standards, or guidelines developed under FISMA’s authority. Binding operational directives will presumably supplement or replace the security-related memoranda regularly issued by OMB. Because DHS is an executive agency, not part of the Executive Office of the President like OMB, directives from DHS would presumably not be mandatory for peer agencies without the additional statutory authority that FISMA 2014 provides. Going forward under FISMA, operational information security directives issued by DHS will be compulsory for all federal executive agencies (Congress and the courts will remain outside FISMA’s scope), enabling DHS to more effectively perform its cybersecurity responsibilities under the law.

FISMA 2014 codifies many current federal security practices

The Federal Information Security Modernization Act of 2014, enacted by Congress in mid-December along with three other pieces of cyber-security-related legislation, is noteworthy primarily for its emphasis on continuous monitoring of the security of federal systems; increased attention on incident detection, response, and reporting; and formally assigning the Department of Homeland Security (DHS) responsibility for developing, implementing, and ensuring government-wide compliance with federal information security policies and practices. For the most part, however, the 2014 update to FISMA introduces little new to federal security management, but instead codifies roles, responsibilities, requirements, and practices already put in place through OMB memoranda and other official guidance to agencies. A side-by-side comparison of the 2002 and 2014 FISMA legislation shows substantial similarities in the text of both laws, with major differences in only four aspects:

  1. Responsibilities assigned to the Secretary of DHS (§3553(b))
  2. Agency reporting requirements (§3554(c))
  3. New guidance and reporting requirements on security incidents (§3554(b) and (§3558(b))
  4. Policies and guidelines on data breach notification (§3558(d))

The 2002 FISMA law assigned essentially all agency oversight responsibilities to OMB (with annual reports to Congress), the 2014 version divides these responsibilities between OMB and DHS. To be fair, at the FISMA was enacted, it would have been infeasible to delegate explicit responsibilities to DHS, since the Homeland Security Act establishing that Department passed just three weeks before FISMA. The 2014 law has OMB handling information security policies and practices and overseeing NIST’s development of standards and guidelines and DHS leading the implementation of those policies, practices, and standards as well as monitoring agency information security practices and, when asked, providing technical assistance to other agencies. This separation of duties under FISMA 2014 is consistent with a clarification of cybersecurity responsibilities between OMB and DHS spelled out in OMB Memorandum M-10-28, issued in July 2010. M-10-28 placed administrative, budgetary, and fiscal oversight with OMB and gave DHS primary responsibility for “operational aspects” of security in all executive agencies, importantly including government-wide incident response.

Much has been made of the provision near the end of the new FISMA legislation that instructs OMB to update its Circular A-130 to “eliminate inefficient or wasteful reporting.” Appendix III of Circular A-130, last revised in 2000 a little more than two years before FISMA was enacted, contains the requirement that agencies formally authorize each of their information systems before putting them into operation and re-authorize them at least every three years. The language in the new law, taken together with the emphasis on continuous diagnostics and monitoring, is assumed to imply that agencies will no longer need to undergo system assessment and authorization processes for the systems they already have operating. Despite the appeal of this interpretation, it is not at all clear that the time- and labor-intensive set of activities and security artifacts specified in the NIST Risk Management Framework will be set aside in favor of robust monitoring programs. Also overlooked is the fact that OMB somewhat quietly waived the every-three-year re-authorization requirement in an answer to a question in the “frequently asked questions” section of its fiscal year 2011 FISMA reporting instructions to agencies, which explained that the implementation of continuous monitoring programs by agencies would obviate the need for system re-authorization every three years.

With respect to security incident reporting and breach notification, FISMA 2014 both substantially augments the obligations of federal agencies for incident handling and reporting and incorporates provisions in official guidance to agencies issued since the 2002 law went into effect. FISMA 2014 provides its own definition of incident: “an occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.” It also adds an agency obligation to report “major incidents” within seven days of their occurrence to designated Congressional committees, in addition to existing requirements to report incidents to appropriate agency officials. There is no reference in the new law to current reporting timeframes for notifying the U.S. Computer Emergency Readiness Team (US-CERT) of incidents, which in the case of incidents involving highly sensitive data require notification within one hour of discovery. This reporting requirement has been in place since 2007, and seems unlikely to change, even as US-CERT now officially falls within the National Cybersecurity and Communications Integration Center codified in the National Cybersecurity Protection Act of 2014 (one of the other bills enacted with the new FISMA legislation).