I can’t count the number of security leaders that I talk to who either are planning, implementing, or just coming out of a re-org, whether self-inflicted or due to upheaval in the ranks above or to the sides. And let’s not even mention the ongoing game of CISO musical chairs that decapitates entire programs and leaves them listless for months on end. I see far more damage to the infosec capability at these businesses from this ongoing restructuring than I ever do from malware outbreaks: management loses confidence and hard-won political capital vanishes, operations and key initiatives get whipsawed by shifting attention, budgets are unpredictable, infrastructure investments wither from lack of care and feeding, morale and cross-group perception ranges from cynical to downright bleak, and a sense of helplessness pervades a practice that is supposed to be enhancing visibility and control over IT.

Certainly, change is inevitable, and some restructuring can of course be good if done thoughtfully to improve clarity of mission, roles and responsibilities, or other fundamentals. But my sense is that we’re changing too much, too often, and it’s disrupting our focus, damaging our credibility and ability to get things accomplished in the long view.

It’s time to adopt a more cross-generational perspective, align around a few fundamental practices that must be sustained for posterity, and keep the eggs incubating in the nest for a little bit longer. Because whatever your opinion about APT, I think most would agree on the “persistent” aspect. What’s your infosec succession plan?

Large disparity in quantity of findings. The first product found 2 Critical severity (4 instances each), 1 High (5 instances), 3 Medium (9, 9, and 1 instances respectively), 4 Low (1 instance each), 5 Informational (4, 1, 1, and 152 instances), and 3 Best Practices (2, 1, and 2 instances) vulnerabilities for a total of 13 vulns and 195 instances. The second tool found 1 Low severity vulnerability (1 instance), yielding a 1,200% difference in quantity of findings. Clearly, the first product implemented much more sophisticated checks with greater efficiency (both scans took under 5 minutes), indicating to us that there are differences in quality of commercial web app scanning tools. The quality of the findings was also a factor however, as we discuss next…

Signal-to-noise ratio was about 30%. We spent about a day manually validating the Critical, High, and Medium findings from the first tool (6 vulns, 28 instances total). This seemed noteworthy by itself; consider the amount of effort to perform such validation on a larger scale application(s). Based on our findings, the manual validation was worthwhile. Of the 2 Critical vulnerabilities, 1 was a false positive (diagnosed as Cross-Site Scripting, XSS, since the error page returned user input, even though it was escaped and we were unable to manually execute the input), and one appeared to also be a false positive, but turned out to be a false negative of a sort (XSS input by scanner would not execute, but we did find a variant that executed after some experimentation). Of the 13 vulns found by the first tool, we only found two issues that justified expedited mitigation, and two that warranted low-priority remediation. We were unable to verify the single Low severity result of the second tool, so it appeared to be a false positive. Thus our extrapolation of signal-to-noise across both tools was 4/14 = ~30%, not an encouraging ratio for those who simply rely verbatim on canned scanner reports.

Severity rankings made prioritization difficult. In both of the cases discussed above, XSS was non-persistent and did not appear to warrant a Critical severity ranking. The vulnerability scored “High” was “ActiveX Control Discovery,” and the description alluded to known issues with the Microsoft Active Template Library (ATL) included with Visual Studio used to create ActiveX controls. The “Medium” vulnerabilities were innocuous, relating to IP addresses in headers, failing to mark cookies “secure,” and the use of persistent cookies. We were unable to find descriptions of the severity ratings in the reports generated by the tools, and overall struggled to relate these ratings to probability or impact of exploitation, or amount of effort required to fix the identified issues, leaving us confused as to how to prioritize remediation efforts. Once again, the level of manual refinement required to produce actionable recommendations was concerning.

Overall, we felt the verdict mixed: the first tool efficiently pointed us in the direction of numerous interesting weaknesses, but the level of manual validation required to filter actionable recommendations was concerning. Other reports confirm some of our observations (see for example this comparison of IBM AppScan, HP WebInspect, and Acunetix WVS).

Unquestionably, web application scanning tools provide great value if you are accountable for the ongoing security of large (numbers of) web applications, and they should receive strong consideration for inclusion in the “first tier” of capabilities implemented in a web-centric SDL (along with threat modeling/risk analysis, design assessment, source code review, and security testing). However, be prepared to invest the additional effort to manually tune and review the output to achieve maximum effectiveness.

“The Recovery Act doesn’t change HIPAA, it just pushes electronic records.”
“Business Associates have to comply just as they did before.”
“Enforcement is only for Covered Entities; BAs just follow the contract.”

