Ethical Hacking Conference 2015- Building Secure Products -a perspective

22nd May 2015, Bangalore

Name of the Speaker : Anish Cheriyan, Director Quality and Centre

of Excellence-Cyber Security

Company Name : Huawei Technologies India Private Limited

www.unicomlearning.com

www.unicomlearning.com/ethicalhacking

Building Secure Product- A Perspective

● Introduction● Background and Perspective● Principles of Security● Security in Product Development Life Cycle● Threat Modelling● Secure Coding● Pen Test

● Cyber Security- a mindset and some anti patterns● Conclusion



Is our Security Implementation Like this?

Image Courtesy: https://c1.staticflickr.com/5/4051/4265223393_9364e67d1d_b.jpg



Is our Security Implementation Like this?

Image Courtesy: http://www.storeapps.org/wp-content/uploads/2013/07/additional-feature-header.jpg

Or like this?

Penetrate and Patch approach is Bad

• Testers can only find problems based on the best testing capability.

• Developers can only patch problems which they know about.’

• Attackers can find issues based on the deeper flaws in the system

• Patches only fix the symptoms • Patches often go unapplied


Penetrate and Patch approach is Bad


Reference: Building Secure Software- John Viega, Gary McGraw

It takes a long time before most people upgrade to patched versions because most people upgrade for new functionality/robust software/performance not because of real vulnerability



Keep your friends close and your enemies closer.

Image Courtesy: https://c2.staticflickr.com/6/5461/17652653098_f80525f2f8_b.jpg



Keep your friends closer and your enemies closer.

Image Courtesy: https://c2.staticflickr.com/6/5461/17652653098_f80525f2f8_b.jpg

Architectural flaws vs

Implementation Bugs

Image Courtesy: http://cdnassets.hw.net/

Design Defects= Flaws


• Flaws are problems in the design• Bugs are problems in the Implementation

• We avoid flaws during the design phase

• According to Gary McGraw, 50% of security problems are flaws

Reference: Coursera Course - Software Security by Michael Hicks, University of Maryland

Design Vs Implemenation?


Reference: Coursera Course - Software Security by Michael Hicks, University of Maryland

• Different levels of System Design Divisions:– Highest Level: main actors (processes), interactions and

programming language (s) to use– Next level: decomposition of an actor into

modules/components, identifying the core functionalities and how they work together

– Next level: how to implement data types and functions eg. Purely functionality , or using parallelism etc.

• Last two could be implementation or design or both– The distinction is bit fuzzy

Categories of Design Principles


Principle Goal Example

Prevention Eliminate software defects entirely

Heartbleed bug would have been prevented by using a type-safe language like Java

Mitigation Reduce the hard from exploitation from unknown defects

Run each browser tab in separate process , so exploitation of one tab does not yield access to data in another

Detection (and Recovery)

Identify and understand an attack (and undo damage)

Monitoring(eg. Expected variants), snapshotting

Reference: Coursara Course - Software Security by Michael Hicks, University of Maryland

The Principles- Secure software design


• Favor simplicity– Use fail safe defaults– Do not expect expert users

• Trust with reluctance– Employ a small trusted computing base– Grant the least privilege possible

• Promote privacy• Compartmentalize

• Defend in Depth– Use Community resource-no security by obscurity

• Monitor and traceReference: Reference: Software Security by Michael Hicks, Coursera

Favor Simplicity


Reference: Reference: Software Security by Michael Hicks, Coursera

Favor Simplicity: Fail Safe Defaults


Favor Simplicity: Do not expect expert users


Trust with Reluctance(TwR)


Trust with Reluctance(TwR)- Trusted Computing Base


Trust with Reluctance(TwR)- Least Privilege


Trust with Reluctance(TwR)- Compartmentalization


Defend in Depth


Defend in Depth-Use Community Resources


Monitoring and Traceability


Top 10 Flaws. Do Not..


Building Security in Product Development Life Cycle


Requirement

Design

Coding

Testing

Release•General

Security Requirement Analysis •Attack Surface Analysis• Threat Modeling -STRIDE(Microsoft)•Testability Analysis

•Secure Architecture and Design.•Security Design guidelines•Security Test Strategy and Test Case

•Secure Coding Guidelines (cert.org-good reference)•Static Check Tools like Fortify, Coverity (Ref- owasp.org)•Code Reviews

•Security Test Cases•Penetration Testing Approach (Reconnaissance, Scanning, Attack, Managing access)

•Anti Virus•Continuous Delivery System (Inspection and Secure Test)

Threat Modeling


Reference: https://msdn.microsoft.com

Identify assets. Identify the valuable assets that your systems must protect.

Create an architecture overview. Use simple diagrams and tables to document the architecture of your application, including subsystems, trust boundaries, and data flow.

Decompose the application. Decompose the architecture of your application, including the underlying network and host infrastructure design, to create a security profile for the application.

Identify the threats. Keeping the goals of an attacker in mind, and with knowledge of the architecture and potential vulnerabilities of your application, identify the threats that could affect the application.

Document the threats. Document each threat using a common threat template that defines a core set of attributes to capture for each threat.

Rate the threats. Rate the threats to prioritize and address the most significant threats first.

Threat Modeling Diagram- a simple example


Reference: https://msdn.microsoft.com

Secure Architecture and Design Perspective


Reference: https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet#DRAFT_CHEAT_SHEET_-_WORK_IN_PROGRESS

• Business Model• Data Essential• End Users• Third Party• Administrators• Regulations

Business Requirements

Secure Code Perspective


Reference: https://owasp.org

Input Validation

Output Encoding

Authn. & Pwd. Mgmt.

Session Management

