CSSLP CIB.pdf

1

© 2015 International Information Systems Security Certification Consortium, Inc. All Rights Reserved. Duplication for commercial

purposes is prohibited. 8.20.15, V11

Effective Date: April 2013

(Exam Outline)


April 2013

2




Impartiality Statement (ISC)² is committed to impartiality by promoting a bias and discrimination free environment for

all members, candidates, staff, volunteers, subcontractors, vendors, and clients. (ISC)²’s board

of directors, management and staff understand the importance of impartiality in carrying out its

certification activities, manage conflict of interest and ensure the objectivity of its certification.

If you feel you have not received impartial treatment, please send an email to [email protected]

or call +1.727.785.0189, so that we can investigate your claim.

Non-Discrimination Policy (ISC)² is an equal opportunity employer and does not allow, condone or support discrimination

of any type within its organization including, but not limited to, its activities, programs, practices,

procedures, or vendor relationships. This policy applies to (ISC)² employees, members,

candidates, and supporters.

Whether participating in an (ISC)² official event or certification examination as an employee,

candidate, member, staff, volunteer, subcontractor, vendor, or client if you feel you have been

discriminated against based on nationality, religion, sexual orientation, race, gender, disability,

age, marital status or military status, please send an email to [email protected] or call

+1.727.785.0189, so that we can investigate your claim.

For any questions related to these polices, please contact the (ISC)² Legal Department

at [email protected].

April 2013

3




1) SECURE SOFTWARE CONCEPTS .................................................................................................. 6

Overview ................................................................................................................................................. 6

Key Areas of Knowledge .................................................................................................................... 6

2) SECURE SOFTWARE REQUIREMENTS ........................................................................................... 8

Overview ................................................................................................................................................. 8

Key Areas of Knowledge .................................................................................................................... 8

3) SECURE SOFTWARE DESIGN ......................................................................................................... 9

Overview ................................................................................................................................................. 9

Key Areas of Knowledge .................................................................................................................. 10

4) SECURE SOFTWARE IMPLEMENTATION/CODING ................................................................. 12

Overview ............................................................................................................................................... 12


5) SECURE SOFTWARE TESTING....................................................................................................... 14

Overview ............................................................................................................................................... 14


6) SOFTWARE ACCEPTANCE .......................................................................................................... 16

Overview ............................................................................................................................................... 16


7) SOFTWARE DEPLOYMENT, OPERATIONS, ................................................................................ 17

MAINTENANCE AND DISPOSAL ........................................................................................................... 17

Overview ............................................................................................................................................... 17


8) SUPPLY CHAIN AND SOFTWARE ACQUISITION ..................................................................... 18

Overview ............................................................................................................................................... 18


SAMPLE EXAM QUESTIONS .................................................................................................................... 27

GENERAL EXAMINATION INFORMATION ........................................................................................... 28

Computer Based Test (CBT) ................................................................................................................. 28

Registering for the Exam ....................................................................................................................... 28

4




Day of the Exam ...................................................................................................................................... 33

Any questions? ......................................................................................................................................... 37

5




CSSLPs are professionals who demonstrate a globally recognized level of competence, as

defined in a common body of knowledge by assuring security throughout the software lifecycle.

They incorporate security when planning, designing, developing, acquiring, testing, deploying,

maintaining, and/or managing software to increase its trustworthiness.

This Candidate Information Bulletin provides the following:

• Exam blueprint to a limited level of detail that outlines major topics and sub- topics

within the domains • Suggested reference list • Description of the format of the items on the exam • Basic registration/administration policies • General Exam Information – for computer based testing and paper based testing.

Candidates should review this section accordingly.

Eligibility Requirement:

• A candidate is required to have a minimum of four years of cumulative paid full-time

Software Development Lifecycle (SDLC) professional work experience in one or more of the

eight domains of the (ISC)²® CSSLP CBK®. Or three- years of cumulative paid full-time SDLC

professional work experience in one or more of the eight domains of the CSSLP CBK® with a

four-year degree leading to a Baccalaureate, or regional equivalent in Computer Science,

Information Technology (IT) or related fields. Only one year experience exemption is granted

for education.

• Before candidates are allowed to take the test at testing centers, they must respond “yes”

or “No” to the following four questions regarding criminal history and related background:

1. Have you ever been convicted of a felony; a misdemeanor involving a computer

crime, dishonesty, or repeat offenses; or a Court Martial in military service, or is there a

felony charge, indictment, or information now pending against you? (Omit minor

traffic violations and offenses prosecuted in juvenile court).

2. Have you ever had a professional license, certification, membership or registration

revoked, or have you ever been censured or disciplined by any professional

organization or government agency?

3. Have you ever been involved, or publicly identified, with criminal hackers or

hacking?

4. Have you ever been known by any other name, alias, or pseudonym? (You need not

include user identities or screen names with which you were publicly identified).

CSSLP professional experience includes:

software developers

engineers and architects

product managers

project managers

software QA

QA testers

business analysts

professionals who manage these

stakeholders

6




1) SECURE SOFTWARE CONCEPTS

Overview

The Secure Software Concepts domain covers the mechanisms that permit managers of a

software system to exercise a directing or restraining influence over the behavior, use, and

content of the system. These Concepts permit management to specify what users can do, which

resources managers can access, and what operations they can perform on a system.

The candidate should fully understand secure software concepts, methodologies and

implementation within centralized and decentralized environments across the enterprise's

computer systems. Security design principles, detective and corrective measures should be

studied by candidates to understand the potential risks, vulnerabilities, and exposures.

Key Areas of Knowledge

1.A. Core Concepts

1.A.1 Confidentiality 1.A.2 Integrity (e.g., reliability, alterations, authenticity) 1.A.3 Availability 1.A.4 Authentication 1.A.5 Authorization 1.A.6 Accounting 1.A.7 Nonrepudiation

1.B. Security Design Principles

1.B.1 Least Privilege 1.B.2 Separation of Duties 1.B.3 Defense in Depth 1.B.4 Fail Safe 1.B.5 Economy of Mechanism 1.B.6 Complete Mediation 1.B.7 Open Design 1.B.8 Least Common Mechanism 1.B.9 Psychological Acceptability 1.B.10 Weakest Link

7




1.B.11 Leveraging Existing Components

1.C. Privacy (e.g., data anonymization, user consent, disposition, test data

management)

1.D. Governance, Risk and Compliance (GRC)

D.1 Regulations and compliance D.2 Legal (e.g., intellectual property, breach notification) D.3 Standards (e.g., ISO, PCI, NIST)

D.4 Risk Management

1.E. Software Development Methodologies (e.g., Waterfall, Agile)

