SecAppDev2016 Ataya and... · • CISSP, CSSLP . Luc POULIN ... schlumberger • Specialized in...

SecAppDev 2016

Cer%fica%on of Applica%on Security

Learning objec6ves •  Introduce a new paradigm to build and verify so<ware security

based on new ISO/IEC Standard •  Understand how to create a Security Design paCern which can

be tracked through the development process •  Describe methods to cer%fy applica%on security through the

review of Applica%on Security Controls (ASC)

Georges ATAYA

Speaker

Certification of Application Security

Career Summary Expertise Summary Education/ Certification •  Professor and Academic

Director (SBS-EM) •  Managing Director ICT

Control advisory firm •  Past International Vice

President at ISACA •  Past Partner Ernst & Young •  Deputy International CIO

ITT World Directories •  Previously Project Manager

and Senior IT Auditor

•  IT Governance (development of Cobit 4 and COBIT 5)

•  IT Governance and Value governance (co-author VALIT and supervision CGEIT BOK)

•  Information Security Management (Co-author CISM Body of Knowledge)

•  IT Audit and Governance •  Information security and risk •  Strategy and Enterprise

Architecture and IT Sourcing

•  Master in Computer Science (faculty of Sciences ULB)

•  Postgraduate in Management (Solvay Brussels School ULB)

•  CISA, CISM, CRISC, CISSP, CGEIT

Alain CIESLIK

Speaker


Career Summary Expertise Summary Education / Certification •  Enterprise Security

Architect (Stib) •  Participate in the

development of an autorisation provider (European commission)

•  ISO 27034 Lead Implementer Trainer (Nitroxis)

•  Security consutlant (ICT Control)

•  Secure Development lifecycle •  Application security •  Security assessment •  Security Awareness •  Digital Forensics

•  Master in IT Management Solvay •  Master in computer Science •  Graduat en informatique de

gestion •  ISO 27034 Lead implementer •  ISO 27001 Lead Implementer •  GWAPT: Web Application

Penetreation tester •  CISSP, CSSLP

Luc POULIN

ISO 27034 father


Career Summary Expertise Summary Education/Certification •  President of the Application

Security Institute – Cogentas inc

•  Senior Advisor on Open Information Systems and Chief Information Security Officer (CISO) at the Computer Research Institute of Montréal (CRIM)

•  Senior application security advisor at nurun

•  Principal/security architect at schlumberger

•  Specialized in security concerns within the information system life cycle for more then 15 years.

•  Chief Informa%on Security Officer •  Informa%on / Applica%on Security Advisor

•  Lead Technological and Func%onal Architect

•  Security Architect •  Func%onal and Technological Analyst

•  Conference speaker and trainer •  Applica%on Security Evaluator / Auditor

•  University Lecturer

•  A Ph.D in Software Engineering/ Application Security in Montreal at School of Advanced Engineering, University of Quebec

•  Master's Degree in Computer Security (thesis) at Laval University

•  Post-graduate Diploma in Software Engineering at Laval University

•  Bachelor's Degree in Computer Science at Laval University

•  Certified ISO/IEC 27034 Application Security Lead Auditor (CASLA), Certified ISO/IEC 27034 Application Security Lead Implementer (CASLI)

•  CSSLP, CISA, CISM, CISSP-ISSMP

Agenda


1.  Introduction 1.  Definition 2.  Scenario

3.  ISO 27034 Concepts

2.  How can we certify security inside an application ? 1.  Phase 1: Risk Assessment 2.  Phase 2: Application Security Controls 3.  Phase 3: Audit Process

3.  ISO 27034 Information Repository 4.  Conclusion Annex I: Workshop – How can we trust frameworks used inside the company ? Annex II: Training – ISO 27034 Lead Implementer

1.1 Introduction


Information security Preservation of confidentiality, integrity and availability of information (ISO 27000:2013) Application security Ø  Preservation of confidentiality, integrity and availability of

information collected, processed, stored or communicated Ø  Protection of the information involved by an application

Validation The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders Verification The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process

1.1 Introduction


