Securing your web apps before they hurt the organization

transcript

Antonio Fontes| OWASP Switzerland

Securing your web project before it hurts your organization

antonio.fontes@owasp.org / SDLC Security

Agenda

- What's happening right now?- From reactive to proactive- What others do?

- What others do?- What can I do?

Bio• Antonio Fontes• Geneva (Switzerland)• Independant infosec/appsec consultant:

– Web applications security

– Web applications security– Risk visibility and management– Training, mentoring, coaching

• Cybercrime/Internet threats analysis report:– http://cddb.ch , written in French, sorry :/

• OWASP:– Switzerland Board Member– Geneva Chapter Leader

Who are you?

• Builders? writing secure code• Breakers? breaking into insecure code• Defenders? protecting insecure code• Managers?

Agenda

What's happening right now?From reactive to proactiveWhat others do?

What others do?What can I do?

Threat context

Incomplete specification documents:

Threat context

1. Analysis --> specs2. Design --> architecture/API3. Implement --> code

3. Implement --> code4. Validate --> binaries5. Deploy --> product6. Audit --> flaws/vulnerabilities7. Back to 1.

Threat context

注意輔助CSRF的！！

Tú eres el CSRF!

Threat context

Which of the following technologies

should we protect against "___

Injection" attacks?

Threat context

A.LDAP

B.HTML

C.Xpath

D.SQL (in the source code)

E.SQL (in a stored procedure)

You own an online dating website for VIPs.

You enforce SSL in all connections as you

value your customers privacy. A user

connects from the corporate network,

Threat context

where SSL deep-packet analysis was

enabled. What happens in the browser?

A.The browser displays a "red" warning

B.The browser displays a "yellow" warning

C.Nothing, all lights green as usual.

Which of the following technologies

should we protect against "___

Injection" attacks?

Threat context

A.LDAP --> yes

B.HTML --> yes

C.Xpath --> yes

D.SQL (in the source code) --> yes

E.SQL (in a stored procedure) --> yes

You own an online dating website for VIPs.

You enforce SSL in all connections as you

value your customers privacy. A user

Threat context

where SSL deep-packet analysis was

enabled. What happens in the browser?

A.The browser shows a "red" warning --> no.

B.The browser shows a "yellow" warning --> maybe

C.Nothing, all lights green as usual --> probably

Threat context// anti-SQL Injection attacks filter

String ValidateInput(string input)

String tmp = input.toUpperCase();