8




2) SECURE SOFTWARE REQUIREMENTS

Overview

The Secure Software Requirements domain covers the controls used during the requirements

phase of the Software Development Lifecycle to integrate security into the software

development process, to identify key security objectives, and to maximize software security while

minimizing disruption to plans and schedules.

The candidate should fully understand the security and controls required during the requirements

gathering phase of the Secure Software Development Lifecycle. The concepts that a candidate

is expected to understand include policy decomposition and identification and gathering of

data including the capturing of use and abuse cases.


2. D. Operational Requirements (e.g., how the software is deployed, operated,

managed)

2.A. Policy Decomposition (e.g., Internal and External Requirements)

2.B. Data Classification and Categorization

2.B.1 Data Ownership (e.g., data owner, data custodian)

2.B.2 Labeling (e.g., sensitivity, impact)

2.B.3 Types of Data (e.g., structured, unstructured data)

2.B.4 Data life-cycle (e.g., generation, retention, disposal)

2.C. Functional Requirements (e.g., Use Cases and Abuse Cases)

2.C.1 Role and user definitions (who)

2.C.2 Deployment environment (where)

2.C.3 Object (what)

2.C.4 Activities/actions (how)

2.C.5 Sequencing and timing (when)

9




3) SECURE SOFTWARE DESIGN

Overview

The Secure Software Design domain addresses the definition of the overall structure of the

software from a security perspective, documenting the elements of the software attack surface,

conducting threat modeling, and defining any specific security criteria that must be met before

the software is released.

Defining the overall structure of the software from a security perspective entails identifying those

components whose correct functioning is essential to security and identifying design techniques

that will assure its security.

Measuring the elements of the attack surface provides the product team for an ongoing metric

for default security and enables them to detect instances where the software has been made

more susceptible to attack.

The threat modeling process identifies threats that can do harm to each asset and provides an

estimate of the risk of the harm being done, thereby helping the product team identify the needs

for security features as well as areas where especially careful code review and security testing

are required.

Specific security criteria may apply to individual product teams or software releases that may

have additional security criteria above and beyond the basic security ship criteria.

The candidate is expected to know the techniques of performing attack surface analysis and

conducting threat modeling and must have the ability to identify and review the

countermeasures that mitigate the risk – either in the form of security features such as encryption,

or in the form of proper functioning of the software that protects the assets from harm. The

candidate is expected to understand the design considerations, architecture and technologies

required to implement secure software design.

10





3.A. Design Processes

3.A.1 Attack surface evaluation 3.A.2 Threat modeling (e.g., APT, insider threat, common malware, third

party/supplier) 3.A.3

A.3 Control identification and prioritization

3.A.4 A.4

Documentation 3.A.5 Design and architecture technical review (e.g., reviewing interface points

and deployment diagram, walk-throughs to verify requirements) 3.A.6 Risk Assessment for Code Reuse

3.B. Design Considerations

3.B.1 Application of Methods to Address Core Security Concepts

3.B.2 Security Design Principles

3.B.3 Interconnectivity

3.B.4 Interfaces (e.g., security management interfaces, out-of-band

management, log interfaces)

3.C. Securing Commonly Used Architecture

3.C.1 Distributed computing (e.g., client server, peer-to-peer, message queuing)

3.C.2 Service-oriented architecture (e.g., enterprise service bus, web services)

3.C.3 Rich Internet applications (e.g., client side exploits or threats, remote code

execution, constant connectivity)

3.C.4 Pervasive/Ubiquitous computing (e.g., wireless, location-based, RFID, near

field communication, sensor networks)

3.C.5 Integration with existing architectures

3.C.6 Cloud Architectures (e.g., software as a service, platform as a service,

infrastructure as a service)

3.C.7 Mobile applications

3.D. Technologies

3.D.1 Authentication and Identity Management

3.D.2 Credential management (e.g., X.509 and SSO)

3.D.3 Flow control (e.g., proxies, firewalls, middleware, message queuing)

3.D.4 Logging (e.g., application event logs, syslog)

3.D.5 Data Loss Prevention (DLP)

3.D.6 Virtualization

3.D.7 Digital Rights Management (DRM)

3.D.8 Trusted Computing (e.g., TPM, TCB, malware, code signing)

11




3.D.9 Database security (e.g., encryption, triggers, views, privilege management)

3.D.10 Programming Language Environment (e.g., CLR, JVM, compiler switches,

sandboxing)

D.11 Operating Systems

D.12 Embedded systems (e.g., control systems, firmware)

12




4) SECURE SOFTWARE IMPLEMENTATION/CODING

Overview

The Secure Software Implementation/Coding domain involves the application of coding and

testing standards, applying security testing tools including “fuzzing”, static-analysis code scanning

tools, and conducting code reviews.

The candidate is expected to know the coding standards that help developers avoid introducing

flaws that can lead to security vulnerabilities. Testing standards and best practices help to ensure

that testing focuses on detecting potential security vulnerabilities rather than concentrating only

on correct operation of software functions and features.

The candidate is expected to know the common software vulnerabilities and countermeasures

and applying security testing tools including fuzzing tools that provide structured but invalid inputs

to software application programming interfaces (APIs) and network interfaces so as to maximize

the likelihood of detecting errors that may lead to software vulnerabilities.

The candidate should familiarize with conducting code reviews supplemented by automated

tools to examine the source code and detect and remove potential security vulnerabilities.

The candidate is expected to know the security issues encountered in exception management,

configuration management, build environment and interface coding.

13





4.A. Declarative versus Imperative (Programmatic) Security

4.B. Vulnerability Databases/Lists (e.g., OWASP Top 10, CWE)

4.C. Defensive Coding Practices and Controls

4.C.1 Concurrency

4.C.2 Configuration

4.C.3 Cryptography

4.C.4 Output Sanitization (e.g., Encoding)

4.C.5 Error Handling

4.C.6 Input Validation

4.C.7 Logging & Auditing

4.C.8 Session Management

4.C.9 Exception management

4.C.10 Safe APIs

4.C.11 Type Safety

4.C.12 Memory Management (e.g., locality, garbage collection)

4.C.13 Configuration Parameter Management (e.g., start-up variables,

cryptographic agility)

4.C.14 Tokenizing

4.C.15 Sandboxing

4.D. Source Code and Versioning

4.E. Development and Build environment (e.g., build tools, automatic build script)

4.F. Code/Peer Review

4.G. Code Analysis (e.g., static, dynamic)

4.H. Anti-tampering Techniques (e.g., code signing, obfuscation)

14




5) SECURE SOFTWARE TESTING

Overview The Secure Software Testing domain refers to the phase in the secure software development

