Navigating Compliance Frameworks with Deepfactor: PCI DSS, SOC2, and NIST 800-53

Security compliance frameworks have witnessed an increased adoption over the last few decades to cater to the ever-evolving technology, cybersecurity and threat landscapes. These frameworks primarily encompass regulatory standards, guidelines, and specifications to manage risk better.

Securing systems, networks, data, and all other assets can no longer be considered an afterthought. Hence compliance risk management has become extremely critical for organizations/individuals selling or buying technology. It focuses on organizations striving to adhere to cybersecurity frameworks, application security standards and having all the programs/policies in place to identify, monitor, mitigate, and understand the potential impact of violations.

Since the 1980s, several security compliance frameworks have emerged, including PCI DSS, SOC2, NIST SP 800-53, ISO, GDPR, and HIPAA to name a few. The diversity of frameworks (international, domain specific, region specific, entity/resource specific, audience, complexity) can be attributed to the dynamic  nature of the technology/cybersecurity landscape and the specific  focus areas of each framework.

Why is compliance necessary?

Security compliance checks several boxes that are either mandatory, or have a positive effect on a company’s bottom line: 

• Legal and regulatory obligations
  • An organization might be legally obligated to comply with a set of compliance frameworks. For instance, GDPR (General Data Protection Regulation) compliance is mandated for organizations handling customer data in Europe.
• Marketing and brand reputation
  • Compliance with frameworks can be used as a promotion strategy to stand out amongst competitors and garner trust.
• Monetary benefits with regard to more paying customers, upselling, avoid fines/penalties, loss due to security incidents
• Effective risk management 
  • Following a standardized set of guidelines and regulations can help organizations prevent, identify, monitor and mitigate security incidents better.

Standards and specifications that help an organization achieve PCI DSS compliance

PCI DSS (Payment Card Industry Data Security Standard) is a set of guidelines first created in 2004 by PCI SSC (Payment Card Industry Security Standards Council) to secure monetary transactions through payment cards (credit, debit etc) and prevent loss of sensitive information like cardholder PII, expiry, and security codes. PCI DSS comprises multiple compliance levels (Level 1-4) depending on the transactions processed per year. The latest version 4.0 was released in 2022, and is being mandated for implementation by April 2024 with some new requirements being mandated by March 31st 2025. 

Applicability: PCI DSS is mandatory for financial institutions and organizations that handle and process payment card transactions and associated data.

An organization being audited for PCI DSS compliance is validated against 12 requirements/250+ standardized controls:

• Install and Maintain Network Security Controls
  • Example: Install network firewalls
• Apply Secure Configurations to All System Components
  • Example: Avoid usage of default/vendor supplied passwords
• Protect Stored Account Data
  • Example: Avoid storing PII (Personally Identifiable Information) wherever possible
• Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
  • Example: Encrypt data in motion and at rest
• Protect All Systems and Networks from Malicious Software
  • Example: Regularly run anti virus/malware scans using updated scanners
• Develop and Maintain Secure Systems and Software
  • Example: Effective vulnerability management by continuously scanning artifacts to identify and remediate vulnerabilities
• Restrict Access to System Components and Cardholder Data by Business Need to Know
• Identify Users and Authenticate Access to System Components
  • Example: Implement multi factor authentication
• Restrict Physical Access to Cardholder Data
• Log and Monitor All Access to System Components and Cardholder Data
• Test Security of Systems and Networks Regularly
• Support Information Security with Organizational Policies and Programs

Standards and specifications that help an organization achieve SOC2 compliance

SOC (Systems and Organization Controls) is a set of principles first developed by AICPA (American Institute of Certified Public Accountants) in 2010 to manage and secure data better. Here is the latest version.

SOC1, SOC2, SOC3 (similar to SOC2 for general public consumption) are the three types of SOC reports which cater to financial reporting and security/control principles respectively. 

SOC2 certifications can be of two types—Type 1 and Type 2. They both focus on the same set of principles but Type 1 focuses on the controls in place at a given point of time while Type 2 focuses on principles being operational over a significant period of time, generally 6-12 months.

Applicability: An optional attestation for organizations handling customer data such as SaaS offerings. 

An organization being audited for SOC2 Type 2 compliance is validated against the following Trust Service Criteria (50+ controls):

• Confidentiality (C1.1-C1.2)
  • Sample controls:
    • C1.1: The entity identifies and maintains confidential information to meet the entity’s objectives related to confidentiality.
• Processing Integrity (PI1.1-PI1.5)
  • Sample controls:
    • PI1.1: The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications, to support the use of products and services.
• Availability (A1.1-A1.3)
  • Sample controls:
    • A1.1: The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.
• Privacy  (P1.0-P8.0)
  • Sample controls:
    • P1.0: Privacy Criteria Related to Notice and Communication of Objectives Related to Privacy
    • P2.0: Privacy Criteria Related to Choice and Consent
    • P3.0: Privacy Criteria Related to Collection
    • P4.0: Privacy Criteria Related to Use, Retention, and Disposal
• Security (CC1-CC9)
  • Sample controls:
    • CC1: Control Environment
    • CC2: Information and Communication
    • CC3: Risk Assessment

