import { DocumentSource, SecurityDocument } from "../types.js";
export class SANSSource implements DocumentSource {
name = "SANS";
async fetchDocuments(): Promise<SecurityDocument[]> {
const documents: SecurityDocument[] = [];
try {
console.error("Fetching SANS/CWE documents...");
// CWE Top 25
documents.push({
id: "cwe-top-25-2023",
source: "SANS",
title: "CWE Top 25 Most Dangerous Software Weaknesses (2023)",
url: "https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html",
content: `The 2023 CWE Top 25 Most Dangerous Software Weaknesses list includes critical vulnerabilities that commonly lead to serious security issues. Top weaknesses include: CWE-787 Out-of-bounds Write - writing data past the end or before the beginning of buffer. CWE-79 Cross-site Scripting (XSS) - improper neutralization of input during web page generation. CWE-89 SQL Injection - improper neutralization of SQL commands. CWE-416 Use After Free - referencing memory after it has been freed. CWE-78 OS Command Injection - improper neutralization of special elements in OS commands. CWE-20 Improper Input Validation - product doesn't validate input properly. CWE-125 Out-of-bounds Read - reading data past buffer boundaries. CWE-22 Path Traversal - improper limitation of pathname to restricted directory. CWE-352 CSRF - web application doesn't verify request origin. CWE-434 Unrestricted Upload of Dangerous File Type. These weaknesses are scored based on prevalence and severity in real-world applications.`,
category: "Vulnerabilities",
lastUpdated: new Date(),
metadata: { year: 2023, type: "CWE Top 25" },
});
// SANS Critical Security Controls
documents.push({
id: "sans-cis-controls-v8",
source: "SANS",
title: "CIS Critical Security Controls v8",
url: "https://www.cisecurity.org/controls",
content: `CIS Controls v8 provides prioritized set of actions to protect organizations from known cyber attack vectors. The 18 controls are organized into three Implementation Groups (IG1, IG2, IG3) based on organization size and resources. Controls include: 1. Inventory and Control of Enterprise Assets - actively manage all enterprise assets. 2. Inventory and Control of Software Assets - manage software inventory. 3. Data Protection - protect data according to sensitivity. 4. Secure Configuration of Enterprise Assets and Software - establish and maintain secure configurations. 5. Account Management - use processes and tools to track user accounts. 6. Access Control Management - use authentication and authorization based on need-to-know. 7. Continuous Vulnerability Management - develop process to continuously identify and remediate vulnerabilities. 8. Audit Log Management - collect and analyze audit logs. 9. Email and Web Browser Protections. 10. Malware Defenses. 11. Data Recovery. 12. Network Infrastructure Management. 13. Network Monitoring and Defense. 14. Security Awareness and Skills Training. 15. Service Provider Management. 16. Application Software Security. 17. Incident Response Management. 18. Penetration Testing. Each control includes safeguards mapped to asset types and security functions.`,
category: "Security Controls",
lastUpdated: new Date(),
metadata: { framework: "CIS Controls", version: "8" },
});
// Common vulnerability categories
documents.push({
id: "sans-common-vulnerabilities",
source: "SANS",
title: "SANS Common Vulnerability Categories",
url: "https://www.sans.org/top25-software-errors/",
content: `Common vulnerability categories from SANS research include: Insecure Interaction Between Components - vulnerabilities allowing attackers to control interactions between system components, including SQL Injection, OS Command Injection, CSRF. Risky Resource Management - improper handling of memory and resources leading to buffer overflows, use-after-free, integer overflows, memory leaks. Porous Defenses - inadequate security controls including missing authentication, broken access control, insufficient encryption, improper certificate validation, using hard-coded credentials. Each category represents systemic weaknesses that attackers commonly exploit. Mitigation requires secure coding practices, security testing, code review, and defense in depth. Organizations should implement input validation, output encoding, parameterized queries, secure memory management, proper authentication and authorization, and encryption for sensitive data.`,
category: "Vulnerabilities",
lastUpdated: new Date(),
metadata: { source: "SANS Institute" },
});
// Security Architecture Principles
documents.push({
id: "sans-security-architecture",
source: "SANS",
title: "SANS Security Architecture Principles",
url: "https://www.sans.org/",
content: `SANS Security Architecture Principles provide foundation for secure system design. Key principles include: Defense in Depth - implement multiple layers of security controls. Least Privilege - grant minimum necessary access rights. Separation of Duties - divide critical functions among different people. Fail Secure - ensure systems fail to secure state, not open state. Security by Design - integrate security from the beginning, not as afterthought. Complete Mediation - check every access to every object. Open Design - security shouldn't depend on secrecy of design. Least Common Mechanism - minimize shared mechanisms to reduce attack surface. Psychological Acceptability - security mechanisms should be user-friendly to ensure compliance. Work Factor - make attack cost exceed value to attacker. Compromise Recording - log security events for detection and forensics. Economy of Mechanism - keep design simple to reduce vulnerabilities. These principles guide secure architecture across all technology domains.`,
category: "Security Architecture",
lastUpdated: new Date(),
metadata: { type: "Principles" },
});
// Incident Response
documents.push({
id: "sans-incident-response",
source: "SANS",
title: "SANS Incident Response Process",
url: "https://www.sans.org/incident-response/",
content: `SANS Incident Response Process consists of six phases: 1. Preparation - establish IR capability, train team, define procedures, acquire tools. 2. Identification - detect and determine whether incident occurred, assess scope and severity. 3. Containment - limit damage, isolate affected systems, preserve evidence. Short-term containment provides immediate protection, long-term containment includes system patching and temporary fixes. 4. Eradication - remove threat from environment, identify and remediate root cause, improve defenses. 5. Recovery - restore systems to normal operations, validate systems are functioning properly, monitor for signs of persistence. 6. Lessons Learned - document incident, conduct post-mortem analysis, update procedures, improve security posture. Continuous improvement through feedback loop. Key activities include maintaining chain of custody for evidence, documenting all actions, communicating with stakeholders, and coordinating with law enforcement when necessary.`,
category: "Incident Response",
lastUpdated: new Date(),
metadata: { framework: "SANS IR" },
});
// Penetration Testing
documents.push({
id: "sans-penetration-testing",
source: "SANS",
title: "SANS Penetration Testing Methodology",
url: "https://www.sans.org/penetration-testing/",
content: `SANS Penetration Testing methodology provides structured approach to security assessment. Phases include: 1. Planning and Reconnaissance - define scope, gather intelligence using OSINT, identify targets. 2. Scanning and Enumeration - perform network scanning, port scanning, service enumeration, vulnerability scanning. 3. Gaining Access - exploit vulnerabilities, attempt authentication bypasses, social engineering. 4. Maintaining Access - install backdoors, establish persistent access, escalate privileges. 5. Analysis and Reporting - analyze findings, document vulnerabilities with evidence, provide remediation recommendations, create executive summary and technical report. Testing types include: Network Penetration Testing, Web Application Testing, Wireless Security Testing, Social Engineering, Physical Security Testing, Red Team Exercises. Rules of Engagement must be clearly defined including scope, timing, testing methods, communication protocols, and legal authorization. Follow responsible disclosure practices.`,
category: "Security Testing",
lastUpdated: new Date(),
metadata: { type: "Methodology" },
});
// Supply Chain Security
documents.push({
id: "supply-chain-security",
source: "SANS",
title: "Software Supply Chain Security",
url: "https://slsa.dev/",
content: `Software Supply Chain Security protects the integrity of software from source to deployment. Key frameworks and practices: SLSA (Supply-chain Levels for Software Artifacts) - framework for ensuring software artifact integrity. Four levels: Level 1 (documentation), Level 2 (hosted build), Level 3 (hardened builds), Level 4 (two-person review). SBOM (Software Bill of Materials) - inventory of software components. Formats include SPDX, CycloneDX. Required for federal software procurement. Key practices: Sign code and artifacts using Sigstore, GPG, or code signing certificates. Verify dependencies using lock files and hash verification. Use private package repositories. Implement dependency scanning for vulnerabilities. Pin dependencies to specific versions. Verify provenance of artifacts. Implement hermetic builds. Use reproducible builds. Threats: Typosquatting attacks on package names. Dependency confusion (private vs public packages). Compromised maintainer accounts. Build system compromises. Malicious packages. CI/CD pipeline attacks. Mitigations: Implement SLSA requirements, scan dependencies, use signed packages, maintain SBOM.`,
category: "Supply Chain Security",
lastUpdated: new Date(),
metadata: { type: "Supply Chain" },
});
// Container Security Best Practices
documents.push({
id: "container-security-practices",
source: "SANS",
title: "Container Security Best Practices",
url: "https://www.sans.org/",
content: `Container Security Best Practices for Docker and Kubernetes environments. Image Security: Use minimal base images (distroless, Alpine). Scan images for vulnerabilities in CI/CD. Don't run as root - use non-root users. Don't include secrets in images. Use multi-stage builds to minimize attack surface. Sign and verify images. Use trusted base images from official sources. Update images regularly. Runtime Security: Run containers with read-only filesystems. Drop unnecessary Linux capabilities. Use seccomp and AppArmor profiles. Implement resource limits (CPU, memory). Don't use privileged mode. Use network policies to restrict traffic. Implement pod security standards. Kubernetes Security: Enable RBAC with least privilege. Use network policies for microsegmentation. Enable audit logging. Secure etcd with encryption. Use admission controllers (OPA/Gatekeeper). Enable pod security admission. Secrets management with external stores. Regular cluster upgrades. Registry Security: Use private registries. Implement access controls. Enable vulnerability scanning. Implement image signing and verification.`,
category: "Container Security",
lastUpdated: new Date(),
metadata: { type: "Container Security" },
});
// Kubernetes Security
documents.push({
id: "kubernetes-security-guide",
source: "SANS",
title: "Kubernetes Security Hardening Guide",
url: "https://www.sans.org/",
content: `Kubernetes Security Hardening based on NSA/CISA guidance. Control Plane Security: Enable TLS for all components. Use strong authentication (OIDC, certificates). Enable audit logging. Encrypt etcd at rest. Restrict access to API server. Use admission controllers. Workload Security: Use Pod Security Standards (Restricted, Baseline, Privileged). Don't run privileged containers. Use read-only root filesystems. Drop all capabilities, add only required. Set resource limits. Use security contexts. Network Security: Implement network policies - deny all by default. Use service mesh for mTLS. Segregate sensitive workloads. Use ingress controllers with WAF. Monitor network traffic. Authentication and Authorization: Enable RBAC. Use namespaces for multi-tenancy. Implement least privilege. Use service accounts per workload. Don't use default service accounts. Secrets Management: Don't store secrets in ConfigMaps. Use external secrets stores (Vault, cloud KMS). Enable encryption at rest. Rotate secrets regularly. Supply Chain: Scan images in CI/CD. Use admission controllers to enforce policies. Verify image signatures. Maintain SBOM.`,
category: "Container Security",
lastUpdated: new Date(),
metadata: { type: "Kubernetes Security" },
});
console.error(`Fetched ${documents.length} SANS/CWE documents`);
} catch (error) {
console.error("Error fetching SANS documents:", error);
}
return documents;
}
}
