导图社区 CISSP-6-安全评估和测试
- 256
- 5
- 0
- 举报
CISSP-6-安全评估和测试
CISSP-信息系统安全专业认证之安全评估和测试思维导图，主要内容有基本概念、评估与测试策略、收集安全流程数据、内部和第三方审计、审计管理控制。
编辑于2021-11-10 12:04:23- 相似推荐
- 大纲
安全评估和测试
基本概念
安全评估和测试
安全评估和测试包含广泛的现行和基于时间点的测试方法用于确定脆弱性及其相关风险。
"Security Assessment and Testing" covers a broad range of ongoing and point-of-time based testing methods used to determine vulnerabilities and associated risk.
T&E的基本目标
T&E能衡量系统和能力开发进展
T&E的专长就是中对系统生命周期在开发过程提供系统强度和弱点的初期认知
为协助在开发、生产、运营和维护系统能力过程中的风险管理提供相应的知识。
能够在部署系统之前识别技术的、操作的和系统缺陷以便开发适当的及时的纠正行为。
T&E策略
测试和评估战略的内容是具有应用于获取/开发流程、所提供的能力要求以及技术驱动所需能力的功能。
倾向于
管理风险所需认知
验证模型和仿真的经验数据
技术性能和系统成熟度的测试
运维效能、适应性和生存能力的确定
目标
识别、管理和降低风险
评估与测试策略 Assessment and Test Strategies
A properly planned and executed test and evaluation strategy can provide 'information about risk and risk mitigation and empirical data to validate models and simulations, evaluate technical performance and system maturity, and determine whether systems are operationally effective, suitable, and survivable. 恰当计划和可执行的T&E策略可以提供有关模拟风险、风险降低以及验证模型的经验数据的信息，来评估技术性能和系统成熟度,并确定系统是否有效、适当的和可存活的运行
T&E策略
策略的作用
管理风险所需认知
验证模型和仿真的经验数据
技术性能和系统成熟度的测试
运维效能、适应性和生存能力的确定。
系统工程师和安全专家
与主办单位一块建立或评价用于支持程序获取/开发的T&E策略；
提供能深度管理风险的T&E的方法；
监控T&E流程以及可能需要的变更；
评价测试计划和程序是否适用于开发测试或运行测试，并提供建议；
进一步被希望理解获取/开发程序的背后的理由以用于建立和执行T&E策略；
期望理解T&E测试的具体活动，如互操作性测试；
企业需要建立工作小组
这个小组通常被称为T&E集成产品团队，由T&E专家、客户用户代表和其他利益相关者组成；
T&E策略是活动文档，该小组负责在需要时进行更新；
该小组需要确保T&E流程包含获取策略以及系统满足基于用于能力的操作要求；
日志评审
A log is a record of the events occurring within an organization's systems and networks 日志就是发生在组织系统和网络中的事件记录。
日志与计算机安全有关
如路由日志分析有利于识别安全事故、策略违背、欺诈行为和操作问题等。
日志作用
auditing and forensic analysis, supporting internal investigations, establishing baselines, and identifying operational trends and long-term problems.
执行审计和取证调查；
支持内部调查；
建立基线；
识别运行趋势以及发现长期问题；
挑战
需要平衡有限的日志管理资源和持续产生的日志数据
日志的生产和存储
不同的日志来源
不一致的日志内容、格式以及时间戳等
日志数据的大量生成
需要保护日志的完整性、机密性和可用性
确保安全、系统和网络管理员定期有效的分析日志数据。
日志管理的方针和程序
为建立和维护成功的日志管理活动，组织应开发执行日志管理的标准流程
定义日志需求和目标
开发清晰定义日志管理活动的强制要求和推荐要求
包括日志的生成、传递、存储、分析和废弃
集成和支持日志管理要求和推荐
管理层应提供必要的支持
日志需求和建议应与实施和维护日志所需的资源和细节分析技术一块生成
原始日志的保护
将网络流量日志的拷贝发送到中心设备
优化日志管理Prioritize Log Management
优化日志和需求，基于组织风险减少的感知以及执行日志管理所需资源和预期的时间。
建立日志管理的职责和角色
建立和维护日志管理架构
日志管理架构包含硬件、软件、网络和介质用于生成、传输、存储、分析和处置日志。
设计日志管理框架时应考虑管理框架现在和未来的需求以及整个组织的独立日志源。
集中式日志服务器和日志数据存储
需要处理的日志数据量，
网络带宽，
在线和离线数据存储
数据的安全要求
员工分析日志所需的时间和资源
为所有员工的日志管理职责提供适当支持
disseminating information, providing training, designating points of contact to answer questions, providing specific technical guidance, and making tools and documentation available.
系统的管理员应获得足够的支持；
包括信息传播、提供培训、提供问题解答的联系点、 提供具体的技术指南、提供相应的工具和文档等。
标准日志管理流程
配置日志源、执行日志分析、启动对识别的认知的响应和管理日志的长期存储。 configuring log sources, performing log analysis, initiating responses to identified events, and managing long-term storage. The distributed nature of logs, inconsistent log formats, and volume of logs all make the management of log generation and storage challenging.
日志管理员职责
监控日志状态
监控日志轮转和归档流程
检查日志系统补丁，获得、测试及部署补丁
确保日志来源系统保持时钟同步
当策略或技术变更时，必要的话，重新配置日志
记录和报告日志异常
确保日志整合存储，例如安全信息和事件管理系统（SIEM）
日志管理流程
配置日志源、执行日志分析、 启动对识别的认知的响应和管理日志的长期存储。
日志来源
基于网络和基于主机的软件
防病毒软件
IDS和IPS系统
远程访问软件
Web代理
漏洞管理软件
验证服务器
路由器
防火墙
网络访问控制 (NAC)/网络访问保护 (NAP) 服务器
操作系统事件和审计记录
基于应用
客户端请求和服务器响应
Client requests and server responses,which can be very helpful in reconstructing sequences of events and determining their apparent outcome.
账号信息
Account informationsuch as successful and failed authentication attempts, account changes (e.g., account creation and deletion, account privilege assignment), and use of privileges
使用信息
the number of transactions occurring in a certain period (e.g., minute, hour) and the size of transactions (e.g., email message size, file transfer size).
重要的操作活动
application startup and shutdown, application failures, and major application configuration changes
挑战
日志的分布属性、日志格式的不一致以及日志的容量都构成日志管理的挑战
必须保护日志的完整性、机密性和可用性
组织还需要保护其日志的可用性。
存档日志的机密性和完整性也需要保护。
系统和网络管理员
需要分析日志
无法有效进行日志分析
没有收到良好的培训
没有工具支撑
日志分析常常是响应型的 reactive
许多日志分析需要实时或近乎实时的
关键实践
在全组织适当的优化日志管理
Prioritize log management appropriately throughout the organization An organization should define its requirements and goals for performing logging and monitoring logs to include applicable laws, regulations, and existing organizational policies. The organization can then prioritize its goals based on balancing the organization’s reduction of risk with the time and resources needed to perform log management functions.
监理日志管理策略和程序
Establish policies and procedures for log management Policies and procedures are beneficial because they ensure a consistent approach throughout the organization as well as ensuring that laws and regulatory requirements are being met. Periodic audits are one way to confirm that logging standards and guidelines are being followed throughout the organization. Testing and validation can further ensure that the policies and procedures in the log management process are being performed properly.
建立和维护安全日志管理基础设施
Create and maintain a secure log management infrastructure It is very helpful for an organization to create components of a log management infrastructure and determine how these components interact. This aids in preserving the integrity of log data from accidental or intentional modification or deletion and also in maintaining the confidentiality of log data. It is also critical to create an infrastructure robust enough to handle not only expected volumes of log data but also peak volumes during extreme situations (e.g., widespread malware incident, penetration testing, vulnerability scans). Organizations should consider using SIEM systems for storage and analysis.
为所有员工的日志管理提供适当的支持
Provide adequate support for all staff with log management responsibilities While defining the log management scheme, organizations should ensure that they provide the necessary training to relevant staff regarding their log management responsibilities as well as skill instruction for the needed resources to support log management. Support also includes providing log management tools and tool documentation, providing technical guidance on log management activities, and disseminating information to log management staff.
合成交易 (Synthetic Transactions) Vs. 真实交易 （Real Transactions）
真实用户监控RUM
Web监控方法，旨在捕获或分析Web或应用上每个用户的每笔交易
又称为real-user measurement真实用户测量, real-user metrics真实用户指标, or end-user experience monitoring (EUM)最终用户体验监控
passive monitoring被动监控的方式
relying on Web-monitoring services that continuously observe a system in action, tracking availability, functionality, and responsiveness.
依赖于Web监控服务持续获得系统活动，追踪其可用性、功能和敏感度。
监控模式
自下而上 bottom-up forms
为重新重构用户体验而捕获服务端信息；
自上而下 top-down client-side RUM
客户端RUM，能直接看到用户如何与应用进行交互及其体验方式
关注站点速度和用户的满意度，提供关于优化应用组件和提升所有的性能的深入视角。
合成交易
synthetic monitoring has been done with lightweight, low-level agents, but increasingly, it’s necessary for these agents to run full Web browsers to process JavaScript, CSS, and AJAX calls that occur on pageload.
proactive monitoring 主动或预响应监控的方式
包含使用外部代理（agent）运行脚本交易的方式而不是Web应用。
这些脚本依照典型用户体验，如用户搜索、查看产品、登录和支付等方式来评估用户体验。
综合监控是轻量级和低水平的代理方式，但很Web浏览器有必要运行发生在页面上处理JavaScript, CSS, and AJAX调用。
并不追踪真实的用户会话
That means it’s more useful for alerting than often-noisy RUM data.
在一个已知的位置以固定的时间间隔执行一组已知的步骤，其性能是可预测的。 比RUM更适合评估站点可用性和网络问题。
Selenium
As applications get more complex, proxy metrics like load or server availability become less useful for measuring uptime. Running Selenium scripts against production is not a proxy measurement; it precisely measures uptime, providing full confidence that if the synthetic transactions are completing, the site is up and running.
http://docs.seleniumhq.org
客户端完全可控 full control over the client
unlike the sandboxed Java Script powering RUM, the detail that can be garnered is impressive.
不像沙盒JAVA脚本方式驱动的RUM，细节的获得可以更客观
微软系统中心操作管理软件
Web站点监控
Website monitoring uses synthetic transactions to perform HTTP requests to check availability and to measure performance of a webpage, website, or Web application.
数据库监控
Database monitoring using synthetic transactions monitors the availability of a database.
TCP 端口监控
A TCP port synthetic transaction measures the availability of your website, service, or application. You can specify the server and TCP port for Operations Manager to monitor.
提升价值
7x24 系统可用性监控 Monitor application availability 24 x 7.
了解远程站点是否可达
理解第三方服务对业务应用系统造成的性能影响
监控SaaS应用的性能和可用性
测试使用SOAP、REST或其他Web服务的 B2B Web站点
监控关键数据库的可用性
衡量服务级别协议（SLAs）
在低业务流量时段作为对真实用户监控的补偿
建立性能基线，进行性能趋势分析
代码评审和测试
导致漏洞的常见原因 vulnerabilities are caused
Bad programming patterns such as missing checks of user-influenced data that can cause, e.g., in SQL injections vulnerabilities, Misconfiguration of security infrastructures, e.g., too permissible access control or weak cryptographic configurations, Functional bugs in security infrastructures, e.g., access control enforcement infrastructures that inherently do not restrict system access, Logical flaws in the implemented processes, e.g., resulting in an application allowing customers to order goods without paying.
不恰当的编程模式，如缺少检查影响用户的数据，SQL注入（输入验证）
安全基础设施的误配：访问控制权限过大或脆弱的加密配置；
安全基础设施的功能错误：访问控制强制设施本身不限制系统的访问；
实施流程的逻辑错误：比如用户下订单而不用支付
常见软件漏洞 Common Software Vulnerabilities
Top 25
■ 不安全的组件交互（Insecure Interaction between Components）
These weaknesses are related to insecure ways in which data is sent and received between separate components, modules, programs, processes, threads, or systems.
■ 有风险的资源管理（Risky Resource Management ）
The weaknesses in this category are related to ways in which software does not properly manage the creation, usage, transfer, or destruction of important system resources.
■ 漏洞百出的防御（Porous Defenses）
The weaknesses in this category are related to defensive techniques that are often misused, abused, or just plain ignored.
测试技术 testing techniques
白盒（结构性测试/开箱测试） vs. 黑盒测试（功能性测试/闭箱测试）
black-box-testing, the tested system is used as a black box, i.e., no internal details of the system implementation are used. In contrast, white-box-testing takes the internal system details (e.g., the source code) into account.
动态测试 VS. 静态测试 Dynamic Testing vs. Static Testing
Traditionally, testing is understood as a dynamic testing, i.e., the system under test is executed and its behavior is observed. In contrast, static testing techniques analyze a system without executing the system under test.
手工 vs. 自动化 Manual Testing vs. Automated Testing
In manual testing, the test scenario is guided by a human, while in automated testing the test scenario is executed by a specialized application.
安全测试考虑 security testing considering
Different security testing methods behave differently when applied to different application types.
攻击面
Different security testing methods find different vulnerability types.
应用类型
Different security testing methods behave differently when applied to different application types.
质量
Security testing techniques and tools differ in usability (e.g., fix recommendations) and quality (e.g., false positives rate).
支持技术
Security testing tools usually only support a limited number of technologies (e.g., programming languages), and if a tool supports multiple technologies, it does not necessarily support all of them equally well.
性能和资源利用率
Different tools and methods require different computing power or different manual efforts.
规划和设计阶段 During Planning and Design
Strictly speaking, a security review of the architecture and threat modeling are not security testing methods. Still, they are an important prerequisite for subsequent security testing efforts, and the security practitioner should be aware of the options available to them. 严格意义上说，架构和威胁模型的安全评审不是安全测试的方法。
架构安全评审
manual review of the product architecture to ensure that it fulfils the necessary security requirements. 通过产品架构的人工评审方式来确认其满足必要的安全条件
先决条件：架构模型
优点：验证架构偏离安全标准
威胁建模 Threat Modeling -
structured manual analysis of an application specific business case or usage scenario. This analysis is guided by a set of precompiled security threats. 应用的具体业务用例或使用场景的结构化手工分析，通过预编译的安全威胁进行。
先决条件：业务用例或使用场景
识别威胁、及其影响以及具体到软件产品开发过程中的潜在控制措施。
a Benefits: Identification of threats, their impact, and potential countermeasures that are specific to the development of the software product.
STRIDE 模型
应用开发阶段 During Application Development
Static Source Code Analysis (SAST) and Manual Code Review（静态代码分析和手动代码评审）
Analysis of the application source code for finding vulnerabilities without actually executing the application.
为寻找弱点而不执行应用而分析应用源代码。
先决条件：应用源代码
优点：检测不安全的编程、过时的代码库以及错误配置
Static Binary Code Analysis and Manual Binary Review（静态二进制代码分析和手工二进制审查）
Analysis of the compiled application (binary) for finding vulnerabilities without actually executing the application. In general, this is similar to the source code analysis but is not as precise and fix recommendations typically cannot be provided.
对已编译的应用进行分析来发现弱点，并不执行应用。
不精确且不提供修复建议。
在测试环境中可执行 Executable in a Test Environment
手工或自动化渗透测试
像攻击者一样发送数据并发现其行为。
优点：在部署的应用上识别大量的弱点；
自动化漏洞扫描
Test an application for the use of system components or configurations that are known to be insecure. For this, pre-defined attack patterns are executed, and system fingerprints are analyzed.
测试使用已知不安全的系统组件或配置的应用。
设定预攻击模式，分析系统指纹。
优点：检测已知漏洞
Fuzz Testing Tools 模糊测试工具
Send random data, usually in larger chunks than expected by the application, to the input channels of an application to provoke a crashing of the application.
优点：检测至关重要的应用程序的崩溃（例如，由缓冲区溢出引起的）。
发送随机数据（常常远比应用所期望的更大块） 到应用输入渠道来引起应用的崩溃。
系统运行和维护中的测试
软件测试特点
推荐使用被动安全测试技术监测系统行为和分析系统日志
软件维护过程中，补丁的测试非常重要
补丁需要进行彻底的安全测试
软件测试有其限制，不可能100%测试完成
测试了所有程序功能和所有程序代码并不意味着程序就是100%正确的！
测试计划和测试用例应尽可能早的在软件开发阶段进行开发
代码级别的测试 Code-based testing
known as structural testing or “white-box” testing. It identifies test cases based on knowledge obtained from the source code, detailed design specification, and other development documents.
软件的安全测试一般起始于单元级别的测试和结束于系统级别测试
结构化测试 (“白盒”测试) 开箱测试
结构化测试主要是放在模块级别的测试；
结构化测试级别可以用被测试的软件结构的百分比来作为指标来衡量；
测试用例基于从源代码、细节设计规格说明和其他开发文档中获得的知识；
Common structural coverage 测试覆盖率（适用于白盒）
Statement Coverage 语句覆盖率
This criteria requires sufficient test cases for each program statement to be executed at least once; however, its achievement is insufficient to provide confidence in a software product’s behavior
Decision (Branch) Coverage 判断覆盖率
This criteria requires sufficient test cases for each program decision or branch to be executed so that each possible outcome occurs at least once. It is considered to be a minimum level of coverage for most software products, but decision coverage alone is insufficient for high integrity applications。分支覆盖率。
Condition Coverage 条件覆盖率，
This criteria requires sufficient test cases for each condition in a program decision to take on all possible outcomes at least once. It differs from branch coverage only when multiple conditions must be evaluated to reach a decision.
Multi-Condition Coverage 多条件覆盖率
This criteria requires sufficient test cases to exercise all possible combinations of conditions in a program decision.
Loop Coverage 循环覆盖率
This criteria requires sufficient test cases for all program loops to be executed for zero, one, two, and many iterations covering initialization, typical running, and termination (boundary) conditions.
Path Coverage 路径覆盖率
This criteria requires sufficient test cases for each feasible path, basis path, etc., from start to exit of a defined program segment, to be executed at least once. Because of the very large number of possible paths through a software program, path coverage is generally not achievable. The amount of path coverage is normally established based on the risk or criticality of the-software under test.
Data Flow Coverage 数据流覆盖率
This criteria requires sufficient test cases for each feasible data flow to be executed at least once. A number of data flow testing strategies are available.
功能性测试或“黑盒”测试/闭箱测试 （functional testing or blackbox testing）
It identifies test cases based on the definition of what the software product (whether it be a unit (module) or a complete program) is intended to do. 测试用例基于软件产品具体要做什么来定义的
测试用例基于软件产品具体要做什么来定义的；
测试用例的主要挑战是预期用途和程序功能以及程序的内外部接口；
功能性测试应用于任意级别的软件测试，从单元测试到系统级别的测试
软件功能测试 functional software testing
Definition-based or specification-based testing is also known as functional testing or “blackbox” testing. It identifies test cases based on the definition of what the software product (whether it be a unit (module) or a complete program) is intended to do. Functional and structural software test case identification techniques provide specific inputs for testing rather than random test inputs.
Normal Case 普通用例
Testing with usual inputs is necessary. However, testing a software product only with expected, valid inputs does not thoroughly test that software product. By itself, normal case testing cannot provide sufficient confidence in the dependability of the software product
Output Forcing 输出要求，
Choosing test inputs to ensure that selected (or all) software outputs are generated by testing.
Robustness 鲁棒性
Software testing should demonstrate that a software product behaves correctly when given unexpected, invalid inputs. Methods for identifying a sufficient set of such test cases include Equivalence Class Partitioning, Boundary Value Analysis, and Special Case Identification (Error Guessing). While important and necessary, these techniques do not ensure that all of the most appropriate challenges to a software product have been identified for testing.
Combinations of Inputs 输入组合
The functional testing methods identified above all emphasize individual or single test inputs. Most software products operate with multiple inputs under their conditions of use. Thorough software product testing should consider the combinations of inputs a software unit or system may encounter during operation. Error guessing can be extended to identify combinations of inputs, but it is an ad hoc technique. Cause-effect graphing is one functional software testing technique that systematically identifies combinations of inputs to a software product for inclusion in test cases.
weakness 弱点
很难将结构化和功能化测试的完成标准与软件产品的可靠性链接起来；
统计测试方法 statistical testing
Statistical testing uses randomly generated test data from defined distributions based on an operational profile (e.g., expected use, hazardous use, or malicious use of the software product). Large amounts of test data are generated and can be targeted to cover particular areas or concerns, providing an increased possibility of identifying individual and multiple rare operating conditions that were not anticipated by either the software product’s designers or its testers.
提供高结构化覆盖率
从基于运行环境（软件产品的预期使用、危险使用或恶意使用）定义的分布来生成随机数据；
生成大量测试数据并用于覆盖到特别领域或所关注的地方，提供增加识别单个和极其罕见的运行状况的可能性，这些运行状况没有被设计者和测试人员所预知；
软件变更测试
1) debugging that finds an error and it is corrected, 2) new or changed requirements (“requirements creep”)； 3) modified designs as more effective or efficient implementations are found.
原因
调试发现的问题并进行纠正；
新的或变化的需求；
发现设计的修改能更高效或有效实施；
目的
变更已正确实施
未对其他部分造成不利影响
回归分析和测试
Regression analysis is the determination of the impact of a change based on review of the relevant documentation (e.g., software requirements specification, software design specification, source code, test plans, test cases, test scripts, etc.) in order to identify the necessary regression tests to be run. Regression testing is the rerunning of test cases that a program has previously executed correctly and comparing the current result to the previous result in order to detect unintended effects of a software change. Regression analysis and testing回归分析和回归测试能提供更好的保障。
回归分析：确定变更的影响，基于相关文档 （软件规格说明、设计规格、源代码等）的评审， 也是为识别运用必要的回归测试；
回归测试：运用之前程序执行正确的测试用例， 比对现有结果和以前的结果发现软件变化的非预期结果。
严格和完整的测试 （V字模型）
Test procedures, test data, and test results should be documented in a manner permitting objective pass/fail decisions to be reach.
Unit (module or component) level testing 单元测试
focuses on the early examination of sub-program functionality and ensures that functionality not visible at the system level 关注子程序功能的早期检，该功能不在系统级别的检查测试中显现；
Integration level testing 集成测试（测模块之间的接口）
focuses on the transfer of data and control across a program’s internal and external interfaces.关注与数据传输和控制跨程序内外部接口
自上而下（Top-Down）
自下而上 (Bottom-Up)
三明治方法
System level testing 系统测试
demonstrates that all specified functionality exists and that the software product is trustworthy.表明所有规定功能存在以及软件产品是可信的
安全和隐私（例如，加密功能、安全日志报告）
性能问题（例如，响应时间、可靠性测量）
压力情况下的反应（例如，最大载荷下的表现）
内外部安全特征的操作
恢复步骤的有效性
可用性 Usability;
不同配置下的表现
文档的准确性
与其他软件的兼容性
验收测试
UAT（用户验收测试）
QAT（质量保证测试）
测试注意事项
系统测试将呈现在特定环境中软件产品的行为；
测试程序、测试数据和测试结果应以获得允许通过/失败决策的方式记录；
企业的软件产品是复杂的，软件产品的测试需要保持一致性、完整性和有效性；
软件维护任务和硬件维护不一样，硬件有预防性维护措施而软件没有；
需要有效验证变更
其他的维护任务
Software Validation Plan Revision软件验证计划修订，
For software that was previously validated, the existing software validation plan should be revised to support the validation of the revised software. If no previous software validation plan exists, it should be established to support the validation of the revised software.
Anomaly Evaluation异常验证，
Software organizations frequently maintain documentation, such as software problem reports that describe software anomalies discovered and the specific corrective action taken to fix each anomaly.
Problem Identification and Resolution Tracking 问题识别和解决跟踪，
All problems discovered during maintenance of the software should be documented.
Proposed Change Assessment 请求变更评估
All proposed modifications, enhancements, or additions should be assessed to determine the effect each change would have on the system. This information should determine the extent to which verification and validation tasks need to be iterated.
Task Iteration 任务迭代，
Documentation Updating 文档更新
Documentation should be carefully reviewed to determine which documents have been impacted by a change.
用例和误用例
用例 Use cases
abstract episodes of interaction between a system and its environment.系统和环境间交互的抽象方法。 A scenario is a description of a specific interaction between particular individuals. A use case abstracts scenarios that are instances of the same kind of interaction between a system and its actors.
站在正常用户使用系统的角度的测试用例
误用例 misuse case：
来自对系统怀有恶意的人员视角的用例。
正向测试方法 Positive testing
确定应用按照所期待的方式进行工作，如果在正向测试中发现错误则失败
负向测试 Negative testing
确保应用可以妥善处理无效输入或非预期用户行为。
接口测试（interface test）
目的
主要检查应用或系统开发的不同组件彼此是否同步；
从技术层面接口测试主要用于确定不同功能诸如 数据在系统的不同元素中是否按照设计进行传输。
用于确保软件的质量
渗透测试
应所有者的要求模拟攻击一个网络及其系统的过程
渗透测试类型屈居于组织机构、它的安全目标和管理层的目标
渗透测试报告应该提交给管理层
应签署授权测试范围的授权书（需要得到管理层的书面的授权）
步骤
发现，收集目标的相关信息(discovery)
发现操作系统的版本 CentOS 5.1
dig
DNS footprinting 工具，发现阶段收集信息
枚举，执行端口扫描和资源标识方法
nbtstat 属于 enumeration, 是在枚举阶段，不是在发现阶段
脆弱性勘探，在确定的系统和资源中标识脆弱性
脆弱性测试分类
人为脆弱性
物理脆弱性
系统和网络脆弱性
利用，尝试利用脆弱性进行未授权访问
向管理层报告，想管理层提交报告和安全建议
分类
黑盒测试，零了解，渗透团队在不了了解测试目标的情况下测试
灰盒测试，在了解一些与测试目标相关的信息上测试
白盒测试，了解目标的本质的基础上测试
渗透性测试团队分类
0知识
对目标一无所知
部分知识
知道目标的部分知识
全部知识
完全了解目标的情况
举例 ：战争拨号
从一系列电话号码中拨号寻找可用的调制解调器
有些组织仍然使用调制解调器用于通信备用
战争拨号是一种旨在避开防火墙和入侵检测系统(IDS)侵入组织网络的形式
战争拨号攻击包括通过拨入访问试图获得组织的内部计算和网络资源访问权， 这给黑客入侵带来了便利性。
自我测试
管理员通过战争拨号方法测试组织内 未经授权安装的调制解调器， 对组织中随意安装者进行再教育。
其他脆弱性类型
Kernel flaws 内核漏洞
内核层存在漏洞
对策：确保安全补丁到操作系统足够的测试后，及时部署在环境中保持尽可能小的漏洞窗口。
Buffer overflows缓冲区溢出
对策：良好的编程实践和开发教育，自动扫描器的源代码， 增强编程库，采用强语言类型不允许缓冲区溢出
Symbolic links 符号链接
黑客重新定向符号链接，从而达到非授权访问的目的。
对策：在编写程序（尤其是脚本）时，无法规避文件的完整路径
File descriptor attacks 文件描述攻击
文件描述符是许多操作系统用来表示进程中打开文件的数字.某些文件描述符数是通用的，对所有程序都有相同的含义.。
如果程序不安全地使用文件描述符，可能会导致攻击者利用程序特权将意外的输入提供给程序，或导致输出到意外的地方
对策：良好的编程实践和开发教育，自动化源代码扫描仪和应用程序安全测试都是减少这种类型的漏洞的方法。
Race conditions 竟态条件 （多进程和多线程环境下）
在执行程序前未消除环境的脆弱性因素
会导致攻击者读取或写入意外数据或执行未经授权的命令
对策：良好的编程实践和开发教育，自动化源代码扫描仪和应用程序安全测试
父进程创建子进程要关注竞态条件和最小授权
File and directory permissions 文件和目录权限
不适当的文件或目录权限
对策：文件完整性检查，还应检查预期的文件和目录的权限
收集安全流程数据 Collect Security Process Data
Information security continuous monitoring（ISCM）信息安全持续监控
maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions.
ISCM
用于定义现行信息安全、漏洞和危险的意识用于支持组织信息安全风险决策；
用于支持跨组织的信息安全监控的任何努力和过程必须开始与高层领导定义的复杂ISCM策略；
ISCM策略
是建立在清晰理解组织风险容忍度并帮助企业设置优先级和管理整个组织的风险一致性；
包含度量指标来提供在所有组织层面的安全状态的真实含义；
确保所有安全控制的持续有效;
验证由组织使命/业务职能、国家法律法规、指南、指南标准所驱动的信息安全要求的符合性;
所有组织的IT资产都被告知并协助维护资产安全的可见性;
确保组织系统和环境变更的知识和控制；
保持威胁和脆弱性的意识.
NIST SP 800-137
联邦信息系统和组织的信息安全持续监控（ISCM）
特点
ISCM方案的建立收集依据预设测量指标的数据，部分通过已实施的安全控制来利用信息变更更加容易。
组织官方定期收集和分析数据并在需要时为企业的每个领域管理风险； 该流程包含整个组织，从高层领导提供治理和战略视角到个人开发、实施和运行单个系统来支持组织的核心使命和业务流程； 组织的安全架构、运维安全能力和监控流程都将随时间不断改进和成熟，以更好响应动态威胁和脆弱性场景；
组织范围的风险监控不能有效的依靠单独的手工流程或单独的自动化流程来获得：
当使用手工流程时，该流程以可重复和可验证的来启动一致性实施； 自动化流程包括使用自动化支持工具，能使得持续性监控流程更具有成本性、一致性和效率。
开发ISCM策略流程
基于风险容忍度定义ISCM策略以维护资产的可见性、漏洞的意识、威胁信息的更新以及使命/业务影响；
建立ISCM方案确定测量指标、状态监控频率、控制评估频率并建立ISCM技术架构；
实施ISCM方案和收集用于测量、评估和报告所需的安全相关信息。尽可能的自动收集、分析和报告；
分析所有收集的数据并报告发现，确定恰当的响应。有必要收集其他信息来澄清或补充现有监控数据；
通过技术、管理和操作的活动来响应发现，这些活动包括削减活动或接受，转移/共享，或者避免/拒绝等。
评审和更新ISCM方案，调整ISCMC策略和成熟的测量能力来增加资产的可见性和脆弱性意识，更多的启用组织信息安全架构并以数据驱动的控制，增加组织的弹性。
测量指标 Metrics
which include all the security-related information from assessments and monitoring produced by automated tools and manual procedures, are organized into meaningful information to support decision-making and reporting requirements A robust ISCM program thus enables organizations to move from compliance-driven risk management to data-driven risk management providing organizations with information necessary to support risk response decisions, security status information, and ongoing insight into security control effectiveness.
测量指标定义及内容
测量指标包含所有来自评估和监控并由自动化工具以及手工程序所产生的安全相关信息，并组织成有意义的信息来支持决策和报告要求。
测量指标应由维持或改进安全态势的具体目标所驱动。
测量指标开发系统级别的数据使得使命/业务背景或组织风险管理变得有意义；
测量指标从不同时间获得的安全相关信息并带有不同级别的延迟。
例子examples
■ The number and severity of vulnerabilities revealed and remediated ■ Number of unauthorized access attempts ■ Configuration baseline information ■ Contingency plan testing dates and results ■ The number of employees who are current on awareness training requirements ■ Risk tolerance thresholds for organizations ■ The risk score associated with a given
测量指标建立原则 NIST SP 800-137
NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations,
Security Control Volatility安全控制波动
Volatile security controls are assessed more frequently, whether the objective is establishing security control effectiveness or supporting calculation of a metric
System Categorizations/Impact Levels系统分类/影响的水平
In general, security controls implemented on systems that are categorized as high-impact are monitored more frequently than controls implemented on moderate-impact systems, which are in turn monitored more frequently than controls implemented on low-impact systems
Security Controls or Specific Assessment Objects Providing Critical Functions安全控制或特定评估对象所提供的关键功能
Security controls or assessment objects that provide critical security functions (e.g., log management server, firewalls) are candidates for more frequent monitoring. Additionally, individual assessment objects that support critical security functions are deemed critical to the system (in accordance with the Business Impact Analysis).7
Security Controls with Identified Weaknesses已识别弱点的安全控制
Existing risks documented in security assessment reports (SARs) are considered for more frequent monitoring to ensure that risks stay within tolerance.
Organizational Risk Tolerance组织风险容忍度，
Organizations with a low tolerance for risk (e.g., organizations that process, store, or transmit large amounts of proprietary and/or personally identifiable information (PII), organizations with numerous high-impact systems, organizations facing specific persistent threats) monitor more frequently than organizations with a higher tolerance for risk (e.g., organizations with primarily low- and moderate-impact systems that process, store, or transmit very little PII and/or proprietary information).
Threat Information威胁信息
Organizations consider current credible threat information, including known exploits and attack patterns.
Vulnerability Information
Organizations consider current vulnerability information with respect to information technology products when establishing monitoring frequencies.
Risk Assessment Results风险评估结果
Results from organizational and/or system specific assessments of risk (either formal or informal) are examined and taken into consideration when establishing monitoring frequencies
Reporting Requirements通报要求
Reporting requirements do not drive the ISCM strategy but may play a role in the frequency of monitoring.
变更的因素
■ Changes to core missions or business processes; ■ Significant changes in the enterprise architecture (including addition or removal of systems); ■ Changes in organizational risk tolerance; ■ Changes in threat information; ■ Changes in vulnerability information; ■ Changes within information systems (including changes in categorization/ impact level); ■ Trend analyses of status reporting output; ■ New laws or regulations; and ■ Changes to reporting requirements.
作为组织风险管理框架 Risk Management Framework (RMF) 的关键步骤
Effectiveness is further enhanced when the output is formatted to provide information that is specific, measurable, actionable, relevant, and timely.
提供组织官方按需访问安全相关信息的能力， 进行及时风险管理决策包括授权决策。
内部和第三方审计（Internal and Third-Party Audits）
审计需求
法律法规需求
如美国联邦信息安全法案（FISMA Federal Information Security Management Act）要求联邦机构每年至少对组织的信息安全体系进行一次自我审计和独立的第三方审计；
信息安全专家需要理解法律标准中所概述的要求以提供保护，但极少做到完全的保护或信息系统的风险管理；
信息安全专家必须确保恰当的范围和裁剪为目标系统在正确的级别上获得适当数量的控制
合规
如美国联邦信息安全法案（FISMA Federal Information Security Management Act）要求联邦机构每年至少对组织的信息安全体系进行一次自我审计和独立的第三方审计； 信息安全专家需要理解法律标准中所概述的要求以提供保护，但极少做到完全的保护或信息系统的风险管理； 信息安全专家必须确保恰当的范围和裁剪为目标系统在正确的级别上获得适当数量的控制
业务驱动
组织为了集中核心竞争力、减少开支和更快速的部署应用新的应用功能， 不断将系统、业务流程和数据处理外包给服务提供商；
组织常更新外包服务商的监控流程以及管理与外包的风险；
历史上，许多组织常借鉴Statement on Auditing Standards (SAS) 70 reports 审计准则说明以获得对外包活动的安慰，然而SAS 70关注财务报告内部控制(ICOFR)，而不关注系统可用性和安全。
SAS70报告已在2011退休，取而代之的是SOC（Service Organization Control)报告；
内部审计（第一方审计）
组织拥有自己的审计团队，以实现持续改进您的组织的安全态势。
优点
他们熟悉组织内部的工作流程。
工作效率高
能够很准确得找出最有问题的点
可以使审计工作更灵活，管理层可不断变换审计需求让审计团队对应调整审计方案
缺点
他们接触到的信息系统相对有限
存在利益冲突的可能性，妨碍客观性。
第三方审计
优点
审计过很多种不同的信息系统，经验丰富
他们不知道目标组织内部的动态和政治。将会保持客观中立
缺点
成本高
你仍然需要处理增加的资源来组织他们并监督他们的工作即使签了保密协议。
缺乏对组织内部运作的了解。
Statement on Auditing Standards (SAS) 70
SAS70=StatementonAuditingStandard70由美国注册会计师协会创建。SAS70是由美国会计师协会（AICPA）制定，针对金融服务机构向客户提供服务的内部控制、安全保障、稽核监督措施的审计标准。
specifically on risks related to internal control over financial reporting (ICOFR) 财务报告内部控制
过去，多数组织使用外包服务要求SAS70报告， 但是仅从财务角度出发，许多用户开始关注安全、可用性而后隐私；
SOC 报告
In some cases, a SOC report may cover a shorter period of time, such as six months, if the system/service has not been in operation for a full year or if annual reporting is insufficient to meet user needs. A SOC report may also cover only the design of controls at a specified point in time for a new system/service or for the initial examination (audit) of a system/service. 
作为SAS70报告的替代，使用SOC报告；
SOC 1报告
与SOC 1/SOC 2报告相反的地方是，SOC1 报告需要服务提供商描述他的系统并定义控制目标和控制，这些与财务报告内部控制有关；
SOC1报告通常不覆盖那些与用户ICOFR报告无关的服务和控制。
SOC1报告在2011年开始被许多服务商用于核心财务处理服务；
SOC 2 / SOC 3 报告
Period of time reports covering design and operating effectiveness 一段时间内包含设计和运维有效性的报告
原则和准则具体定义安全性、可用性、机密性、处理完整性和隐私；
提供超越财务报告内部控制（ICOFR）；
可以基于服务提供商及其用户的需求，采用模块化的方式便于 SOC2/SOC3报告能够覆盖一个或多个原则；
IT服务提供商没有影响或存在间接影响到用户的财务系统，则使用SOC2报告；
SOC3报告一般用于向大范围用户通报其保障级别而不需要披露细节控制和测试结果；
审计管理控制
账号管理
添加账号
1.新员工应阅读并签署可接受使用政策 (AUP)
2.通过审计员工账号，确认员工遵守AUP的情况。
3.从人力资源部门调取新员工清单与IT部门在系统中开设员工账号进行对照，以确保两个部门沟通的有效性。
4.策略还应明确账号过期时间、密码策略、用户可访问信息范围。
修改账号
使用特权账号的问题
1.通常情况每个计算机用户账号都具有本地管理员权限，服务器管理维护人员具有域管理员权限，均存在较大风险。
2.账号的增加、删除或修改，均应严格控制并文档化。
3.实施管理员账号权限分级管理。
4.仅在必须时才使用特权账号，日常维护工作使用受限账号。
暂停账号
1.要暂停不在使用的账号。
2.从人力部获取短期、长期离岗离职人员清单， 与IT系统账号情况进行对比，删除长期离岗离职人员账号， 并暂停短期离岗离职账号使用权限。
备份验证
数据类型
用户文件
存在多个版本和备份地点文件不一致的情况，以及有悖数据保留原则的情况
数据库
确保当需要时数据库备份能够恢复到生产环境中。
邮件数据
考虑到服务器存储空间有限，中大型邮件不备份；邮件服务器应与电子取证手段相结合
验证方法
测试数据备份情况
分析组织可能面临的威胁各种场景
开发一个计划来测试每个场景中所有关键任务数据备份
利用自动化，最大限度地减少审计人员的工作量，确保测试定期发生
尽量减少数据备份测试计划对业务流程的影响，以便它可以定期执行
确保覆盖范围，使每一个系统进行测试，但不一定在同一个测试中。
记录结果，这样你就知道什么是工作，什么是需要工作的
修正或完善你记录的任何问题。
灾难恢复和业务连续性
测试和修改业务连续性计划
测试类型
Checklist Test 检查清单测试
BCP拷贝分发给每个关键业务部门的经理
请求他们评审适合他们部门的计划部分
Structured Walk-Through Test 结构化穿行测试
作为计划初始测试的工具，但不是最好的测试方法
目标
确保来自所有领域的关键人员熟悉BCP
确保计划反应组织从灾难恢复过来的能力
特点
■ Attendance of business unit management representatives and employees who play a critical role in the BCP process; ■ Discussion about each person’s responsibilities as defined by the BCP; ■ Individual and team training, which includes a walk-through of the step-bystep procedures outlined in the BCP; and ■ Clarification and highlighting of critical plan elements, as well as problems noted during testing.
会议室联系，低成本
Simulation Test 模拟测试
比桌面演练包含的内容更多
参加者选择具体的事件场景应用在BCP中
Parallel Test 并行测试
包含真实人员移动到别的站点力图按照DRP规定建立通信和实施真实的恢复流程
主要是确定如果人员应用DRP规定中的程序，关键系统是否能够在备用处理站点恢复
Full-Interruption Test 全中断测试
风险最高的测试
尽可能模拟真实的场景
不能影响业务
安全培训和安全意识培训
安全培训与安全意识宣灌的区别
安全培训是指教授一种技能或一套技能，使人们更好地执行特定功能的过程.
安全意识培训是把人们暴露在安全问题的过程中，以便他们能够认识到他们，并更好地应对他们。
社会工程学
在信息安全的背景下，是操纵个人的过程，使他们执行违反安全协议的行为。
Online Safety 在线安全
网络钓鱼是通过数字通信进行的社会工程.。
一个驱动下载是一个自动攻击，只需访问恶意网站触发。
数据保护
文化
关键绩效和风险指标
关键绩效指标（KPI）
关键绩效指标（KPI）测量组织在一个给定的时间执行一个给定的任务的效率
关键风险指标（KRI）
测量执行给定动作或动作集合所固有的风险.。
报告
一个有效的报告，必须写在一个特定的观众心目中。
技术报告
一个技术报告应该比一个自动扫描工具或一个普通清单的输出要多。
好的审计技术报告包含的要素
威胁
脆弱性
脆弱性被利用的概率
影响程度
改进建议
行政摘要
呈给高级领导者的报告应简洁易懂，主要包括关键的调查结果和建议
最好将风险量化描述，量化风险的一种方法是用货币术语来表达风险.
常见风险计量方法
成本计算法
最通用的计算方法
所得计算法
一般公式为价值等于预期（或潜在）收入除以资本化率。
市场计算法
市场的方法是基于确定有多少其他公司支付类似的资产在市场上。
管理评审
管理评审是高级组织领导者决定管理体系是否有效地实现其目标的正式会议。
管理评审前
管理评审应周期性开展，否则将使检查风险变主动为被动。
会议的频率也应与执行前一次评审的决定所需时长同步。
评审输入
一个关键的输入是相关审计的结果，包括外部和内部。
除了使审计报告可供审查，也有必要产生执行摘要，描述的主要发现，对组织的影响，以及建议的变化（如果有的话）。记住用商务语言写这些摘要。
另一个输入是上次评审发现问题及整改情况的清单
客户评价
最后输入是基于所有其他输入的改进建议。
管理行动
高级领导考虑所有的输入信息，通常问一些有针对性的问题，然后决定批准，拒绝或推迟的建议。
高级管理层将决定是接受它的全部的建议，或接收意见但做细小改变，或拒绝意见，或要求ISMS团队重新收集更多支持数据或重新设计建议选项。