A High Level Overview of IT and Security Industry Standards

A High Level Overview of IT and Security Industry Standards

This may sound like a boring article to many, but it is a basic overview of some very important information that is crucial to include in the repertoire of knowledge for all IT and security professionals.

In this article, we will be going over the high points for the following industry standards: PCI DSS, ISO 27001/27002, HIPAA, and the NIST/DoD frameworks, and adding some comments along the way on the relationships and effects that these policies and frameworks have on network architecture, as well as what possible implications they could have on architectural solutions. Most of the architectural solutions provided come from an Amazon Web Services perspective, but the same basic principles apply, regardless of which cloud service provider (CSP) you use, or even if your infrastructure is hosted on-premises.


PCI DSS is a set of standards with the intention of protecting credit card data and the personal information associated with it, and it basically applies to any company that processes credit cards. Listed below is the official “Overview of PCI Requirements.” You can read more in-depth on PCI DSS by visiting https://www.pcisecuritystandards.org/.

PCI security standards are technical and operational requirements set by the PCI Security Standards Council (PCI SSC) to protect cardholder data. The standards apply to all entities that store, process or transmit cardholder data – with guidance for software developers and manufacturers of applications and devices used in those transactions. The Council is responsible for managing the security standards, while compliance with the PCI set of standards is enforced by the founding members of the Council, American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc.

PCI DSS Quick Reference Guide (PDF) via pcisecuritystandards.org

Listed below are the official PCI DSS Goals, along with their associated requirements.

  • Build and Maintain a Secure Network
    • Install and maintain a firewall configuration to protect cardholder data
    • Do not use vendor-supplied defaults for system passwords and other security parameters
  • Protect Cardholder Data
    • Protect stored cardholder data
    • Encrypt transmission of cardholder data across open, public networks
  • Maintain a Vulnerability Management Program
    • Use and regularly update anti-virus software or programs
    • Develop and maintain secure systems and applications
  • Implement Strong Access Control Measures
    • Restrict access to cardholder data by business need-to-know
    • Assign a unique ID to each person with computer access
    • Restrict physical access to cardholder data
  • Regularly Monitor and Test Networks
    • Track and monitor all access to network resources and cardholder data
    • Regularly test security systems and processes
  • Maintain an Information Security Policy
    • Maintain a policy that addresses information security for employees and contractors

From a PCI perspective, AWS has the ability to come with compliance already built in from the get-go by utilizing infrastructure as code (IaC) in the form of pre-built Cloudformation templates, which you can see here, along with some great examples of PCI-compliant architectural diagrams. The same IaC result can be achieved with other cloud providers such as Microsoft Azure and Google Cloud Platform (GCP), simply by using Terraform by Hashicorp, an IaC solution which is cloud-agnostic.

ISO 27001 / ISO 27002

ISO 27001

ISO 27001 (ISO/IEC 27001:2013) is a specification for an Information Security Management System (ISMS), which is a framework of policies and procedures that includes all legal, physical and technical controls involved in an organization’s information risk management processes. The specification includes details for documentation, management responsibility, internal audits, continual improvement, and corrective and preventive action. The standard requires cooperation among all sections of an organization.

ISO 27001 was developed in order to “provide a model for establishing, implementing, operating, monitoring, reviewing, maintaining and improving an information security management system.”

ISO 27001 uses a topdown, risk-based approach and is technology-neutral. The specification defines a six-part planning process:

  1. Define a security policy.
  2. Define the scope of the ISMS.
  3. Conduct a risk assessment.
  4. Manage identified risks.
  5. Select control objectives and controls to be implemented.
  6. Prepare a statement of applicability.

The ISO 27001 standard does not mandate specific information security controls, but simply provides a checklist of controls that should be considered in the accompanying code of practice, ISO/IEC 27002:2005 (or ISO 27002).

ISO 27002

This second ISO standard describes a comprehensive set of information security control objectives, as well as a set of generally-accepted best practice security controls. ISO 27002 provides 12 main sections:

  1. Risk assessment
  2. Security policy
  3. Organization of information security
  4. Asset management
  5. Human resources security
  6. Physical and environmental security
  7. Communications and operations management
  8. Access control
  9. Information systems acquisition, development and maintenance
  10. Information security incident management
  11. Business continuity management
  12. Compliance

