Software Security Notes

Página 1

Security Requirements

Protect data (encrypt)

Trust nothing and no one (validate and check authorization)

Identify, authenticate and authorize

Escape all input

Manage secrets (protected stores)

MFA and care with passwords (rules, storage, reuse, compromised, …)

Enforce Web app best practices (cookies, security headers, TLS level, …)

Use trusted third-party components and libraries

Check for acceptance, never for rejection

Separate control instructions from data

Página 2

Security Incident Taxonomy

Página 3

Top Secure Coding Practices

Validate input

from all untrusted data sources (including command line arguments, network interfaces, environmental variables, and user-controlled files).

Heed compiler warnings

use the highest warning level and version of your compiler and eliminate warnings by modifying code.

use static and dynamic analysis tools to detect and eliminate additional security flaws.

activate security protection flags.

Architect and design for security policies

create a software architecture and design your software to implement and enforce security policies (e.g. different privilege levels).

Keep it simple

keep the design as simple and small as possible.

Default deny

base access decisions on permission rather than exclusion.

Adhere to the principle of least privilege

every process should execute with the least set of privileges necessary to complete the job and in the shortest time.

Sanitize data sent to other systems

sanitize all data passed to other subsystems, since it can contain unintended information.

Practice defense in depth

manage risk with multiple defensive strategies.

verify everything with multiple rules and implementations.

Use effective quality assurance techniques

techniques like input fuzz testing, penetration testing, and source code audits.

Adopt a secure coding standard

develop and/or apply a secure coding standard for your target development language and platform.

do not rely in very recent or seldom used languages/frameworks.

Define security requirements

identify and document security requirements early in the development life cycle.

Model threats

use threat modeling to anticipate the threats to which the software will be subjected.

Página 4

Goals of Threat Modeling

Conception of a secure design from the start

Documentation of threats and mitigations

Shared understanding of threats spread to all of the development team

Threats to guard against are included in the requirements

Creation of security mechanisms to include in the design

More efficient effort management

Basis for prescribing secure implementation practices

Basis for testing system security after implementation

How to Create a Threat Model

What are we building?

understand the system, description and architecture

assets, data flows, processes, people and roles

drilldown details

What can go wrong?

identify threats and assumptions that apply to the system's scope

use databases of attacks, adversary tactics and techniques

create attack trees

What are we going to do?

turn findings into actions

prioritize risks and mitigate using security mechanisms

Did we do a good enough job?

test, log and monitor

Página 5

Threat Modeling Steps

Vision

Characterize the system (scenarios, use cases, use stories, actors, assets, processes, data stores, data flows, ...)

Can you tell a story without edits?

Does it match reality?

Diagram

Threat Identification

Mitigation

Validation