Building Security Design Principles

© 2021 SEC Consult | All rights reserved
A deep-dive into security design principles | Responsible: T. Kerbl | Version / Date: 1.0 / 2021-01 Confidentiality Class: Public
WELCOME!
Building a secure architecture
A deep-dive into security design principles
January 21, 2021 | with Thomas Kerbl
1

• 20+ years experience in information security
• 50+ speeches
• Service Owner for
„Secure Software Development Consulting“
• Teamleader
• Security Analyst, Security Architect
Education
• MSc @ Technikum Vienna, Specialization in
Multimedia & Software Development
• Dipl. Ing @ Hagenberg, Specialization in
Computer- and Media Security
Certificates
• Accredited ÖNORM A 7700 Auditor
• ISTQB Certified Tester
• ISAQB Certified Professional for
Software Architecture
• ISSECO Certified Professional for
Secure Software Engineering
• PCiIAA Practitioner Certificate in
Information Assurance Architecture
Thomas Kerbl
Principal Security Consultant
t.kerbl@sec-consult.com
https://twitter.com/dementophobia
2

➢ Principle: A rule or belief governing one's behavior.
➢ High level concepts that guide security design
➢ Agnostic concerning
• Technology
• Mechanism
• Development Methodology
• Industry / Type of Organization
What are Security Design Principles?
AVAILABILITY
CONFIDENTIALITY
INTEGRITY
Choose your principles carefully for each protection profile!
3

➢ Multiple security controls on multiple layers
➢ If one control breaks, others mitigate the impact
➢ Mechanisms must not rely on each other
➢ No single point of failure from a defense perspective
Security Design Principles – Defense in Depth
Build as many walls as required around your crown jewels!
4

➢ Also known as: No Security by Obscurity
➢ Security does not depend on concealment of algorithms and architecture
➢ The application shall remain secure even when the architecture is made public
➢ Does not include credentials for authentication and cryptographic secrets
Security Design Principles – Open Design
This does not imply, that the source code must be open source,
but you should be comfortable even if your source code leaks!
5

➢ External data should be viewed as not trustworthy
➢ Many vulnerability classes can be eliminated
through proper input validation
➢ All validation mechanisms must be at least
implemented on server side
➢ Rules must be strict, but still allow all valid use cases
Security Design Principles – Principle of general mistrust
Regardless whether data originates from a user or a backend system,
input data must always be subjected to strict validation.
6

➢ Actors are given the minimum level of access rights
➢ Privileges are only granted as long as required
➢ Potential damage caused by actors (real or compromised) is limited
➢ Example: Never browse the web with administrative privileges
Security Design Principles – Least Privilege
Assigning rights to actors beyond the necessary scope can allow
actors to obtain or modify information in unwanted ways.
7

➢ Critical operations require two or more authenticated actors
➢ If only one secret gets compromised, no damage can be done
➢ Examples for implementation:
• Two or more key cards to access Hardware Security Module (HSM)
• Two or more cryptographic keys are required to decrypt a message
• Two or more people split a passphrase for a system
Security Design Principles – Separation of Privilege
Ensure that no single actor can perform critical operations on their own!
8

➢ Also known as: KISS – Keep it small and simple
➢ Also known as: Minimize the attack surface
➢ Only functionality defined by use cases is implemented
➢ Small systems are less prone to error and easier to audit
➢ Only include libraries and frameworks that you really need
Security Design Principles – Economy of Mechanism
The more functionality that is built in,
the more potential points of entry attackers have.
9

➢ Limit shared resources and information paths
➢ Compromise of one component does not affect other components
➢ Examples for implementation
• Multitenancy
• Sandbox environments
• Separate endpoints for authentication of administrators and users
Security Design Principles – Least Common Mechanism aka. Isolation
Choosing the right level of isolation is the result of
a sensible trade-off between cost and security.
10

➢ Every access to an object must be checked for authority
➢ Permissions must be checked with every request
➢ Examples:
• Changed permissions will be applied immediately
• Force logout of user to refresh permissions during login
Security Design Principles – Complete Mediation
Don’t use caches for your permissions or force updates!
Changes will only be applied after cache is updated.
11

➢ Invest your resources where they matter most
➢ Attackers are more likely to attack weak spots
➢ A single high-risk vulnerability can put the whole system in jeopardy
➢ Consider the weakest link first in all your security decisions
Security Design Principles – Secure the weakest link first
Put yourself into the perspective of the attacker.
Where would YOU break into the system?
12

➢ If the application fails it shall do so securely
➢ Failing safe involves restoring to a secure state
➢ Attackers cannot gain access and obtain information during a failure
➢ Confidentiality and integrity shall remain although availability was lost
Security Design Principles – Fail Safe
Anticipate failures and handle them in your application.
Use last resort error handlers for unexpected failures!
13

➢ Make your systems easy to use in a secure fashion
➢ Security mechanisms should be as unintrusive as possible
➢ Examples:
• Allow copy/paste from password stores
• Provide guidance for the creation of strong passwords
• Provide secure defaults
Security Design Principles – Psychological acceptability
If you make the life of users too complicated,
they will find ways to circumvent important security mechanisms.
14

➢ Don’t apply localized patches to systemic problems
➢ Identified vulnerabilities must be eliminated at their root
➢ Perform root cause analysis for all new types of vulnerabilities
➢ This should be part of a well-defined security defect life-cycle
Security Design Principles – Eliminate root causes
Patching a vulnerability locally fixes one issue.
Eliminating the root cause improves the whole architecture.
15

➢ Shared services should be properly validated and considered secure
➢ Invest in security once, benefit often
➢ Using those components does not introduce new vulnerabilities
➢ Provide guidance on how to use them in a secure fashion
Security Design Principles – Leverage existing components
Components can be many things:
Infrastructure, Services, Frameworks, Libraries, Functions, etc.
16

Recommended Reading
@Dementophobia
Follow me for Updates!
A deep dive into Secure Software Development
based on OWASP SAMM
https://r.sec-consult.com/SSDLC
https://www.heise.de/hintergrund/
Sichere-Software-entwickeln-mit-
OWASP-SAMM-4918292.html
17

18

Q&A
ASK ME ANYTHING!
Thomas Kerbl
t.kerbl@sec-consult.com
https://twitter.com/dementophobia
https://at.linkedin.com/in/thomas-kerbl-2ab81648
19
19

Building Security Design Principles

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Building Security Design Principles

Ähnlich wie Building Security Design Principles (20)

Mehr von SBA Research

Mehr von SBA Research (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Building Security Design Principles