�ݺ�ߣ

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

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

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

What do you mean...
Secure Software?

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

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

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

Train Requirements Design
ImplementVerifyRelease
Respond

Initiate Develop
ImplementOperate
Dispose

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.

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

Threat Modeling and STRIDE
Spoofing * Tampering * Repudiation * Information Disclosure * Denial of Service * Elevation of Privilege
Internet App Server Database

Session Hijacking > Employ SSL

Fuzzing / Overflow > Limit Inputs

Data Access / Theft > Encrypt

?customerid=* > Enforce Access Limits

Auto Refresh > Throttle / Firewall

/?admin=true > Least Privilege

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.

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.

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

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.

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.

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.

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.

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.

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.

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?

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

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.

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.

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

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

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

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?

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

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.

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.

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.

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

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

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

�ݺ�ߣ

Intro to-ssdl--lone-star-php-2013

More Related Content

Intro to-ssdl--lone-star-php-2013