lifecycle where the software is functionally complete and ready to enter user beta testing. The

goal of Secure Software Testing phase is to determine if the final software meets the requirements.

The candidate should be familiar with standards for software quality assurance and know the

impact assessment and corrective action procedures when security issues are encountered.

The candidate is expected to understand the concepts of functional and security testing (both

white and black box), interoperability testing, bug tracking, and the testing of high priority code

(code that is part of the “attack surface” for the software).

The candidate should be familiar with different types of testing such as penetration testing,

fuzzing, scanning, simulation testing, testing for failure and cryptographic validation and the

methods and processes to make sure that bug fixes will not regress the baseline releases of the

code.

15





5.A. Testing Artifacts (e.g., strategies, plans, cases)

5.B. Testing for Security and Quality Assurance

5.B.1 Functional Testing (e.g., logic) 5.B.2 Nonfunctional Testing (e.g., reliability, performance, scalability) 5.B.3 Security Testing (e.g., white box and black box) 5.B.4 Environment (e.g., interoperability, test harness) 5.B.5 Bug tracking (e.g., defects, errors and vulnerabilities) 5.B.6 Attack surface validation 5.B.7 Standards (e.g., ISO, OSSTMM, SEI)

5.C. Types of Testing

5.C.1 Penetration 5.C.2 Fuzzing (e.g., generated, mutated) 5.C.3 Scanning (e.g., vulnerability, content, privacy) 5.C.4 Simulation (e.g., environment and data) 5.C.5 Failure (e.g., fault injection, stress testing, break testing) 5.C.6 Cryptographic validation (e.g., PRNG) 5.C.7 Regression 5.C.8 Continuous (e.g., synthetic transactions)

5.D. Impact Assessment and Corrective Action

5.E. Test Data Lifecycle Management (e.g., privacy, dummy data, referential

integrity)

16




6) SOFTWARE ACCEPTANCE

Overview

The Software Acceptance domain covers the content in determining if the software is ready to

deliver to customers from a security viewpoint. The domain provides an overall picture of the

security posture of the software and the likelihood that it will be able to withstand attack after the

software has been released to customers.

This domain also includes the post-release validation and verification (e.g., Common Criteria

testing) and an independent review of the software conducted by a third-party or by a central

security team of the organization.

The candidate is expected to know the methods for determining completion criteria, risk

acceptance and documentation (e.g., Disaster Recovery and Business Continuity Plans),

Common Criteria and methods of independent testing.


6.A. Pre-release and pre-deployment

6.A.1 Completion Criteria (e.g., documentation, DRP, BCP) 6.A.2 Risk Acceptance (e.g., exception policy, sign-off)

6.B. Post-release

6.B.1 Validation and Verification (e.g., FIPS, common criteria) 6.B.2 Independent Testing (e.g., third party)

17




7) SOFTWARE DEPLOYMENT, OPERATIONS,

MAINTENANCE AND DISPOSAL

Overview

The Software Deployment, Operations, Maintenance and Disposal domain deals with the

vulnerabilities that have not been eliminated from the software as shipped as well as new attacks

that would be discovered after the software has been shipped, and when software that was

“secure” would be found to be vulnerable. The objective in this domain is to learn from errors and

to use the information provided in vulnerability reports to help detect and eliminate further

vulnerabilities before they are discovered in the field and used to put customers at risk. The

problem management process also helps the product team and the security team adapt

processes so that similar errors are not introduced in the future.

The candidate is expected to know how to evaluate reports of vulnerabilities and release security

advisories and updates when appropriate. The candidate must be able to conduct a post-

mortem of reported vulnerabilities and taking action as necessary. The candidate should be

familiar with the procedures and security measures that must be taken when a product reaches

its end of life.


7.A. Installation and Deployment

7.A.1 Bootstrapping (e.g., key generation, access, management)

7.A.2 Configuration Management (e.g., elevated privileges, hardening, platform

change) 7.A.3 Release Management (e.g., version control)

7.B. Operations and Maintenance

7.B.1 Monitoring (e.g., metrics, audits, SLA)

7.B.2 Incident Management

7.B.3 Problem Management (e.g., root cause analysis, vulnerability tracking, user

support) 7.B.4 Change Management (e.g., patching)

7.B.5 Backup, Recovery and Archiving (e.g., retention cycles)

7.C. Software Disposal (e.g., retirement, end of life policies, decommissioning)

18




8) SUPPLY CHAIN AND SOFTWARE ACQUISITION

Overview

The Supply Chain and Software Acquisition domain provides a holistic outline of the knowledge

and tasks required by a CSSLP candidate in managing risk for outsourced development,

acquisition, and procurement of software and related services (e.g., Cloud Computing, Mobile

Application development). This domain defines the expectations of an organization when

acquiring software such that it can be assured that a product will not act maliciously, whether

intended or not, nor disrupt its business and result in negative financial impact.

Key elements that a CSSLP candidate should understand pertaining to supplier risk are the

legalities surrounding the use and reuse of open source libraries and the security vulnerabilities

that may or may not exist in the code. When outsourcing development, a CSSLP candidate

applies his/her knowledge of the secure Software Development Life Cycle (SDLC) and uses that

as a baseline process from which a supplier is evaluated. In particular by providing

documented assurances that technical security controls are built-in starting with: requirements,

then design, test, and finally operations and maintenance.

The concepts and tasks contained in this domain represent a collimation of the secure SDLC

that is applied at an arm’s length to a third-party provider of a service or a product and

enforced through legal instruments. The candidate is expected to know how-to establish a

process for interacting with suppliers on issues such as: vulnerability management, service level

agreement monitoring, and chain of custody throughout the source code development and

maintenance life cycle.

19





8.A. Supplier Risk Assessment (e.g., managing the enterprise risk of outsourcing)

8.A.1 Risk Assessment for Code Reuse

8.A.2 Intellectual Property (e.g., Open Source License, Closed Source License, Third

Party Proprietary) 8.A.3 Legal Compliance

8.A.4 Supplier Pre-Qualification (e.g., assessment of software engineering/SDLC

approaches, information systems security policy compliance)

8.B. Supplier Sourcing

8.B.1 Contractual integrity controls (e.g., audit of security policy compliance,

vulnerability/incident response) 8.B.2 Vendor technical integrity controls for third-party suppliers (e.g. secure transfer,

system sharing/interconnections, secure storage, code exchange) 8.B.3 Managed Services (e.g., cloud, outsourcing)

8.B.4 Service-Level Agreements (SLA’s) (e.g., monitoring plans, KPIs, performance

metrics, targets)

8.C. Software Development and Test

