Cissp - Security Assessment And Testing

Front 1

Service organizations

Back 1

are organizations that provide outsourcing services that can directly impact the control environment of a company’s customers.

Front 2

Service Organization Control (SOC)

Back 2

are internal control reports on the services provided by a service organization providing valuable information that users need to assess and address the risks associated with an outsourced service.

Front 3

SOC 1

Back 3

Pertains to financial controls

Front 4

SOC 2

Back 4

Pertains to trust services (Security, Availability, Confidentiality, Process Integrity, and Privacy)

Front 5

SOC 3

Back 5

Also pertains to trust services (Security, Availability, Confidentiality, Process Integrity, and Privacy)

Front 6

The difference between SOC 2 and 3

Back 6

is that the resulting SOC 2 report provides very detailed data pertaining to the controls that provide the listed trust services, which is not for the general public. SOC 3 results in a report that has less detail and can be used for general purposes.

Front 7

technical control

Back 7

is a security control implemented through the use of an IT asset.

Front 8

Penetration testers use the following methodology:

Back 8

• Planning

• Reconnaissance

• Scanning (also called enumeration)

• Vulnerability assessment

• Exploitation

• Reporting

Front 9

Vulnerability scanning

Back 9

scans a network or system for a list of predefined vulnerabilities such as system misconfiguration, outdated software, or a lack of patching.

Front 10

A security audit

Back 10

is a test against a published standard.

Front 11

Security assessments

Back 11

are a holistic approach to assessing the effectiveness of access control. Instead of looking narrowly at penetration tests or vulnerability assessments, security assessments have a broader scope.

Front 12

Security assessments view many controls across multiple domains, and may include the following:

Back 12

• Policies, procedures, and other administrative controls

• Assessing the real world-effectiveness of administrative controls

• Change management

• Architectural review

• Penetration tests

• Vulnerability assessments

• Security audits

Front 13

The goals of the assessment are to

Back 13

• Evaluate the true security posture of an environment

* Identify as many vulnerabilities as possible, with honest evaluations and prioritizations of each.

• Test how systems react to certain circumstances and attacks, to learn not only what the known vulnerabilities are (such as this version of the database, that version of the operating system, or a user ID with no password set), but also how the unique elements of the environment might be abused (SQL injection attacks, buffer overflows, and process design flaws that facilitate social engineering).

• Before the scope of the test is decided and agreed upon, the tester must explain the testing ramifications. Vulnerable systems could be knocked offline by some of the tests, and production could be negatively affected by the loads the tests place on the systems.

Front 14

Personnel testing

Back 14

includes reviewing employee tasks and thus identifying vulnerabilities in the standard practices and procedures that employees are instructed to follow, demonstrating social engineering attacks and the value of training users to detect and resist such attacks, and reviewing employee policies and procedures to ensure those security risks that cannot be reduced through physical and logical controls are met with the final control category: administrative.

Front 15

Physical testing

Back 15

includes reviewing facility and perimeter protection mechanisms.

Front 16

System and network testing

Back 16

are perhaps what most people think of when discussing information security vulnerability testing. For efficiency, an automated scanning product identifies known system vulnerabilities, and some may (if management has signed off on the performance impact and the risk of disruption) attempt to exploit vulnerabilities.

Front 17

Black box testing

Back 17

This means that the tester has no a priori knowledge of the internal design or features of the system. All knowledge will come to the tester only through the assessment itself.

Front 18

White box testing

Back 18

affords the auditor complete knowledge of the inner workings of the system even before the first scan is performed. This approach allows the test team to target specific internal controls and features and should yield a more complete assessment of the system.

Front 19

Gray box testing

Back 19

meets somewhere between the other two approaches. Some, but not all, information on the internal workings is provided to the test team. This helps guide their tactics toward areas we want to have thoroughly tested, while also allowing for a degree of realism in terms of discovering other features of the system. This approach mitigates the issues with both white and black box testing.

Front 20

Penetration testing

Back 20

is the process of simulating attacks on a network and its systems at the request of the owner, senior management. A penetration test emulates the same methods attackers would use.

Front 21

Vulnerability scanners provide the following capabilities:

Back 21

• The identification of active hosts on the network

• The identification of active and vulnerable services (ports) on hosts

• The identification of applications and banner grabbing

• The identification of operating systems

• The identification of vulnerabilities associated with discovered operating systems and applications

• The identification of misconfigured settings

• Test for compliance with host applications’ usage/security policies

• The establishment of a foundation for penetration testing

Front 22

When performing a penetration test, the team goes through a five-step process:

Back 22

1. Discovery Footprinting and gathering information about the target

2. Enumeration Performing port scans and resource identification methods

3. Vulnerability mapping Identifying vulnerabilities in identified systems and resources

4. Exploitation Attempting to gain unauthorized access by exploiting vulnerabilities

5. Report to management Delivering to management documentation of test findings along with suggested countermeasures

Front 23

The penetration testing team can have varying degrees of knowledge about the penetration target before the tests are actually carried out:

Back 23

• Zero knowledge The team does not have any knowledge of the target and must start from ground zero.

• Partial knowledge The team has some information about the target.

• Full knowledge The team has intimate knowledge of the target.

Front 24

A blind test

Back 24

