企业安全建设实践[更新中]

dalerkd

已于 2023-08-17 23:13:14 修改

阅读量179

点赞数

分类专栏：深造之旅实践规划文章标签：安全网络

于 2023-07-23 22:44:44 首次发布

本文链接：https://blog.csdn.net/dalerkd/article/details/131885458

版权

深造之旅同时被 3 个专栏收录

114 篇文章 1 订阅

订阅专栏

实践

87 篇文章 2 订阅

订阅专栏

规划

39 篇文章 0 订阅

订阅专栏

文章目录

企业安全建设实践

这里的安全建设指的是：
对外服务的Web产品/其他产品的安全增强的实践过程。

企业安全建设实践

笔者原是一家上市公司的逆向人员，后伴随业务发展逐渐成长为一名网络安全专员，受托对公司的对外网络产品服务进行安全提升工作。中间经历了安全提升过程中的种种挑战，积累了若干安全方面的经验，这里会分享一些对安全建设未来的思考、规划和展望。

在这个过程中查阅不少了网络资料，暂未发现相关完整记述式文章，更多是比较针对特定问题的讨论。

安全挑战不止于风险挖掘，还涵盖风险的挖掘和展示、团队协作，笔者为了找到这些问题的解决方案，在此过程中一直在做思考、寻找、借鉴、验证。所以此次寥做回顾，虽然不能完全适用不同规模的公司和业务场景，但如果有一些启发就算值得此文了。

本文将记述我是如何对所在企业进行产品(对外服务)风险挖掘的，以及该过程中的一些经验。

1. 背景 TODO

2. 阶段历程

2.1 盲挖

我从前年开始不断的给包括内网站点在内的各站点进行轻度挖掘，有来自于IT部门的安全委托，也有其他产品的安全风险评估。
这些作为一切的开始。

2.2 老产品

老产品主要集中在公司的对外服务Web站点，这些站点历史比较久远。但是承担着品牌宣传和设备服务售卖。

对老产品的挖掘使我收获第一枚漏洞。领导对这边也非常支持，通过购买学习课程等方式进行了较为深入的学习理解。

那时候对安全风险的认识还比较浅，涉及了很多协作上的挑战。（之后一一解决了）

这个过程中，一些密切部门的同事领导给予了不好的支持。

2.3 自动化与蜜罐

站点的内容太多，深度太深，所以将我挖掘常见漏洞的经验，摸索打造一套趁手的自动化工具基于爬虫。
从最基础的扫描，伴随挖掘类型的增加，扫描便利度的需求，一步步完善重构，最终形成了一套基于插件的自动化安全评估工具。
我把布置在了一台云服务器上，持续对各Web站点进行评估。

蜜罐也是我们一开始的探索方向之一。

2.4 受托黑盒

“你们的水平够不够？”“是否需要外部团队的支持？”
“我们经过你们的安全提升后，还会不会有问题？”

去年底，公司新能源客户找上门来。新能源部门属于非常独立的新部门，规模较大，新产品也很多。由于密切部门的朋友Y的牵线推荐，开始接手相关的新能源部门的安全评估工作。
这个过程我正受困于项目预测经验缺乏，我和朋友Y及团队的老Z组成安全小组进行首轮安全黑盒安全评估。这个过程很嗨，老Z教了我们如何使用Project进行协作规划，在最后两天完成了漏洞突破拿下了关键数据库服务，我们一起协作完成了第一份非常全面且正式的安全报告。

伴随第一份整改报告诞生后，搞定了对方的服务器，证明了我们的专业性和问题的严重性。部门客户的信任显著增强。

2.5 新能源设备风险评估

“你对竞标要求的XXX了解吗”
伴随第一期的渗透评估完成、其他部门的需求也纷至沓来。
新业务线对日益增长的业务规模的安全性表达了担忧。
而硬件设备的渗透挖掘需求是一个特别的领域。我们需要更多的积累。
我们接受了这一挑战。

2.6 第二期的挑战

“我们的安全规划是什么？”“我们的标准是什么”这是其他部门负责同事向我提出的疑问。伴随我们渗透工作的深入，我们需要自己的标准。

“标准”是个关键词。第一期其实已经做了较为广泛的扫描工作，让我们初窥我们当前服务设施。
标准化之旅，开始尝试各种技术解决面临的挑战。还需要我们引入更多业务的安全评估标准才行。
当第一期效果不错的情况下，需要进行第二次评估，你就不得不考虑以下问题：

这里的问题更深入：

如何确保风险挖掘的质量
1. 需要一种方法能对风险进行呈现和评估，以使我们较为直观地掌握可能的措施缺失之处
2. 风险挖掘的方法需要明确标准，以使我们能知道是否确实挖掘了该风险
周期性
- 风险挖掘方法需要可以被重复实施

挑战：
发现风险挖掘的过程无记录，只有结果。无法复测。也无法确保对多站点进行同样质量的安全评估。

解决：
测试用例技术
向好友Y请教初步掌握了测试用例技术。
尝试构建了一批标准化的安全测试用例，光是构建的过程，竟从一期的问题里又挖出一堆。
可见其标准化的威力。

挑战：
各安全问题非常分散，无法获知我们是否已经挖掘全面？
解决：
威胁建模技术
主要从微软的STRIDE技术和杀软的MITRE ATT&CK获得灵感。对当前的风险发生点进行建模。
形成了明确的分层的展示图形。
从左到右分别是：
硬件端 --> Web服务 --> 网关 --> 微服务 --> 中间件 --> 数据库/…

再将挖掘出所有的隐患映射到该图中。威胁建模图即完成。
这样我们即能从攻击角度，看我们不同层的薄弱点；又能防御角度，看我们的防御缺失之处。
此处也引出我们对防御体系建设的需求。

通过对威胁建模和测试用例技术引入，从可视化和规范化等几个角度为我们的二期灰盒评估进行了有力支撑。二期中我们还引入一些我们认可适合的安全评估内容，以拓展我们评估范围。

2.7 二期灰盒 TODO

关键词：标准化+业界自动化工具引入+整改推进
…

3 建设之路

3.1 安全事件应对 TODO

某短信攻击事件
…

3.2 防御体系构建

三方漏洞阻断体系
1. 后端依赖项公共化
2. 公共库定期评估和提升(挑战)与记录
3. 资金允许的情况下进行三方云组件托管
建立定期安全评估机制
- 以半年度和年度为优
基础防御
- 这个主要是WAF和配置与监测，要求定期查看和调整策略，例如：每周一次
纵深防御
- 这个主要考虑极端情况，即你前面的体系全部出现了问题，那么需要最后一种通知机制，告知你的服务器被搞了，赶快采取措施，一些服务器防御软件或者无侵入的有AWS的GuardDuty等。
缩小攻击面
1. 网络管控
  1. 新系统默认内网，转公网开放需要申请（不然神知道会在何时跑出一个充满安全漏洞的初期验证项目）
  2. 各种接口文档管理系统管控在内网
2. 无授权接口排查的管控
客户密码体系升级、密码标准建立健全