return(tmp.Replace("SELECT", "").replace("INSERT",

"").replace("UPDATE",

"").replace("UNION","").replace("BENCHMARK,

"").replace("--", "").replace("OR 1=1",

"").replace("DROP", "").replace("@@version",

"").replace("WAITFOR", "").replace("OUTFILE", "")

return(tmp)

Threat context// anti-SQL Injection attacks filter

String ValidateInput(string input)

String tmp = input.toUpperCase();

return(tmp.Replace("SELECT", "").replace("INSERT",

"").replace("UPDATE",

"").replace("UNION","").replace("BENCHMARK,

"").replace("--", "").replace("OR 1=1",

"").replace("DROP", "").replace("@@version",

"").replace("WAITFOR", "").replace("OUTFILE", "")

return(tmp)

"DRDROPOP table" ?

Threat contextsix@nine:~$ls /etc/conf/threats/

marketing

compliance

technology

hacking

hacktivism

cybercrime / corporate espionage

people

cyberterrorism

cyberwar

9 folder(s) found

What do we know today?

• About 900 software vulnerabilities:– http://cwe.mitre.org/

• About 35 webappsattack

attack techniques:

• About 15 weaknesses:

http://projects.webappsec.org

• 8 core secure development principles:– Data input validation– Data output encoding

– Error handling– Authentication / Authorization– Session management– Secure communications– Secure storage– Secure resource access

http://www.slideshare.net/BSides/the-principles-of-secure-development-david-rook

• Software vulnerabilities appear at 3 major stages of the SDLC:– DESIGN time

– DESIGN time– IMPLEMENTATION time– DEPLOYMENT time

Whether from within your organization…or from your software vendor…

• Design time vulnerabilities:– Appear in the specifications/requirements

documents (security features vs. secure features)

documents

• Causes:– Lack of security requirements analysis– Misunderstanding of the requirements– Insufficient or ambiguous specification– Specifications not being reviewed

• Remediation cost: high

• Coding time vulnerabilities:– Appear during the coding phase.

• Causes:

• Causes:– Misunderstanding of the technology– Lack of good practices– Secure code not being reused– Code not being reviewed– Mistakes, distractions, errors, …

• Remediation cost: average

• Deploy time vulnerabilities:– Appear during/after the deployment.

• Causes:

• Causes:– Insecure default configuration– Insecure installation procedure– Installed on insecure systems/networks– Configurations not being reviewed

• Remediation cost: low

• What about outsoucring?– How do you make sure the code is clean?– How do you know they can fix it?

– How do you know they can fix it?

• Causes:– Incomplete vendor agreements / contracts– Lack of requirements / specifications– Lack of governance / controls

• Remediation cost: high

Organizations have a tolerance level (risk appetite):

• "I want to be compliant!"

• "I want to be compliant!"– Get your webapp audited (checklist).

• "I want to keep my database inside!"– Get a documented solution to the Top10 problem.

• "I want 'secure' written on marketing material!"– Get/hire/rent an appsec professional

What's yours?

Challenge(s)• The threat landscape is highly mobile,

proactive, evolving and..smart.– and moreover: it is increasing!

• Weaknesses, on the other side, are highly static, reproducible and...detectable.

• Organizations are still limited by time and money constraints.

• Challenge: Identifying opportunities to maintain risk to its lowest level, at the lowest cost.

Agenda

Reactive risk control in the SDLC

ImplementationInception Design Verification Release Operations

Prevention:

Prevention:- nah.

Detection:- nah.

Prevention:

Prevention:- "Our software architect has ten years experience in…". Nah.

Detection:- nah.

Prevention:

Prevention:- Nah.- Sometimes: "hey, let's send all our developers to a security trainnig!"

Detection:- If it passes build+compile, then it's gold baby!!- …nah.

Prevention:

Prevention:- Nah.

Detection:- Right password should work. - Wrong password should not work.- Logoff should work.- …- nah…

Prevention:

Prevention:- "our integrators have ten years experience in…" .. Nah.

Detection:- "We will conduct a penetration test. Soon!!"

Prevention:

Prevention:- Nah.

Detection:- PENTEST TIME!!! (aka: asking 'ethical hackers' to simulate an intrusion attempt)

Risk level

Fixing costs

Risk level

Fixing costs

Risk level

Tolerated risk level

Risk level

Fixing costs

Penetration test

Proactive risk control in the SDLC

Risk level

Fixing costs

Good practices: early prevention

Risk level

Fixing costs

Good practices: early prevention

Checkpoints: early detection

Residual risk

Good practice: early prevention Checkpoint: early detection

Risk level

Fixing costs

Residual risk

Prevention:

Prevention:- Analysis of security & privacy requirementsDetection:-Review- Vendor selection criteria

Prevention:- Secure design and architecture guidance

- Secure design and architecture guidance- Secure software requirements definition guidance- Awareness of web induced risks- Threat modeling- Service Level Agreement- Vendor contract: security quality & service agreement Detection:- Requirements/specification analysis- Design security review- Vendor offer: how is the vendor solving major problems?

Prevention:

Prevention:- Secure development environment configuration- Secure coding guidance- Vendor contract: access to code review reports & coding practicesDetection:- Code security review

Prevention:

Prevention:- N/ADetection:-Security testing- Vendor contract: access to test plan and test results- Vendor contract: authorization to perform your own tests- Vendor contract: security acceptance criteria (Top 10? ASVS?)

Prevention:

Prevention:- Secure application deployment guidanceDetection:-Vulnerability/Configuration security assessment- Vendor contract: deployment guidance acceptance criteria

Prevention:

Prevention:- Maintain secure environments (networks, systems, services)- Incident response planing- Vendor agreement: service level agreement (impact analysis, cross-client breach notification, etc.)Detection:- Vulnerability assessment- Penetration testing- Vendor agreement: authorization to attack your own service

Prevention activities:

Prevention activities:- Rely on approved methods and tools to produce secure code- Vendor contract: ensure your software vendor agreed on security deliverables and activities

Detection activities:- Deploy small controls all along the line to detect potential weaknesses.- Vendor contract: ensure you have full right to test yoursystem and/or if necessary, its source code, and/or accessto independent testing results.

Agenda

Secure SDLC examples

• Microsoft• Mozilla• OWASP

• OWASP• BSIMM

SDLC, SDL?

• SDLC:– Systems Development Lifecycle

• SDL:

• SDL:– Security Development Lifecycle

• By Microsoft originaly• but many companies now have their 'SDL'

Microsoft SDL

(collaboration with Adobe and Cisco)

http://www.microsoft.com/security/sdl

Microsoft SDL

Mozilla

https://wiki.mozilla.org/Security/Reviews/Secure_Development_Lifecycle

Mozilla

OWASP OpenSAMM

https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model

OWASP OpenSAMM

http://bsimm.com

Agenda

"Custom" SDLC-security integration

Security requirements

Secure design

Coding guidelines

Security testing

Secure deployment

Incident response

Automated source code

review

Vulnerability management

Risk analysis

Risk assessment

Penetration tests

Governance (Software security group, taskforce, strategy , metrics and dashboards)

Policy & Compliance watch

Training & awareness program

Threat modeling

Design review

Get inspired

• Don't underestimate checklists!• Preliminary triage check:

1. Is it accessible from Internet?

1. Is it accessible from Internet?2. Is it collecting/handling regulated data?

• Privacy, Financial, HIPAA, etc.3. Is it connected to business process systems?4. Does it rely on risky technology?5. How critical is it for the business?6. Do we have control over the source code?7. Do we host the application?8. Etc.

Get inspired

• Document your solutions to major problems:1. How is input data validated?

2. How is output data encoded?3. How are 3rd party systems interrogated?4. How are requests authenticated/authorized/audited?5. How do you store sensitive data?6. How do you transport sensitive data?7. Do you use cryptography? How? Where?8. How do you handle errors and exceptions?

Get inspired

• Most of these models were built in years and adopted by large software vendors.

• Read them but don't try copy-pasting

• Read them but don't try copy-pasting them in your organization!

• Adapt: with your strengths/weaknesses:– You have $$$? Hire read teams!– You have talent? Strengthen your APIs!

If you got lost…1. Document your API-based solution

to each item of the OWASP Top 102. Integrate an automated run of a security testing

software against your application.

software against your application.3. Integrate an automated run of a source code

security analysis software.4. Add a questionnaire in your change management

process:1. Authentication?2. Authorization?3. Audit? Log?4. Input? Validation rule?5. Output? Encoding rule?

6. Access to 3rd. Parties?7. Sensitive data storage?8. Sensitive data transport?9. Use of cryptography?

If you got lost…5. Get a documented threat model and

how you respond to each threat6. Formalize your incident response team and process7. Establish coding guidelines (and make them

7. Establish coding guidelines (and make them available on the intranet)

8. Rearrange this list as it suits you best!

Questions

Thank you!

Contact me: antonio.fontes@owasp.org@starbuck3000https://www.slideshare.net/starbuck3000

https://www.slideshare.net/starbuck3000

Connect to your OWASP local chapters:https://www.owasp.org/index.php/Germanyhttps://www.owasp.org/index.php/Switzerland

This afternoon talk: Top 10 webapp intrusion techniques

Securing your web apps before they hurt the organization

Technology