Audit Systematic, independent and documented process for obtaining audit evidence [records, statements of fact or other information which are relevant and verifiable] and evaluating it objectively to determine the extent to which the audit criteria [set of policies, procedures or requirements] are fulfilled (ISO 19011:2011)

1.1 Introduction


Agenda


1.  Introduction 1.  Definition 2.   Scenario




1.2 Scenario


My Bank’s website, mybank.example.com. This sample application is based on the following technologies.

1.2 Scenario


Our Secure Development lifecycle based on Microsoft SDL and is composed of several phase. Within each phase, we can find security processes or tasks that have to be done. (*): see SecAppDev training sessions

Phase Requirement

• Privacy requirements

• Cryptography requirements

Phase Design

• Privacy Design • Secure Architecture Design *

• Threat Modeling *

Phase Implementa%on

• Owasp Top 10

Phase Verifica%on

• Sta%c Code Analyzer • Security and Privacy tes%ng

• OWASP ASVS

Phase Release

• Server Hardening • Incident Response

How secure we are?

1.2 Scenario


1.2 Scenario


Ø  Can we trust third parties framework used inside our applications ?

Ø  Can we use logs or other evidences in front of court in case of security incident ?

Ø  Can we assure the board that everything is under control ?

Ø Do we effectively respect Data privacy of our clients ? Ø  Could we prove our PCI-DSS compliance ?

Security is critical for organizations

… What cannot be measured … cannot be managed…

1.2 Scenario


We need to create trust between Business and IT

Security software must be assessed with evidences…

1.2 Scenario


Agenda



3.   ISO 27034 Concepts



This presentation is based on key ISO 27034 elements ISO 27034 is composed of the following parts:

–  PART I: Overview and concepts –  PART II: Organization Normative Framework –  PART III: Application Security Management Process –  PART IV: Application Security Validation –  PART V: Protocols and application security control data

structure –  PART VI: Case studies

1.3 ISO 27034 Concepts




ISO 27034 publication planning

2011 2015 2016 2017 2019

ISO 27034-2

ONF Management

ISO 27034-1

Concept & overview

ISO 27034-6

Security guidance for specific applications

ISO 27034-3

Application security managementprocess

ISO 27034-5

Protocols and application security control data structure

ISO 27034-4

Application securityvalidation

1.  Security is a requirement 2.  Application security should be managed 3.  Application security is context-dependent 4.  Appropriate investment for application security 5.  Application security must be demonstrated



I. Principles

Applica%on life cycle processes

Processes involved with the applica%on

Technological Context

Applica%on specifica%on

Organiza%on & User Data

Roles & Permissions

Applica%on Data



II. Type of information that should be protected

Training of stakeholders / Implementa%on process / …

Applica%on Update / Process maintenance / repair / …

Opera%ng systems / External systems / …

Client applica%on specifica%on / server applica%on specifica%on

Business data / Logs / Private key / Configura%on /…

Authen%ca%on data / Authoriza%on data / …

Applica%on configura%on / binary code / source code / …

Agenda




2.   How can we certify security inside an application ? 1.  Phase 1: Risk Assessment 2.  Phase 2: Application Security Controls 3.  Phase 3: Audit Process


Cer6fica6on

Implementa6on

Phase2 Applica%on Security Controls

Phase 3 Audit Process

Phase 1 Risks Assessment

2. How can we certify security inside an application ?


Agenda




2.  How can we certify security inside an application ? 1.   Phase 1: Risk Assessment 2.  Phase 2: Application Security Controls 3.  Phase 3: Audit Process


2.1 Phase 1: Risk assessment


Where risks come from ?

Three sources have an impact on Application Security

Where risks come from ?

Global Data Protec%on Act, Patriot Act, …

PCI-‐DSS, Internal Policies, …

Java, C#, C++,…

File Upload, Dashboards, Sending mails, …



Context

Legal

Technological

Specifica6on

Applica6on

Business

Risk Risk Risk



Where do the risks come from ?

Context

Legal

Technological

Specifica6on

Applica6on

Business Risk Risk Risk

