Multiple governmental and industry regulations have
direct consequences for messaging platforms within organizations.
Security systems within an organization can be based on proprietary
standards; however, as organizations have the need to securely exchange information
with other entities, the need to have information systems built on
standards becomes crucial. Security standards enable organizations to
not only store and transmit information within the enterprise in a
secure manner, but also securely exchange information with other
entities.
A universal
security standard requires the creation of common criteria for a secured
environment, the adoption of the standard by an accepted standards
organization, the acceptance of the standard by organizations, and the
implementation of the standard in enterprise transactions.
There are many
initiatives to create security standards. Some of these standards
include ISO/IEC 17799, HIPAA, and provisions of the Gramm-Leach-Bliley
Act.
Understanding the ISO/IEC 17799 Security Standard
ISO/IEC 17799
is “a comprehensive set of controls comprising best practices in
information security.” It is an internationally recognized generic
information security standard. Its predecessor, titled BS7799-1, has
existed in various forms for a number of years, although the standard
only really gained widespread recognition following publication by ISO
(the International Organization for Standardization) in December of
2000. Formal certification and accreditation were also introduced around
the same time.
ISO/IEC 17799 is organized into 10 major sections, each covering a different topic or area:
Business Continuity Planning—
The objective of this section is to counteract interruptions to
business activities and to critical business processes from the effects
of major failures or disasters.
System Access Control—
The objectives of this section are a) to control access to information,
b) to prevent unauthorized access to information systems, c) to ensure
the protection of networked services, d) to prevent unauthorized
computer access, e) to detect unauthorized activities, and f) to ensure
information security when using mobile computing and telenetworking
facilities.
System Development and Maintenance—
The objectives of this section are a) to ensure security is built in to
operational systems; b) to prevent loss, modification, or misuse of
user data in application systems; c) to protect the confidentiality,
authenticity, and integrity of information; d) to ensure information
technology (IT) projects and support activities are conducted in a
secure manner; and e) to maintain the security of application system
software and data.
Physical and Environmental Security—
The objectives of this section are a) to prevent unauthorized access,
damage, and interference to business premises and information; b) to
prevent loss, damage, or compromise of assets and interruption to
business activities; and c) to prevent compromise or theft of
information and information-processing facilities.
Compliance—
The objectives of this section are a) to avoid breaches of any criminal
or civil law, statutory, regulatory, or contractual obligations, and of
any security requirements; b) to ensure compliance of systems with
organizational security policies and standards; and c) to maximize the
effectiveness of and to minimize interference to/from the system audit
process.
Personnel Security—
The objectives of this section are a) to reduce risks of human error,
theft, fraud, or misuse of facilities; b) to ensure that users are aware
of information security threats and concerns, and are equipped to
support the corporate security policy in the course of their normal
work; and c) to minimize the damage from security incidents and
malfunctions and learn from such incidents.
Security Organization—
The objectives of this section are a) to manage information security
within the company; b) to maintain the security of organizational
information-processing facilities and information assets accessed by
third parties; and c) to maintain the security of information when the
responsibility for information processing has been outsourced to another
organization.
Computer and Operations Management—
The objectives of this section are a) to ensure the correct and secure
operation of information-processing facilities; b) to minimize the risk
of systems failures; c) to protect the integrity of software and
information; d) to maintain the integrity and availability of
information processing and communication; e) to ensure the safeguarding
of information in networks and the protection of the supporting
infrastructure; f) to prevent damage to assets and interruptions to
business activities; and g) to prevent loss, modification, or misuse of
information exchanged between organizations.
Asset Classification and Control—
The objectives of this section are a) to maintain appropriate
protection of corporate assets and b) to ensure that information assets
receive an appropriate level of protection.
Security Policy— The objectives of this section are a) to provide management direction and b) to provide support for information security.
The first step toward
ISO/IEC 17799 certification is to comply with the standard itself. This
is a good security practice in its own right, but it is also the
longer-term status adopted by a number of organizations that require the
assurance of an external measure, yet do not want to proceed with an
external or formal process immediately.
In either case, the
method and rigor enforced by the standard can be put to good use in
terms of better management of risk. It is also being used in some
sectors as a market differentiator, as organizations begin to quote
their ISO/IEC 17799 status within their individual markets and to
potential customers.
Understanding the Health Insurance Portability and Accountability Act of 1996 (HIPAA)
HIPAA
is the acronym for the Health Insurance Portability and Accountability
Act of 1996. When HIPAA was enacted in 1996, it had two major purposes.
One was to allow employees to change jobs while maintaining health-care
coverage. The second was to ensure that health-care providers maintain
the confidentiality of patient information.
With respect to the
portability of insurance, a few decades ago, people stayed in one or two
jobs throughout a whole career. In those days, people had no need for
HIPAA because their jobs were stable and their employee benefits were
retained by a single or limited number of providers. However, today in a
time when jobs and even careers are constantly changing, HIPAA provides
the continuity of health insurance even through job changes and
unemployment.
The original Act was
unclear and led to much confusion in the health-care industry
specifically how to comply with HIPAA, so several revisions to HIPAA
were enacted along with clarification documents.
Early Provisions of HIPAA
The initial actions of
HIPAA were clarified and implemented related to consumer rights to
health-care coverage. HIPAA increased an individual’s ability to get
health coverage for themselves and their dependents. It also lowered an
employee’s chance of losing existing health-care coverage, through a job
change or unemployment. HIPAA also helped employees buy health
insurance coverage on their own if they lost coverage under an
employer’s group health plan and have no other health coverage
available.
Among its specific
protections, HIPAA limited the use of preexisting condition exclusions
and prohibited group health plans from discriminating by denying
coverage or charging employees extra for coverage based on their
individual or family member’s past or present poor health. HIPAA
provided guarantees to employers or individuals who purchased health
insurance so they could renew the coverage regardless of any health
conditions of individuals covered under the insurance policy.
HIPAA, however, does not
require employers to offer or pay for health coverage to their
employees nor does it guarantee health coverage for all workers. HIPAA
also does not control the amount that an insurer can charge for coverage
nor require group health plans to offer specific benefits. Other
provisions do not require an employer or insurer to offer the same level
of health-care coverage as a previous provider nor eliminate all use of
preexisting condition exclusions.
Later Provisions of HIPAA
After the early
provisions for HIPAA relative to consumer rights to health care were
defined and implemented, the focus of HIPAA turned to the accountability
aspects of the Act. The focus areas were standards for transactions and
code sets, privacy of patient information, and security of information.
HIPAA Transaction and Code Sets
The
rules for Transactions and Code Sets (TCS) were published on August 17,
2000, and with modifications published in May 2002. The compliance date
was October 16, 2002. On December 27, 2001, President Bush signed
HR3323, which provided for a delay in the implementation of the TCS
rules of HIPAA. This extended the compliance due date to October 16,
2003, if a compliance extension was requested.
Further
modifications to the final rule were published in February 2003. This
rule finalized provisions applicable to electronic data transaction
standards from two related proposed rules published in the May 31, 2002,
Federal Register. It adopted modifications to implement specifications
for health-care entities and for several electronic transaction
standards that were omitted from the May 31, 2002, proposed rules.
The purpose of
those regulations was to standardize the electronic exchange of
information (transactions) between trading partners. These transactions
were mandated to be in the ANSI ASC X12 version 4010 format. The covered
transactions include the following:
270 = Eligibility Inquiry
271 = Inquiry and Response
276 = Claim Status Inquiry
277 = Claim Status Inquiry and Response
278 = Authorization Request and Authorization Response
820 = Health Insurance Premium Payment
834 = Beneficiary Enrollment
835 = Remittance/Payment
837 = Claim or Encounter
The HIPAA
Code Set Regulations establish a uniform standard of data elements used
to document reasons why patients are seen and the procedures performed
during health-care encounters. HIPAA specified code sets to be used as
follows:
HIPAA specified administrative codes set for use in conjunction with certain transactions and HIPAA eliminated local codes.
HIPAA Privacy
As of April 14, 2003,
health-care providers and health plans were required to be in compliance
with the HIPAA Privacy Regulation. Both the 1996 Congress and the two
subsequent administrations agreed that a privacy law was needed to
ensure that sensitive personal health information can be shared for core
health activities, with safeguards in place to limit the inappropriate
use and sharing of patient data. The HIPAA privacy rule took critical
steps in that direction to require that privacy and security be built in
to the policies and practices of health-care providers, plans, and
others involved in health care.
The U.S. Department of
Health and Human Services (DHHS) had addressed the concerns with new
privacy standards that set a national minimum of basic protections.
Congress recognized that advances in electronic technology could erode
the privacy of health information. Consequently, Congress incorporated
into HIPAA provisions that mandate an adoption of federal privacy
protections for certain individually identifiable health information.
The HIPAA Privacy Rule
(Standards for Privacy of Individually Identifiable Health Information)
provided the first national standards for protecting the privacy of
health information. The Privacy Rule regulates how certain entities,
called covered entities, use and disclose certain individually
identifiable health information, called protected health information
(PHI). PHI is individually identifiable health information that is
transmitted or maintained in any form or medium (for example,
electronic, paper, oral), but excludes certain educational records and
employment records. Among other provisions, the Privacy Rule provides
for the following:
Gives patients more control over their health information.
Sets boundaries on the use and release of health records.
Establishes
appropriate safeguards that the majority of health-care providers and
others must achieve to protect the privacy of health information.
Holds violators accountable with civil and criminal penalties that can be imposed if they violate patients’ privacy rights.
Strikes a balance when public health responsibilities support disclosure of certain forms of data.
Enables patients to make informed choices based on how individual health information can be used.
Enables patients to find out how their information can be used and what disclosures of their information have been made.
Generally limits release of information to the minimum reasonably needed for the purpose of the disclosure.
Generally gives patients the right to obtain a copy of their own health records and request corrections.
Empowers individuals to control certain uses and disclosures of their health information.
The deadline to comply
with the Privacy Rule was April 14, 2003, for the majority of the three
types of covered entities specified by the rule [45 CFR § 160.102]. The
covered entities are the following:
At DHHS, the
Office for Civil Rights (OCR) has oversight and enforcement
responsibilities for the Privacy Rule. Comprehensive guidance and OCR
answers to hundreds of questions are available at http://www.hhs.gov/ocr/hipaa.
DHHS recognized the
importance of sharing PHI to accomplish essential public health
objectives and to meet certain other societal needs (for example,
administration of justice and law enforcement). Therefore, the Privacy
Rule expressly permits PHI to be shared for specified public health
purposes. For example, covered entities can disclose PHI, without
individual authorization, to a public health authority legally
authorized to collect or receive the information for the purpose of
preventing or controlling disease, injury, or disability [45 CFR §
164.512(b)]. Further, the Privacy Rule permits covered entities to make
disclosures that are required by other laws, including laws that require
disclosures for public health purposes. Thus, the Privacy Rule provides
for the continued functioning of the U.S public health system.
HIPAA Security
The American public
began to register serious concerns about the privacy and security of
health records in the early 1990s. Breaches of health privacy, such as
press disclosures of individuals’ HIV status, network hacking incidents,
and misdirected patient emails fueled this concern. At the same time,
health-care industry and federal agencies working toward HIPAA
“administrative simplification” and increased automation of health
information realized that their initiatives would be unsuccessful
without incorporating more effective information-security measures. When
HIPAA was passed in 1996, it included a mandate for standards that
would ensure the security and integrity of health information that is
maintained or transmitted electronically. A Notice of Proposed
Rulemaking (NPRM) on security was published by DHHS on August 12, 1998.
The Security Rule focuses
on both external and internal security threats and vulnerabilities.
Threats from “outsiders” include breaking through network firewalls,
email attacks through interception or viruses, compromise of passwords,
posing as organization “insiders,” computer viruses, and modem number
prefix scanning. These activities can result in denial of service, such
as the disruption of information flow by “crashing” or overloading
critical computer servers. The outsider might steal and misuse
proprietary information, including individual health information.
Attacks can also affect the integrity of information, by corrupting data
that is being transmitted.
Internal threats are of
equal concern, and are far more likely to occur according to many
security experts. Organizations must protect against careless staff or
others who are unaware of security issues, and curious or malicious
insiders who deliberately take advantage of system vulnerabilities to
access and misuse personal health information.
The
rule is intended to set a minimum level or “floor” of security.
Organizations can choose to implement safeguards that exceed the HIPAA
standards—and, in fact, might find that their business strategies
require stronger protections. Covered entities are required to
Assess potential risks and vulnerabilities.
Protect against threats to information security or integrity, and against unauthorized use or disclosure.
Implement and maintain security measures that are appropriate to their needs, capabilities, and circumstances.
Ensure compliance with these safeguards by all staff.
Central to
HIPAA security is the tenet that information security must be
comprehensive. No single policy, practice, or tool can ensure effective
overall security. Cultural and organizational issues must be addressed,
as well as technological and physical concerns. The safeguards that
comprise HIPAA-mandated security focus on protecting “data integrity,
confidentiality, and availability” of individually identifiable health
information through the following:
Administrative procedures— Documented, formal practices to manage the selection and execution of security measures.
Physical safeguards— Protection of computer systems and related buildings and equipment from hazards and intrusion.
Technical security services— Processes that protect and monitor information access.
Technical security mechanisms— Processes that prevent unauthorized access to data that is transmitted over a network.
These
regulations established standards for all health plans, clearinghouses,
and storage of health-care information to ensure the integrity,
confidentiality, and availability of electronic protected health
information. Proposed rules were published on August 12, 1998. Final
rules were published on February 20, 2003, and compliance had to occur
by April 20, 2005.
HIPAA Implications for Exchange Server 2010 Environments
The most
important implication that HIPAA requirements have on an Exchange Server
2010 environment is regarding data security. Organizations subject to
HIPAA regulations must demonstrate that they are taking significant
precautions against confidential patient data being compromised, lost,
or stolen. This includes the transmission of this type of data across a
medium such as email.
Exchange
Server 2010 can help organizations become HIPAA compliant through the
use of enterprise policies that define when email data is encrypted,
thus securing the transmission of protected data.
Understanding the Gramm-Leach-Bliley Act
Information that
many would consider private—including bank balances and account
numbers—is regularly bought and sold by banks, credit card companies,
and other financial institutions. The Gramm-Leach-Bliley Act (GLBA),
which is also known as the Financial Services Modernization Act of 1999,
provides limited privacy protections against the sale of the private
financial information of consumers. In addition, the GLBA codifies
protections against pretexting, the practice of obtaining personal
information through false pretenses.
The GLBA primarily
sought to “modernize” financial services—that is, end regulations that
prevented the merger of banks, stock brokerage companies, and insurance
companies. The removal of these regulations, however, raised significant
risks that these new financial institutions would have access to an
incredible amount of personal information, with no restrictions upon its
use. Prior to GLBA, the insurance company that maintained health
records was distinct from the bank that held the mortgage on a
consumer’s house or the stockbroker who traded a person’s stock. After
these companies merged, however, they had the ability to consolidate,
analyze, and sell the personal details of their customers’ lives.
Because of these risks, the GLBA included three simple requirements to
protect the personal data of individuals: First, banks, brokerage
companies, and insurance companies must securely store personal
financial information. Second, they must advise consumers of their
policies on sharing of personal financial information. Third, they must
give consumers the option to opt out of some sharing of personal
financial information.
Privacy Protections Under the GLBA
The GLBA’s privacy
protections only regulate financial institutions—businesses that are
engaged in banking, insuring, stocks and bonds, financial advice, and
investing.
First, these financial
institutions, regardless of whether they want to disclose the personal
information of individuals, must develop precautions to ensure the
security and confidentiality of customer records and information, to
protect against any anticipated threats or hazards to the security or
integrity of such records, and to protect against unauthorized access to
or use of such records or information that could result in substantial
harm or inconvenience to any customer.
Second, financial
institutions are required to provide consumers with a notice of their
information-sharing policies when the individual first becomes a
customer, and annually thereafter. That notice must inform the consumer
of the financial institutions’ policies on disclosing nonpublic personal
information (NPI) to affiliates and nonaffiliated third parties,
disclosing NPI after the customer relationship is terminated, and
protecting NPI. “Nonpublic personal information” means all information
on applications to obtain financial services (credit card or loan
applications), account histories (bank or credit card), and the fact
that an individual is or was a customer. This interpretation of NPI
makes names, addresses, telephone numbers, Social Security numbers, and
other data subject to the GLBA’s data-sharing restrictions.
Third, the GLBA gives
consumers the right to opt out from a limited amount of NPI sharing.
Specifically, a consumer can direct the financial institution to not
share information with unaffiliated companies.
Consumers have no
right under the GLBA to stop sharing of NPI among affiliates. An
affiliate is any company that controls, is controlled by, or is under
common control with another company. The individual consumer has
absolutely no control over this kind of “corporate family” trading of
personal information.
Several exemptions under
the GLBA can permit information sharing over the consumer’s objection.
For instance, if a financial institution wants to engage the services of
a separate company, they can transfer personal information to that
company by arguing that the information is necessary to the services
that the company will perform. A financial institution can transfer
information to a marketing or sales company to sell new products
(different stocks) or jointly offered products (co-sponsored credit
cards). After this unaffiliated third party has an individual’s personal
information, they can share it with their own “corporate family.”
However, they themselves cannot likewise transfer the information to
further companies through this exemption.
In addition,
financial institutions can disclose information to credit reporting
agencies and to financial regulatory agencies, as part of the sale of a
business, to comply with any other laws or regulations, or as necessary
for a transaction requested by the consumer.
Fourth, financial
institutions are prohibited from disclosing, other than to a consumer
reporting agency, access codes or account numbers to any nonaffiliated
third party for use in telemarketing, direct mail marketing, or other
marketing through electronic mail. Thus, even if a consumer fails to
“opt out” of a financial institution’s transfers, the credit card
numbers, PINs, or other access codes cannot be sold, as they had been in
some previous cases.
Fifth, certain
types of “pretexting” were prohibited by the GLBA. Pretexting is the
practice of collecting personal information under false pretenses.
Pretexters pose as authority figures (law enforcement agents, social
workers, potential employers, and so on) and manufacture seductive
stories (that the victim is about to receive a sweepstakes award or
insurance payment) to elicit personal information about the victim. The
GLBA prohibits the use of false, fictitious, or fraudulent statements or
documents to get customer information from a financial institution or
directly from a customer of a financial institution; the use of forged,
counterfeit, lost, or stolen documents to get customer information from a
financial institution or directly from a customer of a financial
institution; and asking another person to get someone else’s customer
information using false, fictitious, or fraudulent documents or forged,
counterfeit, lost, or stolen documents.
GLBA’s Implications for Exchange Server 2010 Environments
GLBA strictly limits
the disclosure of personal information outside of a company or its
immediate corporate affiliates. Exchange Server policies in regard to
email can be set up to monitor communications for specific types of personal data or key phrases, restricting where it can be sent.
Understanding Sarbanes-Oxley
Sarbanes-Oxley (often
nicknamed SOX), named for the two congressmen who sponsored it, on the
surface doesn’t have much to do with IT security. The law was passed to
restore the public’s confidence in corporate governance by making chief
executives of publicly traded companies personally validate financial
statements and other information.
President Bush signed the
law on July 30, 2002. Initially, companies had to be in compliance by
the fall of 2003, but extensions were granted. Large corporations were
given until June 15, 2004, to meet the requirements of Sarbanes-Oxley.
Smaller companies had to comply by April 15, 2005.
Congress passed the
law in quick response to accounting scandals surrounding Enron,
Worldcom, and other companies. Sarbanes-Oxley deals with many corporate
governance issues, including executive compensation and the use of
independent directors. Section 404 mandates that each annual report
contain an internal control report, which must state the responsibility
of management for establishing and maintaining an adequate internal
control structure and procedures for financial reporting. It must also
contain an assessment, at the end of the issuer’s most recent fiscal
year, of the effectiveness of the internal control structure and
procedures for financial reporting. The auditor must attest to, and
report on, the assessment made by the management of the issuer. It’s
hard to sign off on the validity of data if the systems maintaining it
aren’t secure. It is the internal IT systems that keep the records of
the organizations. If the IT systems aren’t secure, internal controls
can also be questioned.
Sarbanes-Oxley
doesn’t mandate specific internal controls such as strong authentication
or the use of encryption. However, if someone can easily get into an
organization’s IT system, the security hole can establish a condition of
noncompliance. Sarbanes-Oxley creates a link between upper management
and the security operation staff on what is needed to ensure that proper
and auditable security measures are in place. The executives who have
to sign off on the internal controls have to ensure the security in
their organizations is well established; otherwise, the executive could
face criminal penalties if a breach is detected.
Sarbanes-Oxley’s Implications for Exchange Server 2010 Environments
SOX controls stipulate
that data must be secured and audited to make sure that a third party
cannot manipulate financial data. Exchange Server 2010 includes
administrative controls that protect an organization from security
breaches. In addition, SOX controls look to an organization to establish
specific guidelines in regard to data retention and data transfer
controls.
