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

Post on 30-Dec-2015

216 views 3 download

Tags:

transcript

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!