Organizations are required to apply these controls appropriately in line with their specific risks, and third-party accredited certification is recommended for ISO 27001 conformance.

A few additional ISO 27000 standards that are out of the scope of this article are as follows:

  • 27003 – implementation guidance.
  • 27004 – an information security management measurement standard suggesting metrics to help improve the effectiveness of an ISMS.
  • 27005 – an information security risk management standard.
  • 27006 – a guide to the certification or registration process for accredited ISMS certification or registration bodies.
  • 27007 – ISMS auditing guideline.

You can read more about the ISO/IEC 27000:20013 standards on iso.org, and you can review the AWS compliance FAQs here.


HIPAA (Health Insurance Portability and Accountability Act of 1996) refers to the United States legislation which provides data privacy and security provisions for safeguarding medical information.

Many medical organizations are migrating their infrastructure to the cloud because of the sheer volume of data and lifecycle requirements, which can be an optimal use-case for services such as Amazon’s Object Lifecycle Management policies, which have the ability to store versioned data in their Simple Storage Solution (S3), then move it to S3 Infrequent Access, then to AWS Glacier and Glacier Deep Archive, and finally discard the data after a certain amount of time (see also S3 Intelligent Tiering). That being said, if you work in healthcare or deal with medical information, the following 5 key areas of focus apply both on-prem, as well as in the cloud:

1. System availability to ensure timely access to patient health records

Because the majority of healthcare organizations use electronic health records (EHRs), HIPAA mandates that any system hosting protected health information (PHI) must offer high availability (HA) and reliability. This means that your uptime is critical to ensuring patients’ data is available when physicians need access to it.

If you are thinking of migrating your EHRs to the cloud, you should conduct an in-depth review of the CSP’s uptime score and identify whether or not your contract with the vendor includes service level agreements (SLAs).

2. PHI protection and security practices

As part of having electronic health data hosted in a data center, HIPAA mandates that all of that data must be encrypted both in transport and at rest. The law also requires a level of auditing and traceability for system and data access at any time. Most cloud providers offer data encryption services to secure their client’s data, which satisfies the majority of HIPAA encryption requirements. For AWS, this would include EBS encryption and utilization of their Key Management Service (KMS) for data at rest. Standard TLS encryption best practices should always apply for data in transit.

A healthcare organization can always take further steps to protect its data by implementing additional security safeguards, such as adding encryption layers and restricting access to the data to only authorized users, which can be achieved in AWS by utilizing IAM roles to control access authorization to protected resources, as well as CloudTrail in order to provide granular auditing capabilities.

3. Data ownership and accessibility post-service termination

A CSP has to ensure that a healthcare client can extract its data when a hosting agreement is terminated. Any attempt to block or deny access to that data is considered a breach of the HIPAA Privacy Rule, so that’s a big no-no.

Cloud providers, like Amazon, Microsoft, and Google, all offer ways to easily export, migrate and download copies of customer data. However, companies should always ask this question at the beginning of a CSP relationship in order to avoid risking big trouble if they later find themselves in violation of HIPAA.

4. Security practices within data centers

Healthcare organizations are required to have a business associate agreement (BAA) with any entity that comes in contact with PHI — and this includes cloud hosting providers, as well. This also means that the CSP has to meet all of the technical and administrative requirements under HIPAA.

Any CSP that is unwilling to sign a BAA is likely not able to commit to HIPAA requirements, and health IT should not consider it for cloud hosting.

Fun fact: if you share PHI hosted in the cloud with a third party that you have a BAA with, that third party themselves does not have to have a BAA with the cloud provider. Okay, that’s all the fun for today. Let’s get back to the boring compliance shit that you need to know in order to do your job right.

5. Compliance and security standards and practices

Some CSPs, like Microsoft, provide additional services to help their clients review their HIPAA compliance. Some of Microsoft’s services include Compliance Manager, which provides a way for a health organization to track activities on their HIPAA checklist, and Secure Score, which provides detailed scoring for the security of Office 365 and Azure workloads.

