SECURE DEV. BURHAN KHALID

BURHAN.KHALID@GMAIL.COM

TODAY’S TALK •  3 Ps of Info. Security

•  Secure Development - Published Standards •  Practical Best Practices – Implementation Guidelines

•  S.I.T.A.T •  Debunking Common Myths

THREE P OF SECURITY •  PEOPLE

•  PROCESS •  PERSISTANCE / PRACTICE

•  SECURITY IS NOT = PRODUCT

WHY DEVELOPMENT SECURITY? •  MAJORITY of security vulnerabilities result from poor

code

•  Great impact vs. minimal investment •  Awareness at the basic, fundamental, core

•  Reciprocal effect

•  Best Use of Resources

STANDARDS •  SSE-CMM

•  Systems Security Engineering – Capability Maturity Model •  TSP-Secure

•  Team Software Process for Secure Software Development •  Microsoft Trustworthy Computing Software Development

Lifecyle

•  SAMM

•  Software Assurance Maturity Model •  SSF

•  Software Security Framework

PRACTICAL IDEAS •  Standardize

•  Isolate •  Testing & Peer Reviews

•  Audits

•  Tooling

STANDARDIZE •  Infrastructure

•  What systems to use •  What versions/patches to deploy

•  Methodology

•  Waterfall •  Agile •  Swimlanes •  Kanban Boards •  SDLC

•  Deployment Automation

ISOLATE •  Development Stages

•  Development •  Testing •  Staging •  Production

•  Isolate:

•  Hardware •  Connectivity •  Credentials

•  Centralized Credential Store (LDAP/AD/SSO/Federation) •  Change Management Process

TESTING •  Software should be tested by the following:

•  Developers •  End Users •  Dedicated QA/QC Team •  Everyone in the company •  CEO-only •  Customer-only •  My Boss

•  One Good Test = Hours of Development time saved

•  One Bad Test = Hours of Development time wasted

•  Development Time = Money

GOOD TESTS VS. BAD TESTS •  Centralized Bug Database

•  That everyone uses, not just developers •  Good Tests = Good Bug Reports

•  Repeatable •  Example •  Expected This, Got This •  BugCam / ScreenCapture

•  Bad Tests

•  Bugs that can’t be reproduced •  Backlog of bugs •  Time wasted chasing non-software issues

PEER / CODE REVIEWS •  Creating a proper environment

•  Peer Reviews vs. Testing •  Implementation vs. Execution •  Code / Algorithm Level •  “Is there a better way to write this loop?” •  Pool expertise together •  Learning Environment

TOOLING •  Good Quality Tools = Good Quality Product

•  Standardize on tooling and frameworks •  Standard Documentation and bootstrapping

•  Use a wiki/intranet •  Geared towards developers •  Centralize machine images

ABOUT FRAMEWORKS •  Software frameworks good:

•  Set of rules that lead to benefits •  “Batteries Included” •  Save Development Time

•  Common security headaches dealt with •  Software frameworks bad:

•  Black box – too much “magic” •  Another thing to patch/maintain •  Collateral damage

•  Conclusion:

•  Use the Right framework, not the Popular framework

COMMON MYTHS •  Complex passwords are secure passwords

•  Closed Source vs. Open Source •  3rd Party Testing = Assurance

COMPLEX PASSWORDS •  Typical password requirements:

•  1 CAPITAL letter •  1 lowercase letter •  1 numeric character •  1 “special” character •  8 characters in length •  Cannot repeat X passwords

•  Opposite Effect

•  People write down passwords •  Repeat patterns (Apr@2012, May@2012)

Password policies have led to passwords that are difficult for people to remember, but easy for machines to crack.

CLOSED SOURCE VS. OPEN SOURCE •  Common Myths:

•  Since its open, means hackers know the code •  Anyone can find bugs and exploit them

•  The Truth:

•  More Eyes = More People to Fix the bug •  If a bug is found, it is announced and quickly fixed •  No more “zero day” exploits

3RD PARTY TESTING •  Myth

•  They will test my code •  They will tell me what’s wrong •  If they say it passes, it is secure

•  Truth

•  Testing done against published vulnerabilities only •  Report tells you what is wrong with your stack not with

your code. •  Apache vulnerability •  Windows patch missing

•  Your code is evolving

THANK YOU QUESTIONS

@BURHAN – HTTP://SPKR8.COM/S/15462