import { DocumentSource, SecurityDocument } from "../types.js";
export class ComplianceSource implements DocumentSource {
name = "Compliance";
async fetchDocuments(): Promise<SecurityDocument[]> {
const documents: SecurityDocument[] = [];
try {
console.error("Fetching Compliance framework documents...");
// PCI DSS
const pciDocs = this.getPCIDSS();
documents.push(...pciDocs);
// HIPAA
const hipaaDocs = this.getHIPAA();
documents.push(...hipaaDocs);
// ISO 27001/27002
const isoDocs = this.getISO27001();
documents.push(...isoDocs);
// SOC 2
const socDocs = this.getSOC2();
documents.push(...socDocs);
// GDPR
const gdprDocs = this.getGDPR();
documents.push(...gdprDocs);
console.error(`Fetched ${documents.length} Compliance documents`);
} catch (error) {
console.error("Error fetching Compliance documents:", error);
}
return documents;
}
private getPCIDSS(): SecurityDocument[] {
return [
{
id: "pci-dss-overview",
source: "Compliance",
title: "PCI DSS 4.0 Overview",
url: "https://www.pcisecuritystandards.org/",
content: `PCI DSS (Payment Card Industry Data Security Standard) 4.0 is a global standard for protecting cardholder data. Applies to all entities that store, process, or transmit cardholder data. 12 Requirements organized into 6 goals: Build and Maintain a Secure Network: 1. Install and maintain network security controls. 2. Apply secure configurations to all system components. Protect Account Data: 3. Protect stored account data. 4. Protect cardholder data with strong cryptography during transmission. Maintain a Vulnerability Management Program: 5. Protect all systems and networks from malicious software. 6. Develop and maintain secure systems and software. Implement Strong Access Control Measures: 7. Restrict access to system components and cardholder data by business need to know. 8. Identify users and authenticate access to system components. 9. Restrict physical access to cardholder data. Regularly Monitor and Test Networks: 10. Log and monitor all access to system components and cardholder data. 11. Test security of systems and networks regularly. Maintain an Information Security Policy: 12. Support information security with organizational policies and programs.`,
category: "PCI DSS",
lastUpdated: new Date(),
metadata: { standard: "PCI DSS", version: "4.0" },
},
{
id: "pci-dss-requirements",
source: "Compliance",
title: "PCI DSS 4.0 Key Requirements",
url: "https://www.pcisecuritystandards.org/",
content: `PCI DSS 4.0 key requirements and changes from v3.2.1. New in 4.0: Customized approach allows meeting security objectives through alternative controls. Targeted risk analysis replaces some prescriptive requirements. Enhanced authentication requirements including MFA for all access to CDE. Requirement 3 - Protect Stored Account Data: Primary account numbers (PAN) must be rendered unreadable using encryption, truncation, tokenization, or hashing. Sensitive authentication data must not be stored after authorization. Requirement 4 - Cryptography: Use strong cryptography (TLS 1.2+) for transmission over open networks. Requirement 6 - Secure Development: Secure coding practices, code review, vulnerability testing. SAST and DAST for custom applications. Address vulnerabilities per risk ranking. Requirement 8 - Authentication: MFA for all access into the cardholder data environment. Passwords minimum 12 characters (or 8 with additional complexity). No shared accounts. Requirement 10 - Logging: Log all access to cardholder data. Retain logs for at least 12 months. Requirement 11 - Testing: Quarterly vulnerability scans, annual penetration testing.`,
category: "PCI DSS",
lastUpdated: new Date(),
metadata: { standard: "PCI DSS", version: "4.0", type: "Requirements" },
},
{
id: "pci-dss-scope",
source: "Compliance",
title: "PCI DSS Scoping and Segmentation",
url: "https://www.pcisecuritystandards.org/",
content: `PCI DSS scoping determines which systems must comply with the standard. Cardholder Data Environment (CDE): All systems that store, process, or transmit cardholder data, plus all systems connected to CDE. In-scope systems: Systems directly handling cardholder data (POS terminals, payment applications, databases). Systems providing security services to CDE (authentication servers, firewalls, IDS). Systems that can impact CDE security (system administration workstations). Network Segmentation: Not required but strongly recommended to reduce scope. Proper segmentation isolates CDE from other networks. Must be verified through penetration testing. Segmentation controls must be tested at least annually. Scope reduction techniques: Network segmentation using firewalls. Tokenization to replace PAN with non-sensitive values. Point-to-Point Encryption (P2PE) validated solutions. Outsourcing to PCI-compliant service providers. Cloud considerations: Shared responsibility model applies. Understand which controls cloud provider handles. Validate cloud provider's PCI DSS compliance.`,
category: "PCI DSS",
lastUpdated: new Date(),
metadata: { standard: "PCI DSS", type: "Scoping" },
},
];
}
private getHIPAA(): SecurityDocument[] {
return [
{
id: "hipaa-security-rule",
source: "Compliance",
title: "HIPAA Security Rule Overview",
url: "https://www.hhs.gov/hipaa/for-professionals/security/index.html",
content: `HIPAA Security Rule establishes national standards to protect electronic protected health information (ePHI). Applies to covered entities (healthcare providers, health plans, clearinghouses) and business associates. Three types of safeguards required: Administrative Safeguards: Security management process including risk analysis and risk management. Assigned security responsibility. Workforce security and training. Information access management. Security incident procedures. Contingency planning. Physical Safeguards: Facility access controls. Workstation use and security. Device and media controls. Technical Safeguards: Access controls including unique user identification, emergency access, automatic logoff, encryption. Audit controls for recording and examining activity. Integrity controls to protect ePHI from improper alteration. Transmission security including encryption. Key principles: Ensure confidentiality, integrity, and availability of ePHI. Protect against reasonably anticipated threats. Protect against impermissible uses or disclosures. Ensure workforce compliance.`,
category: "HIPAA",
lastUpdated: new Date(),
metadata: { standard: "HIPAA", rule: "Security" },
},
{
id: "hipaa-technical-safeguards",
source: "Compliance",
title: "HIPAA Technical Safeguards",
url: "https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html",
content: `HIPAA Technical Safeguards protect ePHI through technology. Access Control (Required): Unique User Identification - assign unique name/number to track user identity. Emergency Access Procedure - procedures for obtaining ePHI during emergencies. Automatic Logoff - terminate sessions after inactivity. Encryption and Decryption - encrypt ePHI (addressable but strongly recommended). Audit Controls (Required): Implement mechanisms to record and examine access and activity in systems containing ePHI. Include user identification, date/time, actions performed. Integrity (Required): Mechanisms to ensure ePHI is not improperly altered or destroyed. Electronic mechanisms to corroborate ePHI integrity. Person or Entity Authentication (Required): Verify identity of persons or entities seeking access to ePHI. Use multi-factor authentication for remote access. Transmission Security (Required): Integrity Controls - ensure ePHI is not modified during transmission. Encryption - encrypt ePHI transmitted over open networks. Implementation specifications marked as "addressable" require documented decision if not implemented.`,
category: "HIPAA",
lastUpdated: new Date(),
metadata: { standard: "HIPAA", type: "Technical Safeguards" },
},
{
id: "hipaa-breach-notification",
source: "Compliance",
title: "HIPAA Breach Notification Requirements",
url: "https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html",
content: `HIPAA Breach Notification Rule requires notification following breach of unsecured PHI. Breach definition: Acquisition, access, use, or disclosure of PHI in a manner not permitted by Privacy Rule that compromises security or privacy. Unsecured PHI: PHI not rendered unusable, unreadable, or indecipherable through encryption or destruction. Notification Requirements: Individual Notice - notify affected individuals within 60 days of discovery. Written notification by first-class mail or email if individual agreed. Must include description of breach, types of information involved, steps to protect from harm, what entity is doing to investigate and mitigate, contact information. Media Notice - if breach affects more than 500 residents of a state, notify prominent media outlets. HHS Secretary Notice - notify HHS Secretary. Breaches affecting 500+ individuals reported within 60 days. Smaller breaches may be reported annually. Risk Assessment: Perform risk assessment to determine if breach notification required. Consider nature and extent of PHI, unauthorized person, whether PHI actually acquired or viewed, mitigation. Penalties: Civil penalties up to $1.5M per violation category per year. Criminal penalties for willful neglect.`,
category: "HIPAA",
lastUpdated: new Date(),
metadata: { standard: "HIPAA", rule: "Breach Notification" },
},
];
}
private getISO27001(): SecurityDocument[] {
return [
{
id: "iso-27001-overview",
source: "Compliance",
title: "ISO 27001:2022 Information Security Management System",
url: "https://www.iso.org/standard/27001",
content: `ISO 27001:2022 specifies requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). Key components: Context of the Organization - understand organization and stakeholder needs, determine ISMS scope. Leadership - top management commitment, establish security policy, assign roles and responsibilities. Planning - risk assessment and treatment, security objectives, planning changes. Support - resources, competence, awareness, communication, documented information. Operation - operational planning and control, risk assessment execution, risk treatment implementation. Performance Evaluation - monitoring, measurement, analysis, internal audit, management review. Improvement - nonconformity and corrective action, continual improvement. Plan-Do-Check-Act cycle drives continual improvement. Certification requires: Implementation of ISMS meeting standard requirements. Internal audit program. Management review. External audit by accredited certification body. Annual surveillance audits. Recertification every three years.`,
category: "ISO 27001",
lastUpdated: new Date(),
metadata: { standard: "ISO 27001", version: "2022" },
},
{
id: "iso-27002-controls",
source: "Compliance",
title: "ISO 27002:2022 Security Controls",
url: "https://www.iso.org/standard/27002",
content: `ISO 27002:2022 provides reference set of information security controls. Four control themes with 93 controls: Organizational Controls (37 controls): Policies for information security. Information security roles and responsibilities. Segregation of duties. Management responsibilities. Contact with authorities and special interest groups. Threat intelligence. Information security in project management. Inventory of information and assets. Acceptable use of assets. Classification and labeling. People Controls (8 controls): Screening. Terms and conditions of employment. Information security awareness, education, and training. Disciplinary process. Responsibilities after termination. Confidentiality agreements. Remote working. Physical Controls (14 controls): Physical security perimeters. Physical entry controls. Securing offices, rooms, and facilities. Physical security monitoring. Protection against physical and environmental threats. Secure disposal or reuse of equipment. Technological Controls (34 controls): User endpoint devices. Privileged access rights. Information access restriction. Secure authentication. Malware protection. Management of technical vulnerabilities. Configuration management. Data masking and encryption.`,
category: "ISO 27002",
lastUpdated: new Date(),
metadata: { standard: "ISO 27002", version: "2022" },
},
{
id: "iso-27001-risk-assessment",
source: "Compliance",
title: "ISO 27001 Risk Assessment Process",
url: "https://www.iso.org/standard/27001",
content: `ISO 27001 Risk Assessment is fundamental to ISMS implementation. Risk Assessment Process: 1. Establish risk assessment methodology - define criteria for risk acceptance, assessment approach, and evaluation criteria. 2. Identify risks - identify assets, threats, vulnerabilities, and potential impacts. Consider confidentiality, integrity, and availability. 3. Analyze risks - determine likelihood and impact of risk scenarios. Calculate risk level using chosen methodology. 4. Evaluate risks - compare risk analysis results against risk criteria. Prioritize risks for treatment. 5. Document results - maintain documented information of risk assessment process and results. Risk Treatment Options: Modify risk - implement controls to reduce likelihood or impact. Retain risk - accept risk within risk acceptance criteria. Avoid risk - eliminate activity causing risk. Share risk - transfer risk to third party (insurance, outsourcing). Statement of Applicability (SoA): Document control objectives and controls selected from ISO 27002. Justify inclusion or exclusion of each control. Reference to risk treatment plan. Risk treatment plan documents how selected controls will be implemented.`,
category: "ISO 27001",
lastUpdated: new Date(),
metadata: { standard: "ISO 27001", type: "Risk Assessment" },
},
];
}
private getSOC2(): SecurityDocument[] {
return [
{
id: "soc2-overview",
source: "Compliance",
title: "SOC 2 Trust Services Criteria",
url: "https://www.aicpa.org/soc",
content: `SOC 2 (System and Organization Controls 2) reports on controls relevant to security, availability, processing integrity, confidentiality, and privacy. Trust Services Criteria: Security (Common Criteria) - required for all SOC 2 reports. Protection against unauthorized access. Includes: CC1 Control Environment, CC2 Communication and Information, CC3 Risk Assessment, CC4 Monitoring Activities, CC5 Control Activities, CC6 Logical and Physical Access, CC7 System Operations, CC8 Change Management, CC9 Risk Mitigation. Availability - system is available for operation and use. Processing Integrity - system processing is complete, valid, accurate, timely, and authorized. Confidentiality - information designated as confidential is protected. Privacy - personal information is collected, used, retained, disclosed, and disposed of properly. Report Types: Type I - describes controls at a point in time. Type II - describes controls and tests effectiveness over a period (typically 6-12 months). SOC 2 reports are restricted use - shared only with specified parties under NDA.`,
category: "SOC 2",
lastUpdated: new Date(),
metadata: { standard: "SOC 2" },
},
{
id: "soc2-common-criteria",
source: "Compliance",
title: "SOC 2 Common Criteria (Security)",
url: "https://www.aicpa.org/soc",
content: `SOC 2 Common Criteria form the security baseline required for all SOC 2 reports. CC1 Control Environment: Demonstrate commitment to integrity and ethical values. Board exercises oversight responsibility. Management establishes structure, authority, accountability. Commitment to competence. Enforce accountability. CC2 Communication and Information: Use relevant quality information. Communicate internally about controls. Communicate externally with appropriate parties. CC3 Risk Assessment: Specify suitable objectives. Identify and analyze risks. Assess fraud risk. Identify and analyze significant changes. CC4 Monitoring Activities: Select, develop, and perform ongoing and/or separate evaluations. Evaluate and communicate deficiencies. CC5 Control Activities: Select and develop control activities. Select and develop general controls over technology. Deploy through policies and procedures. CC6 Logical and Physical Access Controls: Implement logical and physical access security software. User registration and authorization. Authentication mechanisms. Access removal. CC7 System Operations: Detect and monitor security events. CC8 Change Management: Manage system changes. CC9 Risk Mitigation: Identify, select, and develop mitigation activities. Deploy countermeasures.`,
category: "SOC 2",
lastUpdated: new Date(),
metadata: { standard: "SOC 2", type: "Common Criteria" },
},
];
}
private getGDPR(): SecurityDocument[] {
return [
{
id: "gdpr-overview",
source: "Compliance",
title: "GDPR Data Protection Principles",
url: "https://gdpr.eu/",
content: `General Data Protection Regulation (GDPR) protects personal data of EU residents. Seven Data Protection Principles: 1. Lawfulness, Fairness, Transparency - process data lawfully, fairly, and transparently. Legal bases: consent, contract, legal obligation, vital interests, public task, legitimate interests. 2. Purpose Limitation - collect data for specified, explicit, legitimate purposes only. 3. Data Minimization - collect only data adequate, relevant, and necessary for purposes. 4. Accuracy - keep personal data accurate and up to date. 5. Storage Limitation - keep data only as long as necessary for purposes. 6. Integrity and Confidentiality - process data securely, protect against unauthorized processing, accidental loss, destruction, or damage. 7. Accountability - demonstrate compliance with principles. Data Subject Rights: Right to be informed. Right of access. Right to rectification. Right to erasure (right to be forgotten). Right to restrict processing. Right to data portability. Right to object. Rights related to automated decision making. Organizations must respond to requests within one month.`,
category: "GDPR",
lastUpdated: new Date(),
metadata: { standard: "GDPR" },
},
{
id: "gdpr-security-requirements",
source: "Compliance",
title: "GDPR Security Requirements (Article 32)",
url: "https://gdpr.eu/article-32-security-of-processing/",
content: `GDPR Article 32 requires appropriate technical and organizational security measures. Security measures should consider: State of the art technology. Cost of implementation. Nature, scope, context, and purposes of processing. Risks to data subjects' rights and freedoms. Required measures include as appropriate: Pseudonymization and encryption of personal data. Ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems. Ability to restore availability and access to personal data in timely manner following incident. Regular testing, assessing, and evaluating effectiveness of security measures. Data Protection Impact Assessment (DPIA): Required for high-risk processing (profiling, large-scale processing of special categories, systematic monitoring). Assess necessity, proportionality, risks, and measures to address risks. Data Breach Notification: Notify supervisory authority within 72 hours of becoming aware (when risk to data subjects). Notify affected individuals without undue delay (when high risk). Document all breaches regardless of notification requirement. Penalties: Up to 20 million EUR or 4% of global annual revenue, whichever is higher.`,
category: "GDPR",
lastUpdated: new Date(),
metadata: { standard: "GDPR", article: "32" },
},
];
}
}
