|
1 | | -# security-program-starter |
| 1 | +# Security Program Starter |
2 | 2 |
|
3 | | -A portfolio-ready security program repository that demonstrates practical cybersecurity governance, incident response planning, and lightweight risk management. |
| 3 | +A practical cybersecurity-governance repository for incident response, risk management, repeatable security operations, and business-facing security communication. |
4 | 4 |
|
5 | | -This repository is designed to showcase an employer-friendly blend of: |
6 | | -- Incident response documentation |
7 | | -- Security operations process design |
8 | | -- Risk register management |
9 | | -- Business-aligned security communication |
10 | | -- Documentation quality and maintainability |
11 | | - |
12 | | -It is intentionally defensive and organizational in nature. It does not include exploit code, offensive tooling, or destructive capabilities. |
| 5 | +This project complements my engineering repositories by focusing on the organizational side of trustworthy systems: policies, roles, escalation paths, risk decisions, and the procedures people need when technology fails or behaves unexpectedly. |
13 | 6 |
|
14 | 7 | ## What is included |
15 | 8 |
|
16 | | -### 1. Incident response program documents |
17 | | -Core program documents that define how an organization prepares for, responds to, and learns from security incidents. |
| 9 | +### Incident response program documents |
| 10 | +Core documentation for preparing for, responding to, recovering from, and learning from security incidents. |
| 11 | + |
| 12 | +### Scenario runbooks |
| 13 | +Action-oriented playbooks for common events, including: |
18 | 14 |
|
19 | | -### 2. Runbooks |
20 | | -Actionable, scenario-specific playbooks for common security events: |
21 | 15 | - Ransomware |
22 | 16 | - Phishing |
23 | 17 | - Account compromise |
24 | | -- Lost device |
| 18 | +- Lost devices |
25 | 19 | - Suspicious login activity |
26 | 20 |
|
27 | | -### 3. Templates |
28 | | -Reusable forms and structured templates for: |
| 21 | +### Reusable templates |
| 22 | +Structured material for: |
| 23 | + |
29 | 24 | - Incident reporting |
30 | 25 | - Post-incident reviews |
31 | 26 | - Risk assessments |
32 | 27 | - Vendor security reviews |
33 | 28 | - Business impact assessments |
34 | 29 |
|
35 | | -### 4. Lightweight risk register |
36 | | -A simple CSV-based risk register suitable for small businesses, startups, student projects, or early-stage governance programs. |
| 30 | +### Lightweight risk register |
| 31 | +A CSV-based risk register suitable for small organizations, student environments, prototypes, and early-stage security programs. |
| 32 | + |
| 33 | +### Validation tooling |
| 34 | +Python-based checks help verify that the risk register maintains the expected structure and scoring values. |
| 35 | + |
| 36 | +## Why this project matters |
37 | 37 |
|
38 | | -### 5. Validation tooling |
39 | | -A small Python validation script and tests to ensure the risk register has the expected structure and scoring values. |
| 38 | +Secure systems depend on more than secure code. Organizations also need clear ownership, defined response authority, usable procedures, documented assumptions, and a way to reason about tradeoffs. |
40 | 39 |
|
41 | | -## Why this repository matters |
| 40 | +This repository demonstrates my interest in connecting technical controls with operational reality. The same questions appear in both governance and engineering: |
42 | 41 |
|
43 | | -Many technical portfolios focus only on code. This repository demonstrates the ability to: |
44 | | -- Build repeatable security processes |
45 | | -- Communicate clearly with leadership and stakeholders |
46 | | -- Align operational security with business risk |
47 | | -- Create documentation that teams can actually use |
48 | | -- Think like a future security analyst, GRC professional, incident responder, or security manager |
| 42 | +- Who is authorized to act? |
| 43 | +- What evidence supports the decision? |
| 44 | +- What happens when a control fails? |
| 45 | +- How is the event recorded and reviewed? |
| 46 | +- What risk remains after mitigation? |
49 | 47 |
|
50 | | -## Quick start |
| 48 | +Those questions also inform my work on cyber-physical systems and trustworthy automation. |
51 | 49 |
|
52 | | -Clone the repository and review these files first: |
| 50 | +## Start here |
| 51 | + |
| 52 | +Review these files first: |
53 | 53 |
|
54 | 54 | - `docs/security-program-overview.md` |
55 | 55 | - `docs/incident-response-policy.md` |
56 | 56 | - `runbooks/ransomware.md` |
57 | 57 | - `risk_register/risk_register.csv` |
58 | 58 |
|
59 | | -To validate the risk register locally: |
| 59 | +Validate the risk register locally with: |
60 | 60 |
|
61 | 61 | ```bash |
62 | 62 | python -m venv .venv |
63 | | -source .venv/bin/activate |
| 63 | +source .venv/bin/activate # Windows: .venv\Scripts\activate |
64 | 64 | pip install -e ".[dev]" |
65 | 65 | python tools/validate_risk_register.py risk_register/risk_register.csv |
66 | | -pytest |
| 66 | +pytest |
| 67 | +``` |
| 68 | + |
| 69 | +## Portfolio context |
| 70 | + |
| 71 | +Security Program Starter shows the governance and response side of the same broader engineering philosophy behind my other projects: make trust explicit, preserve evidence, define authority, anticipate failure, and design systems and procedures that remain understandable under pressure. |
| 72 | + |
| 73 | +Related work: |
| 74 | + |
| 75 | +- [BattleReef Marine Controller](https://github.com/DCMedic/BattleReef-Marine-Controller) |
| 76 | +- [SOC Log Triage](https://github.com/DCMedic/soc-log-triage) |
| 77 | +- [Secure Notes API](https://github.com/DCMedic/secure-notes-api) |
| 78 | +- [About / Portfolio](https://github.com/DCMedic/about-dcmedic) |
0 commit comments