1 Secure Implementation In Real Life EPAM Security Excellence Initiative Andrey Chechel August,...
-
Upload
rodger-long -
Category
Documents
-
view
216 -
download
3
Transcript of 1 Secure Implementation In Real Life EPAM Security Excellence Initiative Andrey Chechel August,...
1
Secure ImplementationIn Real Life
EPAM Security Excellence InitiativeAndrey Chechel
August, 2015
2
AGENDA
1. Why it is important to take care about security?2. Meet Security Development Lifecycle (SDL)3. Implementation checklist4. Know your tools
3
IS SO IMPORTANT?WHY SECURITY
INTRODUCTION
4
FOCUS ON THE CUSTOMER
What is Safety?
Wikipedia:“Safety is the state of being ‘safe’, the condition of being protected against physical, social, spiritual, financial, political, emotional, occupational, psychological, educational or other types or consequences of failure, damage, error, accidents, harm or any other event which could be considered non-desirable.”
We are developers and in our work we consider Safety or Security as an important Quality Attribute.
Security Breach -> Unpredictable Impact -> Dissatisfied Customer
5
Cybercrime as a percentage of GDP (as of 2014):• Germany – 1.60%• Netherlands – 1.50%• USA – 0.64%• China – 0.63%• Russia – 0.10%
Top 5 declared losses in 2012:• Sony – $171 million (attack on PlayStation network)• Citigroup – $2.7 million (stolen account
information)• Stratfor – $2 million (confidential info, credit cards)• AT&T – $2 million (stolen money)• Brokerage scam – $1 million (stolen identities,
money)
FINANCIAL LOSSES DUE TO HACKING
6
• Threats
• Vulnerabilities
• Exploits
TERMINOLOGY
7
REACTIVE SECURITY VS. PROACTIVE SECURITY
• Security = Security Features
• Security issue is just a bug
• Fixing instead of preventing
• Focus on known issues only
• No understanding of customer values/needs
• Developers/QA engineers are not aware of security problems, coding best practices etc.
REACTIVE SECURITY(react when it is too late)
• Probability of security breaches is high
• Significant issues affect company’s reputation
• Impact on customers’ business, money, clients
• Risk Assessment
• Security/Privacy Requirements
• Quality Gates
• Risk Analysis
• Threat Modeling
• Attack Surface Analysis
• Mitigation plans
• Implementation according to the models
• Repeating Security Activities (Reviews, Verification, Testing)
PROACTIVE SECURITY(know App security level)
• We perform explicit activities to protect
• It makes customers confident in their product
• No painful Security Audits!!
8
SECURE DEVELOPMENTEPAM APPROACH TO
MEET SDL
9
SECURITY DEVELOPMENT LIFECYCLE
Are you aware of Microsoft Security Development Lifecycle (SDL)? It’s a good point to start with
Microsoft SDL provides very adjustable process out of the box. It will help to deal with:
• Security requirements and data privacy• Attack surface and possible vectors• Potential attackers• Potential threats and mitigations• Security issues prioritization• Testing, reviews and so on..
10
SECURITY-RELATED ACTIVITIES IN SDLC
SDL activities applied to SDLC:
11
THREAT MODELING
A little bit of statistics
Potential threats found:• 16 - Spoofing• 4 - Tampering• 7 - Repudiation• 7 - Information Disclosure• 18 - Denial of Service• 13 - Elevation of Privileges
12
STRIDE MODEL
All threats are categorized to:1. Spoofing2. Tampering3. Repudiation4. Information Disclosure5. Denial of Service6. Elevation of Privilege
Element
External Entity
Process
Data Store
Dataflow
S
V
V
T
V
V
V
R
V
V
V
I
V
V
V
D
V
V
V
E
V
13
SECURE IMPLEMENTATION
• Follow Mitigation Plan in every Feature• Adopt Security Best Practices and Secure Code Standards/Techniques • Perform regular code walkthrough with developers and system architects• Perform regular automated static code analysis using tool-assisted approach (part of CI)• Perform Fuzz Testing – “dumb” or “smart” based on input format• Take care of data (based on Privacy Requirements)• Prepare Security-related Documentation
14
CODING GUIDELINEBACK TO SECURE
IMPLEMENTATION CHECKLIST
15
• No code – no problem
•When you start writing the code you have to think about…
First – always refer to Threat models (secure design, privacy requirements)!
WRITING SECURE CODE
16
• Method, class, library
• Behind an interface or not
• Client/server side
• How is it exposed to the world
• What priority of your code
• Who is going to use it (security context)
Choose the right place in application
WHERE YOUR CODE IS LOCATED?
17
WHAT YOUR CODE IS ABOUT?
“Type” of Code What to Consider Examples
Data Input Processing Input Validation Buffer sizes, data checks, encoding, canonicalization, sanitizing, parsers
Data Output Transfer protection, Permissions on data
SSL/TLS, WCF Message security, row-level filtering, remove private fields
Data Persistence Protection (including in-memory!) Encryption, MACs, ACLs
Security Feature • Implement very carefully• Don’t invent things• Consult with design
Authentication protocols, Authorization mechanisms, cryptography
Adding New Dependency (on a component, an external system etc.)
• Do you really need it?• Do you trust it?
3rd party library, call to other system
18
Where the code is called?
Client/Server
What is security context?
Logical vs Physical: Business Roles vs OS-level permission
CAS, Authentication/Authorization
Apply least privileges or remove
powerful code
WHO CALLS THIS CODE?
19
Memory
Storage
CPU
WHAT RESOURCES ARE USED BY YOUR CODE
Always make sure there are limits!
20
• Errors are sensitive data
•Who is error’s audience?
• Informative (for the audience) but conservative (do not disclose too much)
WHAT ERRORS CODE EMITS?
21
What stays in memory
Do cleanup
What goes to Logs
Do we need security Audit?
Don’t forget Repudiation
WHAT IS CODE FOOTPRINT?
22
• Protect code itself (obfuscation, encryption)
• Deployment (by default, tools)
• Documentation (user, admins, support)
FURTHER ASPECTS
23
KNOW YOUR TOOLSEXAMPLE
24
Microsoft Code Access Security (CAS) in a nutshell:
• Minimizes the damage that can result from security vulnerabilities in your code
• Enforces the varying levels of trust on code, thus protects from malicious code:
• allows code from unknown origins to run with protection
• reduces the likelihood that your code will be misused by malicious or error-filled code
EXAMPLE: CAS IN .NET
25
• Defines permissions for system resources
• Enables code to demand that its callers have specific permissions
• Enables code to demand that its callers possess a digital signature
• Enforces restrictions on code at run time
CAS FUNCTIONS
26
There are several levels of protection which can be applied to your application:
• Hardware (Physical access, Protocols)
• Platform (APIs, Configuration, ACLs)
• Framework (Security mechanisms, Proven algorithms)
• Application (Validation, Data integrity etc.)
Don’t invent – just know and use existing mechanisms!
KNOW YOUR TOOLS
Application
Framework
Platform
Hardware
27
• SDL implementation best practices
•MSDN Security Coding Guidelines
• OWASP Secure Coding Practices
• Security best practices for particular platforms, technologies, products, e.g.
– Java
– WCF
– Azure
RESOURCES AND CHECKLISTS
28
.. AND FINALLY
29
DON‘T FORGET OUR MAJOR GOAL!
30
THANK YOU!