章节目标
Security assessment and testing programs perform regular checks.
安全评估与测试计划会执行定期检查。
本章讲的不是一次性检查,而是周期性验证安全控制是否还在正常工作。
Domain 6 的主线是测试、评估、审计、报告和改进。
左侧是英文原文摘录、中文直译、小白解释和考点提醒;右侧是对应画报。手机端会先显示画报,点击图片可放大查看。
安全团队不是把控制部署上去就结束,而要持续测试、评估和审计,确认控制足够、有效、在本地、云和混合环境中都能稳定保护资产。
Security assessment and testing programs perform regular checks.
安全评估与测试计划会执行定期检查。
本章讲的不是一次性检查,而是周期性验证安全控制是否还在正常工作。
Domain 6 的主线是测试、评估、审计、报告和改进。
The program includes tests, assessments, and audits.
该计划包括测试、评估和审计。
测试看控制是否运行,评估看整体风险,审计看独立证明。
Testing、Assessment、Audit 的差异是本章最核心考点。
Security tests verify that a control is functioning properly.
安全测试验证控制是否正常运行。
例如自动扫描、工具辅助测试、人工尝试验证控制效果。
testing 更偏控制是否工作。
Security assessments are comprehensive reviews.
安全评估是全面审查。
评估不只看工具输出,还要看威胁环境、当前和未来风险、目标环境价值。
assessment 通常产出给管理层的风险与建议报告。
Audits demonstrate the effectiveness of controls to a third party.
审计向第三方证明控制的有效性。
审计强调独立、公正和证明,报告受众常是董事会、监管者、客户或第三方。
audit 的关键词是 independence。
The program should be effective in on-premise, cloud, and hybrid locations.
计划应在本地、云和混合位置都有效。
不能只测传统数据中心,SaaS、云平台、混合架构也要纳入范围。
location 范围题常考 on-premise、cloud、hybrid。
Managers should consider criticality, sensitivity, likelihood, and business impact.
管理者应考虑关键性、敏感度、可能性和业务影响。
越关键、越敏感、变化越快、越可能被攻击的系统,测试频率应更高。
测试计划要按风险优先,而不是拿新工具随便扫。
Security professionals must carefully review the results.
安全专业人员必须仔细复核测试结果。
工具跑完不等于测试成功,结果要确认、解释、告警和跟踪。
测试输出需要人工或自动复核,必要时开工单。
安全评估是面向风险和改进的全面审查,通常输出给管理层。NIST SP 800-53A 把评估对象分为规范、机制、活动和人员四类。
Security assessments are comprehensive reviews of a system, application, or environment.
安全评估是对系统、应用或环境的全面审查。
它比单次扫描更宽,关注控制、风险、威胁和资产价值。
题目问 comprehensive review,通常是 security assessment。
A professional performs a risk assessment that identifies vulnerabilities.
专业人员执行风险评估并识别漏洞。
评估要找出可能导致妥协的弱点,并说明影响和修复建议。
assessment 包含风险判断,不只是列漏洞。
The main work product is an assessment report addressed to management.
主要成果是面向管理层的评估报告。
报告要用非技术语言讲清结果,并给出可执行建议。
评估报告受众常是 management。
Assessments may be conducted internally or outsourced.
评估可由内部团队执行,也可外包。
如果领域专门性强,可以请第三方评估团队。
外包评估不等同审计,审计更强调独立证明。
Specifications include policies, procedures, requirements, and designs.
规范包括策略、程序、要求和设计。
这是控制应该如何被定义和记录。
NIST 800-53A object: Specifications。
Mechanisms are the controls used within an information system.
机制是信息系统中使用的控制。
防火墙、访问控制、加密模块、配置项都可能是机制。
Mechanisms 可基于硬件、软件或固件。
Activities are actions carried out by people.
活动是人员执行的操作。
备份、导出日志、审查账号历史都属于活动。
Activities 强调人做的流程动作。
Individuals implement specifications, mechanisms, and activities.
人员实施规范、机制和活动。
评估者可访谈人员,确认他们是否理解并正确执行控制。
四类对象:Specifications、Mechanisms、Activities、Individuals。
审计和评估会使用相似技术,但审计必须由独立审计人员执行,目的是向第三方证明控制有效性。
Security audits use many of the same techniques as assessments.
安全审计使用许多与评估相同的技术。
审计也会检查文档、访谈、测试控制,但目的和独立性不同。
不要因为技术相似就把 audit 和 assessment 混为一谈。
Audits must be performed by independent auditors.
审计必须由独立审计人员执行。
设计和运行控制的人评价自己的控制,天然存在利益冲突。
independent auditors 是 audit 的核心关键词。
Auditors provide an impartial, unbiased view.
审计师提供公正、无偏的视角。
审计报告的价值在于别人可以相信它不是自说自话。
impartial、unbiased 都指审计独立性。
Audit reports may include the board, regulators, and third parties.
审计报告受众可能包括董事会、监管机构和第三方。
评估报告多为内部改进,审计报告常用于外部证明。
report audience 是区分 assessment/audit 的线索。
There are internal audits.
审计类型包括内部审计。
组织内部审计团队执行,但仍应保持相对独立。
internal audit 在组织控制范围内。
There are external audits.
审计类型包括外部审计。
外部审计由组织外部人员执行,独立性通常更强。
external audit 来自组织外部控制。
There are third-party audits.
审计类型包括第三方审计。
常用于服务提供商、供应商、云或托管环境的控制证明。
third-party audit 常与 outside enterprise control 相关。
Audits may occur on-premise, cloud, or hybrid.
审计可发生在本地、云或混合环境。
云服务不是免审计区域,反而要明确责任和证据来源。
审计策略同样要覆盖 on-premise、cloud、hybrid。
漏洞评估要先把漏洞、平台、配置和检查清单统一命名和评分,才能让扫描、报告和修复排序说同一种语言。
CVE provides a naming system for security vulnerabilities.
CVE 为安全漏洞提供命名系统。
它给漏洞一个通用编号,便于工具、厂商和团队引用同一个问题。
CVE = naming system。
CVSS provides a standardized scoring system.
CVSS 提供标准化评分系统。
它帮助描述漏洞严重性,但实际修复优先级还要结合资产和业务。
CVSS = severity scoring。
CCE provides a naming system for configuration issues.
CCE 为系统配置问题提供命名系统。
配置弱点也要统一命名,便于基线检查和修复追踪。
CCE 对应 configuration。
CPE provides a naming system for platforms.
CPE 为平台提供命名系统。
系统、应用和设备用统一平台名标识,方便判断某漏洞影响哪些资产。
CPE 对应 operating systems、applications、devices。
XCCDF specifies security checklists.
XCCDF 用于指定安全检查清单。
它描述如何表达检查项和基线要求。
XCCDF 与 security checklists 绑定记。
OVAL describes system states and vulnerability checks.
OVAL 描述系统状态和漏洞检查逻辑。
它能表达某个系统是否满足某个漏洞或配置条件。
OVAL 常与自动化检查内容相关。
SCAP combines security automation standards.
SCAP 组合多种安全自动化标准。
它把命名、评分、平台、检查清单等标准整合到自动化扫描和报告中。
SCAP = automation framework style concept。
Administrators should confirm that findings are not false positives.
管理员应确认发现不是误报。
扫描结果不能直接当真,需要验证真实存在和影响。
Validation 是漏洞管理闭环中的关键步骤。
漏洞扫描只负责发现或提示弱点,漏洞管理才负责验证、排序、修复和复测。考试常考扫描类型和工作流差异。
Discovery scans detect open ports and services.
发现扫描检测开放端口和服务。
先弄清网络里有什么主机、端口和服务,再谈具体漏洞。
discovery scan 更偏资产和暴露面发现。
Network vulnerability scans probe for known vulnerabilities.
网络漏洞扫描探测已知漏洞。
它比发现扫描更深入,会检查版本、配置和已知弱点。
network vulnerability scanning 不等于 exploit。
Web applications pose significant risk to enterprise security.
Web 应用给企业安全带来显著风险。
Web 服务常暴露给互联网用户,输入处理、认证、会话和配置都要检查。
Web scanning 与 WAF、PCI DSS、OWASP 工具常一起出现。
Databases contain sensitive information and are lucrative targets.
数据库包含敏感信息,是有吸引力的目标。
数据库扫描关注配置、补丁、权限、弱口令和数据暴露。
数据库背后通常是组织最敏感数据。
Wireless assessments test encryption and security parameters.
无线评估测试加密和安全参数。
还可能结合被动监控,识别网络中的 rogue devices。
wireless assessment 关注加密、接入点、流氓设备。
Detection is the initial identification of a vulnerability.
发现是最初识别漏洞。
扫描或其他检测手段生成候选发现。
漏洞管理第一步通常是 detection。
Administrators confirm the vulnerability is not a false positive.
管理员确认漏洞不是误报。
验证真实存在、适用范围和可影响资产。
false positive 必须排除。
Workflow includes remediation and verification.
工作流包括修复和验证。
修完要复测,确认风险已降低或关闭,否则只是“计划修复”。
Remediation 后要 verification/retest。
渗透测试在授权范围内验证弱点是否可被利用,BAS 和红蓝紫队更偏持续演练和防御改进。这里学习考试概念,不涉及操作步骤。
Penetration tests go beyond vulnerability testing techniques.
渗透测试超越漏洞测试技术。
漏洞扫描通常只是探测弱点,渗透测试在授权范围内验证弱点能否造成实际风险。
扫描发现,渗透测试验证。
Security tests should be carefully designed.
安全测试应被仔细设计。
渗透测试必须有范围、规则、时间窗口和业务影响控制。
rules of engagement 是渗透测试治理要点。
Red team exercises emulate adversary perspectives.
红队演练模拟对手视角。
红队侧重发现防御缺口和真实攻击路径风险。
red team = offensive perspective in authorized exercise。
Blue teams monitor, detect, and respond.
蓝队负责监控、检测和响应。
蓝队关注日志、告警、隔离、阻断和恢复。
blue team = defensive operations。
Purple teams combine red and blue team lessons.
紫队结合红队和蓝队经验。
把红队发现转化为蓝队检测和响应能力提升。
purple team = collaboration and improvement。
Breach and attack simulations validate detection and response.
BAS 验证检测与响应能力。
它是持续、受控的演练,用于确认监控和防御是否能识别已知行为。
BAS 更偏持续自动化验证。
Analyze test output and generate report.
分析测试输出并生成报告。
发现要变成风险、建议、修复计划和复测结果。
测试没有报告和修复跟踪,就不算闭环。
软件开发安全也纳入本章。SAST、DAST、IAST、SCA 和代码审查关注不同阶段和对象,合规检查则把法规和标准映射为控制要求。
Application security testing includes SAST, DAST, SCA, and IAST.
应用安全测试包括 SAST、DAST、SCA 和 IAST。
这些测试覆盖代码、运行时行为、依赖组件和交互式分析。
缩写题要按测试对象记。
SAST is static application security testing.
SAST 是静态应用安全测试。
不运行应用,分析源代码、字节码或二进制中的安全缺陷。
static = look at code without running it。
DAST is dynamic application security testing.
DAST 是动态应用安全测试。
应用运行起来后,从外部像用户一样发送请求并观察行为。
dynamic = test running application。
IAST is interactive application security testing.
IAST 是交互式应用安全测试。
结合运行时内部信息和外部测试,定位更贴近代码路径。
interactive = runtime insight + test activity。
SCA analyzes software components.
SCA 分析软件组成组件。
检查第三方库、开源依赖、许可证和已知漏洞。
SCA = dependencies/components。
Code review and testing are security controls.
代码审查与测试是安全控制。
人工评审和工具分析都能在上线前发现缺陷。
越早发现缺陷,修复成本通常越低。
Compliance checks map obligations to controls.
合规检查把义务映射到控制。
法规、标准和合同要求需要落到具体控制证据上。
compliance check 不等于安全充分,只是满足要求的一部分。
PCI DSS may require web application vulnerability scans or WAF.
PCI DSS 可能要求 Web 应用漏洞扫描或 WAF。
支付环境对 Web 风险有明确额外要求。
PCI DSS、Web scanning、WAF 是常见组合。
本章不只讲漏洞扫描和渗透测试,还包含合成事务、基准测试、误用案例、覆盖率分析、接口测试和网站监控等更细的测试手段。
Synthetic transactions test expected business processes.
合成事务测试预期业务流程。
模拟正常用户路径,比如登录、下单、支付,确认系统可用且响应合理。
synthetic transaction 偏正常流程与可用性监控。
Benchmarks provide standardized measures.
基准测试提供标准化衡量。
用固定指标或基线比较性能、配置或控制状态。
benchmark = compare against baseline/standard。
Misuse case testing considers incorrect or abusive use.
误用案例测试考虑错误或滥用使用方式。
从“用户不该怎么做、攻击者可能怎么误用”角度设计测试。
misuse case 看异常或滥用场景。
Coverage analysis measures test coverage.
覆盖率分析衡量测试覆盖范围。
确认关键功能、接口、路径和风险点有没有被测试到。
coverage analysis 不是找漏洞本身,而是看测试是否覆盖充分。
Interface testing includes user, network, and API interfaces.
接口测试包括用户、网络和 API 接口。
检查输入输出、边界条件、错误处理和接口权限。
UI、network interface、API 都是 interface testing。
Website monitoring observes availability and status.
网站监控观察可用性和状态。
持续检查响应时间、证书、页面内容和服务可用性。
website monitoring 更偏持续运行状态。
Testing methods should match the control objective.
测试方法应匹配控制目标。
要测可用性就别只看漏洞,要测接口边界就别只看首页是否打开。
题目问最佳测试方法时,先看目标。
安全过程数据用于证明控制在持续运行,并帮助管理层发现趋势、例外和修复进展。日志审查、账号管理、备份验证都是重要证据来源。
Log reviews examine security-relevant activity.
日志审查检查与安全相关的活动。
重点看管理员活动、异常登录、错误、访问记录和告警。
log review 可发现滥用、误配置和异常行为。
Logging systems should use NTP.
日志系统应使用 NTP。
没有统一时间,事件顺序和取证会混乱。
日志审查常与时间同步和完整性保护一起考。
Account management reviews ensure users retain only authorized permissions.
账号管理审查确保用户只保留授权权限。
检查孤儿账号、共享账号、权限蔓延、未及时撤销权限。
account management review 是发现越权的重要手段。
Management review and approval are process data.
管理复核和批准属于过程数据。
管理层要看测试输出、风险接受、例外和修复状态。
管理层负责风险决策,不只是技术团队修漏洞。
Backup verification data validates recovery capability.
备份验证数据验证恢复能力。
备份存在不代表可恢复,必须验证恢复能成功。
backup verification 关注恢复结果,不只是备份日志。
Collect technical and administrative security process data.
收集技术和管理类安全过程数据。
扫描、日志、工单、审批、复测报告都能作为证据。
process data 支撑持续改进和审计证据。
Test output should be analyzed and reported.
测试输出应被分析并报告。
发现、风险、建议、修复、复测和例外都要有记录。
没有记录就很难证明控制持续有效。
测试输出要变成管理层可理解的指标和行动计划。KPI 衡量过程绩效,KRI 提示风险变化,修复、例外处理和道德披露共同形成闭环。
Key performance indicators measure process performance.
关键绩效指标衡量过程绩效。
例如补丁按时完成率、备份成功率、培训完成率。
KPI 看是否按计划运行。
Key risk indicators show changes in risk.
关键风险指标显示风险变化。
例如高危漏洞数量上升、重复审计发现、异常登录趋势。
KRI 看风险是否上升。
Remediation addresses identified weaknesses.
修复处理已识别弱点。
要有负责人、计划、截止时间和复测结果。
remediation 是降低或消除缺陷。
Exception handling documents accepted deviations.
例外处理记录被接受的偏离。
不能修或暂缓修时,要说明原因、期限、风险和审批人。
exception 不是忽略风险,而是有记录的风险接受或延期。
Ethical disclosure responsibly reports findings.
道德披露以负责任方式报告发现。
敏感发现要保护细节,通知合适方并配合修复。
ethical disclosure 关注负责任沟通。
Training and awareness data supports personnel controls.
培训和意识数据支持人员控制。
完成率、测验成绩、钓鱼演练结果都可显示人员控制效果。
security awareness 不是口号,要有数据衡量。
DR and BC data supports continuity readiness.
DR 和 BC 数据支持连续性准备。
演练结果、RTO/RPO 达成率、恢复验证都可作为证据。
第 15 章会把测试数据连接到 DR/BC 能力验证。
Generate reports after analyzing test output.
分析测试输出后生成报告。
最终要让管理层看到风险、趋势、修复状态和决策点。
测试结束不是终点,持续改进才是闭环。