is one in which the assessors only have publicly available data to work with. The network security staff is aware that this type of test will take place.

Front 25

A double-blind test

Back 25

is also a blind test to the assessors, as mentioned previously, but in this case the network security staff is not notified. This enables the test to evaluate the network’s security level and the staff’s responses, log monitoring, and escalation processes, and is a more realistic demonstration of the likely success or failure of an attack.

Front 26

War Dialing

Back 26

allows attackers and administrators to dial large blocks of phone numbers in search of available modems.

Front 27

Log Reviews

Back 27

A log review is the examination of system log files to detect security events or to verify the effectiveness of security controls.

Front 28

Misuse Case Testing

Back 28

is a use case that includes threat actors and the tasks they want to perform on the system. The idea behind misuse case testing is to ensure we have effectively addressed each of the risks we identified and decided to mitigate during our risk management process and that are applicable to the system under consideration.

Front 29

code review

Back 29

a systematic examination of the instructions that comprise a piece of software, performed by someone other than the author of that code.

Front 30

Interface testing

Back 30

is performed to evaluate whether systems or components pass data and control correctly to one another. It is to verify if all the interactions between these modules are working properly and errors are handled properly.

Front 31

privilege accumulation

Back 31

Over time, most employees and some contractors move from job to job. As employee responsibilities change, so do their required access to systems and applications.

Front 32

Checklist Test

Back 32

In this type of test, copies of the DRP or BCP are distributed to the different departments and functional areas for review. This enables each functional manager to review the plan and indicate if anything has been left out or if some approaches should be modified or deleted. This method ensures that nothing is taken for granted or omitted, as might be the case in a single-department review.

Front 33

Simulation Test

Back 33

This type of test takes a lot more planning and people. In this situation, all employees who participate in operational and support functions, or their representatives, come together to practice executing the disaster recovery plan based on a specific scenario.

Front 34

Parallel Test

Back 34

In a parallel test, some systems are moved to the alternate site and processing takes place. The results are compared with the regular processing that is done at the original site. This ensures that the specific systems can actually perform adequately at the alternate offsite facility, and points out any tweaking or reconfiguring that is necessary.

Front 35

Full-Interruption Test

Back 35

This type of test is the most intrusive to regular operations and business productivity. The original site is actually shut down, and processing takes place at the alternate site.

Front 36

Security training

Back 36

is the process of teaching a skill or set of skills that will allow people to perform specific functions better.

Front 37

Security awareness training

Back 37

is the process of exposing people to security issues so that they may be able to recognize them and better respond to them.

Front 38

Pretexting

Back 38

is a form of social engineering, typically practiced in person or over the phone, in which the attacker invents a believable scenario in an effort to persuade the target to violate a security policy.

Front 39

key performance indicator (KPI)

Back 39

is an indicator that is particularly significant in showing the performance of an ISMS. KPIs are carefully chosen from among a larger pool of indicators to show at a high level whether our ISMS is keeping pace with the threats to our organization or showing decreased effectiveness.

Front 40

An SAS 70 audit

Back 40

is carried out by a third party to assess the internal controls of a service organization.

Front 41

Synthetic transactions

Back 41

are scripted events that mimic the behaviors of real users and allow security professionals to systematically test the performance of critical services.

Front 42

Key risk indicators (KRIs)

Back 42

measure the risk inherent in performing a given action or set of actions.

Front 43

Static testing

Back 43

tests the code passively; the code is not running. This includes walkthroughs, syntax checking, and code reviews. Static analysis tools review the raw source code itself looking for evidence of known insecure practices, functions, libraries, or other characteristics having been used in the source code.

Front 44

Dynamic testing

Back 44

tests the code while executing it. With dynamic testing, security checks are performed while actually running or executing the code or application under review.

Front 45

Traceability Matrix

Back 45

sometimes called a Requirements Traceability Matrix, or RTM) can be used to map customers’ requirements to the software testing plan: it “traces” the “requirements,” and ensures that they are being met.

Front 46

Unit Testing:

Back 46

Low-level tests of software components, such as functions, procedures or objects

Front 47

Installation Testing

Back 47

Testing software as it is installed and first operated

Front 48

Integration Testing

Back 48

Testing multiple software components as they are combined into a working system. Subsets may be tested, or Big Bang integration testing tests all integrated software components

Front 49

Regression Testing

Back 49

Testing software after updates, modifications, or patches

Front 50

Acceptance Testing

Back 50

testing to ensure the software meets the customer’s operational requirements. When this testing is done directly by the customer, it is called User Acceptance Testing.

Front 51

Fuzzing

Back 51

is a type of black box testing that submits random, malformed data as inputs into software programs to determine if they will crash. is typically automated, repeatedly presenting random input strings as command line switches, environment variables, and program inputs. Any program that crashes or hangs has failed the fuzz test. can be considered a particular type of dynamic testing.

Front 52

Combinatorial software testing

Back 52

is a black-box testing method that seeks to identify and test all unique combinations of software inputs.

Front 53

TEST COVERAGE ANALYSIS

Back 53

Test or code coverage analysis attempts to identify the degree to which code testing applies to the entire application. The goal is to ensure there are no significant gaps where a lack of testing could allow for bugs or security issues to be present that otherwise should have been discovered.