“Rules are not
necessarily sacred, principles are.” – Franklin D. Roosevelt.
Five years
ago, you could list your applicable regulatory bodies on a single sheet of
paper. Today, your hand would tire before you would finish. Regulations have permeated every major
industry and have driven profound changes in how businesses operate. The trick
is complying with all the various bodies without draining your capacity and
simultaneously maintaining your business when new sets of rules appear.
Outside of the
financial category, regulations typically fall into what can be described as
categories; Procedural, Data Driven, and Directive. With hundreds to choose from, it’s simpler if
we use three common regulations as a point of reference; HIPPA, SAS70 and PCI.
Each is different from the other, and was
formed for different reasons by different governing bodies. HIPPA (Health
Insurance Portability and Accountability Act), was created by the US government
specifically for insurance and health providers. By extension, all peripheral
business that services those industries must comply, at least in part, with
HIPPA provisions. The PCI (Payment Card Industry) was started by the largest
credit issuers; American Express, MasterCard, JCB, and Discover. The standard
differs from HIPPA in that it dictates precise measures for security and is
necessary to process credit card payments in volume within the U.S.
The SAS (Statement on Auditing Standard, “.70” specifically) is an auditing
standard developed by the American Institute of Certified Public Accounts
(AICPA). It provides a standard mechanism for auditing controls, practices, and
reporting and requires a third-party auditor to measure compliance.
Each of the
regulation/audit bodies mandates different conditions and documentation
requirements. In the case of HIPPA, specific data handling elements are
defined. With SAS70, your procedural documentation is audited, as well as your
level of compliance with them. PCI
specifically spells out process, data, and technology requirements dictating
practice and infrastructure. The
differences may seem minor, but they become profound when trying to
concurrently comply with each.
Most of the
major regulations have been around for some time, adjusting slightly each year.
What has changed in the last five years has been the effect on your business.
Your business is now subject to the regulatory demands of your business
partners and vendors. Several years ago customers began asking for compliance, their
needs progressed to requiring validated certification. It’s now common to have their
independent auditors validate the certification outside of your process.
Data Management
Regulations
like HIPPA that attach directly to data as opposed to process, best illustrate how
IT is effected by regulations. Data must be managed not only in transit, or
in-flight, but also when at-rest. That notion alone sets the stage for the
tools and platforms necessary for the organization. Every bit stored or moved
is tagged with access identification, credentials, and authenticity. The data
package itself must be encrypted from origination to termination. Life of the
data is measured in addition to its content.
For example, a
policy may require that all data moving through the internal organization have “federated”
authentication to track the originator of the data and be encrypted at the
ingress through to the target, where it must remain encrypted while stored for
the life of its existence. The policies will also dictate how long data may
live “at-rest” before it is destroyed. The depth of data control is leaps ahead
in complexity from how IT shops used to manage information.
Not only are
the tools important to accomplish this, but so is the organizational structure.
The business itself must have a separate, board-mandated group to define,
audit, and validate all the practices identified in the overall governance
policy. Even the IT function for security must be separated for audit and
investigation purposes. Ideally it’s organized as a small group that has
administrative permissions and monitoring tools for e-mail, documents, data,
access, and configuration control.
Your security
group or “internal security office” should
be tasked with the development and maintenance of the overall governance policy
for the business as it effects all aspects of privacy and procedure. For example, the ISO group may interface with
human resources, finance, and legal beyond the expected IT relationship. In
doing so the central policy acts as a unifying procedure by which the company
is certified on an ongoing basis, either quarterly or annually.
In many
instances, customers will want reports on the success of audits, and in the
event there are deviations (e.g., policy gaps, non conformance, etc.) they may apply
penalties or withhold revenue until the business demonstrates compliance. As a
result, you’ll need multiple audit bodies that are employed year round to
manage the process and generate the findings.
Infrastructure
From a
practical perspective, retrofitting your IT infrastructure is the first and
perhaps simplest step in seeking compliance. Devices that support minimum
encryption, identification, and forensic levels are ideal.
That includes
routers, servers, storage arrays, and even desktop and laptop computers. Enterprise
software must be audit-able and insensitive to underlying encryption and identification
models. By extension, open source and many smaller systems aren’t acceptable
for use by businesses seeking compliance to most of the regulatory directives.
CIO and CSO
The CIO plays
a significant part is assessing and driving standards throughout the business.
However, where the CIO is often at the lead of transforming initiatives, the
CSO is preferred for security compliance. The CSO will sometimes report into
the information office for practical management purposes, but by definition
must have direct and unfettered access to the board or senior executives in the
company. This is necessary as the CSO. Like the CFO, they represent a facet of
the business that affects investors, consumers, and governmental authorities.
All of this
structure and formality does not come easily to fast moving businesses. Often,
the desire to seek compliance starts as an external demand. A common mistake is
to view security as a checklist item, or worse, an administrative group to
interface with the customer’s staff. If security isn’t considered an overarching
mandate for the business, compliance will be difficult and unnecessarily
expensive.
Managing the landscape
To address the
disparity and volume of requests, one effective solution is to adopt the “ISO/IEC
27000 series” as a common form of internal process/security governance, and map
it to the requirements set by the various industry regulations.
The ISO
standard acts as an overall policy and governance for all IT and Security
related functions. Because of the completeness of the standard, orienting your
IT organization’s procedures, security, and practices around the structure will
provide you with a reasonable assurance that you’ll be prepared for whatever
regulatory body presents itself over time. As industry specific regulations
come along, your security office can map your policy elements to specific areas
of that standard. This way, you setup
your procedures once, and manage the gaps on a case by case basis.
The security group typically approaches regulatory compliance as an
ongoing effort, but one that is best managed by internal staff, with an
independent auditors’ validation. Because of the far reaching role of security
governance, diplomacy is a necessary virtue of the security office. Acting as a
“corporate policeman” will build
resentment that’s counterproductive for your business.
The CSO and CIO create co-owned groups to manage collective efforts.
Allowing the functional groups to take credit and participate in compliance and
verification engenders cooperation. In the end, the purpose of security is to
improve and standardize the process of a business. Having your functional groups
own the challenge of compliance benefits the business overall.
Staff and Compliance
One challenging task of disseminating your policy is assuring that
your employees understand and follow the instructions. When that number is in
the thousands, it’s a challenge to insure that everybody with sensitive data,
or access to systems, has the proper training.
One effective way to educate your staff is through the use of self-based
training (SBT) modules delivered electronically. By using SBT’s, the security
office is able to demonstrate training across the organization in a measurable
manner. Because security groups generally acts as an escalation point for any
security events that may occur, the training includes escalation procedures in
the occurrence of a breach or non conforming event.
Cost Impact
As a general
rule, security will cost approx 2-3 percent of the overall IT budget for
ongoing support, audit, and compliance work. And that’s beyond any capital
requirements necessary to bring your infrastructure into compliance.
The standard
Return-on-Investment model is a difficult tool to apply to security compliance,
because it implies a predictable reward for capital investment. Commonly, security
investments are justified through risk models reflecting the cost of non
compliance or breaches.
Regulatory
compliance is a reality that all businesses must to manage. The dramatic
increase in data driven capabilities and the efficiencies created by it,
demands new ways of protecting your customers and your business. If you approach security as an overall
governance of your business, you’ll be able to manage compliance cost
effectively, and with the least amount of disruption to your business.
