JoshGouvisis/security-policy-document-set
GitHub: JoshGouvisis/security-policy-document-set
提供符合NIST CSF 2.0框架的基础安全政策模板。
Stars: 0 | Forks: 0
# Veridian货运与物流 — 安全政策文档集
**角色:** 安全分析师(模拟 — 首位安全人员)
**政策类型:** 基础GRC政策开发
**项目:** 投资组合项目3
## 概述
本项目模拟了加入一家公司作为其首位专职安全分析师,并从头开始构建基础安全政策集的经验。虚构公司Veridian货运与物流在此次合作开始时没有正式的安全文档。领导层在一位直接竞争对手发生事件后,将勒索软件视为首要关注点,企业客户也越来越要求将安全声明作为合同条件。
开发了三项政策以建立基础:一项是《可接受使用政策》,规定了员工如何与公司系统和数据进行交互;一项是《事件响应政策》,定义了Veridian如何检测、响应和从安全事件中恢复;还有一项是《访问控制政策》,规定了在整个员工生命周期中如何授予、维护和撤销对系统和数据的访问权限。每项政策都与NIST网络安全框架2.0保持一致。
## 关于Veridian货运与物流
| 属性 | 详细信息 |
|-----------|--------|
| 员工 | 总部和两个区域办公室共有约300人 |
| 工作人员 | 混合型,有大量远程工作人员 |
| 基础设施 | AWS(云),Microsoft 365(电子邮件、协作、文档) |
| 应用程序 | 定制的物流跟踪网络应用程序,SaaS人力资源、薪酬和CRM平台 |
| 数据 | 客户PII(姓名、地址、联系方式),通过第三方处理器处理的支付卡数据 |
| 合作开始时的安全态势 | 没有安全团队,没有书面政策,IT部门兼职处理安全事务 |
| 关键风险驱动因素 | 竞争对手事件后的勒索软件担忧;企业客户要求安全声明 |
## 政策文档
| 文件 | 描述 |
|------|-------------|
| `acceptable-use-policy.md` | 规定员工在混合环境中使用Veridian系统、设备、电子邮件、数据和个人设备的规定 |
| `incident-response-policy.md` | 事件定义、严重程度分类、响应生命周期、升级路径和事件后审查要求 |
| `access-control-policy.md` | 完整的账户生命周期(配置、修改、取消配置)、多因素认证要求、特权访问控制以及季度访问审查 |
## NIST CSF 2.0映射
| 政策 | NIST CSF功能 | 子类别 |
|--------|---------------------|---------------|
| 可接受使用 | 保护 | PR.AT-01, PR.AC-01, PR.AC-03, PR.DS-01, PR.DS-05, PR.PS-01 |
| 事件响应 | 检测、响应、恢复 | DE.AE-02, DE.AE-03, DE.CM-01, RS.MA-01, RS.MA-02, RS.AN-01, RS.AN-03, RS.MI-01, RS.CO-02, RS.CO-03, RC.RP-01, RC.CO-01 |
| 访问控制 | 保护 | PR.AA-01, PR.AA-02, PR.AA-03, PR.AA-05, PR.AC-01, PR.AC-03, PR.AC-04, PR.AC-07, PR.PS-01 |
《事件响应政策》有意触及框架的最多功能,涵盖检测、响应和恢复,因为有效的事件响应需要跨越所有三个方面的能力。《访问控制》和《可接受使用政策》都基于保护功能,反映了这些是旨在在事件发生之前降低事件发生可能性和影响的风险预防控制措施。
## 我学到的
连续为同一家公司编写三项政策,让我学到了一些我认为仅通过阅读政策是无法学到的知识。最困难的部分不是编写规则,而是弄清楚为什么每项规则对Veridian来说都是必要的,并确保每个部分都反映了实际环境,而不是任何公司都可能使用的通用语言。
访问控制政策是我最惊讶的一项。我进去时认为它主要关于给人提供正确的系统访问权限。我花最多时间的地方是取消配置和访问审查,这些都是在访问权限授予之后发生的事情。这才是真正的风险所在,也是我能够最清楚地看到实践中出错的地方。有人改变了角色,却保留了旧访问权限。有人离职了,但他们的账户却活跃了数周。这些都不是假设场景,它们是真实组织中最常见的访问控制失败。
事件响应政策是最具挑战性的,因为它必须足够具体,以便在真实事件中实际使用,同时仍然是一项政策,而不是技术操作手册。正确划分严重程度等级需要最多的迭代。我不断问自己,是否有人能在凌晨2点阅读等级描述并迅速确定他们的情况是否符合条件。这成为了我测试语言是否足够清晰的标准。
可接受使用政策一开始感觉最简单,但BYOD和数据处理部分迫使我仔细思考Veridian的混合工作团队以及他们存储客户PII和处理支付数据的事实。一个通用的AUP无法涵盖这些具体内容。在整个过程中,让这些政策感觉真正属于这家公司,而不是模板,是我的目标。
## 展示的技能
- 与NIST CSF 2.0对齐的安全政策开发
- NIST CSF子类别映射
- 事件严重程度分类和升级设计
- 访问控制生命周期管理,包括取消配置
- 以政策格式面向商业受众的写作
- 将框架要求转化为操作控制
## 关于我
拥有12年企业风险管理经验的网络安全分析师。CompTIA Security+认证(SY0-701)。Google网络安全证书。正在申请ISC2 CC。CRISC候选人。总部位于亚利桑那州凤凰城。
[LinkedIn](https://linkedin.com/in/joshgouvisis) | [GitHub](https://github.com/JoshGouvisis)
标签:AWS, DPI, Microsoft 365, NIST CSF 2.0, PII, ProjectDiscovery, SaaS平台, Streamlit, 人工智能安全, 合规性, 员工培训, 基础架构安全, 安全意识, 安全策略, 安全认证, 应急响应计划, 提示词设计, 支付卡数据, 数据保护, 物流行业, 网络安全, 访问控制, 远程工作安全, 防御加固, 隐私保护