Dead wrong, all of these.

In an attempt to understand these issues, a recent HIPAA/ARRA seminar attendee posed a simple question about the law reference for the definition of Business Associate, and expressed special interest in the expansion of coverage regarding “organizations that transmit protected health information or require routine access to [Protected Health Information (PHI)].” This question presents an opportunity to discuss foundational references, and cut through the confusion by considering three basic questions:

1. What exactly are a “Covered Entity” and “Business Associate”?
2. What were the original requirements for Business Associates?
3. What exactly did the Recovery Act change for Business Associate compliance?

What exactly are a “Covered Entity”
and “Business Associate”?

HIPAA “Covered Entities” are generally healthcare providers, payers (insurance companies), or other organizations that directly handle Protected Health Information (PHI). “Business Associates” are entities that provide one or more services to Covered Entities, where those services involve PHI.

The legal designation of Covered Entity and Business Associate are not specifically defined within the HIPAA Security Rule, but within the larger context of the Administrative Simplification framework estalished earlier with the HIPAA Privacy Rule. The entire framework is contained within 45 CFR Parts 160, 162, and 164 (link provides a copy of the regulation with updates incorporated). The definition of “covered entity” is contained in 45 CFR Part 160.103:

—– REGULATORY TEXT: from 45 CFR Part 160.103 —–

Covered entity means:

(1) A health plan.

(2) A health care clearinghouse.

(3) A health care provider who transmits any health information in electronic form in connection with a transaction covered by this subchapter.

—– END TEXT —–

The definition of “business associate” is also contained in 45 CFR Part 160.103:

—– REGULATORY TEXT: from 45 CFR Part 160.103 —–

Business associate:

(1) Except as provided in paragraph (2) of this definition, business associate means, with respect to a covered entity, a person who:

(i) On behalf of such covered entity or of an organized health care arrangement (as defined in §164.501 of this subchapter) in which the covered entity participates, but other than in the capacity of a member of the workforce of such covered entity or arrangement, performs, or assists in the performance of:

(A) A function or activity involving the use or disclosure of individually identifiable health information, including claims processing or administration, data analysis, processing or administration, utilization review, quality assurance, billing, benefit management, practice management, and repricing; or

(B) Any other function or activity regulated by this subchapter; or

(ii) Provides, other than in the capacity of a member of the workforce of such covered entity, legal, actuarial, accounting, consulting, data aggregation (as defined in §164.501 of this subchapter), management, administrative, accreditation, or financial services to or for such covered entity, or to or for an organized health care arrangement in which the covered entity participates, where the provision of the service involves the disclosure of individually identifiable health information from such covered entity or arrangement, or from another business associate of such covered entity or arrangement, to the person.

(2) A covered entity participating in an organized health care arrangement that performs a function or activity as described by paragraph (1)(i) of this definition for or on behalf of such organized health care arrangement, or that provides a service as described in paragraph (1)(ii) of this definition to or for such organized health care arrangement, does not, simply through the performance of such function or activity or the provision of such service, become a business associate of other covered entities participating in such organized health care arrangement.

(3) A covered entity may be a business associate of another covered entity.

—– END TEXT —–

What were the original requirements
for Business Associates?

The HIPAA Security “Final Rule” is contained primarily in Subpart C of Part 164, 45 CFR Parts 160, 162, and 164. The major requirements for Business Associates appear in two places in Part 164, subsections 308 and 314.

The discussion regarding HIPAA compliance in the context of Business Associates in 164.308 is commonly interpreted as meaning Business Associates are only required to give “satisfactory assurance” regarding the existence and effectiveness of security controls to Covered Entities using their services. The text also says the security controls must “appropriately safeguard the information,” which often has been interpreted to mean that a Business Associate must provide and maintain only those security controls that relate directly to the service provided. In other words, it has commonly been interpreted to mean that Business Associates should implement HIPAA required or addressable technical and physical controls to protect PHI in their care, but not implement the full complement of administrative controls.

—– REGULATORY TEXT: from 45 CFR Part 164.308 (p.8378) —–

(b)(1) Standard: Business associate contracts and other arrangements. A covered entity, in accordance with § 164.306, may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity’s behalf only if the covered entity obtains satisfactory assurances, in accordance with § 164.314(a) that the business associate will appropriately safeguard the information.

—– END TEXT —–

The other major mention of Business Associates in the HIPAA Security Rule does little to clarify the matter noted above. In 164.314, Business Associates are required to implement “reasonable and appropriate” safeguards for PHI data received. “Reasonable and appropriate” is commonly interpreted to mean extending security controls on behalf of the Covered Entity, but rarely to mean every administrative, physical, and technical safeguard noted in the Final Rule.

