Lesson 6-10 Secure Software Design Questions With complete verified solutions already graded A+(PASS GUARANTEED)

Alpha level testing

testing done by the developers themselves

beta level testing

testing done by those not familiar with the actual development of the system

Black box testing

testing form an external perspective with no prior knowledge of the software

Design and Development (A3) phase

the third phase of the security development life cycle, in which you analyze and test software to determine security and privacy issues as you make informed decisions moving forward with your software

External Resources

resources hired on a temporary basis to come into a project, test the application, and report findings

functional testing scripts

step-by-step instructions for a specific scenario or situation

gray box testing

analyzes the source code for the software to help design the test cases

internal resources

resources from the company's organization

secure testing scripts

scripts created specifically for the application being tested

scripts

detailed, logical steps of instructions to tell a person or tool what to do during the testing

system test

test the system and its interaction with other systems

white box testing

tests from an internal perspective with full knowledge of the software

Vulnerability Assessment

examining a product to identify security deficiencies

During the A3 phase

any policy that exists outside of the SDL policy is reviewed

Both the software security group and the centralized information security group

must collaborate on all policies and guidelines

The purpose of testing activities is to

validate the security of software before making the product available

Applications need to be tested not only in the lab or development area but

also in their true operational environment

Security testing is not

static its ongoing

The process of scanning involves

identifying deficiencies anywhere around the system

Security test cases allow a software developer to determine

security issues at the lowest level

External testing, known as beta testing,

allows you to check usability and vulnerabilities in a system

Software security testing techniques are categorized by

white box, gray box, or black box testing

The test environment should mimic the execution environment

as closely as possible

The goal is to build security in, which is less costly than

correcting problems discovered after the software has been deployed.

Active scanner

modifies the hypertext transfer protocol secure (HTTPS) inpute and analyzes thr response to identify vulnerabilities

AppSec

the process of finding, fixing, and preventing security vulnerabilities at the application level

benchmarks

tests used to compare estimated to actual results

code review

a process done to identify security vulnerabilities during software development

control flow analysis

the mechanism used to step through logical conditions in the code

data flow analysis

the mechanism used to trace data from the points of input to the points of output

Design and Development A4 phase

the fourth phase of security development life cycle, in which you will build onto the proper process of security testing and continue to analyze necessities at the security level

documenation

details and guides that are necessary to support the ongoing use of the software

dynamic analysis

application security testing to identify vulnerabilities within a product application

explortatory tests

done by the development tester to continually assess the quality of his or her work

open source security testing methodology manual

a manual that provides templates and standards used when developing a test strategy

OWA SP Zed Attack Proxy

an open source security tool used widely by software security developers

passive scanner

silently analyzes all the hypertext transfer protocol (HTTP) requests and responses passing through the web application security tool

pull request

a request to merge your code into another branch

scheduled tests

mandatory requirements testing to validate the security of the software and associated system(s)

SonarQube

open-source platform for static code analysis that can detect bugs, code smells, vulnerabilities, and hotspots in over 25 programming languages

Spider

identifies inputs and supplies those to the scanning components of the security tools

Static Analysis

the analysis of computer software that is performed without executing programs

Zeb Attack Proxy ZAP

free, open source penetration testing tool

Quality assurance testing occurs

throughout the entire SDLC process

The three specific test type categories are

benchmarks, scheduled test, and exploratory tests

code review

finds and fixes a large number of security issues before the code is tested or shipped

The four basic techniques for code review

automated scanning, manual penetration testing, static analysis, and manual code review

AppSec

describes finding, fixing, and preventing vulnerabilities at the application level

AppSec difficult to scale for

large organizations

what is the goal of code review

To catch bugs early on to decrease the cost of fixing them

Proxy scripts

are effectively used to communicate a

web security bug or web security control

Active and passive scanner scripts

identify common vulnerabilities that are specific to your application

SonarQube give developers the ability to

continuously inspect the quality of code they produce

After the developer is done coding a functionality, when should code review be completed?

within hours or the same day

Authenticated scans

scans that require software to log onto a system to scan t

external scans

scans that target security issues that are found outside the firewall

internal scans

scans to identify security issues that a malicious attacker could exploit from inside the network

intrusive target search

scans to exploit a vulnerability when its identified

nmap

a tool used for network scanning and security auditing

open source software security

identifying software security within in house developed software

penetration testing

an authorized attack of an application to determine its weakness

range

a networking laboratory created to conduct vulnerability analysis testing

ship (A5) phase

the fifth phase of the security development lifecycle that verified that the product complies with security policies and procedures

SQL injection

a code injection that migh destroy your software

target machine

a virtual space to practice identifying attack surfaces of the machine

virtualization

technology used to create software services

vulnerability scan

explore application and databases to attempt to identify weaknesses

vulnerability sites

websites with information on the latest known vulnerabilities

The Ship A5 phase of the SDLC occurs

when the security team perfoms its final analysis and security review on the applications or software

Policy compliance analysis verifies

the product meet quality standards before the release of an application or software

Vulnerability scanning tools attempt

to identify weakness in the applicaitons

penetration testing simulates

the actions of a hacker to attempt to identify vulnerabilities within the software

the four phases of penetration testing are

assess, identify, evaluate, and plan and deploy

Active and passive analysis techniques are both

useful during vulnerability testing

Creating a network laboratory allows you

to test within a controlled environment without written authorization and permissions

Which activity in the Ship (A5) phase of the security development cycle sets requirements for quality gates that must be met before release?

A5 policy compliance analysis

Common vulnerability soring system CVSS

a model used to assess the severity of a vulnerability

legacy code

old code that is no longer supported

merger and aquisition (M&A)

when companies consolidate

Product Security Incident Response Team (PSIRT)

the team that receives, investigates, and reports security vulnerabilities

Post release support phase

the phase of the SDLC in which organizations prepare for vulnerabilities after the product has been released

Post release P SIRT Response

responds to software product security incidents that involve the external discovery of post release software vulnerabilities

software security champion SSC

an expert on promoting security awareness, best practices, and simplifying software security

software security evangelist (S SE)

an expert to promote awareness of products to the wider software community

Code Review

a practice of verification involving review of an organization's secure code to identify vulnerabilities

construction

a function of OpenSAMM centered around how organizations define goals and create software within development projects

Code review

a practice of verification involving review of an organization's secure code to identify vulnerabilities

construction

a function of OpenSAMM centered around how organizations define goals and create software within development projects

deployment

a fuction of OpenSAMM centered around how an organization releases software

design review (DR):

a practice of verification involving inspecting artifacts that were created from the design process

digital enterprise

technology used to enable and improve business activities

education and guidance (EG)

a practice of governance involving increasing security knowledge among software developers

environment hardening (EH):

a practice of deployment involving implementing controls for the operating environment of an organization's software

governance

a function of OpenSAMM centered on how organizations manage overall software development activities

Open Software Assurance Maturity Model (OpenSAMM

an open framework to help organizations implement software security tailored to the organization's specific risks

Operational Enablement (OE)

a practice of deployment involving identifying and capturing security-relevant information

policy and compliance (PC

a practice of governance involving setting up security and compliance control

secure architecture (SA)

a practice of construction involving activities to prompt secure-by-default designs during the design process

security requirements (SR)

a practice of construction involving the promoting of inclusion security requirements during software development

security testing (ST)

a practice of verification involving testing the organization's software in its environment