Security Standards & Methodology ​
How the Finaisse / Blitz security posture is defined, scored, and maintained. For current status see the Security Dashboard; for the worklist see the Findings register.
Target state: Enterprise SaaS Financial Platform Security Baseline — a defense-in-depth posture that can survive enterprise customer security reviews, SOC 2 / ISO 27001 audits, and 300-question security questionnaires.
Owner: Sekhar Prakash (Security & Infrastructure). Review cadence: quarterly and on major architecture change.
Scope & asset criticality ​
| Factor | Assessment |
|---|---|
| Business criticality | Very High |
| Internet exposure | High |
| Data sensitivity | High (customer financial data) |
| Regulatory expectations | SOC 2 (target) · India DPDP · ISO 27001 likely · customer audits |
| Attack surface | Large (multi-service API, file uploads, email ingestion, AI agents, admin portal) |
| Multi-tenant risk | High |
| Supply-chain risk | High |
| Cloud misconfiguration risk | High |
| Insider-threat risk | Medium |
| Availability requirement | High |
Open scoping decisions: see Open Decisions below.
Open decisions (owner input needed) ​
These are choices only the security/infra owner (Sekhar Prakash) can make — distinct from the engineering work in the findings register. Each gates or shapes a tracked item but needs a cost / vendor / scope call first. Listed here so they don't stay buried inside issue bodies.
| Decision | Why it's a decision (not just work) | Gates / relates to |
|---|---|---|
| SAST tooling — GitHub Advanced Security (CodeQL) vs OSS Semgrep | GHAS is paid on private repos; Semgrep is free but self-run. Cost vs. convenience. | SAST lens (coverage); fin-infra#40 |
| Secret scanning / push protection — GHAS native vs OSS gitleaks | Same GHAS cost question; gitleaks (already run ad-hoc) is free in CI. | fin-infra#40; F-34/F-35 |
| Penetration-test vendor, budget & timing | Which firm, what scope, and the go-live gate date — a procurement decision. | fin-infra#39 (F-24) |
| SSO / SAML provider for enterprise tenants | Tool/vendor choice (Okta / Entra / WorkOS / etc.). | Domain 4; blitz#1007 (F-23) |
| Compliance target & timeline | Confirm SOC 2 as the formal audit target and target date (ISO 27001? DPDP baseline scope?). | Domain 15 |
| PCI-DSS in / out of scope | Determines whether card-data controls apply at all. | Scope |
| AWS production go-live date & hard gate | Sets the deadline the AWS gate must be met by. | Go-live |
Resolve these at each posture review; record the decision (and date) here when made, then the related issue becomes pure engineering work.
Data classification ​
| Class | Examples | Baseline handling |
|---|---|---|
| Public | Marketing content, public docs | No restriction |
| Internal | Product documentation, runbooks | Authenticated access |
| Confidential | Customer configuration, tenant metadata | Encrypted, access-controlled, audited |
| Restricted | Financial transactions, journals, invoices, reconciliations, PII | Encrypt at rest + in transit, strict least-privilege, full audit trail, tenant-isolated, retention/deletion policy |
Data lifecycle to govern for each class: creation → processing → storage → archival → deletion.
Security principles ​
- Zero Trust by default
- Defense in depth
- Least-privilege access
- Secure by design
- Immutable auditability
- Tenant isolation
- Continuous verification
- Automated security controls
- Rapid detection & response
- Data-centric security
Risk-prioritization rubric & remediation SLAs ​
Severity is impact × reachability, weighted for a financial multi-tenant platform. Each finding is scored across: exposure · data sensitivity · exploitability · blast radius / lateral movement · financial-fraud impact · regulatory impact · runtime context (prod/staging/dev) · attack surface · detection/response coverage · compensating controls · remediation speed.
A high-priority issue is one that is internet-facing, exploitable, hits Restricted data or the tenant boundary, and is already deployed.
| Severity | Definition | SLA |
|---|---|---|
| P0 | Exploitable now, hits Restricted data or the cross-tenant boundary, low effort | ≤ 7 days; actively exploited → immediate |
| P1 | High impact with a precondition, or on the AWS go-live path | ≤ 30 days |
| P2 | Real weakness, limited reach or strong compensating control | ≤ 90 days |
How this posture is maintained ​
- Standards (this section) reviewed each quarter and on major architecture change.
- Findings register (/security/findings) is the live worklist; every finding is a GitHub issue carrying the
securitylabel + the SLA above, tracked on the Finboard project. - Maturity ratings (dashboard + domains) are re-scored each review from the open findings.
- Control implementations live as code in
blitz,blitz-ui,fin-infra; this site links to them rather than duplicating. - Methodology note: iteration 1 (2026-06-24) is a read-only code review, not a penetration test. Findings tagged needs runtime confirmation must be validated dynamically before closure; independent external validation is itself a tracked gap (fin-infra#39).