Notatki
Konspekt
Designing secure code
Błażej Pietrzak
szwed5@wp.pl
Designing secure code
Two common security mistakes:
Applications are designed by teams of people who do not understand security
Adding security to the application as an afterthought:
It is expensive
Adding security might change the way you’ve implemented features
Adding security might change the application interface
Designing secure code
Why these mistakes are made
Security is boring
Security is often seen as functionality disabler
Security is difficult to measure
Security is usually not the primary skill or interest of the designers and developers creating the product
Designing secure code
Security Principles to Live By:
Establish a security process
Management control and revision control of specifications, code, documentation and tests
Define the product security goals
Consider security as a product feature
Learn from mistakes
Use least privilege
Use defense in depth
Imagine your application is the last application standing, and every defensive mechanism protecting you has been destroyed
Designing secure code
Security Principles to Live By – cont.:
Assume external systems are insecure
Plan on failure
What happens if the firewall is breached?
Death, taxes and computer system failure are all inevitable to some degree. Plan for the event.
Fail to a secure mode
If the attacker knows that he can make your code fail, he can bypass security mechanisms because your failure mode is insecure
Designing secure code
Security Principles to Live By – cont.:
Employ secure defaults
The less often used features should be off by default to reduce potential security exposure
Remember that security features != secure features
Never depend on security through obscurity
Always assume that the attacker has access to all source code and all designs
Designing secure code
Three Final Points
If you find a security bug fix it and go looking for similar issues in other parts of code
Make the fix as close as possible to the location of vulnerability
Cure the problem, not the symptoms
Designing secure code
Security design by Threat Modelling:
Brainstorm the known threats to the system
Rank the threats by decreasing risk
Choose how to respond to the threats
Choose techniques to mitigate the threats
Choose the appropriate technologies from the identified techniques
Designing secure code
Brainstorm the known threats to the system
Two or three hours for the initial brainstorm meeting with group up to 10 people
Have one person lead the meeting – the most security savvy of the team
At least one member from each development discipline: design, coding, testing, documentation
The design and code changes are made after the meeting
Have a overall system architecture on the whiteboard
Designing secure code
The STRIDE Threat Model – categories:
Spoofing identity – illegally accessing and then using another user’s authentication information.
Tampering with data – malicious modification of data like unauthorized changes made to persistent data or data as it flows between two computers over an open network, such as Internet
Designing secure code
The STRIDE Threat Model – categories cont.:
Repudiation – they are associated with users who deny performing an action without other parties having any way to prove otherwise.
Nonrepudiation is the ability of the system to counter repudiation threats.
Example:
If a user purchases an item, he might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user did receive the package.
Designing secure code
The STRIDE Threat Model – categories cont.:
Information disclosure – exposure of information to individuals who are not supposed to have access to it
Example:
A user’s ability to read a file that she was not granted access to and an intruder’s ability to read data in transit between two computers.
Denial of service
Elevation of privilege
Example: Obtaining root account
Designing secure code
Items to Note While Thread Modeling
Title – descriptive and short i.e.: „Attacker accesses a user’s shopping cart”
Threat type(s) – a threat can fall under multiple STRIDE categories
Target – which part of application is prone to the attack
Chance – chance of the threat to occur from 1 (greatest) to 10 (least)
Designing secure code
Items to Note While Thread Modeling – cont.:
Criticality – extent and severity of the damage (some data are invaluable) from 1 (least damage) to 10 (greatest damage)
Attack techniques – How would an attacker manifest the threat?
Mitigation techniques (optional) – What would mitigate such threat? How difficult it is to mitigate?
Mitigation status – Has the threat been mitigated? Valid entries are: Yes, No, Somewhat and Needs Investigating.
Bug number
Designing secure code
Rank the threats by Decreasing Risk
Risk = Criticality / Chance
Choose how to respond to the Threats
Do nothing
Inform the user of the threat
Many users don’t what the right decision is
Users will learn to ignore warnings if they come up to often.
Remove the problem
There is always the next version!
Fix the problem
Designing secure code
Choose techniques to mitigate the Threats (techniques != technologies)
Spoofing identity
Authentication (i.e. X.509 certificates, IPSec, HTTP Basic Authentication, Digest Authentication, DCOM)
Protect secrets
Don’t store secrets
Tampering with data
Authorization (i.e. ACL, Privileges, IP adress restrictions)
Hashes
Message authentication codes
Digital signatures
Tamper-resistant protocols (SSL/TLS, IPSec, DCOM, EFS)
Designing secure code
Choose techniques to mitigate the Threats – cont.:
Repudiation
Digital signatures
Timestamps
Audit trails
Information disclosure
Authorization
Privacy-enhanced protocols
Encryption
Protect secrets
Don’t store secrets
Designing secure code
Choose techniques to mitigate the Threats – cont.:
Denial of service
Authentication
Authorization
Filtering
Throttling – limiting the number of requests to the system
Quality of service – i.e. prioritising the traffic
Elevation of privilege
Run with least privilege
Designing secure code
Defining ACL (Access Control List) Lists:
Determine the resource you use
Determine the business defined access requirements
Determine the appropriate access control technology
Convert the access requirements to access control technology
Designing secure code
ACL consists of ACEs
ACE is:
Subject
Access Rights
Always place deny ACEs at the start of the ACL