Burhan Khalid presented on secure software development practices. He discussed the three Ps of security - People, Process, and Persistence/Practice. He emphasized that security is not just about products but also development practices. Standards for secure development include SSE-CMM, TSP-Secure, and SAMM. Practical best practices include standardizing infrastructure, isolating development environments, peer reviews, centralized bug tracking, and using appropriate tools and frameworks. Common myths debunked are that complex passwords are secure, closed source is less secure than open source, and third party testing ensures code security.

1. SECURE
DEV.
BURHAN KHALID
BURHAN.KHALID@GMAIL.COM

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

3. THREE P OF
SECURITY
• PEOPLE
• PROCESS
• PERSISTANCE / PRACTICE
• SECURITY IS NOT = PRODUCT

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

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

6. PRACTICAL IDEAS
• Standardize
• Isolate
• Testing & Peer Reviews
• Audits
• Tooling

7. STANDARDIZE
• Infrastructure
• What systems to use
• What versions/patches to deploy
• Methodology
• Waterfall
• Agile
• Swimlanes
• Kanban Boards
• SDLC
• Deployment Automation

8. ISOLATE
• Development Stages
• Development
• Testing
• Staging
• Production
• Isolate:
• Hardware
• Connectivity
• Credentials
• Centralized Credential Store (LDAP/AD/SSO/Federation)
• Change Management Process

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

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

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

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

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

14. COMMON MYTHS
• Complex passwords are secure passwords
• Closed Source vs. Open Source
• 3rd Party Testing = Assurance

15. 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)

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

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

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

19. THANK
YOU
QUESTIONS
@BURHAN – HTTP://SPKR8.COM/S/15462