Security & Trust
Security practices for NeuroStrike and guidance for reporting vulnerabilities.
This document outlines security practices for NeuroStrike and provides guidance for reporting vulnerabilities.
Responsible Disclosure
Reporting Vulnerabilities
If you discover a security vulnerability in NeuroStrike, please report it responsibly:
Email: security@neurostrike.com
Please include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Any proof-of-concept code (if applicable)
What to Expect
- Acknowledgment: We will acknowledge receipt within 24 hours
- Assessment: We will assess the vulnerability within 72 hours
- Updates: We will keep you informed of our progress
- Resolution: We aim to resolve critical issues within 7 days
- Credit: With your permission, we will credit you in our security advisories
Scope
In scope:
- NeuroStrike web application
- API endpoints
- Authentication systems
- Data storage and handling
Out of scope:
- Third-party services (unless vulnerability is in our integration)
- Social engineering attacks
- Physical security
- Denial of service attacks
Security Practices
Secure Development
- Code Review: All code changes require review
- Dependency Management: Regular updates, automated vulnerability scanning
- Testing: Unit tests for security-critical functions
Vulnerability Management
| Level | Description | Response Time |
|---|---|---|
| Critical | Remote code execution, auth bypass | 24 hours |
| High | Data exposure, privilege escalation | 72 hours |
| Medium | Limited data exposure, XSS | 7 days |
| Low | Information disclosure | 30 days |
Authentication & Authorization
Authentication Methods
- Email and password (bcrypt hashing), followed by a one-time email verification code
- Two-factor authentication (TOTP authenticator apps)
- Enterprise single sign-on (SAML 2.0) with SCIM user provisioning
- OAuth 2.0 (Google, Discord)
- Session-based authentication
Authorization
| Role | Permissions |
|---|---|
| Owner | Full access, delete organization |
| Admin | Manage members, settings, all scans |
| Member | Create scans, view findings |
| Viewer | Read-only access |
Rules of engagement & scope control
Every assessment runs under an explicit, auditable authorization — testing can only do what the customer has signed off on.
For cloud Strikes, a target must pass an ownership check (DNS, file, meta tag, or IP ownership) before it can be tested, production targets must be explicitly enabled, and out-of-scope domains can be excluded. The on-prem agent adds the engagement controls below:
- Signed rules of engagement. Each engagement is defined by a rules-of-engagement file that fixes the in-scope hosts and networks, any hard exclusions, and the data-retention term. It carries an authorization hash the customer countersigns before testing begins.
- Tool-class ceiling. A configurable ceiling bounds how intrusive testing may get — read-only, low-impact active, intrusive active, or exploit. Anything above the agreed ceiling is refused and recorded, so a routine assessment can never run an exploit-class action.
- Scope enforcement. Targets outside the authorized scope are refused — enforced independently of the AI, which can narrow its own authority but never widen it.
- EEA-only mode. An engagement can be confined to the EEA, refusing any processing path that would leave it.
- OT / ICS safety. For industrial estates, per-zone postures (observation-only or fully excluded) and controller-class protection prevent active probing of fragile equipment.
- Tamper-evident audit and certified purge. Every action is written to a tamper-evident audit record, and customer data is destroyed on a certified schedule — or on demand — at the end of the engagement.
See the On-Prem Agent guide for how engagements are defined and run.
Data Protection
Data Residency
- All production data is stored in Norway (EEA) at an ISO 27001-certified facility
- The database and scan engine are reachable only over a private, encrypted network — never the public internet
Data at Rest
- Sensitive fields encrypted with AES-256-GCM (field-level encryption)
- API keys stored as SHA-256 hashes
- Daily encrypted database backups with an off-site copy and tested restores
Data in Transit
- All public connections use HTTPS (TLS 1.2 or later) with HSTS
- Internal traffic (database, cache, scan engine) is confined to a private, encrypted network and never traverses the public internet
What's Encrypted
- Target authentication headers
- Target authentication cookies
- Webhook secrets
Infrastructure Security
Production is self-hosted on Eltele AS infrastructure in Norway (EEA). Only the edge is reachable from the internet; the database, cache, and scan engine sit on a private, encrypted network with no public ports. The architecture follows an "assume-breach" model that limits the blast radius of any single compromised host or credential.
| Component | Security |
|---|---|
| Hosting (Eltele AS, Norway) | ISO 27001 / 9001 / 14001 certified; EEA data residency; operator-owned fiber |
| Public edge (reverse proxy + TLS) | TLS 1.2+ / Let's Encrypt; HSTS; strict CSP; administrative access restricted to Norway |
| Database (self-hosted PostgreSQL) | Private network only; AES-256-GCM field encryption; least-privilege roles; encrypted + off-site backups |
| Scan / job engine (self-hosted) | Isolated per-run execution; no public ports |
| Stripe (Billing) | PCI DSS compliant |
Certification note: ISO 27001 above refers to the hosting provider (Eltele). NeuroStrike maintains an internal SOC 2 control mapping and is working toward its own certification.
Secure Usage Guidelines
For Administrators
- Use strong passwords (minimum 12 characters)
- Enable two-factor authentication for every account
- Review access regularly - remove inactive members
- Monitor API key usage - rotate unused keys
For Security Testing
- Only scan targets you own or have written permission to test
- Verify target ownership before scanning
- Do not test against production systems you don't control
Compliance
Supported Standards
- OWASP Top 10: Findings mapped to OWASP categories
- CWE: Findings include CWE identifiers
- CVSS: Severity scoring using CVSS v3.1
GDPR Considerations
- Only processes data necessary for service
- User consent for scanning
- Data deletion on request
- Built-in GDPR impact analysis tool
Security Headers
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: default-src 'self'; ...Contact
Security Team: security@neurostrike.com
We recognize and thank security researchers who report vulnerabilities responsibly.