Security Policy

1. Our Security Commitment

At CloudSigma, security is foundational to everything we build. As a platform that helps security teams generate detection rules from threat intelligence, we hold ourselves to the highest standards of security practice. We recognise that our customers trust us with their threat intelligence data and rely on the integrity of the detection rules we generate.

This Security Policy describes the technical and organisational measures we implement to protect your data, ensure service integrity, and maintain the trustworthiness of our platform. We are committed to continuous improvement and regularly review and update our security practices in response to the evolving threat landscape.

2. Infrastructure Security

2.1 Cloud Infrastructure

CloudSigma is hosted on Amazon Web Services (AWS) in the eu-west-2 (London) region. We leverage AWS's security capabilities and compliance certifications, including:

• AWS infrastructure is certified under ISO 27001, SOC 2 Type II, and other industry standards
• Compute workloads run on AWS Lambda (serverless) with automatic patching and isolation
• Static assets served via Amazon CloudFront CDN with AWS Web Application Firewall (WAF) protection
• Infrastructure defined as code using AWS CDK, enabling consistent, auditable, and repeatable deployments

2.2 Network Security

• All external traffic is encrypted in transit using TLS 1.2 or higher
• API endpoints are served through Amazon API Gateway with throttling and rate limiting
• Internal service-to-service communication uses AWS IAM-based authentication and VPC networking
• DNS is managed via Amazon Route 53 with DNSSEC support
• DDoS protection provided by AWS Shield and CloudFront

2.3 Database Security

• Data at rest is encrypted using AES-256 encryption via AWS Key Management Service (KMS)
• Database access is restricted to application-level IAM roles with least-privilege policies
• No direct database access from the public internet; all access is through application-layer APIs
• Automated backups with point-in-time recovery capability

3. Application Security

3.1 Secure Development Lifecycle

• All code changes go through peer review via pull requests before merging
• Automated CI/CD pipeline with linting, type checking, and test execution on every commit
• Dependency vulnerability scanning to identify and remediate known vulnerabilities in third-party packages
• Separation of staging and production environments with independent deployment pipelines

3.2 Authentication and Authorisation

• User authentication managed by AWS Cognito with secure token handling
• JWT-based session management with short-lived access tokens and secure refresh token rotation
• API endpoints protected by Cognito authoriser—unauthenticated requests are rejected before reaching application code
• Role-based access controls for team-tier accounts with per-user permission scoping

3.3 API Security

• API Gateway throttling and rate limiting to prevent abuse and ensure fair resource allocation
• Request validation and input sanitisation at the API layer
• CORS policy restricting API access to authorised origins
• Content Security Policy (CSP) headers to prevent cross-site scripting and code injection in the web application

3.4 SSRF Protection

CloudSigma's URL ingestion feature includes robust Server-Side Request Forgery (SSRF) protection:

• Two-phase validation: hostname string check followed by DNS resolution check to defeat DNS rebinding attacks
• Blocks access to private/reserved IP ranges, localhost, link-local addresses, and non-HTTP protocols
• Response body size cap (5MB) to prevent resource exhaustion
• Only HTTP and HTTPS protocols are permitted for URL ingestion

4. AI/LLM Security

CloudSigma uses third-party large language model APIs for AI-powered TTP extraction and Sigma rule generation. We implement a multi-layered defence-in-depth approach to protect our AI processing pipeline against prompt injection, data exfiltration, and output manipulation attacks.

4.1 Input Normalisation (Layer 0)

• All user inputs undergo Unicode NFC normalisation to prevent homoglyph attacks
• Zero-width characters and invisible Unicode code points are stripped
• HTML content is processed through a visible-text extractor, removing script tags, hidden elements, and injected markup
• Whitespace is collapsed and normalised to prevent obfuscation techniques

4.2 Tripwire Scanning (Layer 1)

• Hard-block patterns detect and reject inputs containing LLM delimiter sequences, system prompt override phrases, and common injection payloads
• Base64 evasion detection identifies encoded injection attempts
• Soft-flag patterns identify suspicious inputs that may warrant additional scrutiny without hard rejection

4.3 Prompt Boundary Enforcement (Layer 2)

• Per-call cryptographic nonces wrap user-supplied content in API calls, creating verifiable boundaries between trusted instructions and untrusted input
• Preamble and reminder messages in user-message blocks reinforce the model's task boundaries
• System prompts remain unchanged to preserve prompt caching benefits

4.4 Output Validation (Layer 3 — Primary Defence)

This is our primary defence against AI manipulation. Even if an injection bypasses earlier layers, output validation ensures the generated content meets strict structural and semantic requirements:

• Source quote verification: extracted quotes are verified against the original input to detect fabricated evidence
• Technique ID whitelisting: only known MITRE ATT&CK technique IDs are accepted (102 cloud-relevant techniques)
• API call validation: detection logic fields are checked against known cloud provider API schemas
• Detection block consistency: generated Sigma rule detection blocks are validated for structural integrity
• String sanitisation: all string outputs are sanitised to prevent downstream injection

4.5 Resource Controls (Layer 4)

• Token budget: cumulative per-request token tracking with hard abort at configured limits to prevent resource exhaustion from adversarial inputs
• Audit logging: structured JSON audit events logged for all AI processing operations, including flagged inputs, rejected outputs, and token consumption

4.6 Sigma Rule Validation

All generated Sigma rules undergo automated validation through the pySigma framework:

• Syntactic validation ensures rules conform to the Sigma specification
• Field path validation checks detection fields against known cloud provider log schemas
• Rules that fail validation trigger an automated retry with corrective feedback to the LLM
• Persistent validation warnings are attached as metadata to inform security analysts

5. Data Protection

5.1 Encryption

• In transit: all data transmitted between your browser and CloudSigma is encrypted using TLS 1.2 or higher. API calls to third-party services also use TLS encryption.
• At rest: all stored data is encrypted using AES-256 encryption managed by AWS Key Management Service (KMS). Encryption keys are rotated automatically.

5.2 Data Retention and Deletion

• Threat intelligence inputs are cached temporarily (up to 24 hours) for performance and are not retained long-term
• Generated rules are retained for the duration of the customer's account
• Account data is deleted within 30 days of account closure
• Audit and security logs are retained for 12 months
• IOC-based rules include expiry metadata (default 90 days) to encourage regular review

5.3 Data Isolation

Customer data is logically isolated at the application layer. Each customer's threat intelligence inputs, generated rules, and pipeline results are associated with their authenticated account and are not accessible to other customers.

6. Access Controls

• Principle of least privilege: internal access to production systems is restricted to the minimum necessary for each role
• IAM policies: AWS IAM roles and policies enforce fine-grained access control for all service components
• Multi-factor authentication: required for all administrative access to production infrastructure
• Access reviews: regular reviews of access permissions to ensure compliance with least-privilege principles
• Audit trails: all administrative actions on production infrastructure are logged via AWS CloudTrail

7. Incident Response

We maintain a documented incident response plan that covers identification, containment, eradication, recovery, and lessons learned. Our incident response process includes:

• Detection: automated monitoring and alerting for security events, anomalous behaviour, and service disruptions
• Classification: incidents are classified by severity (Critical, High, Medium, Low) with corresponding response timelines
• Notification: affected customers will be notified of confirmed data breaches within 72 hours, in accordance with UK GDPR requirements
• Post-incident review: all significant incidents undergo a blameless post-mortem to identify root causes and implement preventive measures

8. Business Continuity

• Serverless architecture: CloudSigma's core pipeline runs on AWS Lambda, providing automatic scaling, redundancy, and fault isolation without single points of failure
• Data durability: data stored in AWS services benefits from built-in replication and durability guarantees (e.g., S3 99.999999999% durability)
• Automated deployments: infrastructure-as-code via AWS CDK enables rapid recovery and consistent environment recreation
• Monitoring: comprehensive monitoring via Amazon CloudWatch with automated alerting for service health, error rates, and performance degradation
• Disaster recovery: recovery procedures are documented and tested to ensure service restoration within defined recovery time objectives

9. Third-Party Security

We carefully evaluate the security posture of all third-party services integrated with CloudSigma:

• AI Processing Provider: used for AI-powered TTP extraction and rule generation. Our AI provider does not use API inputs for model training. Data is processed under a data processing agreement with appropriate security commitments.
• Amazon Web Services: our infrastructure provider, certified under ISO 27001, SOC 2 Type II, and numerous other compliance frameworks.
• Payment processor: PCI DSS-compliant payment processing. CloudSigma does not store full payment card details.

Third-party integrations are reviewed periodically to ensure continued compliance with our security requirements. We maintain data processing agreements with all sub-processors that handle personal data.

10. Questions and Contact

If you have questions about our security practices, wish to report a vulnerability, or need additional information for your security assessment, please contact our security team:

This Security Policy is reviewed and updated regularly. For the most current version, please visit this page. We also encourage you to review our Privacy Policy and Terms of Service for additional information about how we protect your data and the terms governing your use of CloudSigma.