8.C.1 Technical Controls (e.g., code repository security, build environment security)

8.C.2 Code Testing and Verification (e.g., backdoor detection, embedded

malware detection) 8.C.3 Security Testing Controls (e.g., peer review, secure code review)

8.C.4 Software Requirements Verification and Validation

8.D. Software Delivery, Operations and Maintenance

8.D.1 Chain of Custody (e.g., each change and transfer made during the source

codes lifetime is authorized, transparent and verifiable). 8.D.2 Publishing and dissemination controls (e.g., code signing, delivery, transfer,

tamper resistance) 8.D.3 Systems-of-Systems integration (e.g., security testing and analysis)

8.D.4 Software Authenticity and Integrity (e.g., cryptographically hashed, digitally

signed components, software integrity is verified at run-time) 8.D.5 Product deployment and sustainment controls (e.g., upgrades, secure

configuration, custom code extension, operational readiness) 8.D.6 Monitoring and Incident Management (e.g., supplier, components, SLAs,

IDS/IPS) 8.D.7 Vulnerability Management, Tracking and Resolution (e.g., patching)

8.E. Supplier Transitioning (e.g., code escrow, data exports, contracts, disclosure)

20




REFERENCES

(ISC)²® does not intend that candidates purchase and read all of the books and articles listed in

this reference list. Since most of the information tested in the examination pertains to a common

body of knowledge, this additional information serves only as a supplement to one's

understanding of basic knowledge. A reference list is not intended to be inclusive but is provided

to allow flexibility. The candidate is encouraged to supplement his or her education and

experience by reviewing other resources and finding information in areas which he or she may

consider himself or herself not as skilled or experienced. (ISC)² does not endorse any particular

text or author. Although the list may include more than one reference that covers a content

area, one such reference may be enough. The candidate may also have resources available

that are not on the list but which will adequately cover the content area. The list does not

represent the only body of information to be used as study material.

Questions in the examination are also developed from information gained through practical

experience. This reference list is not intended to be all-inclusive, but rather, a useful list of

references used to support the test question development process. Use of the references does

not guarantee successful completion of the test.

On the next page is the suggested reference list:

21




Domain Supplementary Reference (ISC)2, Code of Ethics (https://www.isc2.org/ethics/default.aspx)

SECURE SOFTWARE CONCEPTS

Cannon, J.C., (2004). Privacy: What Developers and IT Professionals Should Know

Chess, B., McGraw, G., Migues, S., (2011). The Building Security In Maturity Model (BSIMM3)

Eeles, P., P. Cripps, (2009). The Process of Software Architecting

Howard, M., D. LeBlanc, (2003). Writing Secure Code (2nd Edition)

Howard, M., S. Lipner, (2006). The Security Development Lifecycle

ISO/IEC 15026: 2011, Systems and Software Engineering -- Systems and Software Assurance

ISO/IEC 27005:2008, Information Technology -- Security techniques -- Information Security Risk Management

National Institute of Standards and Technology (NIST)1. 1) FIPS-197, Advanced Encryption Standard, 2) FIP-186-3, Digital Signature Standard (DSS), 3) FIPS-180-4, Secure Hash Standard (SHS), 4) FIPS-140-2, Security Requirements for Cryptographic Modules, 5) SP 800-95, Guide to Secure Web Services, 6) SP 800-92, Guide to Computer Security Log Management, 7) SP 800-64 Rev. 2, Security Considerations in the System Development Life Cycle, 8) SP 800-51 Rev. 1, Guide to Using Vulnerability Naming Schemes, 9) SP 800-40 version 2.0, Creating a Patch and Vulnerability Management Program

Organization for the Advancement of Structured Information Standards (OASIS)2. 1) Web Services Security v1.1, 2) Security Assertion Markup Language (SAML) v2.0

Paul, M., (2011). Official (ISC)2 Guide to the CSSLP3

Shore, J., Chromatic, (2007). The Art of Agile Development

Simpson, S., (2008). Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today. SAFECode.

The Open Web Application Security Project (OWASP): 1) Top Ten Project, 2) Code Review Guide, 3) Testing Guide, 4) Legal Project, 5) Development Guide, 6) Enterprise Security API (ESAPI) Project

The Payment Card Industry Security Standards Council (PCI SSC): 1) PCI DSS (PCI Data Security Standard), 2) PA-DSS (Payment Application Data Security Standard), 3) PCI PTS (PIN Transaction Security), 4) PCI P2PE (Point-to-Point Encryption), and 5) PCI DSS Tokenization Guidelines

Vasudevan, V., A. Mangla, F. Ummer, S. Shetty, S. Pakala, S. Anbalahan, (2008). Application Security in the ISO 27001 Environment

Wysopal, C., L. Nelson, D. Dai Zovi, E. Dustin, (2006). The Art of Software Security Testing: Identifying Software Security Flaws

1 This reference can be used for multiple domains. 2 This reference can be used for multiple domains. 3 This reference can be used for multiple domains.

22




SECURE SOFTWARE REQUIREMENTS

Allen, J. H., S. Barnum, R. J. Ellison, G. McGraw, N. R. Mead, (2008). Software Security Engineering: A Guide for Project Managers

Berry, D.M., X. Franch, (2011). Requirements Engineering: Foundation for Software Quality: 17th International Working Conference

Cohn, M., (2004). User Stories Applied: For Agile Software Development

Adzic, G., (2011). Specification by Example: How Successful Teams Deliver the Right Software