It can be a real challenge for health IT to determine the best cloud service provider to partner with, who is able to meet their HIPAA requirements. Fortunately, most of the big vendors recognize that alignment with HIPAA is a must, in order for them to attract healthcare clients. The result is that vendors like Amazon, Google, Microsoft, and IBM, fully advertise their adherence — not only to HIPAA — but to other healthcare-related rules and security frameworks, such as HITRUST, which all ensure the protection of health-related data.

You can view the AWS HIPAA FAQs here, as well as some nifty architectural HIPAA-compliant diagrams and Cloudformation templates here.

NIST 800-53 / 800-171 (DoD) Frameworks

NIST 800-53

The U.S. National Institute of Standards and Technology (NIST) built an extensive collection of information security standards and best practices documentation, and The NIST Special Publication 800 series was, first published in 1990, has grown to provide advice on pretty much every aspect of information security. Although not specifically an information security framework, other frameworks have evolved from the NIST SP 800-53 model. U.S. government agencies utilize NIST SP 800-53 to comply with the Federal Information Processing Standards’ (FIPS) 200 requirements. Even though it is specific to government agencies, the NIST framework can be applied in any other industry, and it should definitely not be overlooked by other organizations looking to build an information security program.

There is just too much to list that the NIST 800-53 framework covers, so feel free to check it out for yourself right here.

NIST 800-171 (DoD) Framework

NIST Special Publication 800-171

The U.S. Department of Defense that mandated contractor compliance with the NIST 800-171 security framework back in December 2017. Since then, the framework has widely grown in popularity. Cyberattacks are occurring throughout the supply chain, and government contractors often find their systems and intellectual property a frequent target used to gain access into federal information systems. Since December of 2017, all manufacturers and their subcontractors now have to implement an IT security framework in order to bid on new business opportunities.

NIST SP 800-171 was the valid choice for this requirement, since the framework also applies to smaller organizations. It’s focused on the protection of Controlled Unclassified Information (CUI) resident in nonfederal systems and organizations, which aligns well with manufacturing or other industries, who don’t deal with information systems or other types of compliance. It may not be a good fit by itself for industries dealing with more sensitive information such as credit cards or Social Security data, but it is freely available and allows for self-certification within the organization by using readily-available documentation from NIST.

The controls included in the NIST SP 800-171 framework are directly related to NIST SP 800-53, but they are less detailed and more generalized. It’s still possible to bridge the two standards if an organization has to show compliance with NIST SP 800-53 using NIST SP 800-171 as the base. This allows a good level of flexibility for smaller organizations that may grow over time as they need to show compliance with the additional controls included in NIST SP 800-53. By the way, AWS is NIST 800-171-compliant right out of the gate.

Some relief – information you are familiar with but may not have exactly pieced together yet

So how do the NIST frameworks effect us on a day-to-day basis? Did you know they did? Sure, sure. Of course you did. Have you ever conducted a penetration test before? Unlike The Great Book, all sins are not equal in the eyes of a security professional, and it is our job to rank those sins from LOW to CRITICAL — and for that, we use this handy dandy tool — the Common Vulnerability Scoring System (CVSS) Calculator. That’s all NIST. They came up with that shit.

Here’s more fun facts so you can leave feeling like you learned something today:

Ever had a CVE with your name on it? Yeah, me neither…yet. Well that’s not actually NIST, that’s Mitre. They launched the CVE List of Common Vulnerabilities and Exposures back in 1999. However, they have a strong symbiotic relationship with the National Vulnerability Database (NVD), which was established by NIST in 2005. Each CVE contains an identification number, a description, and at least one public reference for publicly-known cybersecurity vulnerabilities. CVE Entries are used in numerous cybersecurity products and services from around the world, including NIST’s own National Vulnerability Database, which is fed directly by CVE and immediately updated with new vulnerabilities. Both CVE and NVD are funded by the U.S. Department of Homeland Security (DHS), as well as the Cybesecurity and Infrastructure Security Agency (CISA).

So yeah, theres’s a lot of compliance mumbo-jumbo, and it can be painful at times, but it is also necessary for the type of business we conduct in this day and age. It is well worth your time and effort to become at least somewhat familiar with the policies and frameworks that apply to the sectors that you currently work in (or wish to work in), in order to be as knowledgeable as possible about the protocols that are in place for you to conduct your daily activities according to previously-established best practices. I hope this helps!

Leave a Reply