CISSP备考终极指南：关键小时学习

需积分: 10 161 浏览量更新于2024-07-18 收藏 1.71MB PDF 举报

"Eleventh Hour CISSP Study Guide" 是一本专门为准备CISSP（Certified Information Systems Security Professional）认证考试的人士编写的备考手册。该书由Eric Conrad作为主要作者，Seth Misenar和Joshua Feldman作为贡献作者，Kevin Riggins担任技术编辑。此书属于Syngress出版社的Eleventh Hour系列，旨在帮助考生在考试前的关键时刻高效复习。 CISSP是信息安全领域的一个权威认证，它涵盖了多个关键领域，包括安全与风险管理、资产安全、安全工程、通信与网络安全、身份与访问管理、安全评估与测试、软件开发安全以及运营安全。这本书的内容将深入这些领域，提供详尽的考试知识点和复习策略。书中可能包含以下关键知识点： 1. 安全与风险管理：涵盖风险评估、风险管理和缓解策略，以及业务连续性和灾难恢复计划。 2. 资产安全：讨论如何保护组织的信息资产，包括数据、硬件、软件和设施，以及相应的访问控制策略。 3. 安全工程：涉及安全设计原则，如最小权限原则，以及安全架构和生命周期管理。 4. 通信与网络安全：涵盖网络协议、加密技术、网络安全威胁和防御措施。 5. 身份与访问管理：讲解身份验证、授权和审计过程，以及多因素认证和单点登录系统。 6. 安全评估与测试：介绍安全审计、渗透测试和漏洞评估的方法和技术。 7. 软件开发安全：讨论软件开发生命周期中的安全实践，包括代码审查、安全测试和安全编程原则。 8. 运营安全：涵盖安全管理、事件响应、物理安全和操作安全监控。此外，书中可能还包含模拟试题、案例研究和实践建议，以帮助读者理解和应用这些概念，并为实际考试做好准备。对于打算获得CISSP认证的专业人士来说，这是一本非常实用的参考资料。

Domain 1: Information Security Governance CHAPTER 1

Accept the risk

Some risks may be accepted: In certain cases, it is cheaper to leave an asset unpro-

tected from a specific risk rather than make the effort (and spend the money)

required to protect it. This cannot be an ignorant decision: The risk, and all

options, must be considered before you can accept it.

Risk Acceptance Criteria

Low-likelihood/low-consequence risks are candidates for risk acceptance. High

and Extreme risks are not . There are cases, such as data protected by laws or regu-

lations or risk to human life or safety, where accepting the risk is not an option.

MitigAte the risk

Mitigating the risk means lowering it to an acceptable level. The laptop encryp-

tion example given previously in the Annualized Loss Expectancy section is an

example of risk mitigation. The risk of lost PII due to stolen laptops was miti-

gated by encrypting the data on them. It was not eliminated entirely: A weak or

exposed encryption password could expose the PII, but the risk was reduced to

an acceptable level.

In some cases it is possible to remove the risk entirely: this is called eliminating it.

trAnsFer the risk

Risk transfer is the “insurance model.” Most people do not assume the risk of fire

to their house: They pay an insurance company to assume that risk for them.

AVoid the risk

A thorough Risk Analysis should be completed before taking on a new project.

If it discovers high or extreme risks that cannot be easily mitigated, avoiding the

risk (and the project) may be the best option.

The math for this decision is straightforward: Calculate the Annualized Loss

Expectancy of the new project, and compare it with the Return on Investment

expected from the project. If the ALE is higher than the ROI (even after risk miti-

gation), risk avoidance is the best course. There may also be legal or regulatory

reasons that will dictate avoiding the risk.

Qualitative and Quantitative Risk Analysis

Quantitative and Qualitative Risk Analysis are two methods for analyzing risk.

Quantitative Risk Analysis uses hard metrics, such as dollars. Qualitative Risk

Analysis uses simple approximate values. Quantitative is more objective; quali-

tative is more subjective.

Exam Warning

Quantitative Risk Analysis requires you to calculate the quantity of the asset you are

protecting. “Quantitative-quantity” is a hint to remember on the exam.

8 Eleventh Hour CISSP® Study Guide

Calculating the Annualized Loss Expectancy (ALE) is an example of Quantitative

