WGU D487 Computer Science Terms & Definitions for SAMM QUESTIONS AND CORRECT DETAILED ANSWERS (VERIFIED ANSWERS) ALREADY GRADED A+

A1 - Security Assessment

Is the first phase of SDL. This is the phase in which the project team identifies the project risk profile and the needed SDL activities, in some SDLs it is called the discovery phase.

A2- Architecture

At this stage of the SDL, security is looked at more in terms of business risks, which inputs from the software security group and discussions with key stakeholders in the SDLC.

A3 - Design and Development

In this phase the end user of your software is foremost in your mind. During this phase, you will do an analysis of policy compliance, create the test plan documentation, , update your threat models if necessary, conduct a design security analysis, and do a privacy implementation assessment so you can make informed decisions about how to deploy your software securely and establish development best practices to detect and remove security and privacy issues early in the development lifecycle.

A4 - Design and Development

This phase can be mapped to the "readiness" phase in a typical software development life cycle (SDLC). In this phase we start the continuation of policy compliance analysis.

A5 - Ship

In the final policy compliance review, the SDL policy will be reviewed to ensure that the policy provides specific requirements based on different development criteria, such as product type, code type, and platform. A vulnerability scan will look for any remaining vulnerabilities in your software and associated systems and report potential exposure.

Scrum Master

A person who ensures that the team is productive, facilitates the daily Scrum, enables close cooperation across all roles and functions, and removes barriers that prevent the team from being effective

Product Owner

Key stakeholder. Represents the users you're building the solution for. Often someone from the product management or marketing department.

Scrum Team

A small group of up to 9 cross-functional developers that is responsible for developing, testing, and delivering software at the end of a scrum sprint. The team determines a sprint's major goals and deliverables.

Scrum Ceremonies

Sprint Planning - Product owner top ideas

Sprint Review - Shows what accomplished during sprint

Sprint Retrospective - How well is scrum working

Daily Scrum - Helps the team stay on track

Scrum Artifacts

Product Backlog - List of desired features for a product

Sprint backlog - List of tasks to be completed

Burndown Chart - Updated after every sprint

Sprint

A fixed length of time period in which a specific set of work is completed. It is a time-boxed iteration, typically lasting between one to four weeks, with two weeks being the most common duration.

DREAD

D - Damage Potential - How catastrophic is the event?

R - Reproducibility - How easy to reproduce the attack?

E - Exploitability - How easy to launch the attack?

A - Affected Users - What percentage of users are affected?

D - Discoverability - How easy it is to find the vulnerability?

STRIDE-Per-Element

Concentrates on each element of a diagram. Based on threats common to each type of element.

STRIDE-Per-Interaction

Concentrates on the interactions of a system. Leads to threats that are easier to understand.

OCTAVE

Operationally

Critical

Threat

Asset

Vulnerability Evaluation

*Risk Analysis Framework

*Evaluates Organizations

PASTA

Process for

Attack

Simulation

Threat Analysis

*Targeted towards medium to large sized companies

*Mature companies

*Having security knowledge

*Iterative

*Outcome is geared towards management

STRIDE Model

S - Spoofing - How do we ensure a users authenticity?

T - Tampering - How do we check the integrity of our data?

R - Repudiation - How do we audit actions in our systems?

I - Information Disclosure - How do we keep data confidential?

D- Denial of Service - How do we prevent resource from being maliciously exhausted?

E - Elevation of privilege - How do we stop someone from getting additional access that they shouldn't be authorized to gain?

Building Security in Maturity Model (BSIMM)

A study of real-world software security initiatives organized so that you can determine where you stand with your software security initiative and how to evolve your efforts over time.

Static Analysis

Source code of an application is reviewed manually or with automatic tools without running the code.

Dynamic Analysis

Analysis and testing of a program occurs while it is being executed or run.

Software Assurance Maturity Model (SAMM)

A roadmap and a well-defined maturity model for secure software development and deployment, along with useful tools for self-assessments and planning.

OWASP ZAP

An open source web application security scanner. can be used as a proxy to manipulate traffic running through it (even https).

ISO/IEC 27001