Leffingwell, D., (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise

McGraw, G., (2006). Software Security: Building Security

Mead, N., E. Hough, T. Stehney, (2005). Security Quality Requirements Engineering (CMU/SEI-2005-TR-009)

Paul, M., (2012).The 7 Qualities of Highly Secure Software

Srivatanakul, T., J.A. Clark, F. Polack, (2004). Writing Effective Security Abuse Cases. University of York Technical Report YCS-2004-375

Stuttard, D., M. Pinto, (2011). The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws (2nd Edition)

Wiegers, K. (2003). Software Requirements 2

SECURE SOFTWARE DESIGN

Aho, A.V., M. S. Lam, R. Sethi, J.D. Ullman, (2006). Compilers: Principles, Techniques, and Tools (2nd Edition)

Bertino, E., K. Takahashi, (2010). Identity Management: Concepts, Technologies, and Systems

Challener, C., K. Yoder, R. Catherman, D. Safford, L.V. Doorn, (2008). A Practical Guide to Trusted Computing

Clarke, J., (2009). SQL Injection Attacks and Defense

Dwivedi, H., (2010). Mobile Application Security

Gamma, E., R. Helm, R. Johnson, J. Vlissides, (1994). Design Patterns: Elements of Reusable Object-Oriented Software

Howard, M., J. Pincus, J.M. Wing, (2002). Measuring Relative Attack Surfaces

Kanneganti, R., P.R. Chodavarapu, (2008). SOA Security

Kenan, K., (2005). Cryptography in the Database: The Last Line of Defense

Kleidermacher, D., M. Kleidermacher, (2012). Embedded Systems Security: Practical Methods for Safe and Secure Software and Systems Development

23




SECURE SOFTWARE DESIGN

Litchfield, D., C. Anley, J. Heasman, B. Grindlay, (2005). The Database Hacker’s Handbook: Defending Database Servers.

Meier, J.D., A. Mackman, S. Vasireddy, M. Dunner, R. Escamilla, A. Murukan, (2003). Improving Web Application Security Threats and Countermeasures (Patterns & Practices)

Poslad, S., (2009). Ubiquitous Computing: Smart Devices, Environments and Interactions

Steel, C., R. Nagappan, R. Lai, (2005). Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

Swiderski, F., W. Snyder, (2004). Threat Modeling

Viega, J., M. Messier, (2003). Secure Programming Cookbook for C and C++: Recipes for Cryptography, Authentication, Input Validation & More

Wetteroth, D., (2001). OSI Reference Model for Telecommunications

Zeldovich, N., (2007). Securing Untrustworthy Software Using Information Flow Control. Doctoral Thesis.

SECURE SOFTWARE IMPLEMENTATION/CODING

Anley, C., J. Heasman, F. Lindner, G. Richarte, (2007). The Shellcoder's Handbook: Discovering and Exploiting Security Holes

Appleton, B., K. Brown, (2003). Software Configuration Management Patterns: Effective Teamwork, Practical Integration

Chess, B., J. West, (2007). Secure Programming with Static Analysis

D. Hankerson, A.J. Menezes, S. Vanstone, (2010). Guide to Elliptic Curve Cryptography

Howard, M., D. LeBlanc, J. Viega, (2009). 24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them

Kayem, A.V., S.G. Akl, P. Martin, (2010). Adaptive Cryptographic Access Control

Martin, R.C., (2008). Clean Code: A Handbook of Agile Software Craftsmanship

NIST, Software Assurance Metrics and Tool Evaluation (SAMATE) Project

Robert C. Seacord, R.C., W. Dormann, J. McCurley, P. Miller, R.W. Stoddard, D. Svoboda, J. Welch, (2012). Source Code Analysis Laboratory (SCALe) (CMU/SEI-2012-TN-013)

Schneier, B., (1996). Applied Cryptography: Protocols, Algorithms, and Source Code in C (2nd Edition)

Secure Coding Standards, Software Engineering Institute, Carnegie Mellon: 1) The CERT C Secure Coding Standard, 2) The CERT C++ Secure Coding Standard, 3) The CERT Oracle Secure Coding Standard for Java, 4) The CERT Perl Secure Coding Standard

Simon, A., (2011). Value-Range Analysis of C Programs: Towards Proving the Absence of Buffer Overflow Vulnerabilities

Tennoe, L.M., M.T. Henssonow, S.F. Surhone, (2010). Tokenization (Data Security)

24




The MITRE Corporation. 1) Common Weakness Enumeration (CWE), 2) Common Attack Pattern Enumeration and Classification (CAPEC), 3) Malware Attribute Enumeration and Characterization (MAEC)

SECURE SOFTWARE TESTING

Andrews, M., J.A. Whittaker, (2006). How to Break Web Software: Functional and Security Testing of Web Applications and Web Services

Black, R., (2007). Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional

Cohn, R., J. Russell, (2012). Cryptographic Module Validation Program

Crispin, L. J. Gregory, (2009). Agile Testing: A Practical Guide for Testers and Agile Teams

Eilam, E., E. J. Chikofsky, (2005). Reversing: Secrets of Reverse Engineering

Gallagher, T., L. Landauer, B. Jeffries, (2006). Hunting Security Bugs

Graham, D., M. Fewster, (2012). Experiences of Test Automation: Case Studies of Software Test Automation

Herzog, P., (2010). Open Source Security Testing Methodology Manual (OSSTMM) 3.02. ISECOM

Hope, P. B. Walther, (2008). Web Security Testing Cookbook: Systematic Techniques to Find Problems Fast

Kennedy, D., J. O'Gorman, D. Kearns, M. Aharoni, (2011). Metasploit: The Penetration Tester's Guide

Liu, H.H., (2009). Software Performance and Scalability: A Quantitative Approach

Martin, R. A., (2007). Being Explicit About Security Weaknesses. CrossTalk - The Journal of Defense Software Engineering, Vol. 20, No. 3.

Microsoft, (2007). Performance Testing Guidance for Web Applications Patterns & Practices

Myers, G.J., C. Sandler, T. Badgett, T.M. Thomas, (2004). The Art of Software Testing, (2nd Edition)

Osherove, R., (2009). The Art of Unit Testing: With Examples in .Net

Sutton, M., A. Greene, P. Amini, (2007). Fuzzing: Brute Force Vulnerability Discovery

SOFTWARE ACCEPTANCE

Ali, S., T. Heriyanto, (2011). BackTrack 4: Assuring Security by Penetration Testing

Humphrey, W.S. J. W. Over. (1999). Introduction to the Team Software Process

ISO/IEC 15408, Information technology -- Security techniques -- Evaluation criteria for IT security: Part 1, Introduction and general model; Part 2, Security functional requirements; Part 3, Security assurance requirement

Lewis, R.O. (1992). Independent Verification and Validation

Mead, N.R., J.H. Allen, W. A. Conklin, A. Drommi, J. Harrison, J. Ingalsbe, J. Rainey, D. Shoemaker, (2009). Making the Business Case for Software Assurance (CMU/SEI-2009-SR-001)

Nanda, V. J. Robinson, (2011). Six Sigma Software Quality Improvement

25




SOFTWARE ACCEPTANCE

Perry, W.E. (2006). Effective Methods for Software Testing: Includes Complete Guidelines, Checklists, and Templates

Pohl, K., G. Böckle, F.J. van der Linden, (2010). Software Product Line Engineering: Foundations, Principles and Techniques

Rakitin, S.R. (1997). Software Verification and Validation: A Practitioner's Guide

Rice, D., (2007). Geekonomics: The Real Cost of Insecure Software

SOFTWARE DEPLOYMENT, OPERATIONS, MAINTENANCE AND DISPOSAL

Allen, J.H., S. Barnum, R. Ellison, G. McGraw, N.R. Mead, (2008). Software Security Engineering: A Guide for Project Managers