Risk Analysis. The inputs for ALE are hard numbers: Asset Value (in dollars),

Exposure Factor (as a percentage), and Annual Rate of Occurrence (as a hard

number).

The Risk Analysis Matrix (shown in Table 1.1) is an example of Qualitative Risk

Analysis. Likelihood and Consequences are rough (and sometimes subjective)

values, ranging from 1 to 5. Whether the consequences of a certain risk are a 4

or a 5 can be a matter of (subjective) debate.

Quantitative Risk Analysis is more difficult: To quantitatively analyze the risk of

damage to a data center due to an earthquake, you need to calculate the asset

value of the data center, such as the cost of the building, servers, network equip-

ment, computer racks, and monitors. Then you must calculate the Exposure

Factor and so on.

To qualitatively analyze the same risk, you research it and agree that the likeli-

hood is a 2 and the consequences are a 4, and use the Risk Analysis Matrix to

determine a risk of “high.”

The risk management process

Published by the National Institute of Standards and Technology (NIST), Special

Publication 800-30, Risk Management Guide for Information Technology

Systems (see: http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf), describes

a nine-step Risk Analysis process:

1. System Characterization

2. Threat Identification

3. Vulnerability Identification

4. Control Analysis

5. Likelihood Determination

6. Impact Analysis

7. Risk Determination

8. Control Recommendations

9. Results Documentation

We covered these steps individually; let’s end this section by following NIST’s

process.

Step 1, System Characterization, describes the scope of the risk management effort

and the systems that will be analyzed. Threat Identification and Vulnerability

Identification, Steps 2 and 3, identify the threats and vulnerabilities required to

determine risks using the “Risk = Threat × Vulnerability” formula.

Step 4, Control Analysis, analyzes the security controls (safeguards) in place or

planned to mitigate risk. Steps 5 and 6, Likelihood Determination and Impact

Analysis, identify important risks (especially those with high likelihood and

high impact/consequence).

Domain 1: Information Security Governance CHAPTER 1

Steps 1 through 7 are used to determine Control Recommendations, or the risk

mitigation strategy. That strategy is documented in Step 8, Results Documentation.

INFORMATION SECURITY GOVERNANCE

Information Security Governance is information security at the organizational

level: senior management, policies, processes, and staffing. It is also the organi-

zational priority, provided by senior leadership, that is required for a successful

information security program.

Security policy and related documents

Documents such as policies and procedures are a required part of any success-

ful information security program. These should be grounded in reality: They are

not idealistic documents that sit on shelves collecting dust, but should mirror

the real world and provide guidance on the correct (and sometimes required)

way of doing things.

policy

Policies are high-level management directives. Policy is mandatory: If you do

not agree with your company’s policy on sexual harassment, for example, you

do not have the option of not following it.

Components of Program Policy

All policy should contain these basic components:

n Purpose

n Scope

n Responsibilities

n Compliance

Purpose describes the need for the policy, typically to protect the confidenti-

ality, integrity, and availability of data.

Scope describes the systems, people, facilities, and organizations that are

covered by the policy. Any related entities that are not in scope should be

documented to avoid confusion.

Policy is high level: It does not delve into specifics. A server

security policy discusses protecting the confidentiality,

integrity, and availability of the system (usually in those

terms). It may discuss software updates and patching. It

does not use terms like “Linux” or “Windows”; these are

too low level. In fact, if you converted your servers from

Windows to Linux, your server policy would not change.

Other documents, like procedures, would change.

Crunch Time

10 Eleventh Hour CISSP® Study Guide

Responsibilities include those of the information security staff and policy and

management teams, as well as those of all members of the organization.

Compliance describes two related issues: how to judge the effectiveness of

the policies (how well they are working), and what happens when a policy is

violated (the sanction). All policy must have “teeth”: One that forbids access-

ing explicit content via the Internet is not useful if there are no consequences

for doing so.

Policy Types

The NIST Special Publication 800-12 (see http://csrc.nist.gov/publications/nistpubs/

800-12/800-12-html/chapter5.html) discusses three specific policy types: pro-

gram, issue-specific, and system-specific.

Program policy establishes an organization’s information security program.

Examples of issue-specific policies listed in NIST SP 800-12 include email and email

privacy. System-specific policy examples include file servers and web servers.

procedures

A procedure is a step-by-step guide for accomplishing a task. Procedures are