An auditor finalizes the set of controls to be validated by working with the organization being tested for compliance and reports it as Unqualified (pass), Qualified (pass with reservations), Adverse (fail), Disclaimer of Opinion (not enough information to attest) depending on the test results.

Some NIST 800-53 guidelines

NIST SP 800-53 are a set of security and privacy controls, both technical and non-technical, that were first developed by the National Institute of Standards and Technology in 2005, primarily for federal information systems and organizations. The latest revision, NIST SP 800-53A Rev. 5 was rolled out in January 2022. 

Applicability: Although primarily used and mandated for federal systems, it can now be used as a general standard with the latest revision.

An organization being audited for NIST 800-53 compliance is validated against a bunch of controls. Some of the control families (approx 20 control families and 1000+ controls) include:

• Access Control
• Risk Assessment
• Identification and Authentication
• Incident Response
• Audit and Accountability
• Assessment, Authorization and Monitoring
• Configuration Management
• Supply Chain Risk Management
• System and Information Integrity
• Program Management
• Planning

Frequently Asked Questions

What role does application security play in achieving compliance?

Application security focuses on securing applications, associated entities (like data, network, code, hardware etc) and ensuring confidentiality/integrity/availability of the application. It encompasses secure practices across the different stages of the SDLC (software development lifecycle), such as:

• Secure designing/coding/vulnerability management
• Security testing
• Data protection
• Access control
• Secure deployment
• Audit/logging
• Incident response and management, and more.

Now that we understand specifics of some of the commonly adopted compliance frameworks and application security, the answer to our question about the role of application security in compliance is pretty clear. The overlap between application security workflows and compliance framework standards is evident. Effective application security:

• Ensures protection of sensitive data through secure coding, vulnerability management, data encryption, role based access control.
• Enables continuous scanning of running applications for detection of anomalous behavior with evidence including stack traces, system calls and mapping of violations to compliance controls which helps in identifying, understanding and mitigating compliance risk.
• Facilitates incident response through effective audit and logging workflows.
• Enables secure deployment by integrating application security workflows in CICD pipelines and infrastructure configuration management.
• Provides security testing practices to continuously monitor and test applications.

Application security serves as a medium to achieve compliance and help organizations build and maintain secure processes, systems and applications.

How does Deepfactor simplify compliance with PCI DSS, SOC2 and NIST 800-53? Can Deepfactor help automate the compliance process?

We have established that application security can help us meet many/most compliance requirements. The immediate need, though, is security compliance automation i.e automating detection of compliance issues associated with the different frameworks using compliance monitoring tools and regulatory compliance software, instead of just one-time or sporadic compliance checks.

Deepfactor addresses the two main requirements of compliance frameworks.

• Vulnerability Management

Some of the compliance requirements within the various frameworks that talk about vulnerability management are:

PCI DSS v4 

• 11.3 : External and internal vulnerabilities are regularly identified, prioritized, and addressed (11.3.1)
  • Internal vulnerability scans are performed as follows:
    • At least once every three months.
    • High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
    • Rescans are performed that confirm all high risk and critical vulnerabilities (as noted above) have been resolved. 
    • Scan tool is kept up to date with latest vulnerability information. 
    • Scans are performed by qualified personnel and organizational independence of the tester exists.
• 6.3 Security vulnerabilities are identified and addressed. (6.3.3)
  • All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: 
    • Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release. 
    • All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release).

SOC2 Type 2

• CC7.1 To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.
• Conducts Vulnerability Scans — The entity conducts infrastructure and software vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after significant changes are made to the environment. Action is taken to remediate identified deficiencies in a timely manner to support the achievement of the entity’s objectives. 

With Deepfactor’s unique runtime software composition analysis, one can now correlate static scans with runtime analysis and prioritize vulnerabilities based on true usage, reachability, exploitability and deployment context.

Reduction in SCA noise using Deepfactor can help organizations achieve their primary compliance goal of vulnerability management without unnecessary hassle.

• Secure Networks and Systems through continuous monitoring and anomaly detection

Some of the compliance requirements that talk about continuously monitoring networks and systems and detecting anomalous behavior are:

SOC2 Type 2

• CC7.2: The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives; anomalies are analyzed to determine whether they represent security events 
• CC6.6: The entity implements logical access security measures to protect against threats from sources out- side its system boundaries. 

PCI DSS v4

• 11.5 : Network intrusions and unexpected file changes are detected and responded to.
• 1.2 : Network security controls (NSCs) are configured and maintained.

Deepfactor runtime security is not only capable of highlighting true reachability at runtime,  which can be used to better prioritize SCA vulnerabilities, but it can also continuously monitor networks and systems, gather application insights that highlight anomalous behavior and zero-day vulnerabilities, map policy violations to compliance controls, and generate configurable alerts. 

Deepfactor runtime security capabilities, with granular control using pre-defined/configurable rules, spans across categories such as those in the screenshot below: 

Deepfactor is a new approach to application security that combines software composition analysis, container scans, container runtime security, and SBOM into a powerful integrated platform. Feel free to reach out to us in case you have any questions and want to learn more about AppSec 2.0 using Deepfactor.