Cavusoglu, H., H. Cavusoglu, J. Zhang, (2006). Economics of Security Patch Management. Fifth Workshop on Economics of Information Security (WEIS)

Dowd, M., J. McDonald, J. Schuh, (2006). The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities

Fowler, M.J., K. Beck, J. Brant, W. Opdyke, D. Roberts, (1999). Refactoring: Improving the Design of Existing Code

Jaquith, A., (2007). Security Metrics: Replacing Fear, Uncertainty, and Doubt

Metula, E., (2010). Managed Code Rootkits: Hooking into Runtime Environments

Molyneaux, I., (2009). The Art of Application Performance Testing: Help for Programmers and Quality Assurance

Rajnovic, D., (2010). Computer Incident Response and Product Security

Stackpole, B., P. Hanrion, (2007). Software Deployment, Updating, and Patching

Venkatakrishnan, V. N., R. Sekar, T. Kamat, S. Tsipa, Z. Liang, (2002). An Approach for Secure Software Installation. 2002 LISA XVI

Wetter, F.M. (2005). Curing the Patch Management Headache

SUPPLY CHAIN AND SOFTWARE ACQUISITION

Alberts, C., R. Creel, A. Dorofee, R. Ellison, C. Woody, (2011). A Systemic Approach for Assessing Software Supply-Chain Risk. 44th Hawaii International Conference on System Sciences

Department of Homeland Security, (2009). Software Assurance in Acquisition and Contract Language. Software Assurance Pocket Guide Series: Acquisition & Outsourcing, Volume I, Version 1.1

Department of Homeland Security, (2009). Software Supply Chain Risk Management and Due Diligence. Software Assurance Pocket Guide Series: Acquisition and Outsourcing Volume II, Version 1.2

Ellison, R., C. Woody, (2010). Considering Software Supply-Chain Risks. CrossTalk - The Journal of Defense Software Engineering Vol. 23, No. 5

Ellison, R.J., J.B. Goodenough, C.B. Weinstock, C. Woody, (2010). Evaluating and Mitigating Software Supply Chain Security Risks (CMU/SEI-201-TN-016)