Risk Risk Risk

Risk Risk Risk


Es%mated Impact

€



cv Risks Security Requirements

Context

Legal

Technological

Specifica6on

Applica6on

Business

Required Level of Trust

What are the level of trusts ?



•  Security Labels are used to classify applications inside an organization

•  Describe mandatory security controls required to provide a minimum security assurance into a level of trust

•  Traceability mechanism between risks, security requirements and security controls




Security Requirements

Must provide security during transmission

Must provide a Secure Authentication

Must provide secure online transaction

Level of trust

LOW

HTTP HTTPS HTTPSData encryption

User: Login FormAdmin: Login Form

MEDIUM HIGH

User: Login FormAdmin: 2 Factors

User: 2 FactorsAdmin: 2 Factors

- Validation before payment

Validation before paymentUse One-time password

Security Requirements

Applica%on Security Controls

Risks

Es%mated Impact

€

Implementa%on Cost €



How can we mitigate a risk ?

Context

Legal

Technological

Specifica6on

Applica6on

Business




Application Security Controls

SecurityControl

Security Requirement

RequiredLevel Of Trust

Agenda




2.  How can we certify security inside an application ? 1.  Phase 1: Risk Assessment 2.   Phase 2: Application Security Controls 3.  Phase 3: Audit Process


2.2 Phase 2: Application Security Controls


A. Different types of Security Controls

Preven6ve (Before)

Detec6ve (During)

Correc6ve (AHer)

Administra%ve Security awareness and technical training

Security reviews and audits Required vaca%ons

Penalty

Technical Access control so<ware An%virus so<ware

Audit Trails

Restore the system

Physical Fire ex%nguishers, Locks and keys

Mo%on detectors. Smoke and fire detectors.

Modify barriers

Objectives

•  Security Design Pattern ( Knowledge documentation) –  Security activity –  Security verification

•  Translate the Security Requirements into a concrete set of tasks •  Use by the project to implement a Security Control •  Use by the business to estimate the cost •  Use by the project manager to estimate the time •  Use by the quality manager to verify the implementation •  Use by the auditor to certify the application •  Improve the organization's Application Security Maturity

Phase 2: Application Security Controls


Implementa6on & Verifica6on Cost (€)



Applica6on Security Controls

Security Ac6vi6es

Verifica6on Process

Evidence Verifica6on outcome

Security Design Pattern ( Knowledge documentation)



XML Structure

Translate Security Requirements into concrete set of tasks

ASC 1

ASC 2

ASC 4

ASC 3

ASC 6

ASC 5

ASC 7

Security Requirement Risk



Use by the business to estimate the cost

200 €

150 €

50 €

15 €

5 €

10 €

5 €




Cost = ASC 1 (200€) + ASC 2 (150€) + ASC 3 (15€) + ASC 4 (50€) + ASC 5 (10€) + ASC 6 (5€) + ASC 1 (5€)

= 435 €

Use by the project manager to estimate the time

20 day

15 day

7 day

1 day

1 day

1 day

3 day


Time = ASC 1 (20d) + ASC 2 (15d) + ASC 3 (1d) + ASC 4 (7d) + ASC 5 (1d) + ASC 6 (1d) + ASC 1 (3d)

= 48 days



Level of trust

Mitigation cost of security requirements

ASC 1


1 Risk A

ASC 2


2 Risk B

ASC 3


3 Risk C

10 days

20 days

5 days

35 days

500 €

100 €

200 €

800 €



Time Cost

C. Application Security Life Cycle Model ISO 27034 proposes a global life cycle model



Disciplines concerned by Applica6on Security

Project Management

Opera6on Team SoHware Development

Network

Enterprise Architecture Governance

Audit

Applica6on Management

Applica6on Supply

Infrastructure Management

Verifica6on

Server

Layers

Disciplines concerned by Applica6on Security

Opera6on stages Provisioning stages

C. Application Security Life Cycle Model



Opera6on Team SoHware Development

Infrastructure for Development

Opera6on Management Applica6on Management

Quality Verifica6on

Infrastructure for opera6on

Audit