For example, a billing service receiving electronic PHI may encrypt the data in transit and at rest, as well as requiring strong access controls in accordance with HIPAA, based on the rationale that HIPAA defines “appropriate” controls. However, many such organizations have considered administrative safeguards such as workforce security (164.308(a)(3)), contingency planning (164.308(a)(7)) or broader technical controls across the enterprise, as out of scope or beyond “reasonable” for a business service.

—– REGULATORY TEXT: from 45 CFR Part 164.314 (p.8379) —–

(a)(2) Implementation specifications (Required).

(i) Business associate contracts. The contract between a covered entity and a business associate must provide that the business associate will—

(A) Implement administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of the electronic protected health information that it creates receives, maintains, or transmits on behalf of the covered entity as required by this subpart;

(B) Ensure that any agent, including a subcontractor, to whom it provides such information agrees to implement reasonable and appropriate safeguards to protect it;

(C) Report to the covered entity any security incident of which it becomes aware;

(D) Authorize termination of the contract by the covered entity, if the covered entity determines that the business associate has violated a material term of the contract.

—– END TEXT —–

What exactly did the Recovery Act change
for Business Associate compliance?

Changes to the HIPAA Security Rule in the ARRA are found in “TITLE XIII—HEALTH INFORMATION TECHNOLOGY Subtitle D—Privacy.” Changes pertinent to Business Associate compliance are noted in two main places:

<!–[if !supportLists]–>■ Sec. 13401. Application of security provisions and penalties to business associates of covered entities; annual guidance on security provisions.<!–[endif]–>

<!–[if !supportLists]–>■ Sec. 13404. Application of privacy provisions and penalties to business associates of covered entities.<!–[endif]–>

These changes simply and forcefully cut through evasive and dissembling discussions about partial compliance by Business Associates. Section 13401 clearly states that the HIPAA Security Rule in its full form (45 CFR Parts 164.308/10/12/14/16) applies to Business Associates, and that guidance will be issued annually for Business Associates and others regarding technical controls. Pointedly, it is no longer at the discretion of Business Associates to determine what constitutes “reasonable and appropriate” security controls.

—– REG. TEXT: Title XIII Subtitle D Sec. 13401 (42 USC 17931) —–

SEC. 13401. APPLICATION OF SECURITY PROVISIONS AND PENALTIES TO BUSINESS ASSOCIATES OF COVERED ENTITIES; ANNUAL GUIDANCE ON SECURITY PROVISIONS.

(a) APPLICATION OF SECURITY PROVISIONS.—Sections 164.308, 164.310, 164.312, and 164.316 of title 45, Code of Federal Regulations, shall apply to a business associate of a covered entity in the same manner that such sections apply to the covered entity. The additional requirements of this title that relate to security and that are made applicable with respect to covered entities shall also be applicable to such a business associate and shall be incorporated into the business associate agreement between the business associate and the covered entity.

(b) APPLICATION OF CIVIL AND CRIMINAL PENALTIES.—In the case of a business associate that violates any security provision specified in subsection (a), sections 1176 and 1177 of the Social Security Act (42 U.S.C. 1320d–5, 1320d–6) shall apply to the business associate with respect to such violation in the same manner such sections apply to a covered entity that violates such security provision.

(c) ANNUAL GUIDANCE.—For the first year beginning after the date of the enactment of this Act and annually thereafter, the Secretary of Health and Human Services shall, after consultation with stakeholders, annually issue guidance on the most effective and appropriate technical safeguards for use in carrying out the sections referred to in subsection (a) and the security standards in subpart C of part 164 of title 45, Code of Federal Regulations, including the use of standards developed under section 3002(b)(2)(B)(vi) of the Public Health Service Act, as added by section 13101 of this Act, as such provisions are in effect as of the date before the enactment of this Act.

—– END TEXT —–

In addition to the full range of controls required by the HIPAA Security Final Rule, the ARRA ensures that Business Associates don’t miss out on privacy and enforcement changes that apply to Covered Entities. Specifically, all new compliance requirements regarding privacy safeguards now directly apply to Business Associates.

Despite the nearly-identical titles of this second section and the one above, this one gives more guidance on current and future changes, as well as guidance on Business Associate Agreements (contracts). The upshot is that those contracts still serve as evidence of compliance safeguards for Covered Entities (a new form of “satisfactory assurance”), but they no longer define the limit of a Business Associate’s responsibility regarding compliance with the HIPAA Security Rule.

