公开文集
0x01 信安之路安全产品
0x01 SRC 资产管理系统
001 企业资产有那些?
002 订阅最新 POC
003 IP 域名关联查询
004 公益权重数据
0x02 安全学习成长平台
001 成长平台视频参考
100 百分成就-学习心得-TOP 21 小伙伴
101 百分成就-学习心得-不想起床
102 百分成就-学习心得-不驚
103 百分成就-学习心得-aiDa0
104 百分成就-学习心得-起十二
105 百分成就-学习心得-Eyes
201 你为什么选择信安之路!
0x03 安全知识库
001 蜜罐运营专辑
0x04 自研蜜罐系统
0x02 Web 漏洞案例库
0x01 配置安全
001 header 安全配置
002 首页信息泄露
003 HTTP 访问控制 (CORS)
0x02 安全控制缺失
001 速率限制绕过
0x03 应用逻辑
0x03 小程序漏洞案例库
第一章:小程序渗透基础
1.1 微信小程序反编译与动态调试
1.2 微信小程序强制开启开发者模式
0x04 星球讨论知识问答
信息安全入门
学习方向选择
学习经验分享
安全产品研发
代码审计
物联网安全
APT
安全防御建设
安全建设经验
数据泄露监控
网络安全
终端安全
主机安全
产品安全
安全意识
数据安全
内部资产管理
安全管理
应急响应
网络安全架构
安全运营
业务安全
运维安全
渗透测试技术
信息收集
EXP/POC
web 测试
APP测试
内网渗透
0x05 代码审计小挑战
01 前端安全问题
101 script 标签下的 XSS
102 消息事件引发的 DOM XSS
104 常规评论 xss 漏洞
105 页面开放重定向漏洞
106 部分过滤的 xss 漏洞绕过
107 基于 DOM 的 XSS
108 CORS 配置错误
109 退出登录出 XSS
110 URL 重定向漏洞
111 CSRF 漏洞利用
112 JavaScript 代码注入
113 xss 绕过括号和反引号检测
02 文件操作类问题
201 Django 任意文件读取漏洞
202 php 后缀黑名单验证绕过上传
203 jsp 任意文件上传
204 jsp 代码中的 SSRF 漏洞
205 jsp 目录穿越漏洞
206 PHP文件包含漏洞
207 Django 本地文件包含
208 文件包含功能绕过
209 SSRF 跨服务端请求伪造
210 本地文件包含漏洞 windows
211 目录穿越漏洞
212 文件上传绕过
213 php 文件包含漏洞
03 注入类问题
301 由 SQL 注入引发的命令执行
302 php8 XML 实体注入
303 正则问题导致验证绕过
304 XPath 注入
305 典型认证 SQL 注入
306 数字型 SQL 注入
307 主机头(host header)注入
308 LDAP 注入
309 典型的万能密码漏洞
310 Ldap 注入漏洞代码
04 命令执行类问题
401 调用第三方工具时被劫持
402 原型污染导致命令执行
403 php array_map 代码执行
404 命令执行绕过检测
405 SSTI 模板注入
406 文件名注入 RCE
407 无防护命令执行
408 python eval 注入
409 绕过多个黑名单命令
05 业务逻辑类问题
501 django 认证 jwt 未验证 token
502 绕过权限检测执行命令
503 密码找回邮箱地址大小写绕过
504 DNS 重绑定问题
505 权限比对逻辑问题
506 越权访问其他用户的记录
507 用户注册问题
508 用户权限验证逻辑问题
509 PHP 判断两个变量相等逻辑问题
06 反序列化类问题
601 php 反序列化漏洞
602 python 反序列化漏洞
09 C语言问题
901 c 条件竞争
902 缓冲区溢出
903 通配符注入提权
0x99 AI 教你学安全
01-网络安全基础
Day-001-TCP-IP协议栈安全分析
Day-002-DNS协议安全与DNS劫持攻防
Day-003-IPv6 安全基础与过渡
Day-004-HTTP-HTTPS协议深度解析
Day-005-网络嗅探与流量分析技术
Day-006-防火墙原理与配置实践
Day-007-网络地址转换 NAT 安全分析
Day-008-路由协议安全 RIP-OSPF-BGP
Day-009-VLAN 安全与 VLAN-Hopping
Day-010-无线网络基础与安全 802.11
Day-011-网络访问控制 802.1X-NAC
Day-012-网络分段与微隔离设计
Day-013-负载均衡器安全配置
Day-014-CDN安全与防护
Day-015-NTP安全
Day-016-DHCP安全与攻击防护
Day-017-ICMP协议安全分析
Day-018-网络协议模糊测试基础
Day-019-网络流量基线建立
Day-020-网络取证基础
Day-021-网络入侵检测系统 NIDS
Day-022-网络入侵防御系统 NIPS
Day-023-网络流量加密与解密
Day-024-网络协议逆向工程基础
Day-025-网络性能与安全权衡
Day-026-SDN 安全
Day-027-网络虚拟化安全
Day-028-网络欺骗技术
Day-029-网络威胁情报应用
Day-030-网络容量规划与安全
Day-031-网络安全架构设计实战
02-Web 安全
Day-032-OWASP-Top-10-2021详解
Day-033-SQL 注入原理与手工检测
Day-034-SQL注入进阶报错注入与盲注
Day-035-XSS跨站脚本攻击基础
Day-036-XSS 进阶绕过与利用
Day-038-CSRF 跨站请求伪造
Day-039-文件上传漏洞
Day-040-反序列化漏洞基础
Day-041-PHP反序列化深入
Day-042-Java反序列化深入
Day-043-SSTI 服务端模板注入
Day-044-文件包含漏洞 LFI-RFI
Day-045-命令注入漏洞
Day-046-XXE-XML 外部实体注入
Day-047-反序列化漏洞进阶
Day-048-API 安全基础
Day-049-API认证与授权安全
Day-050-API漏洞挖掘实战
Day-051-文件上传漏洞进阶
Day-052-反序列化漏洞实战
Day-053-Web 安全综合实战
Day-054-移动安全基础
Day-055-Android 应用安全测试
Day-056-iOS 应用安全测试
Day-057-移动应用综合实战
Day-058-云安全基础
Day-059-AWS 安全实战
Day-060-Azure 安全实战
Day-061-GCP 安全实战
Day-062-云安全综合实战
Day-063-容器安全基础
Day-064-Docker 安全实战
Day-065-Kubernetes 安全实战
Day-066-容器安全综合实战
Day-067-API 安全进阶
Day-068-服务端请求伪造 SSRF 深入
Day-069-文件上传漏洞进阶
Day-070-反序列化漏洞实战进阶
Day-071-业务逻辑漏洞深入
Day-072-前端安全深入
Day-073-Web 安全综合实战
Day-074-云安全进阶
Day-075-移动安全进阶
Day-076-API 安全进阶
Day-077-前端安全进阶
Day-078-业务逻辑漏洞进阶
Day-079-反序列化漏洞实战进阶
Day-080-文件上传漏洞实战进阶
Day-081-SSTI 服务端模板注入进阶
Day-082-XXE-XML 外部实体注入进阶
Day-083-SSRF 服务端请求伪造进阶
Day-084-命令注入漏洞进阶
Day-085-文件包含漏洞进阶
Day-086-反序列化漏洞实战进阶
Day-087-文件上传漏洞实战进阶
Day-088-SSTI 服务端模板注入实战进阶
Day-089-XXE-XML 外部实体注入实战进阶
Day-090-SSRF 服务端请求伪造实战进阶
Day-091-命令注入漏洞实战进阶
Day-092-Web 安全综合实战
Day-093-GraphQL 安全
Day-094-JWT 与 OAuth2 安全
03-系统安全
Day-095-系统监控与检测
Day-096-主机防火墙配置
Day-097-系统审计与合规
Day-098-Linux 系统安全进阶
Day-099-Windows 系统安全进阶
Day-100-容器安全进阶
Day-101-容器编排安全进阶
Day-102-Linux 内核安全
Day-103-Windows 内核安全
Day-104-系统安全总结与实战
Day-105-Linux 系统安全基础
Day-106-Windows 系统安全基础
Day-107-容器安全基础
Day-108-系统加固技术
Day-109-日志分析技术
Day-110-威胁狩猎技术
04-应用安全
Day-111-安全编码规范
Day-112-输入验证技术
Day-113-输出编码技术
Day-114-错误处理安全
Day-115-会话管理安全
Day-116-认证安全
Day-117-授权安全
Day-118-数据保护安全
Day-119-日志安全
Day-120-API 安全
Day-121-微服务安全
Day-122-新兴技术安全概论
Day-123-DevSecOps 流水线安全
Day-124-云原生安全架构
Day-125-API 安全最佳实践
Day-126-安全编码规范
Day-127-SDL 安全开发生命周期
Day-128-威胁建模实战
Day-129-安全需求分析
Day-130-安全架构设计
Day-131-安全编码实践Java
Day-132-安全编码实践Python
Day-133-代码审计方法论
Day-134-静态代码分析SAST
Day-135-动态应用测试DAST
Day-136-交互式测试IAST
Day-137-软件成分分析SCA
Day-138-依赖漏洞管理
Day-139-安全测试自动化
Day-140-漏洞管理与响应
Day-142-OWASP-Top10-2024 详解
Day-143-CWE-Top25 分析
Day-144-漏洞挖掘方法论
Day-145-模糊测试技术
Day-146-逆向工程基础
Day-147-漏洞利用开发基础
Day-148-漏洞复现与验证
Day-149-漏洞披露流程
Day-150-CVE 申请与管理
Day-151-漏洞赏金计划
Day-152-等保2.0详解
Day-153-GDPR 合规实践
Day-154-数据安全法解读
Day-155-个人信息保护法与合规指南
Day-156-个人信息保护法解读
Day-157-ISO-27001 信息安全管理体系
Day-158-SOC-2 合规与审计
Day-159-PCI-DSS 支付卡行业数据安全标准
Day-160-网络安全审查办法解读
Day-161-数据出境安全评估办法
Day-162-应用安全评估实战
Day-163-红蓝对抗演练
Day-164-安全应急响应
Day-165-安全运营中心建设
Day-166-应用安全总结与展望
05-密码学
Day-167-密码学基础
Day-168-对称加密算法详解
Day-169-非对称加密算法详解
Day-170-哈希函数与数字签名
Day-171-密钥管理与PKI
Day-172-TLS-SSL 协议详解
Day-173-国密算法详解
Day-174-认证与密钥协议
Day-175-随机数生成与熵源
Day-176-椭圆曲线密码学详解
Day-177-后量子密码学详解
Day-178-高级密码学主题
Day-179-密码学行业应用精选
Day-180-常用加密算法原理与实现
Day-181-密码学总结与展望
06-渗透测试
Day-183-渗透测试方法论
Day-184-信息收集技术详解
Day-185-漏洞扫描技术详解
Day-186-漏洞利用技术详解
Day-187-渗透测试中的漏洞利用框架
Day-188-漏洞利用框架与 Metasploit 深入
Day-189-渗透测试中的 WAF 绕过技术
Day-190-渗透测试中的模糊测试技术
Day-191-渗透测试中的代码审计与静态分析
Day-192-渗透测试中的密码哈希破解技术
Day-193-渗透测试报告编写指南
Day-194-Web 应用渗透测试
Day-195-渗透测试中的 API 安全测试
Day-196-渗透测试中的 GraphQL 安全测试
Day-197-渗透测试中的前后端分离应用测试
Day-198-渗透测试中的小程序安全测试
Day-199-渗透测试中的浏览器安全测试
Day-200-OAuth-SSO安全测试
Day-201-渗透测试中的业务逻辑漏洞测试
Day-202-渗透测试中的厚客户端安全测试
Day-203-渗透测试综合实战演练
Day-204-内网渗透技术详解
Day-205-渗透测试中的内网信息收集进阶
Day-206-渗透测试中的域森林渗透技术
Day-207-渗透测试中的权限维持技术
Day-208-渗透测试中的横向移动技术
Day-209-渗透测试中的痕迹清理与反取证技术
Day-210-渗透测试中的数据窃取与 Exfiltration 技术
Day-211-渗透测试中的内部威胁与数据泄露测试
Day-212-渗透测试中的物理安全渗透
Day-213-社会工程学攻击技术
Day-214-移动应用渗透测试
Day-215-云安全渗透测试
Day-216-渗透测试中的容器与 Kubernetes 安全渗透
Day-217-渗透测试中的 Serverless 安全测试
Day-218-渗透测试中的微服务安全测试
Day-219-物联网安全渗透测试
Day-220-工业控制系统安全渗透测试
Day-221-无线网络安全渗透测试
Day-222-数据库安全渗透测试
Day-223-渗透测试中的供应链安全测试
Day-224-红队演练技术详解
Day-225-渗透测试中的红队基础设施搭建
Day-226-渗透测试中的威胁情报与狩猎
Day-227-渗透测试中的综合指纹识别技术
Day-228-自动化渗透测试技术
Day-229-渗透测试中的运维安全测试
Day-230-渗透测试中的区块链与智能合约安全测试
Day-231-渗透测试中的漏洞管理与修复验证
Day-232-渗透测试法律与合规
Day-233-后渗透攻击技术详解
Day-234-渗透测试中的人工智能应用
Day-235-漏洞利用开发深入
Day-236-云原生渗透测试深入
07-应急响应
Day-237-应急响应概述与核心概念
Day-238-应急响应流程框架
Day-239-CSIRT 团队组建与职责分工
Day-240-应急响应工具包准备
Day-241-应急响应法律与合规要求
Day-242-安全事件检测方法与指标
Day-243-云原生应急响应
Day-244-日志收集与分析技术
Day-245-网络流量分析与异常识别
Day-246-自动化响应与 SOAR
Day-247-端点监控与 EDR 技术
Day-248-威胁狩猎方法论
Day-249-威胁情报在检测中的应用
Day-250-数字取证基础与证据链管理
Day-251-内存取证技术
Day-252-磁盘取证与文件恢复
Day-253-网络取证与数据包分析
Day-254-云环境与容器取证
Day-255-恶意代码静态分析技术
Day-256-恶意代码动态分析技术
Day-257-恶意代码行为分析方法
Day-258-逆向工程基础与工具
Day-259-沙箱技术与自动化分析
Day-260-事件隔离与遏制策略
Day-261-威胁根除与系统修复
Day-262-系统恢复与数据重建
Day-263-业务连续性计划
Day-264-事件复盘与经验总结
Day-265-APT 攻击事件复盘分析
Day-266-勒索软件事件响应实战
Day-267-数据泄露事件处置流程
Day-268-内部威胁调查与取证
Day-269-综合应急响应演练
08-安全运维
Day-270-安全运营中心 SOC 概述
Day-271-安全监控指标体系
Day-272-安全告警管理
Day-273-安全可视化与仪表盘
Day-274-监控工具选型
Day-275-日志采集技术
Day-276-日志标准化与解析
Day-277-日志存储与归档
Day-278-日志分析技术
Day-279-日志合规要求
Day-280-SIEM 架构与设计
Day-281-关联规则引擎
Day-282-高级关联分析
Day-283-UEBA 用户实体行为分析
Day-284-威胁狩猎
Day-285-SOAR 基础概念
Day-286-剧本设计
Day-287-自动化响应技术
Day-288-安全工具集成
Day-289-SOAR 度量与优化
Day-290-安全基线管理
Day-291-漏洞管理流程
Day-292-补丁管理策略
Day-293-变更安全管理
Day-294-合规审计技术
Day-295-7x24 安全运营
Day-296-安全事件管理流程
Day-297-安全运营度量体系
Day-298-持续改进机制
Day-299-安全运维综合演练
Day-300-云原生安全运营
Day-301-AI 与机器学习安全运营
Day-302-安全自动化脚本实战
09-移动安全
Day-303-移动安全威胁概述
Day-304-移动设备安全架构
Day-305-移动操作系统安全模型
Day-306-移动应用权限管理
Day-307-移动端数据加密
Day-308-330-Android 安全合集
Day-309-Android 安全架构
Day-310-Android 组件安全
Day-311-Android 权限与隐私
Day-312-Android 逆向工程
Day-313-Android 应用加固
Day-314-iOS 安全架构
Day-315-iOS 应用沙盒机制
Day-316-越狱与反越狱
Day-317-iOS 逆向工程
Day-318-iOS 企业分发安全
Day-319-移动安全开发生命周期
Day-320-移动应用安全测试
Day-321-移动应用加固技术
Day-322-移动威胁防护
Day-323-移动安全合规
10-云安全
Day-324-云计算安全模型
Day-325-责任共担模型
Day-326-云安全威胁模型
Day-327-云安全合规框架
Day-328-云安全架构设计
Day-329-AWS IAM 安全
Day-330-AWS 网络安全
Day-331-AWS 存储安全
Day-332-AWS 安全监控
Day-333-AWS 安全最佳实践
Day-334-Azure AD 安全
Day-335-Azure 网络安全
Day-336-Azure 存储安全
Day-337-Azure 安全中心
Day-338-Azure 安全最佳实践
Day-339-容器安全基础
Day-340-Kubernetes 安全
Day-341-Serverless 安全
Day-342-云原生 DevSecOps
Day-343-云安全态势管理 CSPM
11-物联网工控
Day-344-物联网安全概述
Day-345-IoT 通信协议安全
Day-346-IoT 设备安全
Day-347-IoT 平台安全
Day-348-IoT 应用安全
Day-349-工业控制系统概述
Day-350-工控协议安全
Day-351-PLC 安全
Day-352-SCADA 系统安全
Day-353-工控安全防护
12-综合与总结
Day-354-安全职业发展路径
Day-355-安全技术趋势展望
Day-356-安全建设方法论
Day-357-经典攻防案例复盘
Day-358-安全学习资源指南
Day-359-信息安全行业求职指南
-
+
首页
数据安全
上周业务线领导跟我聊,虽然我们数据值钱,但它现在还没产生价值,我们投入太多钱去保护这部分数据的话压力比较大,我们还不像有融资那种,可以先烧钱,不能高估安全,安全只是保障及服务,没有安全业务照样跑。那有了安全,你也不能保证不出问题 ### 0x01 如何利用文件加密来预防数据安全? 我当年给建了一个给外面批量传文件的系统,网络加密+应用加密,解决了这个问题。事先打好包,配置做成标准文件,单独发,拿到以后手工导入就行,不是 gdp,当时是基于法国的一个产品,做的二次开发,另外,我们还联合业务部门做了一个流程,这种需求都经业务部门确认后科技再制作标准文件发给外面机构 请教各位大佬,目前国内做全磁盘加密的是不是只有亿赛通?明朝万达也有吧,中软、veracrypt、truecrypt、磁盘加密,厂商工程师都不是很推荐 windows 自带的和 AD 搞在一起,会不会有什么隐患?如果不和 AD 搞一起,每个人自己管自己的密钥,万一丢了。。。怎么搞?出方案容易,我怕后面别人找我麻烦 ### 0x02 DLP 能够解决数据泄露的问题? **我理解中的DLP几个基本逻辑,** 1、数据扫描发现(分为文件内的详细数据、文档格式、文件类型等) 2、然后打标签 3、根据标签执行动作(加解密、拦截、删除、日志记录等) 4、堵塞数据传播通道(物理、过滤、显示水印),每个动作都可以用来做很多场景 对于内网非结构化数据的防泄漏,是不是可以把所有业务系统对接网盘,集中存放,在网盘里面做敏感数据打标签,在网盘入口做杀毒,出口做加密,加上在线编辑和文件检索等便利性功能。对于散落在终端上的敏感文件,是不是可以智能识别一轮,加上使用者人工确认一轮,逐步把终端上的文件也都加上标签,再配合 DLP 和外设管控水印什么的,也就差不多了。 最近遇到一个终端DLP防泄漏的场景,之前也讨论过很多,有一个场景:以图片为载体的文件,如何提高图片上敏感信息识别效率,进而防止员工故意泄漏?大佬们是怎么做的?OCR引擎识别效率太慢了。 买的dlp都是集成的OCR集群,可是效果不好,识别效率不高。 DLP 产品越到后面深入下去,会发现很多问题,场景太多了,ueba大部分针对内部用户的的异常行为,往往基于AI分析,误判断也大,只能慢慢细致调整。 个人感觉模式啥的都是死的,结合数据做起来才是活的,针对内部最高优的风险定制解决策略,结合不同风险场景进一步产品化,就能逐步演化成一个平台化产品了,这样 ROI 也高 其实现在很多中小企业都是监控 报警,然后一大堆误报!(特别是没有机器学习能力的情况下,还不太好优化,只是不断优化报警规则和阈值) 先减少误报 能转起来后一步一步推动吧,阈值什么的,基本的告警规则能用起来就不错了 我们在一项项加,已经内置不少通用模型了,未来路线图早都设计好了,只是工程资源少要慢慢做。ForcePoint是单独卖UEBA,再收一份钱,再上一套es,跟折腾个SIEM投入差不多呢,我们可买不起 多说两句哈,绝大部分DLP实施场景,指纹机制落地都遇到了极大问题,数据量增长很快,到底哪些数据应该取指纹,变成了无法解决的管理问题,业务部门谁来拍板哪些数据放进池子里,以什么频度放,需要占用多少人手,谁来审计保证此过程的有效性,等等 数据安全要取得比较好的效果,管理基础是绕不过去的坎,但是现在太多国内企业的数据安全出现扯皮、成本太高的根本原因就是因为没有一个比较良好或者合理的底层基础,然而对于这些组织来说,这又何尝是信息安全能推动的变革呢?信息安全只是需要站在这些基础之上,基础不牢哇。 嗯嗯是的,管理要求很高。SIEM只给安全团队用,大家觉得很复杂但不会影响管理层和员工。DLP的用户也包括管理层和普通员工,日常展现和准确度和干扰频度等等更复杂,实际上的推进难度更大,所以我们很理解和佩服管数据安全的甲方同学 机密信息在数据载体上的安全和业务&客户数据的数据安全是两个不同的技术体系。 API数据安全,还是老一套方法论应用到新场景。也分内部威胁和外部威胁。自动识别高价值API(有敏感数据传输的),梳理资产和服务界面,发现攻击面,还原行为可调查,建立行为基线,发现异常。老生常谈 实时发现很难,投入大不合算,我觉得就是事后审计发现,达到威慑作用就行了,你可以作弊试试,发现就加入黑名单 也不一定是理论派和实践派,主要是体制和理念,就像风险接受程度,金融和互联网企业差距很大,最后的控制方案也不一样 然后后台大数据跑一下,可以预估出来现在可能的违规人数,这个是不做的损失,简单想想,就知道该不该做了,什么问题都解决掉,那安全,风险没边界了。。。 明明可以用管理手段解决的问题,何必一定要用技术来解决?如果违规成本低,每次只罚差价,你就算发现效率再高又能如何? 比方说闯红灯抓起来判刑,需要评估抓人判刑的成本,社会影响,对比下带来的收益。如果不是重大风险,国内很难落实,你看地铁安检投去多少,设置了多少岗位。 建议在内网环境中部署数据防泄密系统,保持某单位现有的工作模式和员工操作习惯不变,不改变任何文件格式、不封闭网络、不改变网络结构、不封闭计算机各种丰富的外设端口、不改变复杂的应用服务器集群环境,实现对企业内部数据强制透明加解密,员工感觉不到数据存在,保证办公效率,实现数据防泄密管理,形成“对外受阻,对内无碍”的管理效果。 员工未经授权,不管以任何方式将数据带离公司的环境,都无法正常查看。如:加密文件通过MSN、QQ、电子邮件、移动存储设备等方式传输到公司授权范围以外(公司外部或公司内没有安装绿盾终端的电脑),那么将无法正常打开使用,显示乱码,并且文件始终保持加密状态。只有经过公司审批后,用户才可在授予的权限范围内,访问该文件。 1) 在不改变员工任何操作习惯、不改变硬件环境和网络环境、不降低办公效率,员工感觉不到数据被加密的存在,实现了单位数据防泄密管理; 2) 员工不管通过QQ、mail、U 盘等各种方式,将单位内部重要文件发送出去,数据均是加密状态; 3) 存储着单位重要数据的U 盘、光盘不慎丢失后,没有在公司的授权环境下打开均是加密状态; 4) 员工出差办公不慎将笔记本丢失,无单位授予的合法口令,其他人无法阅读笔记本内任何数据; ### 0x03 针对员工的 IM 管控如何做? 请教各位大佬,在内部IM通信管控都是怎么做。 大部分人都习惯IM直接传文件作为内、外部沟通渠道,直接掐断这个渠道担心反弹很大 我们准备用终端DLP来管控文件操作,同时建立了统一的对外数据交换平台,用于内外文件和数据传输 统一对外数据交换平台,这个有商用的产品推荐吗,想了解一下,这个是我们自研的,主要是数据流通工作较多,建立了一个安全的平台,统一对文件进行加密和留痕等操作 建议可以从优先局部部署客户端(内部好说话),收集所有用户体验(择取优化)、从开审计模式收集的用户常用行为,形成画像,在决定策略场景。 目前准备先对一下核心人员,监控用户信息和商业信息的关键字段,主要是常规的数据出口。初期先做上报和统计,然后再逐步的进行弹窗提示或是阻断封禁。也是怕影响太大 主要还是一些文档性质的文件,对大小限制的用处有限。 至于审计现在只是用深信服AC做一些审计,IM性质的外发只能审计到文件名 对,先做无感知的收集,然后再考虑强硬一点的策略,尽量降低办公影响。当然如果有高层强力意志的支持,那也可以开始就强硬一些 我们当前主要场景是用户通过Im渠道传输文件、运维区域代码上传频繁、区块链hash字段的内容较多。 因为DLP对用户,是比较不好交代,尽量慢慢让其习惯成自然,温水煮青蛙。 如果能有商用产品能做到敏感字眼外发弹窗提醒不阻断的话就舒心了--------这个定制开发应该容易做的,文件外发的时候先进行敏感信息扫描。但是文件大的时候扫描效率很低,拷贝可能比较花时间。 更人性化的就是识别到敏感信息自动发起审批流程,由相关授权人员审批通过后就可以外发了。需要和相关系统对接,开发量较大。 如果要和企业的审批工单挂钩,好像都没有,定制化开发难度大 如果你们是固定IP能和人对上,能监控外发文档的流量大小,每人每月限制流量100M,超出需审批否则阻断,然后每周晒流量外发排名,每月减小流量10M,大概10个月就可以直接阻断了。当然要有外发的其他合理渠道而不是用IM的方式,一点策略供参考。 可以生成邮件抄送给相关部门主管,这个前提是策略的关键字匹配策略得足够精确,要不每天部门主管收到一大堆邮件,肯定会有意见的 加上通报机制,那是不是每人外传文件都得考虑下,但这里面就一定会有用户反弹,要求增加个人流量,故只能起到警戒作用。 引申出来的问题就是敏感字眼谁定义,需要周期更新这些敏感字眼。-----------------------如何提搞敏感信息识别的准确率,这个有什么好的方法吗 先装个AGENT,然后本地先识别外发文件的行为,吓吓大家,效果会好一些。 ### 0x04 员工自带设备如何管理? 终端上的,防病毒,管控软件,dlp 软件,都是不同厂商的。这些产品的日志有做统一分析吗?就拿最简单的如何确保这些终端软件都是正常运行的(准入是一种方式) 数据能到个人设备,个人电脑,个人网盘,企业就管不了了,只能在泄密后追责。你想管到什么地步呢,手伸太长就侵犯隐私了,企业区域可以禁止往个人区域转移的 首先要规定,BYOD也需要同样遵守公司的终端管理规定,该装啥装啥,离职时该由IT删数据或是格式化也都做了,还是看企业的策略,是给员工电脑补贴,希望员工自己BYOD呢,还是入职都主动提供电脑,员工自己BYOD属于不必要的行为 安全的边界要划清,业务逻辑或风控应属于业务安全的范畴,科技部门的安全管不了,还是需要业务部门风控 1.先在本地,由其主管陪同,对电脑进行检查。 2.当面清除回收站,对硬盘剩余空间进行随机复写 3.签字走人 关键是离职流程里面有针对离职员工电脑处理这个环节,不管是企业配发还是自己的 嗯..我们的情况复杂得多...员工分布到县城,自带设备,离职不规范.. 从道理来说,自己带电脑,企业给补贴,这种也算企业临时征用个人电脑用于办公,个人电脑需要遵守管理规定 这个深入讨论下去没有尽头,员工带笔记本回家,打开机密文档拿手机挨个拍怎么办?所以需要全面的数据管理,把各种场景都想到 一般用户(非管理员)其实管控还好,主要是针对IT(权限管理者)尤其是针对可将数据提前转移的人员,将大量数据转移的路径严控才是关键,比如管理员的USB、云盘等的最后授予权限有高位者掌握。一旦有泄漏,直接追责高位者。 如果,员工在你这干了5年,出去了根据自己的经验,能够独当一面,这是沉淀,如果,他需要抄着你那的资料才能干个主管,不抄干不了,那属于偷窃 个人觉得,对于自带设备,有个形式,流程合规,好多东西,分不清的。所以要拉上他的业务主管过来协助确认。 其他哪些文档,我就是自己想拷贝走,心里也要考虑合适不合适,真有哪些文档是自己的心血,也得脱敏处理 就像大家经常在群里说,希望大家给分享点哪方面材料,不都是为了参考吗?谁还拿去全抄袭呢?有时候人的记忆力是最大的障碍,虽然以前干过这件事,但是时间久了就会忘记,留下一些文档可以当做参考,对于员工来说也是情理之中 跟你们一样。保密协议直接明确了,利用公司资源(办公资源、业务资源等)输出的一切资产都属于公司。一般只让拷贝照片之类,任何带商秘的文件都不允许带走,但是技术上没法做到100%控制。 各家企业不一样。我们内网桌面云,办公相关都在内网,日常文件交换已经审核了一次,所以理论上不应该有敏感文件在个人家庭电脑。 说的场景肯定有,但是讨论这种问题最好限定个场景,不然讨论不着边际, 也没个结论。 办公用公司的电脑。byod只限于移动设备,离职走byod注销流程。有需要从办公电脑烤走个人资料的,联系dlp团队。 ### 0x04 第三方合作伙伴的安全怎么做? 我自己考虑两个方面 :数据开放前的评审,包括数据量级、敏感程度(包含哪些字段)、第三方的安全评审、开放方式及存在风险 ; 数据开放后,第三方公司的定期审计、数据的使用范围及安全控制、数据泄露影响分析等。 鉴权、日志、字段收敛、资质审核、数据染色、脱敏、加密,保密协议,还有一个大招,是自己有云,让他们上云 对的,现在是加工过的,做个关联,数据还在行内的。 以后会涉及到一些原始数据开放了。但是我们有安全的上游责任啊。非常怕第三方的信息泄露 赋予对方使用权,存在两方面风险:对方再次外发给第三方,以及对方数据滥用,你把数据给了合作伙伴,合作伙伴再次外发给第三方,你来负责吧? 一说api就想到api防护的风险。 我们传输上应该还是会专线+数据加密的方式。 历史问题难搞,新建是最容易规范化的,传输加密了,到对端应用还是要解密的,密钥谁控制 这个目前是两方的密钥管理员。 头疼的问题在于说制度等定好了, 数据在行内都好控, 一旦开放后,落地到第三方就很头疼了,不能只靠一纸合约。 还需要很多落地的技术方案。 这种的话 数据染色会好点 起码知道从哪个使用方泄露出去。 三种模式:(从使用对象上:第一种在物理空间场景有限制,无法支撑终端浏览数据,只是让别人过来跑算法。而第三种是可以面向最终人的) 1,让合作伙伴在招行的云上跑程序,云上有数据外传管控,合作伙伴只能拿走结果,而不拿走原始数据 2,如果不具备1的条件,必须数据外发合作伙伴,可以用数据加密(结合脱敏、水印或染色),再加上保密协议转移风险达成威慑 3,放大招(成本高、但管控效果最强):采用TDF(可信数据格式),把数据加密和安全堡垒技术结合起来,加密和密钥管控技术兜底(未许可数据管控),使用数据采用特定软件或硬件终端增强(防止使用滥用,已解密数据非法外发) 从技术上,第一种是采用物理边界控制实现数据所有权不转移(数据不出招行IDC),第二种是采用加密技术实现数据所有权不转移(通过加密和密钥管控,外加安全堡垒技术) 第一种都放私有云上了为什么会有空间限制? 对公司没限制。但对合作伙伴来说,第一种存在一定限制,比如对方不愿意把算法给公司,或者对方还有自己数据和结合计算 所以第三种是说要求所有业务系统包括第三方需要支持TDF文件 (先不用说MPC多方计算、FHE全同态加密等这种目前侧重于学术研究的技术),数据共享的本质问题是使用权和所有权没法区分,从技术上,合作伙伴拥有数据使用权,同时也意味着拥有了所有权。而数据脱敏、染色水印等作用有限,或者容易被绕过。由于数据外发具有隐蔽性,所以保密协议难以奏效,TDF本质上在解决使用权和所有权的区分 外发数据的部分加密(或脱敏)、染色(或水印),主要成本在于辨识哪些数据要加密(前提是还不影响接收方正常使用)。从加密算法本身效率极高,即使是国密SM4加密算法,单颗CPU也可以跑到130Gbps,分分钟全加密 现在这些数据防护技术新术语,比如染色是现在业界已经达成共识的技术语言了么?还是一些安全产品厂商的市场宣传措辞? “数据染色”这个词我也是近期从群友这里现学的,刚才Google了半天没找到数据染色这种提法,我觉得应该不算是产业共识语言 举个例子,大美团要把一些高价值数据共享给伙伴A,比如每天某个品类的xxx数据量,Top 30的XXX数据,但你只希望合作伙伴A只获得使用权(看到数据,或每分钟只能看20条),而无法外发给第三方(本质是美团把所有权给了A) TDF适用于面向合作伙伴A的受控共享(A可以是个人,支持离线使用),涉及两个关键技术: 1,把高价值数据、商业秘密信息加密后(Payload数据),再和解密机制及权限规则(元数据),封装到一个数据胶囊,发给A,美团按规则下发密钥、也可以按规则收回密钥。首先用密码实现对数据的管控 2,美国情报部门使用TDF是在专用终端上,专用终端本身难以被逆向。专用终端确保了即使你有了对应数据的密钥,但仍然无法拷贝外发 透明加密的权限颗粒度很粗,而TDF可以很细。甚至可以定制逻辑,但是我们目前覆盖不到的外发场景,比如短信外发,监管报送,有相同的特征就是接收端不可控,专用终端主要就是为了解密和使用吧? 封装到数据胶囊 保障了身份的权限控制 和 加密,主要还是在保密性上, 但是并没有控签名,似乎并没太在意完整性 ### 0x05 数据库安全审计如何搞?  有上数据库审计的工具,说实话多在事后,还真没注意过实时预警的 是被黑客直接盗取数据库的。那么数据库加密产品,对这类攻击是否能起到防护作用? 1,把系统部署在腾讯云,云虚拟环境采用高性能国密软件,应用内建密码安全,同时结合腾讯云上的国密HSM确保密钥安全。采用KMIP交互密钥避免厂商锁定 2,对外服务南北向通信安全,采用QQ国密浏览器+腾讯云的国密ADC,全程国密TLS无死角。身份认证基于SM2算法 3,落盘存储加密采用高性能SM4算法,同时用基于SM3的HMAC保持数据完整性 4,在应用系统中结合用户身份还原,把数据解密与基于ABAC的访问细控结合,打造无法绕过的数据安全防护。进一步的,在数据解密点提供高置信度的数据访问审计 5,再配合一套数据安全风控系统,全程追溯无死角 6,数据全生命周期数据安全防护,传输+存储+使用 数据泄露这层,应用的账户/人这个粒度,其实是很重要的,数据库层的保护手段针对这个,基本是无解的。对于酒店这样的体系更是如此,万豪如何泄露的不清楚,国内某家店的泄露,我倒是有些技术线索,一些店的接待电脑被植入了专门木马,木马通过应用查询接口获取会员数据。 在16年打掉的几个窃取电商数据的专业黑产团伙,也是这种套路。这种东西针对某个具体行业应用定制的木马,没有一家安全厂商的产品可以查杀。 只要数据需要被应用前端在开放环境中使用(多个分支机构,外包客服,移动应用场景)的,在后端怎么保护也难以真正的保护。 ### 0x06 黑产获取敏感数据有哪些办法? 1)组织严密,由挑头的分头联系。下面分写马的,植入的,卖数据的。挑头的分头联系,之间互不认识,只拿钱干活。 2)写马写定向马,过杀毒检测。植入由植入的人去应聘大电商客服,管的不严的应聘时找机会插u盘植入,管的严就真当一段时间客服,给一些电脑植入。样本针对性强,散布只在具体行业内(一些检测有无安装针对的行业应用来判断是否散播,并只通过篡改特定应用的组件来和特定应用一起加载激活),所以没有安全厂商产品可以检测他们的样本,只有阿里的电商安全客户端去查。数据搞回来后,新鲜及时的订单数据找客户卖(一般是诈骗团伙),中间还有黑产的交易担保。 3)专业诈骗团队作案极其专业,深山老林作案,ups+4g,交流通讯和数据落地的机器上,都装主机还原卡。一有异常,按还原键,破坏证据。 4)产业链里,最底的是搞技术的。写了牛逼的马,还要和阿里对抗,才拿了不到十万。 ,最后还得进去,因为证据最实锤。 5)我了解的真正定向大批量搞行业数据的团伙都不是远程漏洞这条链路来的。爬,中间劫持,收买,打入内部植入是核心手段 自己的体会,安全的痛点:一是黑产的专业化、分工协作、利益和目标一致的内驱力,将成果最大化;而企业的业务目标和科技战略虽然在Paper上是一致的,但落地和执行就陷入各自为政、异化的境地;在技术上我们追求用户体验和便捷,管控还是以业务优先为主,在安全和体验的平衡中试错;行业和企业的业务模式确定了业务场景,难以突破,萧规曹随,多分支、跨地域、B/S架构,都是现实的存在。 我手上还有几个定制的专门针对淘宝卖家的木马样本。功能很简单,就是针对几个特定的进销存管理软件偷数据,也没有特殊的系统行为,不会触发杀软主防。 主要网安法和gdpr都有披露要求,做的越好就越多披露。做得差感知不到反倒可以不披露。所以制度安排上是有些问题的 那银行为了应对木马泄露数据风险,是不是应该把黑市里的木马找几个买下来,研究怎么能检测出来? 银行问题不大。银行分支机构相对管理严格。而且这种针对型样本不会在黑市上有,把你自己的业务终端的应用相关文件收上来做分析才能找到端倪。 其实我也一直带着这方面的疑问,为什么黑产从业者遍布五湖四海,互相没见过面,甚至没接触过,为什么能配合如此默契而且高产,大企业的正规力量反而很难做到,现在终于明白了 ### 0x07 数据分类分级怎么落地? 一开始其实确定不了,只能要求 leader 背书。而且安全的责任,可能不在于需求是不是真的,而是需求是否合理、是否安全 我们在关键数据的流通审核上,是需要安全和法务一起审批的。但是业务系统自身的权限,一般由申请方和业务方自行决定 建议做分级策略,比如说,业务系统分不同等级,核心系统/公共平台强制安全测试和代码检测。同样,修复也分级,高危以上的必须修复,其他的可以排计划。SDL 推进也是,一开始可能是只做安全测试,根据漏洞类型和等级分布在推下一步,逐步向安全需求、安全架构推进 权限是可以设置有效期的,但是一般业务方配置时都会申请较长,为了平衡安全和业务使用,我们也准备对权限默认期限做个限制。另外对于标注为敏感的接口,会重点关注和审计,同时操作进行完整留痕,这种口子一泄露就是一大批数据 这就又回到数据分类分级了,我们关心的敏感数据到底有哪些类型,可能有些时候,部门架构,内网红人,老大花名都是敏感数据 戴总,数据的级别你们怎么定义的啊?尤其是动态方面的,拍脑袋~安全先定义,然后跟业务征求意见 针对关键的、敏感的数据流通做联合审批,那对于敏感程度是如何界定的?我们一般针对影响公司信誉层面的会提高审批等级,上升到业务风控部层面,会对流通的数据做评估,这个流程相对较时间长,但是效率低。 ### 0x08 企业基于数据安全保护的目的能不能使用和记录已经合法采集的个人隐私数据? 昨天一个群里讨论,企业基于数据安全保护的目的能不能使用和记录已经合法采集的个人隐私数据。我的理解如下: 1)隐私保护首先体现在采集授权上,如果数据未经过业务合法采集而基数据安全保护需要额外采集的,需要向用户明示原因和用途经过用户授权。 2)已经经过业务合法采集的数据,隐私保护体现在数据用途上。如果个人用户数据除了授权的业务使用外,仅用于已获得业务授权的企业范围内,为保护个人数据安全目的进行使用和记录,应该无需额外授权。 3)如果个人数据仅用于已获得业务授权的企业范围内,为保护个人数据安全目的进行使用和记录,也需要获得授权,我们目前所有的日志,审计系统,基于内容检测和分析的安全系统,都会有较大问题。但我们知道安全与合规是不可能离开这些系统的,当然也可以在用户授权里作为授权项把这块加进去,但这些安全系统很难实现像业务系统一样能区分用户授权与非授权的数据。除非作为隐私协议的标准项。 4)必须承认即使基于数据安全的目的的使用和记录个人数据,也可能带来个人数据的二次泄露风险以及滥用误用风险。相关产品必须提供保护措施(加密,脱敏,授权,二次审计等)保护个人数据安全,对这些产品的使用企业也需要有流程和控制来保护个人数据的二次泄露和误用滥用风险。 5)其实现在相关风险最大的还不是这些安全产品本身,相对好控制二次风险。而是一些业务系统日志以及日志流转上,数据比较分散,数据接触面广,这个是后面比较重点需要解决的。 隐私保护和数据安全,需要很多安全产品支持落地,但从目前的政策和监管趋势看,一些自身产品设计和业务管理流程中的坑很容易引火上身,甚至体现在一些很细致的规则的点上,比收集环节的设计,收集什么数据类型,用户录取的,还是系统权限获取的,第三方系统给的还是给了第三方什么数据,频率如何,有没有敏感数据,以及数据是出还是入方向,这些很细的点都需要掌握清楚,所以甲方的产品经理的安全观,开发人员和安全人员对于隐私政策的理解,很重要很重要。 个人理解,隐私保护重要以满足数据主体权利的相关要求,数据安全仅是保障隐私保护的一种手段,首先重点要考虑收集数据的最小化以及合法性目的,就算企业有完备的数据安全保护能力,但所收集的数据如果超出目的范围,还是与隐私保护相违背。其次,企业要有能力关注数据在内部的流动,能够确保数据没有滥用以及不会失控流转到第三方等风险风险,确保企业使用个人数据与隐私声明的一致性。此外,要结合数据的分类分级考虑,同样隐私数据也分一般个人数据与敏感个人数据,针对不同类别的个人数据所采取的收集方式,包括隐私声明的要求,处理和使用方式都不同。还有,隐私保护另一个重点是如何保障个人主体权利的行使,包括数据删除、数据限制、撤销同意等,往往这些是企业隐私保护实施过程中的难点。 ### 0x09 数据安全相关的工作规划如何做? 一、近期工作——现状评估和整改,能快速出效果! 1、梳理业务数据导出功能,非必要就关闭,增加线上导出审批,完善导出权限、日志审计等功能; 2、梳理线上数据共享上下游,把控传递数据的合规,以及对传输方式(对库同步、http或dubbo等)和约束对方数据安全存储及不再第三方共享; 3、 梳理内外接口,身份认证、加密和鉴权、幂等性,以及数据最小化合规约束。——前期可做些简单的,后期上专业API数据安全方案(中期); 4、 梳理线下数据共享上下游,指定传递人、传递介质,以及在合同上约束安全保护及不再第三方共享; 5、 后台数据修正和导出,走线上审批,均由指定运维人员通过堡垒机操作 6、 git和svn权限管控,快速清理离职或岗位调整已不在项目组中的人员,本地电脑DLP(这个周期长); 7、 利用开源的工具(如gsil等)快速搭建github数据外泄监控平台,或利用携程云安全监控,事件驱动快速整改,快速震慑; 8、 梳理外网http服务,权限改成https,保障B/S架构数据传输安全; 9、梳理数据采集是否合规,特别是大数据这块,爬虫机制适合合理,数据采集是否合规; 10、梳理现有公文或其他途径数据披露机制是否得有些安全控制,比如内容审核人、发放范围、查看权限等; 11、制定、颁发和及时宣贯数据安全管理制度、源码安全管理制度、数据泄露惩罚制度等相关数据安全制度。 ........................ 二、中期——往往涉及到采购,周期有些长,不易出成果! 1、数据资产全面梳理和分类(大工程),根据具体场景实施安全措施,同步开展其他的数据安全工作; 2、生产数据加密,自己开发加密平台或采购; 3、测试环境或展示数据脱敏,自己开发或采购; 4、上邮件外发审计系统,避免敏感文件外传,同时发布邮件外发数据安全制度,比如条款有外发敏感信息时要抄送给领导; 5、上网行为管理,过滤外网网盘等访问; 6、管控IM、远程协助软件(如TV等)的使用,使用内部IM,外部IM只能发文字不能发文件等策略管控,以及对应制度制定、颁发和宣贯到位! 7、上终端或网络的DLP,监测数据防泄漏; 8、上数据库安全审计系统,实现监测数据库的安全操作审计等功能; 9、上API数据安全方案,进行数据标签和数据流跟踪保护; 10、上水印,自己开发或采购; 11、上销毁和擦除设备,对敏感文件使用后进行及时销毁,对敏感磁盘数据进行擦除等; ......................... 三、长期——持续改进优化了! 1、 持续优化前面的各种数据安全管理措施。 2、上数据资产自动化发现和分类系统,自动分析敏感数据,预警数据安全风险,如合规等,可定义为高大上的数据态势感知平台。 ...................... 数据流动那块是难点,工作量大,标记、识别,感觉放在中期来搞好些,不容易出成绩效果 沈总,老板会问你:1.为什么要做这些事情?2.做这些事情的价值在哪里?3.如果从这些事情里面让你选择,只能选三个做,你会选择哪三个?为什么? 近期工作当中,有些比较好落地,时间而已;有些恐怕第一要考虑的是业务连续性与用户体验的变化(业务数据导入导出的管控,若就数据出入而言很好实现,按照最小够用原则就好,但是往往因业务系统之间相互调用的关系的复杂性,那么明确清晰的梳理工作很重要,这是个长期过程,因为要兼顾业务,这恐怕是个大前提),然后再落实数据管控标准; 甲方的好处就是接触面比较广,对安全工作思考相对更立体多维一些,但相对来说没有乙方那么自由。从乙方到甲方,PPT编制从纯技术描述变成要从业务讲故事,要求生动、紧凑…精雕细琢… 即便讲清楚,也属于理想化价值,管理层是需要看到可量化的成效,才有可能被管理层研究、投入的可能性,评价衡量标准很重要吧,是的 后继是治理体系 运营体系 技术体系 一系列的工作,但如果没有一个懂行的被信任的安全负责人,做很多事情都会事倍功半 我们现在刚建成这个平台,已经在一些项目上试用。形式上可以看到原先用户需求说明书中没有的、或者不完善的安全需求,在使用这个平台后,安全需求内容可以做到非常丰富。一般情况下业务人员、或者是研发人员不太能够专业的提出到底有哪些安全需求,这个平台就是来帮助提出需求的。通过情景式的交互,可以生成需求、设计和测试用例。另外我们还把标准化的组件和解决方案也集成进来了,直接使用标准化的安全相关的代码即可,无需编程人员自行编写,回避了水平不高的编程人员带来的漏洞。最起码这个工具中集成了各类监管文件要求,通过交互,能够识别你的需求需要满足哪些监管要求,会自动生成符合监管要求的需求、设计和测试用例。 这个平台是解决开发安全问题的,从需求阶段开始就必须要求考虑安全需求,当然最终是否满足安全需求,最后一道关是安全检测。当所有测试结束后、上线前,安全团队需要进行安全检测,也就是渗透测试,根据内部定义的漏洞价级别,判定是否允许上线。 情景式,指的是交互式。平台提供交互式问答,掌握你要提安全需求的系统,是什么架构的、用于什么业务的、满足几级等保要求的,等等,然后自动生成需求书、设计文档和测试用例。 我理解,这个坑是不是这几个意思: 1.这个平台之所以能够生成需求、设计和测试用例,是因为内部集成了安全需求场景,比如支付类交易,正因为平台上已经把支付类交易面临的安全场景已经内置了,所以才能生成对应的需求、设计和测试用例。那么问题来了,谁来内置这些东西?没错,这就是安全运营需要做的,安全团队必须要有人不断把各类安全应用的场景内置进来,没有?对不起,那不能生成对应的需求!这就是坑。 2.标准化组件,这个也是要不断收集、归纳,和总结的,把各个项目共性的代码收集起来,编写成统一的代码,然后要进行大量测试。 “情景式”体现在几个方面,一是指平台使用的交互式,见时总的释义;二是指在stride建模导出安全需求基线时,更突出的将系统功能场景化,比如转账场景,登陆场景等,旨在固化常见的系统登陆类场景。目标是将开发安全能力统一化,标准化,解决开发安全依靠个人能力的问题。 两种方式,一种是要求开发人员去使用这个平台,二是安全人员协助他们,需求不分级,没有红线需求,开发人员懵逼,场景一多需求一堆,我们帮开发裁剪后量还是很大,这个还依赖于开发安全体系的建设,要建立一系列的制度、规则和流程,与CMMI的过程管理融合,我觉得要区分平台本身能力和使用两个维度的问题。 而且具体是否实现需求我们目前也没有好的方法,精力跟不上,依赖于开发自查和渗透,其实这是不够的,一方面有制度要求,一方面要建立规则要大家都去遵守,一方面使用流程工具去约束开发生命周期的管理。其实我们也知道,前面那些都是虚的,只有最后的安全检测是最后能把关的,有精力前面那些工作可以多做些,没精力那就给安全团队最后把关的权利。 还是要配合研发自己的措施,我们研发现在也上了代码走查、审计,甚至自己搞安全测试,情景式安全需求平台从业务场景出发生成需求,内置的都是些基础的,比如转账,登录这些是基础的,还有许多不同业务场景,先期和他们梳理了一些场景,目前看还是得依赖于自己,他们“造需求能力”有限。 ### 0x10 客户数据泄露如何排查? 客户办了业务就被推销电话,这个大家有碰到过么? CISO开展工作的4个策略:1.事件驱动. 2.自顶向下 3.自下向上 4.划水式 这个线上线下渠道太多,都不知道怎么查了 ? 有一些工作思路,但是不保证会有结果: 1. 收集营销电话知道的用户信息,比如姓、名字、手机号、业务信息等 2. 排查能够明文查询到此类信息的内部业务系统(重点是客服、电销等外包比较多的岗位),必要时增加留痕和审计,看看是否有帐号或数据异常。这个群内有大佬在这个方向创业。 3. 排查业务是否有短信触达用户,是否包含以上信息。第三方运营商泄露是一个重要的渠道。 4. 排查是否有第三方查询接口输出过以上信息,必要时可以考虑投毒测试 5. 建议关键字段在业务系统中脱敏或加密,对所有解密请求进行留痕审计 还有一种情况就是客户因为办了业务,所以手机装了相关的app,然后客户手机上的其他app采集了这个手机的软件列表,然后这个其他软件上送信息给外面大数据公司,从而推断出客户办了某种业务 ? 对,有些小的场景,比如第三方软件采集、手机系统开通短信分析、用户帐号密码或登录凭证泄露等,都可能导致此类用户信息泄露 3和4的可能性比较高,内部作案一般不会那么傻逼,立刻卖,一查就能查到谁查询信息了,比较明显,而且数据量也不大,风险大 直接客服话术就是经排查,未发现我行有信息泄露渠道,可能您手机上的某些app采集了我行的业务开通信息短信和app安装信息,请关注手机app上的权限情况并即时清理 第三点有几个工作思路: 1、内部建立统一短信发送平台:对短信发送模板进行审核、尽量降低业务数据泄露点;对所有短信发送记录留痕,记录运营商渠道信息,用于此类客诉聚类,看是否有运营商的指向性; 2、用未办理业务的手机号对不同运营商进行投毒测试
myh0st
2022年1月17日 15:21
分享文档
收藏文档
上一篇
下一篇
微信扫一扫
复制链接
手机扫一扫进行分享
复制链接
Markdown文件
分享
链接
类型
密码
更新密码