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