—– REG. TEXT: Title XIII Subtitle D Sec. 13404 (42 USC 17934) —–

SEC. 13404. APPLICATION OF PRIVACY PROVISIONS AND PENALTIES TO BUSINESS ASSOCIATES OF COVERED ENTITIES.

(a) APPLICATION OF CONTRACT REQUIREMENTS.—In the case of a business associate of a covered entity that obtains or creates protected health information pursuant to a written contract (or other written arrangement) described in section 164.502(e)(2) of title 45, Code of Federal Regulations, with such covered entity, the business associate may use and disclose such protected health information only if such use or disclosure, respectively, is in compliance with each applicable requirement of section 164.504(e) of such title. The additional requirements of this subtitle that relate to privacy and that are made applicable with respect to covered entities shall also be applicable to such a business associate and shall be incorporated into the business associate agreement between the business associate and the covered entity.

(b) APPLICATION OF KNOWLEDGE ELEMENTS ASSOCIATED WITH CONTRACTS.—Section 164.504(e)(1)(ii) of title 45, Code of Federal Regulations, shall apply to a business associate described in subsection (a), with respect to compliance with such subsection, in the same manner that such section applies to a covered entity, with respect to compliance with the standards in sections 164.502(e) and 164.504(e) of such title, except that in applying such section 164.504(e)(1)(ii) each reference to the business associate, with respect to a contract, shall be treated as a reference to the covered entity involved in such contract.

(c) APPLICATION OF CIVIL AND CRIMINAL PENALTIES.—In the case of a business associate that violates any provision of subsection (a) or (b), the provisions of sections 1176 and 1177 of the Social Security Act (42 U.S.C. 1320d–5, 1320d–6) shall apply to the business associate with respect to such violation in the same manner as such provisions apply to a person who violates a provision of part C of title XI of such Act.

—– END TEXT —–

The risk-shifting sands of HIPAA have changed again, creating business opportunity for some and hardship for others. Smaller and single-service businesses that fit the definition of a HIPAA Business Associate may not be able to bear the overhead of a robust security program and wither, while others may specialize or diversify and grow. However, when considering these costs and problems, it’s important to recognize recent achievements and the generally improving level of health privacy for individuals.

Disclaimer:

Disclaimer: This discussion and its references are not legal advice. Consult qualified counsel for any legal issues that concern you, your organization, or questions of compliance.

More reading:

Excellent reference from HHS.GOV with recent updates:
Unofficial Version of HIPAA Administrative Simplification Regulation Text
Recent HIPAA/ARRA webinar hosted by Neohapsis and Consciere:
The HIPAA Countdown Has Begun: How the Stimulus Bill Affects Healthcare IT
Well-informed blog focused on current health information and HIPAA legal issues:
Information Law Theory and Practice
Community discussion focused on healthcare IT business and compliance issues:
Health Information Trust Alliance

http://dilbert.com/2009-05-24/

The first article highlights the banking industry, pointing out that a great deal of granular information was available prior to the recent credit market correction that regulators and others were apparently unable to assimilate: “Indeed, the credit bubble is a reminder that above all regulators need to know what to do with information once it’s disclosed. Bank regulators had access to the information to know who was at risk for how much, which should have alerted them to systemic risk among brokers, AIG and others. Yet regulators weren’t able to predict the implosion any better than the banks.” [my emphasis]

The second article treats a quite different topic, that of government surveillance. And yet, it highlights some of the same conclusions: “…’electronic surveillance is not always augmenting traditional policing; it is more often than not replacing it, with poor results.’ Likewise, huge collections of information gleaned from private sources such as phone companies, banks and credit bureaus (along the lines of America’s renamed but not abandoned Total Information Awareness Program) are apt to be unmanageable and rife with errors. Mr. Clark notes: ‘There is a fundamental rule about databases: the bigger they are, the more useless they become.’” [my emphasis] That last statement seems particularly devastating to the notion that we can glean immaculate knowledge simply through accumulating large volumes of data (and maybe even more devastating to some big database vendors’ business strategies, but I digress).

The second article continues: “Again and again, Mr. Clark finds, high-tech systems that seem at first to be outrageous invasions of privacy turn out to be outrageous boondoggles that don’t succeed at their official goals and actually get in the way of catching the bad guys and protecting the public. ‘The excessive collection of data tends to act as a fog through which authorities struggle to find what they are looking for,’ Mr. Clark writes. ‘The more Big Brother watches, the less he seems to see.’” [my emphasis]

