|
|
|
Błażej Pietrzak |
|
szwed5@wp.pl |
|
|
|
|
|
|
|
|
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 |
|
|
|
|
|
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 |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
|
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 |
|
|
|
|
|
|
|
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 |
|
|
|
|
|
|
|
|
|
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 |
|
|
|
|
|
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 |
|
|
|
|
|
|
|
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 |
|
|
|
|
|
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 |
|
|
|
|
|
|
|
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. |
|
|
|
|
|
|
|
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 |
|
|
|
|
|
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) |
|
|
|
|
|
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 |
|
|
|
|
|
|
|
|
|
|
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 |
|
|
|
|
|
|
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) |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
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 |
|
|
|
|
|
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 |
|
|
|
|
|
ACL consists of ACEs |
|
ACE is: |
|
Subject |
|
Access Rights |
|
Always place deny ACEs at the start of the ACL |
|