Health Insurance Portability and Accountability Act
This act is a two part bill. Title I: protects the health care of people who are transitioning between jobs or are laid off. Title II: meant to simplify the healthcare process by shifting to electronic data. Also it protects the privacy of individual patients.
The sort of company affected by this bill is any company or office that deals with healthcare data. That includes but is not limited to doctor’s offices, insurance companies, business associates, and employers.
|Type of Violation||CIVIL Penalty (min)||CIVIL Penalty (max)|
|Individual did not know (and by exercising reasonable diligence would not have known) that he/she violated HIPAA||$100 per violation, with an annual maximum of $25,000 for repeat violations||$50,000 per violation, with an annual maximum of $1.5 million|
|HIPAA violation due to reasonable cause and not due to willful neglect||$1,000 per violation, with an annual maximum of $100,000 for repeat violations||$50,000 per violation, with an annual maximum of $1.5 million|
|HIPAA violation due to willful neglect but violation is corrected within the required time period||$10,000 per violation, with an annual maximum of $250,000 for repeat violations||$50,000 per violation, with an annual maximum of $1.5 million|
|HIPAA violation is due to willful neglect and is not corrected||$50,000 per violation, with an annual maximum of $1,000,000||$50,000 per violation, with an annual maximum of $1.5 million|
|Type of Violation||CRIMINAL Penalty|
|Covered entities and specified individuals who “knowingly” obtain or disclose individually identifiable health information||A fine of up to $50,000Imprisonment up to 1 year|
|Offenses committed under false pretenses||A fine of up to $100,000Imprisonment up to 5 years|
|Offenses committed with the intent to sell, transfer, or use individually identifiable health information for commercial advantage, personal gain or malicious harm||A fine of up to $250,000Imprisonment up to 10 years|
Federal Information Security Management Act of 2002
This act recognized the information security as matters of national security. Thus, it mandates that all federal agencies develop a method of protecting the information systems.
All Federal agencies fall under the range of this bill. Including contractors and those do business with agencies that fall under this Act.
Compliance framework defined by FISMA:
FISMA defines a framework for managing information security that must be followed for all information systems used or operated by a U.S. federal government agency in the executive or legislative branches, or by a contractor or other organization on behalf of a federal agency in those branches. This framework is further defined by the standards and guidelines developed by
Inventory of information systems
FISMA requires that agencies have in place an information systems inventory. According to FISMA, the head of each agency shall develop and maintain an inventory of major information systems (including major national security systems) operated by or under the control of such agency. The identification of information systems in an inventory under this subsection shall include an identification of the interfaces between each such system and all other systems or networks, including those not operated by or under the control of the agency. The first step is to determine what constitutes the “information system” in question. There is not a direct mapping of computers to information system; rather, an information system may be a collection of individual computers put to a common purpose and managed by the same system owner. NIST SP 800-18, Revision 1, Guide for Developing Security Plans for Federal Information Systems provides guidance on determining system boundaries.
Categorize information and information systems according to risk level
All information and information systems should be categorized based on the objectives of providing appropriate levels of information security according to a range of risk levels The first mandatory security standard required by the FISMA legislation, FIPS 199 “Standards for Security Categorization of Federal Information and Information Systems” provides the definitions of security categories. The guidelines are provided by NIST SP 800-60 “Guide for Mapping Types of Information and Information Systems to Security Categories.”
The overall FIPS 199 system categorization is the “high water mark” for the impact rating of any of the criteria for information types resident in a system. For example, if one information type in the system has a rating of “Low” for “confidentiality,” “integrity,” and “availability,” and another type has a rating of “Low” for “confidentiality” and “availability” but a rating of “Moderate” for “integrity,” then the impact level for “integrity” also becomes “Moderate”.
Federal information systems must meet the minimum security requirements.These requirements are defined in the second mandatory security standard required by the FISMA legislation, FIPS 200 “Minimum Security Requirements for Federal Information and Information Systems”. Organizations must meet the minimum security requirements by selecting the appropriate security controls and assurance requirements as described in NIST Special Publication 800-53, “Recommended Security Controls for Federal Information Systems”. The process of selecting the appropriate security controls and assurance requirements for organizational information systems to achieve adequate security is a multifaceted, risk-based activity involving management and operational personnel within the organization. Agencies have flexibility in applying the baseline security controls in accordance with the tailoring guidance provided in Special Publication 800-53. This allows agencies to adjust the security controls to more closely fit their mission requirements and operational environments. The controls selected or planned must be documented in the System Security Plan.
The combination of FIPS 200 and NIST Special Publication 800-53 requires a foundational level of security for all federal information and information systems. The agency’s risk assessment validates the security control set and determines if any additional controls are needed to protect agency operations (including mission, functions, image, or reputation), agency assets, individuals, other organizations, or the Nation. The resulting set of security controls establishes a level of “security due diligence” for the federal agency and its contractors. A risk assessment starts by identifying potential threats and vulnerabilities and mapping implemented controls to individual vulnerabilities. One then determines risk by calculating the likelihood and impact that any given vulnerability could be exploited, taking into account existing controls. The culmination of the risk assessment shows the calculated risk for all vulnerabilities and describes whether the risk should be accepted or mitigated. If mitigated by the implementation of a control, one needs to describe what additional Security Controls will be added to the system.
NIST also initiated the Information Security Automation Program (ISAP) and Security Content Automation Protocol (SCAP) that support and complement the approach for achieving consistent, cost-effective security control assessments.
System security plan
Agencies should develop policy on the system security planning process.NIST SP-800-18 introduces the concept of a System Security Plan.System security plans are living documents that require periodic review, modification, and plans of action and milestones for implementing security controls. Procedures should be in place outlining who reviews the plans, keeps the plan current, and follows up on planned security controls.
The System security plan is the major input to the security certification and accreditation process for the system. During the security certification and accreditation process, the system security plan is analyzed, updated, and accepted. The certification agent confirms that the security controls described in the system security plan are consistent with the FIPS 199 security category determined for the information system, and that the threat and vulnerability identification and initial risk determination are identified and documented in the system security plan, risk assessment, or equivalent document.
Certification and accreditation
Once the system documentation and risk assessment has been completed, the system’s controls must be reviewed and certified to be functioning appropriately. Based on the results of the review, the information system is accredited. The certification and accreditation process is defined in NIST SP 800-37 “Guide for the Security Certification and Accreditation of Federal Information Systems”. Security accreditation is the official management decision given by a senior agency official to authorize operation of an information system and to explicitly accept the risk to agency operations, agency assets, or individuals based on the implementation of an agreed-upon set of security controls. Required by OMB Circular A-130, Appendix III, security accreditation provides a form of quality control and challenges managers and technical staffs at all levels to implement the most effective security controls possible in an information system, given mission requirements, technical constraints, operational constraints, and cost/schedule constraints. By accrediting an information system, an agency official accepts responsibility for the security of the system and is fully accountable for any adverse impacts to the agency if a breach of security occurs. Thus, responsibility and accountability are core principles that characterize security accreditation. It is essential that agency officials have the most complete, accurate, and trustworthy information possible on the security status of their information systems in order to make timely, credible, risk-based decisions on whether to authorize operation of those systems.
The information and supporting evidence needed for security accreditation is developed during a detailed security review of an information system, typically referred to as security certification. Security certification is a comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security accreditation, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. The results of a security certification are used to reassess the risks and update the system security plan, thus providing the factual basis for an authorizing official to render a security accreditation decision.
All accredited systems are required to monitor a selected set of security controls and the system documentation is updated to reflect changes and modifications to the system. Large changes to the security profile of the system should trigger an updated risk assessment, and controls that are significantly modified may need to be re-certified.
Continuous monitoring activities include configuration management and control of information system components, security impact analyses of changes to the system, ongoing assessment of security controls, and status reporting. The organization establishes the selection criteria and subsequently selects a subset of the security controls employed within the information system for assessment. The organization also establishes the schedule for control monitoring to ensure adequate coverage is achieved.
Sarbanes Oxley Act
This act requires companies to maintain financial records for seven years. It was implemented to prevent another Enron scandal.
U.S. public company boards, management and public accounting firms. There are also a number of provisions of the Act that also apply to privately held companies, for example the willful destruction of evidence to impede a Federal investigation.
Payment Card Industry Data Security Standard (PCI-DSS)
A set of 12 regulations designed to reduce fraud and protect customer credit card information.
Companies handling credit card information.
The 12 Regulations: The PCI DSS 12 requirements are as follows:
1. Install and maintain a firewall configuration to protect cardholder data.
2. Do not use vendor-supplied defaults for system passwords and other security parameters.
3. Protect stored cardholder data.
4. Encrypt transmission of cardholder data across open, public networks.
5. Use and regularly update antivirus software.
6. Develop and maintain secure systems and applications.
7. Restrict access to cardholder data by business need-to-know.
8. Assign a unique ID to each person with computer access.
9. Restrict physical access to cardholder data.
10. Track and monitor all access to network resources and cardholder data.
11. Regularly test security systems and processes.
12. Maintain a policy that addresses information
The PCI SSC has released several supplemental pieces of information to clarify various requirements. These documents include the following:
- Information Supplement: Requirement 11.3 Penetration Testing
- Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified
- Navigating the PCI DSS – Understanding the Intent of the Requirements
- Information Supplement: PCI DSS Wireless Guidelines
|PCI NONCOMPLIANT CONSEQUENCES|
Gramm Leach Bliley Act
This act allowed insurance companies, commercial banks, and investment banks to be within the same company. As for security, it mandates that companies secure the private information of clients and customers.
The Safeguards Rule requires financial institutions to develop a written information security plan that describes how the company is prepared for, and plans to continue to protect clients’ nonpublic personal information. (The Safeguards Rule applies to information of any consumers past or present of the financial institution’s products or services.) This plan must include:
- Denoting at least one employee to manage the safeguards,
- Constructing a thorough risk analysis on each department handling the nonpublic information,
- Develop, monitor, and test a program to secure the information, and
- Change the safeguards as needed with the changes in how information is collected, stored, and used.
The Safeguards Rule forces financial institutions to take a closer look at how they manage private data and to do a risk analysis on their current processes. No process is perfect, so this has meant that every financial institution has had to make some effort to comply with the GLB.
This act defines “financial institutions” as: “…companies that offer financial products or services to individuals, like loans, financial or investment advice, or insurance.”