[{"content":"","date":null,"permalink":"https://puresecurity.com/zh/services/compliance/pci-dss-qsa-audit/","section":"安全服务","summary":"","title":"PCI DSS 4.0.1 QSA 审计与 AOC 认证"},{"content":"合规工作由在职 QSA 兼前 CISO 直接主导，他曾以受审方和审查方两种身份通过央行审查，服务过横跨 12 个亚太辖区的 100 多家金融机构。\n我们验证卡组织与监管机构真正要求的内容，并从缩小受评估范围入手，因为成本最低的审计对象，就是那些被划出范围之外的控制措施。本支柱适合需要可辩护认证、又不想陷入数月评估拖延的支付企业、金融科技和受监管企业。 #","date":null,"permalink":"https://puresecurity.com/zh/services/compliance/","section":"安全服务","summary":"","title":"PCI DSS 与法规合规"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/services/technical/penetration-testing/","section":"安全服务","summary":"","title":"人工主导渗透测试"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/services/governance/vciso-advisory/","section":"安全服务","summary":"","title":"虚拟 CISO（vCISO）顾问"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/services/technical/linux-hardening/","section":"安全服务","summary":"","title":"Linux 与基础设施加固"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/services/compliance/pci-dss-gap-assessment/","section":"安全服务","summary":"","title":"PCI DSS 差距评估与范围缩减"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/services/governance/third-party-risk-management/","section":"安全服务","summary":"","title":"第三方风险管理（TPRM）"},{"content":"工程工作由曾保卫国家关键基础设施、运营过 7x24 安全运营中心的工程师主导，而不只是评估过别人的系统。\n每项发现都附带经验证的证据、复现步骤，以及将修复长期固化所需的自动化。本支柱适合工程主导型组织：他们要的是项目结束后自己也能运行、测试和维护的安全成果。 #","date":null,"permalink":"https://puresecurity.com/zh/services/technical/","section":"安全服务","summary":"","title":"技术安全与工程"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/services/technical/api-application-security-review/","section":"安全服务","summary":"","title":"API 与应用安全审查"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/services/compliance/regulatory-compliance/","section":"安全服务","summary":"","title":"法规合规与框架对齐"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/services/technical/configuration-architecture-assessment/","section":"安全服务","summary":"","title":"配置与架构评估"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/services/governance/cyber-crisis-tabletop-exercises/","section":"安全服务","summary":"","title":"网络危机管理与高管桌面演练"},{"content":"我们提供承载问责的安全领导力：负责路线图、出面应对审计和企业客户审查、向董事会汇报安全事务。建议来自曾向董事会汇报、与 CFO 争取预算、并接受央行审查的前 CISO，因此沟通方式符合利益相关方的预期。\n本支柱适合需要可信安全领导力以赢得企业订单的成长型公司，以及需要独立高管视角、但不想承担全职高管招聘周期与成本的老牌组织。 #","date":null,"permalink":"https://puresecurity.com/zh/services/governance/","section":"安全服务","summary":"","title":"战略治理与领导力"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/services/technical/vulnerability-management/","section":"安全服务","summary":"","title":"漏洞管理与合规扫描"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/services/technical/dfir-retainer/","section":"安全服务","summary":"","title":"DFIR 常驻与内部调查"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/categories/","section":"Categories","summary":"","title":"Categories"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/tags/incident-response/","section":"Tags","summary":"","title":"Incident Response"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/categories/insights/","section":"Categories","summary":"","title":"Insights"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/tags/","section":"Tags","summary":"","title":"Tags"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/tags/thailand/","section":"Tags","summary":"","title":"Thailand"},{"content":"来自我们在泰国及亚太地区审计与工程一线的实务笔记：PCI DSS 范围决策、监管期望、加固基线，以及我们最常提出的问题。每篇文章都会说明我们观察到了什么、实际意味着什么，以及我们建议采取的行动。\n","date":null,"permalink":"https://puresecurity.com/zh/posts/","section":"安全洞察与公告","summary":"","title":"安全洞察与公告"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/","section":"全方位安全，负责任地交付","summary":"","title":"全方位安全，负责任地交付"},{"content":"没有组织会计划被入侵。但那些能够干净利落完成恢复的组织有一个共同点：他们在需要之前就准备好了证据。当事件降临（勒索软件攻击、内部人员外泄、账户失陷），两周恢复与两个月法律泥潭之间的差别，几乎总是由数月前在平静中做出的决定所决定。\n数字取证与事件响应（DFIR）准备，就是提前做出这些决定的学科。\n取证始于事件发生之前 #取证的第一条规则是：你没有保存的东西就无法调查。等到事件被发现时，你希望自己拥有的证据（日志、内存、网络抓包、文件元数据）早已消失：如果你没有提前配置的话。\nRFC 3227 这份证据收集的奠基性指南说得很直白：取证是一项规划纪律，而不是应急纪律。实际的准备意味着：\n集中化、脱离主机的日志：让攻陷一台服务器的攻击者无法顺手抹掉自己的痕迹。 与义务匹配的留存期：泰国 PDPA 和泰国央行指引都隐含着现实的留存窗口要求，留存不足本身就是一项发现。 时钟同步：让跨系统的时间线分析真正可行。 经过检验的证据监管链：让你收集的一切在法律或监管程序中站得住脚，而不是以\u0026quot;可能被篡改\u0026quot;为由被驳回。 这些都不光鲜。但事件来临时，每一条都是决定性的。\n为什么你的 IT 团队无法在压力下兼顾这件事 #事件进行中，内部团队要同时做三份工作：遏制损害、维持业务运转、回应管理层。取证是第四份工作，而且需要完全不同的心态：缓慢、有条不紊、带着对抗性思维，因为调查结果最终可能会摆到监管机构或法庭面前。\n这正是常驻服务的意义所在：与一支了解你环境的取证团队预先建立关系，按约定的 SLA 响应，并以可辩护的标准保存证据，而你的员工专注于恢复。另一种选择是在危机中现找取证公司，那会耗尽你最缺的资源：时间。\n速度是一项业务指标 #事件响应中有两个数字最重要：\nMTTD：平均检测时间。攻击者在你察觉之前活动了多久。大多数入侵是以周或月计的，而不是分钟。 MTTR：平均响应与恢复时间。从发现到遏制和恢复需要多久。 NIST SP 800-61 将整个事件响应生命周期围绕压缩这两个数字而展开。驻留时间每多一小时，就意味着更多的数据外泄、更多的横向移动和更多的法律暴露。检测工程和一份经过检验的响应计划，才是真正能推动这两个指标的两个杠杆。\nflowchart LR A[检测] --\u003e B[遏制] B --\u003e C[清除] C --\u003e D[恢复] D --\u003e E[事后复盘] E --\u003e|反哺| A style A stroke:#0EA5E9,stroke-width:2px style E stroke:#10B981,stroke-width:2px 泰国的监管现实 #事件不仅仅是 IT 问题，还是一个通报问题。泰国 PDPA 要求数据控制者履行泄露通报义务，泰国央行则期望金融机构在规定时限内通报重大网络安全事件。如果在通报中陈述的事实有误，或者无法用证据支持你的说法，就会把一次安全失败叠加成一次合规失败。\n取证准备让你能够做出准确、及时、经得起辩护的通报，而不是惊慌之下的猜测。\n如果今天下午发生事件，你知道从哪里着手吗？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 我们的 DFIR 常驻与内部调查让一支响应团队随时待命，提供保证 SLA 和法庭可采信的证据处理； 网络危机桌面演练则在你需要之前对计划进行压力测试。\n","date":"2026-08-11","permalink":"https://puresecurity.com/zh/posts/dfir-readiness-incident-response-thailand/","section":"安全洞察与公告","summary":"","title":"泰国的数字取证与事件响应准备"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/tags/apac/","section":"Tags","summary":"","title":"APAC"},{"content":"现代组织不是一家孤立的公司，而是一张由供应商、SaaS 平台、云提供商和集成商组成的网，每一方都握着你数据和声誉的一根线。当其中一方失守时，你继承这个失败：监管机构问你为什么没有审查这家供应商，客户问你为什么他们的数据会从你选择的供应商那里泄露。\n第三方风险管理（TPRM）就是让这张网变得可读的学科：知道谁能访问什么、你有多依赖他们、以及他们的控制措施是否真的经得起检验。\n问卷陷阱 #大多数 TPRM 项目是一张发给所有供应商的 200 到 500 题表格，填完归档，年复一年。这产生了文书，却几乎没有减少风险，原因有二：\n**它把所有供应商一视同仁。**咖啡供应商和支付处理商收到同一份问卷，尽管两者的暴露程度天差地别。 **它信任自我声明。**说\u0026quot;是的，我们加密数据\u0026quot;的供应商，和能证明这一点的供应商不是一回事。问卷衡量的是信心，而不是控制。 修复方法是相称性与验证。按供应商实际拥有的访问权限分类，然后把深度评估花在真实暴露所在的地方。\n按实际暴露程度分级 #一个可行的模型按接触内容为供应商分层：\n第一层，关键：持有持卡人或个人数据、与你的系统深度集成、或构成单点故障的供应商。对他们进行技术评估、授予审计权、签署合同安全条款。 第二层，重要：处理业务数据或拥有特权访问的供应商。进行较轻的技术审查和定期复验。 第三层，事务性：有限或无数据访问。做基线尽职调查即可，到此为止。 重点不是更多流程，而是相称的流程。一家失守的第一层支付网关是一起事件；一家失守的第三层文具供应商只是个小麻烦。把它们同等对待，是把力气花在错误的风险上。\nflowchart TD A[新供应商] --\u003e B{数据与访问级别？} B --\u003e|关键| C[第一层：深度技术审查] B --\u003e|重要| D[第二层：轻量审查] B --\u003e|事务性| E[第三层：基线尽调] C --\u003e F[合同安全条款 + 审计权] style C stroke:#F43F5E,stroke-width:2px style F stroke:#10B981,stroke-width:2px 超越问卷：技术验证 #对重要的供应商来说，自我声明是不够的。技术验证意味着索取证据，并在关系值得的情况下进行测试：\n证据审阅：SOC 2 报告、ISO 27001 证书、PCI DSS AOC，以及最关键的：这些报告的范围，而不只是 logo。 架构审查：供应商在自己的环境里如何实际处理你的数据，而不是他们营销页面上怎么写的。 合同利齿：可执行的安全条款、泄露通报时限，以及在重新谈判中仍然存活的审计权。 各框架在这一点上立场一致。关于供应链风险的 NIST SP 800-161， 以及 ISO 27001 的供应商安全条款（2022 版映射中的 A.15），都推动相称的、基于证据的供应商保证，而不是一刀切的问卷。泰国央行的外包指引对金融机构及其关键供应商应用同样的逻辑。\n持续进行，而非一次了事 #供应商风险不是静态的。去年通过审查的供应商，今年可能被收购、被入侵，或悄悄更换了子处理者。成熟的模型按基于风险的周期复验、监测信号（数据泄露、所有权变更、证书过期），并设有一条真正会吊销访问权限的下线流程，而不是仅仅取消发票。\n被永远减不了风险的供应商问卷淹没了？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 我们的第三方风险管理服务负责搭建分级模型、执行深度审查，并起草你的法务团队需要的合同安全条款。搭配法规合规， 将供应商义务映射到 BOT 和 ISO 27001 要求。\n","date":"2026-07-15","permalink":"https://puresecurity.com/zh/posts/third-party-risk-management-apac/","section":"安全洞察与公告","summary":"","title":"APAC 企业的第三方风险管理"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/tags/governance--leadership/","section":"Tags","summary":"","title":"Governance \u0026 Leadership"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/tags/third-party-risk/","section":"Tags","summary":"","title":"Third-Party Risk"},{"content":"大多数生产 Linux 系统与其默认配置的接近程度，超出了任何人愿意承认的范围。加固文档是存在的，往往还是多年前为某次审计而写的，但服务器与文档并不一致。\u0026ldquo;文档化的基线\u0026quot;与\u0026quot;实际配置\u0026quot;之间的差距，正是攻击者稳定栖身的地方。\nLinux 加固就是弥合这一差距的学科，而且要以能挺过下一次部署的方式来完成。\n默认配置是起点，不是安全姿态 #默认安装的 Linux 优先考虑兼容性而非安全性。它自带你用不到的服务、你不需要的内核特性，以及只够桌面使用、远不足以应对被攻陷的生产主机的日志配置。加固就是把这台通用机器改造成专用机器的过程。\n主要工作分几类：\n内核与 sysctl 调优：网络防护（如忽略 ICMP 重定向、启用源路由过滤）、文件系统限制，以及地址空间布局随机化等内存保护。 服务最小化：禁用并移除主机上不运行的东西，让不存在被利用价值的闲置组件留在系统里。 强制访问控制：SELinux 或 AppArmor，约束进程可以做什么，即使它已被攻陷。 Systemd 与容器加固：丢弃 capabilities、封禁原始套接字访问，并用 seccomp 配置文件限制系统调用。 审计与日志：捕获真正重要的事件，并传输出主机之外，让攻击者无法抹掉自己的痕迹。 CIS Benchmarks 仍然是这些控制措施最实用、认可度最高的成文标准， OpenSCAP 则将应用与审计自动化。\n配置即代码，否则等于不存在 #躺在 wiki 里的加固指南只是一份愿望清单。活在代码里的加固（一个 Ansible role、一个 Packer 镜像、一条 Kubernetes 准入策略）才是事实。当基线成为代码，三件事随之改变：\n**它是可复现的。**每一台新主机都继承基线，而不只是那些恰好有人记得配置的主机。 **它是可测试的。**CI 中的合规扫描会在配置漂移时让构建失败。 **它是可评审的。**基线的变更就是一次 pull request，遵循与应用代码相同的评审纪律。 这就是\u0026quot;一年一次的加固活动\u0026quot;与\u0026quot;平台固有属性\u0026quot;之间的区别。\n不可变基础设施是终点 #合乎逻辑的终局是不可变基础设施：主机和容器从不原地打补丁，只会被替换。新镜像被构建、扫描、部署；旧镜像被销毁。配置漂移成为不可能，因为没有可以漂移的东西：运行中的系统就是一个构建产物。\n不可变基础设施与代码化加固天然搭配。你维护的不再是基线，而是在把安全性编译进镜像。当漏洞出现时，修复方式是一次重建，而不是深夜的一场 SSH 会话。\nflowchart LR A[CIS benchmark 基线即代码] --\u003e B[在 CI 中构建加固镜像] B --\u003e C[流水线中的合规扫描] C -- 通过 --\u003e D[部署并轮换实例] C -- 失败 --\u003e B style C stroke:#0EA5E9,stroke-width:2px style D stroke:#10B981,stroke-width:2px 主机之外 #加固不会止步于操作系统。同样的纪律会向多个方向延伸，每个方向都有自己的失效模式。\n容器继承一切，还会叠加自己的风险。 从未加固的基础镜像层构建出来的容器镜像，会把主机层面的所有弱点带进运行它的每一个 Pod。解决方案在上游：最小化基础镜像、在 CI 中扫描、以非 root 身份运行并挂载只读文件系统、裁剪 capabilities，以及用 seccomp 配置文件把 syscall 限制在工作负载真正需要的范围内。默认 seccomp 配置已经拦截了不少；再根据实际观察到的 syscall 行为定制一份配置，就能覆盖剩余部分。Kubernetes 准入策略在整个集群层面强制执行这一切，让不符合标准的部署根本无法被调度。\nOT 环境的赌注更高。 在工业和运营技术场景中，加固与可用性的冲突是办公 IT 从未见过的。一条错误套用的 CIS 控制项落在楼宇管理系统、产线 PLC 网络或医院设备分区上，产生的不是一条 finding，而是停机：有时还牵涉人身安全。因此 OT 加固的顺序正好相反：先做被动监测和资产盘点，变更安排在维护窗口内并附带回滚方案，控制措施先在与生产一致的镜像环境中试点。IT 问的是\u0026quot;这个系统安全吗？\u0026quot;，OT 必须问的是\u0026quot;我们能不能在不让它停下来的前提下保护它？\u0026rdquo;\n漂移检测闭环。 基线会在日常变更中退化：工程师为了调试打开一个端口，某个安装程序重新启用了一项服务，一个热修复没有回写进代码。没有检测机制，今天加固到位的主机就是明年的软肋。有效的模式是：每日定时扫描，将在线主机和镜像与代码化基线比对，发现的结果作为告警直接路由给责任人，而不是归档进没人读的季度报告。一天内发现的漂移是一张工单；一年后才发现的漂移是一场事件调查。\n加固到位的主机，如果背后挂着一个过度宽松的云 IAM 角色，或者身处未经扫描的容器流水线，依然处于暴露之中。最持久的姿态是把主机基线、容器构建链、云配置和身份边界当作同一个连续的表面来对待，并以这种方式监控它。\n不确定你的服务器是否真的符合加固文档？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 我们的 Linux 与基础设施加固以代码形式交付基线和自动化的漂移检测； 配置与架构评估则审查主机周边的云与身份层。想要全貌， 请预约一次工程与范围界定会谈。\n","date":"2026-06-17","permalink":"https://puresecurity.com/zh/posts/linux-infrastructure-hardening-apac/","section":"安全洞察与公告","summary":"","title":"APAC 系统的 Linux 基础设施加固"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/tags/security-engineering/","section":"Tags","summary":"","title":"Security Engineering"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/tags/compliance--regulatory/","section":"Tags","summary":"","title":"Compliance \u0026 Regulatory"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/tags/data-protection/","section":"Tags","summary":"","title":"Data Protection"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/tags/penetration-testing/","section":"Tags","summary":"","title":"Penetration Testing"},{"content":"多年来，\u0026ldquo;加密传输中的数据\u0026quot;只意味着一件事：上 HTTPS。TLS 在负载均衡器处终结，载荷在内部网络里明文流动，而所有人都称之为\u0026quot;已加密\u0026rdquo;。 泰国央行一直在稳步弥合这个缺口，方向也很明确：对于敏感金融数据，仅有传输加密已经不够了。\n传输加密与载荷加密的区别 #TLS 保护的是线路上两点之间的数据，它并不保护应用内部的数据。一旦 TLS 在反向代理、API 网关或负载均衡器处终结，载荷就被解密并以明文形式交给后端。\n这些明文随后会流经、驻留在你并不希望它出现的地方：\n日志：过于勤快的网关把请求体写进日志，完整的主账号和账号号码随之落盘。 服务网格与内部跳数：微服务之间的东西向流量常常不加密，理由是\u0026quot;内网是可信的\u0026quot;。 内存与缓存：内存中的请求对象、调试转储和 APM 追踪都可能保留解密后的载荷。 可观测性管道：跨团队、跨第三方的指标与追踪数据在转发 span 时一并带走了内容。 应用层载荷加密通过加密消息本身来填补这一缺口，因此无论它跨越多少跳、基础设施如何处置它，数据都始终受到保护。\nflowchart LR A[客户端] --\u003e|TLS| B[API 网关：TLS 终结] B --\u003e|明文| C[后端服务] C --\u003e|明文| D[日志 / 追踪 / 缓存] subgraph \"应用层加密\" E[已加密载荷] -.-\u003e|JWE / AES-GCM| B B -.-\u003e E2[传输全程保持加密] end style D stroke:#F43F5E,stroke-width:2px style E2 stroke:#10B981,stroke-width:2px 标准推荐用什么 #载荷加密的机制已经标准化且广为理解：\nJSON Web Encryption（JWE）（RFC 7516）：加密结构化 API 载荷的事实标准，用非对称接收方密钥包裹对称数据密钥。 AES-256-GCM：载荷主体的认证加密主力算法，同时提供机密性与完整性。 RSA-OAEP 或 ECDH：密钥封装层，保护对称密钥在传输与静态存储中的安全。 这套模式与 TLS 自身如出一辙：用快速对称密码处理批量数据，再用非对称密钥交换进行封装，区别在于它作用于消息层级，因此在 TLS 会话之外依然有效。\n央行为何此时推动这件事 #监管者的逻辑并不深奥。金融 API 如今已是整个泰国支付生态的连接组织：银行、PSP、金融科技、商户。一次网关配置失误，不应该让任何有日志访问权限的人看到账户数据。载荷加密是一种纵深防御措施：它假设传输链路终将被检查、被记录或在某个时刻被攻破，并确保那一刻到来时敏感数据不可读。\n这与 PCI DSS 保护静态持卡人数据的要求背后的原则一脉相承：当你不再信任任何单一跳点时，你就不会再把\u0026quot;网络是安全的\u0026quot;当作唯一的控制手段。\n对你的工程团队意味着什么 #采用载荷加密不是拨一个配置开关。它意味着：\n密钥管理成为一等公民。你需要轮换机制、签名密钥与加密密钥的分离，以及受保护的密钥存储。 网关与日志改造：所有读取或记录请求体的组件都必须重新评估，因为中间件再也读不懂报文了。 契约变更：下游消费方必须能够解密，这意味着要在链条上的每一方之间做好密钥分发与版本管理。 测试：可观测性必须从\u0026quot;倾倒载荷\u0026quot;转变为\u0026quot;先认证授权，再仅在必要处解密\u0026quot;。 只要你身处 BOT 的监管半径之内，这些都不是可选项。这是一次从\u0026quot;给管道加密\u0026quot;到\u0026quot;保护消息本身\u0026quot;的转变。\n不确定你的 API 载荷是否满足泰国央行的期望？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 我们的法规合规服务将 BOT 指引映射为具体的工程要求， API 与应用安全审查则验证你的载荷在端到端层面究竟受到了怎样的保护。\n","date":"2026-05-13","permalink":"https://puresecurity.com/zh/posts/bot-api-payload-encryption-thailand/","section":"安全洞察与公告","summary":"","title":"泰国央行 API 载荷加密规则"},{"content":"每家组织都有一份事件响应计划。但其中大多数从未被检验过。计划躺在文档管理系统里，由一位早已离职的人撰写，从未在时间压力下的真实决策中存活过。计划的第一次演练就是它第一次真正发挥作用的时刻，而那恰恰是未经检验的计划失败的时刻。\n桌面演练能以很低的成本解决这个问题：一场有引导的、以后果驱动的网络危机模拟，用你真实的团队、真实的阈值和真实的监管机构来跑。\n为什么计划总在初次实战时失灵 #真实事件不是线性的。它们模糊、嘈杂，充满任何剧本都无法完全预设的判断题：\n什么时候告诉董事会？ 太早是狼来了；太晚就失去了他们的信任。 什么时候通知监管机构？ 在泰国， 泰国央行等监管机构设定了泄露通报时限。犹豫不决会产生法律后果。 谁对客户发言，用什么措辞？ 一份措辞不当的首次声明造成的声誉损害比事件本身还大。 谁有权关停生产系统？ 真实危机中，有权限的人往往不是掌握信息的人。 这些问题由人决定，而不是流程。桌面演练会在攻击者之前很久，就让你看到决策在哪里停摆。\n一次好的演练长什么样 #设计良好的桌面演练以威胁情报为依据，并针对你的行业定制。它不是一句笼统的\u0026quot;发生泄露了\u0026quot;。它遵循一条现实的链条：比如一次始于供应商告警的供应链失陷，逐步升级为关键系统上的勒索软件，并迫使团队面对层层加码的决策点。并非所有信息一开始就可用，也并非所有人从一开始就参与进来。你必须用手头现有的资源开展工作，并准备好在新信息出现时随机应变、临场处置。\n在变更可能需要数周或数月的企业环境中，你必须考虑事件期间\u0026quot;什么都不做\u0026quot;的影响。拖延决策或行动，其结果可能比提交一个\u0026quot;预估变更\u0026quot;或\u0026quot;紧急变更\u0026quot;更糟糕。\n真正的价值在于复盘。好的演练以下列标准衡量：\n决策速度：从检测到做出可辩护的决定需要多久？ 升级路径清晰度：有没有人清楚到底谁有权拍板？ 监管合规准确性：你的通报时点是否满足合规要求？ 沟通一致性：对内和对外的口径一致吗？ NIST SP 800-84 将这一点定义为任何测试、训练与演练项目的核心：演练的存在是为了发现差距并改进，而不是证明你已经准备好了。\n大多数团队忽略的模式 #几乎每一次演练中最大的发现都不是技术问题，而是：技术团队和高管团队对同一起事故持有不同的心智模型。工程师思考的是遏制和根因；高管思考的是披露、责任和客户信任。两者都没有错，但如果他们在危机进行中才第一次碰撞，结果就是最坏时刻的最糟摩擦。\n桌面演练把这种碰撞强制安排在一间安全的会议室里，让摩擦变成一堂课，而不是一笔负债。\n你的事件响应计划上一次真正被演练是什么时候？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 我们的网络危机桌面演练是为期半天、针对你的基础设施和监管暴露定制的引导式模拟，并附上一份可以直接呈交董事会的准备度报告。搭配 DFIR 常驻服务，当演练成为现实时，你无需即兴发挥。\n","date":"2026-04-15","permalink":"https://puresecurity.com/zh/posts/cyber-crisis-tabletop-apac/","section":"安全洞察与公告","summary":"","title":"APAC 企业的网络危机桌面演练"},{"content":"应用程序早在几年前就不再是\u0026quot;网站\u0026quot;了。它们现在是 API：微服务调用微服务，一端是移动客户端，另一端是支付通道。而安全对话还没有完全跟上。团队仍然在购买\u0026quot;Web 应用渗透测试\u0026quot;，把 80% 的精力花在前端，而背后的 API，资金和数据真正流动的地方，却测试不足。\n为什么 API 能绕过扫描器 #自动化 Web 扫描器围绕\u0026quot;页面模型\u0026quot;构建：爬链接、找表单、注入载荷。API 不呈现页面，它呈现的是路由、方法和模式，而有趣的行为恰恰存在于它们之间的业务逻辑里。\n设想一个对象级访问缺陷：用户把请求中的 user_id=1024 改成 user_id=1025，就读到了别人的记录。没有签名告警，没有恶意载荷。扫描器看到一个正常请求便继续前行。这就是失效的对象级授权（BOLA），OWASP API Security Top 10 榜单上的第一名，而几乎所有的自动化工具都对它视而不见。\n这正是人工主导 API 测试的核心论据：破坏性最大的缺陷是设计缺陷，而发现设计缺陷需要一位理解业务上下文的分析师。\n一次有效的 API 测试究竟覆盖什么 #有意义的 API 评估远不止对着 OpenAPI 规范跑一遍扫描器：\n认证与授权：令牌处理、权限范围检查，以及跨越每个角色边界的对象级访问。 业务逻辑：用户能否给订单设置负价格、重放支付回调，或者直接调用下一个端点跳过工作流步骤？ 数据暴露：哪些端点返回了过多字段？哪些端点接受客户端本不该发送的字段？ 限流与滥用：枚举、撞库，以及利用薄弱限流实现的账户接管路径。 集成边界：webhook、第三方回调、消息队列：这些地方往往默认信任，从未验证。 正因如此，最好的项目会把人工攻击技术与 AI 辅助侦察和模糊测试结合起来：自动化扩展覆盖面，人来判断严重性和上下文。\n持续进行，而非一年一次 #一年一次的 API 测试，是对一个每周都在部署的系统的时点快照。报告写完的时候，端点早就变了。现代做法是把 API 安全检查融入交付流水线：\n左移：在 CI 中加入静态分析和模式校验。 按发布测试：每当 API 面发生变化时做聚焦审查。 年度深检：为满足审计留痕以及流水线无法判断的业务逻辑，做一次完整的、人工主导的评估。 对于接触卡数据的组织， PCI DSS 要求 6 和要求 11.4 都指向这个方向，而泰国央行的数字渠道安全指引同样如此。\nflowchart LR A[CI 中的 Schema 与 SAST] --\u003e B[随版本发布的 API 审查] B --\u003e C[人工主导的深度评估] C --\u003e D[修复与复测] D --\u003e A style C stroke:#0EA5E9,stroke-width:2px style D stroke:#10B981,stroke-width:2px 自动化扫描器看不见的东西 #值得具体说清楚自动化到底错过了什么，因为这些缺口并不是随机分布：它们恰好聚集在资金流动的地方。\n实践中的 BOLA。 扫描器只测试它发现的端点和它理解的参数。拿一个发票 API 来说：GET /invoices/8842 返回调用者自己的发票，扫描器记一次通过。但 GET /invoices/8843：另一个客户的发票：可能同样顺利返回，而没有任何扫描器会去尝试，因为要理解 8843 属于别人，必须知道所有权在你的业务里意味着什么。每一个跨过租户边界的对象标识符都是潜在 BOLA，只有逐个账户枚举对象的分析师才能找到它们。\n业务逻辑缺陷。 扫描器测试请求成功还是失败；逻辑缺陷藏在那些本不该成功却成功了的请求里。真实案例来自实际项目：优惠券可以重复使用，因为核销校验发生在支付捕获之后；两个账号之间转移预订却不需要重新授权；已发货的已付款订单可以被取消，因为取消端点从不检查履约状态。每一个都返回 HTTP 200。每一个都是没有任何报错信息的资金损失。\n服务间的信任假设。 在微服务体系里，一个服务通常会信任调用方提交的 header、token 或内部端点，因为设计图上调用方永远是内部服务。然后某一天，一个服务被攻陷，或某个内部端点从信任等级更低的网段变得可达，这些继承下来的信任假设就成了攻击者的梯子：先在薄弱的边缘服务上完成认证，再把它的身份一路递给下游那些真正值钱的 API。发现这类问题需要既按设计师的本意理解架构，又按攻击者的路径去测试它。\n这三样东西都不会出现在扫描器输出里。它们只会出现在花时间理解了你的 API 到底用来做什么的分析师写的报告里。\n想了解你的 API 在攻击者眼中的样子？ 通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我们，获取一次直接的可行性评估。 我们的 API 与应用安全审查将人工源代码分析与情境化的渗透测试相结合，交付开发人员可以直接使用的修复指导。如果你需要的是对边界和分段的更广泛验证，请参阅人工主导渗透测试。\n","date":"2026-03-11","permalink":"https://puresecurity.com/zh/posts/api-penetration-testing-thailand/","section":"安全洞察与公告","summary":"","title":"泰国的高效 API 渗透测试"},{"content":"成长型公司获取安全领导力的方式存在一个结构性缺口。一家 50 人、手握严肃企业客户管线的 scale-up，规模小到无法证明一份全职 CISO 薪酬的合理性，却又暴露到不能没有一位 CISO 的程度。于是它落入了安全的炼狱：一个疲于奔命、兼职管安全的 IT 负责人；一个企业级潜在大客户提出董事会和投资人层面无人能回答的问题；还有一个期望有人对安全体系负责的监管机构。\nFractional CISO 的存在就是为了填补这个缺口。\nvCISO 到底做什么 #虚拟 CISO 不是写完报告就走的顾问。这个角色是按约保留的领导力：一位具名的、可问责的人，负责安全路线图，向董事会代表安全职能，并承担那些否则会落在既无权限也无话语权之人身上的风险对话。\n具体来说：\n董事会与委员会汇报：把技术风险翻译成营收、声誉和监管暴露的语言。 审计防御：带领监管机构、外部审计师和企业客户的安全团队走查你的控制措施。 企业问卷：快速且可信地回答那些卡在你最大订单前的 200 题安全审查。 预算与战略：一份经得起 CFO 审视的安全路线图，因为它出自一位曾经成功答辩过的人。 事件治理：一位处置过真实事件的决策者，让第一次真正的危机不再也是领导层第一次临阵练习。 这些都不需要每周 40 小时，但都需要一位真正在 CISO 层面做过不止一次的人。\n为什么 scale-up 总是在安全领导力上投入不足 #较小的公司倾向于把安全当产品来买（一套 EDR 许可证、一个扫描器、一台防火墙），然后纳闷为什么企业订单还是卡在采购环节。原因在于：工具回答的是\u0026quot;你有没有控制措施？\u0026quot;，却回答不了\u0026quot;谁对这些措施负责？如何治理？你能向我们的董事会证明吗？\u0026quot;\n企业买家和监管机构真正审计的不是你的工具，而是你的问责结构。vCISO 提供的正是这个结构：具名的责任人、持续维护的风险登记册、固定的治理节奏，以及一套经得起追问的安全叙事。\n这也是全职 CISO 能提供的价值，但其薪酬只有在超过一定人数规模后才说得通，而且六到十二个月的招聘周期，是任何在短跑道上从 0 走到 1 的公司都耗不起的。\n与工程团队的对齐 #最好的安全领导力不与工程团队对抗，而是与之对齐。一位动手型的 vCISO 和你的开发者说同一种语言，尊重交付速度，更愿意让控制措施活在 CI/CD 流水线里，而不是活在一本策略 PDF 里。\n这就是\u0026quot;只做治理的顾问\u0026quot;与\u0026quot;能坐进你的平台团队、审阅真实架构、并把监管要求转化为一个 pull request 的动手型 CISO\u0026quot;之间的区别。当写董事会报告的人和理解你威胁模型的是同一个人时，战略就不再是纸上谈兵。\n真实成本对比 #评估按需安全领导力的诚实方式，是把两种选择放在同一页上，把每一项都数进去，而不只是工资。\n全职选项。 在本地区域，拥有真实企业级和监管经验的 CISO，其总薪酬远超基本工资：年薪、奖金、福利，通常还有股权：因为真正有分量的人加入成长型公司时，都期望分享成果。再加上相当于首年薪酬百分之二十到三十的招聘佣金，以及六到十二个月的招聘周期，全职雇佣的第一年成本通常是按需方案经常性成本的数倍。还有一种最难定价的风险：请错了人的高管，照样要走完整的离职补偿周期。\n按需选项。 按合同约定每月固定天数计费的顾问费，没有招聘佣金、没有股权、没有超出合同条款的通知期。对于需要董事会代表、审计辩护和企业级安全问卷应对能力的成长型公司来说，这通常只占全职方案的一小部分，同时得到的是在多家公司做过这件事的人，而不是正在你的公司里现学的人。\n盈亏平衡点。 在安全领导力需求变成真正的持续性需求之前：持续的监管压力、需要日常安全协作的大型工程组织、或希望有常任高管的董事会：纯经济账上按需方案都占优。对大多数公司而言，这个拐点出现在全职雇佣尚不划算的阶段之后相当远的地方，而好的按需合作让过渡是渐进式的：服务天数随业务增长而增加，直到全职变得有意义，届时 vCISO 还会协助招聘并交接给自己的继任者。\n企业订单的算术。 还有一个视角会改写整个对比。当成企客户的安审卡住时，那张订单就躺在采购流程里：有时年价值超过你整个安全预算。一位能在一周内令人信服地完成那场安审的 vCISO 不是花钱：在关键的那些案例里，顾问费相对它解锁的收入只是零头。安全领导力是少数几种支出可以直接与赢单挂钩、而不只是与风险降低挂钩的职能之一。\n正在考虑按需安全领导力？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 我们的 vCISO 顾问服务由一位前 CISO 提供，他负责路线图并维护董事会关系。想确认是否合适？ 预约一次工程与范围界定会谈，我们将为你规划安全领导力的第一个 90 天。\n","date":"2026-02-18","permalink":"https://puresecurity.com/zh/posts/fractional-vciso-advisory-apac/","section":"安全洞察与公告","summary":"","title":"APAC 规模型企业的 Fractional vCISO 服务"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/tags/fintech--payments/","section":"Tags","summary":"","title":"Fintech \u0026 Payments"},{"content":"一个令人不安的事实：哈希不等于保护。你可以存储信用卡号的 SHA-256 哈希值，完全符合 PCI DSS，却实际上毫无保护可言，因为你哈希的那个值根本不含足以抵御暴力破解的熵。\n这会让平时很严谨的工程团队栽跟头，因为哈希感觉上是安全的。哈希是单向的，原值无法通过反推函数还原，所以数据理应是受保护的。问题不在哈希本身，而在于你喂给它的是什么。\n用真实数字看熵的问题 #16 位卡号不是随机的。它的结构是公开且固定的：\n前 4 到 6 位是发卡行识别码（IIN）：银行前缀，完全公开。 最后一位是校验位，由 Luhn 算法计算得出，这个公式 1954 年就发表了。它不是秘密，只是错误检测。 再按 PCI DSS 常见允许的方式遮蔽 PAN：前 4 到 6 位和后 4 位可见，中间 6 到 8 位隐藏：\n4532 AAXX XXXX 1234 IIN 已知 4 位的情况下，未知部分是8 位数字，即至多 100,000,000 种可能。套用 Luhn 校验后只有十分之一能存活。你真正的搜索空间是 1,000 万个值。这不是一个密码，这是一份很短的清单。\n测试 1,000 万个哈希需要多久？ #接下来情况会更糟。SHA-256 在设计上就是快的。它是为千兆级速度的完整性校验而生，而不是为存储秘密。现代 GPU 破解跑分是公开且可复现的：\n硬件 大致 SHA-256 吞吐 1× RTX 4090 GPU 约 85 亿次哈希/秒 4× RTX 4090 集群 约 340 亿次哈希/秒 8× RTX 4090 集群 约 680 亿次哈希/秒 1,000 万次猜测除以每秒 85 亿次，大约是千分之一秒。一块消费级显卡就够了。甚至一台单 GPU 的电脑都能用彩虹表在眨眼之间\u0026quot;反解\u0026quot;出一个信用卡号。\n结论很直白：合规不等于安全。**对于低熵字段，即便是 SHA-2（或 SHA-3）也不安全，即使它合规。**函数确实是单向的，但当输入空间极小时，它会被轻而易举地穷举殆尽。把 SHA-256 换成 SHA-512 或 SHA-3 解决不了问题，因为它们同样快。\n\u0026ldquo;合规\u0026quot;真正允许的是什么 #PCI DSS 其实并没有要求你用 SHA-256 哈希 PAN。要求 3.5 说的是你必须用强密码学使 PAN 不可读，并明确点名了带密钥的哈希和加密，同时指出：只要盐值保密、哈希不具备现实可逆性，加盐哈希索引是可以接受的。问题在于，对一个只有 1,000 万值空间的裸 SHA-256 而言，穷举在实践中就等于可逆，因此它违背了要求的本意，哪怕检查表上打了勾。\n遮蔽（显示前 4-6 位和/或后 4 位）是另一项独立控制：它保护的是操作员看到的内容，而不是你存储的内容。两者极易混淆，而这种混淆正是\u0026quot;已遮蔽但未加盐哈希\u0026quot;的 PAN 混进生产环境的原因。\n如何正确保护这类数据 #修复方法是用对待密码的态度对待低熵字段，因为在数学上它们一样弱。按优先级排序：\n**干脆不要存储它。**将 PAN 令牌化，把真实号码保存在独立的保险库或 HSM 中。如果你从不存储这个值，就没有什么可以被暴力破解。 **带秘密 pepper 的 keyed hashing（HMAC）。**如果必须以 PAN 为索引，使用 HMAC，并将高熵密钥保存在数据库之外。没有密钥，无论输入熵多低，暴力破解在算力上都不可行。 **内存困难型密码哈希。**当你只能靠值本身来保护值时，使用 Argon2id（RFC 9106）或 scrypt，配合每个值的随机盐和调校过的参数，让每一次猜测都消耗真实的时间和内存。比如 64 MB 内存成本的 Argon2id，能把那次 0.001 秒的穷举变成数月的 GPU 时间。 **到处使用盐和 pepper。**每个值的随机盐可以击败预计算的彩虹表；只要保守住秘密，pepper 可以彻底击溃离线攻击。 OWASP 密码存储速查表 和 NIST SP 800-63B 正是出于同样的原因，推荐对低熵机密使用内存困难型函数。 flowchart TD A[存储 PAN] --\u003e B{索引用？} B -- 否 --\u003e C[令牌化 / 保险库 / HSM] B -- 是 --\u003e D{有密钥可用？} D -- 是 --\u003e E[HMAC + pepper] D -- 否 --\u003e F[Argon2id / scrypt + 盐] style C stroke:#10B981,stroke-width:2px style E stroke:#10B981,stroke-width:2px style F stroke:#10B981,stroke-width:2px 卡片之外的启示 #这条原则适用于一切熵受限的定长标识符：国民身份证号、电话号码、出生日期，甚至是生成不佳的 API 密钥。如果输入空间很小，哈希函数的速度就是你的敌人，而\u0026quot;合规\u0026quot;绝不是\u0026quot;安全\u0026quot;的同义词。\n担心你目前保护 PAN 或其他标识符的方式？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 我们的 API 与应用安全审查 会检视你的代码实际如何存储和传输敏感值，并且我们会直截了当地告诉你：哪里通过了检查表，却仍在暴露真实数据。\n","date":"2026-01-14","permalink":"https://puresecurity.com/zh/posts/hashing-low-entropy-data-apac/","section":"安全洞察与公告","summary":"","title":"低熵数据与信用卡哈希的安全边界（APAC）"},{"content":"我听到的最常见的 PCI DSS 问题不是\u0026quot;如何合规？\u0026quot;，而是\u0026quot;我到底需不需要合规？\u0026ldquo;答案比大多数组织想象的更宽泛，而猜错的代价也绝非纸上谈兵：罚款、更高的交换费率，以及一旦发生泄露时以真金白银计的取证成本和品牌损失。\n简短的回答 #PCI 数据安全标准适用于任何存储、处理或传输持卡人数据的实体，也适用于任何可能影响该数据安全的实体。这个定义刻意宽泛，把三类常被误认为豁免的对象都囊括了进来。\n1. 任何存储、处理或传输卡数据的主体 #这是最显而易见的情况，但远不止刷卡的那家商户。它包括：\n在结账表单里收集卡号的电商网站。 \u0026ldquo;只是为了对账\u0026quot;而存着主账号（PAN）的 ERP 系统。 在录音线路上把卡号敲进 CRM 的呼叫中心。 每天接触这些数据的支付网关、PSP、收单机构和发卡行。 只要卡数据落到你的系统上，哪怕只有一瞬间、哪怕只在内存里，你就在范围内。\u0026ldquo;我们只保存一秒\u0026quot;不是豁免理由，它本身就是范围。\n2. 即使你使用了第三方处理机构 #最大的误解莫过于\u0026quot;我们用 Stripe / 2C2P / PayPal，所以 PCI DSS 与我们无关\u0026rdquo;。使用第三方会缩小你的范围，但不会让它消失。\n对小型组织而言，这通常意味着你有资格填写简化版验证表单：SAQ A 或 SAQ A-EP，而不是完整的 SAQ D，因为卡数据从不经过你的系统。但你仍有义务：正确维护脚本集成、保持结账页面免受 skimming 攻击，并按照标准的要求 12.8 对第三方进行管理。你仍然要验证，只是验证的内容变少了。\n陷阱在于范围蔓延。只要新增一个在服务端捕获卡号的自定义字段，或者让支付流程经由你自己的端点重定向，你就会悄无声息地从 SAQ A 变成 SAQ D：义务规模完全不同。没有人会在这种事发生时提醒你。\n3. 银行以及持卡人链条上游的每一环 #银行、收单机构、发卡行和支付便利化机构不仅仅是\u0026quot;在范围内\u0026rdquo;：它们是整个生态中被验证最频繁、最深度的实体。在泰国，金融机构除了 PCI DSS 之外，还要接受泰国央行 IT 风险和数字渠道指引的约束。两套体系有重叠但并不等同，一次 BOT 审计不能替代 PCI DSS 验证。\n为什么范围就是一切 #PCI DSS 的成本随范围而增长。持卡人数据环境（CDE）内的每一个系统、每一段网络、每一个人都要接受全套控制要求。因此，缩小 CDE 是你能做的杠杆率最高的合规动作：\n令牌化卡数据，让你存储的是无用的引用而不是主账号。 通过分段隔离支付系统，让业务其余部分脱离范围。 对不需要亲自接触的部分，有意地外包给已通过验证的服务提供商。 一个界定良好的环境可以把为期六个月、六位数的评估变成可控、可重复的例行工作。而界定糟糕的环境会把全公司都拖进审计，却不带来任何额外的安全收益。\nflowchart TD A[收到卡数据] --\u003e B{经过你的系统？} B -- 否 --\u003e C[SAQ A / A-EP：范围缩小] B -- 是 --\u003e D[完整 CDE：SAQ D / ROC] D --\u003e E{令牌化并分段？} E -- 是 --\u003e F[审计前缩小 CDE] E -- 否 --\u003e G[全面评估，覆盖每个系统] style F stroke:#10B981,stroke-width:2px style G stroke:#F43F5E,stroke-width:2px 4.0.1 改变了游戏规则 #PCI DSS 4.0.1 把许多优秀工程团队本来就在做的事情正式化了：把合规视为一种持续状态而非年度事件，提出了针对性风险分析、定制化控制方法以及在变更中保持安全等要求。它传递的信息是：时点式证书不再足够，标准现在期望各控制措施在两次评估之间保持真实有效。\n不确定自己是 SAQ A、SAQ A-EP 还是需要完整 ROC？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 从哪里开始 #在承诺审计之前，先做一次 PCI DSS 差距评估与范围缩减： 缩小 CDE、测试你的网络分段，然后再进入验证。准备就绪后， 我们由 QSA 主导的审计将由曼谷的在职业评估员带你完成完整的 ROC/AOC 流程。\n","date":"2025-12-10","permalink":"https://puresecurity.com/zh/posts/pci-dss-compliance-thailand/","section":"安全洞察与公告","summary":"","title":"谁在泰国需要 PCI DSS 4.0.1 合规？"},{"content":"二十年前，打补丁是一项月度杂务：一张表格、一个维护窗口、一次变更评审委员会，再加上\u0026quot;别出事\u0026quot;的祈祷。这种节奏行得通，是因为攻击者的速度和防守者差不多。那个世界已经不在了。\n如今，一个漏洞可以在数小时内完成披露、武器化和大规模利用。\u0026ldquo;概念验证\u0026quot;到\u0026quot;在野利用\u0026quot;之间的窗口已经坍缩到：靠人工审表格必然太迟。漏洞管理必须变成一条流水线，而不是一套流程。\nAI 是加速器 #两个趋势让 AI 成为这个等式中的主导变量。\n第一，AI 辅助的防御：静态分析器、模糊测试工具和代码审查工具已经强大到比人工审计更快地暴露缺陷。这是好消息，也是安全团队被发现事项淹没的原因。\n第二，也更重要的，AI 辅助的攻击。研究者和攻击者都在用语言模型分诊安全公告、编写可用的 exploit，并变异已知攻击技术来绕过特征检测。Google Project Zero 和关于自动化漏洞发现的学术工作都表明：曾经需要数月人力的事情，现在可以被大幅压缩。\n净效果是：从披露到利用的差距每个月都在缩小，人工补丁队列再也跟不上了。这不是推测，它清晰可见于 CISA 已知被利用漏洞 目录：目录中缺陷的典型利用时间相对于披露时间持续缩短。\n是牛群，不是宠物 #\u0026ldquo;牛群，不是宠物\u0026quot;这句话出自早期云计算时代：服务器应当是可互换、可丢弃的资源，而不是有名字有性格、被人精心调教的机器。这个理念完美适用于打补丁。\n如果服务器是宠物，你会温柔地为它打补丁：登录、应用修复、重启、祈祷。如果它是牛群，你根本不打补丁。你替换它。你在 CI/CD 中烘焙一个新的、打好补丁的镜像，销毁旧实例，部署新的。补丁是一个构建产物，在触碰生产之前就已完成评审和测试。\nflowchart LR A[CVE 发布] --\u003e B[自动分诊] B --\u003e C{构建已修补镜像} C --\u003e D[流水线中测试] D --\u003e E[部署并轮换实例] E --\u003e F[旧镜像销毁] style C stroke:#0EA5E9,stroke-width:2px style F stroke:#10B981,stroke-width:2px 不可变基础设施把打补丁从一项危险的手工操作变成一次例行的部署。这是唯一能跟上现代利用速度的模型，而它依赖许多团队至今仍未建立的自动化测试与部署流水线。\n优先级高于数量 #返回 40,000 条发现的扫描器不是安全项目，是噪音。真正的功夫在分诊：这些发现里哪些真正可达、真正可利用、真正位于关键路径上。\nCISA SSVC 模型抓住了正确的心态：按利用状态、暴露程度和使命影响排优先级，而不是只看 CVSS 分。一个仅内网可达、不可路由服务上的 CVSS 9.8，往往不如一个公开端点上已有在野 exploit 的 CVSS 6.5 紧急。\n分层，因为任何单层都会失效 #没有任何单一控制能在坚决的攻击者面前幸存。纵深防御就是承认每一层都有失效模式：\n补丁缩小攻击面，但不可能即时完成。 网络分段在补丁滞后时控制爆炸半径。 运行时检测抓住漏过补丁周期的东西。 最小权限限制被攻陷资产能触达的范围。 备份与经验证的恢复是以上全部失守时的最后一道防线。 目标不是阻止每一次利用。目标是让每一次单独的失败都可存活。当补丁流水线慢了一周，分段和检测为你争取追上来的时间。当分段失守，最小权限限制损害。分层，就是你在无法完全掌控的时间线前保持领先的方法。\n补丁队列追不上？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 落到实处 #我们的漏洞管理与合规扫描提供面向 PCI DSS、BOT 与 ISO 27001 的自动化持续扫描与优先级报告； Linux 与基础设施加固则把修复固化成代码。\n","date":"2025-11-12","permalink":"https://puresecurity.com/zh/posts/vulnerability-management-patching-apac/","section":"安全洞察与公告","summary":"","title":"现代漏洞管理与补丁策略（APAC）"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/tags/cost--strategy/","section":"Tags","summary":"","title":"Cost \u0026 Strategy"},{"content":"企业安全采购中有一个安静的讽刺：一个组织会为\u0026quot;统一平台\u0026quot;支付七位数的许可费，而这个平台拆开来看，不过是一堆开源项目套上一个仪表盘和一套销售说辞。检测引擎不是厂商发明的，是社区发明的。你付的是包装费。\n这不是反对为软件付费，而是主张弄清楚你在买什么，并且认识到：一个小的工程团队用开源组件往往能搭出比向厂商授权更有效、更贴合自身的安全栈。\n为独特的环境定制方案 #没有两个环境是一样的，而商业工具是为\u0026quot;平均环境\u0026quot;造的。它们预设了一种网络形态、一种数据中心拓扑、一种日志模型，而这些可能都与你的现实不符。结果是一个匹配你 80% 环境的工具，剩下别扭的 20%，通常恰恰是重要的部分，最后还是得靠自定义脚本来补。\n开源把这种关系倒了过来。你按照自己的架构来组合技术栈，而不是反过来。运行时安全用 Falco，网络可见性用 Zeek，主机入侵检测用 Wazuh，容器扫描用 Trivy，漏洞自动化用 Nuclei，静态分析用 Semgrep。每个组件把一件事做好，而且它们能组合。\n这就是应用于安全的 Unix 哲学：小巧锋利的工具通过标准接口通信，而不是一个包揽一切的单体。\n工具之间可以对话 #厂商套件想成为引力中心。一切都得喂给它，装它的代理，说它的查询语言。那个孤岛就成了天花板：一旦你需要一个它原生不产生的信号，你就只能等路线图。\n开源工具围绕开放格式和 API 构建。Zeek 输出 JSON，Falco 把事件写到 stdout，Wazuh 通过 API 摄取数据。因为它们通过开放接口通信，你可以把它们全部接入同一条管道：无论那是一个 OpenSearch 集群、一个 SIEM 还是一个普通的日志汇聚点，然后用一种语言查询全局。\ngraph LR A[Falco：运行时] --\u003e E[OpenSearch / SIEM] B[Zeek：网络] --\u003e E C[Wazuh：主机] --\u003e E D[Nuclei：扫描] --\u003e E E --\u003e F[检测与响应剧本] style E stroke:#0EA5E9,stroke-width:2px style F stroke:#10B981,stroke-width:2px 商业套件要求你放弃这种可组合性。开源栈把它作为默认。\n你投资的是人，不是许可证 #许可证是一项经常性成本，停止付费的那一刻它连同能力一起消失。开源栈是对你的工程师的经常性投资，他们学会了自己所运营工具的内部原理。\n这比报表上的那一行更重要。搭建过检测流水线的工程师明白告警为何触发，无需开支持工单就能调掉误报，并能在新威胁出现时扩展工具。你的组织拥有这项能力，而不是租用它。\n当一位关键工程师离开时，项目不会随他而去。工具链有版本控制、有文档、可复现，因为开源工作天然接受审视。这正是 Eric S. Raymond 在 《大教堂与集市》 中描述的动态：注视代码的眼睛越多，bug 越浅；知识传递成为流程的一部分，而非事后补救。\n小心\u0026quot;我们已经在卖那个\u0026quot;陷阱 #在购买任何东西之前，先看看你已经在运营什么。数量惊人的组织授权了商业 SIEM、商业扫描器和商业 EDR，然后发现自己现有的开源栈早已免费产出了其中 90% 的同类信号。\n这个模式反复上演：某厂商卖给你一个\u0026quot;解决方案\u0026quot;，其实是一层编排，底下是你自己就能跑起来的工具，外加一个 UI 和一份支持合同。当你缺人运维工具时，那份支持合同确有价值。但如果你有人，或者想培养出这样的人，开源路径通常更便宜也更有效。\n什么时候\u0026quot;买\u0026quot;仍然是对的 #这不是一刀切的论调。以下情况商业工具会赢：\n你完全没有人来运维工具，而支持本身就是产品。 厂商确实拥有你无法复制的专有检测内容。 需要对厂商本身（而不只是你对它的使用）进行合规认证。 关键是睁着眼睛、看清引擎盖之下是什么之后再做决定，而不是默认去买许可证。\n怀疑你现在的工具配不上它的许可费？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 如果你想让人替你完成这套组合，我们的 配置与架构评估 会审查你现有的运行情况，并为缺口规划一条自建还是外购的路径；或者 预约一次工程与范围界定会谈，围绕你的环境设计一套定制的栈。\n","date":"2025-10-15","permalink":"https://puresecurity.com/zh/posts/open-source-security-tools-thailand/","section":"安全洞察与公告","summary":"","title":"泰国：开源与商业安全工具之辨"},{"content":"大多数高管把网络安全合规体验为一笔必要的税：一年装订一次的活页夹、一位熬过去就行的审计师、一个似乎永远不产生收入的科目。这种框架是反的，而且它的代价超过审计费本身。做对了，合规是安全项目所能拥有的最强商业论证，因为它把工程投入转化成了买家、合作伙伴和监管机构真正可以验证的东西。\n合规验证支出，而不是创造支出 #安全预算是与财务部门的一场持久辩论。\u0026ldquo;去年的钱花出了什么？\u0026ldquo;是个合理的问题，而\u0026quot;我们拦住了威胁\u0026quot;这个答案，在发生泄露的那一刻就会迅速贬值。合规框架为这笔支出提供了一个外部的、可独立验证的标尺。\n当你的环境对齐了 ISO/IEC 27001、 NIST CSF 或 PCI DSS 4.0.1， 你资助的每一项控制都对应一条评估师可以测试的要求。这会把\u0026quot;我们觉得自己挺安全\u0026quot;变成\u0026quot;一家有资质的第三方已证明我们达到了国际标准\u0026rdquo;。对董事会而言，这是信仰型安全投资与证据型安全投资的区别。\n反面同样成立：没有框架，支出会漂向销售团队嗓门最大的那家供应商。合规强迫你排定优先级。当你的差距分析指出真正的风险是一个未打补丁的身份边界时，你很难再为一件面子工程辩护。\n信任与保证如今是采购准入条件 #APAC 的企业买家不再接受销售 PPT 里那句\u0026quot;我们非常重视安全\u0026rdquo;。他们会发来一份安全问卷，然后是审计权条款，然后是渗透测试。在受监管行业，他们会直接派来评估师。\n合规产物就是这场对话的通货：\n一张 ISO 27001 证书能省去数周的问卷往返。 PCI DSS 合规报告（ROC）或 AOC 是任何接触卡数据的组织的必过关卡，而且在支付价值链上游也日益成为硬性要求。 与泰国央行（BOT）IT 风险指引的对齐，向金融机构及其供应商传递了一个信号：你理解本地的监管视角。 每一项都在降低成为供应商的成本。这就是收入影响，而不仅仅是风险削减。潜在客户越快通过你的资质审查，交易就越快落地，你的工程团队被拉去填问卷而不是发产品的时间就越少。\n合规打开更大行业与更大客户的大门 #合规最被低估的好处是准入。泰国乃至整个 APAC 的政府招标、金融服务、医疗健康和大型企业采购，例行公事地把国际标准设为投标前提，而不是加分项。\n一家拿到 ISO 27001 的成长型软件公司，突然有资格参与此前被过滤掉的合同。一家保持 PCI DSS 4.0.1 合规的金融科技公司，能够接通那些原本会拒绝合作的收单机构和 PSP 伙伴。一家对齐 NIST CSF 的区域性公司，可以底气十足地回答总部反复追问\u0026quot;你们依据什么框架运作？\u0026ldquo;的美国母公司。\n合规实际上是一把市场准入钥匙。每个框架都会解锁一类新客户，对他们而言证书是见面之前就要过的最低门槛。\n有韧性、安全的服务才是真正的产品 #在\u0026quot;合规就是文书工作\u0026quot;的叙事里丢失的部分是：大多数框架控制措施不过是写下来的优秀工程实践。\n访问控制与最小权限减少横向移动。 变更管理与补丁压缩已知漏洞的可利用窗口。 日志与监控把盲目的宕机变成可诊断的事件。 备份与恢复演练是一次普通故障与一场终结业务的事故之间的差别。 IBM 数据泄露成本报告持续发现：更低泄露成本的最强预测因子是成熟的事件响应和经过测试的控制环境，而这正是框架逼着你维护的东西。 Verizon DBIR 则从攻击者一侧得出同样的结论：大多数事件利用的是已知的、可打补丁的弱点，而一个由合规驱动的补丁计划早就该覆盖它们。\n换句话说，合规就是一个组织制度化韧性的方式。它区分的是：一位会给服务器加固的天才工程师，和一个默认在上线时、并且永远给每台服务器加固的组织。\n向董事会这样讲 #如果你是为预算辩护的那个人，别再把合规说成经营的必要成本。把它讲成：\n保证：经独立认证的控制措施，更快关掉企业订单。 准入：拿到 otherwise 无法进入的受监管与企业采购资格。 证据：可度量的安全投资回报，而不是一句模糊的承诺。 韧性：制度化的工程纪律，人员流动也带不走。 这是一份 CFO 读得懂、CISO 站得住的商业论证。\n对 ISO 27001、NIST CSF 或泰国央行指引有疑问？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 从哪里开始 #大多数组织不需要把海洋煮沸。先针对你最大客户真正问到的那个框架做一次 差距评估， 修补那些对应真实暴露的差距，让证书跟随工程走，而不是反过来。\n如果你希望把它映射到自己的路线图上， 请预约一次工程与范围界定会谈，我们会把这个框架翻译成一份具体的工程任务清单。\n","date":"2025-09-17","permalink":"https://puresecurity.com/zh/posts/roi-cybersecurity-compliance-apac/","section":"安全洞察与公告","summary":"","title":"APAC 网络安全合规的商业 ROI"},{"content":"在东南亚扩张的金融科技公司面对的是一堆拼图式的监管机构，各有各的重点、时限和定义。能过新加坡金管局（MAS）这一关的控制环境，放到菲律宾央行（BSP）的监管下可能满是缺口。为马来西亚国家银行（BNM）设计的控制体系，不经过大改也未必能让泰国央行（BOT）的审查员满意。\n这不是纸上谈兵。我们见过机构在审计中途才发现，自己的日志留存周期满足一家监管机构却满足不了另一家；也见过合规团队搭好了符合 MAS 预期的 DPO 职能，才得知 BSP 要求不同的任职资格。这些昂贵的错误，都源于假设\u0026quot;亚洲的法规\u0026quot;可以互相通用。\n它们不能。\n四大监管机构一览 # 泰国央行（BOT） 新加坡金管局（MAS） 马来西亚国家银行（BNM） 菲律宾央行（BSP） 主要指令 IT 风险指引 / 数字渠道安全 科技风险管理指引 科技风险管理框架（RMiT） IT 风险管理框架 适用范围 受 BOT 监管的银行、PSP、电子货币发行方、金融科技公司 银行、保险公司、资本市场机构、支付服务 持牌银行、伊斯兰银行、电子货币发行方 银行、非银金融机构、电子货币发行方、VASP 日志留存 至少 1 年（热数据 90 天） 交易记录 5 年；系统日志按风险评估确定 至少 1 年，审计轨迹建议 7 年 所有安全相关日志至少 3 年 泄露通报 重大事件 24 小时内报 BOT；受影响个人 72 小时内，依据PDPA 严重事件 1 小时内；14 天内提交根因报告 1 小时内 email 报 BNM；7 天内书面报告 2 小时内报 BSP；14 天内详细报告 渗透测试 每年一次，或重大变更后 每年一次；范围按 TRM 指引界定 每年一次；覆盖面向互联网及关键内部系统 每年一次；重大系统变更后追加 要求冲突之处 #日志留存：三年陷阱 #最常见的跨辖区意外就是日志留存。按 BOT 一年要求搭建日志基础设施的组织，会栽在期望三年安全日志的 BSP 审查上。成本差异不是线性的：可检索地存三年日志，需要的架构和\u0026quot;存一年然后删\u0026quot;完全不同。\n反过来，围绕 BSP 三年标准建设的组织，在新加坡可能过度配置：MAS Notice 826 关注的是交易记录留五年，而系统日志走的是基于风险的方法，不是固定年限。\n实操建议： 按你经营的所有辖区中最长的留存要求设计日志管道。一次性同时满足多个监管机构，比事后改造便宜。\n数据保护官：是谁，而不只是有没有 #马来西亚 PDPA 明确要求数据保护官是马来西亚公民或永久居民 （2010 年个人数据保护法第 12 条）。 泰国 PDPA 没有这条明文规定，但实践中 BOT 的检查以泰语进行，并期待体现本地监管知识的回答：即使法律不强制国籍，这也形成了对泰语人才的间接偏好。\n新加坡走原则导向：MAS TRM 指引要董事会层面对技术风险负责，但不规定 DPO 的任职资格。菲律宾的 BSP Circular 1105 要求设首席信息安全官或同等角色，但未限定国籍。\n对区域化组织来说，这意味着：\n常驻新加坡的集团 DPO 可能满足不了马来西亚的要求 泰籍 DPO 可能缺乏 MAS 汇报所需的英语能力 菲律宾可能接受一位向区域负责人汇报的本地授权代表 实操建议： 在搭建区域合规团队之前先映射各辖区的 DPO 要求。有些情况下，任命向区域负责人汇报的本地代表，可以同时满足集中管控和本地监管预期。\n泄露通报：速度差异超乎想象 #通报窗口从一小时（MAS 严重事件）到七十二小时不等（泰国 PDPA 对受影响个人）。这不是小差别：一套按 BOT 二十四小时窗口校准的响应流程，如果严重事件发生在下班时间，就会错过 MAS 的一小时死线。\n场景 BOT MAS BNM BSP 在隔离测试服务器上发现勒索软件 重大事件须通报 无论是否隔离，1 小时内通报 1 小时内通报 2 小时内通报 配置错误的存储暴露客户数据 是 + PDPA 个人通知 是 + PDPA 个人通知 是 + PDPA 个人通知 是 + NPC（菲律宾隐私专员）个人通知 第三方供应商泄露波及你的数据 你有责任通报 BOT 你有责任通报 MAS 你有责任通报 BNM 你有责任通报 BSP 上表说明了为什么事件响应预案必须分辖区，而不能一刀切。同一场勒索软件事件，触发的是哪口时钟，取决于哪个主体发现了它、哪家监管机构管辖受影响的系统。\n可以对齐的地方 #尽管差异不少，重叠面同样很大。四家监管机构都期望：\n董事会层面的技术风险问责，以成文的治理结构佐证 定期渗透测试覆盖面向互联网及关键内部系统 漏洞管理项目，按严重程度设定修复时限 访问控制框架，落实最小权限与职责分离 成文、演练并持续更新的事件响应计划 第三方风险管理，覆盖接触敏感数据或系统的供应商 一个设计良好的控制环境可以同时满足多家监管。关键在于按最严格的适用要求设计控制项，再逐一记录如何满足每家监管的具体预期。\n例如，一个 72 小时内修复 critical 漏洞的漏洞管理项目，超出每家监管机构的预期。把这条时限记录一次，就同时满足了 BOT、MAS、BNM 和 BSP，无需任何修改。\n关键源文件 # 泰国央行 IT 风险指引 BOT 数字渠道安全服务通知 MAS 科技风险管理指引 MAS 网络卫生通知 MAS Notice 826：反洗钱与反恐融资 BNM RMiT 科技风险管理框架 BSP 备忘录 M-2020-022：IT 风险管理框架 BSP Circular 1105：强化公司治理指引 泰国个人数据保护法（PDPA） 新加坡个人数据保护法 马来西亚个人数据保护法 菲律宾数据隐私法 执法落差 #监管预期是一回事，执法强度是另一回事。理解这个落差有助于排定合规投入的优先级。\nMAS 公认是区域内技术上最老练的监管者。检查探的是落地深度，不只是政策存在与否。MAS 有过公开执法记录，包括针对技术风险失职的罚款和业务限制，例如 2023 年对 OCBC 处以 380 万新元罚款，理由是反洗钱控制不到位。\nBOT 自数字银行指引发布以来明显加强了执法。现在的检查包含技术测试，不只是文件审阅。不过相比 MAS，它提供了更多落地指导，解释歧义更少。\nBNM 凭借 RMiT 框架的规范性要求维持强势执法。规范性强意味着解读空间小，但选择替代方案的灵活性也小。\nBSP 正在积极补强监督能力。近期动向显示其执法强度将向 MAS 看齐：今天的合规缺口，就是未来检查中的发现项。\n实操建议 # 按最严格的要求设计。 只要在菲律宾运营，就建三年日志留存。其他辖区自动满足。 维护控制项到法规的映射表。 一张矩阵说明哪些控制满足哪些监管要求。跨辖区审计时价值连城。 不要假设互认。 监管机构之间不互相承认认证。通过 MAS 检查不免除 BOT 检查。 事件响应手册本地化。 按辖区准备通报模板、联系人清单和升级路径。危机中不该临时查通报时限。 尽早接触新市场的监管机构。 进驻前就开启对话，而不是部署之后。提前沟通能挖出公开指引未必覆盖的预期。 正在跨多个东盟辖区运营？ 欢迎聊聊如何把你的控制映射到每家监管的预期上。通过 LINE（@PureSecurity） 或电子邮件（hello@puresecurity.com）联系我们。 我们的合规咨询服务会把你的现有控制对照每家监管的具体要求， 识别缺口与重叠，产出多辖区检查所要求的文档证据。\n","date":"2025-05-14","permalink":"https://puresecurity.com/zh/posts/asean-cyber-regulations-comparison/","section":"安全洞察与公告","summary":"","title":"对比东盟网络安全监管：BOT vs MAS vs BNM vs BSP"},{"content":"","date":null,"permalink":"https://puresecurity.com/zh/tags/cloud-security/","section":"Tags","summary":"","title":"Cloud Security"},{"content":"云奖励速度。一个团队可以在一下午之内搭起完整的生产环境：计算、存储、数据库、负载均衡，全靠一条 CLI 命令或一份 Terraform 文件。同样的速度也适用于犯错。为了演示而公开、之后再没改回来的存储桶；为了在截止日期前\u0026quot;修复\u0026quot;连通性问题而对 0.0.0.0/0 放开的安全组；被粘贴进 Slack 频道的管理员凭证：每一样只需几秒钟，而每一样都可能暴露整个业务。\n这就是云安全的根本不对称性。本地部署中，一个失误通常只影响一台网络内服务器；而在云端，单个配置默认往往全球可达，各大洲都有自动化扫描器全天候寻找这些设置。如今的攻击者很少破门而入，正如那句话所说：他们是登堂入室，走的是有人忘了关的门。\n为什么配置错误主导云安全事件 #翻看公开的泄露记录，规律清晰可见。绝大多数云数据暴露并非源于新颖的漏洞利用，而是源于那些有据可查却被留在不安全状态下的已知配置：\n对象存储暴露公网。 存放客户记录、备份或数据库转储的存储桶，因为一个开关对全世界开放。 过度宽松的 IAM。 Action: \u0026quot;*\u0026quot; 配 Resource: \u0026quot;*\u0026quot; 的策略，为项目便利而授予，事后从未收紧。 管理控制台任意访问。 无 IP 限制、不强制 MFA，凭证从任何国家都能登录。 未加密的数据存储。 快照与卷对任何拿到标识符的人开放读取。 代码中的机密。 提交到代码仓库的 API 密钥，自动化爬虫几分钟内就能找到。 利用这些问题不需要任何高深技术，防范它们只需要基本的用心。这正是它们重要的原因：它们存在于平台文档所写的内容与忙碌的工程团队实际能核查的时间之间。\n看不见的就无法修好 #多数项目里第一个诚实的步骤，是承认这个面有多大。一家中型组织通常拥有数千个云资源，分散在不同的账户、区域和订阅中，由不同团队经年累月累积而成。没有人能把全貌装进脑子里，表格在写完几周后就会过时。\n这正是持续监控的价值所在。原则很简单：像对待应用健康一样对待配置状态：持续观察，而不是每年审计一次。\ngraph LR A[Cloud APIs\nconfig state] --\u003e B[Continuous assessment] C[IaC repos\nTerraform etc] --\u003e B D[Identity \u0026\naccess logs] --\u003e B B --\u003e E{Severity triage} E --\u003e|Critical exposure| F[Fix now:\nautomated where possible] E --\u003e|Drift and noise| G[Tune, baseline,\nscheduled remediation] style B stroke:#0EA5E9,stroke-width:2px style F stroke:#EF4444,stroke-width:2px style G stroke:#10B981,stroke-width:2px CSPM：有用的工具，但要用对 #云安全态势管理（CSPM）工具就是为了把这种观察自动化。它们将线上配置与 CIS 基础基准及各厂商最佳实践框架对比，然后给出带严重级别的发现。每家主流云现在都有原生选项（AWS Security Hub、Azure Secure Score、Google 安全指挥中心），第三方工具则增加多云覆盖和更深的上下文。\n用得好，它们确实有价值。用得粗糙，则会制造另一个问题：发现队列长到没人再看。区分两种结局的是三个习惯：\n先处理面向互联网的暴露。 公开存储、敞开的管理端口、无鉴权服务优先。这些是本周就可能变成事件的发现，而不是\u0026quot;以后再说\u0026quot;。 修源头，不只修资源。 如果某个发现靠手工修复，但 Terraform 模块仍会生成不安全的资源，你只是买来了一轮清理。改掉模块，这条发现在所有使用它的地方就永久消失。 不懈调优。 对不适用的发现有依据地抑制。只包含有人会处理的发现的队列，比没人读的全量队列有价值得多。 还要注意 CSPM 不做什么：它观察，但不强制。服务控制策略禁止公开存储桶、组织级策略阻断区域蔓延这类护栏能在创建时就阻止错误。最强的方案两者兼用：护栏拦已知的坏，监控兜其余的底。\n最好的控制是有认知的工程师 #上面每一层技术最终都依赖于人们理解这些设置为什么重要。懂得对象存储 ACL 与网络路由相互独立的工程师，在做\u0026quot;快速演示\u0026quot;前会犹豫要不要让桶全局可读。没学过的则会一路点下去。\n契合真实工程文化的实操做法：\n让安全的路成为容易的路。 黄金 Terraform 模块、预批准架构模式、默认启用加密和日志的内部模块，胜过任何政策文档。 短时动手工作坊。 用九十分钟对着你们自己的环境、一起审阅你们自己的 CSPM 发现，比一整天泛泛的云安全幻灯片有效得多。 对险情做无责复盘。 被同事赶在攻击者之前发现的暴露桶是免费的教材。写下来、广泛分享，然后把允许它发生的模块改掉。 让工程师尽早参与范围讨论。 设计期的安全评审花的是小时；上线后的安全评审花的是返工。 管理培训不是工具的软性替代品：它是你所购每一项控制的乘数。\n本季度就能开始的事 #如果只能记住一件事：不需要平台大改造，也能实质性降低云配置错误风险。现实的九十天序列如下：\n第 1 至 2 周： 清点每一个账户、订阅和项目。开启原生态势工具（如未开启）。 第 3 至 6 周： 分诊并修复所有面向互联网的暴露。这份清单通常不长，但永远值得。 第 7 至 12 周： 在 IaC 源头修复高频复现的发现，为要彻底杜绝的类别添加护栏，并基于自己的发现开展第一次工程培训。 躲过云事件的机构很少是工具最多的那批。它们是工程师明白每个设置含义、流水线让安全选项成为默认选项的那批。\n不确定你的云账户此刻正暴露着什么？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 如果想获得外部视角，我们的配置与架构评估 会对照 CIS 基准和你自身架构的意图审查你的云资产，或 schedule an Engineering \u0026amp; Scoping Session 与团队一起规划修复序列。\n","date":"2025-04-16","permalink":"https://puresecurity.com/zh/posts/cloud-misconfiguration-security-apac/","section":"安全洞察与公告","summary":"","title":"云配置错误：APAC 地区藏在眼皮底下的风险"},{"content":"每一份安全预算最终都会遇到财务部门的同一个问题：什么都没发生，为什么预防要花这么多钱？这是个公平的问题，值得一个数字化的答案。诚实的回答方式是为另一头定价，因为在整个东南亚，数据泄露的成本已不再是抽象概念。它白纸黑字写在法律条文、监管机构的处罚标准，以及直接适用于曼谷、新加坡、吉隆坡各地企业的卡组织规则里。\n把两栏数字并排一放，结论始终一致：即便不计那些永远不会出现在发票上的损失，防护的成本也只占真实事件成本的零头。\n监管机构设定的是下限，不是上限 #本地区的数据保护制度成熟得很快，而且每一部都长出了牙齿：\n司法辖区 制度 最高责任 泰国 PDPA 行政罚款最高 500 万泰铢，敏感数据违法另附刑事责任 新加坡 PDPA 本地年营业额超 1000 万新元的组织，最高可罚新加坡年营业额的 10% 马来西亚 2024 年个人数据保护修正法案 罚款提高且泄露通报失职可判监禁；直接义务延伸至数据处理者 印度尼西亚 2022 年第 27 号 PDP 法 行政罚款最高年收入的 2%，非法处理的数据将被销毁 澳大利亚 Privacy Act 修订案 最高 5000 万澳元、获益额三倍或调整后营业额的 30% 菲律宾 2012 年 Data Privacy Act 每项违法行为最高罚 500 万比索，责任人可判监禁 这张表里有三点比数字本身更重要。\n第一，这些是上限，而监管机构已经证明会用足它们。新加坡 PDPC 公布每一次执法决定，包括对未落实双因素认证管理员账户这类基本保障的组织开出的六到七位数罚单。泰国 PDPC 已开始发布整改令。整个地区的趋势只有一个方向：向上。\n第二，马来西亚的修正案是结构性变化，不只是改数字。强制泄露通报、对处理者的直接法定义务、强制任命数据保护官：这意味着供应商和服务商现在各自承担责任。无论你是向马来西亚提供服务，还是从相关供应商采购，你的合同都会受影响。\n第三，印尼按收入百分比计罚的模式意味着罚款随成功增长。对一家快速成长的印尼企业来说，五年后的同一场泄露可能比今天贵得多。\n罚款很少是最大的一笔 #高管们往往盯着监管罚款，因为它公开、可引用。但在实际经历过事件的机构口中，围绕罚款的一切花费更大：\n调查与响应。 取证团队、应急法务和外部事件响应都不便宜，而且是在时间压力下按危机费率计费。这正是 DFIR 年度服务能把恐慌性支出变成计划内关系的原因。\n大规模通知。 本地区泄露通报法要求在固定期限内联系受影响个人。对于几十万的客户基数，那是呼叫中心、邮件群发、征信监控服务：全都要在团队还没恢复完系统的时候交付。\n业务中断。 应急期间被下线的系统不产生收入。勒索软件事件尤其常见地让运营停摆数天到数周；恢复成本：重建的基础设施、加班、紧急采购硬件：在任何监管决定下达之前就已落地。\n客户与合作伙伴流失。 IBM 的数据泄露成本报告多年来持续追踪这一点：相当大比例的泄露成本出现在事件之后的一到两年里，主要来自客户流向竞争对手造成的业务流失。区域性研究一致发现，新兴市场组织识别和遏制泄露耗时更长，这会推高其成本。\n合同后果。 企业客户越来越多地在合同中写入带审计权和终止触发条款的安全条款。一次泄露等于把你最不愿让对方做的决定递到了这些客户手上。\nPCI DSS：拥有真实处罚的私营监管层 #只要你的组织处理持卡人数据，隐私监管之上就还有第二层执法。卡组织不会直接罚款商户：它们向收单银行收取违约金，再由收单行通过商户协议向下传导。公开报道中的数字从每月数千美元到数十万美元不等，持续不合规还会升级为取消收卡资格。\n失去收卡能力不是一张罚单。对本地区许多零售和酒店业者来说，这是生死存亡的事件。这就是认真做好 PCI DSS 范围缩减与差距评估而非应付了事的商业理由：评估费相对它关掉的敞口只是零头。\n把数字摆在一起 #设想一家中等规模的泰国金融科技公司：200 名员工，处理支付，持有客户 KYC 记录：\n预防（年化）： 一名兼职安全工程师的投入、一份 DFIR 服务、漏洞扫描与补丁纪律、每年一次演练、以及对照 PDPA 和 PCI DSS 要求的定期评估。对这个规模的大多数组织来说，总额大约在每年数十万泰铢量级。\n一次泄露： 最高 500 万泰铢的行政罚款、数周的取证与法务费用、覆盖全部客户的通知成本、 invoking 终止条款的企业客户，以及需要数月重建且永远回不到满格的商业信任。\n你不需要精确计算就能看出两栏对比的形状。预防是订阅费；泄露是一场带利息的诉讼。就算某一年发生事件的概率很低，两栏之间的不对称性也让期望值论证一目了然。\n什么才能真正压低代价 #并非所有安全支出都同样有效降低泄露成本。行业研究反复确认了一份短清单：\n更快的检测与遏制。 从被攻陷到被遏制的每一天都在增加成本。配上经验证的升级路径的监控，是杠杆率最高的单项投资。 演练过的响应预案。 排练过头 48 小时的组织，比临场现做决定的组织表现好得多。网络危机桌面演练能在修补还免费的阶段找到缺口。 收缩数据足迹。 不持有的数据无法泄露。保留期限限制和加密同时缩小泄露概率与波及范围。 分段与最小权限。 被围住的 incident 比扩散开的便宜，这正是我们反复强调网络分段的原因：它同时降低风险和修复成本。 没有一项需要新奇的技术。需要的是持续的工程用心，从事故之前开始，而不是之后。\n想现实地看看你的组织暴露有多大、关闭它又要花多少？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 我们的合规咨询梳理你在 PDPA、PCI DSS 及区域框架下的义务， vCISO 服务帮你建立能切实降低事件成本的预算论证。 或者 schedule an Engineering \u0026amp; Scoping Session，我们和你的团队一起算这笔账。\n","date":"2025-03-19","permalink":"https://puresecurity.com/zh/posts/data-breach-cost-southeast-asia/","section":"安全洞察与公告","summary":"","title":"东南亚数据泄露的真实成本"},{"content":"在东南亚处理支付的每一家机构，迟早都会同时遇到这两个框架，常常还落在同一个季度里。银行在企业准入时索要 ISO 27001 证书；收单行在同一时间索要 PCI DSS 合规证明。两场对话听起来很像：都有审计师、控制项、年度周期：于是很容易得出结论：它们可以互相替代。\n不能。分清这一点很重要，因为把一个当成另一个的替身，要么为不必要的认证买单，要么暴露在卡组织的处罚之下。本文讲清两个框架各自真正要求什么、在哪里重叠，以及为什么一起运行的成本低于分开运行。\nISO 27001：管理信息安全的治理框架 #ISO/IEC 27001 定义的是一个组织如何管理信息安全，与行业无关。它的核心是信息安全管理体系（ISMS）：一个由风险评估、控制选择、运行、测量和改进组成的循环。\n两个特征定义了它：\n它是基于风险的。 标准不告诉你买哪款防火墙、多久打一次补丁。它要求你识别自身风险，从附录 A 控制清单（及更广范围）中选择应对措施，并为每个决定给出理由。两家组织可以持有同样有效的证书，却运行着差别很大的控制集，因为它们的风险不同。\n由认可机构认证。 认证由经认可的认证机构在一阶段和二阶段审核后颁发。获证后进入三年周期，每年接受监督审核，期满再认证。这张证书国际通用，这正是采购团队喜欢它的原因：一份 PDF 回答了几十个供应商风险问卷条目。\n灵活的代价是抽象。ISO 27001 证书告诉合作伙伴你系统化地管理安全，但不保证任何具体技术保障措施达到了什么强度。\nPCI DSS：针对持卡数据的规范性操作要求 #PCI DSS 的存在只为一个目的：保护支付卡数据。各卡组织（Visa、Mastercard、Amex、JCB、银联等）通过 PCI 安全标准委员会发布标准，通过收单行和支付处理商以合同方式执行。\n它的性格几乎处处与 ISO 相反：\n它是规范性的。 现行的 v4.x 版本在十二个族群里列明具体要求：网络安全控制、安全的系统配置、存储账户数据保护、公网传输加密、恶意软件防御、访问控制、物理安全、日志与监控、定期安全测试。ISO 说\u0026quot;管理未授权访问的风险\u0026quot;，PCI 则直接写\u0026quot;15 分钟无操作即视为不可信\u0026quot;这类条款，连测试间隔都有明确规定。\n范围锚定在持卡数据环境（CDE）。 一切始于界定卡数据存放在哪、如何流动、连接到哪里。与 CDE 相连的系统进入范围；正确隔离的系统可以不在范围内。因此缩减范围是多数 PCI 项目中价值最高的动作：范围内的系统越少，证据越少、评估工时越少、持续成本越低。\n年度验证且角色各异。 视交易量和卡组织规则而定，验证通过合格安全评估师（QSA）签署的合规报告（ROC），或辅以季度 ASV 漏洞扫描的自评问卷（SAQ）。这里没有 ISO 意义上的\u0026quot;证书\u0026quot;：只有绑定到某一时间点的合规声明。\n并排对比 # 维度 ISO 27001 PCI DSS 目的 全组织的信息安全风险管理 专门保护支付卡数据 方法 基于风险，控制选择有评估依据 规范性，技术与流程要求明确 适用对象 任何组织、任何数据类型 存储、处理或传输卡数据的任何主体 验证 认可机构颁发证书，三年周期加监督审核 年度 ROC 或 SAQ、季度扫描，经收单行合同执行 范围 整个 ISMS，边界由组织划定 持卡数据环境，按数据流界定 失败后果 失去证书、合同受损 经收单行传导罚款、失去收卡资格 重叠之处 #尽管理念不同，底层的实际工作大部分是共用的。两个框架都要求：\n最小权限访问控制和唯一身份标识 敏感数据传输加密及静态机密保护 日志、监控和时间同步 漏洞管理与补丁纪律 敏感环境的网络分段 安全意识培训及有评审周期的成文策略 事件响应规划与演练 实践中，一次建好的控制通常能同时满足两边审计，前提是你刻意做了映射。挣扎的组织往往是为每位审计师各建一遍，因为没人维护框架间的对照表。\n同时运行两套的实用路径 #对一家泰国金融科技公司或任何一边收卡一边争取企业客户的区域企业来说，有效的顺序是：\n以 ISO 27001 锚定治理。 建立体系、风险登记册、策略文档集和管理评审节奏。这是其他一切的操作系统。 将 PCI DSS 叠加到 CDE 上。 把范围划紧，在边界内落实规范性要求，并把每条 PCI 要求映射回 ISMS 控制项。 共享证据管道。 一个日志平台、一套漏洞管理流程、一张访问评审日历，同时喂给两个项目。此后的评估就成了核验练习，而不是项目。 错开两套日历。 只要规划得当，ISO 监督审核和 PCI 年度声明可以落在一年中的不同时点。利用间隔，在另一边到来之前修完前一轮的发现。 这样做，在已有 ISO 27001 体系上叠加 PCI DSS（或反过来）的边际成本，远低于从零建起任何一个。做不好呢？付两次钱，窟窿照旧。\n所以你需要哪个？ #问两个问题。你接触支付卡数据吗？那 PCI DSS 就适用，没有商量余地，收单行会在最不合时宜的时刻书面确认这一点。企业客户、银行或监管机构期待可验证的安全治理吗？那 ISO 27001 能消掉一整类采购摩擦。\n支付行业的多数组织最终需要两者。好消息是它们相互成就：ISO 给你管理纪律，PCI 给你在资金流动之处的操作深度。\n还不确定该上 ISO、PCI 还是双管齐下？实际范围又覆盖到哪里？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 作为活跃的 QSA 执业机构，我们提供 PCI DSS 差距评估与 QSA 审计和 合规咨询， 包括组合式项目映射，让你用同一套控制满足两个框架。或者 schedule an Engineering \u0026amp; Scoping Session，聊聊你的具体情况。\n","date":"2025-02-19","permalink":"https://puresecurity.com/zh/posts/iso-27001-vs-pci-dss/","section":"安全洞察与公告","summary":"","title":"ISO 27001 与 PCI DSS：你的业务需要哪个？"},{"content":"如果要为一家想同时降低入侵风险和安全成本的机构选一项架构改造，我不会选新产品或新平台。我会选网络分段。据我所知，没有任何其他控制项能用同一笔钱同时缓解你最大的两个问题。\n原因很简单。几乎每一类昂贵的安全问题都共享同一个根源：扁平网络让小问题长成大问题。分段切断了这条因果链。它限制了攻击者在第一次得手之后能触及的范围，缩小了合规框架关心的系统集合，还把一团管不过来的摊子变成小团队能真正理解的架构。\n扁平网络如何悄悄失败 #扁平网络就是大多数系统可以和大多数系统互通的网络。这是网络的默认结局，因为扁平最方便：新服务器要连数据库时不用协商防火墙规则，开发者笔记本要连测试环境时也不用更新任何东西。\n代价随后到来。看看真实入侵是如何推进的。最初的立足点通常很小：一台被钓鱼的笔记本、一个有漏洞的 VPN 设备、一台忘了下线且管理端口直接面向互联网的测试服务器。单看这个立足点，价值不大。让泄露变得昂贵的，是横向移动：从第一台被攻陷的机器出发，攻击者探查网络、收割凭证、摸到那些本不该从用户设备可达的服务器，一路提权直到握住真正值钱的东西。\n扁平网络让这段旅程的每一步都免费。分段的网络让每一步都要付出攻击者看得见的代价：精力、时间和动静。渗透测试人员会告诉你差别有多大：在扁平环境里，我们常规操作是从一台笔记本几天内拿下整个域；面对设计良好的分段，同一场测试会卡在第一跳，然后一直停在那里。\n分段买到了什么 #1. 限制初次失陷的影响 #当分区之间由强制执行的边界隔开时，一台工作站被攻陷并不等于拿到支付系统、域控制器或工业控制系统的权限。攻击者握住的是一个分区，而不是你的业务。这就是\u0026quot;一个下午恢复的事件\u0026quot;和\u0026quot;一纸泄露公告\u0026quot;之间的区别。\n2. 阻断横向移动 #工作负载之间的东西向流量应该稀少、有目的、被观察。而在多数环境里它三者皆无。分段让落地后的攻击者到处撞上死胡同，而不是四通八达；那些必须存在的路径也窄到可以监控。\n3. 缩小合规范围 #成本下降在这里变成实打实的数字。PCI DSS 适用于持卡数据环境（CDE）及其相连的一切。有了经验证的分段：通过渗透测试验证：CDE 可能只剩几台系统而不是几百台。范围内的系统越少：收集的证据越少、评估工时越少、年度验证越便宜，需要打补丁和监控的面也更小。同样的逻辑也惠及 ISO 27001 的风险处置和任何关于遏制能力的监管对话。\n我们见过评估工作量直接减半的案例，仅仅因为客户事先完成了分段项目。而分段工程本身的费用，通常低于它带来的第一年评估节省。\n4. 让网络变得可管理 #最少被人提起的好处：分段后的网络是可理解的。当流量被约束在文档化的路径上，异常自然显眼。某台负载突然去连它从没通信过的数据库服务器：无论是一次事件还是一处配置错误：都值得关注。在扁平网络里，同样的信号会淹没在噪声里，因为所有东西一直在跟所有东西通信。分段正是让监控变得有意义的前提。\n经得起考验的设计原则 #好的分段是架构设计，不是采购设备。重要的原则：\n从数据出发，不是从机器出发。 先识别敏感数据在哪里、如何流动：持卡数据、凭证、个人信息、财务记录。分区围绕需要保护的东西成形，而不是照搬去年的旧图。\n按信任和功能分层。 对多数组织来说一个务实的基线：\ngraph TD I[Internet] --\u003e DMZ[DMZ / edge services] U[User networks] --\u003e APP[Application tier] DMZ --\u003e APP APP --\u003e DB[(Data tier:\ndatabases, CDE, secrets)] MGMT[Management network] -.-\u003e|admin access only| APP MGMT -.-\u003e DB U -.-\u003e|no direct access| DB style DB stroke:#EF4444,stroke-width:2px style MGMT stroke:#0EA5E9,stroke-width:2px 面向互联网的服务、用户终端、应用层、数据层，外加一张独立的带外管理网。每条边界都有明确的允许清单；清单之外一律拒绝。\n默认拒绝，然后有理由地放行。 每一条跨区放行的流量都应该有归属人和书面理由。如果没人说得清一条规则为什么存在，它就是一个等着被利用的 finding。\n云里也要分段。 安全组、VPC 和服务策略就是分段；只是云平台换了实现方式。纪律不变：生产与非生产隔离、数据库对互联网不可达、管理面走独立通道。\n验证分段，不要假设它成立。 只有扛得住攻击的分段才算数。PCI DSS 明确要求至少每年一次、并在重大变更后由渗透测试验证隔离性。一场渗透测试从每个分区尝试横向移动，才能告诉你设计是真的有效，还是只在图上好看。\n一条现实可行的路径 #没有人能在一个周末重造在线网络。有效的顺序：\n发现。 连续几周测绘真实流量。真实网络和它的文档永远不一样。 声明。 定义目标分区，写下必须跨越每条边界的流量清单，并取得业务方签字确认。 先围住皇冠上的宝石。 支付系统、域基础设施和敏感数据存储优先，好看的事往后放。 分批迁移。 按波次把系统移入分区，先从面向互联网的开始，在低风险区域消化教训。 验证并维持。 每年测试边界，每季度评审规则，任何未记录的跨区流量在被证明清白之前按事件处理。 多数组织在一到两个季度的持续投入内就能达到站得住脚的基线，而早期阶段通过缩小的审计范围立刻回本。\n底线 #安全支出通常面临取舍：降风险还是降成本。网络分段是那个长期的例外。它给成功突破的攻击封顶，饿死让事件变贵的横向移动，缩小你要应付的每个框架的范围，还给团队留下一张看得懂的网络。第二名不值得争。\n想知道你现在的网络会遏制入侵还是扩散入侵？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 我们的配置与架构评估 会测绘真实流量并设计团队可执行的分段路线图， 渗透测试则验证分段是否真的挡得住。 或者 schedule an Engineering \u0026amp; Scoping Session，聊聊从哪里开始。\n","date":"2025-01-15","permalink":"https://puresecurity.com/zh/posts/network-segmentation-design/","section":"安全洞察与公告","summary":"","title":"网络分段设计：一次投入，同时降低风险与成本"},{"content":"看到季度安全报告时，董事们会问一个合理的问题：这份东西我要拿来做什么？很多时候诚实的回答是：什么也做不了。报告里装着拦截邮件数量、培训完成率和一页从供应商材料里翻新的威胁形势幻灯片。这是活动汇报，不是保障，它让董事们停留在原点：无法判断这个组织是有韧性，还是只是很忙。\n能打动董事会的指标有一个共同属性：它们衡量的是压力之下的能力，而不是投入的努力。董事会不需要知道上个月过滤了多少封钓鱼邮件。他们需要知道的是：如果明天勒索软件落地，业务能否撑过这一周。\n为什么大多数安全汇报不及格 #安全团队通常汇报工具能统计的东西，因为提取最方便。结果就是一屏 steadily 上涨却毫无意义的数字：\n拦截威胁数。 数字越大往往只说明你收到的垃圾更多。每家邮件平台每天拦截百万级消息；有意思的问题是漏进来多少，而没有任何工具会诚实统计这个。 培训完成率。 完成率衡量出勤，不衡量行为。完成率 100% 的组织，照样可能在第二周的社工测试里栽跟头。 成千上万的漏洞计数。 没有暴露上下文的原始数字毫无意义。内部测试系统上一万条低危发现，不如面向互联网的支付基础设施上两条 critical 要紧。 告警量。 更多告警意味着更多噪声，不是更多安全。高告警量加慢分诊，恰恰说明还没准备好。 没有一条能回答董事们的受托责任问题：我们准备好了吗？怎么知道的？\n韧性长什么样：变成数字 #董事会治理的是结果：连续性、法律敞口、声誉。值得占用董事会时间的指标直接衡量这些。\n检测与响应速度 #从被攻陷到被遏制要多久？用真实事件和演练场景测出的平均检测时间（MTTD）和平均响应时间（MTTR），是安全领域最接近生命体征的东西。行业研究反复证实泄露成本与遏制速度挂钩：几周内遏制的组织比拖上几个月的组织付出少得多。如果连这几个数字都不知道，这本身就是该向董事会汇报的发现。\n恢复能力的证据 #从未恢复过的备份只是愿望，不是控制项。真正要紧的指标：上次把一套生产服务完整地从备份恢复出来是什么时候、花了多久？再加上勒索软件首选目标系统的不可变备份覆盖率。一次在约定 RTO 内完成的恢复演练，比任何威胁统计都更能给董事们吃定心丸，因为它直接证明业务扛得住破坏性攻击。\n演练及其成果 #高管团队上一次排练网络危机是什么时候、暴露了哪些缺口？桌面演练产出的发现包括：决策权限缺失、联系不上的供应商、没人认领的客户沟通职责。按审计发现的方式跟踪：已识别、已指派、已关闭。当董事会看到演练发现按期关闭，他们就知道这个组织的学习速度快于攻击者的进化速度。\n真正重要的敞口 #用与后果挂钩的敞口指标替换漏洞计数：\n面向互联网系统上的 critical/high 漏洞，SLA 内修复率：百分比与趋势。 任何营收相关系统上最老未修复 critical 的年龄。 特权账户中 MFA 与即时提权的覆盖率。 这些数字直接连接到被攻陷的概率，也就是董事们在管理的那些头条新闻。\n第三方敞口 #对许多组织来说，下一次泄露将从供应商进来。董事会应该看到：关键供应商完成了多少家评估、有多少份评估逾期、以及是否与每家关键供应商签有事故通报条款。这能干净地映射到董事们已经理解的供应商风险治理上。\n让业务远离新闻版面 #董事们描述安全目标的方式通常很朴素：别成为下一条泄露新闻。这个目标可以拆解为可衡量的组成部分，而且不需要技术背景就能解读：\n董事会关心的结果 佐证它的指标 入侵会被快速发现 MTTD 趋势；关键系统的监控覆盖 会在重大损失前被遏制 MTTR 趋势；测试中横向移动被拦住 能在勒索软件下存活 实测恢复时长 vs RTO；不可变备份覆盖 履行法律义务 演练过的泄露通报流程；映射完毕的监管义务 合作伙伴信任 关键供应商评估在效期内；框架认证有效 一份只含这张表、附趋势和例外的季度报告，比四十页工具统计数据更能给董事会真正的保障。\n怎样拿到诚实的数字 #这些指标要求工程上的诚实，这也是它们稀少的原因：\n通过演练测量，不要靠假设。 恢复时长来自真实的恢复；响应时长来自模拟入侵。如果没人跑过测试，就如实报\u0026quot;未知\u0026quot;：这对董事会同样是可行动的信息。 报趋势，不报快照。 单点数值招来粉饰；轨迹才揭示项目是否在改善。 每个红色数字都配上决策请求。 董事会靠资源分配来治理。\u0026ldquo;恢复测试达不到 RTO；需要两名工程师六周\u0026quot;是治理语言。\u0026ldquo;风险仍然偏高\u0026quot;不是。 保持简短。 一页带趋势的指标，一页待批事项。如果材料还需要会前导读，那就是太复杂了。 改用这种汇报方式的组织通常会发现一件有用的事：对话从\u0026quot;IT 钱花够了吗？\u0026ldquo;变成了关于恢复目标、人员配置和第三方风险的具体、可决断的问题。这种转变才是治理本该有的样子。\n想把董事会材料重建为真正衡量韧性的指标？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 我们的 vCISO 服务构建董事可以据此行动的报告体系， 网络危机桌面演练 产出让报告保持诚实的演练发现。或者 schedule an Engineering \u0026amp; Scoping Session 开启这场对话。\n","date":"2024-12-18","permalink":"https://puresecurity.com/zh/posts/board-security-metrics/","section":"安全洞察与公告","summary":"","title":"董事会真正需要的安全指标：跳出虚荣数字"},{"content":"勒索软件不是会过去的潮流。它是一门产业，而且利润丰厚：犯罪集团用销售团队、加盟计划、客服工单和谈好的分成比例来运营它。他们持续投入能力建设，因为它稳定地生钱：于是继续再投入、招募高水平开发者、进化速度超过大多数防守方的更新节奏。预防很重要，但诚实的起点是：假设某一天，尽管做对了一切，加密载荷还是会在你的系统上运行。备战就是从这个假设之后开始的。\n本文覆盖这枚硬币的两面：为什么勒索软件如此难挡，以及在现代云连接环境中真正的备战长什么样：包括攻击者碰得到却毁不掉的备份策略。\n为什么勒索软件这么难挡 #早期的勒索软件是机会主义的：加密被感染机器够得着的一切，要价几百美元。现代模式是定向且耐心的。团伙通过钓鱼、暴露的远程入口或买来的凭证获得访问权，然后用几天到几周时间悄悄向内推进、提权、摸清备份布局，并在触发任何可见动作之前把数据偷走。\n这种演变造成了两个防守方花钱也解决不了的问题：\n双重勒索拆掉了备份这条逃生通道。 从备份恢复曾经能让危机结束。现在拒绝付款，窃取的数据照样会被公开或出售，即使恢复得干干净净，你仍面临一场数据泄露、PDPA 及同类法规的通知义务和公开曝光。备份是必要的；但已经不够了。\n初始立足点只需要成功一次。 防守方必须赢下每一封钓鱼邮件、每一个未打补丁的设备、每一组泄露的凭证、每一条第三方连接。攻击者只需要在某个星期二成功一次。这种不对称不会因为许愿而倒向防守方。\n这不意味着防御没有意义；它改变的是被打中的概率。但它改变不了打中之后的结果。能改变结果的只有准备。\n真实经历是什么感觉 #董事会倾向于把勒索软件想象成一个技术事件。经历过它的组织描述起来更像一场带着账单的自然灾害：\n数周的停机。 即使是拒绝付款且备份完好的组织，完整恢复生产服务也常要几周：重建必须排序、验证，而且比所有人计划的都慢。 成本从四面八方同时涌来。 按危机费率计费的取证、应急法务、IT 与运营的加班、重建的硬件、逐日叠加的收入损失，以及之后接踵而至的监管调查。 高压之下做没有授权的决定。 谁来决定付不付赎金？谁来通知员工？谁来面对客户、监管者和记者？从没排练过这些问题的公司，答案往往给得又差又慢，还常常公开。 漫长的信任尾巴。 客户流失、企业合同被援引，这次事件还会在此后几年的每一次采购对话里被翻出来。 理解这个形状很重要，因为下面的每一项备战措施都直接对应着降低其中一项成本。\n不可变备份：改变结局的那项控制 #如果说有一项技术投资能把勒索软件从灭顶之灾变成糟糕的一周，那就是攻击者无法篡改或删除的备份。传统备份恰恰败在这里：它们是可达的。拿到域凭证的攻击者会例行公事地先删掉或加密备份任务，再对一家一无所有的组织发动总攻。\n现代对象存储用不可变性解决了这个问题：\nObject Lock / WORM 存储 以在保留期内任何人都无法修改或删除的形式写入备份*，包括你自己的管理员*。AWS S3 Object Lock、Azure 不可变 blob 存储以及其他云的同类产品都实现了这一模式。 保留期制造生存窗口。 设置好不可变窗口，让攻击者今天毁掉的一切之前的历史版本活到锁过期。这里正是云专属设计的要点所在：在文件老化出保留期之前，限制任何账户对受保护副本的写入与删除权限。不只是攻击者的账户：是所有账户。入侵过程中被攻陷的凭证是你自己的凭证，所以保护必须对他们同样成立。 备份身份完全独立。 备份基础设施应使用专用凭证、独立认证域，以及生产用户环境不可达的网络路径。如果同一个管理员账号同时管生产和备份，不可变性就在孤军奋战，而它值得帮手。 按计划演练恢复。 没测过的备份只是猜想。定期把一套生产服务完整恢复一遍、记录耗时，趁风险还低的时候修掉暴露的问题。 在备份之外收紧访问 #不可变性保护的是恢复路径。同样的\u0026quot;先赢得信任再放行\u0026quot;原则也适用于别处：\n特权即时化。 常驻的管理员权限等于拱手送给入侵者。带审批和过期的提权机制，缩小了单个被攻陷账号能解锁的范围。 分阶段的恢复环境。 一块干净的带外管理区，离线搭建或验证过，重建从这里发起。从被攻陷的管理面重建系统，等于把攻击者重新装回去。 关键系统的隔离分段。 支付系统、域控制器和工业控制系统放在强制边界之后，一台被加密的工作站能引发的连锁反应就小得多。 备战清单 #把它整理成一个小团队两个季度能执行完的顺序：\n备份优先： 关键系统的不可变 object-lock 副本、独立的备份身份、成文的保留策略、第一次完整的恢复测试。 排练决策： 一场网络危机桌面演练， 覆盖赎金问题、通报义务和沟通角色分工。现在找到缺口很便宜，以后找到就很贵。 提前建立响应能力： DFIR 年度服务 让取证和遏制在约定条款下几小时内启动，而不是危机进行中才开始走采购流程。 收缩特权常驻访问，覆盖所有身份平台。 每年验证边界： 分段与隔离声明要通过渗透测试验证，不能靠假设。 备战不会让勒索软件不可能发生。它把一场存亡事件变成一次昂贵但可以活下来的事故，而这两种结局之间的差别，几乎完全是在事件开始之前决定的。\n想知道你的组织下周能不能扛住勒索软件？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 我们的 DFIR 年度服务在你需要之前就把响应能力就位， 配置与架构评估 则对照这一场景审查你的备份架构、权限模型和分段。或者 schedule an Engineering \u0026amp; Scoping Session，和团队一起排这份清单。\n","date":"2024-11-20","permalink":"https://puresecurity.com/zh/posts/ransomware-preparedness-apac/","section":"安全洞察与公告","summary":"","title":"APAC 勒索软件备战：假设它一定会进来"},{"content":"零信任有个营销包袱。这个词总是和平台推销、多年期转型计划捆绑出现，给人一种印象：搞零信任意味着一次性替换整个身份、网络和终端体系。几乎所有这么尝试的组织都半途搁浅：项目大到无法立项、颠覆性大到没法执行，最后在某个指导委员会里悄无声息地死去。\n真正走到目的地的组织做的其实是更朴素的事。他们把零信任架构（ZTA）当成一个方向，而不是一次采购，然后用一个个小而稳定的步骤向它靠近，每一步都独立产生价值。而在几乎每个环境里，第一步都是同一个：清掉那些悄悄破坏你所拥有的每项现代控制的遗留访问协议。\n零信任到底要求什么 #剥掉包装，核心思想很简单：不再根据请求来自哪里授权，而是根据请求是什么、谁发出的来授权，并且每次都验证。\n传统安全信任网络内部。进了内网就是可信的，于是一台在公司局域网（或后来的 VPN）里的笔记本，只需极少复查就能触达一大片资源。零信任把这个假设倒了过来：\n显式验证。 每个请求都基于身份、设备健康度和上下文完成认证与授权，与网络位置无关。 最小权限。 用户和工作负载只拿到所需的最小访问，能按时间限定更好。 假设已失陷。 设计时就当攻击者已经进来，限制任何单点失陷能解锁的范围。 最后一条原则，正好解释了为什么遗留协议是最自然的第一个目标。\n第一步：请走遗留协议 #遗留访问协议是零信任的反义词。它们诞生在现代身份思维之前，带着一套无论堆多新的工具都救不了的假设：\nSMBv1 和其他因疏于关闭而仍在运行的陈旧文件共享方言，既是入口也是横向移动的通道。 NTLMv1 及其他弱认证方案，撑不起现代验证，而且 routinely 被中继或破解。 Telnet 和明文 FTP，在你声称已分段的网络里明文传输凭证。 HTTP Basic 认证和无签名 LDAP 绑定，把可重用的密码直接暴露给任何能观测流量的位置。 旧式邮件收取协议（未加密的 POP3/IMAP），绕过你在其他所有地方强制执行的 MFA。 每一个都在发出同样的邀请：带上上世纪九十年代的凭证来，我们照样认。只要它们还开着，它们就是绕开身份检查、设备状态检查和条件访问策略的后门。你不可能在一个\u0026quot;按位置即信任\u0026quot;的协议地基上盖零信任的大厦。\n清除工作还是少有的见效快、成本低的的安全项目。多数环境通过日志（而非猜测）发现，每个遗留协议只剩少数系统或流程还在依赖：一批老打印机、某个供应商的一条对接、一个被遗忘的应用。每一项依赖配一个短期整改计划；剩下的全部关掉。一个季度的专注工作通常就能消灭大部分敞口。\n然后持续向外升级 #地基清干净后，剩下的是一段层层递进的升级序列。没有一步需要大爆炸，每一步都让下一步更容易：\ngraph LR A[Remove legacy\nprotocols] --\u003e B[MFA everywhere:\nusers \u0026 admins] B --\u003e C[Identity-based access:\nreplace implicit trust] C --\u003e D[Device posture \u0026\nconditional access] D --\u003e E[Per-application micro-segmentation] style B stroke:#10B981,stroke-width:2px style E stroke:#0EA5E9,stroke-width:2px 先铺满 MFA，尤其是特权账户。 这是整条链上性价比最高的控制项，也为后续一切打下身份基础。可行的情况下给管理员上抗钓鱼方式。 用显式授权替换隐式网络信任。 把远程访问从扁平 VPN 迁到由身份中介的逐应用访问。每迁移一个应用，一台被盗笔记本的爆炸半径就缩小一分。 把设备健康纳入决策。 一旦访问经由身份流转，敏感应用就可以要求受管且打了补丁的设备。不健康的设备进隔离通道，别碰生产数据。 渐进式微分段工作负载。 从最关键的服务开始：支付系统、域基础设施、敏感数据存储。显式列出允许的调用方。这是零信任在东西向流量上的应用，与本博客之前讨论的分段纪律相互叠加。 度量和迭代。 记录每一次访问决策，评审拒绝日志找误伤，按团队能消化的节奏扩大范围。 为什么稳定胜过速度 #零信任项目的死法不是选错技术，而是三分钟热度。半成品的架构往往比没有更糟：两套访问模型并行意味着两套规则要维护，用户会绕开让他们烦的那套。\n稳步推进赢在：\n每个阶段收尾时都可用。 用户一次只经历一个变化，支持渠道就位，而不是迎面撞上一堵迁移墙。 安全收益来得早还会复利。 清掉遗留协议立刻见效；MFA 立刻见效。你永远不会抱着未建成的风险干等遥远的终点线。 预算经得起现实检验。 小而可立项的阶段能反复通过财务评审；一个巨型项目通常只通过一次然后被砍。 团队的架构认知随项目成长。 等做到微分段时，你的团队已经经历过身份升级和条件访问，知道自己环境的真实流量长什么样。 对一家中型组织来说现实的时间表是：一两个季度内清掉遗留协议，MFA 同步铺开，之后两三个季度推进逐应用访问，工作负载分段作为长期实践继续滚动。两年后回头看：从没搞过什么\u0026quot;转型\u0026quot;的你，已经在一个零信任架构上运行了。\n想要一条从现有资产出发的务实零信任路线图？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 我们的配置与架构评估 帮你找出今天环境里藏着的遗留协议和隐式信任路径， vCISO 服务则把 rollout 排成团队撑得住的可立项阶段。 或者 schedule an Engineering \u0026amp; Scoping Session，直接从第一步开始。\n","date":"2024-10-16","permalink":"https://puresecurity.com/zh/posts/zero-trust-implementation/","section":"安全洞察与公告","summary":"","title":"零信任落地：从能坚持下来的小步开始"},{"content":"大多数机构保护服务器的方式，就好像服务器才是值钱的东西。给它们做镜像、做备份、提心吊胆地打补丁，等一台死掉或被攻陷了，再投入大量时间把它原样恢复。而真正值钱的数据，就躺在这些服务器上，享受的不过是那台服务器碰巧得到的保护。\n把这个关系倒过来，很多安全问题会变简单。把系统当成耗材，把数据当成宝贝。用代码构建服务器，让它们几分钟能被替换而不是几天被恢复。然后把真正的保护精力集中在它该在的地方：数据本身：全程追踪生命周期、有目的地备份，而且越来越多地，干脆不放在处理它的系统上。\n系统用来重新部署，不是用来修理 #旧模式把服务器当宠物养。每一台都有名字、有脾气、有一段没人完整记录的手工修补史。宠物服务器一死，恢复就成了考古：靠记忆、笔记和希望去重建几年积累下来的变更。\n现代模式把服务器当牛群：借用那个比无数流行词活得更久的 DevOps 说法。你不会抢救一头病入膏肓的奶牛；你换掉它，继续往前走。落到实践中：\n基础设施即代码。 每台服务器、每个容器、每份配置都以声明式定义：Terraform 管平台层，Ansible 或 cloud-init 管主机层，容器镜像管工作负载。一个运行中的实例只是这份定义的一次实例化，与其他任何实例没有区别。\n不可变部署。 不是登进服务器改配置，而是构建新版本、测试后滚动发布，整批替换旧实例。什么都不累积。配置漂移：那些让每个环境都独一无二且无法解释的手工改动悄悄堆积：从结构上就不可能发生。\n重新部署取代恢复。 这是让很多人意外的收益：一支正确搭建的\u0026quot;牛群\u0026quot;舰队几乎不需要备份。如果一台服务器被攻陷、损坏或干脆丢了，你不去恢复它，而是按代码重新部署，几分钟的事，因为那份定义就是备份。事故中的对话不再是\u0026quot;怎么把这台机器救回来？\u0026quot;，而是\u0026quot;替换实例能起多快？\u0026quot;：在真实事件里，这是个好得多的对话。\n这也大幅缩小了勒索软件的打击面。加密只能伤害难以重现的东西。由 Git 仓库定义的可抛弃机器，恰恰最容易重现。\n所有的注意力转向数据 #一旦系统变成耗材，一切不可替代的东西都在数据里。数据值得拥有自己的纪律，而这始于一个多数组织从未精确回答过的问题：我们持有哪些数据、存在哪里、谁在接触、随时间如何流转？\n全生命周期追踪数据。 创建、处理、复制、归档、销毁：每个阶段都应该被知晓且是有意的。生命周期追踪反复带来回报：它告诉你监管义务附着在哪里（PDPA 及同类法规跟随数据而非机器）；它暴露那些无人认账的遗忘副本：泄露真正发生的地方；它还告诉你今天就能删什么，这往往是最便宜的风险削减：不存在的数据无法泄露。\n有目的地备份数据，而不是无意识地备份机器。 当系统以代码定义，备份变得聚焦而诚实：数据库转储、对象存储复制、配置仓库、密钥保险库。一小批真正重要的东西，可验证，而不是每晚对一切（包括垃圾）做整机镜像。\n考虑让数据根本不在处理它的系统上。 应用可以几乎不在本地持有任何东西：状态放托管数据库，文件放对象存储，机密放保险库。这样处理层就没有值得偷的东西，一台被攻陷的应用服务器就从\u0026quot;需上报事件\u0026quot;降级成\u0026quot;运营麻烦\u0026quot;。附带的好处是，专为存储设计的数据服务通常内置更强的保护：版本控制、不可变选项、细粒度访问控制：比任何通用服务器能做到的都好。\n运营一支机队，而不是三支 #这里面还藏着第二重简化，关于机队本身。看看任何 Windows 与 Linux 混合环境的成本结构，数一数重复建设：\n两套技能。 Windows 管理和 Linux 管理是两个职业。两头都支持意味着要么各聘专家，要么接受两头都不深。粗略地说，同样数量的机器，两倍的团队。 两套工具链。 补丁、监控、配置管理、加固基线、Agent 部署：每样都有两份，各自采购、维护、升级。双倍预算、双倍的管理面攻击面、双倍可能悄悄掉队的东西。 两套失效模式。 事件响应手册、取证能力、灾备流程全都按平台分叉。事故发生时，这个分叉消耗的恰好是你最缺的时间。 航空公司的类比在这里站得住脚。没有哪家成功的航司什么机型都飞：每多一种机型，维护项目、备件库存、机组资质、培训管线和机库设备都会成倍增加，而且这些成本永远循环，远在采购决定被遗忘之后。所以航空公司无情地把机型标准化到覆盖航线所需的最小集合。IT 机队值得同样的算术。选定你的标准操作系统并守住阵线，就把所有\u0026quot;两份\u0026quot;变成了\u0026quot;一份\u0026quot;，而节省逐年复利。\n标准化还直接强化安全。一支机队意味着一条吃透了的加固基线；一条调校到位、可以信赖的补丁流水线；一套贴合实际机队的检测规则。深度每一次都胜过覆盖面。\n从哪里开始 # 挑一个工作负载，让它可抛弃。 反复用代码重建，直到完整替换只需几分钟、没有任何东西是手工配的。 诚实地盘点数据。 在哪、在哪台系统上、归谁管、哪些明天就能删。 把状态移出应用服务器， 放进带合适访问控制和不可变选项的专业存储。 诚实计算机队的分叉成本。 把重复的许可、工具和人头加总，对照整合的价格。像航司评估航线一样呈报领导层：经常性成本对经常性收入。 立下今后的标准： 新系统一律加入标准机队、以代码定义、尽量无状态。例外必须写下理由。 关注点分离是工程界最古老的教训之一，安全完全可以字面地受益于它：系统是短暂的，数据是永久的，按各自的真面目保护两者，比为两者都保护不好更省钱。\n想知道你的关键数据能否在所有相关服务器全部丢失的情况下幸存？ 欢迎联系我们做一个直接的可行性判断。通过 LINE（@PureSecurity）或电子邮件（hello@puresecurity.com）联系我。 我们的配置与架构评估 会梳理数据存放与处理的分布并设计分离路径， Linux 加固实践则帮你打下让标准化产生回报的单机队基线。 或者 schedule an Engineering \u0026amp; Scoping Session，和团队一起规划。\n","date":"2024-09-18","permalink":"https://puresecurity.com/zh/posts/separating-data-from-systems/","section":"安全洞察与公告","summary":"","title":"把数据与系统分开：以不可变性设计"},{"content":"Pure Security 围绕三大支柱展开：由在职 QSA 验证的法规合规、以可直接使用的配置交付的技术安全工程，以及承载真实问责的战略治理。\n这一模式刻意保持直接：为您界定项目范围的人，就是实际执行项目的人。因此评估与整改之间没有任何脱节，每一条建议都来自亲自运营过相关控制措施的人。\n对大型企业而言，这意味着一位坐在您这一侧的评估者：一位曾向董事会、监管机构和央行审查人员负责的前 CISO。对成长型企业而言，这意味着规模与预算相匹配的高层能力，且工作范围在开工前以书面形式固定。\n凡是由我们设计或运营的控制措施，我们都会将该控制的独立保证工作分开进行，以确保您获得的建议始终客观。 #","date":null,"permalink":"https://puresecurity.com/zh/services/","section":"安全服务","summary":"","title":"安全服务"},{"content":"为您界定项目范围的人，就是实际交付项目的人。\n以直接交付为本，杜绝层层转手 #Pure Security 的组织方式确保：界定您项目范围的人，就是交付项目的人。您直接获得 CISO 级的判断力和务实的安全工程能力，在了解您环境的人与实际动手的人之间，不存在任何交接损耗。\n这些工作背后是 20 多年的安全领导经验：曾任服务 100 多家金融机构、横跨 12 个辖区的亚太支付处理商 CISO；曾任泰国某银行集团数据与 AI 业务的信息安全负责人；曾任全球科技平台的企业 GRC 负责人；以及澳大利亚空中交通关键基础设施的 7x24 安全运营负责人。\n早期职业根基奠定于澳大利亚信号局，参与编写包括 Information Security Manual 在内的国家防御政策，并主导针对国家级威胁的防御行动，此后还负责过高保障政府与企业平台的站点可靠性工程。\n我们的服务范围 # 泰国：我们的本土市场，依据泰国央行（BOT）和泰国证券交易委员会的监管要求，支持受监管行业 亚太地区：为跨国经营集团提供跨境项目。我们已设计并实施了符合该地区 10 多个独特辖区和控制框架的网络安 全计划，深谙各地不同的监管与运营要求。服务覆盖法规合规、技术安全工程和战略治理。 预批签证：我们可以明天就加入您的团队。我们持有可进入多数亚太国家的预批商务签证，包括澳大利亚、文莱、中国、香港特区、印度尼西亚、日本、韩国、马来西亚、新西兰、巴布亚新几内亚、菲律宾、新加坡、中华台北、泰国和越南： China Australia Indonesia Japan New Zealand Philippines Papua New Guinea Malaysia Thailand Vietnam South Korea Taiwan Hong Kong SAR Brunei Singapore 清晰、可执行的成果 #我们提出的每一项发现都附带责任人、整改路径和成本估算。报告会说明测试了什么、未测试什么，以及这些差距在业务层面的含义，包括对我们自身不利的发现。\n透明、合理的定价 #报价在提案之前公开，范围以书面形式固定，因此在工作开始之前，商业图景已经清晰。\n当某项工作不适合我们承担时，我们也会直言拒绝。例如独立审计我们自己设计或运营的控制措施会有损独立性，此时我们会告知您，并在可能的情况下推荐其他可信供应商。\n开始对话 # 需要快速评估？ 描述您需要的成果，您将与实际执行工作的专家直接对话。\nLINE 联系我们 致信安全工程师 ","date":null,"permalink":"https://puresecurity.com/zh/about/","section":"全方位安全，负责任地交付","summary":"","title":"关于 Pure Security"},{"content":"直接与经验丰富的 CISO 或在职 QSA 对话。\n开始对话 #描述您需要的成果，您将与实际交付工作的人直接对话。无论最终是否合作，所有咨询均按保密处理，初步沟通不附带任何义务。\n联系渠道 #hello@puresecurity.com\nLINE: @PureSecurity\n+66 88 788 8600\n建议包含的信息 #预先提供以下信息通常能省去一个来回：\n您需要的成果，以及驱动它的截止期限 工作所属的支柱：合规、技术安全或治理 涉及的框架（PCI DSS 4.0.1、ISO 27001、NIST CSF、BOT 指引） 响应时间 #我们会在一个工作日（曼谷时间，UTC+7）内回复新咨询。事件响应常驻客户享有合同约定的更优响应时限，并以书面形式保证。\n已购买 DFIR 常驻服务？ #常驻客户完全无需排队：合同约定的响应时限、指定的工程师，以及从第一次通话开始的证据保全指导。请参阅 DFIR 常驻与内部调查 了解常驻服务内容。\n正在处置安全事件？ #正在应对活跃事件？ 请在邮件主题中注明，我们将优先处理。\n","date":null,"permalink":"https://puresecurity.com/zh/contact/","section":"全方位安全，负责任地交付","summary":"","title":"联系 Pure Security"},{"content":"我们是谁 #纯粹安全有限公司（\u0026ldquo;Pure Security\u0026rdquo;、\u0026ldquo;我们\u0026rdquo;）为泰国及更广泛亚太地区的组织提供托管安全、治理与鉴证服务。\n我们收集什么 # 咨询数据：您联系我们时的姓名、组织、电子邮箱及消息内容 合作数据：为交付服务所必需的客户人员联系方式 技术数据：标准服务器请求日志。本网站不使用任何分析、广告或第三方跟踪工具，字体亦由本站自托管，而非从第三方 CDN 加载。 我们如何使用 #咨询数据用于回应您的请求，合作数据用于交付与贵机构约定的服务。\n保留期限 #咨询数据自最后一次联络起保留 24 个月。合作记录按合同及适用法定义务要求的期限保存，随后安全销毁。\n数据共享 #我们不出售个人数据。除法律要求，或为交付服务所必需且受同等义务约束的分处理者之外，我们不会与他人共享个人数据。\n您的权利 #您可以请求访问、更正、删除、限制处理、携带您的个人数据，或反对处理。如需行使上述权利，请联系 hello@puresecurity.com。\n政策变更 #本政策的重大变更将在此处更新，并注明修订日期。\n","date":null,"permalink":"https://puresecurity.com/zh/privacy/","section":"全方位安全，负责任地交付","summary":"","title":"隐私政策"}]