Humble, J., and D. Farley, (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Humphrey, W.S., (1987). A Method for Assessing the Software Engineering Capability of Contractors (CMU/SEI-87-TR-023)

26




SUPPLY CHAIN AND SOFTWARE ACQUISITION

Jones, T.C., (1993). Assessment and Control of Software Risks

Lewis, J.A., (2007). Foreign Influence on Software. A Report of the Technology and Public Policy Program Center for Strategic and International Studies.

Lindberg, V., (2008). Intellectual Property and Open Source: A Practical Guide to Protecting Code

Mead, N.R., (2003). International Liability Issues for Software Quality (CMU/SEI-2003-SR-001)

Polydys, M.L., and S. Wisseman, (2009). Software Assurance in Acquisition: Mitigating Risks to the Enterprise - A Reference Guide for Security-Enhanced Software Acquisition and Outsourcing

Simpson, S., (2009). The Software Supply Chain Integrity Framework: Defining Risks and Responsibilities for Securing Software in the Global Supply Chain. SAFECode.

Tollen, D., (2011). The Tech Contracts Handbook: Software Licenses and Technology Services Agreements for Lawyers and Businesspeople

27




SAMPLE EXAM QUESTIONS ________________________________________________________________

1. Which of the following is the BEST method for providing integrity for released code?

(A) Role Based Access Control (RBAC) to source code library

(B) Cryptographic hash validation of code versions

(C) Advanced Encryption Standard (AES) encryption of source code versions

(D) Change Control Board controls access to source code

Answer: B

________________________________________________________________

2. What is the advantage of employing cryptographic agility?

(A) Better security

(B) Better performance

(C) Easy to upgrade

(D) Save cost

Answer: C

________________________________________________________________

3. A software product has been tested, and several vulnerabilities were identified and

ranked with a low rating. In order to safely proceed with the acquisition and

incorporation of this product into an organization’s infrastructure, which of the following

must be created?

(A) An escrow agreement

(B) An indemnification checklist

(C) A statement of plausible deniability

(D) A risk acceptance statement

Answer: D ________________________________________________________________

28




GENERAL EXAMINATION INFORMATION

Computer Based Test (CBT) Please note: General Exam Information – there are two sets of instructions – one for Computer

Based Test (CBT), and one for Paper Based Test (PBT). Please choose accordingly.

Registering for the Exam

Process for Registration Overview

This section describes procedures for candidates registering to sit for a Computer Based Test

(CBT). The test is administered at Pearson VUE Testing centers in the US, Canada, and other

parts of the world.

1. Go to www.pearsonvue.com/isc2 to register for a test appointment.

2. Select the most convenient test center

3. Select an appointment time.

4. Pay for your exam appointment.

5. Receive confirmation from Pearson VUE with the appointment details, test center

location and other relevant instructions, if any.

Please note that your registration information will be transferred to (ISC)² and all

communication about the testing process from (ISC)² and Pearson VUE will be sent to you via

email.

Fees Please visit the (ISC)² website https://www.isc2.org/certification-register-now.aspx for the most

current examination registration fees.

29




U.S. Government Veteran’s Administration G.I. Bill The U.S. Department of Veterans Affairs has approved reimbursement to veterans under the G.I.

Bill for the cost of the Certified Information System Security Professional (CISSP), the CISSP

Concentrations (ISSAP, ISSEP, ISSMP), the Certification and Accreditation Professional (CAP), and

the System Security Certified Practitioner (SSCP) examinations. Please refer to the U.S.

Department of Veterans Affairs Website at www.va.gov for more details.

CBT Demonstration Candidates can experience a demonstration and tutorial of the CBT experience

on our Pearson VUE web page. The tutorial may be found at

www.pearsonvue.com/isc2.

Scheduling a Test Appointment

Process for Registration Overview

Candidates may register for a testing appointment directly with Pearson VUE (

www.pearsonvue.com/isc2 ). Candidates who do not pass the test will be subject to the retake

policy and must wait the applicable time before they are allowed to re-sit for the examination.

Exam Appointment

Test centers may fill up quickly because of high volume and previously scheduled special

events. Pearson VUE testing centers also serve candidates from other entities; thus waiting to

schedule the testing appointment may significantly limit the options for candidate’s desired

testing dates at the closest center available.

Scheduling for a Testing Appointment

Candidates may schedule their appointment online at (ISC)² CBT Website located at

www.pearsonvue.com/isc2. Candidates will be required to create a Pearson VUE account in

order to complete registration. Candidates profile will be transferred to (ISC)² and becomes

part of the candidate’s permanent record. Candidates will be able to locate test centers and

select from a choice of available examination appointment times at the Pearson VUE website.

Candidates may also register over the telephone with a CBT registration specialist. Please refer

to ‘Contact Information’ for local telephone numbers for your region.

30




Rescheduling or Cancellation of a Testing Appointment If you wish to reschedule or cancel your exam appointment, you must contact Pearson VUE at

least 48 hours before the exam date by contacting Pearson VUE online

(www.pearsonvue.com/isc2), OR at least 24 hours prior to exam appointment time by

contacting Pearson VUE over the phone. Canceling or rescheduling an exam appointment less

than 24 hours via phone notification, or less than 48 hours via online notification is subject to a

forfeiture of exam fees. Exam fees are also forfeited for no-shows. Please note that Pearson VUE

charges a 50 USD/35 £/40 € fee for reschedules, and 100 USD/70 £/80 € fee for cancellations

Reschedules and cancellations may be done at the (ISC)² CBT Candidate Website

(www.pearsonvue.com/isc2) or via telephone. Please refer to ‘Contact Information’ for more

information and local telephone numbers for your region.

Late Arrivals or No Shows If the candidate does not arrive within 15 minutes of the scheduled exam starting time, he or

she has technically forfeited his or her assigned seat.

If the candidate arrives late (after 15 minutes of his/her scheduled appointment), it is up to the

discretion of the testing center as to whether or not the candidate may still take the exam. If the

test administrator at the testing location is able to accommodate a late arriving candidate,

without affecting subsequent candidates’ appointments, he/she will let the candidate to sit for

the exam and launch his/her exam.

Any/all attempts are made to accommodate candidates who arrive late. However, if the

schedule is such that the test center is not able to accommodate a late arrival, the candidate

will be turned away and his/her exam fees will be forfeited.

If a candidate fails to appear for a testing appointment, the test result will appear in the system

as a No-Show and the candidate’s exam fees will be forfeited.

31




Procedure for Requesting Special Accommodations Pearson VUE Professional Centers can accommodate a variety of candidates’ needs, as they

are fully compliant with the Americans with Disability Act (ADA), and the equivalent

requirements in other countries.

Requests for accommodations should be made to (ISC)² in advance of the desired testing

appointment. Once (ISC)² grants the accommodations request, the candidate may schedule

the testing appointment using Pearson VUE’s special accommodations number. From there, a

Pearson VUE coordinator will handle all of the arrangements.

PLEASE NOTE: Candidates that request special accommodations should not schedule their

appointment online or call the main CBT registration line.

What to Bring to the Test Center

Proper Identification

(ISC)² requires two forms of identification, a primary and a secondary, when checking in for a

CBT test appointment at a Pearson VUE Test Center. All candidate identification documents

must be valid (not expired) and must be an original document (not a photocopy or a fax).

Primary IDs: Must contain a permanently affixed photo of the candidate, along with the

candidate’s signature.

Secondary IDs: Must have the candidate’s signature.

Accepted Primary ID (photograph and signature, not expired)

Government issued Driver’s License or Identification Card

U.S. Dept of State Drivers License

U.S. Learner’s Permit (card only with photo and signature)

National/State/Country Identification Card

Passport

Passport Cards

Military ID

Military ID for spouses and dependents

Alien Registration Card (Green Card, Permanent Resident Visa)

Government Issued local language ID (plastic card with photo and signature

Employee ID

School ID

32




Credit Card* (A credit card can be used as a primary form of ID only if it

contains both a photo and a signature and is not expired. Any credit card can

be used as a secondary form of ID, as long as it contains a signature and is not

expired. This includes major credit cards, such as VISA, MasterCard, American

Express and Discover. It also includes department store and gasoline credit

cards.

Accepted Secondary ID (contains signature, not expired)

U.S. Social Security Card

Debit/(ATM) Card

Credit Cards

Any form of ID on the primary list

Name Matching Policy

Candidate’s first and last name on the presented identification document must exactly match

the first and last name on the registration record with Pearson VUE. If the name the candidate

has registered with does not match the name on the identification document, proof of legal

name change must be brought to the test center on the day of the test. The only acceptable

forms of legal documentation are marriage licenses, divorce decrees, or court sanctioned legal

name change documents. All documents presented at the test center must be original

documents. If a mistake is made with a name during the application process, candidates

should contact (ISC)² to correct the information well in advance of the actual test date. Name

changes cannot be made at the test center or on the day of the exam. Candidates who do

not meet the requirements presented in the name matching policy on the day of the test may

be subject to forfeiture of testing fees and asked to leave the testing center.

Examination Agreement and Non-Disclosure Agreement

All candidates must agree to the terms listed in (ISC)2’s Examination Agreement. The

agreement is located at

https://www.isc2.org/uploadedfiles/education/cbt%20examination%20agreement.pdf.

Prior to starting the exam, all candidates are also required to accept the (ISC)² non-disclosure

agreement (NDA), and are required in the computer to accept the agreement prior to being

presented with exam questions. If the NDA is not accepted by the candidate, or refused to

accept within the time allotted, the exam will end, and the candidate will be asked to leave

the test center. No refund of exam fees will be given. For this reason, all candidates are strongly

encouraged to review the non-disclosure agreement prior to scheduling for, or taking the

exam. The agreement is located at www.pearsonvue.com/isc2/isc2_nda.pdf.

33




Day of the Exam

Check-In Process

Plan to arrive at the Pearson VUE testing center at least 30 minutes before the scheduled testing

time. If you arrive more than 15 minutes late to your scheduled appointment, you may lose your

examination appointment. For checking-in:

You will be required to present two acceptable forms of identification.

You will be asked to provide your signature, submit to a palm vein scan, and have

your photograph taken. Hats, scarves and coats may not be worn in the testing room,

or while your photograph is being taken.

You will be required to leave your personal belongings outside the testing room.

Secure storage will be provided. Storage space is small, so candidates should plan

appropriately. Pearson Professional Centers assume no responsibility for candidates’

personal belongings.

The Test Administrator (TA) will give you a short orientation, and then will escort you to

a computer terminal. You must remain in your seat during the examination, except

when authorized to leave by test center staff. You may not change your computer

terminal unless a TA directs you to do so.

Raise your hand to notify the TA if you

o believe you have a problem with your computer.

o need to change note boards.

o need to take a break.

o need the administrator for any reason.

Breaks

You will have up to six hours to complete the CISSP, and up to four hours to complete the CSSLP

and CCFP up to three hours to complete the following examinations:

SSCP

CAP

HCISPP

ISSAP

ISSEP

ISSMP

Total examination time includes any unscheduled breaks you may take. All breaks count

against your testing time. You must leave the testing room during your break, but you may not

leave the building or access any personal belongings unless absolutely necessary (e.g. for

34




retrieving medication). Additionally, when you take a break, you will be required to submit to a

palm vein scan before and after your break.

Examination Format and Scoring

The CISSP® examination consists of 250 multiple choice questions with four (4) choices

each.

The CSSLP® examination consists of 175 multiple choice questions with four (4) choices

each.

The HCISPP examination contains 125 multiple choice questions with four (4) choices

each.

The CCFP examination contains 125 multiple choice questions with four (4) choices each.

The SSCP® examination contains 125 multiple choice questions with four (4) choices

each.

The ISSAP®, ISSEP®, and ISSMP® concentration examinations contain 125, 150, 125

multiple choice questions respectively with four (4) choices each.

The Certified Authorization Professional (CAP®) examination contains 125 multiple choice

questions with four (4) choices each. Also, administered in computers.

There may be scenario-based items which may have more than one multiple choice

question associated with it. These items will be specifically identified in the test booklet.

Each of these exams contains 25 questions which are included for research purposes only.

The research questions are not identified; therefore, answer all questions to the best of your

ability. There is no penalty for guessing, so candidates should not leave any item unanswered.

Examination results will be based only on the scored questions on the examination. There

are several versions of the examination. It is important that each candidate have an

equal opportunity to pass the examination, no matter which version is administered. Subject

Matter Experts (SMEs) have provided input as to the difficulty level of all questions used in the

examinations. That information is used to develop examination forms that have comparable

difficulty levels. When there are differences in the examination difficulty, a mathematical

procedure called equating is used to make the difficulty level of each test form equal.

Because the number of questions required to pass the examination may be different for each

version, the scores are converted onto a reporting scale to ensure a common standard. The

passing grade required is a scale score of 700 out of a possible 1000 points on the grading

scale.

35




Technical Issues

On rare occasions, technical problems may require rescheduling of a candidate’s examination.

If circumstances arise causing you to wait more than 30 minutes after your scheduled

appointment time, or a restart delay lasts longer than 30 minutes, you will be given the choice

of continuing to wait, or rescheduling your appointment without an additional fee.

o If you choose to wait, but later change your mind at any time prior to beginning or

restarting the examination, you will be allowed to take exam at a later date, at

no additional cost.

o If you choose not to reschedule, but rather test after a delay, you will have no

further recourse, and your test results will be considered valid.

o If you choose to reschedule your appointment, or the problem causing the delay

cannot be resolved, you will be allowed to test at a later date at no additional

charge. Every attempt will be made to contact candidates if technical problems

are identified prior to a scheduled appointment.

Testing Environment Pearson Professional Centers administer many types of examinations including some that

require written responses (essay-type). Pearson Professional Centers have no control over typing

noises made by candidates sitting next to you while writing their examination. Typing noise is

considered a normal part of the computerized testing environment, just as the noise of turning

pages is a normal part of the paper-and pencil testing environment. Earplugs are available

upon request.

When the Exam is Finished After you have finished the examination, raise your hand to summon the TA. The TA will collect

and inventory all note boards. The TA will dismiss you when all requirements are fulfilled.

If you believe there was an irregularity in the administration of your test, or the associated test

conditions adversely affected the outcome of your examination, you should notify the TA

before you leave the test center.

Results Reporting Candidates will receive their unofficial test result at the test center. The results will be handed

out by the Test Administrator during the checkout process. (ISC)² will then follow up with an

official result via email. All test results are subject to (ISC)²’s psychometric and forensic

evaluation. Based on the number of tests administered, this evaluation may be conducted

36




after candidates receive the official results email. Any candidate whose score is affected by

the psychometric and forensic evaluation will be notified by (ISC)².

In some instances, real time results may not be available. A comprehensive statistical and

psychometric analysis of the score data is conducted during every testing cycle before scores

are released. A minimum number of candidates are required to take the exam before this

analysis can be completed. Depending upon the volume of test takers for a given cycle, there

may be occasions when scores are delayed for approximately 6-8 weeks in order to complete

this critical process. Results WILL NOT be released over the phone. They will be sent via email

from (ISC)² as soon as the scores are finalized. If you have any questions regarding this policy,

you should contact (ISC)² prior to your examination.

Exam Irregularities and Test Invalidation

(ISC)2 exams are intended to be delivered under standardized conditions. If any irregularity or

fraud is encountered before, during, or after the administration of the exam, (ISC)2 will examine

the situation and determine whether action is warranted. If (ISC)2 determines that any testing

irregularity or fraud has occurred, it may choose not to score the answer documents of the

affected test taker(s), or it may choose to cancel the scores of the affected test taker(s).

(ISC)2 may at its sole discretion revoke any and all certifications a candidate may have earned

and ban the candidate from earning future (ISC)2 certifications, and decline to score or cancel

any Exam under any of the circumstances listed in the (ISC)2 Examination Agreement.

Please refer to the (ISC)2 Examination Agreement for further details

(https://www.isc2.org/uploadedfiles/education/cbt%20examination%20agreement.pdf).

Retake Policy Test takers who do not pass the exam the first time will be able to retest after 30 days. Test

takers that fail a second time will need to wait 90 days prior to sitting for the exam again. In the

unfortunate event that a candidate fails a third time, the next available time to sit for the exam

will be 180 days after the most recent exam attempt. Candidates are eligible to sit for (ISC)²

exams a maximum of 3 times within a calendar year.

Recertification by Examination Candidates and members may recertify by examination for the following reasons ONLY;

The candidate has become decertified due to reaching the expiration of the time limit

for endorsement.

The member has become decertified for not meeting the number of required continuing

professional education credits.

37




Logo Usage Guidelines

(ISC)² is a non-profit membership organization identified as the leader in certifying individuals in

information security.

Candidates who successfully complete any of the (ISC)² certification requirements may use the

appropriate Certification Mark or the Collective Mark, where appropriate, and the logo

containing the Certification Mark or the Collective Mark, where appropriate (the “Logo”) to

identify themselves as having demonstrated the professional experience and requisite

knowledge in the realm of information system security. Please visit the following link (URL) for

more information on logo use:

https://www.isc2.org/uploadedfiles/(ISC)2_Public_Content/Legal _and

_Policies/LogoGuidleines.pdf

Any questions?

(ISC)2

Candidate Services

311 Park Place Blvd, Suite 400

Clearwater, FL 33759

Phone: 1.866.331.ISC2 (4722) in the United States

1.727.785.0189 all others

Fax: 1.727.683.0785

38




Documents

CSSLP CIB.pdf