Do these disparate but cogent critiques of data for data’s sake refute the notion that quantitative analysis provides the best justification for security initiatives? Restated more bluntly: is quantification even practical? Can security risk be boiled down to useful numbers?

I’m not ready to throw the baby out with the bathwater yet. The above articles helpfully point out that the push towards quantitative analysis is just as vulnerable to information overload as any other discipline. And therein perhaps lies a lesson. Often we come across organizations building security metrics initiatives involving dozens of measurements undergoing complex manipulations. Would such efforts be more successful if they started from a more simple set of practical measurements?

A recent experience perhaps illuminates. We were moderating a discussion of application security metrics with a group of corporate security leaders from across the Eastern US. The discussion was wide-ranging and covered a number of candidate measurements that could be helpful to drive higher security quality into code. The audience seemed overwhelmed at points, unable to see clearly which metrics might be most applicable to their operations, when a sudden insight was made. Two issues continued to be raised throughout the discussion: age of code, and code re-use. These metrics seemed to be predictors of potential security risk in many scenarios (older code has legacy bugs, newer code has unidentified bugs, heavily re-used routines present greater attack surface, and so on). Furthermore, they were not exotic measurements requiring advanced tools or skillsets to produce consistently. Could one build an effective application security program around tracking solely these two metrics?

Some recent research has opened up our thinking on this topic even further (thanks to Gene Kim  of Tripwire for introducing us to this data) . The IT Process Institute (ITPI) has produced a number of research reports and benchmarking studies that illustrate strikingly the “bang for the buck” delivered by excelling at just a handful of IT security practices and controls versus being moderately good (or worse) at many. For example, ITPI’s executive snapshot “Process maturity matters: The key to unlocking the power of IT controls” (July 2007) shows how just 12 of 53 IT controls predict 60% of the performance variation in the 330 companies studied. If you could cut your controls investment by ~75% and still retain 60% of the value, you’d probably think about it, right?

How many other “generally accepted security practices” would benefit from scrutiny like this? Is it time for us to reconsider investing “broad and thin” versus “deep and effective”? Are you picking your battles (and your data) wisely, or are you deluged by information security overload?

Many colleagues have made similar points to me over the years about the temptations of quantification – no formula will ever sufficiently model real-world events. While this is a truism, the above article raises two thoughts in my mind:

1. Garbage in, garbage out. Even the best model produces useless results if fed inadequate data. Data-driven decisions are generally preferable to the opposite, at least in business. So perhaps we are shooting the messenger when the real problem is inability to collect and manage data.

2. All too frequently we forget the point of the whole exercise: decision support. Models are by definition imperfect, but they may only need to provide enough insight to enhance human judgment. We shouldn’t blindly accept what the formula spits out, but neither should we throw the baby out with the bathwater.

I remain a believer in quantitative analysis: even if the final decision becomes a “gut call,” it’s likely inflected with perceived data points and thus more well-reasoned.

“If man is not to do more harm than good in his efforts to improve the social order, he will have to learn that in this, as in all other fields where essential complexity of an organized kind prevails, he cannot acquire the full knowledge which would make mastery of the events possible. He will therefore have to use what knowledge he can achieve, not to shape the results as the craftsman shapes his handiwork, but rather to cultivate a growth by providing the appropriate environment, in the manner in which the gardener does this for his plants.” – Friedrich von Hayek

Managing these infrastructure changes is different from managing development projects, and requires some tweaking to the traditional SDLC.

The requirements and design phases are shorter for infrastructure projects, as changes involve either buying a solution or essentially “flipping a switch” on existing systems.  In a traditional development project, this
phase focuses primarily on features and usability.  Features are still a component of infrastructure projects, but the primary focus shifts to the architecture, and how the changes are going to impact other systems.

The development phase is the most drastically shortened phase of the SDLC, as infrastructure changes are often a matter of plugging something in or making a simple configuration change.  The impact of these changes is
increased because many types of infrastructure changes, such as installing firewalls or appliances and hardening existing network or server components, have to be made directly in production.

Testing occurs immediately following the change.  Since these changes are often made in production, planning and coordination efforts must begin earlier and have greater attention to detail than many development projects
that may go through many iterations of testing.

Implementation may be the same as the development phase in an infrastructure project.  Post-implementation activities are the least different between development and infrastructure, as they involve monitoring, managing issues, and potentially rolling back.

Before undertaking your next infrastructure initiative, consider revisiting and revising the SDLC deliverables and scalability to determine how best to accommodate the differences between development and infrastructure projects.