Compliance

Information Security Compliance – What is it and how does it affect my organization?

Compliance, in general, continues to be of heavy concern to most information technology organizations. The regulations tend to be “under-understood” and understanding their impact to your organization (both from a time, cost and personnel perspective) can be challenging, particularly as they apply to organizations migrating to the cloud. Today, we are going to take a look at some of the most common compliance regulations for information technology, while in a future article we will explore some of the protections and options we have when moving to the cloud.

Sarbanes-Oxley Act (SOX) – 2002

This legislation was enacted in 2002 as a direct response to the abuses that came from the Enron and WorldCom financial collapses. It was designed so that shareholders and the general public would be protected from fraudulent financial practices (“cooking the books”) and accounting errors in the enterprise. In addition to setting rules as to what type of business transactions to store and how long to store them, it also requires that executive board members “sign off” on anything that is reported to the shareholders and the stock market. These individuals can then be held responsible if it is found that the accounting practices are suspect and the financial gains reported are fraudulent.

In short, Sarbanes-Oxley requires:

  • All business records (including electronic messages and other records) must be saved for “not less than five years”
  • There are three rules set forth that govern the management of electronic records:
    1. Deals with the destruction, alteration or falsification of records and all resulting penalties.
    2. Defines the retention periods for record storage (generally recommending that best practices are followed like public accountants).
    3. Defines the type of records that need to be stored (communications of all kind including electronic and other business records).

Dodd-Frank Act – 2010

These sets of regulations do not apply to all IT organizations. It was enacted in response to the “Great Recession” in the early 2000s, designed to address the lack of regulation and over reliance on “large” banks (this is where the phrase “too big to fail” came into being). This set of regulations actually created the Financial Stability Oversight Council (FSOC) to oversee and react to persistent issues that occur in the financial industry to help prevent another recession.

Banks must maintain what are called “funeral” plans in the event that a company goes under; it provides guidance for a swift and orderly shutdown of operations. Additionally, the Consumer Financial Protection Bureau (CFPB) was created to help protect consumers from unregulated banking. This new bureau facilitated the consolidation of a number of older bureaus including HUD, the NCUA and the FTC.

Information Technology requirements are defined within this act more loosely and generally repeat the guidance of SOX in terms of the type of business records that must be kept as well as how long they are stored.

Health Insurance Portability and Accountability Act – 1996

More commonly known as HIPAA, this act’s primary function was to simplify the administration and storage of medical records of all kinds. This act mandated the standardization of electronic health record systems and includes an array of security mechanisms that are designed to protect individual data privacy and patient confidentiality.

Among many of the administrative requirements (yearly notifications provided to patients, new patient signature acknowledgement and perpetual storage of such, etc.), there are a number of complex regulations that include physical access to systems and data centers where these kinds of records exist. Audits of personnel accessing records and a comprehensive audit trail of accessibility and exchanges made with any other organization. This set of regulations is one of the more onerous for IT organizations to support because of the physical security and audit trails that must be documented. In particular, it has been one of the more challenging regulations to meet in an “all cloud, all the time” model.

Federal Information Security Management Act – 2002

FISMA is a set of regulations that requires federal agencies (and those approved vendors or contractors who do business with those federal agencies) to conduct annual reviews of all their information security processes. These processes include (but are not limited to) physical building access, datacenter access, physical server access, physical storage access, user access to operating systems, user access to applications, user access to databases, firewall access, intrusion detection systems and more. These reports are often published with various “threat levels” depending on their contents. The “security profile” of an organization can preclude it from doing business with certain federal agencies as a result until deficiencies are mitigated satisfactorily.

Again, this is not a set of regulations that affects all IT organizations, but if you want to deal with the government or any large financial institution, expect them to ask for your last security profile summary.

Payment Card Industry Data Security Standard

This set of policies and procedures (often called “PCI Compliance” or PCI DSS) is the only one not issued by the federal government. These policies and procedures were developed by the major credit companies (Mastercard, Visa, American Express and Discover) intended to optimize the security around credit, debit and cash card transactions. Although designed ostensibly to protect cardholders against misuse of their private information, it was also primarily designed to limit the liability of these organizations to fraudulent transactions.

By defining six major objectives (most of them affecting IT organizations from either an equipment, personnel or audit perspective), PCI compliance standardizes these financial transactions:

  1. A secure network must be maintained on which financial transactions can be conducted.
    • This includes the network on both ends of the transaction and includes security (firewalls), access, encryption and audit controls.
  2. Cardholder information must be protected wherever it is stored (whether that be temporarily or permanently stored, via encryption and access/audit controls). Whenever any private data must be transmitted over public networks, it MUST be encrypted.
    • Cardholder information is defined as dates of birth, mother’s maiden name, phone numbers, mailing address, social security numbers, driver’s license information
  3. All systems should be protected by anti-virus, anti-spyware, anti-malware and other solutions in that category. Additionally, all operating systems, applications and the aforementioned protections should be kept up to data so as to keep them free of known bugs or vulnerabilities which could otherwise be exploited to gain access to said data.
  4. Access to all system information and operations is restricted and controlled. Anyone working in any center that requires any access to any personally identifying data, either through working with a consumer or as part of their daily activities, has to be assigned a unique identification name or number. Physical copies of private data should be immediately destroyed via shredder or any other method appropriate to medium.
  5. All networks must be constantly monitored and tested so that all security processes are functioning as designed and are up-to-date.
  6. A formal information security policy must be defined, maintained, followed, tested and be audited by everyone at all times. Enforcement comes in the form of random audits that can be performed to check any of these at any time with penalties being levied if compliance is found to be lacking.

Although this is one of the most common compliance discussions in any IT organization, it is NOT a federal law. Some U.S. states refer to the PCI DSS or have made equivalent provisions as part of doing business in that state.

What Does All This Mean?

If you work in IT, you probably know which of these apply to you and how. However, as organization move to a hybrid cloud environment, some of these requirements have become a little murky. Additionally, those looking to make the full cloud transition may be worried that they will not be able to meet some of these regulations if they do. In our next article, we will take a look at how Amazon Web Services is helping facilitate these transitions and some of the tools and processes that they provide protection for organizations affected by these situations.

Terrence T. Cox

A veteran of twenty years in Information Technology in a variety of roles. He has worked in development, security and infrastructure well before they merged into what we now call DevOps. He provides training in Linux, VMWare, DevOps (Ansible, Jenkins, etc) as well as containers and AWS topics.

2 thoughts on “Information Security Compliance – What is it and how does it affect my organization?

  1. Excellent article! I worked in InfoSec for nearly 10 years before moving to a different field of work about 9 or 10 years ago. With my InfoSec experience (even though a bit outdated) and my 23 years of Linux experience, I’m hoping to get back in field.

    1. I am glad you found it informative. I think with 20+ years of Linux and some InfoSec experience, you will be fine. I might suggest hopping on our site though and reviewing for one of the system administration certifications. It can help ease your transition to have an up to date certification on your resume. Let me know if you have any questions!

Leave a Reply

Your email address will not be published. Required fields are marked *