C706 - Chapter 5 -- Design and Development (A3)

Black box debugging (black box).

Debuggers for low-level programming languages such as C or ASM are software tools that enable the tester to monitor the execution of a program, start and stop a program, set breakpoints, and modify values. Debuggers are typically used to debug an application when the source code or the compiler symbols are available. The source-code and compiler symbols allow information, the values of internal variable, to be tracked to discover some aspect of internal program behavior. However, sometimes only the binary is available, and the binary was compiled from code with no compiler symbols or debug flags set. This is typical in commercial software, legacy software, and software that implements protective measures, such as code obfuscation, to prevent reverse engineering. In this case, traditional debugging is not possible. It should be noted that if the focus of debugging effort is on the software interaction with an external component, the binary may be all that is needed.

Defense in depth

Defense in depth. This is the application of multiple layers of protection, such that a subsequent layer will provide protection if a previous layer is breached.

Dynamic code analysis (gray box)

Dynamic code analysis examines the code as it executes in a running application, with the tester tracing the external interfaces in the source code to the corresponding interactions in the executing code, so that any vulnerabilities or anomalies that arise in the executing interfaces are simultaneously located in the source code, where they can be fixed. Unlike static analysis, dynamic analysis enables the tester to exercise the software in ways that expose vulnerabilities introduced by interactions with users and changes in the configuration or behavior of environmental components. Because the software is not fully linked and deployed in its actual target environment, the testing tool essentially simulates these interactions and their associated inputs and environment conditions.

Fuzz testing (black box).

Fuzzing is a technique that is used to detect faults and security-related bugs in software by providing random inputs (fuzz) to a program. As opposed to static analysis, where source code is reviewed line by line for bugs, fuzzing conducts dynamic analysis by generating a variety of valid and invalid inputs to a program and monitoring the results. In some instances, the result might be the program crashing.

Open Design

Open design. There has always been discussion of the merits and strength of security of designs that are kept secret versus designs that are open to scrutiny and evaluation by the community at large. For most purposes, an open-access control system design that has been evaluated and tested by a large number of experts provides a more secure authentication method than one that has not been widely assessed.

Subject vs object

Subject - request a service (Active) example: user, client, process, programs Object- Provides are requested service(passive) ex: server, program, process, printers database etc

Fail Safe

System must be able to fail and yet maintain the safety of personnel -Manual and automatic overrides -Fire exits/doors

A __________ means that if a system ceases to function, it moves to a state where the security of the system and its data are not compromised. -fail safe policy -least privilege -separation of duties -defense in depth

a fail safe policy A fail safe policy means that if a system ceases to function, it moves to a state where the security of the system and its data are not compromised. In the situation where system recovery is not done automatically, the system should permit access only by the system administrator and not by users, until security controls are reestablished.

Access controls

-Application enable access to sensitive information -Application handle users with different access levels -Especially when one application calls another process

Essentials of Need to know

-Classification -Ownership -Clearance

Preventing Collusion

-Job Rotation -Mandatory vacations

Justification for Need to Know- protection from unauthorized disclosure of information

-Prevent loss of intellectual property (IP) -Protect competitive data -Legal compliance

Problems with Need to Know

-Reduce the ability to share ideas and collaborate -Duplication of effort -Incorrect decision making -Impact on performance -Impact on morale

Plan of action and milestone schedule

A detained required document of the corrective measures planned to increase the effectiveness of the security controls and provide the requisite security for the software prior to its release

Master Test Plan

A plan used to outline the entire test process: augmented by detailed test plans for invididual test stages and individual modules

Design & Development (A3) Stage

A3 Policy compliance analysis Security test plan composition Static Analysis Threat model updating Design security analysis and review Privacy implementation assessment

Least Privilege

Access Time Benefits: -Confidentiality -Integrity -Availability

Economy ofMechanism

Based on the concept of not developing a function that can be provided by a already available mechanism solution -Keeping the design simple

Building Security In

Based on the idea that problems found early in the software lifecycle are significantly easier and less costly to correct than problems discovered post-implementation or post deployment

Block box

Black box. Testing the software from an external perspective, i.e., with no prior knowledge of the software; only binary executable or intermediate byte code is available for analysis.7,8

Economy of mechanism

Economy of mechanism. This promotes simple and comprehensible design and implementation of protection mechanisms, so that unintended access paths do not exist or can be readily identified and eliminated.

Fail safe.

Fail safe. This means that if a system fails, it should fail to a state where the security of the system and its data are not compromised. In the situation where system recovery is not done automatically, the failed system should permit access only by the system administrator and not by users, until security controls are reestablished.

Open Design (open source)