Access Control

Cryptographic Practices

Error Handling and LoggingData Encryption

Communication Security

System Configuration

File Management

Memory Management

Gen. Coding Practices

Secure Code Perspective-Code Review


Further Reading: Threat Modeling- Frank Swiderski, Window Snyder, A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World - http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext

Trust bound

ary code

(Threat

Model)

Static

Tool Executio

n

Manual

Code Review

While doing the code review we can take the inputs from the code in the trust boundary, issues from the static tools like Fortiy, Coverity etc and put the focus at the right place for the Code Review

Secure Testing Perspective


•Information Gathering (About the system, environment etc.)

•Scan the system

•Threat Analysis

•Usage of the Static analyzer (Run fortify, Coverity, Appscan, Nessus, NMAP etc)•Right tool usage

•Vulnerability Analysis

•Fuzz Testing

•Penetration testing

•Use /Develop right set of tools to attack

•Raise Defects

Reconnaissance

Scanning Attack

Managing

Access

Test Strategy


Validation Approach of ABC

Picture Courtesy: http://sd.keepcalm-o-matic.co.uk/i/assume-nothing-believe-nobody-and-check-everything--1.png

Secure Testing Pen Test Tools


Software URL Description

Maltego http://www.paterva.com/web5The defacto standard for mining data on individuals and companies. Comes in a free community version and paid version.

Nessus http://tenable.com/products/nessusA vulnerabilty scanning tool available in paid and free versions. Nessus is useful for finding and documenting vulnerabilities mostly from the inside of a given network.

IBM AppScan http://www-01.ibm.com/software/awdtools/appscan

IBM's automated Web application security testing suite.

eEye Retina http://www.eeye.com/Products/Retina.aspx

Retina is an an automated network vulnerability scanner that can be managed from a single web-based console. It can be used in conjunction with Metasploit where if an exploit exists in Metasploit, it can be launched directly from Retina to verify that the vulnerability exists.

Nexpose http://www.rapid7.comNexpose is a vulnerability scanner from the same company that brings you Metasploit. Available in both free and paid versions that differ in levels of support and features.

OpenVAS http://www.openvas.org

OpenVAS is a vulnerability scanner that originally started as a fork of the Nessus project. The actual security scanner is accompanied with a daily updated feed of Network Vulnerability Tests (NVTs), over 20,000 in total (as of January 2011)

HP WebInspect https://www.fortify.com/products/web_inspect.html

HP WebInspect performs web application security testing and assessment for complex web applications. Supports JavaScript, Flash, Silverlight and others.

HP SWFScan https://h30406.www3.hp.com/campaigns/2009/wwcampaign/1-5TUVE/index.php?key=swf

HP SWFScan is a free tool developed by HP Web Security Research Group to automatically find security vulnerabilities in applications built on the Flash platform. Useful for decompiling flash apps and finding hard-coded credentials, etc.

THC IPv6 Attack Toolkit http://www.thc.org/thc-ipv6

The largest single collection of tools designed to exploit vulnerabilities in the IPv6 and ICMP6 protocols.

Pen Test Tools and Guidelines- http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines

Microsoft Office Excel Worksheet

http://www.paterva.com/web5

http://tenable.com/products/nessus

http://www-01.ibm.com/software/awdtools/appscan

http://www-01.ibm.com/software/awdtools/appscan

http://www.eeye.com/Products/Retina.aspx

http://www.eeye.com/Products/Retina.aspx

http://www.rapid7.com/

http://www.openvas.org/

https://www.fortify.com/products/web_inspect.html

https://www.fortify.com/products/web_inspect.html

https://h30406.www3.hp.com/campaigns/2009/wwcampaign/1-5TUVE/index.php?key=swf



http://www.thc.org/thc-ipv6

http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines

Some Anti Patterns


• Attack Surface analysis, Threat modeling not deeply practiced

• Secure design and code practices not practiced well• Ignoring some errors of Fortify /Coverity and other

tools. Sometimes considering them as false positives• Relying too much on Testing• “This is not a valid scenario. Customer would never test

this way”.• “Innocent until Proven”- It should be “Guilty unless

proven”

Reference: Reference: Software Security by Michael Hicks, Coursera

Conclusion

• Build Security into the Life Cycle of product development

• Focus on Security Competency• Assume Nothing, Believe Nobody, Check

Everything.


References and Further Reading

• www.cert.org• www.owasp.org• http://pr.huawei.com/en/connecting-the-dots/cyber-securit

y/

• http://pr.huawei.com/en/connecting-the-dots/cyber-security/hw-401493.htm#.VV6DBfBCijM

• https://msdn.microsoft.com/en-us/security/aa570330.aspx • Building Secure Software –John Viega, Gary McGraw• Coursera Course - Software Security by Michael Hicks,

University of Maryland

http://www.cert.org/

http://www.owasp.org/

http://pr.huawei.com/en/connecting-the-dots/cyber-security/

http://pr.huawei.com/en/connecting-the-dots/cyber-security/

http://pr.huawei.com/en/connecting-the-dots/cyber-security/hw-401493.htm

http://pr.huawei.com/en/connecting-the-dots/cyber-security/hw-401493.htm

https://msdn.microsoft.com/en-us/security/aa570330.aspx

Thank youSpeaker Name: Anish Cheriyan

Email ID: [email protected], @anishcheriyan

www.unicomleaning.com

Organized byUNICOM Trainings & Seminars Pvt. Ltd.

[email protected]


mailto:[email protected]

Ethical Hacking Conference 2015- Building Secure Products -a perspective

Technology

Transcript of Ethical Hacking Conference 2015- Building Secure Products -a perspective