low-level and specific. Like policies, they are mandatory.

Here is a simple example of a procedure for creating a new user:

1. Receive a new-user request form and verify its completeness.

2. Verify that the user’s manager has signed the form.

3. Verify that the user has read and agreed to the user account security policy.

4. Classify the user’s role by following role-assignment procedure NX-103.

5. Verify that the user has selected a “secret word,” such” as mother’s maiden

name, and enter it into the help desk account profile.

6. Create the account and assign the proper role.

7. Assign the secret word as the initial password, and set “Force user to change

password on next login” to “True.”

8. Email the New-Account document to the user and his or her manager.

The steps in this procedure are mandatory. Security administrators do not have the

option of skipping Step 1, for example, and creating an account without a form.

DID YOU KNOW?

Other safeguards depend on the fact that procedures are mandatory: When a user

calls the help desk because of a forgotten password, the help desk follows its

“forgotten password” procedure, which includes asking for the user’s secret word. It

cannot do that unless Step 5 was completed: Without that word, the help desk cannot

securely reset the password. This mitigates social engineering attacks, in which an

imposter tries to trick the help desk into resetting a password for an account he or

she is not authorized to access.

Domain 1: Information Security Governance CHAPTER 1

stAndArds

A standard describes the specific use of technology, often applied to hardware

and software. “All employees will receive an ACME Nexus-6 laptop with 2 giga-

bytes of memory, a 2.8-GHZ duo core CPU, and 300-gigabyte disk” is an exam-

ple of a hardware standard. “The laptops will run Windows 7 Professional, 32-bit

version” is an example of a software (operating system) standard.

Standards are mandatory. They lower the Total Cost of Ownership of a safe-

guard. They also support disaster recovery, as recovering from disasters is easier

when standards are employed.

guidelines

Guidelines are recommendations (which are discretionary). They can include a

useful piece of advice, such as “To create a strong password, take the first letter

of every word in a sentence, and mix in some numbers and symbols. ‘I will pass

the CISSP exam in 6 months!’ becomes ‘Iwptcei6m!’”

You can create a strong password without following this advice, which is why

guidelines are not mandatory. They are useful, especially for novice users.

BAselines

Baselines are uniform ways of implementing a safeguard. An example is “Harden

the system by applying the Center for Internet Security Linux benchmarks” (see

www.cisecurity.org for the CISecurity benchmarks; they are a great resource). The

system must meet the baseline described by a benchmark.

Baselines are discretionary. It is acceptable to harden the system without follow-

ing the aforementioned benchmarks, as long as it is at least as secure as a system

hardened using the benchmarks.

Table 1.5 summarizes the types of security documentation.

Summary of Security Documentation

Document Example

Mandatory or

Discretionary?

Policy

Protect the CIA of PII by hardening the operating

system Mandatory

Procedure

Step 1: Install prehardened OS Image. Step 2:

Download patches from update server. Step 3: . . . Mandatory

Standard Use Nexus-6 laptop hardware Mandatory

Guideline

Patch installation may be automated via the use of

an installer script Discretionary

Baselines

Use the CISecurity Windows Hardening

benchmark Discretionary

Table 1.5

剩余204页未读，继续阅读

sd886393

粉丝: 0
资源: 3

CISSP备考终极指南：关键小时学习

Eleventh Hour Study Guide (Third Edition)

Eleventh Hour CISSP Study Guide Second Edition

Java - The complete reference - Eleventh edition

eleventh:将本地开发的Lambda函数同步到AWS Lambda

蓝桥杯嵌入式第十一界the-eleventh-competition.rar

javael源码-Java-The-Complete-Reference-Eleventh-Edition-source-code-:Java

eleventh:CRUD应用程序，用于在React.js，Node.js，MSSQL中对用户数据进行计费

Summary-of-Java-The-Complete-Reference-Eleventh-Edition:我试图对Java有了扎实的了解，并且偶然发现了Herbert Schildt撰写的这本很棒的书

Kramer, J. J., & Conoley, J. C. (Eds.). (1992). The Eleventh Mental Measurements yearbook. Lincoln, NE: The University of Nebraska Press, 1,183 pp., [dollar]125.00

模拟电子技术(第二版) [electronic devices and circuit theory, eleventh ed] pd

最新资源