Given a large enough beta tester and code developer base, almost every problem will be characterized quickly and the fix obvious to someone. (Linus's Law)

Gray Box

Gray box. Analyzing the source code for the purpose of designing the test cases, but using black-box testing techniques; both the source code and executable binary are available for analysis.

Defense in depth

Layered Defense -Defend the local enclave -Defend the enclave perimeter -Defend networks and communications -Defend the infrasructure

Least Priviledge

Least privilege. The principle of least privilege maintains that an individual, process, or other type of entity should be given the minimum privileges and resources for the minimum period of time required to complete a task. This approach eliminates the opportunity for unauthorized access to sensitive information.

Control

Operate at all levels within an organization to mitigate risk Each individual within an organization must posses an appropriate risk culture and ensure control effectiveness

Separation of Duties

Prevent and detect fraud

Property-based (white box)

Property-based (white box). Property-based testing is a formal analysis technique developed by the University of California Davis. Property-based testing validates that the software's implemented functionality satisfies its specifications. It does this by examining security-relevant properties revealed by the source code, such as the absence of insecure state changes. Then these security-relevant properties in the code are compared against the software's specification to determine if the security assumptions have been met

Risk Reporting

Provide management with data required for -Governance -Compliance

Risk Monitoring

Risk is Dynamic Can be affected by changes in -operational environment -technology -laws and regulations -new vulnerabilities -new threats -effectiveness of controlls

Question 2 : The __________ principle maintains that an individual, process, or other type of entity should be given the minimum privileges and resources for the minimum period of time required to complete a task -defense in depth -separation of duties -least privilege -fail safe policy

least privilege The least privilege principle maintains that an individual, process, or other type of entity should be given the minimum privileges and resources for the minimum period of time required to complete a task. This approach eliminates the opportunity for unauthorized access to sensitive information.

Risk Acceptance

the level of risk that management is willing to bear/lose

Risk Response /treatement

-Avoid Risk-cease or decide not to participate in the risk activity -Transfer/Share- share the risk with another party (insurance) -Accept - decide to accept the consequences of the risk -Reduce/Mitigate- implement new controls or enhance existing controls to reduce risk

Application Infrastructure

-Do not rely on network security to defend an application -Defend the device -Use secure APIs -Deploy on secure infrastructure/architecture -Database securing

Methods of enforcing separation of duties in information security

-Dual Control (multi-party control) -Balancing -Mutual Exclusivity (mutex) -System authorization

Network Security

-Encryption (for trusted channels) -Firewalls -IPS/IDS -Network segmentation and security zones

Implementing Need to know in APplication

-Label and classification -Access control procedures (granular) -Database views -Masking data on screens (use dots for password, credit card etc)

Purpose and Justification for controls

-Mitigate risk -Protect business assets and enable attainment of objective

Types of controls

-Preventative -Detective -Corrective -Manual and Automated process -Administrative -Technical -Operational/Physical

Least Priviledgee

-Read only -Write only -Red/Write -Create -Delete

Implementing Least Privildege

-Separation of duties -Menus -Temporal isolation -Physical controls (ATMs)

Question 5 : The __________ principle requires that completion of a specified sensitive activity or access to sensitive objects is dependent on the satisfaction of multiple conditions. -fail safe policy -defense in depth -seperation of duties -least privilege

-separation of duties The separation of duties principle requires that completion of a specified sensitive activity or access to sensitive objects is dependent on the satisfaction of multiple conditions. This approach forces collusion among entities in order to compromise the system.

Policy compliance analysis

A continuation of the A2 policy compliance review in which any policy that exists outside the domain of the SLD policy is reviewed

Kerckhoff's Law

A cryptosystem should be secure even if everything about the systems, except the key, is public knowledge.

Binary code analysis (black box)

Binary code scanners analyze machine code to model a language-neutral representation of the program's behaviors, control and data flows, call trees, and external function calls. Such a model may then be traversed by an automated vulnerability scanner in order to locate vulnerabilities caused by common coding errors and simple back doors. A source code emitter can use the model to generate a human-readable source code representation of the program's behavior, enabling manual code review for design-level security weaknesses and subtle back doors that cannot be found by automated scanners.

Binary fault injection (gray box, black box)

Binary fault injection (gray box, black box). Binary fault injection is a runtime analysis technique whereby an executing application is monitored as faults are injected. By monitoring system call traces, a tester can identify the names of system calls, the parameters to each call, and the call's return code. This allows the tester to discover the names and types of resources being accessed by the calling software, how the resources are being used, and the success or failure of each access attempt. In binary fault analysis, faults are injected into the environment resources that surround the application

Byte code analysis (black box).

Byte code scanners are used just like source-code security analyzers, but they detect vulnerabilities in the byte code. For example, the Java language is compiled into a platform-independent byte code format that is executed in the runtime environment (Java Virtual Machine). Much of the information contained in the original Java source code is preserved in the compiled byte code, thus making de-compilation possible. Byte code scanners can be used in cases where the source code is not available for the software—for example, to evaluate the impact a third-party software component will have on the security posture of an application.

Control Framework

COBIT 5 ISO/IEC 277001, ISO/IEC 27002 NIST Special Publications SP800-53

Complete Mediation

Complete mediation. This is where every request by a subject to access an object in a computer system must undergo a valid and effective authorization procedure. This mediation must not be suspend or become capable of being bypassed, even when the information system is being initialized, undergoing shutdown, being restarted, or is in maintenance mode. Complete mediation entails: identification of the entity making the access request verification that the request has not changed since its initiation application of the appropriate authorization procedures and reexamination of previously authorized requests by the same entity.

The following are common steps that can be used to implement a test plan regardless of the strategy, framework, or standard being used:

Define test scripts. Scripts are very detailed, logical steps of instructions that tell a person or tool what to do during the testing. Functional testing scripts are step-by-step instructions that depict a specific scenario or situation that the use case will encounter as well as the expected results. Secure testing scripts are scripts created specifically to test the security of the application. The basis for these scripts comes from the threat models that were generated during the design phase. Misuse cases define what needs to be protected (assets) and what types of attacks can gain access to those assets. Secure test scripts define the acts of carrying out those attacks. Define the user community. Defining the user community helps testers identify acceptable levels of failures and risk. Identify the showstoppers. Defining the must-haves and the "what-if-available" scenarios should be in the use case. If not, a revisit to the requirements might be necessary so that these specifications can be documented. Identify internal resources. Internal resources come from the company's organization, including developers, analysts, software tools, and sometimes project managers. Identify external resources. External resources are tools or people who are hired on a temporary basis to come into a project, test the application, and report findings. External resources are best suited for security testing because they typically come highly trained in secure programming techniques and they are far removed from the code and any internal politics. If external resources are needed, the test plan needs to answer the following questions: (1) What are they going to test? (2) To whom will they report? and (3) With whom will they be working?2

Need to know

Enforces -Confidentiality -Accountability

Design Controls

Ensure that right controls are in place and: -That the controls are effective to mitigate risk -cost-effective -Being managed and monitor -Ensure that residual risk levels are acceptable

Complete Mediation

Every access request must be controlled in accord with policy -Access permissions should be reviewed at the time of access not just based on earlier permissions

Which risk describes the feature, product, or service that stores or transfers personally identifiable information (PII), changes settings or file type associations, or installs software? -Hight Privacy Risk -Moderate Privacy Risk -Low Privacy Risk -No privacy Risk

High Privacy Risk High Privacy Risk is described as the feature, product, or service stores or transfers personally identifiable information (PII), changes settings or file type associations, or installs software. Moderate Privacy Risk is the sole behavior that affects privacy in the feature, product, or service is a one-time, user-initiated, anonymous data transfer. Low Privacy Risk is when no behaviors exist within the feature, product, or service that affect privacy. No anonymous or personal data is transferred, no PII is stored on the machine, no settings are changed on the user's behalf, and no software is installed

Least common mechanism

Least common mechanism. This principle states that a minimum number of protective mechanisms should be common to multiple users, as shared access paths can be sources of unauthorized information exchange. Shared access paths that provide unintentional data transfers are known as covert channels. The least common mechanism promotes the least possible sharing of common security mechanisms.

Leveraging existing components.

Leveraging existing components. In many instances, the security mechanisms of an information system are not configured properly or used to their maximum capability. Reviewing the state and settings of the extant security mechanisms and ensuring that they are operating at their optimum design points will greatly improve the security posture of an information system. Another approach that can be used to increase system security by leveraging existing components is to partition a system into defended subunits. Then, if a security mechanism is penetrated for one subunit, it will not affect the other subunits and damage to the computing resources will be minimized.16

Privacy Impact Rating

P1: High Privacy Risk. The feature, product, or service stores or transfers personally identifiable information (PII), changes settings or file type associations, or installs software. P2: Moderate Privacy Risk. The sole behavior that affects privacy in the feature, product, or service is a one-time, user-initiated, anonymous data transfer (for example, the user clicks on a link and the software goes out to a website). P3: Low Privacy Risk. No behaviors exist within the feature, product, or service that affect privacy. No anonymous or personal data is transferred, no PII is stored on the machine, no settings are changed on the user's behalf, and no software is installed.

During this phase, any policy that exists outside the domain of the SDL policy is reviewed and might include policies from outside the development organization that set security and privacy requirements and guidelines to be adhered to when developing software or applications. What is this phase? -Policy compliance analysis -Policy compliance assessment -Policy requirements assesment -Policy compliance review

Policy compliance analysis A3 policy compliance analysis is a continuation of the A2 policy compliance review. During this phase, any policy that exists outside the domain of the SDL policy is reviewed. These might include policies from outside the development organization that set security and privacy requirements and guidelines to be adhered to when developing software or applications.

IS Control

Provide reasonable assurance that -Business goals and objectives will be achieved -Undesired events will be prevented or detected and corrected -

Psychological acceptability

Psychological acceptability. This refers to the ease of use and intuitiveness of the user interface that controls and interacts with the access control mechanisms. The user must be able to understand the user interface and use it without having to interpret complex instructions.

Runtime

Run time refers to when a process is executing (running) on a system -Often uses privileged state -May require administrator approval to execute -Systems should restrict APIs from automatically running privileged programs -Can be corrupted by malware

Separation of duties.

Separation of duties. This principle requires that completion of a specified sensitive activity or access to sensitive objects is dependent on the satisfaction of multiple conditions. Separation of duties forces collusion among entities in order to compromise the system.

Source-code fault injection (white box, gray box)

Source-code fault injection (white box, gray box). Fault injection is a technique used to improve code coverage by testing all code paths, especially error-handling code paths that may not be exercised during functional testing. In fault injection testing, errors are injected into the software to simulate unintentional attacks on the software through its environment, and attacks on the environment itself. In source-code fault injection, the tester decides when environment faults should be triggered. The tester then "instruments" the source code by nonintrusively inserting changes into the program that reflect the changed environment data that would result from those faults. The instrumental source code is then compiled and executed, and the tester observes the ways in which the executing software's state changes when the instrumental portions of code are executed. This allows the tester to observe the secure and nonsecure state changes in the software resulting from changes in its environment. The tester can also analyze the ways in which the software's state change results from a fault propagating through the source code. This type of analysis is typically referred to as fault propagation analysis, and involves two techniques of source-code fault injection: extended propagation analysis and interface propagation analysis.

Source code analysis (white box)

Source-code security analyzers examine source code to detect and report software weaknesses that can lead to security vulnerabilities. The principal advantage that source-code security analyzers have over the other types of static analysis tools is the availability of the source code. The source code contains more information than code that must be reverse-engineered from byte code or binary. Therefore, it is easier to discover software weaknesses that can lead to security vulnerabilities. Additionally, if the source code is available in its original form, it will be easier to fix any security vulnerabilities that are found.

Cost/Benefit Analysis

The benefit realized by control versus the cost of the control.

Penetration testing (black box

The portion of security testing in which the evaluators attempt to circumvent the security features of a system. The evaluators might be assumed to use all systems design and implementation documentation, which can include listings of system source code, manuals, and circuit diagrams. The evaluators work under the same conditions as are applied to ordinary user

Software Risk-based security testing

This type of testing should always augment traditional requiremnts-based testing

An element of security testing is to identify software weaknesses so that security violations and noncompliance with security requirements that could cause the software to fail or be out of compliance with any of software security requirements are avoided. True False

True An element of security testing is to identify software weaknesses so that security violations and noncompliance with security requirements that could cause the software to fail or be out of compliance with any of software security requirements are avoided.

One element of security testing is to identify software weaknesses in order to avoid security violations and noncompliance with security requirements that could cause the software to fail or be out of compliance with any of software security requirements. (True or False) True False

True One element of security testing is to identify software weaknesses so that security violations and noncompliance with security requirements that could cause the software to fail or be out of compliance with any of software security requirements are avoided.

Risk of Collusion

Two parties work together to circumvent separation of duties

Vulnerability scanning (black box)

Vulnerability scanning (black box). Automated vulnerability scanning of operating system and application-level software involves use of commercial or open-source scanning tools that observe executing software systems for behaviors associated with attack patterns that target specific known vulnerabilities. Like virus scanners, vulnerability scanners rely on a repository of "signatures," in this case indicating recognizable vulnerabilities. Like automated code review tools, although many vulnerability scanners attempt to provide some mechanism for aggregating vulnerabilities, they are still unable to detect complex vulnerabilities or vulnerabilities exposed only as a result of unpredictable (combinations of) attack patterns. In addition to signature-based scanning, most vulnerability scanners attempt to simulate the reconnaissance attack patterns used by attackers to "probe" software for exposed, exploitable vulnerabilities.

Weakest link.

Weakest link. As in the old saying, "A chain is only as strong as its weakest link," the security of an information system is only as good as its weakest component. It is important to identify the weakest mechanisms in the security chain and layers of defense and improve them so that risks to the system are mitigated to an acceptable level.

White Box

White box. Testing from an internal perspective, i.e., with full knowledge of the software internals; the source code, architecture and design documents, and configuration files are available for analysis.

Residual Risk

risk that still remains after the implementation of controls