DEPARTMENT OF HEALTH & HUMAN SERVICES
Centers for Medicare & Medicaid Services
7500 Security Boulevard, Mail Stop N2-14-26
Baltimore, Maryland 21244-1850
CENTERS FOR MEDICARE & MEDICAID SERVICES (CMS)
Office of Information Services (OIS)
Security and Standards Group (SSG)
7500 Security Blvd
Baltimore, MD 21244-1850
CMS Information Security Risk Assessment (RA) Methodology
Version # 1.1
September 12, 2002
Table of Contents Overview (1)
Purpose (2)
Risk Assessment Process (2)
1 System Documentation Phase (2)
1.1 Document System Identification (3)
1.2 Document System Purpose and Description (4)
1.3 Document System Security Level (4)
2 Risk Determination Phase (5)
2.1 Identify System Environment Threats (5)
2.2 Identify System Vulnerabilities (6)
2.3 Describe Risk (6)
2.4 Identify Existing Controls (6)
2.5 Determine the Likelihood of Occurrence (6)
2.6 Determine the Severity of Impact (7)
2.7 Determine the Risk Level (8)
3 Safeguard Determination Phase (9)
3.1 Identify Safeguards (10)
3.2 Determine Residual Likelihood of Occurrence (11)
3.3 Determine Residual Severity of Impact (11)
3.4 Determine Residual Risk Level (11)
Appendix A: Risk Assessment Process Flow (12)
Appendix B: Security in the System Development Life Cycle (13)
Appendix C: References (15)
Appendix D: Information Security Risk Assessment Template (16)
Overview
The Centers for Medicare & Medicaid Services (CMS) Information Security Risk Assessment (RA) Methodology presents a systematic approach for the RA process of information computer systems within the CMS environment. This methodology describes the steps to produce an Information Security RA Report for systems that are part of a General Support System (GSS), Major Application (MA) or that are an “Other” System. The Information Security RA Report includes a system overview to provide a basic understanding of the system and its interconnections, and describe the overall system security level. Additionally, the RA Report contains a list of system threats and vulnerabilities; an evaluation of current security controls to safeguard against the identified threat/vulnerability pairs and the resulting risks levels; and the recommended safeguards to reduce the system’s risk exposure with a revised or residual risk level once the recommended safeguards are implemented.
The RA process described in this methodology is an integral part of risk management. Risk Management also includes prioritization of risks, categorization of recommended safeguards, their feasibility of implementation, and other risk mitigation processes and solutions within the management, operational and technical environment. These risk management activities are beyond the scope of this methodology and are performed as part of the system’s certification and accreditation process as it affects the organization’s security posture and management assesses an acceptable level of risk for continuation of operations.
The RA process is presented as the following three phases:
? System Documentation Phase
? Risk Determination Phase
? Safeguard Determination Phase
The following appendices are included in the methodology to assist the system owner or RA author in the risk assessment analysis and provide further clarification and references to complete the Information Security RA Report:
Appendix A, Risk Assessment Process Flow – Depicts the RA process flow detailed in this methodology for ease of reference.
Appendix B, Security in the System Development Life Cycle – Describes system security deliverables and resources as they relate to the System Development Life Cycle and the CMS Roadmap.
Appendix C, References – Provides links to web sites for documents referred to or used as background in this Information Security RA Methodology.
Appendix D, CMS Information Security RA Template – Facilitates the RA report documentation, and provides a common and consistent format for the Information Security RA report.
Refer to the CMS Information Security Terms and Definitions document for information security terms used throughout this methodology.
Purpose
The CMS Information Security RA Methodology has been developed as a tool to guide system owners and RA authors in evaluating and documenting the system’s management, operational and technical security environment. This tool describes the steps to produce the CMS Information Security Risk Assessment Report, which is incorporated into the System Security Plan (SSP) and is reviewed during the CMS Information Security Certification and Accreditation process. The system RA process supports risk management in the evaluation of the system(s) risk impact upon CMS’ enterprise security model.
CMS requires each system to have an Information Security RA in each of the following instances: new system, operational legacy system, major system modification(s), increase security risks/exposure, increase of overall system security level, serious security violation(s) as described the CMS Computer Security Incident Handling Procedures document, and security evaluations and/or audits. For a new system or a system undergoing a major modification, an RA will be developed as part of the System Development Life Cycle (SDLC) phases. The RA steps are illustrated in Appendix B of this methodology and the RA Template is provided in Appendix D.
Risk Assessment Process
To perform the information security risk assessment, the system owner must identify the system’s threats and associated vulnerabilities. For each threat/vulnerability pair, the system owner determines the severity of impact upon the system’s confidentiality, integrity and availability, and determines the likelihood of the vulnerability exploit occurring given existing security controls. The product of the likelihood of occurrence and the impact severity results in the risk level for the system based on the exposure to the threat/vulnerability pair.
Once the risk level is determined for each threat/vulnerability pair, safeguards are identified for pairs with moderate or high risk levels. The risk is re-evaluated to determine the remaining risk, or residual risk level, after the recommended safeguard is implemented.
1 System Documentation Phase
The System Documentation Phase provides background information to describe the system and the data it handles, as CMS assets in support of or in fulfillment of the organization’s business mission. This phase establishes a framework for subsequent RA phases.
The system owner must provide system identification to include system description, business function and assets, and system security level determination. For new systems, these are defined when the system is first conceived and developed during the SDLC’s design and implementation phases of the system. These steps are illustrated in the top section in Appendix A: Risk Assessment Process Flow, Figure A-1.
1.1 Document System Identification
Document the system name, other related information, and the responsible organization. The system must be categorized as part of a General Support System (GSS), Major Application (MA) or be an “Other” Systems, according to the CMS SSP Methodology.
Official System Name
System Acronym
System of Records (SOR)
Financial Management Investment
Board (FMIB) Number
Web Support Team (WST) Number
System Type (select one) GSS, MA or “Other” System
Name of Organization
Address
City, State, Zip
Contract Number, Contractor
contact information (if applicable)
Identify system contacts information for system owner/manager name, business owner/manager, system maintainer manager and RA author. If applicable, provide contractor information, (i.e., contractor name, contract number, contact, e-mail address and phone number, project
officer/GTL name, e-mail address and phone number.)
Name of Individual
Title
Name of Organization
Address
Mailstop
City, State, Zip
Email Address
Phone number
Contractor contact information (if
applicable)
Identify the individual(s) responsible for security and the component’s Information System Security Officer.
Name (Component ISSO)
Title
Name of Organization
Address
Mailstop
City, State, Zip
Email Address
Phone number
Emergency Contact Information
(name, phone and e-mail only)
1.2 Document System Purpose and Description
(Asset Identification)
To identify the assets covered by the RA, provide a brief description of the function and purpose of the system and the organizational business processes supported, including functions and processing of data. If it is part of a GSS, include all supported applications, as well as functions and information processed.
1.2.1 Document System Environment and Special Considerations
Provide a brief general technical description of the system. Discuss any environmental factors that raise special security concerns and document the physical location of the system. Provide a network diagram or schematic to help identify, define, and clarify the system boundaries for the system, and a general description of the system.
1.2.2 Document System Interconnection/Information Sharing
For GSSs, show how the various components and sub-networks are connected and/or interconnected to any other Local Area Network (LAN) or Wide Area Network (WAN). For MAs and “Other” Systems provide a description of the system and sub-applications or other software interdependencies.
1.3 Document System Security Level
Describe and document the information handled by the system and identify the overall system security level as LOW, MODERATE, or HIGH. This element includes a general description of the information, the information sensitivity, and system criticality; which includes requirements for confidentiality, integrity and availability, auditability and accountability as dictated by CMS information security policy. Refer to the CMS Information Security Levels document on https://www.doczj.com/doc/903428289.html,/CyberTyger.
2 Risk Determination Phase
The goal of the Risk Determination Phase is to calculate the level of risk for each
threat/vulnerability pair based on: (1) the likelihood of a threat exploiting a vulnerability; and (2) the severity of impact that the exploited vulnerability would have on the system, its data and its business function in terms of loss of confidentiality, loss of integrity and loss of availability. The Risk Determination Phase is comprised of six steps:
1. Identify potential dangers to information and system (threats).
2. Identify the system weakness that could be exploited (vulnerabilities) associated to
generate the threat/vulnerability pair.
3. Identify existing controls to reduce the risk of the threat to exploit the vulnerability.
4. Determine the likelihood of occurrence for a threat exploiting a related vulnerability
given the existing controls.
5. Determine the severity of impact on the system by an exploited vulnerability.
6. Determine the risk level for a threat/vulnerability pair given the existing controls.
This six-step process for Risk Determination is conducted for each identified threat/vulnerability pair. These steps are illustrated in the center section of Appendix A: Risk Assessment Process Flow, Figure A-1. Use the following table, Table 1, to document the analysis performed in this phase.
Table 1. Risk Determination Phase Table
Item No. Threat
Name
Vulnerability
Name
Risk Description Existing
Controls
Likelihood
of
Occurrence
Impact
Severity
Risk
Level
The Item Number designated in the left-most column is for reference purposes only. It is assigned in numerical order as rows are added to the table for different threat/vulnerability pairs. The Item No. is also used in Table 5 in the Safeguard Determination Phase, to correlate the analysis done in both tables.
2.1 Identify System Environment Threats
Identify threats that could have the ability to exploit system vulnerabilities. Refer to the CMS Threat Identification Resource for environmental/physical, human, natural, and technical threats that may affect General Support Systems, Major Applications, and Other Systems, when applicable. The system owner must consider interconnection and interdependencies with other systems that may introduce new threats to the system under review. Therefore, an understanding of the system’s interconnections and subordinate processes, if any, will provide significant
information regarding inherited and new risks and controls that may affect the system and they must be identified in this section.
Complete columns labeled “Item No.” and “Threat Name” in Table 1 with the result of this step.
2.2 Identify System Vulnerabilities
Identify vulnerabilities associated with each threat to produce a threat/vulnerability pair. Vulnerabilities may be associated with either a single or multiple threats.
Previous risk assessment documentation, audit and system deficiencies reports, security advisories and bulletins, automated tools and technical security evaluations may be used to identify threats and vulnerabilities. Testing results during and after system development as part of the system’s SDLC may be used to identify vulnerabilities for new systems or systems undergoing major modifications.
Complete the column labeled “Vulnerability Name” in Table 1 with the result of this step.
2.3 Describe Risk
Describe how the vulnerability creates a risk in the system in terms of confidentiality, integrity and/or availability elements that may result in a compromise of the system and the data it handles.
Complete the column labeled “Risk Description” in Table 1 with the result of this step.
2.4 Identify Existing Controls
Identify existing controls that reduce: (1) the likelihood or probability of a threat exploiting an identified system vulnerability, and/or (2) the magnitude of impact of the exploited vulnerability on the system. Existing controls may be management, operational and/or technical controls depending on the identified threat/vulnerability pair and the risk to the system.
Complete the column labeled “Existing Controls” in Table 1 with the result of this step.
2.5 Determine the Likelihood of Occurrence
Determine the likelihood that a threat will exploit a vulnerability. The likelihood is an estimate of the frequency or the probability of such an event. Likelihood of occurrence is based on a number of factors that include system architecture, system environment, information system access and existing controls; the presence, motivation, tenacity, strength and nature of the threat; and the presence of vulnerabilities; and the effectiveness of existing controls.
Refer to the information provided in Table 2 for guidelines to determine the likelihood of occurrence that the threat is realized and exploits the system’s vulnerability.
Complete the column labeled “Likelihood of Occurrence” in Table 1 with the result of this step.
Table 2. Likelihood of Occurrence Levels
Likelihood Description
occur.
to
Negligible Unlikely
Very Low Likely to occur two/three times every five years.
Low Likely to occur one every year or less.
Medium Likely to occur once every six months or less.
High Likely to occur once per month or less.
Very High Likely to occur multiple times per month
Extreme Likely to occur multiple times per day
2.6 Determine the Severity of Impact
Determine the magnitude or severity of impact on the system’s operational capabilities and data if the threat is realized and exploits the associated vulnerability. Determine the severity of impact for each threat/vulnerability pair by evaluating the potential loss in each security category (confidentiality, integrity and availability) based on the system’s information security level as explained in the CMS Information Security Levels document and described in the System Documentation Phase of this methodology. The impact can be measured by loss of system functionality, degradation of system response time or inability to meet a CMS business mission, dollar losses, loss of public confidence, or unauthorized disclosure of data.
Refer to Table 3 for guidelines on impact severity levels.
Table 3. Impact Severity Levels
Impact Severity Description
Insignificant Will have almost no impact if threat is realized and exploits
vulnerability.
Minor Will have some minor effect on the system. It will require
minimal effort to repair or reconfigure the system.
Significant Will result in some tangible harm, albeit negligible and perhaps only noted by a few individuals or agencies. May cause political embarrassment. Will require some expenditure of resources to repair.
Damaging May cause damage to the reputation of system management, and/or notable loss of confidence in the system’s resources or services. It will require expenditure of significant resources to repair.
Serious May cause considerable system outage, and/or loss of connected customers or business confidence. May result in compromise or large amount of Government information or services.
Critical May cause system extended outage or to be permanently closed, causing operations to resume in a Hot Site environment. May result in complete compromise of Government agencies’ information or services.
Complete the column labeled “Impact Severity” in Table 1 with the result of this step.
2.7 Determine the Risk Level
The risk can be expressed in terms of the likelihood of the threat exploiting the vulnerability and the impact severity of that exploitation on the confidentiality, integrity and availability of the system. Mathematically, the Risk Level is equal to the Likelihood of Occurrence multiplied by the Severity of Impact in the system’s confidentiality, integrity and availability. Table 4 shows risk levels resulting from the affect of both parameters on the risk level. The system owner may increase the risk to a higher level depending on the system’s information security level and the level of compromise if a threat is realized.
Table 4. Risk Levels
Impact Severity
Likelihood
of
Occurrence Insignificant
Minor
Significant
Damaging
Serious
Critical
Negligible Low Low Low Low Low Low Very Low
Low Low Low Low Moderate Moderate Low Low Low Moderate Moderate High High Medium Low Low Moderate High High High High Low Moderate High High High High Very High Low Moderate High High High High Extreme
Low Moderate High High High High
Complete the column labeled “Risk Level” in Table 1 with the result of this step.
3 Safeguard Determination Phase
The Safeguard Determination Phase involves identification of additional controls, safeguards or corrective actions to minimize the threat exposure and vulnerability exploitation for each
threat/vulnerability pairs identified in the Risk Determination Phase and resulting in moderate or high risk levels. Identification of new security measures should address the level of risk already assessed for the threat/vulnerability pair and should reduce the risk level. The residual risk level is determined assuming full implementation of the recommended controls/safeguards.
The Safeguard Determination Phase is comprised of four steps:
1. Identify the controls/safeguards to reduce the risk level of an identified threat/vulnerability pair, if the risk level is moderate or high.
2. Determine the residual likelihood of occurrence of the threat if the recommended safeguard is implemented.
3. Determine the residual impact severity of the exploited vulnerability once the recommended safeguard is implemented.
4. Determine the residual risk level for the system.
These steps are illustrated in the bottom section of Appendix A: Risk Assessment Process Flow, Figure A-1.
Table 5 can be used to summarize the analysis performed during the Safeguard Determination Phase.
Table 5. Safeguard Determination Phase Table
Item No.
Recommended
Safeguard Description
Residual
Likelihood of
Occurrence
Residual
Impact
Severity
Residual Risk
Level
Use the Item Numbers created for Table 1 as reference in Table 5 to correlate the analysis summarized in both tables to the same threat/vulnerability pair and associated risk level. The Items Numbers here are used to maintain consistency, and ease of reference, and match a recommended safeguard to a threat/vulnerability pair. They refer back to the same item numbers used in the Risk Determination Phase for the threat/vulnerability pairs that resulted in moderate or high risk levels.
3.1 Identify Safeguards
Identify controls/safeguards for each threat/vulnerability pair with a moderate or high risk level as identified in the Risk Determination Phase. The purpose of the recommended safeguard is to reduce or minimize the level of risk. When identifying a safeguard, consider the:
(1) Security area where the control/safeguard belongs, such as management, operational,
technical;
(2) Method the control/safeguard employs to reduce the opportunity for the threat to exploit
the vulnerability;
(3) Effectiveness of the proposed control/safeguard to mitigate the risk level; and
(4) Policy and architectural parameters required for implementation in the CMS
environment.
Recommended safeguards will address the security category identified during the risk analysis process (confidentiality, integrity and availability) that may be compromised by the exploited vulnerability.
Complete the column labeled “Recommended Safeguard” in Table 5 with the result of this step. If more than one safeguard is identified for the same threat/vulnerability pair, list them in this column in separate rows and continue with the analysis steps: the residual risk level must be evaluated during this phase of the assessment and may be further evaluated in risk management activities outside of the scope of this methodology.
If a complete implementation of the recommended safeguard cannot be achieved in the CMS environment due to management, operational or technical constraints, annotate the circumstances in this space and continue with the analysis.
3.2 Determine Residual Likelihood of Occurrence
Follow the directions described in Section 2.4 of the Risk Determination Phase while assuming full implementation of the recommended safeguard.
Complete the column labeled “Residual Likelihood of Occurrence” in Table 5 with the result of this step.
3.3 Determine Residual Severity of Impact
Follow the directions described in Section 2.5 of the Risk Determination Phase while assuming full implementation of the recommended safeguard.
Complete the column labeled “Residual Impact Severity” in Table 5 with the result of this step.
3.4 Determine Residual Risk Level
Determine the residual risk level for the threat/vulnerability pair and its associated risk once the recommended safeguard is implemented. The residual risk level is determined by examining the likelihood of occurrence of the threat exploiting the vulnerability and the impact severity factors in categories of Confidentiality, Integrity and Availability.
Follow the directions described in Section 2.6 of the Risk Determination Phase to determine the residual risk level once the recommended safeguard is fully implemented.
Depending on the nature and circumstances of threats and vulnerabilities, a recommended safeguard may reduce the risk level to Low. Annotate with a narrative below the table, if needed, if such special conditions exist.
Complete the column labeled “Residual Risk Level” in Table 5 with the result of this step.
Appendix A: Risk Assessment Process Flow
Figure A-1: Risk Assessment Process Flow
Appendix B: Security in the System Development Life Cycle Although information security must be considered in all phases of the life of a system, the System Development Life Cycle identifies four specific steps that are needed to ensure that information at CMS is properly protected. These include the Information Sensitivity Assessment (Section 10.5 of the Business Case Analysis), System Requirements Document, the RA Report and the System Security Plan.
Step 1 - The Information Sensitivity Assessment (ISA)
Prior to project initiation, the system owner prepares a Business Case Analysis (BCA),
which includes the ISA (section 10.5 of the BCA). In this step, the system owner
categorizes the data according to sensitivity and identifies high-level security
requirements that apply to the system under consideration for development. Information from the ISA is one of the factors considered in determining if the system will go forward into development and what level of information security will be needed. Elements from
the ISA provide the initial input to the RA.
Step 2 –System Requirements Document (specifically Security Requirements)
As an initial step of the development process, system requirements are documented for
every system. The security requirements serve as a baseline for security within the
system. The CMS Minimum Information Security Standards is a tool to assist in defining security requirements. Other requirements may be determined by business or functional requirements.
Step 3 – Risk Assessment Report
During the development process, a risk assessment is conducted and the result RA Report documents the vulnerabilities that have been identified in the system, the risks to the
system resulting from the vulnerabilities and the efforts designed to reduce those risks,
through the use of safeguards. The RA Report provides input to the System Security Plan and other risk management activities.
Step 4 – System Security Plan
The System Security Plan incorporates all of the elements required for the system owner to determine if the system should be certified as meeting both CMS policy and business requirements. Information from the RA Report is incorporated into the System Security Plan in Section 2 – Management Controls.
Security steps also correspond to phases in the Integrated IT Investment Management Road Map (ROADMAP) for system development. The ROADMAP is CMS’ implementation standard for SDLC and Investment Management and can be found on
https://www.doczj.com/doc/903428289.html,/roadmap/intro/roadmap.htm. In Figure B-1, the system development life cycle and ROADMAP are shown on the right and left sides with the information security deliverables and tools entered in the center section between them. This format illustrates the relationship of the information security tasks to both processes.
Figure B-1. Security in the System Development Life Cycle and CMS’ Roadmap
Appendix C: References
CMS Information Security Levels;
https://www.doczj.com/doc/903428289.html,/cybertyger/docs/security_levels.pdf
CMS Integrated IT Investment Management Road Map; August 15, 2001;
https://www.doczj.com/doc/903428289.html,/roadmap/misc/IT_Investment_Mgmt_Process_Guide.pdf
CMS System Security Plan Methodology, Version 2.1;
https://www.doczj.com/doc/903428289.html,/hpages/ois/ssp/022102_SSP_meth_V2-1.pdf
Risk Management Guide for Information Technology Systems NIST Special Publication 800-30; https://www.doczj.com/doc/903428289.html,/publications/nistpubs/800-30/sp800-30.pdf
Australian Communications-Electronic Security Instruction 33, Handbook 3: Risk Management; Defense Signals Directorate; https://www.doczj.com/doc/903428289.html,.au/infosec/acsi33/HB3p.pdf
Appendix D: Information Security Risk Assessment Template 1 System documentation
1.1 System Identification
1.1.1 System Name/Title
Official System Name
System Acronym
System of Records (SOR)
Financial Management Investment
Board (FMIB) Number
Web Support Team (WST) Number
System Type (select one) GSS, MA or “Other” System
1.1.2 Responsible Organization
Name of Organization
Address
City, State, Zip
Contract Number, Contractor
contact information (if applicable)
1.1.3 Information Contact(s)
Name (System Owner/Manager)
Title
Name of Organization
Address
Mailstop
City, State, Zip
Email Address
Phone number
Contractor contact information (if
applicable)
Name (Business Owner/Manager) Title
Name of Organization
Address
Mailstop
City, State, Zip
Email Address
Phone number
Contractor contact information (if applicable)
Name (System Maintainer Manager) Title
Name of Organization
Address
Mailstop
City, State, Zip
Email Address
Phone number
Contractor contact information (if applicable)
Name (IS RA Author)
Title
Name of Organization
Address
Mailstop
City, State, Zip
Email Address
Phone number
Contractor contact information (if applicable)
1.1.4 Assignment of Security Responsibility
Name (individual[s] responsible for
security)
Title
Name of Organization
Address
Mailstop
City, State, Zip
Email Address
Phone number
Emergency Contact Information
(name, phone and e-mail only)
Name (Component ISSO)
Title
Name of Organization
Address
Mailstop
City, State, Zip
Email Address
Phone number
Emergency Contact Information
(name, phone and e-mail only)
1.2 Asset Identification
Identify the assets covered by the RA, provide a brief description of the function and
purpose of the system and the organizational business processes supported, including
functions and processing of data. If it is part of a GSS, include all supported applications, as well as functions and information processed.
[Click here and Type]
1.2.1 System Environment and Special Considerations
Provide a brief general technical description of the system. Discuss any environmental factors that raise special security concerns and document the physical location of the
system. Provide a network diagram or schematic to help identify, define, and clarify the system boundaries for the system, and a general description of the system.
信息安全风险评估模型及其算法研究 摘要：在信息科技日益发展，人类社会对信息的依赖性越来越强，信息资产的安全性受到空前的重视，而当前我国的信息安全水平普遍不高，与西方发达国家存在较大差距。在当前信息安全领域，主要的管理手段是奉行着“三分技术，七分管理”的原则。要想提高整体的信息安全水平，必须从一个组织整体的信息安全管理水平着手，而不仅是依赖于防火墙、入侵检测、漏洞扫描等传统信息安全技术手段，而目前信息安全管理的最起始的工作主要是信息安全风险评估，而信息安全风险评估的手段单一化、多元化、难以定量化。以往的信息安全风险评估多从AHP层析分析法、模糊综合评价及灰色理论入手，而较少采用V AR风险定量分析和概率论等数学方法去分析和评估信息安全的风险。以V AR风险定量分析每个风险源的损失额度，以概率论和数理统计的方法去评估每个风险源在整体信息安全的风险比例，从而便于组织合体调配资源，达到资源的最佳配置，降低组织的整体信息安全风险。 关键词：信息安全；风险评估；V AR分析；数理统计 1研究背景及现状 随着信息时代的迅速到来，众多的组织机构将重要信息存放在信息系统中，在业务上也越来越依赖信息系统的安全性、可用性、可恢复性。越来越多的组织机构意识到信息安全的重要性，例如金融、电力、通讯等相关涉及公共利益的组织机构投入巨资进行了信息安全能力的提升。而我国以公安部牵头的信息安全等级保护工作也在如火如荼的进行，对不同行业，不同机构进行分类保护，极大的从制度和法规方面促进了我国信息安全保护水平的提升，从国家宏观层面上积极推进了信息安全工作的开展。针对于国家公安部开展的信息安全等级保护工作，不同行业的信息安全等级易于测量，但对于某一行业具体金融机构的信息安全能力定级上难以定量化，不同金融机构所面对的信息安全风险大小不一，来源不同，极具差异化。小型银行在信息安全领域的花费将和大银行完全相同，将加大中小银行的商业负担，造成不必要的浪费，如何运用数量方法定量的而不是定性的去评估信息安全风险成为信息安全领域一个急需解决的学术问题。 ①国外的研究现状。目前在国外，最为流行的信息安全风险管理手段莫过于由信息系统审计与控制学会ISACA（InformationSystemsAuditandControl Association）在1996年公布的控制框架COBIT 目前已经更新至第四版，主要研究信息安全的风险管理。这个框架共有34个IT的流程，分成四个控制域：PO （Planning&Organization）、AI（Acquisition&Implementation）、DS （Delivery and Support）、ME（Monitor and Evaluate），共包含214个详细控制目标，提供了自我审计标准及最仕实践，能够指导组织有效利用信息资源。管理信息安全相关风险。文章总结了其中与信息安全管理相关的特点：更清晰的岗位责任划分。为了改善对IT流程模型的理解，COBIT4.0为每个IT流程进行了定义，对每个流程及基木输入/输出及与其他流程的关系进行了描述，确定它从哪个流程来，哪个
风险评估实施方案
一、风险评估概述 1、风险服务的重要性 对于构建一套良好的信息安全系统，需要对整个系统的安全风险有一个清晰的认识。只有清晰的了解了自身的弱点和风险的来源，才能够真正的解决和削弱它，并以此来构建有着对性的、合理有效的安全策略，而风险评估既是安全策略规划的第一步，同时也是实施其它安全策略的必要前提。 近几年随着几次计算机蠕虫病毒的大规模肆虐攻击，很对用户的网络都遭受了不同程度的攻击，仔细分析就会发现，几乎所有的用户都部署了防病毒软件和类似的安全防护系统，越来越多的用户发现淡村的安全产品已经不能满足现在的安全防护体系的需求了。 安全是整体的体系建设过程，根据安全的木桶原理，组织网络的整个安全最大强度取决于最短最脆弱的那根木头，因此说在安全建设的过程中，如果不仔细的找到最短的那根木头，而盲目的在外面加钉子，并不能改进整体强度。 信息安全风险评估是信息安全保障体系建立过程中的重要的评价方法和决策机制，只有经过全面的风险评估，才能让客户对自身信息安全的状况做出准确的判断。 2、风险评估服务的目的及其意义 信息安全风险是指人为或自然的威胁利用信息系统及其团里
体系中存在的脆弱性导致安全事件的发生及其对组织造成的影响。 信息安全风险评估是指依据有关信息安全技术与管理标准，对信息系统及由其处理、传输和存储的信息的机密性、完整性和可用性等安全属性进行评价的过程。她要评估资产面临的威胁以及威胁利用脆弱性导致安全事件的可能性，并结合安全事件所涉及的资产价值来判断安全事件一旦发生对组造成的影响。 信息安全风险评估是信息系统安全保障机制建立过程中的一种评价方法，其结果为信息安全更显管理提供依据。 3、风险评估服务机制 在信息系统生命周期里，有许多种情况必须对信息系统所涉及的人员、技术环境、物理环境进行风险评估： ●在设计规划或升级新的信息系统时； ●给当前的信息系统增加新应用时； ●在与其它组织（部门）进行网络互联时； ●在技术平台进行大规模更新（例如，从Linux系统移植到 Sliaris系统）时； ●在发生计算机安全事件之后，或怀疑可能会发生安全事件 时； ●关心组织现有的信息安全措施是否充分或食后具有相应的安 全效力时；
1111单位:1111系统安全项目信息安全风险评估报告 我们单位名 日期
报告编写人: 日期： 批准人：日期： 版本号：第一版本日期 第二版本日期 终板
目录 1概述 (5) 1.1项目背景 (5) 1.2工作方法 (5) 1.3评估范围 (5) 1.4基本信息 (5) 2业务系统分析 (6) 2.1业务系统职能 (6) 2.2网络拓扑结构 (6) 2.3边界数据流向 (6) 3资产分析 (6) 3.1信息资产分析 (6) 3.1.1信息资产识别概述 (6) 3.1.2信息资产识别 (7) 4威胁分析 (7) 4.1威胁分析概述 (7) 4.2威胁分类 (8) 4.3威胁主体 (8) 4.4威胁识别 (9) 5脆弱性分析 (9) 5.1脆弱性分析概述 (9) 5.2技术脆弱性分析 (10) 5.2.1网络平台脆弱性分析 (10) 5.2.2操作系统脆弱性分析 (10) 5.2.3脆弱性扫描结果分析 (10) 5.2.3.1扫描资产列表 (10) 5.2.3.2高危漏洞分析 (11) 5.2.3.3系统帐户分析 (11) 5.2.3.4应用帐户分析 (11)
5.3管理脆弱性分析 (11) 5.4脆弱性识别 (13) 6风险分析 (14) 6.1风险分析概述 (14) 6.2资产风险分布 (14) 6.3资产风险列表 (14) 7系统安全加固建议 (15) 7.1管理类建议 (15) 7.2技术类建议 (15) 7.2.1安全措施 (15) 7.2.2网络平台 (16) 7.2.3操作系统 (16) 8制定及确认................................................................................................................. 错误!未定义书签。9附录A：脆弱性编号规则.. (17)
从最开始接触风险评估理论到现在，已经有将近5个年头了，从最开始的膜拜捧为必杀技，然后是有一阵子怀疑甚至预弃之不用，到现在重拾之，尊之为做好安全的必备法宝，这么一段起起伏伏的心理历程。对风险的方法在一步步的加深，本文从风险评估工作最突出的问题：如何得到一致的、可比较的、可重复的风险评估结果，来加以分析讨论。 1. 风险评估的现状 风险理论也逐渐被广大信息安全专业人士所熟知，以风险驱动的方法去管理信息安全已经被大部分人所共知和接受，这几年国内等级保护的如火如荼的开展，风险评估工作是水涨船高，加之国内信息安全咨询和服务厂商和机构不遗余力的推动，风险评估实践也在不断的深入。当前的风险评估的方法主要参照两个标准，一个是国际标准《ISO13335信息安全风险管理指南》和国内标准《GB/T 20984-2007信息安全风险评估规范》，其本质上就是以信息资产为对象的定性的风险评估。基本方法是识别并评价组织/企业内部所要关注的信息系统、数据、人员、服务等保护对象，在参照当前流行的国际国内标准如ISO2700 2,COBIT，信息系统等级保护，识别出这些保护对象面临的威胁以及自身所存在的能被威胁利用的弱点，最后从可能性和影响程度这两个方面来评价信息资产的风险，综合后得到企业所面临的信息安全风险。这是大多数组织在做风险评估时使用的方法。当然也有少数的组织/企业开始在资产风险评估的基础上，在实践中摸索和开发出类似与流程风险评估等方法，补充完善了资产风险评估。 2. 风险评估的突出问题 信息安全领域的风险评估甚至风险管理的方法是借鉴了银行业成熟的风险管理方法，银行业业务风险管理的方法已经发展到相当成熟的地步，并且银行业也有非常丰富的基础数据支撑着风险分析方法的运用。但是，风险评估作为信息安全领域的新生事物，或者说舶来之物，尽管信息安全本身在国内开展也不过是10来年，风险评估作为先进思想也存在着类似“马列主义要与中国的实际国情结合走中国特色社会主义道路”的问题。风险评估的定量评估方法缺少必要的土壤，没有基础的、统计数据做支撑，定量风险评估寸步难移;而定性的风险评估其方法的本质是定性，所谓定性，则意味着估计、大概，不准确，其本质的缺陷给实践带来无穷的问题，重要问题之一就是投资回报问题，由于不能从财务的角度去评价一个/组风险所带来的可能损失，因此，也就没有办法得到投资回报率，尽管这是个问题，但是实践当中，一般大的企业都会有个基本的年度预算，IT/安全占企业年度预算的百分之多少，然后就是反正就这么些钱，按照风险从高到低或者再结合其他比如企业现有管理和技术水平，项目实施的难易度等情况综合考虑得到风险处理优先级，从高到低依次排序，钱到哪花完，风险处理今年就处理到哪。这方法到也比较具有实际价值，操作起来也容易，预算多的企业也不怕钱花不完，预算少的企业也有其对付办法，你领导就给这么些钱，哪些不能处理的风险反正我已经告诉你啦，要是万一出了事情你也怪不得我，没有出事情，等明年有钱了再接着处理。
1、风险评估概述 1.1风险评估概念 信息安全风险评估是参照风险评估标准和管理规，对信息系统的资产价值、潜在威胁、薄弱环节、已采取的防护措施等进行分析，判断安全事件发生的概率以及可能造成的损失，提出风险管理措施的过程。当风险评估应用于IT领域时，就是对信息安全的风险评估。风险评估从早期简单的漏洞扫描、人工审计、渗透性测试这种类型的纯技术操作，逐渐过渡到目前普遍采用国际标准的BS7799、ISO17799、国家标准《信息系统安全等级评测准则》等方法，充分体现以资产为出发点、以威胁为触发因素、以技术/管理/运行等方面存在的脆弱性为诱因的信息安全风险评估综合方法及操作模型。 1.2风险评估相关 资产，任何对组织有价值的事物。 威胁，指可能对资产或组织造成损害的事故的潜在原因。例如，组织的网络系统可能受到来自计算机病毒和黑客攻击的威胁。 脆弱点，是指资产或资产组中能背威胁利用的弱点。如员工缺乏信息安全意思，使用简短易被猜测的口令、操作系统本身有安全漏洞等。 风险，特定的威胁利用资产的一种或一组薄弱点，导致资产的丢失或损害饿潜在可能性，即特定威胁事件发生的可能性与后果的结合。风险评估，对信息和信息处理设施的威胁、影响和脆弱点及三者发生的可能性评估。
风险评估也称为风险分析，就是确认安全风险及其大小的过程，即利用适当的风险评估工具，包括定性和定量的方法，去顶资产风险等级和优先控制顺序。 2、风险评估的发展现状 2.1信息安全风险评估在美国的发展 第一阶段（60-70年代）以计算机为对象的信息阶段 1067年11月到1970年2月，美国国防科学委员会委托兰德公司、迈特公司（MITIE）及其它和国防工业有关的一些公司对当时的大型机、远程终端进行了研究，分析。作为第一次比较大规模的风险评估。 特点： 仅重点针对了计算机系统的性问题提出要求，对安全的评估只限于性，且重点在于安全评估，对风险问题考虑不多。 第二阶段（80-90年代）以计算机和网络为对象的信息系统安全保护阶段 评估对象多为产品，很少延拓至系统，婴儿在严格意义上扔不是全面的风险评估。 第三阶段（90年代末，21世纪初）以信息系统为对象的信息保障阶段 随着信息保障的研究的深入，保障对象明确为信息和信息系统；保障能力明确来源于技术、管理和人员三个方面；逐步形成了风险评估、自评估、认证认可的工作思路。
信息安全风险评估方 案
第一章网络安全现状与问题 1.1目前安全解决方案的盲目性 现在有很多公司提供各种各样的网络安全解决方案，包括加密、身份认证、防病毒、防黑客等各个方面，每种解决方案都强调所论述方面面临威胁的严重性，自己在此方面的卓越性，但对于用户来说这些方面是否真正是自己的薄弱之处，会造成多大的损失，如何评估，投入多大可以满足要求，对应这些问题应该采取什麽措施，这些用户真正关心的问题却很少有人提及。 1.2网络安全规划上的滞后 网络在面对目前越来越复杂的非法入侵、内部犯罪、恶意代码、病毒威胁等行为时，往往是头痛医头、脚痛医脚，面对层出不穷的安全问题，疲于奔命，再加上各种各样的安全产品与安全服务，使用户摸不着头脑，没有清晰的思路，其原因是由于没有一套完整的安全体系，不能从整体上有所把握。 在目前网络业务系统向交易手段模块化、经纪业务平台化与总部集中监控的趋势下，安全规划显然未跟上网络管理方式发展的趋势。 第二章网络动态安全防范体系 用户目前接受的安全策略建议普遍存在着“以偏盖全”的现象，它们过分强调了某个方面的重要性，而忽略了安全构件（产品）之间的关系。因此在客户化的、可操作的安全策略基础上，需要构建一个具有全局观的、多层次的、组件化的安全防御体系。它应涉及网络边界、网络基础、核心业务和桌面等多个层面，涵盖路由器、交换机、防火墙、接入服务器、数据库、操作系统、DNS、WWW、MAIL及其它应用系统。 静态的安全产品不可能解决动态的安全问题，应该使之客户化、可定义、可管理。无论静态或动态（可管理）安全产品，简单的叠加并不是有效的防御措施，应该要求安全产品构件之间能够相互联动，以便实现安全资源的集中管理、统一审计、信息共享。 目前黑客攻击的方式具有高技巧性、分散性、随机性和局部持续性的特点，因此即使是多层面的安全防御体系，如果是静态的，也无法抵御来自外部
胜达集团 信息安全评估报告 (管理信息系统) 胜达集团 二零一六年一月
1目标 胜达集团信息安全检查工作的主要目标是通过自评估工作，发现本局信息系统当前面临的主要安全问题，边检查边整改，确保信息网络和重要信息系统的安全。 2评估依据、范围和方法 2.1 评估依据 根据国务院信息化工作办公室《关于对国家基础信息网络和重要信息系统开展安全检查的通知》（信安通［2006］15号）、国家电力监管委员会《关于对电力行业有关单位重要信息系统开展安全检查的通知》（办信息[2006]48号）以及集团公司和省公司公司的文件、检查方案要求, 开展××单位的信息安全评估。 2.2 评估范围 本次信息安全评估工作重点是重要的业务管理信息系统和网络系统等， 管理信息系统中业务种类相对较多、网络和业务结构较为复杂，在检查工作中强调对基础信息系统和重点业务系统进行安全性评估，具体包括：基础网络与服务器、关键业务系统、现有安全防护措施、信息安全管理的组织与策略、信息系统安全运行和维护情况评估。2.3 评估方法 采用自评估方法。 3重要资产识别 对本局范围内的重要系统、重要网络设备、重要服务器及其安全属性受破坏后的影响进行识别，将一旦停止运行影响面大的系统、关键网络节点设备和安全设备、承载敏感数据和业务的服务器进行登记汇总，形成重要资产清单。 资产清单见附表1。 4安全事件 对本局半年内发生的较大的、或者发生次数较多的信息安全事件进行汇总记录，形成本单位的安全事件列表。安全事件列表见附表2。 5安全检查项目评估 5.1 规章制度与组织管理评估 5.1.1组织机构 5.1.1.1评估标准 信息安全组织机构包括领导机构、工作机构。 5.1.1.2现状描述 本局已成立了信息安全领导机构，但尚未成立信息安全工作机构。 5.1.1.3 评估结论
信息安全技术公共基础设施PKI系统安全等级保护技术要求 引言 公开密钥基础设施（PKI）是集机构、系统（硬件和软件）、人员、程序、策略和协议为一体，利用公钥概念和技术来实施和提供安全服务的、具有普适性的安全基础设施。PKI系统是通过颁发与管理公钥 证书的方式为终端用户提供服务的系统，包括CA、RA、资料库等基本逻辑部件和OCSP等可选服务部件以及所依赖的运行环境。 《PKI系统安全等级保护技术要求》按五级划分的原则，制定PKI系统安全等级保护技术要求，详细说明了为实现GB/T AAA—200×所提出的PKI系统五个安全保护等级应采取的安全技术要求、为确保这些安全技术所实现的安全功能能够达到其应具有的安全性而采取的保证措施，以及各安全技术要求在不同安全级中具体实现上的差异。第一级为最低级别，第五级为最高级别，随着等级的提高，PKI系统安全等级保护的要求也随之递增。正文中字体为黑体加粗的内容为本级新增部分的要求。 信息安全技术公钥基础设施 PKI系统安全等级保护技术要求 1 范围 本标准依据GB/T AAA—200×的五个安全保护等级的划分，规定了不同等级PKI系统所需要的安全技术要求。 本标准适用于PKI系统的设计和实现，对于PKI系统安全功能的研制、开发、测试和产品采购亦可参照使用。 2 规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，提倡使用本标准的各方探讨使用其最新 版本的可能性。凡是不注日期的引用文件，其最新版本适用于本标准。 GB/T 19713-2005 信息安全技术公钥基础设施在线证书状态协议 GB/T 20271-2006 信息安全技术信息系统通用安全技术要求 GB/T 20518-2006 信息安全技术公钥基础设施数字证书格式 GB/T 21054-2007 信息安全技术公钥基础设施PKI系统安全等级保护评估准则 GB/T 21052-2007 信息安全技术信息系统物理安全技术要求 GB/T20984-2007 信息安全技术信息安全风险评估指南 3 术语和定义 下列术语和定义适用于本标准。 3.1 公开密钥基础设施（PKI）public key infrastructure (PKI) 公开密钥基础设施是支持公钥管理体制的基础设施，提供鉴别、加密、完整性和不可否认性服务。 3.2 PKI系统PKI system PKI系统是通过颁发与管理公钥证书的方式为终端用户提供服务的系统，包括CA、RA、资料库等基本逻辑部件和OCSP等可选服务部件以及所依赖的运行环境。 3.3
信息安全风险评估方案 第一章网络安全现状与问题 1、1 目前安全解决方案的盲目性现在有很多公司提供各种各样的网络安全解决方案，包括加密、身份认证、防病毒、防黑客等各个方面，每种解决方案都强调所论述方面面临威胁的严重性，自己在此方面的卓越性，但对于用户来说这些方面是否真正是自己的薄弱之处，会造成多大的损失，如何评估，投入多大可以满足要求，对应这些问题应该采取什麽措施，这些用户真正关心的问题却很少有人提及。 1、2 网络安全规划上的滞后网络在面对目前越来越复杂的非法入侵、内部犯罪、恶意代码、病毒威胁等行为时，往往是头痛医头、脚痛医脚，面对层出不穷的安全问题，疲于奔命，再加上各种各样的安全产品与安全服务，使用户摸不着头脑，没有清晰的思路，其原因是由于没有一套完整的安全体系，不能从整体上有所把握。 在目前网络业务系统向交易手段模块化、经纪业务平台化与总部集中监控的趋势下，安全规划显然未跟上网络管理方式发展的趋势。 第二章网络动态安全防范体系用户目前接受的安全策略建议普遍存在着“以偏盖全”的现象，它们过分强调了某个方面的重要性，而忽略了安全构件（产品）之间的关系。因此在客户化的、可操作的安全策略基础上，需要构建一个具有全局观的、多层次的、组件化的安全防御体系。它应涉及网络边界、网络基础、核心业务和桌面等多个层面，涵盖路由器、交换机、防火墙、接入服务器、数据库、操作系统、 DNS、 WWW、 MAIL 及其它应用系统。 静态的安全产品不可能解决动态的安全问题，应该使之客户化、可定义、可管理。无论静态或动态（可管理）安全产品，简单的叠加并不是有效的防御措施，应该要求安全产品构件之间能够相互联动，以便实现安全资源的集中管理、统一审计、信息共享。
附件： 国家电子政务工程建设项目非涉密信息系统信息安全风险评估报告格式 项目名称： 项目建设单位： 风险评估单位： 年月日
目录 一、风险评估项目概述 (1) 1.1工程项目概况 (1) 1.1.1 建设项目基本信息 (1) 1.1.2 建设单位基本信息 (1) 1.1.3承建单位基本信息 (2) 1.2风险评估实施单位基本情况 (2) 二、风险评估活动概述 (2) 2.1风险评估工作组织管理 (2) 2.2风险评估工作过程 (2) 2.3依据的技术标准及相关法规文件 (2) 2.4保障与限制条件 (3) 三、评估对象 (3) 3.1评估对象构成与定级 (3) 3.1.1 网络结构 (3) 3.1.2 业务应用 (3) 3.1.3 子系统构成及定级 (3) 3.2评估对象等级保护措施 (3) 3.2.1XX子系统的等级保护措施 (3) 3.2.2子系统N的等级保护措施 (3) 四、资产识别与分析 (4) 4.1资产类型与赋值 (4) 4.1.1资产类型 (4) 4.1.2资产赋值 (4) 4.2关键资产说明 (4) 五、威胁识别与分析 (4)
5.2威胁描述与分析 (5) 5.2.1 威胁源分析 (5) 5.2.2 威胁行为分析 (5) 5.2.3 威胁能量分析 (5) 5.3威胁赋值 (5) 六、脆弱性识别与分析 (5) 6.1常规脆弱性描述 (5) 6.1.1 管理脆弱性 (5) 6.1.2 网络脆弱性 (5) 6.1.3系统脆弱性 (5) 6.1.4应用脆弱性 (5) 6.1.5数据处理和存储脆弱性 (6) 6.1.6运行维护脆弱性 (6) 6.1.7灾备与应急响应脆弱性 (6) 6.1.8物理脆弱性 (6) 6.2脆弱性专项检测 (6) 6.2.1木马病毒专项检查 (6) 6.2.2渗透与攻击性专项测试 (6) 6.2.3关键设备安全性专项测试 (6) 6.2.4设备采购和维保服务专项检测 (6) 6.2.5其他专项检测 (6) 6.2.6安全保护效果综合验证 (6) 6.3脆弱性综合列表 (6) 七、风险分析 (6) 7.1关键资产的风险计算结果 (6) 7.2关键资产的风险等级 (7) 7.2.1 风险等级列表 (7)
第一章网络安全现状与问题 目前安全解决方案的盲目性 现在有很多公司提供各种各样的网络安全解决方案，包括加密、身份认证、防病毒、防黑客等各个方面，每种解决方案都强调所论述方面面临威胁的严重性，自己在此方面的卓越性，但对于用户来说这些方面是否真正是自己的薄弱之处，会造成多大的损失，如何评估，投入多大可以满足要求，对应这些问题应该采取什麽措施，这些用户真正关心的问题却很少有人提及。 网络安全规划上的滞后 网络在面对目前越来越复杂的非法入侵、内部犯罪、恶意代码、病毒威胁等行为时，往往是头痛医头、脚痛医脚，面对层出不穷的安全问题，疲于奔命，再加上各种各样的安全产品与安全服务，使用户摸不着头脑，没有清晰的思路，其原因是由于没有一套完整的安全体系，不能从整体上有所把握。 在目前网络业务系统向交易手段模块化、经纪业务平台化与总部集中监控的趋势下，安全规划显然未跟上网络管理方式发展的趋势。 第二章网络动态安全防范体系 用户目前接受的安全策略建议普遍存在着“以偏盖全”的现象，它们过分强调了某个方面的重要性，而忽略了安全构件（产品）之间的关系。因此在客户化的、可操作的安全策略基础上，需要构建一个具有全局观的、多层次的、组件化的安全防御体系。它应涉及网络边界、网络基础、核心业务和桌面等多个层面，涵盖路由器、交换机、防火墙、接入服务器、数据库、操作系统、DNS、WWW、MAIL及其它应用系统。 静态的安全产品不可能解决动态的安全问题，应该使之客户化、可定义、可管理。无论静态或动态（可管理）安全产品，简单的叠加并不是有效的防御措施，应该要求安全产品构件之间能够相互联动，以便实现安全资源的集中管理、统一审计、信息共享。 目前黑客攻击的方式具有高技巧性、分散性、随机性和局部持续性的特点，因此即使是多层面的安全防御体系，如果是静态的，也无法抵御来自外部和内部的攻击，只有将众多的攻击手法进行搜集、归类、分析、消化、综合，将其体系化，才有可能使防御系统与之相匹配、相耦合，以自动适应攻击的变化，从而
信息安全风险评估技术手段综述 王英梅1 （北京科技大学信息工程学院北京 100101） 摘要：信息安全成为国家安全的重要组成部分，因此为保证信息安全，建立信息安全管理体系已成为目前安全建设的首要任务。风险评估作为信息安全管理体系建设的基础，在体系建设的各个阶段发挥着重要的作用。风险评估的进行离不开风险评估工具，本文在对风险评估工具进行分类的基础上，探讨了目前主要的风险评估工具的研究现状及发展方向。 关键词：风险评估综合风险评估信息基础设施工具 引言 当今时代，信息是一个国家最重要的资源之一，信息与网络的运用亦是二十一世纪国力的象征，以网络为载体、信息资源为核心的新经济改变了传统的资产运营模式，没有各种信息的支持，企业的生存和发展空间就会受到限制。信息的重要性使得他不但面临着来自各方面的层出不穷的挑战，因此，需要对信息资产加以妥善保护。正如中国工程院院长徐匡迪所说：“没有安全的工程就是豆腐渣工程”。信息同样需要安全工程。而人们在实践中逐渐认识到科学的管理是解决信息安全问题的关键。信息安全的内涵也在不断的延伸，从最初的信息保密性发展到信息的完整性、可用性、可控性和不可否认性，进而又发展为“攻（攻击）、防（防范）、测（检测）、控（控制）、管（管理）、评（评估）”等多方面的基础理论和实施技术。 如何保证组织一直保持一个比较安全的状态，保证企业的信息安全管理手段和安全技术发挥最大的作用，是企业最关心的问题。同时企业高层开始意识到信息安全策略的重要性。突然间，IT专业人员发现自己面临着挑战：设计信息安全政策该从何处着手？如何拟订具有约束力的安全政策？如何让公司员工真正接受安全策略并在日常工作中执行？借助于信息安全风险评估和风险评估工具，能够回答以上的问题。 一.信息安全风险评估与评估工具 风险评估是对信息及信息处理设施的威胁、影响、脆弱性及三者发生的可能性的评估。它是确认安全风险及其大小的过程，即利用定性或定量的方法，借助于风险评估工具，确定信息资产的风险等级和优先风险控制。 风险评估是风险管理的最根本依据，是对现有网络的安全性进行分析的第一手资料，也 1作者介绍：王英梅(1974-)，博士研究生，研究方向为信息安全、风险评估。国家信息中心《信息安全风险评估指南》编写小组成员。
信息安全风险评估需求 方案 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】
信息安全风险评估需求方案 一、项目背景 多年来，天津市财政局（地方税务局）在加快信息化建设和信息系统开发应用的同时，高度重视信息安全工作，采取了很多防范措施，取得了较好的工作效果，但同新形势、新任务的要求相比，还存在有许多不相适应的地方。2009年，国家税务总局和市政府分别对我局信息系统安全情况进行了抽查，在充分肯定成绩的同时，也指出了我局在信息安全方面存在的问题。通过抽查所暴露的这些问题，给我们敲响了警钟，也对我局信息安全工作提出了新的更高的要求。 因此，天津市财政局（地方税务局）在对现有信息安全资源进行整合、整改的同时，按照国家税务总局信息安全管理规定，结合本单位实际情况确定实施信息安全评估、安全加固、应急响应、安全咨询、安全事件通告、安全巡检、安全值守、安全培训、应急演练服务等工作内容（以下简称“安全风险评估”），形成安全规划、实施、检查、处置四位一体的长效机制。 二、项目目标 通过开展信息“安全风险评估”, 完善安全管理机制；通过安全服务的引入，进一步建立健全财税系统安全管理策略，实现安全风险的可知、可控和可管理；通过建立财税系统信息安全风险评估机制，实现财税系统信息安全风险的动态跟踪分析，为财税系统信息安全整体规划提供科学的决策依据，进一步加强财税内部网络的
整体安全防护能力，全面提升我局信息系统整体安全防范能力，极大提高财税系统网络与信息安全管理水平；通过深入挖掘网络与信息系统存在的脆弱点，并以业务系统为关键要素，对现有的信息安全管理制度和技术措施的有效性进行评估，不断增强系统的网络和信息系统抵御风险安全风险能力，促进我局安全管理水平的提高，增强信息安全风险管理意识，培养信息安全专业人才，为财税系统各项业务提供安全可靠的支撑平台。 三、项目需求 （一）服务要求 1基本要求 “安全风险评估服务”全过程要求有据可依，并在产品使用有据可查，并保持项目之后的持续改进。针对用户单位网络中的IT 设备及应用软件，需要有软件产品识别所有设备及其安全配置，或以其他方式收集、保存设备明细及安全配置，进行资产收集作为建立信息安全体系的基础。安全评估的过程及结果要求通过软件或其他形式进行展示。对于风险的处理包括：协助用户制定安全加固方案、在工程建设及日常运维中提供安全值守、咨询及支持服务，通过安全产品解决已知的安全风险。在日常安全管理方面提供安全支持服务，并根据国家及行业标准制定信息安全管理体系，针对安全管理员提供安全培训，遇有可能的安全事件发生时，提供应急的安全分析、紧急响应服务。
XXXXX公司 信息安全风险评估报告 历史版本编制、审核、批准、发布实施、分发信息记录表
一. 风险项目综述 1.企业名称: XXXXX公司 2.企业概况：XXXXX公司是一家致力于计算机软件产品的开发与销售、计算机信息系统集成及技术支持欢迎下载 2
3.ISMS方针：预防为主，共筑信息安全；完善管理，赢得顾客信赖。 4.ISMS范围：计算机应用软件开发，网络安全产品设计/开发，系统集成及服务的信息安全管理。 二. 风险评估目的 为了在考虑控制成本与风险平衡的前提下选择合适的控制目标和控制方式，将信息安全风险控制在可接受的水平,进行本次风险评估。 三. 风险评估日期： 2017-9-10至2017-9-15 四. 评估小组成员 XXXXXXX。 五. 评估方法综述 1、首先由信息安全管理小组牵头组建风险评估小组； 2、通过咨询公司对风险评估小组进行相关培训； 3、根据我们的信息安全方针、范围制定信息安全风险管理程序，以这个程序作为我们风险评估的依据和方 法； 4、各部门识别所有的业务流程，并根据这些业务流程进行资产识别，对识别的资产进行打分形成重要资产 清单； 5、对每个重要资产进行威胁、脆弱性识别并打分，并以此得到资产的风险等级； 6、根据风险接受准则得出不可接受风险，并根据标准ISO27001:2013的附录A制定相关的风险控制措施； 7、对于可接受的剩余风险向公司领导汇报并得到批准。 六. 风险评估概况 欢迎下载 3
欢迎下载 4 如下： 1. 2017-9-10 ~ 2017-9-10，风险评估培训； 2. 2017-9-11 ~ 2017-9-11，公司评估小组制定《信息安全风险管理程序》，制定系统化的风险评估方法； 3. 2017-9-12 ~ 2017-9-12，本公司各部门识别本部门信息资产，并对信息资产进行等级评定，其中资产分为物理资产、软件资产、数据资产、文档资产、无形资产，服务资产等共六大类； 4. 2017-9-13 ~ 2017-9-13，本公司各部门编写风险评估表，识别信息资产的脆弱性和面临的威胁，评估潜在风险，并在ISMS 工作组内审核； 5. 2017-9-14 ~ 2017-9-14，本公司各部门实施人员、部门领导或其指定的代表人员一起审核风险评估表； 6. 2017-9-15 ~ 2017-9-15，各部门修订风险评估表，识别重大风险，制定控制措施；ISMS 工作组组织审核，并最终汇总形成本报告。 . 七. 风险评估结果统计 本次风险评估情况详见各部门“风险评估表”，其中共识别出资产190个，重要资产115个，信息安全风 险115个，不可接受风险42个.
第3章业务系统信息安全风险评估方案 3.1 风险评估概述 3.1.1 背景 该业务系统风险评估的目标是评估业务系统的风险状况，提出风险控制建议，同时为下一步要制定的业务系统安全管理规范以及今后业务系统的安全建设和风险管理提供依据和建议。 需要指出的是，本评估报告中所指的安全风险针对的是现阶段该业务系统的风险状况，反映的是系统当前的安全状态。 3.1.2 范围 该业务系统风险评估范围包括业务系统网络、管理制度、使用或管理业务系统的相关人员以及由业务系统使用时所产生的文档、数据。 3.1.3 评估方式 信息系统具有一定的生命周期，在其生命中期内完成相应的使命。采取必要的安全保护方式使系统在其生命周期内稳定、可靠地运行是系统各种技术、管理应用的基本原则。 本项目的评估主要根据国际标准、国家标准和地方标准，从识别信息系统的资产入手，确定重要资产，针对重要资产分析其面临的安全威胁并识别其存在的脆弱性，最后综合评估系统的安全风险。 资产划分是风险评估的基础，在所有识别的系统资产中，依据资产在机密性、完整性和可用性安全属性的价值不同，综合判定资产重要性程度并将其划分为核心、关键、中等、次要和很低5个等级。 对于列为重要及以上等级的资产，分析其面临的安全威胁。 脆弱性识别主要从技术和管理两个层面，采取人工访谈。现场核查。扫描检测。渗透性测试等方式，找出系统所存在的脆弱性和安全隐患。 对重要资产已识别的威胁、脆弱性，根据其可能性和严重性，综合评估其安全风险。 3.2 该业务系统概况 3.2.1 该业务系统背景 近年来，由于数据量迅速增加，业务量也迅速增长，原先的硬件系统、应用系统和模式已渐渐不适应业务的需求，提升IT管理系统已经成为刻不容缓的事情。 经过仔细论证之后，信息决策部门在IT管理系统升级上达成如下共识：更换新的硬件设备，使用更先进和更强大的主机；在模式上为统一的集中式系统；在系统上用运行和维护效率较高的单库结构替换原有多库系统；在技术上准备使用基于B/S架构的J2EE中间件技术，并且实施999.999%的高可靠性运行方式；在业务上用新型工作流作为驱动新一代业务系统的引擎，真正达到通过以客户为中心来提升利润及通过高效智能的工作流来提高每个行员的劳动生产率，从而降低成本、提高核心竞争力以应对外部的竞争。 3.2.2 网络结构与拓扑图 该系统的网络包含应用服务器组、数据库服务器组、业务管理端、网络连接设备和安全防护设备。业务系统网络通过一台高性能路由器连接分部网络，通过一台千兆以太网交换机连接到其他业务系统。其中业务系统网络内部骨干网络采用千兆位以太网，两台千兆以太网交换机位骨干交换机。网络配备百兆桌面交换机来连接网络管理维护客户机。
***软件有限公司 信息安全风险评估指南
变更记录
信息安全风险评估指南 1、本指南在编制过程中主要依据了国家政策法规、技术标准、规范与管理要求、行业标准并得到了 无锡新世纪信息科技有限公司的大力支持。 1.1政策法规： ?《国家信息化领导小组关于加强信息安全保障工作的意见》（中办发[2003]27号） ?《国家网络与信息安全协调小组关于开展信息安全风险评估工作的意见》（国信办[2006]5号） 1.2国际标准： ?ISO/IEC 17799：2005《信息安全管理实施指南》 ?ISO/IEC 27001：2005《信息安全管理体系要求》 ?ISO/IEC TR 13335《信息技术安全管理指南》 1.3国内标准： ?《信息安全风险评估指南》（国信办综[2006]9号） ?《重要信息系统灾难恢复指南》（国务院信息化工作办公室2005年4月） ?GB 17859—1999《计算机信息系统安全保护等级划分准则》 ?GB/T 18336 1-3：2001《信息技术安全性评估准则》 ?GB/T 5271.8--2001 《信息技术词汇第8部分：安全》 ?GB/T 19715.1—2005 《信息技术安全管理指南第1部分：信息技术安全概念和模型》 ?GB/T 19716—2005 《信息安全管理实用规则》 1.4其它 ?《信息安全风险评估方法与应用》（国家863高技术研究发展计划资助项目(2004AA147070)） 2、风险评估 2.1、风险评估要素关系模型 风险评估的出发点是对与风险有关的各因素的确认和分析。下图中方框部分的内容为风险评估的基本要素，椭圆部分的内容是与这些要素相关的属性，也是风险评估要素的一部分。风险评估的工作是围绕其基本要素展开的，在对这些要素的评估过程中需要充分考虑业务战略、资产价值、安全事件、残余风险等与这些基本要素相关的各类因素。如下模型表示了各因素的关系：
企业信息安全风险评估方案
知识域：信息安全风险评估 ?:?知识子域：风险评估流程和方法 ■掌握国家对开展风险评估工作的政策要求 ■理解风险评估、检查评估和等级保护测评之间的关系 掌握风险评估的实施流程：风险评估准备、资产识别、威胁评 估、脆弱性评估、已有安全措施确认、风险分析、风险评估文档 记录 -理解走量风险分析和定性风险分析的区别及优缺点理解自评估和检查评估的区别及优缺点 ■掌握典型风险计算方法：年度损失值(ALE)、矩阵法、相乘法掌握风险评估工具：风险评估与管理工具、系统基础平台风险评 估工具、风险评估辅助工具
1、《国家信息化领导小组关于加强信息安全保障工作的意见》仲办发[2003]27号）中明确提出 :”要重视信息安全风险评估工作”对网络与信息系统安全的潜在威胁.薄弱环节、防护措施等进行分析评估，综合考虑网络与信息系统的重要性.涉密程度和面临的信息安全风险等因素，进行相应等级的安全建设和管理〃
国家对开展风险评估工作的政 2、《国家网络与信息安全协调小组〈关于开展信息安全风险评估工作的意见〉》（国信办［2006 】5号文）中明确规定了风险评估工作的相关要求： 风险评估的基本内容和原则开展风险评估工作的有 关安排 风险评估工作的基本要求 K信息安全风险评估工作应当贯穿信息系统全生命周 期。在信息系统规划设计阶段，通过信息安全风险评 估工作，可以明确信息系统的安全需求及其安全目标，有针对性地制定和部署安全措施”从而避免产生欠保 护或过保护的情况。
2、在信息系统建设完成验收时，通过风险评估工作可以检验信息系统是否实现了所设计的安全功能, 是否满足了信息系统的安全需求并达到预期的安全目标。 3. 由于信息技术的发展.信息系统业务以及所处安全环境的变化，会不断出现新的信息安全风险，因此，在信息系统的运行阶段，应当定期逬行信息安全风险评估，以检验安全措施的有效性以及对安全环境的适应性。当安全形势发生重大变化或信息系统使命有重大变更时，应及时逬行信息安全风险评估。 4. 信息安全风险评估也是落实等级保护制度的重要 手段，应通过信息安全风险评估为信息系统确定安全
第一章网络安全现状与问题 1.1目前安全解决方案的盲目性 现在有很多公司提供各种各样的网络安全解决方案，包括加密、身份认证、防病毒、防黑客等各个方面，每种解决方案都强调所论述方面面临威胁的严重性，自己在此方面的卓越性，但对于用户来说这些方面是否真正是自己的薄弱之处，会造成多大的损失，如何评估，投入多大可以满足要求，对应这些问题应该采取什麽措施，这些用户真正关心的问题却很少有人提及。 1.2网络安全规划上的滞后 网络在面对目前越来越复杂的非法入侵、内部犯罪、恶意代码、病毒威胁等行为时，往往是头痛医头、脚痛医脚，面对层出不穷的安全问题，疲于奔命，再加上各种各样的安全产品与安全服务，使用户摸不着头脑，没有清晰的思路，其原因是由于没有一套完整的安全体系，不能从整体上有所把握。 在目前网络业务系统向交易手段模块化、经纪业务平台化与总部集中监控的趋势下，安全规划显然未跟上网络管理方式发展的趋势。 第二章网络动态安全防范体系 用户目前接受的安全策略建议普遍存在着“以偏盖全”的现象，它们过分强调了某个方面的重要性，而忽略了安全构件（产品）之间的关系。因此在客户化的、可操作的安全策略基础上，需要构建一个具有全局观的、多层次的、组件化的安全防御体系。它应涉及网络边界、网络基础、核心业务和桌面等多个层面，涵盖路由器、交换机、防火墙、接入服务器、数据库、操作系统、DNS、WWW、MAIL及其它应用系统。 静态的安全产品不可能解决动态的安全问题，应该使之客户化、可定义、可管理。无论静态或动态（可管理）安全产品，简单的叠加并不是有效的防御措施，应该要求安全产品构件之间能够相互联动，以便实现安全资源的集中管理、统一审计、信息共享。 目前黑客攻击的方式具有高技巧性、分散性、随机性和局部持续性的特点，因此即使是多层面的安全防御体系，如果是静态的，也无法抵御来自外部和内部的攻击，只有将众多的攻击手法进行搜集、归类、分析、消化、综合，将其体系化，才有可能使防御系统与之相匹配、相耦合，以自动适应攻击的变化，从而
第六章信息安全管理 第一节信息安全管理概述 一、信息安全管理的内容 1、什么信息安全管理？ 通过计划、组织、领导、控制等环节来协调人力、物力、财力等资源，以期有效达到组织信息安全目标的活动。 2、信息安全管理的主要活动 制定信息安全目标和寻找实现目标的途径； 建设信息安全组织机构，设置岗位、配置人员并分配职责； 实施信息安全风险评估和管理；制定并实施信息安全策略； 为实现信息安全目标提供资源并实施管理； 信息安全的教育与培训；信息安全事故管理；信息安全的持续改进。 3、信息安全管理的基本任务 （1）组织机构建设（2）风险评估（3）信息安全策略的制定和实施 （4）信息安全工程项目管理（5）资源管理 ◆（1）组织机构建设 ★组织应建立专门信息安全组织机构，负责： ①确定信息安全要求和目标；②制定实现信息安全目标的时间表和预算 ③建立各级信息安全组织机构和设置相应岗位④分配相应职责和建立奖惩制度 ⑤提出信息安全年度预算，并监督预算的执行⑥组织实施信息安全风险评估并监督检查 ⑦组织制定和实施信息安全策略，并对其有效性和效果进行监督检查 ⑧组织实施信息安全工程项目⑨信息安全事件的调查和处理 ⑩组织实施信息安全教育培训⑾组织信息安全审核和持续改进工作 ★组织应设立信息安全总负责人岗位，负责： ①向组织最高管理者负责并报告工作②执行信息安全组织机构的决定 ③提出信息安全年度工作计划④总协调、联络 ◆（2）风险评估 ★信息系统的安全风险 信息系统的安全风险，是指由于系统存在的脆弱性，人为或自然的威胁导致安全事件发生的可能性及其造成的影响。 ★信息安全风险评估 是指依据国家有关信息技术标准，对信息系统及由其处理、传输和存储的信息的保密性、完整性和可用性等安全属性进行科学评价的过程 它要评估信息系统的脆弱性、信息系统面临的威胁以及脆弱性被威胁源利用后所产生的实际负面影响，并根据安全事件发生的可能性和负面影响的程度来识别信息系统的安全风险。 ★信息系统安全风险评估的总体目标是： 服务于国家信息化发展，促进信息安全保障体系的建设，提高信息系统的安全保护能力。★信息系统安全风险评估的目的是： 认清信息安全环境、信息安全状况；有助于达成共识，明确责任；采取或完善安全保障措施，使其更加经济有效，并使信息安全策略保持一致性和持续性。 ★信息安全风险评估的基本要素 使命：一个单位通过信息化实现的工作任务。 依赖度：一个单位的使命对信息系统和信息的依靠程度。