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

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

INTRODUCTION WHY Security Is so important?

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

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)

TERMINOLOGY Threats Vulnerabilities Exploits

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!!

MEET SDL EPAM Approach TO SECURE DEVELOPMENT

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..

SECURITY-RELATED ACTIVITIES IN SDLC SDL activities applied to SDLC:

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

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

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

IMPLEMENTATION CHECKLIST BACK TO SECURE CODING GUIDELINE

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)!

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

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

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

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

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

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

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

EXAMPLE KNOW YOUR TOOLS

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

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

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

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

.. AND FINALLY

DON‘T FORGET OUR MAJOR GOAL!

THANK YOU!