Organization for standardization (ISO) standard is the benchmark for information security today.

ISO/IEC 17799

establishes guidelines and general principles for initiating, implementing, maintaining, and improving information security management in an organization.

ISO/IEC 23034

is a multi-part standard that provides guidance to organizations on how to integrate security into their application management processes. It's applicable to all applications, whether developed in-house, acquired from third parties, or outsourced.

Every-Sprint Requirement

The first category consists of the SDL requirements that are so essential to security that no software should ever be released without these requirements being met. This category is called the every-sprint category. Whether a team's sprint is two weeks or two months long, every SDL requirement in the every-sprint category must be completed in each and every sprint, or the sprint is deemed incomplete, and the software cannot be released.

Bucket Requirements

The second category of SDL requirement consists of tasks that must be performed on a regular basis over the lifetime of the project but that are not so critical as to be mandated for each sprint. This category is called the bucket category and is subdivided into three separate buckets of related tasks. Currently there are three buckets in the bucket category-verification tasks (mostly fuzzers and other analysis tools), design review tasks, and planning tasks. Instead of completing all bucket requirements each sprint, product teams must complete only one SDL requirement from each bucket of related tasks during each sprint.

One-Time Requirements

There are some SDL requirements that need to be met when you first start a new project with SDL-Agile or when you first start using SDL-Agile with an existing project. These are generally once-per-project tasks that won't need to be repeated after they're complete. This is the final category of SDL-Agile requirements, called the one-time requirements.

The one-time requirements should generally be easy and quick to complete, with the exception of creating a baseline threat model.

SDLC Phase 1: Planning

The initial stage of software development involves defining the software's purpose and scope, much like pinpointing our destination and plotting the best route. We uncover the tasks at hand during this phase and strategize for efficient execution.

The team collaborates to understand the end-users' needs and the goals the software should meet. Essentially, we ask, "What problem will this software solve?" and "What value will it offer to the user?"

SDLC Phase 2: Requirements

Seeks to identify and record the precise requirements of the final users. In this phase, the team is looking to answer, "What are the expectations of our users from our software?" This is called requirements gathering.

The project team collects information from stakeholders, including analysts, users, and clients. They conduct interviews, surveys, and focus groups to understand the user's expectations and needs. The process involves not only asking the right questions but also accurately interpreting the responses.

After collecting the data, the team analyzes it, distinguishing the essential features from the desirable ones. This analysis helps the team understand the software's functionality, performance, security, and interface needs.

SDLC Phase 3: Design

The development team is responsible for software engineering and outlines the software's functionality and aesthetic. This ultimately results in the software product. The emphasis lies on outlining the software's structure, navigation, user interfaces, and database design. This phase ensures that the software is user-friendly and performs its tasks efficiently.

Key activities include crafting data flow diagrams, constructing entity-relationship diagrams, and designing user interface mock-ups. The team also identifies system dependencies and integration points. They also set the software's limitations, such as hardware constraints, performance requirements, and other system-related factors.

SDLC Phase 4: Implementation

is when engineers and developers get down to business and start converting the software design into tangible code.

This development phase aims to develop software that is functional, efficient, and user-friendly. Developers use an appropriate programming language, Java or otherwise, to write the code, guided by coding guidelines. This document, acting as a roadmap, ensures the software aligns with the vision set in earlier phases.

SDLC Phase 5: Testing

Consider this phase of the SDLC as a stringent quality inspection on a production line. It is when vulnerabilities are uncovered. Software testing involves a thorough examination of the software for any bugs or glitches that might have slipped through during coding. The aim is to ensure flawless software operation before it reaches the end-users. And even identify opportunities for enhancement.

SDLC Phase 6: Deployment

This phase involves rolling out the meticulously tested and fine-tuned software to its end-users.

SDLC Phase 7: Maintenance

This phase is characterized by constant assistance and improvement, which guarantees the software's best possible functioning and longevity and ensures it meets customer expectations.

The primary focus is to adapt to the software's changing needs. This adaptation involves responding to user feedback, resolving unexpected issues, and upgrading the software based on users' evolving requirements. It's a continuous process of refining and adapting, much like a gardener tending to their garden.