ISC2 CISSP Practice Test

This statement is false because, in a DAC environment, the file owner retains the ability to both delegate and revoke access permissions to their resources. DAC grants users the flexibility to control who can access their files and to modify those permissions as needed. This contrasts with models like Mandatory Access Control (MAC), where access is dictated by external policies and cannot be altered by individual users.

The correct answer is Mandatory Access Control (MAC). This model is characterized by centrally controlled access rights based on clearance levels, where the system or security administrators determine the access levels rather than the data owners. In MAC, users cannot share or transfer their access rights to others, as access is strictly governed by security labels and clearance levels.

Discretionary Access Control (DAC) is incorrect because in DAC, the data owner determines who can access the resources and can delegate those permissions to others.

Role-Based Access Control (RBAC) is incorrect because while it does involve assigning permissions to roles rather than individual users, it doesn't inherently involve clearance levels and doesn't prevent delegation if the implementation allows it.

Attribute-Based Access Control (ABAC) is incorrect because it makes access decisions based on attributes of users, resources, and environmental conditions rather than clearance levels alone.

The correct answer is conducting a software composition analysis and vulnerability scan. This approach provides objective, verifiable information about the components' security by identifying known vulnerabilities in the specific versions being used. It gives organizations direct visibility into security issues rather than relying solely on vendor claims or documentation.

Requesting the vendor's security certification documentation is useful but insufficient on its own. Certifications may be outdated, have limited scope, or not address specific vulnerabilities in the components you're using.

Reviewing the vendor's claims about security features during contract negotiation may discourage overstatement of security capabilities. However, it does not evaluate or compensate for vulnerabilities in their products.

Using only open-source components with public code repositories has some advantages for transparency but doesn't guarantee security. Open-source software can still contain vulnerabilities, and not all proprietary software is inherently less secure than open-source alternatives. The key is proper evaluation regardless of the source.

The statement is true because job rotation helps mitigate risks associated with continuous access to sensitive information or processes by distributing responsibilities among different personnel. By rotating jobs, organizations can reduce the opportunities for individuals to engage in unethical behavior or make mistakes without oversight. The incorrect options do not accurately reflect the security benefits of implementing job rotation.

The correct answer is Power Analysis. Power analysis is a specific type of side-channel attack that monitors the power consumption of a device during cryptographic operations. By analyzing the variations in power consumption patterns, attackers can potentially extract sensitive information such as cryptographic keys.

Differential Power Analysis (DPA) and Simple Power Analysis (SPA) are common techniques where attackers measure power consumption during cryptographic operations to deduce secret information. The observed correlation between electrical usage and operations being performed is a classic indicator of vulnerability to power analysis attacks.

Fault injection involves deliberately introducing errors into a Hardware Security Module (HSM) to cause it to behave incorrectly and potentially reveal cryptographic secrets, but does not focus on monitoring energy consumption. Timing attacks exploit the time taken to perform cryptographic operations rather than power consumption. Electromagnetic analysis focuses on radiation emissions rather than direct power consumption patterns.

The correct answer is to prevent untested code and configuration changes from affecting production systems. Separate environments allow changes to be developed and tested in isolation before being deployed to production, reducing the risk of service disruptions and security issues in systems serving real users.

Reducing the ability of developers to use sensitive data in development environments can be a benefit of separating environments. However, good security practices would make it difficult for developers to access and retrieve sensitive data regardless of the environment, as they should develop using artificial data sets.

**Enforcing separation of duties among development teams may be a secondary benefit **but is not the primary purpose of environment separation. Separation of duties can be implemented through access controls and organizational structure even within a single environment.

Enabling different access control policies for different user groups can be accomplished without completely separate environments. While access controls are important, the main purpose of environment separation is to isolate changes and provide a progression for testing and validation.

A purple team exercise is the BEST answer because it combines both offensive (red team) and defensive (blue team) capabilities in a collaborative effort. Purple team exercises involve red team members conducting attacks while blue team members actively defend and respond, with both teams sharing information and insights throughout the exercise. This approach allows for real-time feedback, immediate learning opportunities, and provides the most comprehensive view of both attack and defense capabilities simultaneously.

