1. An introduction to the Secure Software Development Lifecycle Lone Star PHP Conference, Dallas TX June 28th - 29th 2013 Feedback - http://joind.in/8682

2. Who am I? Neal Anders Senior Software Engineer at Infoblox http://github.com/nanderoo http://neal-anders.com @nanderoo

3. Who are you? Designers? Developers? Dev-Ops? Sys-Admin? Managers? Recruiters?

4. What do you mean... Secure Software?

5. What does Secure Software mean? Resilience? Dependable? Trustworthy?

6. Secure Software Assurance "...the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at anytime during its lifecycle, and that the software functions in the intended manner." - National Information Assurance Glossary; CNSS Instruction No. 4009

7. Secure Software Development What is different about SSD/SDL? - More than one flavor out there. - Different approaches / frameworks. - Microsoft "Security Development Lifecycle" - CERT/SEI Carnegie Mellon University - OWASP - SANS / NIST / IETF - BITS - Others

8. Secure Software Development Train Requirements Design ImplementVerifyRelease Respond

9. Secure Software Development Initiate Develop ImplementOperate Dispose

10. Requirements & Design What makes secure requirements different - Front-loaded planning. - Thinking about things other than 'features' - Requirements and risk measurements. - Design is not eye-candy and pixel pushing. - Sometimes at the expense of usability.

11. Requirements & Design Design aspects of secure software - Redundancy - Stability - Graceful Fall-over/Failure - And recovery! - Data Integrity - Information Assurance - Threat Modeling

12. Requirements & Design Threat Modeling and STRIDE Spoofing * Tampering * Repudiation * Information Disclosure * Denial of Service * Elevation of Privilege Internet App Server Database

13. Requirements & Design Session Hijacking > Employ SSL Spoofing * Tampering * Repudiation * Information Disclosure * Denial of Service * Elevation of Privilege Internet App Server Database

14. Requirements & Design Fuzzing / Overflow > Limit Inputs Spoofing * Tampering * Repudiation * Information Disclosure * Denial of Service * Elevation of Privilege Internet App Server Database

15. Requirements & Design Data Access / Theft > Encrypt Spoofing * Tampering * Repudiation * Information Disclosure * Denial of Service * Elevation of Privilege Internet App Server Database

16. Requirements & Design ?customerid=* > Enforce Access Limits Spoofing * Tampering * Repudiation * Information Disclosure * Denial of Service * Elevation of Privilege Internet App Server Database

17. Requirements & Design Auto Refresh > Throttle / Firewall Spoofing * Tampering * Repudiation * Information Disclosure * Denial of Service * Elevation of Privilege Internet App Server Database

18. Requirements & Design /?admin=true > Least Privilege Spoofing * Tampering * Repudiation * Information Disclosure * Denial of Service * Elevation of Privilege Internet App Server Database

19. Development & Testing What is different about 'secure' development - Requires you think about what may not be in the specs. - Error handling becomes the first step and second nature. - Testing becomes as much about making tests pass with expected behavior and pass with failed (but expected) behavior.

20. Development & Testing So, testing is more than 1-time unit tests - You will be continually adding new cases even after you release. - As vulnerabilities are found they should be included in your test cases. - When someone claims to have an exploit you can easily and quickly validate. - Testing with "fail gracefully" can be tricky.

21. Acceptance More than a check list - Now you are ready to release, right? - Acceptance will run the gamut of all your specs and tests and things you might not know about. - 3rd party / independent validation

22. Acceptance Validate with real-world data - The best data is real data (but not always possible). - Fuzzing / brute force tends to expose only a subset of issues. - Some of the same tools used during testing.

23. Acceptance Have this figured out before you get here - What steps will you perform to validate? - What remediations will be taken should something not pass? - Used assigned weights / values to potential weaknesses (garnered from threat modeling). - Measure the product / release as a whole.

24. Least Privilege The concept that... for a given task to be completed, it should be accomplished in the shortest amount of time, with the least amount of resources and permissions.

25. Least Privilege Rethinking how you design your app - Traditional approach is to show everything. - Prune back until something that isn't desired is gone. - Often leads to poor UX / escapes / vulnerabilities. - Instead, start with only what is needed. - You can end up writing more code, but it is more secure.

26. Least Privilege Flexible vs. strict permissions - We often want to create a beautiful machine with a versatile codebase. - But you can end up designing and building for what isn't required or desired. - Trouble caused by taking short cuts and... not knowing. - Diverse skill-sets, teamwork, code reviews, and properly vetted specs help make this easier.

27. Least Privilege Extensive logging and test cases - Logging / Auditing often is an afterthought - Work on logging and thinking about your design up front, make it transparent. - TDD / BDD approaches can be helpful. - Test cases should be clear and concise. - Recognizing what unexpected behavior looks like is key.

28. Policies and Standards Have them for your entire engineering org - Specs, Designs, Code, Play Books. - Set common / minimum levels of logging. - Document expected / desired failure modes. - Code reviews can become quite different. - How will you enforce them?

29. Policies and Standards Make code and documentation enforcements - Automated as possible - Part of your code review cycle - PHPDoc / Pod / Etc - Reference BUG-IDs, small changes in code.

30. Policies and Standards Are part of your release cycle - Good time to audit code - Verify / sign / validate packaging - If you 'bike-shed' during this time is a sign of poor implementation or understanding.

31. Defensive Coding When 1 line of code turns into many - Thinking outside of the spec - Red Teaming - Validation of your threat modeling! - It's ok to bring in help from outside your group. - DRY helps maintain sanity, makes changes easier.

32. Defensive Coding php://memory demo (time permitting)

33. Operations Push to production - Prime operations personnel - Perform phased rollout - Have a rollback plan, test it. - Pre-position monitoring and alerts

34. Operations Monitoring state - Decide (early on) what measurements to take - Establish baseline, deviance, historical triggers - Create a playbook - "Beach Certify" your app - Periodically review what you measure/monitor

35. Operations Dealing with attempted break-ins - What does normal state look like? - Are there indicators that you can watch for? - Annoyance or real threat? - Persistent? - What are they trying?Known vuln? 0-day?

36. Operations An Intrusion - Now what? - Don't Panic! - Notify the right people. - Take defensive measures. - Enact your Risk Mitigation Plan(s)

37. Risk Mitigation Handling Breaches / Exposure - Role-play different scenarios and your responses. - Threats can come from external or internal sources. - Sometimes things are found by accident. - Don't do anything to destroy evidence. - Be ready to bring in outside help. - It's audit time boys and girls.

38. Risk Mitigation Full Disclosure Planning - Acknowledge the report of the "issue". - Have a response ready for the person or group reporting. - Provide an outline / timeline of what they should expect and when. - Decide if/when to go public with the breach or vulnerability. - If a true issue, provide workarounds/fixes.

39. Risk Mitigation Reactive vs. Proactive - You must be ready to react to changes in the performance and operation of your application or service. - In order to do this you must proactively monitor the services you provide and the infrastructure it operates on. - Recognize expected vs observed behavioral deviations.

40. Bonus Round Cleared Work - Social Media - Adverse Behavior - Financial Status - M.I.C.E. M=money I =ideology(patriotism/religion) C=coercion E=ego

41. Plugs Check out - Baltimore / D.C. PHP - Surge Conf - MDC3 - BlackHat / BSIDES / Defcon - Your Local Hacker Space

42. Contact & Feedback Email - Neal.Anders@Yahoo.com Twitter - @nanderoo Web - http://neal-anders.com/blog Feedback - http://joind.in/8682