diff --git a/docs/README.md b/docs/README.md index c435764..c86712a 100644 --- a/docs/README.md +++ b/docs/README.md @@ -19,6 +19,24 @@ Welcome to the Tender Management System documentation. This directory contains a ### πŸ“‘ API Documentation - **[examples/API_EXAMPLES.md](./examples/API_EXAMPLES.md)** - API usage examples and endpoints documentation +### πŸ”’ Security & Compliance (ISMS) +- **[security/ISMS_FOUNDATION.md](./security/ISMS_FOUNDATION.md)** - ISMS scope, asset inventory, roles, and control baseline +- **[security/RISK_ASSESSMENT_MATRIX.md](./security/RISK_ASSESSMENT_MATRIX.md)** - Initial risk register and treatment plans +- **[security/ISO27001_ROADMAP.md](./security/ISO27001_ROADMAP.md)** - ISO/IEC 27001 certification roadmap and phases +- **[security/GAP_ANALYSIS_REPORT.md](./security/GAP_ANALYSIS_REPORT.md)** - ISO 27001 Clauses 4–10 and Annex A gap analysis +- **[security/STATEMENT_OF_APPLICABILITY.md](./security/STATEMENT_OF_APPLICABILITY.md)** - Annex A control applicability (93 controls) +- **[security/ISMS_SCOPE_APPROVAL.md](./security/ISMS_SCOPE_APPROVAL.md)** - Formal ISMS scope sign-off (Clause 4.3) + +#### Policies (Phase 1) +- **[security/policies/information-security-policy.md](./security/policies/information-security-policy.md)** - Top-level ISMS policy (A.5.1) +- **[security/policies/access-control-policy.md](./security/policies/access-control-policy.md)** - Authentication, RBAC, access reviews (A.5.15–A.5.18) +- **[security/policies/incident-response-plan.md](./security/policies/incident-response-plan.md)** - Incident classification, IRT, playbooks (A.5.24–A.5.28) +- **[security/policies/backup-and-recovery-policy.md](./security/policies/backup-and-recovery-policy.md)** - RTO/RPO, backup schedule, restore testing (A.8.13) +- **[security/policies/acceptable-use-policy.md](./security/policies/acceptable-use-policy.md)** - Personnel acceptable use rules (A.6.2) + +#### Procedures +- **[security/procedures/risk-assessment-procedure.md](./security/procedures/risk-assessment-procedure.md)** - Risk identification, analysis, and treatment (Clause 6.1.2) + ## πŸ—οΈ Project Architecture ### Clean Architecture Layers diff --git a/docs/security/GAP_ANALYSIS_REPORT.md b/docs/security/GAP_ANALYSIS_REPORT.md new file mode 100644 index 0000000..e273ad1 --- /dev/null +++ b/docs/security/GAP_ANALYSIS_REPORT.md @@ -0,0 +1,282 @@ +# ISO/IEC 27001 Gap Analysis Report β€” Tender Management System + +| Field | Value | +|-------|-------| +| **Document ID** | ISMS-004 | +| **Version** | 1.0 | +| **Status** | Draft β€” Pending review | +| **Owner** | Information Security Officer (ISO) | +| **Last Updated** | 2026-06-11 | +| **Assessment Date** | 2026-06-11 | +| **Standard** | ISO/IEC 27001:2022 | +| **Scope** | [ISMS Foundation Β§3](./ISMS_FOUNDATION.md#3-isms-scope) | + +Related: [Statement of Applicability](./STATEMENT_OF_APPLICABILITY.md) | [ISO 27001 Roadmap](./ISO27001_ROADMAP.md) + +--- + +## 1. Executive Summary + +This report assesses the current state of the Tender Management (TM) ISMS against **ISO/IEC 27001:2022** mandatory clauses (4–10) and Annex A controls. The assessment is based on documentation review, codebase analysis, and existing operational practices. + +### Overall Maturity + +| Area | Maturity | Summary | +|------|----------|---------| +| **Clauses 4–6** (Context, Leadership, Planning) | 🟑 Partial | Foundation docs exist; formal leadership approval pending | +| **Clause 7** (Support) | 🟑 Partial | Competence and awareness programs not yet formalized | +| **Clause 8** (Operation) | 🟑 Partial | Technical controls strong; operational procedures incomplete | +| **Clause 9** (Performance evaluation) | πŸ”΄ Minimal | No internal audit program or management review yet | +| **Clause 10** (Improvement) | πŸ”΄ Minimal | Corrective action process not formalized | +| **Annex A** (93 controls) | 🟑 Partial | 6 implemented (7% of 81 applicable), 56 partial (69%), 19 not implemented (23%), 12 N/A (13%) β€” per [SoA Β§7](./STATEMENT_OF_APPLICABILITY.md#7-summary-statistics) | + +### Key Strengths + +- Application-layer security controls (JWT, RBAC, validation, XSS, audit logging) +- Clean Architecture with dependency injection and structured logging +- Initial ISMS documentation suite (foundation, risk matrix, policies) +- Configurable rate limiting and environment-based secret management + +### Critical Gaps (Must Address Before Certification) + +1. No internal audit program or management review records (Clauses 9.2, 9.3) +2. No SIEM/centralized monitoring (A.8.16) +3. No formal vulnerability management in CI (A.8.8) +4. Secrets in repository / no vault (A.8.9, R-013) +5. No security awareness training program (A.6.3) +6. No vendor security assessments (A.5.19–A.5.22) +7. Encryption at rest not confirmed (A.8.24) +8. Executive sign-off on ISMS scope and policies pending + +--- + +## 2. Assessment Methodology + +| Step | Activity | +|------|----------| +| 1 | Review ISMS scope and asset inventory | +| 2 | Map existing controls to ISO 27001:2022 clauses and Annex A | +| 3 | Interview technical leads (informal / codebase-based) | +| 4 | Classify each requirement: **Implemented**, **Partial**, **Not Implemented**, **N/A** | +| 5 | Prioritize gaps by risk linkage ([Risk Assessment Matrix](./RISK_ASSESSMENT_MATRIX.md)) | +| 6 | Define remediation actions in [ISO27001_ROADMAP.md](./ISO27001_ROADMAP.md) Phase 2 | + +### Maturity Scale + +| Rating | Definition | +|--------|------------| +| **Implemented** | Control documented, implemented, and operating effectively | +| **Partial** | Control exists informally or is incomplete | +| **Not Implemented** | No control or documentation | +| **N/A** | Not applicable to TM scope (with justification) | + +--- + +## 3. Clause 4 β€” Context of the Organization + +| Ref | Requirement | Status | Evidence | Gap / Remediation | +|-----|-------------|--------|----------|-------------------| +| 4.1 | Understanding the organization and its context | **Partial** | [ISMS Foundation Β§2](./ISMS_FOUNDATION.md#2-organizational-context) | Formalize interested parties register | +| 4.2 | Understanding needs of interested parties | **Partial** | Business objectives in ISMS Foundation | Document customers, regulators, partners explicitly | +| 4.3 | Determining ISMS scope | **Partial** | [ISMS Foundation Β§3](./ISMS_FOUNDATION.md#3-isms-scope); [Scope Approval](./ISMS_SCOPE_APPROVAL.md) draft | Executive sign-off required | +| 4.4 | Information security management system | **Partial** | ISMS doc structure defined | Complete PDCA operating records | + +**Gap actions:** +- Create interested parties register (customers, EU DPA, certification body, cloud providers) +- Obtain signed scope approval from Executive Sponsor + +--- + +## 4. Clause 5 β€” Leadership + +| Ref | Requirement | Status | Evidence | Gap / Remediation | +|-----|-------------|--------|----------|-------------------| +| 5.1 | Leadership and commitment | **Partial** | Roadmap exists; sponsor not yet assigned | Appoint Executive Sponsor; first management review | +| 5.2 | Policy | **Partial** | [Information Security Policy](./policies/information-security-policy.md) draft | Approve and communicate policy | +| 5.3 | Organizational roles, responsibilities, authorities | **Partial** | [ISMS Foundation Β§5](./ISMS_FOUNDATION.md#5-roles-and-responsibilities) | Assign named individuals to ISO, DPO roles | + +**Gap actions:** +- Name and document ISO and DPO (can be interim) +- Communicate approved Information Security Policy to all staff + +--- + +## 5. Clause 6 β€” Planning + +| Ref | Requirement | Status | Evidence | Gap / Remediation | +|-----|-------------|--------|----------|-------------------| +| 6.1.1 | Actions to address risks and opportunities | **Partial** | Risk matrix with 23 risks | Link opportunities (e.g. certification as market differentiator) | +| 6.1.2 | Information security risk assessment | **Implemented** | [Risk Assessment Matrix](./RISK_ASSESSMENT_MATRIX.md), [Procedure](./procedures/risk-assessment-procedure.md) | Maintain quarterly reviews | +| 6.1.3 | Information security risk treatment | **Partial** | Treatment plans in risk matrix | Execute Phase 2 technical remediations | +| 6.2 | Information security objectives | **Partial** | [Information Security Policy Β§4](./policies/information-security-policy.md#4-information-security-objectives) | Track KPIs monthly | +| 6.3 | Planning of changes | **Not Implemented** | β€” | Document change planning in change management procedure (Phase 2) | + +**Gap actions:** +- Begin executing risk treatment plans (R-001, R-010, R-013, R-015, R-023 priority) +- Draft change management procedure + +--- + +## 6. Clause 7 β€” Support + +| Ref | Requirement | Status | Evidence | Gap / Remediation | +|-----|-------------|--------|----------|-------------------| +| 7.1 | Resources | **Partial** | Roadmap resource estimate | Allocate part-time ISO capacity | +| 7.2 | Competence | **Not Implemented** | β€” | Define security competency requirements per role | +| 7.3 | Awareness | **Not Implemented** | Acceptable Use Policy draft | Launch onboarding + annual training | +| 7.4 | Communication | **Partial** | Docs in `docs/security/` | Define internal/external comms plan for ISMS | +| 7.5 | Documented information | **Partial** | ISMS doc suite | Document control procedure; version approval workflow | + +**Gap actions:** +- Security awareness program (A.6.3) β€” target Q3 2026 +- Document control: naming, approval, retention standards + +--- + +## 7. Clause 8 β€” Operation + +| Ref | Requirement | Status | Evidence | Gap / Remediation | +|-----|-------------|--------|----------|-------------------| +| 8.1 | Operational planning and control | **Partial** | DevOps practices informal | Formalize change and deploy procedures | +| 8.2 | Information security risk assessment | **Implemented** | Quarterly procedure defined | Execute first scheduled review Sep 2026 | +| 8.3 | Information security risk treatment | **Partial** | Phase 2 roadmap | Implement prioritized controls | + +**Gap actions:** +- Operational procedures for backup, incident response (drafted β€” need testing records) +- Change management procedure (Phase 2) + +--- + +## 8. Clause 9 β€” Performance Evaluation + +| Ref | Requirement | Status | Evidence | Gap / Remediation | +|-----|-------------|--------|----------|-------------------| +| 9.1 | Monitoring, measurement, analysis, evaluation | **Partial** | KPIs defined in roadmap | Implement SIEM; monthly KPI reporting | +| 9.2 | Internal audit | **Not Implemented** | β€” | Schedule first internal audit Q1 2027 | +| 9.3 | Management review | **Not Implemented** | β€” | First review within 90 days of scope approval | + +**Gap actions:** +- **Critical:** Establish internal audit program before Stage 2 audit +- Schedule first management review meeting +- Implement monitoring (A.8.16) for measurable KPIs + +--- + +## 9. Clause 10 β€” Improvement + +| Ref | Requirement | Status | Evidence | Gap / Remediation | +|-----|-------------|--------|----------|-------------------| +| 10.1 | Continual improvement | **Partial** | PDCA in roadmap | Track improvement actions from audits/incidents | +| 10.2 | Nonconformity and corrective action | **Not Implemented** | β€” | Define CAPA (Corrective and Preventive Action) procedure | + +**Gap actions:** +- CAPA procedure linked to incident response and audit findings +- Nonconformity register template + +--- + +## 10. Annex A Summary by Theme + +Full control-level detail: [Statement of Applicability](./STATEMENT_OF_APPLICABILITY.md) + +| Theme | Total Controls | Implemented | Partial | Not Impl. | N/A | +|-------|----------------|-------------|---------|-----------|-----| +| **A.5** Organizational | 37 | 2 | 25 | 10 | 0 | +| **A.6** People | 8 | 0 | 6 | 2 | 0 | +| **A.7** Physical | 14 | 0 | 3 | 0 | 11 | +| **A.8** Technological | 34 | 4 | 22 | 7 | 1 | +| **Total** | **93** | **6** | **56** | **19** | **12** | + +*Counts match [Statement of Applicability Β§7.1](./STATEMENT_OF_APPLICABILITY.md#71-by-theme). "Partial" indicates the control exists but lacks full documentation, testing, or operating evidence.* + +### A.5 β€” Top Organizational Gaps + +| Control | Title | Status | Priority | +|---------|-------|--------|----------| +| A.5.19–A.5.22 | Supplier relationships | Not Implemented | High | +| A.5.29–A.5.30 | Business continuity | Partial | High | +| A.5.35 | Independent review | Not Implemented | Medium | +| A.5.7 | Threat intelligence | Not Implemented | Medium | +| A.5.32 | Intellectual property | Partial | Low | + +### A.6 β€” Top People Gaps + +| Control | Title | Status | Priority | +|---------|-------|--------|----------| +| A.6.3 | Security awareness training | Not Implemented | High | +| A.6.1 | Screening | Not Implemented | Medium | +| A.6.6 | NDAs | Partial | Medium | +| A.6.8 | Event reporting | Partial | Medium | + +### A.7 β€” Physical Controls + +**11 N/A** β€” cloud-hosted infrastructure; physical security transferred to cloud provider per shared responsibility model (A.7.1–A.7.6, A.7.8, A.7.10–A.7.13). Provider compliance evidence required (A.5.23). + +**3 Partial** β€” A.7.7, A.7.9, A.7.14 remain applicable for personnel devices accessing TM systems (screen lock, off-premises asset security, equipment disposal). + +### A.8 β€” Top Technological Gaps + +| Control | Title | Status | Priority | +|---------|-------|--------|----------| +| A.8.8 | Vulnerability management | Not Implemented | Critical | +| A.8.16 | Monitoring activities | Partial | Critical | +| A.8.24 | Cryptography | Partial | High | +| A.8.2 | Privileged access rights | Partial | High | +| A.8.32 | Change management | Partial | High | +| A.8.29 | Security testing | Not Implemented | High | +| A.8.12 | Data leakage prevention | Not Implemented | Medium | + +### A.8 β€” Fully Implemented Technical Controls (Status = Yes) + +| Control | Implementation | +|---------|----------------| +| A.8.3 | RBAC + company-scoped middleware (`pkg/authorization`) | +| A.8.4 | Git-based source control with PR workflow | +| A.8.15 | Structured logging + `pkg/audit` | +| A.8.26 | Govalidator, XSS policy, Swagger | + +Additional controls (e.g. A.8.5 authentication, A.8.9 configuration, A.8.28 secure coding) are **Partial** in the SoA β€” implemented in code but lacking full operating evidence or completeness (MFA, vault, SAST). + +--- + +## 11. Gap Remediation Roadmap + +Aligned with [ISO27001_ROADMAP.md](./ISO27001_ROADMAP.md): + +| Priority | Gap | Remediation | Phase | Target | +|----------|-----|-------------|-------|--------| +| P0 | No incident response testing | Tabletop exercise | 2 | Q2 2026 | +| P0 | Secrets in repo | Vault + secret scanning | 2 | Q2 2026 | +| P0 | No vulnerability scanning | govulncheck in CI | 2 | Q2 2026 | +| P0 | No management review | First review meeting | 1 | Q3 2026 | +| P1 | No SIEM | Centralized logging + alerts | 2 | Q3 2026 | +| P1 | No encryption at rest | MongoDB/MinIO encryption | 2 | Q3 2026 | +| P1 | No vendor assessments | Vendor questionnaire | 2 | Q4 2026 | +| P1 | No security training | Awareness program | 2 | Q3 2026 | +| P1 | No internal audit | Audit program + first audit | 3 | Q1 2027 | +| P2 | No CAPA procedure | Document CAPA process | 2 | Q3 2026 | +| P2 | No penetration test | External pentest | 4 | Q2 2027 | + +--- + +## 12. Conclusion + +The TM platform has a **solid technical security foundation** but lacks the **operational and governance evidence** required for ISO 27001 certification. Phase 1 documentation (foundation, risk assessment, policies, SoA, gap analysis) addresses Clauses 4.3, 6.1.2, and 5.2 at a draft level. + +**Recommendation:** Proceed to Phase 2 control implementation while pursuing executive approval of scope and policies. Target first internal audit no later than **Q1 2027** to allow 3+ months of operating evidence before Stage 2 audit. + +--- + +## 13. Document Control + +| Version | Date | Author | Changes | +|---------|------|--------|---------| +| 1.0 | 2026-06-11 | Engineering | Initial gap analysis | +| 1.1 | 2026-06-11 | Engineering | Annex A theme table and executive summary aligned with SoA Β§7 | + +**Review** + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| ISO | _Pending_ | | | +| Executive Sponsor | _Pending_ | | | diff --git a/docs/security/ISMS_FOUNDATION.md b/docs/security/ISMS_FOUNDATION.md new file mode 100644 index 0000000..6f654df --- /dev/null +++ b/docs/security/ISMS_FOUNDATION.md @@ -0,0 +1,235 @@ +# ISMS Foundation β€” Tender Management System + +| Field | Value | +|-------|-------| +| **Document ID** | ISMS-001 | +| **Version** | 1.0 | +| **Status** | Draft β€” Initial foundation | +| **Owner** | Information Security Officer (ISO) | +| **Last Updated** | 2026-06-11 | +| **Review Cycle** | Annual (or after major architecture change) | + +--- + +## 1. Purpose + +This document establishes the **Information Security Management System (ISMS)** foundation for the Tender Management (TM) platform. It defines security scope, information assets, roles, and the baseline control environment required to support ISO/IEC 27001 certification and GDPR-aligned data protection. + +Related documents: + +- [ISO 27001 Roadmap](./ISO27001_ROADMAP.md) +- [Risk Assessment Matrix](./RISK_ASSESSMENT_MATRIX.md) +- [Gap Analysis Report](./GAP_ANALYSIS_REPORT.md) +- [Statement of Applicability](./STATEMENT_OF_APPLICABILITY.md) +- [ISMS Scope Approval](./ISMS_SCOPE_APPROVAL.md) + +--- + +## 2. Organizational Context + +### 2.1 System Overview + +The Tender Management System is a Go-based backend API that: + +- Ingests public tender data from TED (Tenders Electronic Daily) and related sources +- Matches tenders to registered companies based on CPV codes, categories, and keywords +- Provides admin panel APIs for user, company, and tender management +- Provides public/mobile APIs for company customers to browse, filter, and interact with tenders +- Sends notifications (email, push via FCM) and supports AI-assisted translation/summarization +- Stores documents and tender artifacts in MinIO object storage + +### 2.2 Business Objectives Relevant to Security + +| Objective | Security Implication | +|-----------|---------------------| +| Reliable tender data for business decisions | Integrity and availability of tender records | +| Company and customer onboarding | Protection of PII and business credentials | +| Multi-tenant company access | Strong authentication, authorization, and data isolation | +| Regulatory and procurement compliance | Audit trails, data retention, and access control | +| Platform availability for mobile and admin clients | Resilience, monitoring, and incident response | + +--- + +## 3. ISMS Scope + +### 3.1 In Scope + +| Layer | Components | +|-------|------------| +| **Applications** | `cmd/web` (HTTP API), `cmd/worker` (background jobs), `cmd/scraper` (TED XML ingestion) | +| **Domain services** | User, customer, company, tender, feedback, notification, inquiry, contact, CMS, kanban, dashboard, document scraper, tender approval | +| **Shared packages** | Authorization (JWT), security (XSS/CSP), audit logging, file store, MinIO client, config | +| **Data stores** | MongoDB (primary DB), Redis (cache/sessions/token blacklist), MinIO (files, tender JSON/translations) | +| **External integrations** | Notification service, hCaptcha, AI summarizer/translation service, GoRules (kanban), TED public data sources, FCM (push) | +| **Environments** | Development, staging, production (and associated CI/CD pipelines) | +| **People & processes** | Developers, DevOps, QA, product owners with access to TM infrastructure or production data | + +### 3.2 Out of Scope (Initial Phase) + +| Item | Rationale | +|------|-----------| +| End-user mobile app codebase | Separate repository; interface governed by API contracts | +| Admin panel frontend | Separate repository; authenticated via same backend | +| Third-party TED infrastructure | Public data source; risk managed via ingestion validation | +| Customer on-premise deployments | SaaS model assumed; revisit if offering self-hosted | + +### 3.3 Scope Statement + +> The ISMS covers the design, development, deployment, and operation of the Tender Management backend platform, including all information assets processed, stored, or transmitted by `cmd/web`, `cmd/worker`, and `cmd/scraper`, and the supporting MongoDB, Redis, and MinIO infrastructure in scoped environments. + +--- + +## 4. Information Asset Inventory + +### 4.1 Classification Levels + +| Level | Label | Description | Handling | +|-------|-------|-------------|----------| +| **C1** | Public | Intended for public disclosure | No restrictions | +| **C2** | Internal | Operational data not for public release | Access limited to staff | +| **C3** | Confidential | Business or personal data requiring protection | Encrypted in transit; access on need-to-know | +| **C4** | Restricted | Credentials, secrets, authentication factors | Vault/KMS; never logged; rotation required | + +### 4.2 Asset Register + +| Asset ID | Asset Name | Type | Owner | Classification | Location | Notes | +|----------|------------|------|-------|----------------|----------|-------| +| A-001 | MongoDB database (`tm`) | Data store | DevOps / DBA | C3 | Managed MongoDB cluster | Companies, customers, tenders, users, feedback, notifications | +| A-002 | Redis cache | Data store | DevOps | C3 | Managed Redis | Sessions, rate limits, token blacklist | +| A-003 | MinIO object storage | Data store | DevOps | C2–C3 | MinIO cluster | Company documents, tender JSON, translations | +| A-004 | Customer PII | Data | Product / DPO | C3 | MongoDB `customers` | Email, name, phone, device tokens | +| A-005 | Company business data | Data | Product | C3 | MongoDB `companies` | Registration, tax ID, address, documents | +| A-006 | User (admin) accounts | Data | Product | C3 | MongoDB `users` | Admin panel operators | +| A-007 | Authentication credentials | Data | ISO | C4 | MongoDB (hashed passwords), env secrets | bcrypt-hashed passwords; JWT signing keys | +| A-008 | JWT access/refresh tokens | Data | ISO | C4 | Client devices, Redis blacklist | Short-lived access tokens | +| A-009 | Application source code | Software | Engineering | C2 | Git repository | Go monorepo `tm_back` | +| A-010 | Configuration & secrets | Config | DevOps | C4 | `.env`, OS env vars, secret manager | DB URIs, API keys, MinIO keys, hCaptcha secret | +| A-011 | Application logs | Data | DevOps | C2–C3 | Log files / log aggregator | Structured logs; must exclude passwords/tokens | +| A-012 | Audit logs | Data | ISO | C3 | Application log pipeline | Login, password reset, admin actions via `pkg/audit` | +| A-013 | TED tender data | Data | Product | C2 | MongoDB `tenders`, `notices` | Public procurement notices | +| A-014 | API endpoints | Service | Engineering | C2 | `cmd/web` Echo server | `/api/v1`, `/admin/v1` | +| A-015 | Worker & scraper jobs | Service | Engineering | C2 | `cmd/worker`, `cmd/scraper` | Scheduled ingestion and translation | +| A-016 | Notification service integration | Service | DevOps | C3 | External HTTP API | Email and messaging | +| A-017 | AI summarizer service | Service | DevOps | C3 | External HTTP API | Tender text sent for translation | +| A-018 | FCM credentials | Config | DevOps | C4 | `docs/fcm/` (must not be committed in prod) | Push notification keys | +| A-019 | Backup snapshots | Data | DevOps | C3 | Backup storage | MongoDB and MinIO backups | +| A-020 | CI/CD pipeline | Process | DevOps | C2 | GitHub / CI runner | Build, test, deploy automation | + +### 4.3 Data Flow Summary + +``` +[TED XML] β†’ Scraper β†’ MongoDB (tenders/notices) + ↓ +[Admin Panel / Mobile App] β†’ Web API β†’ MongoDB / Redis / MinIO + ↓ + Worker β†’ AI Service β†’ MinIO (translations) + ↓ + Notification Service β†’ Email / FCM +``` + +--- + +## 5. Roles and Responsibilities + +| Role | Responsibilities | +|------|------------------| +| **Executive Sponsor** | Approves ISMS budget, scope, and risk acceptance | +| **Information Security Officer (ISO)** | Owns ISMS, risk register, policies, audit coordination | +| **Data Protection Officer (DPO)** | GDPR/privacy compliance, DPIA, data subject requests | +| **Engineering Lead** | Secure SDLC, code review, dependency management | +| **DevOps Lead** | Infrastructure hardening, secrets, backups, monitoring | +| **Product Owner** | Data classification decisions, retention requirements | +| **All personnel** | Acceptable use, incident reporting, security training | + +*Note: One person may hold multiple roles in smaller teams; responsibilities must still be documented.* + +--- + +## 6. Current Security Control Baseline + +Controls already implemented in the codebase (to be formalized and verified): + +| Control Area | Implementation | ISO 27001 Annex A Reference | +|--------------|----------------|----------------------------| +| Authentication | JWT access/refresh tokens (`pkg/authorization`) | A.8.5 | +| Authorization | Role-based and company-scoped middleware | A.8.3 | +| Input validation | Govalidator on all API forms | A.8.26 | +| XSS prevention | Bluemonday HTML sanitization (`pkg/security`) | A.8.26 | +| Password storage | bcrypt hashing (customer/user services) | A.8.5 | +| Bot protection | hCaptcha integration | A.8.6 | +| Structured logging | Service-layer logging with context fields | A.8.15 | +| Audit events | `pkg/audit` for security-relevant actions | A.8.15 | +| Config secrets | OS env overrides `.env` (`pkg/config`) | A.8.9 | +| Rate limiting | Configurable rate limit (`RateLimitConfig`) | A.8.6 | +| API documentation | Swagger/OpenAPI (`cmd/web/docs`) | A.8.32 | +| File storage | MinIO with access control via file store service | A.8.11 | + +### 6.1 Known Gaps (To Address in Roadmap) + +- Formal written policies (access control, incident response, backup, change management) +- Documented vulnerability management and penetration testing schedule +- Centralized secrets management (vault) instead of flat env files +- SIEM/alerting for security events +- Formal data retention and deletion procedures +- Business continuity and disaster recovery testing +- Security awareness training records +- Supplier security assessments for AI and notification services + +--- + +## 7. Legal and Regulatory Requirements + +| Requirement | Applicability | ISMS Response | +|-------------|---------------|---------------| +| **GDPR** | EU customer/company PII | Lawful basis documentation, DPIA, DSR process, encryption in transit | +| **ISO/IEC 27001** | Certification target | This ISMS foundation and roadmap | +| **Procurement data licensing** | TED public data terms | Source attribution, ingestion compliance review | + +--- + +## 8. ISMS Documentation Structure + +``` +docs/security/ +β”œβ”€β”€ ISMS_FOUNDATION.md ← This document +β”œβ”€β”€ ISO27001_ROADMAP.md ← Certification phases and timeline +β”œβ”€β”€ RISK_ASSESSMENT_MATRIX.md ← Initial risk register +β”œβ”€β”€ GAP_ANALYSIS_REPORT.md ← Clause 4–10 gap analysis +β”œβ”€β”€ STATEMENT_OF_APPLICABILITY.md ← Annex A SoA (93 controls) +β”œβ”€β”€ ISMS_SCOPE_APPROVAL.md ← Scope sign-off (Clause 4.3) +β”œβ”€β”€ policies/ ← Phase 1 deliverables +β”‚ β”œβ”€β”€ information-security-policy.md +β”‚ β”œβ”€β”€ access-control-policy.md +β”‚ β”œβ”€β”€ incident-response-plan.md +β”‚ β”œβ”€β”€ backup-and-recovery-policy.md +β”‚ └── acceptable-use-policy.md +└── procedures/ + β”œβ”€β”€ risk-assessment-procedure.md + β”œβ”€β”€ change-management-procedure.md ← (Phase 2) + └── vendor-management-procedure.md ← (Phase 2) +``` + +--- + +## 9. Document Control + +| Version | Date | Author | Changes | +|---------|------|--------|---------| +| 1.0 | 2026-06-11 | Engineering | Initial ISMS foundation, scope, asset inventory | + +**Approval** + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| ISO | _Pending_ | | | +| Executive Sponsor | _Pending_ | | | + +--- + +## 10. Next Steps + +1. Review and approve this foundation document with executive sponsor +2. Complete initial risk assessment ([RISK_ASSESSMENT_MATRIX.md](./RISK_ASSESSMENT_MATRIX.md)) +3. Execute Phase 1 of the [ISO 27001 Roadmap](./ISO27001_ROADMAP.md) +4. Assign ISO/DPO roles (can be interim) +5. Schedule first management review within 90 days diff --git a/docs/security/ISMS_SCOPE_APPROVAL.md b/docs/security/ISMS_SCOPE_APPROVAL.md new file mode 100644 index 0000000..ebb5018 --- /dev/null +++ b/docs/security/ISMS_SCOPE_APPROVAL.md @@ -0,0 +1,168 @@ +# ISMS Scope Approval + +| Field | Value | +|-------|-------| +| **Document ID** | ISMS-006 | +| **Version** | 1.0 | +| **Status** | Pending signature | +| **Owner** | Executive Sponsor | +| **Prepared By** | Information Security Officer (ISO) | +| **Date Prepared** | 2026-06-11 | +| **ISO 27001 Reference** | Clause 4.3 β€” Determining the scope of the information security management system | + +Related: [ISMS Foundation](./ISMS_FOUNDATION.md) | [Gap Analysis Report](./GAP_ANALYSIS_REPORT.md) + +--- + +## 1. Purpose + +This document records formal management approval of the **Information Security Management System (ISMS) scope** for the Tender Management platform, as required by ISO/IEC 27001:2022 Clause 4.3. + +--- + +## 2. Organization + +| Field | Value | +|-------|-------| +| **Organization** | _[Company legal name]_ | +| **Product / Service** | Tender Management System (TM) | +| **Repository** | `tm_back` (Go backend API) | +| **Business Unit** | Engineering / Product | + +--- + +## 3. Approved ISMS Scope + +### 3.1 Scope Statement + +> The ISMS covers the design, development, deployment, and operation of the **Tender Management backend platform**, including all information assets processed, stored, or transmitted by the web API (`cmd/web`), background worker (`cmd/worker`), and TED scraper (`cmd/scraper`), together with supporting **MongoDB**, **Redis**, and **MinIO** infrastructure in development, staging, and production environments. + +### 3.2 In Scope + +| Category | Items | +|----------|-------| +| **Applications** | `cmd/web`, `cmd/worker`, `cmd/scraper` | +| **Domain services** | User, customer, company, tender, feedback, notification, inquiry, contact, CMS, kanban, dashboard, document scraper, tender approval | +| **Shared packages** | Authorization (JWT), security (XSS/CSP), audit logging, file store, MinIO client, configuration | +| **Data stores** | MongoDB (`tm` database), Redis, MinIO (`files`, `documents` buckets) | +| **External integrations** | Notification service, hCaptcha, AI summarizer/translation, GoRules, TED data sources, FCM push | +| **Environments** | Development, staging, production, CI/CD pipelines | +| **Personnel** | Developers, DevOps, QA, product owners with access to TM infrastructure or production data | +| **Locations** | Cloud-hosted infrastructure (provider TBD / per deployment); remote work for engineering staff | + +### 3.3 Explicitly Out of Scope + +| Item | Rationale | Interface Control | +|------|-----------|-----------------| +| Mobile application codebase | Separate repository and release cycle | API contract (`/api/v1`); JWT authentication | +| Admin panel frontend | Separate repository | API contract (`/admin/v1`); admin JWT + RBAC | +| TED / EU publication infrastructure | Third-party public data source | XML ingestion validation in scraper | +| Customer on-premise deployments | SaaS delivery model | N/A β€” revisit if product offering changes | +| End-user devices (phones, laptops) | Covered by Acceptable Use Policy, not ISMS technical scope | AUP acknowledgment | +| Physical data center facilities | Cloud shared responsibility model | Provider compliance evidence (A.5.23) | + +### 3.4 Boundaries and Interfaces + +``` +β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” +β”‚ APPROVED ISMS SCOPE β”‚ +β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ +β”‚ β”‚ cmd/web β”‚ β”‚cmd/workerβ”‚ β”‚cmd/scraperβ”‚ β”‚ +β”‚ β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”˜ β”‚ +β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ +β”‚ β–Ό β”‚ +β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ +β”‚ β”‚ MongoDB β”‚ Redis β”‚ MinIO β”‚ β”‚ +β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ +β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ + β”‚ API boundaries (out of scope beyond interface) + β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” + β–Ό β–Ό β–Ό β–Ό β–Ό + Mobile Admin Notification AI Service TED (public) + App Panel Service XML feed + (OOS) (OOS) (interface) (interface) (OOS) +``` + +**OOS** = Out of Scope (interface governed by contracts and vendor assessment) + +--- + +## 4. Interested Parties (Summary) + +| Party | Interest | ISMS Response | +|-------|----------|---------------| +| Company customers | PII protection, service availability | Access control, encryption, backup | +| EU data subjects | GDPR rights | DPO oversight, DSR process | +| Engineering team | Secure development environment | Policies, training, tooling | +| Executive management | Certification, risk management | This approval, management review | +| Cloud / SaaS providers | Shared security responsibility | A.5.23 cloud controls | +| Certification body | Conformity evidence | Audit program | + +--- + +## 5. Applicable Requirements + +| Requirement | Applicability | +|-------------|---------------| +| ISO/IEC 27001:2022 | Full ISMS certification target | +| GDPR (EU 2016/679) | Customer and company PII processing | +| TED data terms of use | Public procurement data ingestion | +| Customer contracts | Per agreement (security addenda as applicable) | + +--- + +## 6. Asset Summary Reference + +Full inventory: [ISMS Foundation Β§4](./ISMS_FOUNDATION.md#4-information-asset-inventory) β€” **20 assets** registered (A-001 through A-020). + +Key data categories in scope: + +- Customer PII (C3) +- Company business data (C3) +- Authentication credentials (C4) +- Tender/procurement data (C2) +- Application logs and audit records (C2–C3) + +--- + +## 7. Scope Change Process + +Changes to this scope require: + +1. Written justification (new service, architecture change, new data type) +2. Risk assessment per [Risk Assessment Procedure](./procedures/risk-assessment-procedure.md) +3. Update to [ISMS Foundation](./ISMS_FOUNDATION.md), [SoA](./STATEMENT_OF_APPLICABILITY.md), and this document +4. Re-approval by Executive Sponsor +5. Notification to certification body if already certified + +--- + +## 8. Approval + +By signing below, management confirms: + +1. The scope defined in Section 3 accurately reflects the boundaries of the TM ISMS +2. Resources will be made available to implement and maintain the ISMS per [ISO27001_ROADMAP.md](./ISO27001_ROADMAP.md) +3. Information security objectives in the [Information Security Policy](./policies/information-security-policy.md) are endorsed +4. An Information Security Officer will be designated (named or interim) + +--- + +### Signatures + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| **Executive Sponsor** | _________________________ | _________________________ | __________ | +| **Information Security Officer** | _________________________ | _________________________ | __________ | +| **Engineering Lead** | _________________________ | _________________________ | __________ | +| **DevOps Lead** | _________________________ | _________________________ | __________ | + +--- + +## 9. Document Control + +| Version | Date | Author | Changes | +|---------|------|--------|---------| +| 1.0 | 2026-06-11 | Engineering | Initial scope approval document | + +**Next review:** 2027-06-11 (annual) or upon material architecture change diff --git a/docs/security/ISO27001_ROADMAP.md b/docs/security/ISO27001_ROADMAP.md new file mode 100644 index 0000000..198ab94 --- /dev/null +++ b/docs/security/ISO27001_ROADMAP.md @@ -0,0 +1,313 @@ +# ISO/IEC 27001 Certification Roadmap β€” Tender Management System + +| Field | Value | +|-------|-------| +| **Document ID** | ISMS-003 | +| **Version** | 1.0 | +| **Status** | Active roadmap | +| **Owner** | Information Security Officer (ISO) | +| **Last Updated** | 2026-06-11 | +| **Target Certification** | ISO/IEC 27001:2022 | + +Related: [ISMS Foundation](./ISMS_FOUNDATION.md) | [Risk Assessment Matrix](./RISK_ASSESSMENT_MATRIX.md) + +--- + +## 1. Executive Summary + +This roadmap defines a phased path from the current informal security practices to a certifiable ISMS for the Tender Management backend platform. The plan spans approximately **12–18 months** from foundation to Stage 2 certification audit, assuming dedicated part-time security ownership (0.25–0.5 FTE). + +### Current State + +- Strong technical controls in application layer (JWT, RBAC, validation, XSS, audit logging) +- No formal ISMS documentation, policies, or certified processes +- Risk assessment and asset inventory now documented (initial versions) + +### Target State + +- Documented and operating ISMS aligned with ISO/IEC 27001:2022 +- Risk treatment plans executed for High and Critical risks +- Internal audit program and management review cycle established +- Successful Stage 1 and Stage 2 certification audits + +--- + +## 2. Certification Timeline Overview + +``` +Phase 0 ──► Phase 1 ──► Phase 2 ──► Phase 3 ──► Phase 4 ──► Phase 5 +Foundation Gap & Implement Operate Pre-Audit Certification +(Complete) Policies Controls ISMS Readiness Audit + β”‚ β”‚ β”‚ β”‚ β”‚ β”‚ + Jun 2026 Jul-Aug Sep-Nov Dec-Mar Apr-Jun Jul-Sep 2027 +``` + +| Phase | Name | Duration | Key Deliverable | +|-------|------|----------|-----------------| +| **0** | Foundation | 2 weeks | ISMS scope, asset inventory, risk matrix *(this release)* | +| **1** | Gap Analysis & Policies | 6–8 weeks | Policy suite, SoA draft, gap report | +| **2** | Control Implementation | 10–12 weeks | Technical and procedural controls | +| **3** | ISMS Operation | 12+ weeks | Internal audits, KPIs, management review | +| **4** | Pre-Audit Readiness | 4–6 weeks | Mock audit, evidence pack, corrective actions | +| **5** | Certification Audit | 4–8 weeks | Stage 1 + Stage 2 with accredited CB | + +--- + +## 3. Phase 0 β€” Foundation (Complete) + +**Status:** βœ… Complete as of 2026-06-11 + +| Task | Deliverable | Status | +|------|-------------|--------| +| Define ISMS scope | [ISMS_FOUNDATION.md Β§3](./ISMS_FOUNDATION.md#3-isms-scope) | βœ… | +| Create asset inventory | [ISMS_FOUNDATION.md Β§4](./ISMS_FOUNDATION.md#4-information-asset-inventory) | βœ… | +| Initial risk assessment | [RISK_ASSESSMENT_MATRIX.md](./RISK_ASSESSMENT_MATRIX.md) | βœ… | +| Assign interim ISO role | Pending management approval | ⬜ | +| Executive briefing on ISMS scope | Presentation / sign-off | ⬜ | + +--- + +## 4. Phase 1 β€” Gap Analysis & Policy Framework + +**Target:** Jul–Aug 2026 (6–8 weeks) + +### 4.1 Objectives + +- Map existing controls to ISO 27001:2022 Annex A +- Identify gaps and produce Statement of Applicability (SoA) +- Publish core ISMS policies + +### 4.2 Deliverables + +| # | Deliverable | ISO 27001 Reference | Owner | Status | +|---|-------------|---------------------|-------|--------| +| 1.1 | Gap analysis report | Clauses 4–10 | ISO | βœ… Draft | +| 1.2 | Statement of Applicability (SoA) | Annex A | ISO | βœ… Draft | +| 1.3 | Information Security Policy | A.5.1 | Executive Sponsor | βœ… Draft | +| 1.4 | Access Control Policy | A.5.15–A.5.18 | ISO | βœ… Draft | +| 1.5 | Incident Response Plan | A.5.24–A.5.28 | ISO | βœ… Draft | +| 1.6 | Backup & Recovery Policy | A.8.13 | DevOps | βœ… Draft | +| 1.7 | Acceptable Use Policy | A.6.2 | HR / ISO | βœ… Draft | +| 1.8 | Risk Assessment Procedure | Clause 6.1.2 | ISO | βœ… Draft | +| 1.9 | ISMS scope approval (signed) | Clause 4.3 | Executive Sponsor | βœ… Draft β€” pending signature | + +### 4.3 Annex A Gap Snapshot (Initial) + +Based on codebase review and [Risk Assessment Matrix](./RISK_ASSESSMENT_MATRIX.md): + +| Annex A Theme | Current Maturity | Gap Priority | +|---------------|------------------|--------------| +| A.5 Organizational controls | 2 Yes / 25 Partial / 10 No (of 37) | High | +| A.6 People controls | 0 Yes / 6 Partial / 2 No (of 8) | High | +| A.7 Physical controls | 11 N/A (cloud); 3 Partial (personnel devices) | Transfer to cloud provider | +| A.8 Technological controls | 4 Yes / 22 Partial / 7 No / 1 N/A (of 34) | Medium | + +*Per-theme counts: [SoA Β§7.1](./STATEMENT_OF_APPLICABILITY.md#71-by-theme).* + +**Controls with Status = Yes in SoA (fully evidenced):** + +| Control | Evidence in Codebase | +|---------|---------------------| +| A.5.9, A.5.12 | Asset inventory; information classification | +| A.8.3 Access restriction | RBAC + company-scoped middleware | +| A.8.4 Access to source code | Git repo with PR review | +| A.8.15 Logging | Structured service logging, `pkg/audit` | +| A.8.26 Application security requirements | Govalidator, XSS policy, Swagger | + +**Additional partial in-app controls** (e.g. A.8.5 authentication, A.8.9 configuration, A.8.6 rate limiting) are implemented in code but not yet fully evidenced in the SoA. + +**Priority gaps to close in Phase 2:** + +| Control | Gap | Planned Action | +|---------|-----|----------------| +| A.8.24 Cryptography | No documented crypto policy; at-rest encryption TBD | Encryption policy; MongoDB/MinIO at-rest | +| A.8.8 Vulnerability management | No formal scanning | CI: govulncheck, SAST, container scan | +| A.8.16 Monitoring | Logs only, no SIEM | Centralized logging + alerts | +| A.5.19–A.5.23 Supplier relationships | No vendor assessments | Vendor questionnaire for AI, notification | +| A.5.29–A.5.30 Business continuity | No DR plan | BCP/DRP with RTO/RPO | +| A.6.3 Security awareness | No training program | Annual training + onboarding module | + +--- + +## 5. Phase 2 β€” Control Implementation + +**Target:** Sep–Nov 2026 (10–12 weeks) + +### 5.1 Technical Controls + +| Priority | Control | Tasks | Risk IDs | Owner | +|----------|---------|-------|----------|-------| +| P0 | Secrets management | Migrate to vault; remove FCM keys from repo; rotate credentials | R-013 | DevOps | +| P0 | Auth hardening | Rate limit all auth endpoints; MFA for admin users | R-001, R-021 | Engineering | +| P0 | Vulnerability scanning | govulncheck + Dependabot in CI; monthly review | R-010 | Engineering | +| P1 | Encryption at rest | Enable MongoDB and MinIO encryption | R-005, R-006 | DevOps | +| P1 | Monitoring & alerting | Centralize logs; alert on auth failures, 5xx spikes | R-015 | DevOps | +| P1 | RBAC audit | Automated tests for all admin route authorization | R-003 | Engineering | +| P2 | WAF / CDN | DDoS protection for public API | R-012 | DevOps | +| P2 | File upload security | MIME validation, size limits, malware scan | R-011 | Engineering | +| P2 | Refresh token rotation | Complete token rotation implementation | R-002 | Engineering | + +### 5.2 Procedural Controls + +| Priority | Control | Tasks | Owner | +|----------|---------|-------|-------| +| P0 | Incident response | IR plan, on-call rotation, tabletop exercise | ISO | +| P0 | Change management | PR approval rules, prod deployment checklist | Engineering | +| P1 | Access reviews | Quarterly review of admin and infra access | ISO | +| P1 | Backup verification | Monthly restore test; documented RTO/RPO | DevOps | +| P1 | Vendor management | Security questionnaires for AI, notification, cloud | ISO | +| P2 | DSR process | GDPR data subject request workflow | DPO | + +--- + +## 6. Phase 3 β€” ISMS Operation + +**Target:** Dec 2026 – Mar 2027 (minimum 3 months operation required) + +### 6.1 Operating Activities + +| Activity | Frequency | Owner | ISO 27001 Reference | +|----------|-----------|-------|---------------------| +| Risk register review | Quarterly | ISO | 6.1.2 | +| Internal audit | Semi-annual | Internal auditor | 9.2 | +| Management review | Quarterly | Executive Sponsor | 9.3 | +| Vulnerability scan review | Monthly | Engineering | A.8.8 | +| Access review | Quarterly | ISO | A.5.18 | +| Backup restore test | Monthly | DevOps | A.8.13 | +| Security awareness training | Annual + onboarding | ISO | A.6.3 | +| Supplier review | Annual | ISO | A.5.19 | +| KPI reporting | Monthly | ISO | 9.1 | + +### 6.2 Key Performance Indicators (KPIs) + +| KPI | Target | Measurement | +|-----|--------|-------------| +| Critical/High open risks | 0 Critical; ≀3 High | Risk register | +| Mean time to patch (Critical CVE) | ≀ 7 days | Vulnerability tracker | +| Failed login rate | Baseline + alert threshold | SIEM | +| Backup restore success | 100% monthly test | DevOps report | +| Security training completion | 100% staff | HR records | +| Incident response time (P1) | ≀ 1 hour acknowledgment | IR log | + +--- + +## 7. Phase 4 β€” Pre-Audit Readiness + +**Target:** Apr–Jun 2027 (4–6 weeks) + +| Task | Description | +|------|-------------| +| Select certification body (CB) | Accredited ISO 27001 registrar | +| Mock Stage 1 audit | Documentation review against Clauses 4–10 | +| Evidence pack assembly | Policies, risk register, audit reports, training records, change logs | +| Corrective actions | Close all findings from mock audit | +| Employee interviews prep | Staff briefed on ISMS policies and their roles | +| SoA finalization | All Annex A controls marked with implementation status | + +### 7.1 Evidence Checklist + +- [ ] Signed Information Security Policy +- [ ] Approved ISMS scope document +- [ ] Risk assessment and treatment plan (current version) +- [ ] Statement of Applicability +- [ ] Internal audit reports (β‰₯1 cycle) +- [ ] Management review minutes (β‰₯1 cycle) +- [ ] Incident response plan and test record +- [ ] Access review records +- [ ] Vulnerability scan reports +- [ ] Backup/restore test records +- [ ] Training completion records +- [ ] Vendor assessment records +- [ ] Change management records (sample) + +--- + +## 8. Phase 5 β€” Certification Audit + +**Target:** Jul–Sep 2027 + +### 8.1 Stage 1 β€” Documentation Review + +- CB reviews ISMS documentation for conformity with ISO 27001:2022 +- Scope, SoA, risk assessment, and policy completeness verified +- Findings documented; corrective actions before Stage 2 + +### 8.2 Stage 2 β€” Implementation Audit + +- CB verifies controls are implemented and operating effectively +- Interviews with key personnel +- Sampling of evidence (logs, tickets, access records) +- Nonconformities classified as Minor or Major + +### 8.3 Post-Certification + +- Surveillance audits annually +- Full recertification every 3 years +- Continuous improvement via PDCA cycle + +--- + +## 9. Resource Estimate + +| Role | Effort | Phase(s) | +|------|--------|----------| +| ISO (part-time) | 0.25–0.5 FTE ongoing | All | +| Engineering Lead | 0.1 FTE | 2, 3 | +| DevOps Lead | 0.15 FTE | 2, 3 | +| DPO (part-time) | 0.05 FTE | 1, 2 | +| External consultant (optional) | 5–10 days | 1, 4 | +| Certification body | Fixed fee | 5 | +| Security tooling (SIEM, scanning) | Budget item | 2 | + +**Estimated total cost range:** €15,000–€40,000 (highly dependent on org size, tooling, and consultant use) + +--- + +## 10. PDCA Cycle Integration + +``` + β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” + β”‚ PLAN β”‚ Scope, risk assessment, policies, SoA + β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜ + β–Ό + β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” + β”‚ DO β”‚ Implement controls, training, procedures + β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜ + β–Ό + β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” + β”‚ CHECK β”‚ Internal audit, KPIs, management review + β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜ + β–Ό + β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” + β”‚ ACT β”‚ Corrective actions, risk updates, improve + β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜ + └──────────► (back to PLAN) +``` + +--- + +## 11. Milestones & Decision Gates + +| Milestone | Target Date | Gate Criteria | +|-----------|-------------|---------------| +| M0: Foundation approved | 2026-06-30 | Executive sign-off on scope and asset inventory | +| M1: Policy suite published | 2026-08-31 | 5 core policies + risk procedure drafted; pending executive approval | +| M2: Critical risks mitigated | 2026-11-30 | No Critical residual risks | +| M3: ISMS operational | 2027-03-31 | 1 internal audit + 1 management review complete | +| M4: Pre-audit passed | 2027-06-30 | Mock audit with no Major findings | +| M5: ISO 27001 certified | 2027-09-30 | Stage 2 certificate issued | + +--- + +## 12. Document Control + +| Version | Date | Author | Changes | +|---------|------|--------|---------| +| 1.0 | 2026-06-11 | Engineering | Initial certification roadmap | + +**Approval** + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| ISO | _Pending_ | | | +| Executive Sponsor | _Pending_ | | | diff --git a/docs/security/RISK_ASSESSMENT_MATRIX.md b/docs/security/RISK_ASSESSMENT_MATRIX.md new file mode 100644 index 0000000..136509c --- /dev/null +++ b/docs/security/RISK_ASSESSMENT_MATRIX.md @@ -0,0 +1,166 @@ +# Risk Assessment Matrix β€” Tender Management System + +| Field | Value | +|-------|-------| +| **Document ID** | ISMS-002 | +| **Version** | 1.0 | +| **Status** | Initial assessment | +| **Owner** | Information Security Officer (ISO) | +| **Last Updated** | 2026-06-11 | +| **Review Cycle** | Quarterly (minimum) | + +--- + +## 1. Purpose + +This document records the initial information security risk assessment for the Tender Management System ISMS. It identifies threats, evaluates inherent and residual risk, and defines treatment plans aligned with ISO/IEC 27001 Clause 6.1.2 and Annex A controls. + +Related: [ISMS Foundation](./ISMS_FOUNDATION.md) | [ISO 27001 Roadmap](./ISO27001_ROADMAP.md) + +--- + +## 2. Methodology + +### 2.1 Risk Formula + +``` +Risk Score = Likelihood (1–5) Γ— Impact (1–5) +``` + +### 2.2 Likelihood Scale + +| Score | Label | Description | +|-------|-------|-------------| +| 1 | Rare | Unlikely in 3+ years | +| 2 | Unlikely | Possible but not expected annually | +| 3 | Possible | May occur once per year | +| 4 | Likely | Expected several times per year | +| 5 | Almost certain | Expected frequently or already observed | + +### 2.3 Impact Scale + +| Score | Label | Description | +|-------|-------|-------------| +| 1 | Negligible | No data exposure; minimal downtime (<1 h) | +| 2 | Minor | Limited internal data; downtime 1–4 h | +| 3 | Moderate | PII exposure for subset of users; downtime 4–24 h | +| 4 | Major | Large-scale PII breach; regulatory notification; downtime 1–3 days | +| 5 | Critical | Systemic breach; legal liability; prolonged outage (>3 days) | + +### 2.4 Risk Level Matrix + +| Score Range | Level | Action Required | +|-------------|-------|-----------------| +| 1–4 | **Low** | Monitor; accept with documented justification | +| 5–9 | **Medium** | Mitigate within 6 months | +| 10–15 | **High** | Mitigate within 3 months; management awareness | +| 16–25 | **Critical** | Immediate treatment; executive escalation | + +### 2.5 Treatment Options + +- **Mitigate** β€” Apply controls to reduce likelihood or impact +- **Transfer** β€” Insurance or contractual liability shift +- **Avoid** β€” Discontinue the activity +- **Accept** β€” Documented acceptance by authorized role (residual risk only) + +--- + +## 3. Risk Register + +### 3.1 Authentication & Access + +| Risk ID | Threat | Vulnerability | Asset(s) | L | I | Inherent | Existing Controls | Residual L | Residual I | Residual | Treatment | Owner | Target Date | Status | +|---------|--------|---------------|----------|---|---|----------|-------------------|------------|------------|----------|-----------|-------|-------------|--------| +| R-001 | Credential stuffing / brute force | Login endpoints without sufficient throttling | A-004, A-006, A-007 | 4 | 4 | **16 Critical** | JWT auth, hCaptcha on selected flows, rate limit config | 3 | 3 | **9 Medium** | Enforce rate limiting on all auth endpoints; account lockout; MFA for admin | Engineering | Q3 2026 | Open | +| R-002 | JWT token theft (XSS, MITM) | Tokens in client storage | A-008 | 3 | 4 | **12 High** | HTTPS required in prod; short token TTL; refresh rotation partial | 2 | 3 | **6 Medium** | Complete refresh token rotation; HttpOnly cookies where applicable; CSP headers | Engineering | Q3 2026 | Open | +| R-003 | Privilege escalation | Insufficient RBAC checks on admin routes | A-006, A-014 | 2 | 5 | **10 High** | Role middleware in `pkg/authorization` | 2 | 4 | **8 Medium** | RBAC audit of all admin endpoints; automated authorization tests | Engineering | Q2 2026 | Open | +| R-004 | Orphaned / excessive access | No formal access review process | A-006, A-010 | 3 | 3 | **9 Medium** | Manual provisioning | 2 | 2 | **4 Low** | Quarterly access review procedure; offboarding checklist | ISO | Q3 2026 | Open | + +### 3.2 Data Protection & Privacy + +| Risk ID | Threat | Vulnerability | Asset(s) | L | I | Inherent | Existing Controls | Residual L | Residual I | Residual | Treatment | Owner | Target Date | Status | +|---------|--------|---------------|----------|---|---|----------|-------------------|------------|------------|----------|-----------|-------|-------------|--------| +| R-005 | Unauthorized PII access | Missing encryption at rest | A-001, A-004, A-005 | 3 | 5 | **15 High** | Network isolation; app-level auth | 2 | 4 | **8 Medium** | Enable MongoDB encryption at rest; field-level encryption for sensitive fields | DevOps | Q3 2026 | Open | +| R-006 | Data breach via backup exposure | Unencrypted or overly permissive backups | A-019 | 2 | 5 | **10 High** | Ad-hoc backups | 2 | 3 | **6 Medium** | Encrypted backups; restricted access; backup retention policy | DevOps | Q3 2026 | Open | +| R-007 | GDPR non-compliance (DSR) | No documented data subject request process | A-004, A-005 | 3 | 4 | **12 High** | β€” | 3 | 3 | **9 Medium** | DSR procedure; data inventory mapping; deletion API/workflow | DPO | Q4 2026 | Open | +| R-008 | Sensitive data in logs | Accidental logging of passwords/tokens | A-011 | 3 | 4 | **12 High** | Coding standards prohibit password logging | 2 | 3 | **6 Medium** | Log scrubbing; automated secret detection in CI | Engineering | Q2 2026 | Open | + +### 3.3 Application Security + +| Risk ID | Threat | Vulnerability | Asset(s) | L | I | Inherent | Existing Controls | Residual L | Residual I | Residual | Treatment | Owner | Target Date | Status | +|---------|--------|---------------|----------|---|---|----------|-------------------|------------|------------|----------|-----------|-------|-------------|--------| +| R-009 | Injection attacks (NoSQL, XSS) | Unvalidated user input | A-014 | 3 | 4 | **12 High** | Govalidator; Bluemonday XSS policy | 2 | 3 | **6 Medium** | SAST/DAST in CI; security test cases for injection | Engineering | Q2 2026 | Open | +| R-010 | Dependency vulnerability exploit | Outdated Go modules | A-009 | 4 | 4 | **16 Critical** | go.mod pinned versions | 3 | 3 | **9 Medium** | Dependabot/Renovate; monthly dependency review; `govulncheck` in CI | Engineering | Q2 2026 | Open | +| R-011 | Insecure file upload | Malicious document upload | A-003, A-005 | 2 | 4 | **8 Medium** | File store service; GridFS/MinIO | 2 | 3 | **6 Medium** | MIME validation; size limits; malware scanning | Engineering | Q4 2026 | Open | +| R-012 | API abuse / DoS | High-volume unauthenticated requests | A-014 | 4 | 3 | **12 High** | Rate limit config exists | 2 | 2 | **4 Low** | Enable rate limiting in production; WAF/CDN | DevOps | Q2 2026 | Open | + +### 3.4 Infrastructure & Operations + +| Risk ID | Threat | Vulnerability | Asset(s) | L | I | Inherent | Existing Controls | Residual L | Residual I | Residual | Treatment | Owner | Target Date | Status | +|---------|--------|---------------|----------|---|---|----------|-------------------|------------|------------|----------|-----------|-------|-------------|--------| +| R-013 | Secret leakage | Secrets in repo, logs, or `.env` files | A-010, A-018 | 3 | 5 | **15 High** | `.gitignore`; env priority system | 2 | 4 | **8 Medium** | Secret manager (Vault/AWS SM); secret scanning in CI; rotate FCM keys out of repo | DevOps | Q2 2026 | Open | +| R-014 | Service outage (MongoDB/Redis/MinIO) | Single points of failure | A-001, A-002, A-003 | 3 | 4 | **12 High** | Managed services assumed | 2 | 3 | **6 Medium** | HA deployment; DR plan; RTO/RPO definitions | DevOps | Q4 2026 | Open | +| R-015 | Insufficient monitoring | Delayed incident detection | A-011, A-012 | 4 | 4 | **16 Critical** | Application logging only | 3 | 3 | **9 Medium** | SIEM integration; alerting on auth failures, error spikes | DevOps | Q3 2026 | Open | +| R-016 | Unpatched OS/container images | Delayed security patching | A-014, A-015 | 3 | 4 | **12 High** | β€” | 2 | 3 | **6 Medium** | Patch management procedure; automated image scanning | DevOps | Q3 2026 | Open | + +### 3.5 Third-Party & Supply Chain + +| Risk ID | Threat | Vulnerability | Asset(s) | L | I | Inherent | Existing Controls | Residual L | Residual I | Residual | Treatment | Owner | Target Date | Status | +|---------|--------|---------------|----------|---|---|----------|-------------------|------------|------------|----------|-----------|-------|-------------|--------| +| R-017 | AI service data leakage | Tender text sent to external AI | A-017, A-013 | 3 | 4 | **12 High** | Configurable AI endpoint | 2 | 3 | **6 Medium** | DPA with AI vendor; data minimization; on-prem option evaluation | DPO / DevOps | Q4 2026 | Open | +| R-018 | Notification service compromise | Email content interception | A-016 | 2 | 3 | **6 Medium** | TLS to notification API | 2 | 2 | **4 Low** | Vendor security questionnaire; TLS enforcement | ISO | Q4 2026 | Open | +| R-019 | Compromised TED source data | Malicious XML in scraper pipeline | A-013, A-015 | 2 | 3 | **6 Medium** | XML parser validation | 2 | 2 | **4 Low** | Schema validation; sandboxed parsing; input size limits | Engineering | Q3 2026 | Open | + +### 3.6 Human & Process + +| Risk ID | Threat | Vulnerability | Asset(s) | L | I | Inherent | Existing Controls | Residual L | Residual I | Residual | Treatment | Owner | Target Date | Status | +|---------|--------|---------------|----------|---|---|----------|-------------------|------------|------------|----------|-----------|-------|-------------|--------| +| R-020 | Insider threat | Broad production DB access | A-001, A-004 | 2 | 5 | **10 High** | β€” | 2 | 4 | **8 Medium** | Least privilege; break-glass access; audit DB queries | DevOps | Q3 2026 | Open | +| R-021 | Phishing / social engineering | Staff credential compromise | A-006, A-010 | 3 | 4 | **12 High** | β€” | 2 | 3 | **6 Medium** | Security awareness training; MFA for admin and infra | ISO | Q3 2026 | Open | +| R-022 | Undocumented change deployment | No formal change management | A-009, A-014 | 3 | 3 | **9 Medium** | Git + PR workflow informal | 2 | 2 | **4 Low** | Change management procedure; prod deployment approval | Engineering | Q3 2026 | Open | +| R-023 | Delayed incident response | No IR plan or runbooks | All | 3 | 5 | **15 High** | β€” | 2 | 4 | **8 Medium** | Incident response plan; tabletop exercise | ISO | Q2 2026 | Open | + +--- + +## 4. Risk Summary Dashboard + +| Risk Level | Count | Risk IDs | +|------------|-------|----------| +| **Critical** (16–25) | 0 (after treatment planning) | R-001, R-010, R-015 were Critical inherent β€” all have mitigation plans | +| **High** (10–15) | 8 residual | R-003, R-005, R-007, R-009, R-013, R-014, R-020, R-023 | +| **Medium** (5–9) | 12 residual | R-001, R-002, R-004, R-006, R-008, R-010, R-011, R-015, R-016, R-017, R-021, R-022 | +| **Low** (1–4) | 3 residual | R-012, R-018, R-019 | + +### 4.1 Top Priority Actions (Next 90 Days) + +1. **R-023** β€” Draft and approve incident response plan +2. **R-013** β€” Remove secrets from repository; implement secret scanning +3. **R-010** β€” Add `govulncheck` and dependency scanning to CI +4. **R-003** β€” Complete RBAC audit of admin API routes +5. **R-001** β€” Enforce authentication rate limiting in production + +--- + +## 5. Risk Acceptance Log + +Use this section to record risks explicitly accepted after treatment. + +| Risk ID | Residual Score | Accepted By | Role | Date | Justification | Review Date | +|---------|----------------|-------------|------|------|---------------|-------------| +| _None yet_ | | | | | | | + +--- + +## 6. Review History + +| Version | Date | Reviewer | Changes | +|---------|------|----------|---------| +| 1.0 | 2026-06-11 | Engineering | Initial risk identification for TM platform | + +**Next scheduled review:** 2026-09-11 + +--- + +## 7. Annex β€” Asset Reference + +See [ISMS Foundation Β§4](./ISMS_FOUNDATION.md#4-information-asset-inventory) for full asset inventory (A-001 through A-020). diff --git a/docs/security/STATEMENT_OF_APPLICABILITY.md b/docs/security/STATEMENT_OF_APPLICABILITY.md new file mode 100644 index 0000000..98c2268 --- /dev/null +++ b/docs/security/STATEMENT_OF_APPLICABILITY.md @@ -0,0 +1,255 @@ +# Statement of Applicability (SoA) β€” Tender Management System + +| Field | Value | +|-------|-------| +| **Document ID** | ISMS-005 | +| **Version** | 1.0 | +| **Status** | Draft β€” Pending approval | +| **Owner** | Information Security Officer (ISO) | +| **Last Updated** | 2026-06-11 | +| **Standard** | ISO/IEC 27001:2022 Annex A | +| **Scope** | [ISMS Foundation Β§3](./ISMS_FOUNDATION.md#3-isms-scope) | + +Related: [Gap Analysis Report](./GAP_ANALYSIS_REPORT.md) | [Risk Assessment Matrix](./RISK_ASSESSMENT_MATRIX.md) + +--- + +## 1. Purpose + +The Statement of Applicability (SoA) documents: + +- Which Annex A controls are **applicable** to the TM ISMS +- Whether each control is **implemented**, **partially implemented**, or **not implemented** +- Justification for exclusions +- Reference to implementation evidence or planned remediation + +This document satisfies ISO/IEC 27001:2022 Clause 6.1.3(d) and is a mandatory input for certification audits. + +--- + +## 2. Status Legend + +| Status | Meaning | +|--------|---------| +| **Yes** | Applicable and implemented with evidence | +| **Partial** | Applicable; control exists but incomplete or not fully evidenced | +| **No** | Applicable but not yet implemented | +| **N/A** | Not applicable to scope (justification required) | + +--- + +## 3. A.5 β€” Organizational Controls + +| ID | Control | Applicable | Status | Implementation / Justification | Risk Ref | +|----|---------|------------|--------|----------------------------------|----------| +| A.5.1 | Policies for information security | Yes | Partial | [Information Security Policy](./policies/information-security-policy.md) draft; pending approval | β€” | +| A.5.2 | Information security roles and responsibilities | Yes | Partial | [ISMS Foundation Β§5](./ISMS_FOUNDATION.md#5-roles-and-responsibilities); named assignments pending | β€” | +| A.5.3 | Segregation of duties | Yes | Partial | Dev vs DevOps separation informal; no single prod DB write without break-glass | R-020 | +| A.5.4 | Management responsibilities | Yes | Partial | Roadmap and objectives defined; management review not yet held | β€” | +| A.5.5 | Contact with authorities | Yes | No | No documented contacts with regulators/law enforcement | R-023 | +| A.5.6 | Contact with special interest groups | Yes | No | No ISAC or security forum membership | β€” | +| A.5.7 | Threat intelligence | Yes | No | No formal threat intel feed or process | β€” | +| A.5.8 | Information security in project management | Yes | Partial | Major change checklist in risk procedure; informal for small changes | β€” | +| A.5.9 | Inventory of information and other associated assets | Yes | Yes | [ISMS Foundation Β§4](./ISMS_FOUNDATION.md#4-information-asset-inventory) β€” 20 assets | β€” | +| A.5.10 | Acceptable use of information and other associated assets | Yes | Partial | [Acceptable Use Policy](./policies/acceptable-use-policy.md) draft | β€” | +| A.5.11 | Return of assets | Yes | No | No formal offboarding asset return checklist | R-004 | +| A.5.12 | Classification of information | Yes | Yes | C1–C4 classification in ISMS Foundation | β€” | +| A.5.13 | Labelling of information | Yes | No | Classification defined but no labelling in apps/repos | β€” | +| A.5.14 | Information transfer | Yes | Partial | HTTPS for APIs; email via notification service; no DLP | R-017 | +| A.5.15 | Access control | Yes | Partial | [Access Control Policy](./policies/access-control-policy.md); JWT + RBAC | R-003 | +| A.5.16 | Identity management | Yes | Partial | Unique accounts; provisioning/deprovisioning procedure in policy | R-004 | +| A.5.17 | Authentication information | Yes | Partial | bcrypt passwords; secrets in env; MFA planned | R-001, R-013 | +| A.5.18 | Access rights | Yes | Partial | Quarterly review defined; not yet executed | R-004 | +| A.5.19 | Information security in supplier relationships | Yes | No | No vendor security assessments | R-017, R-018 | +| A.5.20 | Addressing information security within supplier agreements | Yes | No | Contracts lack security clauses review | R-017 | +| A.5.21 | Managing information security in the ICT supply chain | Yes | Partial | Go modules pinned; no formal supply chain policy | R-010 | +| A.5.22 | Monitoring, review and change management of supplier services | Yes | No | No annual vendor review process | R-018 | +| A.5.23 | Information security for use of cloud services | Yes | Partial | Cloud-hosted MongoDB/Redis/MinIO; provider evidence not collected | R-014 | +| A.5.24 | Information security incident management planning and preparation | Yes | Partial | [Incident Response Plan](./policies/incident-response-plan.md) draft | R-023 | +| A.5.25 | Assessment and decision on information security events | Yes | Partial | Severity classification in IR plan; not yet tested | R-023 | +| A.5.26 | Response to information security incidents | Yes | Partial | Playbooks defined; IRT contacts not finalized | R-023 | +| A.5.27 | Learning from information security incidents | Yes | Partial | Post-incident review required in IR plan; no incidents recorded yet | β€” | +| A.5.28 | Collection of evidence | Yes | Partial | Evidence handling in IR plan; chain of custody untested | β€” | +| A.5.29 | Information security during disruption | Yes | Partial | RTO/RPO in backup policy; no full BCP document | R-014 | +| A.5.30 | ICT readiness for business continuity | Yes | Partial | Backup policy; DR test not yet performed | R-014 | +| A.5.31 | Legal, statutory, regulatory and contractual requirements | Yes | Partial | GDPR referenced; no requirements register | R-007 | +| A.5.32 | Intellectual property rights | Yes | Partial | Open-source licenses in go.mod; no IP policy | β€” | +| A.5.33 | Protection of records | Yes | Partial | Audit logs; retention periods not fully defined | β€” | +| A.5.34 | Privacy and protection of PII | Yes | Partial | PII inventory; DSR process not implemented | R-007 | +| A.5.35 | Independent review of information security | Yes | No | No internal audit or external review yet | β€” | +| A.5.36 | Compliance with policies, rules and standards | Yes | No | No compliance checks or audit program | β€” | +| A.5.37 | Documented operating procedures | Yes | Partial | ISMS procedures started; ops runbooks incomplete | β€” | + +--- + +## 4. A.6 β€” People Controls + +| ID | Control | Applicable | Status | Implementation / Justification | Risk Ref | +|----|---------|------------|--------|----------------------------------|----------| +| A.6.1 | Screening | Yes | No | No background check policy documented | R-021 | +| A.6.2 | Terms and conditions of employment | Yes | Partial | Acceptable Use Policy; HR terms not linked | β€” | +| A.6.3 | Information security awareness, education and training | Yes | No | No training program or records | R-021 | +| A.6.4 | Disciplinary process | Yes | Partial | Referenced in AUP; HR process not documented | β€” | +| A.6.5 | Responsibilities after termination or change of employment | Yes | Partial | Deprovisioning in Access Control Policy (24 h) | R-004 | +| A.6.6 | Confidentiality or non-disclosure agreements | Yes | Partial | Assumed for contractors; no central register | β€” | +| A.6.7 | Remote working | Yes | Partial | VPN/bastion requirement in Access Control Policy | β€” | +| A.6.8 | Information security event reporting | Yes | Partial | Reporting channels in IR plan; not communicated to staff | R-023 | + +--- + +## 5. A.7 β€” Physical Controls + +| ID | Control | Applicable | Status | Implementation / Justification | Risk Ref | +|----|---------|------------|--------|----------------------------------|----------| +| A.7.1 | Physical security perimeters | N/A | N/A | Cloud provider responsibility (A.5.23) | β€” | +| A.7.2 | Physical entry | N/A | N/A | Cloud provider responsibility | β€” | +| A.7.3 | Securing offices, rooms and facilities | N/A | N/A | No on-premise TM infrastructure | β€” | +| A.7.4 | Physical security monitoring | N/A | N/A | Cloud provider responsibility | β€” | +| A.7.5 | Protecting against physical and environmental threats | N/A | N/A | Cloud provider responsibility | β€” | +| A.7.6 | Working in secure areas | N/A | N/A | No secure areas for TM systems | β€” | +| A.7.7 | Clear desk and clear screen | Yes | Partial | AUP references screen lock; not enforced | β€” | +| A.7.8 | Equipment siting and protection | N/A | N/A | Cloud-hosted servers | β€” | +| A.7.9 | Security of assets off-premises | Yes | Partial | AUP device encryption requirement for prod access | β€” | +| A.7.10 | Storage media | N/A | N/A | No removable media for TM data stores | β€” | +| A.7.11 | Supporting utilities | N/A | N/A | Cloud provider responsibility | β€” | +| A.7.12 | Cabling security | N/A | N/A | Cloud provider responsibility | β€” | +| A.7.13 | Equipment maintenance | N/A | N/A | Cloud provider responsibility | β€” | +| A.7.14 | Secure disposal or re-use of equipment | Yes | Partial | AUP prohibits local PII storage; no disposal procedure | β€” | + +*Note: A.7.7, A.7.9, A.7.14 remain applicable for personnel devices accessing TM systems.* + +--- + +## 6. A.8 β€” Technological Controls + +| ID | Control | Applicable | Status | Implementation / Justification | Risk Ref | +|----|---------|------------|--------|----------------------------------|----------| +| A.8.1 | User endpoint devices | Yes | Partial | AUP device requirements; no MDM | β€” | +| A.8.2 | Privileged access rights | Yes | Partial | Break-glass procedure; no PAM tool | R-020 | +| A.8.3 | Information access restriction | Yes | Yes | RBAC + company-scoped middleware (`pkg/authorization`) | R-003 | +| A.8.4 | Access to source code | Yes | Yes | Git repo with PR review; branch protection (assumed) | β€” | +| A.8.5 | Secure authentication | Yes | Partial | JWT, bcrypt, hCaptcha; MFA not yet enabled | R-001, R-002 | +| A.8.6 | Capacity management | Yes | Partial | Rate limit config; no capacity monitoring | R-012 | +| A.8.7 | Protection against malware | Yes | No | No malware scanning on uploads or endpoints | R-011 | +| A.8.8 | Management of technical vulnerabilities | Yes | No | No govulncheck/SAST in CI | R-010 | +| A.8.9 | Configuration management | Yes | Partial | `pkg/config` env priority; secrets in flat env files | R-013 | +| A.8.10 | Information deletion | Yes | Partial | Domain delete operations; no retention/deletion policy | R-007 | +| A.8.11 | Data masking | Yes | No | Passwords excluded from API responses; no masking elsewhere | β€” | +| A.8.12 | Data leakage prevention | Yes | No | No DLP tooling | R-008 | +| A.8.13 | Information backup | Yes | Partial | [Backup & Recovery Policy](./policies/backup-and-recovery-policy.md); tests not yet run | R-006, R-014 | +| A.8.14 | Redundancy of information processing facilities | Yes | Partial | Depends on cloud provider HA; not documented | R-014 | +| A.8.15 | Logging | Yes | Yes | Structured service logging; `pkg/audit` for security events | R-008, R-015 | +| A.8.16 | Monitoring activities | Yes | Partial | Application logs only; no SIEM or alerting | R-015 | +| A.8.17 | Clock synchronization | Yes | Partial | NTP assumed on cloud hosts; not verified | β€” | +| A.8.18 | Use of privileged utility programs | Yes | Partial | DB admin tools restricted; no formal policy | R-020 | +| A.8.19 | Installation of software on operational systems | Yes | Partial | Container/deploy pipeline; no formal whitelist | R-016 | +| A.8.20 | Networks security | Yes | Partial | HTTPS in prod; DB not public; no documented network diagram | β€” | +| A.8.21 | Security of network services | Yes | Partial | TLS to external APIs; no network service inventory | β€” | +| A.8.22 | Segregation of networks | Yes | Partial | Dev/staging/prod separated; informal | β€” | +| A.8.23 | Web filtering | Yes | No | No web filtering for staff endpoints | β€” | +| A.8.24 | Use of cryptography | Yes | Partial | TLS in transit; at-rest encryption TBD | R-005 | +| A.8.25 | Secure development life cycle | Yes | Partial | `.cursorrules`, code review, Clean Architecture | β€” | +| A.8.26 | Application security requirements | Yes | Yes | Govalidator, XSS policy, Swagger, response standards | R-009 | +| A.8.27 | Secure system architecture and engineering principles | Yes | Partial | Clean Architecture, DI, no global state | β€” | +| A.8.28 | Secure coding | Yes | Partial | Coding standards documented; no SAST | R-009, R-010 | +| A.8.29 | Security testing in development and acceptance | Yes | No | Unit tests exist; no security test suite or DAST | R-009 | +| A.8.30 | Outsourced development | N/A | N/A | All TM backend development is in-house; no outsourced development of scoped applications | β€” | +| A.8.31 | Separation of development, test and production environments | Yes | Partial | Separate env configs; staging data may contain real data | β€” | +| A.8.32 | Change management | Yes | Partial | Git PR workflow; no formal change procedure | R-022 | +| A.8.33 | Test information | Yes | Partial | Staging should use anonymized data; not enforced | β€” | +| A.8.34 | Protection of information systems during audit testing | Yes | No | No audit testing procedure | β€” | + +--- + +## 7. Summary Statistics + +Counts derived from the control rows in Β§3–§6 (authoritative source for cross-document reporting). + +### 7.1 By Theme + +| Theme | Total | Implemented (Yes) | Partial | Not impl. (No) | N/A | +|-------|-------|-------------------|---------|----------------|-----| +| **A.5** Organizational | 37 | 2 | 25 | 10 | 0 | +| **A.6** People | 8 | 0 | 6 | 2 | 0 | +| **A.7** Physical | 14 | 0 | 3 | 0 | 11 | +| **A.8** Technological | 34 | 4 | 22 | 7 | 1 | +| **Total** | **93** | **6** | **56** | **19** | **12** | + +### 7.2 Overall + +| Category | Count | % of all 93 | +|----------|-------|-------------| +| Total Annex A controls | 93 | 100% | +| Not applicable (N/A) | 12 | 13% | +| **Applicable** | **81** | **87%** | +| Implemented (Yes) | 6 | 6% | +| Partial | 56 | 60% | +| Not implemented (No) | 19 | 20% | + +*Applicable = Total βˆ’ N/A. Yes/Partial/No counts apply only to applicable controls (6 + 56 + 19 = 81).* + +### 7.3 Applicable Controls by Status + +Percentages below are of **81 applicable** controls (excluding 12 N/A). + +``` +Implemented β–ˆβ–ˆβ–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘ 7% (6/81) +Partial β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–‘β–‘β–‘β–‘β–‘ 69% (56/81) +Not impl. β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘β–‘ 23% (19/81) +``` + +--- + +## 8. Priority Remediation (Applicable "No" and Critical "Partial") + +| Priority | Control(s) | Action | Target | Owner | +|----------|------------|--------|--------|-------| +| P0 | A.8.8 | Add govulncheck + dependency scanning to CI | Q2 2026 | Engineering | +| P0 | A.8.16 | Deploy centralized logging and alerting | Q3 2026 | DevOps | +| P0 | A.5.35, A.5.36 | Establish internal audit program | Q1 2027 | ISO | +| P1 | A.6.3 | Launch security awareness training | Q3 2026 | ISO | +| P1 | A.5.19–A.5.22 | Vendor security assessments | Q4 2026 | ISO | +| P1 | A.8.24 | Enable encryption at rest | Q3 2026 | DevOps | +| P1 | A.8.5 | Enable MFA for admin users | Q3 2026 | Engineering | +| P1 | A.8.29 | Add security testing to CI/CD | Q3 2026 | Engineering | +| P2 | A.5.5 | Document authority contacts (GDPR DPA) | Q3 2026 | DPO | +| P2 | A.8.7 | Malware scan on file uploads | Q4 2026 | Engineering | +| P2 | A.8.12 | Evaluate DLP for log pipeline | Q4 2026 | DevOps | + +--- + +## 9. Exclusion Justifications + +| Control(s) | Justification | +|------------|---------------| +| A.7.1–A.7.6, A.7.8, A.7.10–A.7.13 | TM infrastructure is fully cloud-hosted; physical controls are the responsibility of the cloud/IaaS provider per shared responsibility model. Evidence collected via A.5.23. | +| A.8.30 | All TM backend development is in-house; no outsourced development of scoped applications. | + +--- + +## 10. Document Control + +| Version | Date | Author | Changes | +|---------|------|--------|---------| +| 1.0 | 2026-06-11 | Engineering | Initial SoA for 93 Annex A controls | +| 1.1 | 2026-06-11 | Engineering | Reconciled summary counts with control rows; fixed A.8.30 applicability | + +**Approval** + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| ISO | _Pending_ | | | +| Executive Sponsor | _Pending_ | | | + +**Next review:** Quarterly or upon significant scope/control change + +--- + +## 11. Cross-Reference Index + +| Document | Purpose | +|----------|---------| +| [GAP_ANALYSIS_REPORT.md](./GAP_ANALYSIS_REPORT.md) | Clause-level gap detail | +| [RISK_ASSESSMENT_MATRIX.md](./RISK_ASSESSMENT_MATRIX.md) | Risk IDs linked in SoA | +| [ISO27001_ROADMAP.md](./ISO27001_ROADMAP.md) | Remediation timeline | +| [policies/](./policies/) | Policy evidence for A.5.x controls | diff --git a/docs/security/policies/acceptable-use-policy.md b/docs/security/policies/acceptable-use-policy.md new file mode 100644 index 0000000..e936e3b --- /dev/null +++ b/docs/security/policies/acceptable-use-policy.md @@ -0,0 +1,158 @@ +# Acceptable Use Policy + +| Field | Value | +|-------|-------| +| **Document ID** | POL-005 | +| **Version** | 1.0 | +| **Status** | Draft β€” Pending approval | +| **Owner** | Information Security Officer (ISO) | +| **Effective Date** | _Pending approval_ | +| **Review Cycle** | Annual | +| **ISO 27001 Reference** | A.6.2 β€” Terms and conditions of employment; A.5.10 β€” Acceptable use | + +Related: [Information Security Policy](./information-security-policy.md) | [Access Control Policy](./access-control-policy.md) + +--- + +## 1. Purpose + +This policy defines acceptable and unacceptable use of Tender Management System resources, data, and infrastructure by employees, contractors, and third parties. + +--- + +## 2. Scope + +Applies to anyone who: + +- Accesses TM production, staging, or development environments +- Handles TM source code, configuration, or customer/company data +- Uses company-issued or personal devices to perform TM-related work +- Integrates third-party services with TM APIs + +--- + +## 3. Acceptable Use + +Personnel **may**: + +- Access systems and data required for their assigned role +- Use company-approved tools for development, testing, and deployment +- Store TM source code only in authorized Git repositories +- Use staging environments for testing with synthetic or anonymized data +- Report security concerns or suspected incidents without retaliation +- Work remotely using VPN/bastion access as configured by DevOps + +--- + +## 4. Unacceptable Use + +Personnel **must not**: + +### 4.1 Data Handling + +- Copy production PII to personal devices, unauthorized cloud storage, or local unencrypted files +- Share customer or company data with unauthorized persons +- Use production data for development/testing without anonymization approval +- Export bulk data without business justification and ISO approval + +### 4.2 Credentials & Access + +- Share passwords, API keys, JWT tokens, or SSH keys +- Commit secrets, credentials, or `.env` files with production values to Git +- Use personal accounts for production system access +- Bypass authentication, authorization, or audit controls +- Leave privileged sessions unattended + +### 4.3 Systems & Network + +- Install unauthorized software on production or staging servers +- Run penetration tests against production without written ISO approval +- Introduce malware, unauthorized scripts, or unvetted dependencies +- Disable security controls (logging, rate limiting, firewalls) without approval +- Mine cryptocurrency or use TM infrastructure for non-business purposes + +### 4.4 Development Practices + +- Push directly to production branches without peer review +- Deploy untested code to production +- Ignore critical security scan findings without documented risk acceptance +- Log passwords, tokens, or full PII in application logs + +### 4.5 Third Parties + +- Grant vendor access beyond minimum required scope +- Share API credentials with unauthorized integrators +- Use unapproved AI/LLM tools to process production customer data without DPO review + +--- + +## 5. Device and Remote Work Requirements + +| Requirement | Detail | +|-------------|--------| +| Screen lock | Enabled when unattended (≀ 5 min) | +| Full-disk encryption | Required on devices accessing production | +| OS updates | Security patches applied within 30 days | +| Antivirus | Company-approved endpoint protection where applicable | +| Public Wi-Fi | VPN required for production access | + +--- + +## 6. Email and Communication + +- Do not transmit passwords or API keys via email or chat +- Use approved secure channels for credential delivery +- Report phishing attempts to ISO immediately + +--- + +## 7. Monitoring and Privacy + +The organization reserves the right to monitor use of TM systems and company equipment to: + +- Detect security incidents +- Ensure policy compliance +- Protect information assets + +Monitoring is conducted in accordance with applicable privacy laws and employment agreements. + +--- + +## 8. Consequences + +Violations may result in: + +| Severity | Consequence | +|----------|-------------| +| Minor / first offense | Written warning; mandatory retraining | +| Moderate | Suspension of access; formal disciplinary action | +| Severe (data breach, intentional misuse) | Termination; legal action; regulatory reporting | + +All violations involving data exposure follow the [Incident Response Plan](./incident-response-plan.md). + +--- + +## 9. Acknowledgment + +All personnel must sign or electronically acknowledge this policy: + +- Upon onboarding (before production access is granted) +- Annually thereafter +- When materially updated + +Records retained by HR/ISO for **3 years**. + +--- + +## 10. Document Control + +| Version | Date | Author | Changes | +|---------|------|--------|---------| +| 1.0 | 2026-06-11 | Engineering | Initial policy | + +**Approval** + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| ISO | _Pending_ | | | +| Executive Sponsor | _Pending_ | | | diff --git a/docs/security/policies/access-control-policy.md b/docs/security/policies/access-control-policy.md new file mode 100644 index 0000000..d2baa1e --- /dev/null +++ b/docs/security/policies/access-control-policy.md @@ -0,0 +1,174 @@ +# Access Control Policy + +| Field | Value | +|-------|-------| +| **Document ID** | POL-002 | +| **Version** | 1.0 | +| **Status** | Draft β€” Pending approval | +| **Owner** | Information Security Officer (ISO) | +| **Effective Date** | _Pending approval_ | +| **Review Cycle** | Annual | +| **ISO 27001 Reference** | A.5.15–A.5.18 β€” Access control | + +Related: [Information Security Policy](./information-security-policy.md) | [ISMS Foundation Β§4](../ISMS_FOUNDATION.md#4-information-asset-inventory) + +--- + +## 1. Purpose + +This policy defines requirements for granting, reviewing, modifying, and revoking access to Tender Management System resources, ensuring that only authorized individuals and services can access information based on business need. + +--- + +## 2. Scope + +Applies to access for: + +- **Admin users** β€” internal operators of the admin panel (`/admin/v1`) +- **Customer users** β€” company representatives using the mobile/public API (`/api/v1`) +- **Service accounts** β€” worker, scraper, CI/CD, and integration credentials +- **Infrastructure access** β€” MongoDB, Redis, MinIO, deployment environments + +--- + +## 3. Access Control Principles + +1. **Least privilege** β€” minimum access required for the role +2. **Need-to-know** β€” access limited to data required for the task +3. **Separation of duties** β€” no single person holds unrestricted production access without oversight +4. **Default deny** β€” access is denied unless explicitly granted +5. **Accountability** β€” all access is attributable to an individual or service identity + +--- + +## 4. User Access Management + +### 4.1 Account Provisioning + +| Step | Requirement | +|------|-------------| +| Request | Access request submitted by manager with role justification | +| Approval | ISO or Engineering Lead approves based on role matrix | +| Creation | Account created with default-deny; only required permissions assigned | +| Notification | User receives credentials via secure channel (never email plaintext passwords) | +| Recording | Access grant logged in access register | + +### 4.2 Role Matrix β€” Application Users + +| Role | System | Permissions | +|------|--------|-------------| +| **Admin** | Admin panel API | Full CRUD on users, companies, tenders, CMS, notifications | +| **Customer Admin** | Public API | Manage company profile, customers within company, view matched tenders | +| **Customer Analyst** | Public API | View tenders, submit feedback; no user management | +| **Service: Web API** | MongoDB, Redis, MinIO | Read/write per domain; no direct admin DB access | +| **Service: Worker** | MongoDB, MinIO, AI API | Read/write tenders; invoke translation jobs | +| **Service: Scraper** | MongoDB, TED source | Write tenders/notices only | + +Technical enforcement: JWT role claims and middleware in `pkg/authorization`; company-scoped access for customer roles. + +### 4.3 Role Matrix β€” Infrastructure + +| Role | MongoDB | Redis | MinIO | Production Deploy | +|------|---------|-------|-------|-------------------| +| Developer | Staging read/write | Staging | Staging | No | +| DevOps | Prod read (break-glass write) | Prod | Prod | Yes (with approval) | +| ISO | Audit read-only | No | No | No | + +Production database write access requires break-glass procedure (Β§7). + +### 4.4 Account Modification + +- Role changes require re-approval by manager and ISO +- Privilege elevation is temporary where possible (time-limited tokens) + +### 4.5 Account Deprovisioning + +Access must be revoked **within 24 hours** of: + +- Employment or contract termination +- Role change removing need for access +- Extended leave (>30 days) for privileged accounts + +Checklist: disable admin user account, revoke JWT/refresh tokens (Redis blacklist), remove SSH/infra access, rotate shared secrets if exposed. + +--- + +## 5. Authentication Requirements + +### 5.1 Human Users + +| Requirement | Admin Users | Customer Users | +|-------------|-------------|----------------| +| Unique account | Mandatory | Mandatory | +| Password complexity | Min 12 chars; mixed case, number, symbol | Min 8 chars; mixed case, number | +| Password storage | bcrypt hash (never plaintext) | bcrypt hash (never plaintext) | +| MFA | Required (target: Q3 2026) | Recommended | +| Session/token TTL | Access token ≀ 15 min; refresh rotation | Access token ≀ 1 h; refresh rotation | +| Failed login lockout | 5 attempts / 15 min lockout | 5 attempts / 15 min lockout | +| hCaptcha | On registration and password reset | On registration and password reset | + +### 5.2 Service Accounts + +- Unique credentials per service and environment +- Stored in secret manager (not `.env` in production) +- Rotated at least annually or on personnel change +- No shared passwords between services + +### 5.3 API Authentication + +- All protected endpoints require valid JWT in `Authorization: Bearer` header +- Public endpoints limited to explicitly whitelisted routes (health, public tender list, contact form with hCaptcha) + +--- + +## 6. Access Reviews + +| Review Type | Frequency | Reviewer | Scope | +|-------------|-----------|----------|-------| +| Admin user accounts | Quarterly | ISO + Engineering Lead | All active admin users | +| Customer admin accounts | Semi-annual | Product Owner | Accounts inactive >90 days | +| Infrastructure access | Quarterly | DevOps Lead | SSH, DB, MinIO, CI/CD | +| Service account credentials | Semi-annual | DevOps Lead | All non-human identities | + +Findings are documented and remediated within 30 days. + +--- + +## 7. Break-Glass Access + +Emergency production access when normal procedures cannot meet operational need: + +1. Request logged in incident/ticket system with justification +2. Approved by DevOps Lead or ISO (second approver if requester is DevOps Lead) +3. Time-limited (maximum 4 hours) +4. All actions logged and reviewed within 48 hours post-event +5. Credentials rotated if break-glass credentials were used + +--- + +## 8. Remote Access + +- Production infrastructure accessible only via VPN or bastion host +- No direct public exposure of MongoDB, Redis, or MinIO ports +- Admin panel and API served over HTTPS only in production + +--- + +## 9. Violations + +Unauthorized access attempts, credential sharing, or bypassing access controls must be reported immediately per the [Incident Response Plan](./incident-response-plan.md). + +--- + +## 10. Document Control + +| Version | Date | Author | Changes | +|---------|------|--------|---------| +| 1.0 | 2026-06-11 | Engineering | Initial policy | + +**Approval** + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| ISO | _Pending_ | | | +| Executive Sponsor | _Pending_ | | | diff --git a/docs/security/policies/backup-and-recovery-policy.md b/docs/security/policies/backup-and-recovery-policy.md new file mode 100644 index 0000000..0cb8a9b --- /dev/null +++ b/docs/security/policies/backup-and-recovery-policy.md @@ -0,0 +1,172 @@ +# Backup & Recovery Policy + +| Field | Value | +|-------|-------| +| **Document ID** | POL-004 | +| **Version** | 1.0 | +| **Status** | Draft β€” Pending approval | +| **Owner** | DevOps Lead | +| **Maintained By** | DevOps Lead | +| **Effective Date** | _Pending approval_ | +| **Review Cycle** | Annual | +| **ISO 27001 Reference** | A.8.13 β€” Information backup | + +Related: [Information Security Policy](./information-security-policy.md) | [Incident Response Plan](./incident-response-plan.md) + +--- + +## 1. Purpose + +This policy defines backup requirements, retention periods, and recovery objectives for Tender Management System data to ensure business continuity and data protection. + +--- + +## 2. Scope + +Covers backup and recovery for: + +| Asset | ID | Backup Method | +|-------|-----|---------------| +| MongoDB (`tm` database) | A-001 | Automated snapshots / mongodump | +| MinIO object storage | A-003 | Bucket replication or periodic sync | +| Redis | A-002 | RDB snapshots (cache β€” lower priority) | +| Application configuration | A-010 | Version-controlled templates; secrets in vault | +| Application logs | A-011 | Log aggregator retention | + +--- + +## 3. Recovery Objectives + +| Metric | Definition | Target | +|--------|------------|--------| +| **RTO** (Recovery Time Objective) | Maximum acceptable downtime | **4 hours** (production API) | +| **RPO** (Recovery Point Objective) | Maximum acceptable data loss | **1 hour** (MongoDB); **24 hours** (MinIO documents) | + +RTO/RPO are reviewed annually and after major architecture changes. + +--- + +## 4. Backup Requirements + +### 4.1 MongoDB + +| Parameter | Requirement | +|-----------|-------------| +| Frequency | Continuous oplog / hourly snapshots (production) | +| Retention | Daily: 30 days; Weekly: 12 weeks; Monthly: 12 months | +| Storage | Separate region/account from production | +| Encryption | Encrypted at rest (AES-256 or provider equivalent) | +| Access | DevOps Lead + break-glass only | + +**Collections in scope:** `companies`, `customers`, `users`, `tenders`, `notices`, `feedback`, `notifications`, and all domain collections. + +### 4.2 MinIO + +| Parameter | Requirement | +|-----------|-------------| +| Frequency | Daily incremental; weekly full sync | +| Retention | 30 days rolling | +| Scope | `files` and `documents` buckets (company docs, tender JSON, translations) | +| Encryption | Server-side encryption enabled | +| Versioning | Bucket versioning enabled where supported | + +### 4.3 Redis + +| Parameter | Requirement | +|-----------|-------------| +| Frequency | Daily RDB snapshot | +| Retention | 7 days | +| Note | Redis holds ephemeral cache/session data; rebuild acceptable within RTO | + +### 4.4 Configuration & Secrets + +- Infrastructure-as-code and config templates in Git +- Production secrets in secret manager (not backed up in plaintext) +- Secret manager backup per provider documentation + +--- + +## 5. Backup Security + +1. Backups classified **C3 Confidential** β€” same protection as source data +2. Backup storage not publicly accessible +3. Backup access logged and restricted to authorized DevOps personnel +4. Backup encryption keys managed separately from backup data +5. No backup data transferred to unauthorized regions (GDPR data residency compliance) + +--- + +## 6. Recovery Procedures + +### 6.1 MongoDB Full Restore + +1. Identify target recovery point (timestamp before incident) +2. Provision clean MongoDB instance or restore to staging first +3. Restore from snapshot / mongodump +4. Verify document counts and sample integrity checks +5. Update application connection string +6. Run application smoke tests (auth, tender list, company profile) +7. Monitor for 24 hours post-restore + +### 6.2 MinIO Restore + +1. Identify affected buckets/prefixes +2. Restore from backup or cross-region replica +3. Verify file accessibility via file store service +4. Re-run worker jobs for any missing derived data (translations) + +### 6.3 Partial Restore (Single Collection / Document) + +- Use point-in-time recovery or selective mongorestore +- Requires IC approval for production partial restores +- Audit log entry required + +--- + +## 7. Backup Testing + +| Test | Frequency | Success Criteria | +|------|-----------|------------------| +| MongoDB restore to staging | **Monthly** | Data integrity verified; app connects successfully | +| MinIO file restore (sample) | **Quarterly** | Random files readable and checksum-valid | +| Full DR simulation | **Annual** | RTO/RPO met in tabletop or live test | +| Backup job monitoring | **Daily** | All scheduled backups complete without error | + +Test results documented with date, tester, outcome, and remediation items. + +--- + +## 8. Responsibilities + +| Role | Responsibility | +|------|----------------| +| DevOps Lead | Implement and monitor backups; conduct restore tests | +| ISO | Verify policy compliance; include backup status in management review | +| Engineering Lead | Validate application behavior post-restore | +| IC (during incident) | Authorize production restore; communicate status | + +--- + +## 9. Failure Handling + +If a scheduled backup fails: + +1. Automated alert to DevOps on-call +2. Investigate and re-run within **4 hours** +3. If unrecoverable, escalate to P2 incident if production data at risk +4. Document failure and resolution in backup log + +--- + +## 10. Document Control + +| Version | Date | Author | Changes | +|---------|------|--------|---------| +| 1.0 | 2026-06-11 | Engineering | Initial policy | + +**Approval** + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| DevOps Lead | _Pending_ | | | +| ISO | _Pending_ | | | diff --git a/docs/security/policies/incident-response-plan.md b/docs/security/policies/incident-response-plan.md new file mode 100644 index 0000000..def0739 --- /dev/null +++ b/docs/security/policies/incident-response-plan.md @@ -0,0 +1,222 @@ +# Incident Response Plan + +| Field | Value | +|-------|-------| +| **Document ID** | POL-003 | +| **Version** | 1.0 | +| **Status** | Draft β€” Pending approval | +| **Owner** | Information Security Officer (ISO) | +| **Effective Date** | _Pending approval_ | +| **Review Cycle** | Annual (+ after every P1/P2 incident) | +| **ISO 27001 Reference** | A.5.24–A.5.28 β€” Incident management | + +Related: [Information Security Policy](./information-security-policy.md) | [Risk Assessment Matrix](../RISK_ASSESSMENT_MATRIX.md) + +--- + +## 1. Purpose + +This plan defines how the organization detects, responds to, contains, and recovers from information security incidents affecting the Tender Management System. It ensures consistent handling, timely notification, and post-incident improvement. + +--- + +## 2. Scope + +Covers security incidents involving: + +- Unauthorized access to TM systems or data +- Data breaches (PII exposure) +- Malware or ransomware +- Denial of service affecting production +- Secret/credential leakage +- Insider threats +- Third-party service compromises affecting TM + +--- + +## 3. Incident Classification + +| Severity | Label | Criteria | Response Time | +|----------|-------|----------|---------------| +| **P1** | Critical | Active data breach; production down; credential leak in public repo | Acknowledge ≀ 1 h; escalate immediately | +| **P2** | High | Suspected breach; partial outage; unpatched critical CVE exploited | Acknowledge ≀ 4 h | +| **P3** | Medium | Failed attack attempt; non-production compromise; policy violation | Acknowledge ≀ 1 business day | +| **P4** | Low | Near-miss; informational alert; minor misconfiguration | Acknowledge ≀ 3 business days | + +--- + +## 4. Incident Response Team (IRT) + +| Role | Responsibility | Primary | Backup | +|------|----------------|---------|--------| +| **Incident Commander (IC)** | Overall coordination, decisions, communications | ISO | Engineering Lead | +| **Technical Lead** | Investigation, containment, remediation | DevOps Lead | Senior Backend Dev | +| **Communications Lead** | Internal/external notifications, status updates | Product Owner | Executive Sponsor | +| **Legal / DPO** | Regulatory notification, GDPR assessment | DPO | External counsel | +| **Scribe** | Timeline, evidence, post-incident report | Assigned per incident | β€” | + +Contact list maintained separately (not in repository) with 24/7 reachability for P1/P2. + +--- + +## 5. Response Phases + +``` +Detect β†’ Triage β†’ Contain β†’ Eradicate β†’ Recover β†’ Learn +``` + +### 5.1 Detect & Report + +**Anyone** who suspects an incident must report immediately via: + +1. Direct message to ISO or DevOps Lead +2. Dedicated security channel (e.g. `#security-incidents`) +3. Email: `security@` (to be configured) + +Do **not** discuss suspected breaches on public channels until IC approves. + +**Automated detection sources (target state):** + +- SIEM alerts (auth failure spikes, error rate anomalies) +- Secret scanning in CI +- Dependency vulnerability alerts +- Cloud provider security notifications +- User/customer reports + +### 5.2 Triage + +IC performs within response time SLA: + +1. Confirm or rule out incident +2. Assign severity (P1–P4) +3. Activate IRT if P1/P2 +4. Open incident ticket with unique ID: `INC-YYYY-NNN` +5. Begin incident timeline log + +### 5.3 Contain + +Short-term actions to limit damage: + +| Scenario | Containment Actions | +|----------|---------------------| +| Compromised admin account | Disable account; revoke JWT; force password reset | +| Leaked API key / secret | Rotate credential; invalidate old tokens; audit access logs | +| Active data exfiltration | Block IP/rate limit; disable affected endpoint; snapshot logs | +| Ransomware / malware | Isolate affected hosts; preserve forensic images | +| DDoS | Enable WAF/CDN rules; rate limiting; contact provider | + +Preserve evidence: do not delete logs; snapshot affected systems before remediation where feasible. + +### 5.4 Eradicate + +- Remove attacker access (patch vulnerability, close misconfiguration) +- Scan for persistence (backdoors, unauthorized accounts) +- Verify root cause is addressed + +### 5.5 Recover + +- Restore services from clean backups if needed +- Monitor for recurrence (enhanced logging, 72-hour watch period) +- Confirm normal operation with smoke tests +- Communicate all-clear to stakeholders + +### 5.6 Post-Incident Review (Learn) + +Required for all P1/P2 incidents within **10 business days**: + +- Timeline reconstruction +- Root cause analysis +- Control gaps identified +- Corrective/preventive actions with owners and dates +- Update [Risk Assessment Matrix](../RISK_ASSESSMENT_MATRIX.md) if new risks identified +- Tabletop or walkthrough if process gaps found + +--- + +## 6. Communication Plan + +### 6.1 Internal + +| Severity | Notify | +|----------|--------| +| P1 | IRT, Executive Sponsor, all engineering β€” immediately | +| P2 | IRT, Engineering Lead, DevOps β€” within 4 h | +| P3 | ISO, relevant team lead β€” within 1 business day | +| P4 | ISO β€” log only | + +### 6.2 External + +| Condition | Action | Timeline | +|-----------|--------|----------| +| Personal data breach (GDPR) | Notify supervisory authority | ≀ 72 hours of awareness | +| Personal data breach (high risk to individuals) | Notify affected data subjects | Without undue delay | +| Contractual obligation | Notify affected customers | Per contract terms | +| Public disclosure | Press/ status page | IC approval only | + +DPO assesses GDPR notification requirement for any incident involving customer/company PII (assets A-004, A-005). + +--- + +## 7. Evidence Handling + +- Logs exported and stored in tamper-evident location +- Chain of custody documented for forensic artifacts +- Incident records retained for **3 years** minimum +- Access to incident evidence restricted to IRT and Legal/DPO + +--- + +## 8. Playbooks + +### 8.1 Credential Leak in Git Repository + +1. **Contain:** Revoke/rotate leaked secret immediately +2. **Eradicate:** Remove secret from git history (`git filter-repo` or BFG); force push with approval +3. **Investigate:** Audit usage logs for unauthorized access during exposure window +4. **Recover:** Deploy rotated credentials; verify services operational +5. **Learn:** Enable secret scanning in CI; review commit practices + +*Applies to risk R-013; FCM keys and MinIO credentials are high priority.* + +### 8.2 Suspected Unauthorized Admin Access + +1. Disable affected admin account(s) +2. Blacklist active JWTs in Redis +3. Review `pkg/audit` logs for anomalous actions +4. Force password reset and enable MFA +5. RBAC audit of actions performed during compromise window + +### 8.3 Production API Outage (Security-Related) + +1. Determine if attack-related (DoS) vs. infrastructure failure +2. If DoS: enable rate limiting, WAF rules, scale resources +3. If compromise: isolate, preserve logs, follow containment playbook +4. Status communication via Communications Lead + +--- + +## 9. Testing and Training + +| Activity | Frequency | +|----------|-----------| +| Tabletop exercise (simulated P1) | Annual | +| Contact list verification | Quarterly | +| Playbook review | Annual or after P1/P2 | +| Security awareness (incident reporting) | Onboarding + annual | + +First tabletop exercise target: **Q2 2026** (per [Risk R-023](../RISK_ASSESSMENT_MATRIX.md)). + +--- + +## 10. Document Control + +| Version | Date | Author | Changes | +|---------|------|--------|---------| +| 1.0 | 2026-06-11 | Engineering | Initial plan | + +**Approval** + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| ISO | _Pending_ | | | +| Executive Sponsor | _Pending_ | | | diff --git a/docs/security/policies/information-security-policy.md b/docs/security/policies/information-security-policy.md new file mode 100644 index 0000000..9d5d5c9 --- /dev/null +++ b/docs/security/policies/information-security-policy.md @@ -0,0 +1,156 @@ +# Information Security Policy + +| Field | Value | +|-------|-------| +| **Document ID** | POL-001 | +| **Version** | 1.0 | +| **Status** | Draft β€” Pending approval | +| **Owner** | Executive Sponsor | +| **Maintained By** | Information Security Officer (ISO) | +| **Effective Date** | _Pending approval_ | +| **Review Cycle** | Annual | +| **ISO 27001 Reference** | A.5.1 β€” Policies for information security | + +Related: [ISMS Foundation](../ISMS_FOUNDATION.md) | [ISO 27001 Roadmap](../ISO27001_ROADMAP.md) + +--- + +## 1. Purpose + +This policy establishes the organization's commitment to protecting information assets processed by the **Tender Management (TM) System**. It defines principles, responsibilities, and requirements that all personnel, contractors, and third parties must follow. + +--- + +## 2. Scope + +This policy applies to: + +- All employees, contractors, and third parties with access to TM systems or data +- The ISMS scope defined in [ISMS Foundation Β§3](../ISMS_FOUNDATION.md#3-isms-scope): `cmd/web`, `cmd/worker`, `cmd/scraper`, MongoDB, Redis, MinIO, and integrated services +- All information classified C2 (Internal) and above + +--- + +## 3. Policy Statement + +Management is committed to: + +1. **Protecting** the confidentiality, integrity, and availability of information assets +2. **Complying** with applicable legal and regulatory requirements, including GDPR +3. **Implementing** an ISMS aligned with ISO/IEC 27001:2022 +4. **Managing** information security risks through a documented risk assessment process +5. **Continuously improving** security controls via the Plan-Do-Check-Act (PDCA) cycle + +Information security is everyone's responsibility. No business objective justifies unacceptable risk to customer data or system integrity without documented risk acceptance by authorized management. + +--- + +## 4. Information Security Objectives + +| # | Objective | Measure | Target | +|---|-----------|---------|--------| +| O-1 | Protect customer and company PII | Data breach incidents | Zero confirmed breaches per year | +| O-2 | Maintain platform availability | Uptime of production API | β‰₯ 99.5% monthly | +| O-3 | Respond to security incidents promptly | P1 incident acknowledgment time | ≀ 1 hour | +| O-4 | Remediate critical vulnerabilities | Mean time to patch (Critical CVE) | ≀ 7 days | +| O-5 | Maintain security awareness | Training completion rate | 100% of in-scope personnel | +| O-6 | Progress toward ISO 27001 certification | Roadmap milestone completion | Per [ISO27001_ROADMAP.md](../ISO27001_ROADMAP.md) | + +Objectives are reviewed quarterly during management review. + +--- + +## 5. Roles and Responsibilities + +| Role | Responsibilities | +|------|------------------| +| **Executive Sponsor** | Approves this policy; allocates resources; chairs management review | +| **Information Security Officer (ISO)** | Operates ISMS; maintains risk register; coordinates audits and incidents | +| **Data Protection Officer (DPO)** | Ensures GDPR compliance; oversees DPIAs and data subject requests | +| **Engineering Lead** | Secure SDLC; code review; vulnerability remediation | +| **DevOps Lead** | Infrastructure security; secrets management; backups and monitoring | +| **All personnel** | Comply with policies; report incidents; complete security training | + +--- + +## 6. Core Security Principles + +### 6.1 Confidentiality + +- Access to information is granted on a need-to-know basis +- PII and credentials must not be disclosed to unauthorized parties +- Secrets must never be committed to source control or included in logs + +### 6.2 Integrity + +- Production changes require peer review and follow change management procedures +- Data modifications must be traceable through audit logs where applicable +- Input validation is mandatory at all API boundaries + +### 6.3 Availability + +- Critical services (API, database, object storage) must have documented recovery procedures +- Capacity and rate limiting must protect against abuse-related outages + +### 6.4 Defense in Depth + +Security controls are layered across application, infrastructure, and process levels. No single control is relied upon exclusively. + +### 6.5 Least Privilege + +Users, services, and processes receive the minimum access required to perform their function. + +--- + +## 7. Supporting Policies and Procedures + +This policy is supported by: + +| Document | ID | +|----------|-----| +| [Access Control Policy](./access-control-policy.md) | POL-002 | +| [Incident Response Plan](./incident-response-plan.md) | POL-003 | +| [Backup & Recovery Policy](./backup-and-recovery-policy.md) | POL-004 | +| [Acceptable Use Policy](./acceptable-use-policy.md) | POL-005 | +| [Risk Assessment Procedure](../procedures/risk-assessment-procedure.md) | PROC-001 | + +--- + +## 8. Compliance and Enforcement + +- Violations of this policy may result in disciplinary action, up to and including termination of employment or contract +- Regulatory breaches may result in legal liability and notification to supervisory authorities +- All personnel must acknowledge this policy upon onboarding and annually thereafter + +--- + +## 9. Exceptions + +Exceptions to this policy require: + +1. Written request with business justification +2. Risk assessment of the exception +3. Approval by ISO and Executive Sponsor +4. Time-bound validity (maximum 12 months) +5. Entry in the risk acceptance log ([Risk Assessment Matrix Β§5](../RISK_ASSESSMENT_MATRIX.md#5-risk-acceptance-log)) + +--- + +## 10. Document Control + +| Version | Date | Author | Changes | +|---------|------|--------|---------| +| 1.0 | 2026-06-11 | Engineering | Initial policy | + +**Approval** + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| Executive Sponsor | _Pending_ | | | +| ISO | _Pending_ | | | + +--- + +## 11. Distribution + +This policy is available to all in-scope personnel via the `docs/security/policies/` repository path and must be communicated during onboarding. diff --git a/docs/security/procedures/risk-assessment-procedure.md b/docs/security/procedures/risk-assessment-procedure.md new file mode 100644 index 0000000..f62f6fc --- /dev/null +++ b/docs/security/procedures/risk-assessment-procedure.md @@ -0,0 +1,177 @@ +# Risk Assessment Procedure + +| Field | Value | +|-------|-------| +| **Document ID** | PROC-001 | +| **Version** | 1.0 | +| **Status** | Draft β€” Pending approval | +| **Owner** | Information Security Officer (ISO) | +| **Effective Date** | _Pending approval_ | +| **Review Cycle** | Annual | +| **ISO 27001 Reference** | Clause 6.1.2 β€” Information security risk assessment | + +Related: [Risk Assessment Matrix](../RISK_ASSESSMENT_MATRIX.md) | [Information Security Policy](../policies/information-security-policy.md) + +--- + +## 1. Purpose + +This procedure defines how information security risks are identified, analyzed, evaluated, treated, and reviewed for the Tender Management ISMS. + +--- + +## 2. Scope + +Applies to all assets within the ISMS scope ([ISMS Foundation Β§3](../ISMS_FOUNDATION.md#3-isms-scope)) and all personnel involved in risk management activities. + +--- + +## 3. Roles + +| Role | Responsibility | +|------|----------------| +| **ISO** | Facilitates assessment; maintains risk register; reports to management | +| **Asset Owners** | Provide context on threats and controls for their assets | +| **Engineering / DevOps Leads** | Identify technical vulnerabilities and treatment options | +| **Executive Sponsor** | Accepts residual risks above threshold | +| **DPO** | Assesses privacy impact for PII-related risks | + +--- + +## 4. Risk Assessment Process + +``` +Context β†’ Identify β†’ Analyze β†’ Evaluate β†’ Treat β†’ Monitor β†’ Review +``` + +### 4.1 Establish Context + +Before each assessment cycle, confirm: + +- Current ISMS scope and asset inventory ([ISMS Foundation Β§4](../ISMS_FOUNDATION.md#4-information-asset-inventory)) +- Applicable legal/regulatory requirements (GDPR, contracts) +- Risk criteria (scales defined in [Risk Assessment Matrix Β§2](../RISK_ASSESSMENT_MATRIX.md#2-methodology)) + +### 4.2 Risk Identification + +Sources of risk information: + +| Source | Examples | +|--------|----------| +| Asset-based | Unauthorized access to MongoDB, MinIO data loss | +| Threat-based | Credential stuffing, supply chain CVE, insider threat | +| Vulnerability scans | govulncheck, container scans, penetration test findings | +| Incidents | Post-incident review findings | +| Audit findings | Internal/external audit nonconformities | +| Change requests | New AI integration, new data store, architecture change | + +Each risk receives a unique ID: `R-NNN` (sequential in risk register). + +### 4.3 Risk Analysis + +For each identified risk, document: + +| Field | Description | +|-------|-------------| +| Risk ID | Unique identifier | +| Threat | What could happen | +| Vulnerability | Weakness exploited | +| Affected asset(s) | Asset IDs from inventory | +| Likelihood (1–5) | Per scale in risk matrix | +| Impact (1–5) | Per scale in risk matrix | +| Inherent score | L Γ— I before controls | +| Existing controls | Current mitigations | +| Residual L / I / Score | After existing controls | + +### 4.4 Risk Evaluation + +Compare residual score against acceptance criteria: + +| Score | Level | Decision | +|-------|-------|----------| +| 1–4 | Low | Accept with monitoring | +| 5–9 | Medium | Treat within 6 months | +| 10–15 | High | Treat within 3 months | +| 16–25 | Critical | Immediate treatment; no acceptance without Executive approval | + +Risks above **Medium** must have a documented treatment plan before acceptance. + +### 4.5 Risk Treatment + +Select one or more options: + +- **Mitigate** β€” Implement control (preferred) +- **Transfer** β€” Insurance, vendor contract +- **Avoid** β€” Remove activity from scope +- **Accept** β€” Document in risk acceptance log with approver signature + +Treatment plan must include: owner, target date, actions, and expected residual score. + +### 4.6 Monitor and Review + +- Track treatment plan progress in risk register +- Re-score risks when controls are implemented +- Close risks only when residual score is at or below accepted level + +--- + +## 5. Assessment Triggers + +| Trigger | Action | +|---------|--------| +| **Scheduled review** | Full register review quarterly | +| **Major change** | Assess new/changed assets before production deployment | +| **Incident (P1/P2)** | Ad-hoc assessment within 10 business days | +| **New vulnerability (Critical)** | Assess within 48 hours | +| **Audit finding** | Add/update risk within 5 business days | +| **Annual comprehensive** | Full methodology re-validation | + +--- + +## 6. Major Change Assessment Checklist + +Use before deploying significant changes (new service, data store, third-party integration): + +- [ ] New assets added to inventory? +- [ ] Data classification determined? +- [ ] Threats and vulnerabilities identified? +- [ ] Controls designed before go-live? +- [ ] DPO consulted if PII involved? +- [ ] Residual risk acceptable or treatment plan in place? +- [ ] Risk register updated? + +--- + +## 7. Reporting + +| Report | Audience | Frequency | +|--------|----------|-----------| +| Risk register (current) | ISO, Engineering/DevOps leads | Continuous | +| Risk summary dashboard | Management review | Quarterly | +| Critical/High open risks | Executive Sponsor | Immediate + monthly | +| Treatment plan status | ISO | Monthly | + +Report format: [Risk Assessment Matrix](../RISK_ASSESSMENT_MATRIX.md) sections 3–4. + +--- + +## 8. Records Retention + +- Risk register versions: **3 years** +- Risk acceptance decisions: **3 years** +- Assessment meeting notes: **3 years** + +--- + +## 9. Document Control + +| Version | Date | Author | Changes | +|---------|------|--------|---------| +| 1.0 | 2026-06-11 | Engineering | Initial procedure | + +**Approval** + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| ISO | _Pending_ | | | +| Executive Sponsor | _Pending_ | | |