0% found this document useful (0 votes)
5 views5 pages

Secure Software Design Chapter 3

Uploaded by

b2ntegami
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views5 pages

Secure Software Design Chapter 3

Uploaded by

b2ntegami
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

Secure Software Design Chapter 3: Security Assessment (A1) — Notes

SDL Activities and Best Practices — Phase A1 is the first phase of the Secure Development Lifecycle,
focused on planning security and privacy before a single line of code is written.

3.1 — Loop in security early

The security team joins the project at the very start to identify risk, plan milestones, and reduce cost of
fixes later.

3.2 — Discovery meeting

An SDL kick-off where all stakeholders align on security requirements, CIA goals, threats, regulations, and
resource needs.

3.3 — SDL project plan

Initial security milestones are documented and integrated into the overall development schedule for
ongoing planning.

3.4 — Privacy Impact Assessment

The PIA evaluates how the software collects, stores, and transfers PII — and ensures compliance with
privacy laws from the start.

3.5 — Success factors & metrics

Five key success factors guide phase evaluation. Deliverables are formally documented. Metrics track SDL
progress over time.

3.6 — Summary

Security and privacy requirements defined in A1 form the baseline for all future SDL phases, minimizing
schedule disruption.

The four core questions answered in Phase A1

1. How critical is the software to the customer's mission?

2. What security objectives are required — confidentiality, integrity, availability (CIA)?

3. What regulations and policies determine what must be protected?

4. What threats exist in the environment where the software will operate?

Phase A1 deliverables

Product risk profile

Estimates the true cost of the product across markets and security liabilities.

SDL project outline

Maps security milestones to the development schedule.


Applicable laws & regulations

Formal review with legal sign-off on all compliance requirements.

Threat profile

Assumptions about the operating environment and potential attack vectors.

Certification requirements

FIPS, ISO 27001, and other certifications needed for the product.

List of third-party software

Identifies dependencies to include in the threat profile.

Metrics template

Template for periodic reporting to management on SDL progress.

PIA privacy impact ratings (Microsoft SDL)

P1 — High privacy risk

Feature stores/transfers PII or error reports, monitors users with ongoing anonymous data transfer,
changes settings, or installs software.

P2 — Moderate privacy risk

The only privacy-affecting behavior is a one-time, user-initiated, anonymous data transfer (e.g., clicking a
link to visit a website).

P3 — Low privacy risk

No behaviors affect privacy. No anonymous or personal data is transferred, no PII is stored, no settings
changed, no software installed.

Key terms and definitions

All major terms introduced in Chapter 3.

SDL

Security Development Lifecycle (SDL)

A structured process for integrating security activities into every phase of software development. Phase
A1 (Security Assessment) is the first phase — it sets the direction for all subsequent phases.

SDL

SDLC — Software Development Life Cycle


The broader development process into which the SDL is integrated. The security team must be included
in the SDLC kick-off to ensure security is built in, not bolted on.

Phase A1

Security Assessment (A1)

The first phase of the SDL, sometimes called the "discovery phase." Its purpose is to identify the
product's risk profile, needed SDL activities, security milestones, and initial privacy requirements.

Phase A1

Discovery meeting

An SDL kick-off meeting where all key stakeholders align on security and privacy requirements, threat
profiles, regulations, resource needs, and milestones before development begins.

Privacy

PIA — Privacy Impact Assessment

A process that evaluates how software collects, stores, accesses, and transfers Personally Identifiable
Information (PII). It ensures privacy is a fundamental design consideration rather than an afterthought.

Privacy

PII — Personally Identifiable Information

Any data that can identify a specific individual — names, addresses, email, IP addresses, and more.
Software that handles PII must apply strict privacy controls and comply with applicable regulations.

Privacy

The four C's of privacy design

Comprehension, Consciousness, Control, and Consent — the principles used to educate stakeholders on
privacy expectations at the discovery meeting.

Privacy

Prominent notice vs. discoverable notice

A Prominent Notice is designed to catch a user's attention (e.g., a pop-up inviting them to review privacy
settings). A Discoverable Notice must be sought out (e.g., a privacy statement link in a help menu).

Privacy

Privacy impact ratings (P1, P2, P3)

A Microsoft SDL practice that rates the privacy sensitivity of a feature: P1 = high risk (stores/transfers PII),
P2 = moderate risk (one-time anonymous transfer), P3 = low risk (no privacy-affecting behaviors).

Security

CIA — Confidentiality, Integrity, Availability


The three core security objectives. Confidentiality ensures data is accessed only by authorized parties;
Integrity ensures data is accurate and unaltered; Availability ensures systems are accessible when
needed.

Security

Product risk profile

A baseline assessment of security risks associated with a software product, based on its importance to
customers, the data it processes, applicable regulations, and the markets in which it will operate.

Security

Threat profile

Documentation of the assumed operating environment and potential threats facing the software,
including perceived use cases, customer integrations, and security exposure through dependencies on
other software.

Security

Principle of least privilege

Access to user data should be limited to those with a legitimate business need ("need to know").
Administrators, database managers, and third parties should only receive the minimum data necessary
for their specific business purpose.

Compliance

FIPS — Federal Information Processing Standards

U.S. government standards for computer security. Products used in federal contexts may need FIPS
compliance, which can be affected by the use of open-source library dependencies.

Compliance

CPO — Chief Privacy Officer

An executive role responsible for privacy compliance and strategy. The CPO is an ideal partner for
translating privacy regulations into software requirements within the SDL.

Compliance

Data sensitivity assessment

The process of evaluating what regulatory legislation or policies apply to the software being developed
— a prerequisite step before building the PIA.

Metrics

Phase A1 SDL metrics


Suggested measurements for this phase: (1) time (weeks) when security team was looped in, (2) % of
stakeholders participating, (3) % of SDL activities mapped to development activities, (4) % of security
objectives met.

You might also like