Applica6on Management

Applica6on Supply

Infrastructure Management

Verifica6on




Preparation Development Transition Utilization Archival Disposal

Application provisioninginfrastructure management

Acquisition

Outsourcing

Application provisioning management Application operation management

Application operation

infrastructure management

Disposal

Application provisioning audit Application operation audit

Operation stages

Realization Transition Utilization &Maintenance Disposal

ApplicationManagement

ApplicationSupply

InfrastructureManagement

ApplicationAudit

Preparation

Provisioning stages

A reference Model aligns different disciplines required to produce Secure Application

C. Application Security Life Cycle Model What are the advantages of such model ? •  Create a Helicopter view of different disciplines under the scope of Application

Security •  Allow to identify what are missing areas within the organization •  Allow different disciplines to communicate in an effective way

•  Allow to choose the right place for an Application Security Controls



Phase Requirement

• ASC: Privacy requirements

• ASC: Cryptography requirements

Phase Design

• ASC: Privacy Design • ASC: Secure Architecture Design

• ASC: Threat Modeling

Phase Implementa%on

• ASC: Owasp Top 10

Phase Verifica%on

• ASC: Sta%c Code Analyzer

• ASC: Security and Privacy tes%ng

• ASC: OWASP ASVS

Phase Release

• ASC: Server Hardening

• ASC: Incident Response



C. Application Security Life Cycle Model What relation exists between the SDLC of our initial sample and the ISO 27034 reference life cycle model ?

C. Application Security Life Cycle Model Advantages •  Improve the communication between provisioning and operation teams. •  Allow to identify areas not covered by our initial SDLC



Utilization Archival Disposal

Application provisioninginfrastructure management

Application provisioning management Application operation management

Application operation

infrastructure management

Disposal

Application provisioning audit Application operation audit

Operation stages

Realization Transition Utilization &Maintenance Disposal

ApplicationManagement

ApplicationSupply


ApplicationAudit

Preparation

Provisioning stages

Requirement Design requirement Verification release

Map your current Development life cycle with the reference model




ASC1.1


Required Level Of TrustHIGH

Verification Process- What: Create a test case to verify HTTP response header X-XSS-Protection HTTP Response Headers- Where: Implementation phase- How: See Code Snippe- How much: 1 day- Documentation: https://spring.io/blog/2014/05/23/preview-spring-security-test-web-security

Security Activities

- What: Use Spring Security and activate X-XSS-Protection HTTP Response Headers- Where: Implementation phase- How much: 1 day- Who: Back office Developer- How: See code Snippet- Documentation: https://docs.spring.io/spring-security/site/docs/current/reference/html/headers.html

RiskApplication can be vulnerable to XSS

SourceTechnological Context




ASC1.2


Required Level Of TrustHIGH

Verification Process- What: Internet Explorer Screenshot with the blocking message- Where: Verification- How: Use screen capture tool- How much: 1 h- Documentation: https://spring.io/blog/2014/05/23/preview-spring-security-test-web-security

Security Activities

- What: User Acceptance Testing with - Where: Verification phase- How much: 1 h- Who: Tester- How: See the general message when XSS is blocked by Internet Explorer- Documentation:https://blogs.msdn.microsoft.com/ieinternals/2011/01/31/controlling-the-xss-filter/

RiskApplication can be vulnerable to XSS

SourceTechnological Context




Utilization Archival Disposal

Operation stages

Realization TransitionUtilization &Maintenance Disposal

ApplicationSupply

Preparation

Provisioning stages

Requirement Design Implementation Verification release

Application can be vulnerable to XSS

Security Req 1Security headers 1.1 1.2 1.3

Technological Context

Security Req 3Sanitize data 3.2 3.33.1

Security Req 2Encoding data 2.1 2.2 2.3


3.4

Application Security Controls can be implemented everywhere in the Development lifecycle




SecurityControl


RequiredLevel Of Trust

Verification Process

whathowwherewhenhow much

SecurityActivities

whathowwherewhenhow much

Application Security Life Cycle Model

Agenda




