securing your web apps before they hurt the organization

Antonio Fontes| OWASP Switzerland

Securing your web project before it hurts your organization

[email protected] / SDLC Security

Agenda

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

2

- What others do?- What can I do?


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

– Web applications security

3

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

4

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

5

What others do?What can I do?


Threat context

Incomplete specification documents:

6


Threat context

7


Threat context

8


Threat context

9


Threat context

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

10

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


Threat context

11


注意輔助CSRF的！！

12

Tú eres el CSRF!


Threat context

13


Threat context

14


Threat context

15


Threat context

16


Which of the following technologies

should we protect against "___

Injection" attacks?

Threat context

17

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

18


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

19

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

20


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

21


"").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();


22


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

23

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/

24



• About 35 webappsattack

25

attack techniques:



• About 15 weaknesses:

26

http://projects.webappsec.org



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

27

– 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

28

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

29

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:

30

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

31

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

32

– 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!"

33

• "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!

34

• 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


35



Reactive risk control in the SDLC

ImplementationInception Design Verification Release Operations

36




Prevention:

37

Prevention:- nah.

Detection:- nah.




Prevention:

38

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

Detection:- nah.




Prevention:

39

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:

40

Prevention:- Nah.

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




Prevention:

41

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

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




Prevention:

42

Prevention:- Nah.

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




Risk level

43




Risk level

Fixing costs

44

Risk level




Risk level

Fixing costs

45

Risk level

Tolerated risk level




Risk level

Fixing costs

46


Penetration test


Proactive risk control in the SDLC


Risk level

Fixing costs

47


Good practices: early prevention




Risk level

Fixing costs

48


Good practices: early prevention

Checkpoints: early detection




Residual risk

49

Good practice: early prevention Checkpoint: early detection

Risk level

Fixing costs


Residual risk




Prevention:

50

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




Prevention:- Secure design and architecture guidance

51

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

52

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




Prevention:

53

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:

54

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




Prevention:

55

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:

56

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


57



Secure SDLC examples

• Microsoft• Mozilla• OWASP

58

• OWASP• BSIMM


SDLC, SDL?

• SDLC:– Systems Development Lifecycle

• SDL:

59

• SDL:– Security Development Lifecycle

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


Microsoft SDL

60

(collaboration with Adobe and Cisco)

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


Microsoft SDL

61


Mozilla

62

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


Mozilla

63


OWASP OpenSAMM

64

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


OWASP OpenSAMM

65


BSIMM

66

http://bsimm.com


BSIMM

67


BSIMM

68


Agenda


69



"Custom" SDLC-security integration

Security requirements

Secure design

Coding guidelines

Security testing

Secure deployment

Incident response


70

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?

71

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?

72

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

73

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

74

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

75

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: [email protected]@starbuck3000https://www.slideshare.net/starbuck3000

77

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