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.

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

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 trace
Reference: Reference: Software Security by Michael Hicks, Coursera

Favor Simplicity

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(Microsof
t)
•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
•Network
•Systems
•Infrastructure Monitoring
•Virtualization and
Externalization
Infrastructure
Requirements •Environments
•Data Processing
•Access
•Application Monitoring
•Application Design
Application
Requirements
•Operations
•Change Management
•Software Development
•Corporate
Security Program
Requirements

Secure Code Perspective
Reference: https://owasp.org
Input
Validation
Output
Encoding
Authn. & Pwd.
Mgmt.
Session
Management
Access Control
Cryptographic
Practices
Error Handling
and Logging
Data
Encryption
Communicatio
n 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
boundary
code (Threat
Model)
Static Tool
Execution
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
Reconnaissan
ce
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/web5
The defacto standard for mining data on individuals and companies. Comes in a free
community version and paid version.
Nessus http://tenable.com/products/nessus
A 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/appsca
n 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.com
Nexpose 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/campaig
ns/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

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”

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-
security/
• 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

Speaker Name: Anish Cheriyan
Email ID: anishcheriyan@huawei.com, @anishcheriyan
www.unicomleaning.com
Organized by
UNICOM Trainings & Seminars Pvt. Ltd.
contact@unicomlearning.com

Ethical Hacking Conference 2015- Building Secure Products -a perspective

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Ethical Hacking Conference 2015- Building Secure Products -a perspective

Similar to Ethical Hacking Conference 2015- Building Secure Products -a perspective (20)

More from Dr. Anish Cheriyan (PhD)

More from Dr. Anish Cheriyan (PhD) (15)

Recently uploaded

Recently uploaded (20)

Ethical Hacking Conference 2015- Building Secure Products -a perspective