2.  How can we certify security inside an application ? 1.  Phase 1: Risk Assessment 2.  Phase 2: Application Security Controls 3.   Phase 3: Audit Process


Audit Process Applica6on Security Controls

Verifica%on outcome

Certification of Application Security 2.3 Phase 3: Audit Process

Audit Process

Audit outcome Verifica6on

Process

The auditing process starts with the verification outcome The auditor can check that the verification process was correctly performed. The auditor can also easily verify the coherence of all the security controls thanks to the helicopter view provided by ISO 27034


Utilization Archival DisposalApplication

Supply Requirement Design Implementation Verification release

Security Req 2Security headers 2.1 2.2 2.3

Security Req 4Sanitize data 4.2 4.34.1

Security Req 3Encoding data 3.1 3.2 3.3


4.4

Application provisioning audit Application operation auditApplication

Audit V.1 V.2 A.1 A.2

Audit can be applied anytime during the development lifecycle

2.3 Phase 3: Audit Process

Certification of Application Security 3. ISO 27034 Information Repository

Applica6on Norma6ve Framework (ANF)

ASCs Applica%on

Legal Context

Applica%on Business Context

Applica%on Technologic Context

Applica%on Specifica%on

Actors Roles Applica%on Security Life Cycle Model

Application Normative Framework is the repository where all files are kept There is one ANF per application



Organiza6on Norma6ve Framework (ONF)

ASCs Legal Context

Business Context

Technologic Context

Applica%on Specifica%ons

Actors Roles Other processes

Organization Normative Framework contains all information and it consolidates Application Security across the organization.

Levels of Trust


Organiza6on Norma6ve Framework (ONF)

Relation between ONF and ANF

Applica6on Norma6ve Framework (ANF)

Agenda





3.  ISO 27034 Information Repository 4.   Conclusion Annex I: Application Security Controls - XML structure Annex II: Workshop – How can we trust frameworks used inside the company ?

4. Conclusion


ISO 27034 website hCp://www.iso27001security.com/html/27034.html

OWASP TOP 10 – ISO 27034: Applica%on Security controls project hCps://www.owasp.org/index.php/OWASP_ISO_IEC_27034_Applica%on_Security_Controls_Project

Microso< SDL conforms to ISO/IEC 27034-‐1:2011 hCp://blogs.microso<.com/cybertrust/2013/05/14/microso<-‐sdl-‐conforms-‐to-‐isoiec-‐27034-‐12011/

ASIQ: La norme ISO/CEI 27034 – Sécurité des applica%ons hCps://asiq.org/evenement/la-‐norme-‐iso-‐cei-‐27034/

In 2016, Applica%on Security cannot be just a feeling…

•  A security control cannot be taken in account if there is no evidence it fulfills his purpose.

•  It provides a way to demonstrate that an applica%on reaches a specific level of trust within the organiza%on.

•  It provides a way to evaluate the applica%on security cost.

[TO-‐DO: Complete this part]

OWSAP TOP 10 Project Microso< is working on this standard.

Security cannot be a feeling, we need more Applica%on Security

4. Conclusion


Agenda







Spring Security is a great framework with a lot of security features. One of them is a mechanism that handle HCp Response Headers. Default Spring Security Headers •  Cache Control •  Content Type Op%ons •  HTTP Strict Transport Security •  X-‐Frame Op%ons •  X-‐XSS Protec%on

Annex II: Workshop - How can we trust third party frameworks ?


Documenta%on: List of usefull HTTP Headers hCps://www.owasp.org/index.php/List_of_useful_HTTP_headers


Header Spring support

Public Key Pinning Extension for HTTP Custom

Strict-‐Transport-‐Security Default

X-‐Frame-‐Op%ons,Frame-‐Op%ons Default

X-‐XSS-‐Protec%on Default

X-‐Content-‐Type-‐Op%ons Custom

Content-‐Security-‐Policy, X-‐Content-‐Security-‐Policy, X-‐WebKit-‐CSP

Custom

Content-‐Security-‐Policy-‐Report-‐Only Custom

