HIPAA

Geography: US

Industry: Healthcare

Type: Regulation

The Health Insurance Portability and Accountability Act (HIPAA) of 1996 is a US federal law to protect sensitive patient healthcare data from disclosure without the patient’s consent.

At a technical level, the most common item of concern to developers is the protection of sensitive healthcare data—often called protected health information (PHI)—at rest and in transit. The wording in HIPAA can be vague, however, and is often open to interpretation.

An example of a technical control in HIPAA is as follows:

§ 164.312 Technical safeguards. (iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.

In 2009, the US government enacted the Health Information Technology for Economic and Clinical Health (HITECH) Act, which broadens portions of various HIPAA privacy and security laws and regulations and is more specific about encryption of data at rest and in transit.

HITRUST

Geography: Global

Industry: Originally healthcare, but now used in other verticals

Type: Risk framework

The Health Information Trust (HITRUST; https://hitrustalliance.net) is an organization governed by representatives from various industries. It is not a government agency. HITRUST created and maintains the Common Security Framework (CSF), a certifiable security and privacy controls framework to help healthcare organizations and their providers demonstrate security and compliance in a consistent manner.

The HITRUST CSF provides organizations with a comprehensive, flexible, and efficient approach to regulatory compliance and risk management. The HITRUST CSF cross-references more than 40 authoritative sources. The HITRUST CSF is regularly updated as mapped authoritative sources change and new authoritative sources are introduced. Because the HITRUST CSF is both risk- and compliance-based, organizations of varying risk profiles can customize the security and privacy control baselines using a variety of factors including organization type, size, systems, and regulatory requirements.

Although the HIRTUST CSF documentation is large—more than 500 pages—it is readable, specific, and structured. It is also a useful cross-reference for other compliance programs. For example, the HITRUST 9.6.0 documentation shows that HITRUST “Control Reference: 01.c Privilege Management” maps to the following and many others:

• FedRAMP AC-6

• NIST SP 800-53 R4 AC-21(2)[S]

• NIST Cybersecurity Framework v1.1 PR.AC-4

• PCI DSS v3.2.1 7.1

An example of a technical control in HITRUST is:

Control Reference: 01.a Access Control Policy: An access control policy shall be established, documented, and reviewed based on business and security requirements for access.

GDPR

Geography: EU (also outside EU)

Industry: All

Type: Regulation

The General Data Protection Regulation (GDPR)—or more formally, Regulation (EU) 2016/679—is a privacy regulation in the European Union (EU) that “lays down rules relating to the protection of natural person with regard to the processing for personal data and rules relating to the free movement of personal data.” In short, GDPR is a security and privacy regulation that has a major impact on how companies gather, store, and process personal data for EU citizens and residents.

The last point, “EU citizens and residents,” is important; GDPR applies to any company handling this data, whether they are based in the EU or not—for example, a US company that provides services or goods to a person in Italy, or a company with a website based in Japan that uses cookies and logs the IP addresses of people visiting the site from the EU.

Article 32, “Security of Processing,” has a large impact on software architects and developers. The following example is from Article 32:

1. Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:

   1. the pseudonymization and encryption of personal data.

   2. the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services.

PCI DSS

Geography: Global

Industry: Finance (credit cards)

Type: Regulation

The Payment Card Industry Data Security Standard (PCI DSS) is a global information security standard that defines prescriptive control of credit card data. Compliance with PCI DSS is required for all organizations that store, process, or transmit payment or cardholder data.

The PCI DSS documentation not only describes requirements but includes testing procedures to determine whether issues exist or to verify that a procedure has not regressed when adding new functionality or fixing bugs.

PCI has also created the Payment Application Data Security Standard (PA DSS), which is designed to help software vendors develop security applications that manage payment data. PA DSS will be replaced by the PCI Software Security Framework (PCI SSF) by the end of 2022.

There are two standards under the PCI SSF umbrella:

• Secure Software Standard

• Secure Software Lifecycle Standard

Many of the items addressed in the lifecycle standard are outlined in Chapter 1, “Secure development lifecycle processes.”

An example of a technical control in PCI DSS is as follows: calls the Windows CryptoAPI

2.4 Maintain an inventory of system components that are in scope for PCI DSS.

FedRAMP

Geography: US

Industry: Federal government

Type: Regulation

The Federal Risk and Authorization Management Program (FedRAMP), which dates to 2011, provides a standard approach to accelerate the adoption of secure cloud solutions by US federal agencies. It came into effect under the Federal Information Security Management Act (FISMA), which requires federal agencies to implement mandatory processes and controls designed to ensure security. In essence, FedRAMP allows cloud-based solutions to meet FISMA requirements.

FedRAMP derives its controls from National Institute of Standards and Technology (NIST) SP 800-53 (covered next) and uses differing controls based on the impact levels of the solution: Low, Medium, and High. The impact levels are described in NIST PUB 199. NIST PUB 199 defines the Low, Medium, and High categories based on the impact of confidentiality, integrity, and availability.

Here’s an example of technical control in FedRAMP High:

AU-09 Audit and Accountability: The information system implements cryptographic mechanisms to protect the integrity of audit information and audit tools.

Supplemental Guidance: Cryptographic mechanisms used for protecting the integrity of audit information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. Related controls: AU-10, SC-12, SC-13.

NIST SP 800-53

Geography: US

Industry: Federal government

Type: Risk framework

National Institute of Standards and Technology (NIST) is a nonregulatory agency within the US Department of Commerce that helps to develop and publish IT security standards.

NIST Special Publication (SP) 800-53, “Security and Privacy Controls for Information Systems and Organizations,” is a catalog of security and privacy controls that applies to all federal information systems in the United States. It provides a process for selecting controls to protect organizations from cyberattacks and other threats. NIST SP 800-53 is just one of a series of other SP 800 documents, all of which relate to computer security. The current revision is revision 5, often abbreviated to r5 or R5.

Even though SP 800-53 applies to federal agencies, many nongovernment organizations use it, too, because it is exhaustive and well-documented. NIST SP 800-53 defines controls within a set of families:

• AC Access Control

• AT Awareness and Training

• AU Audit and Accountability

• CA Assessment, Authorization, and Monitoring

• CM Configuration Management

• CP Contingency Planning

• IA Identification and Authentication

• IR Incident Response

• MA Maintenance

• MP Media Protection

• PE Physical and Environmental Protection

• PL Planning

• PM Program Management

• PS Personnel Security

• PT PII Processing and Transparency

• RA Risk Assessment

• SA System and Services Acquisition

• SC System and Communications Protection

• SI System and Information Integrity

• SR Supply Chain Risk Management

NIST SP 800-53 controls are often cited by other compliance and risk programs.

Here’s an example of a NIST SP 800-53 technical control:

AC-6 Least Privilege. (2) LEAST PRIVILEGE | NON-PRIVILEGED ACCESS FOR NONSECURITY FUNCTIONS

Require that users of system accounts (or roles) with access to [Assignment: organization-defined security functions or security-relevant information] use non-privileged accounts or roles, when accessing non-security functions

NIST Cybersecurity Framework

Geography: US

Industry: Public and private sectors

Type: Risk framework

Released in 2014 under a presidential executive order, the NIST Cybersecurity Framework (NICT CSF), or, more formally, the Framework for Improving Critical Infrastructure Cybersecurity, has become an invaluable resource for private-sector enterprises and public agencies. A 2017 presidential executive order requires compliance with NIST CSF for federal government agencies and for entities in the federal government supply chain.

The NIST CSF core components are divided into five areas of cybersecurity:

• Identify

• Protect

• Detect

• Respond

• Recover

The NIST CSF is relatively high level but references documents like NIST 800-53 for more detail on how to implement specific controls and processes. The NIST CSF document is only approximately 40 pages long, while NIST SP 800-53 release 5 weighs in at a hefty 500 pages.

An example of a NIST CSF technical control is as follows:

PR.DS-7: The development and testing environment(s) are separate from the production environment

Note that this control makes further references to NIST SP 800-53 CM-2, which starts with the following:

CM-2 BASELINE CONFIGURATION

Control: a. Develop, document, and maintain under configuration control, a current baseline configuration of the system.

FIPS 140

Geography: US

Industry: Government (often used in the private sector)

Type: Regulation

As the name suggests, the Federal Information Processing Standard (FIPS) Publication 140, “Security Requirements for Cryptographic Modules,” is a US government standard that specifies the security requirements satisfied by a cryptographic module. The FIPS 140 security requirements cover 11 areas related to the design and implementation of a cryptographic module. The standard provides four security levels, 1 through 4, with increasing levels of security. Most US government agencies require the use of FIPS 140–validated cryptographic modules, and maybe at specific security levels. Some commercial organizations require both.

There is a great deal of confusion about what FIPS 140 is, so let us clarify things. FIPS 140 is a standard by which the implementation of cryptographic modules is validated. A module could be a library that implements a cryptographic algorithm, or it might be a cryptographic device.

Here are two examples:

• FIPS 140

• SHA-2 in NET

FIPS 140 and SHA-2 in .NET

You might know there are three implementations of the various SHA-2 hash algorithms in .NET:

• System.Security.Cryptography.SHA256Cng

• System.Security.Cryptography.SHA256CryptoServiceProvider

• System.Security.Cryptography.SHA256Managed

There are also implementations of SHA384 and SHA512, but let’s keep things simple and focus only on the 256-bit versions of SHA-2.

SHA-2 is defined in another FIPS standard: FIPS 180-4, “Secure Hash Standard.” This document describes the code behind SHA-2 as well as test values to verify a correct implementation.

Other cryptographic algorithms are defined in other FIPS standards:

• AES is defined in FIPS 197.

• SHA-1 is defined in FIPS 180-1.

• 3DES is defined in FIPS 46-3.

Someone implementing a cryptographic algorithm can choose to have the implementation reviewed and validated using FIPS 140-3. The review is performed by an independent third party certified to perform the work.

Let’s get back to the .NET SHA-2 implementations. SHA256Cng and SHA256CryptoServiceProvider call into the Windows SHA-2 implementations, which are both FIPS 140-2 (because it predates FIPS 140-3) validated implementations of SHA-2. If you look at the source code for these three implementations at the .NET source code site (https://referencesource.microsoft.com/), you can see that:

• SHA256Managed is a full implementation of the algorithm in C#.

• SHA256CryptoServiceProvider calls the Windows CryptoAPI CapiHashAlgorithm() function.

• SHA256Cng calls the Windows Cryptography Next Generation (CNG) BCryptHashAlgorithm() function.

Here’s where things get interesting (and important): the Windows CNG and CryptoAPI implementations of SHA-2 are FIPS 140-2 validated, but SHA256Managed is not. All three are functionally the same, and all three are implementations of the FIPS 180-4 hash algorithm. What makes this important is your company or some of your customers may require the use of FIPS 140-validated implementations.

For compliance purposes, it is possible to put Windows into a FIPS 140 mode. Applications performing cryptographic operations can interrogate this setting to determine which algorithms to use. This setting should be used with caution, however, as it can cause some applications to fail in “mysterious ways” if they do not fail gracefully in the face of this setting. Also, setting this is not a guarantee that an application will use only FIPS 140–validated algorithms because the application might not read the setting, or it could simply ignore it.

You can set the FIPS policy from Group Policy. (See Figure 8-1.)

You can also set the policy directly in the registry under HKEY_LOCAL_MACHINESystemCurrent-ControlSetControlLsaFipsAlgorithmPolicy. Set Enabled to 1 or 0 to enable or disable FIPS policy, respectively.

SOC

Geography: Global

Industry: All

Type: Regulation

System and Organization Controls (SOC, pronounced sock) are internal control reports created by the American Institute of Certified Public Accountants (AICPA). They are intended to examine services provided by a service organization so that end users can assess and address the risk associated with a service.

• SOC 1 is a financial auditing framework that analyzes the controls implemented to protect the integrity of financial data.

• SOC 2 is designed specifically for auditors to use when assessing the data security and privacy controls of service providers such as Azure.

• A SOC 3 report is a shorter version of a SOC 2 report intended to be used for public access.

To make things a little more complex, various SOC reports have two types:

• A Type 1 report evaluates controls at a point in time and whether their design is suitable to meet relevant trust principles.

• A Type 2 report details the operational effectiveness of the controls over a period, such as 6 or 12 months.

Various independent Azure audit reports, including SOC 2 Type 2, are available at the Service Trust Portal.

SOC 2 addresses five trust services principles (TSPs):

• Security

• Availability

• Processing integrity

• Confidentiality

• Privacy

An example SOC 2 Trust Service Criteria is as follows:

CC6.6 The entity implements logical access security measures to protect against threats from sources outside its system boundaries.

ISO/IEC 27001

Geography: Global

Industry: All

Type: Regulation

The International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 27000 family of standards outlines hundreds of controls and control mechanisms to help organizations secure their environments.

ISO/IEC 27001, “Information Security Management,” is a security standard that mandates requirements that define how to implement, monitor, maintain, and continually improve security. It also outlines best practices, which include documentation requirements, divisions of responsibility, availability, access control, security, auditing, and corrective and preventive measures. The standard covers not only technical controls but also physical controls such as locks on doors and background checks, which are clearly outside the scope of software.

One of the benefits of ISO/IEC 27001 certification is it is internationally accepted, so it helps organizations comply with other regulatory and legal requirements that relate to the security of information.

In terms of size, it is similar to NIST 800-53:

• NIST 800-53 has 20 control families and hundreds of controls.

• ISO/IEC 27001 has 14 control categories and 114 controls.

An example of an ISO/IEC 27001 control is as follows:

A.9.4.1 Access to information and application system functions shall be restricted in accordance with the access control policy.

And another:

A.10.1.2 A policy on the use, protection and lifetime of cryptographic keys shall be developed and implemented through their whole lifecycle.

ISO/IEC 27034

Geography: Global

Industry: All

Type: Regulation

Another regulation under the ISO/IEC 27000 umbrella, ISO/IEC 27034, “Information technology — Security techniques — Application security — Part 1: Overview and concepts,” focuses on secure software practices. It is not one document; rather, it is a set of six documents that help organizations to map their current software development practices to current security best practices.

Annex A of the first document, ISO/IEC 27034-1, presents a case study on how to map an existing software development process to some of the components of ISO/IEC 27034. That case study is the Microsoft Security Development Lifecycle that we explain in Chapter 1.

Center for Internet Security Benchmarks

Geography: Global

Industry: All

Type: Risk Framework

The Center for Internet Security (CIS) is an independent group of security professionals from academia, industry, and government who collaborate to build prescriptive security guidance for many products, including Azure, Microsoft Exchange, IIS, iOS, NGINX, and much more. The prescriptive guidance is delivered as extensive benchmarks. CIS also has hardened operating system images that embody the various benchmarks within the images. These OS images can be downloaded from within various cloud services, including Azure.

The CIS Benchmark is a comprehensive set of controls and is often cited in Microsoft documents, including the Azure Security Benchmark. The items in each benchmark map to one or more controls in the CIS controls (as well as PCI and SOC; more will be added over time). Each CIS practice is complete, with the rationale for the policy as well as steps to set the policy from the Azure Portal, the Azure CLI, PowerShell, and links to further resources. This is extremely beneficial.

Some example CIS controls for Azure include the following:

1.14 Ensure That 'Restrict access to Azure AD administration portal' is Set to "Yes" Database (maps to 6.8 ‘Define and Maintain Role-Based Access Controls’ in CIS Controls v8.0)

2.8 Ensure that Microsoft Defender for Key Vault is set to 'On' Database (maps to 10.1 ‘Deploy and Maintain Anti-Malware Software’ in CIS Controls v8.0)

3.10 Ensure Storage logging is Enabled for Blob Service for 'Read', 'Write', and 'Delete' requests Database (maps to 8.5 ‘Collect Detailed Audit Logs’ in CIS Controls v8.0)

4.1.2 Ensure that 'Data encryption' is set to 'On' on a SQL Database (maps to 3.11 ‘Encrypt sensitive data at rest’ in CIS Controls v8.0)

Azure Security Benchmark

Geography: Global

Industry: All

Type: Risk framework

The Azure Security Benchmark (ASB) is a set of security recommendations to help tenants secure their subscriptions. From the ASB, Azure products derive their own interpretation of each recommendation. These are called the Azure Security Baseline. Notice in Figure 8-2 how the ASB recommendations map to other compliance programs outlined in this chapter.

Here is an example of an ASB recommendation:

DP-3: Monitor for unauthorized transfer of sensitive data

Here is what the recommendation means when it maps to Cosmos DB:

Guidance: Cosmos DB supports Microsoft Defender for Cosmos DB, which provides an additional layer of security intelligence that detects unusual and potentially harmful attempts to access or exploit Azure Cosmos DB accounts. This layer of protection allows you to address threats, even without being a security expert, and integrate them with central security monitoring systems.

Here is what it means when it maps to Azure Media Services:

Guidance: Azure Media Services transmits sensitive data. But it doesn't support native monitoring of the unauthorized transfer of sensitive data. Organizations can configure events to be logged to Azure Monitor. Organizations can also set up custom Logic App automation flows to trigger on any anomalous activity.

Here is what it means when it maps to Azure Purview:

Guidance: Azure Purview offers lineage monitoring capability. Currently, Azure Purview supports the following extract, transform, and load (ETL) tools:

• Azure Data Factory

• Azure Data Share

• Power BI

Data lineage can display how data propagates from one system to another. This display helps eliminate duplication of sensitive data. It provides a graphical representation to increase data lineage visibility.

For your data sources that Azure Purview scans, monitor for the unauthorized transfer of data to locations outside of enterprise visibility and control. Use service-specific Microsoft Defender and log options to do the monitoring. This action typically involves monitoring for anomalous activities, such as large or unusual transfers. These activities might indicate unauthorized data exfiltration.

Tools like Microsoft Defender for Cloud offer, among other things, a direct mapping between an issue that might put an Azure tenant at risk and the appropriate ASB information. Figure 8-3 shows a partial view of the Regulator Compliance section of Microsoft Defender for Cloud. Note that SOC TSP is for SOC2 and SOC3.

OWASP

Geography: Global

Industry: All

Category: De facto best practices standard

The Open Web Application Security Project (OWASP) was started more than 20 years ago by Mark Curphey in response to the constant stream of security vulnerabilities in web-based applications. OWASP is most well-known for its OWASP Top 10 list, which is updated every few years and addresses the most pertinent vulnerability classes, impacts, and remedies. As of this writing, the latest version is OWASP Top 10 2021.

The OWASP Top 10 is absolutely not a regulation; it is a set of best practices. Every architect and developer should understand the OWASP Top 10 and have practices in place to prevent or mitigate each issue in the list. Having concrete practices in place to address the OWASP Top 10 is always a good idea because middle and upper management will often ask about them (even if they don’t know what they are!).

Of course, there are vulnerabilities outside the Top 10. Tooling and processes should cover more than the Top 10, because the Top 10 is updated only every two years or so, and new issues are always found. As part of a good defensive posture, you should keep an eye on new and evolving threats. With all that said, addressing this list is always seen as a good, solid baseline.

MITRE

Geography: Global

Industry: All

Category: De facto standards and practices

No book on compliance, best practice, risk, and de facto standards is complete without a discussion of MITRE. MITRE is a US not-for-profit organization that works closely with industry, academia, and governments on, among other things, security research. While MITRE is based in the United States, it is well-respected around the world.

Over the years, MITRE has helped build and maintain some of the most important and influential security programs. The following list contains some of them:

• CVE

• CWE

• ATT&CK

• CAPEC

Let’s dive into each.

Compliance synopsis

There are many more compliance and risk programs out there. These include the following:

• ISO 27002 code of practice for information security controls

• US Department of Defense Cybersecurity Maturity Model Certification (CMMC)

• Internet of Things (IoT) Cybersecurity Improvement Act of 2020

• Cloud Security Alliance Cloud Control Matric (CSA CCM)

• Criminal Justice Information Services (CJIS)

• International Traffic in Arms Regulations (ITAR)

• NIST SP 800-171, “Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations”

• Gramm-Leach-Bliley Act (GLBA)

• UK Cyber Essentials Plus

• Sarbanes-Oxley Act (SOX)

• California Privacy Rights Act (CPRA)

• Children’s Online Privacy Protection Rule (COPPA)

• New Zealand ISM Restricted

We could keep going! It is critically important that all engineering staff have a baseline level of knowledge about the most common compliance programs that might affect them as they design, develop, and test a solution.

One way to map the design of a system to the security controls required by compliance programs is to use threat models. This is covered next.