1. Secure Implementation In Real Life
EPAM Security Excellence Initiative
Andrey Chechel
August, 2015

2. AGENDA
1. Why it is important to take care about security? 2. Meet Security Development Lifecycle (SDL) 3. Implementation checklist 4. Know your tools

3. INTRODUCTION
WHY Security
Is so important?

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. FINANCIAL LOSSES DUE TO HACKING
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)

6. TERMINOLOGY
Threats
Vulnerabilities
Exploits

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. MEET SDL
EPAM Approach TO
SECURE DEVELOPMENT

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. Element S T R I D E STRIDE MODEL External Entity Process Data Store
All threats are categorized to:
Spoofing
Tampering
Repudiation
Information Disclosure
Denial of Service
Elevation of Privilege
Element
External Entity
Process
Data Store
Dataflow S V T R I D E

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. IMPLEMENTATION CHECKLIST
BACK TO SECURE
CODING GUIDELINE

15. WRITING SECURE CODE 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)!

16. WHERE YOUR CODE IS LOCATED?
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

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. WHO CALLS THIS CODE? 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

19. Always make sure there are limits!
WHAT RESOURCES ARE USED BY YOUR CODE
Memory
Storage
CPU
Always make sure there are limits!

20. WHAT ERRORS CODE EMITS?
Errors are sensitive data
Who is error’s audience?
Informative (for the audience) but conservative (do not disclose too much)

21. Do we need security Audit?
WHAT IS CODE FOOTPRINT?
What stays in memory
Do cleanup
What goes to Logs
Do we need security Audit?
Don’t forget Repudiation

22. FURTHER ASPECTS Protect code itself (obfuscation, encryption)
Deployment (by default, tools)
Documentation (user, admins, support)

23. EXAMPLE
KNOW YOUR TOOLS

24. EXAMPLE: CAS IN .NET
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

25. CAS FUNCTIONS 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

26. Application Framework Platform Hardware KNOW YOUR TOOLS
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!
Application
Framework
Platform
Hardware

27. RESOURCES AND CHECKLISTS
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

28. .. AND FINALLY

29. DON‘T FORGET OUR MAJOR GOAL!

30. THANK YOU!