Red team exercises focus primarily on simulating attacks without actively involving the defensive team in a collaborative way. Blue team exercises focus on defense without incorporating active, realistic attack simulations. Compliance checks are formal reviews to ensure systems meet regulatory or policy requirements but don't involve simulated attacks or defensive responses in real-time.

Code signing is the most appropriate security measure for embedded medical devices like infusion pumps because it ensures that only authorized firmware and software updates can be installed on the devices. This prevents malicious code execution and unauthorized modifications to the device functionality.

The other options are inadequate or inappropriate for securing embedded medical devices:

• Strong passwords alone would not prevent firmware tampering or unauthorized code execution
• Physical isolation is impractical for networked medical devices that need to communicate with hospital systems
• Daily vulnerability scanning could potentially disrupt the operation of these critical medical devices and many embedded systems lack the computing resources to support continuous scanning

Misuse case testing is a methodology that examines how systems can be intentionally or unintentionally abused by exploring negative scenarios and unexpected interactions. This approach differs from traditional use cases by specifically focusing on potential exploit vectors and problematic usage patterns rather than legitimate functionality. Security professionals leverage misuse case testing to identify vulnerabilities that might remain hidden during conventional testing approaches by adopting an adversarial mindset. This methodology helps organizations strengthen their security posture by uncovering potential attack vectors before they can be exploited by malicious actors.

The correct answer is protecting the integrity and security of all components and processes involved in creating software. Supply chain security in software development encompasses securing all aspects of the software creation process, from third-party components and development tools to build systems and distribution mechanisms, ensuring that malicious code isn't introduced at any stage.

Ensuring the physical security of hardware devices during shipping addresses only a narrow aspect of hardware supply chain security. While important for hardware, it doesn't address the broader software supply chain concerns.

**Managing inventory levels of development equipment **is an availability concern, but it is rarely a security function related to software development. Inventory management may be part of asset management but doesn't directly relate to securing the software supply chain.

**Optimizing delivery schedules for software patches ** can assist security in scheduling operational impact. However, release timing doesn't directly affect the security of the software being developed.

Physical destruction is the BEST method for addressing data remanence concerns with Solid State Drives (SSDs) that contained classified information. Unlike traditional hard drives, SSDs store data in flash memory cells that can retain data fragments even after logical deletion operations.

Overwriting (secure wiping) is less effective on SSDs due to wear-leveling algorithms that redistribute write operations across the drive, potentially leaving some cells with original data untouched. Standard formatting simply removes the file system index without removing the actual data. Degaussing is effective for magnetic media (like traditional hard drives) but does not reliably clear data from SSDs which use electronic storage rather than magnetic storage.

Physical destruction (shredding, disintegration, pulverization, or incineration) ensures that no data can be recovered from the storage media, making it the most appropriate choice for addressing data remanence on devices that contained classified information.

The correct answer involves designing the facility away from flood plains while implementing proper access control systems. This approach simultaneously addresses environmental threats (avoiding flood-prone areas) and physical security concerns (restricting unauthorized access). A layered approach to data center security must account for both natural hazards and human threats. The other options fail to provide comprehensive protection: glass walls compromise security despite visibility benefits, high-traffic locations increase rather than decrease security risks, and top-floor locations with large windows create vulnerabilities to both environmental threats and physical security breaches.

The selected method typically requires engaging in a scenario that alters normal operations, allowing teams to identify weaknesses and refine processes in real-time. Other options represent less direct forms of evaluation that do not provide the same level of insight into recovery effectiveness.

'Fail securely' is the correct secure design principle to apply in this scenario. When a system encounters an error or failure condition, it should default to a secure state rather than an insecure one. In practice, this means that when the financial application encounters an unexpected error, it should reject transactions by default rather than accidentally approving them, maintain access restrictions rather than opening them, and preserve security controls even during failure modes.

Other options are incorrect because:

• Secure defaults refers to systems being deployed with secure initial configurations.
• Defense in depth involves implementing multiple security controls in layers.
• Least privilege concerns limiting user access rights to only what's necessary for their job function.

This statement is true, as it describes a context-aware access control policy that employs role-based access control (RBAC) principles while factoring in dynamic elements. By using contextual factors, organizations can enhance security and ensure that access is not only role-based but also relevant to the situation, thereby mitigating risks associated with unauthorized access or misuse. In contrast, a static role assignment would not provide the same level of flexibility or security in varying circumstances.