Let’s start with a Default HTTP Response: HTTP Strict Transport Security Header According to the Spring Security documenta%on If you omit the hCps protocol, you are poten%ally vulnerable to Man in the Middle aCacks. Even if the website performs a redirect a malicious user could intercept the ini%al HTTP request and manipulate the response. Many users omit the hCps protocol and this is why HTTP Strict Transport Security (HSTS) was created. A browser can know ahead of %me that any request to hCp://mybank.example.com should be interpreted as hCps://mybank.example.com. This greatly reduces the possibility of a Man in the Middle aCack occurring.



According to the Spring Security documenta%on

While each of these headers are considered best prac%ce, it should be noted that not all clients u%lize the headers, so addi%onal tes%ng is

encouraged.



Check browser support table for HTTP Strict Transport Security Source: hCp://caniuse.com/#feat=stricCransportsecurity





Security Ac%vity How to implement HTTP Strict Transport Security with Spring Security ? Cost: 0,5 day Who: Developer Where: Implementa%on phase



Verifica%on Ac%vity How to test HTTP Headers

public class HstsHeaderWriterTests { … @Before public void setup() { request = new MockHCpServletRequest(); response = new MockHCpServletResponse(); writer = new HstsHeaderWriter(); } @Test public void allArgsCustomConstructorWriteHeaders() { writer = new HstsHeaderWriter(AnyRequestMatcher.INSTANCE, 15768000, false); writer.writeHeaders(request, response); assertThat(response.getHeaderNames().size()).isEqualTo(1); assertThat(response.getHeader("Strict-‐Transport-‐Security")).isEqualTo("max-‐age=15768000"); } }

Cost: 0,5 Where: Implementa%on Phase



Is our tes%ng strategy good enough ?

NO Unsecure scenario •  No HTTPS configura%on on the produc%on server.

•  ASC: We need another ASC to test HCps

•  Some browsers do not support the HTTP response header. •  ASC: How can we discover when a browser is not suppor%ng this header ?

Let’s con%nue with a Custom Header: Content Security Policy 1.0





Security Ac%vity How to implement Content Security Policy 1.0 with Spring Security ? Cost: 0,5 day Who: Developer Where: Implementa%on phase



Verifica%on Ac%vity How to test HTTP Headers

public class HstsHeaderWriterTests { … @Before public void setup() { request = new MockHCpServletRequest(); response = new MockHCpServletResponse(); writer = new HstsHeaderWriter(); } @Test public void allArgsCustomConstructorWriteHeaders() { writer = new HstsHeaderWriter(AnyRequestMatcher.INSTANCE, 15768000, false); writer.writeHeaders(request, response); assertThat(response.getHeaderNames().size()).isEqualTo(1); assertThat(response.getHeader("Content-‐Security-‐Policy")).isEqualTo("default-‐src 'self'; ."); assertThat(response.getHeader(” X-‐WebKit-‐CSP)).isEqualTo("default-‐src 'self'; ."); } }

Cost: 0,5 Where: Implementa%on Phase



HTTP Headers

HttpStrict

TransportSecurity

Content&Security&Policy&1.0

CheckServer

Configuration

CheckBrowserSupport

CheckBrowserSupport

Security Req 1Force Https

Security Req 1XSS Protection

Risk Information leakage

Risk XSS Vulnerable

Agenda






Annex III: Trainings


CERTIFIED ISO 27034 LEAD IMPLEMENTER 5 Day course

Next course dates: •  May 23-‐27, 2016 •  October 3-‐7, 2016

Useful links •  hCp://www.ictcontrol.eu/Services/Training/CERTIFIED-‐ISO-‐27034-‐LEAD-‐

IMPLEMENTER.aspx •  hCp://www.ictcontrol.eu/Media/pdf/iso-‐27034-‐lead-‐implementer_4p.pdf

SecAppDev2016 Ataya and... · • CISSP, CSSLP . Luc POULIN ... schlumberger • Specialized in...

Documents

Transcript of SecAppDev2016 Ataya and... · • CISSP, CSSLP . Luc POULIN ... schlumberger • Specialized in...