Temporary version for audience attending the live IPC / Webtechconf 2012

1. Antonio Fontes| OWASP Switzerland
Securing your web project before it
hurts your organization

2. antonio.fontes@owasp.org / SDLC Security
Agenda
- What's happening right now?
- From reactive to proactive
- What others do?
- What can I do?
2

3. antonio.fontes@owasp.org / SDLC Security
Bio
• Antonio Fontes
• Geneva (Switzerland)
• Independant infosec/appsec consultant:
– 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
3

4. antonio.fontes@owasp.org / SDLC Security
Who are you?
• Builders? writing secure code
• Breakers? breaking into insecure code
• Defenders? protecting insecure code
• Managers?
4

5. antonio.fontes@owasp.org / SDLC Security
Agenda
What's happening right now?
From reactive to proactive
What others do?
What can I do?
5

6. antonio.fontes@owasp.org / SDLC Security
Threat context
Incomplete specification documents:
6

7. antonio.fontes@owasp.org / SDLC Security
Threat context
7

8. antonio.fontes@owasp.org / SDLC Security
Threat context
8

9. antonio.fontes@owasp.org / SDLC Security
Threat context
9

10. antonio.fontes@owasp.org / SDLC Security
Threat context
1. Analysis --> specs
2. Design --> architecture/API
3. Implement --> code
4. Validate --> binaries
5. Deploy --> product
6. Audit --> flaws/vulnerabilities
7. Back to 1.
10

11. antonio.fontes@owasp.org / SDLC Security
Threat context
11

12. antonio.fontes@owasp.org / SDLC Security
注意輔助CSRF
的！！
Tú eres el CSRF!
12

13. antonio.fontes@owasp.org / SDLC Security
Threat context
13

14. antonio.fontes@owasp.org / SDLC Security
Threat context
14

15. antonio.fontes@owasp.org / SDLC Security
Threat context
15

16. antonio.fontes@owasp.org / SDLC Security
Threat context
16

17. antonio.fontes@owasp.org / SDLC Security
Threat context
Which of the following technologies
should we protect against "___
Injection" attacks?
A.LDAP
B.HTML
C.Xpath
D.SQL (in the source code)
E.SQL (in a stored procedure)
17

18. antonio.fontes@owasp.org / SDLC Security
Threat context
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,
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.
18

19. antonio.fontes@owasp.org / SDLC Security
Threat context
Which of the following technologies
should we protect against "___
Injection" attacks?
A.LDAP --> yes
B.HTML --> yes
C.Xpath --> yes
D.SQL (in the source code) --> yes
E.SQL (in a stored procedure) --> yes
19

20. antonio.fontes@owasp.org / SDLC Security
Threat context
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,
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
20

21. antonio.fontes@owasp.org / SDLC Security
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)
}
21

22. antonio.fontes@owasp.org / SDLC Security
Threat context
// anti-SQL Injection attacks filter
String ValidateInput(string input)
{
String tmp = input.toUpperCase();
return(tmp.Replace("SELECT", "").replace("INSERT",
"").replace("UPDATE",
"DRDROPOP table" ?
"").replace("UNION","").replace("BENCHMARK,
"").replace("--", "").replace("OR 1=1",
"").replace("DROP", "").replace("@@version",
"").replace("WAITFOR", "").replace("OUTFILE", "")
...
return(tmp)
}
22

23. antonio.fontes@owasp.org / SDLC Security
Threat context
six@nine:~$ls /etc/conf/threats/
marketing
compliance
technology
hacking
hacktivism
cybercrime / corporate espionage
people
cyberterrorism
cyberwar
9 folder(s) found
23

24. antonio.fontes@owasp.org / SDLC Security
What do we know today?
• About 900 software vulnerabilities:
– http://cwe.mitre.org/
24

25. antonio.fontes@owasp.org / SDLC Security
What do we know today?
• About 35
webapps
attack
techniques:
25

26. antonio.fontes@owasp.org / SDLC Security
What do we know today?
• About 15
weaknesses:
http://projects.webappsec.org
26

27. antonio.fontes@owasp.org / SDLC Security
What do we know today?
• 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
27

28. antonio.fontes@owasp.org / SDLC Security
What do we know today?
• Software vulnerabilities appear at 3
major stages of the SDLC:
– DESIGN time
– IMPLEMENTATION time
– DEPLOYMENT time
Whether from within your organization…or from
your software vendor…
28

29. antonio.fontes@owasp.org / SDLC Security
What do we know today?
• Design time vulnerabilities:
– Appear in the specifications/requirements
documents (security features vs. secure features)
• Causes:
– Lack of security requirements analysis
– Misunderstanding of the requirements
– Insufficient or ambiguous specification
– Specifications not being reviewed
• Remediation cost: high 29

30. antonio.fontes@owasp.org / SDLC Security
What do we know today?
• Coding time vulnerabilities:
– Appear during the coding phase.
• Causes:
– Misunderstanding of the technology
– Lack of good practices
– Secure code not being reused
– Code not being reviewed
– Mistakes, distractions, errors, …
• Remediation cost: average 30

31. antonio.fontes@owasp.org / SDLC Security
What do we know today?
• Deploy time vulnerabilities:
– Appear during/after the deployment.
• Causes:
– Insecure default configuration
– Insecure installation procedure
– Installed on insecure systems/networks
– Configurations not being reviewed
• Remediation cost: low
31

32. antonio.fontes@owasp.org / SDLC Security
What do we know today?
• What about outsoucring?
– How do you make sure the code is clean?
– How do you know they can fix it?
• Causes:
– Incomplete vendor agreements / contracts
– Lack of requirements / specifications
– Lack of governance / controls
• Remediation cost: high
32

33. antonio.fontes@owasp.org / SDLC Security
What do we know today?
Organizations have a tolerance level (risk
appetite):
• "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?
33

34. antonio.fontes@owasp.org / SDLC Security
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.
34

35. antonio.fontes@owasp.org / SDLC Security
Agenda
What's happening right now?
From reactive to proactive
What others do?
What can I do?
35

36. antonio.fontes@owasp.org / SDLC Security
Reactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
36

37. antonio.fontes@owasp.org / SDLC Security
Reactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Prevention:
- nah.
Detection:
- nah.
37

38. antonio.fontes@owasp.org / SDLC Security
Reactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Prevention:
- "Our software architect has ten years experience in…". Nah.
Detection:
- nah.
38

39. antonio.fontes@owasp.org / SDLC Security
Reactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
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.
39

40. antonio.fontes@owasp.org / SDLC Security
Reactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Prevention:
- Nah.
Detection:
- Right password should work.
- Wrong password should not work.
- Logoff should work.
-…
- nah…
40

41. antonio.fontes@owasp.org / SDLC Security
Reactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Prevention:
- "our integrators have ten years experience in…" .. Nah.
Detection:
- "We will conduct a penetration test. Soon!!"
41

42. antonio.fontes@owasp.org / SDLC Security
Reactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Prevention:
- Nah.
Detection:
- PENTEST TIME!!! (aka: asking 'ethical hackers' to simulate an
intrusion attempt)
42

43. antonio.fontes@owasp.org / SDLC Security
Reactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Risk level
43

44. antonio.fontes@owasp.org / SDLC Security
Reactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Fixing
costs
Risk level
44

45. antonio.fontes@owasp.org / SDLC Security
Reactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Fixing
costs
Risk level
Tolerated risk level
45

46. antonio.fontes@owasp.org / SDLC Security
Reactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Fixing
costs
Risk level
Penetration
test
Tolerated risk level
46

47. antonio.fontes@owasp.org / SDLC Security
Proactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Fixing
costs
Risk level
Tolerated risk level
Good practices: early
prevention
47

48. antonio.fontes@owasp.org / SDLC Security
Proactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Fixing
costs
Risk level
Tolerated risk level
Good practices: early Checkpoints: early
prevention detection
48

49. antonio.fontes@owasp.org / SDLC Security
Proactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Residual risk
Tolerated risk level
Risk level
Fixing
costs
Good practice: early prevention Checkpoint: early
detection
49

50. antonio.fontes@owasp.org / SDLC Security
Proactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Prevention:
- Analysis of security & privacy requirements
Detection:
-Review
- Vendor selection criteria
50

51. antonio.fontes@owasp.org / SDLC Security
Proactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Prevention:
- 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?
51

52. antonio.fontes@owasp.org / SDLC Security
Proactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Prevention:
- Secure development environment configuration
- Secure coding guidance
- Vendor contract: access to code review reports & coding
practices
Detection:
- Code security review
52

53. antonio.fontes@owasp.org / SDLC Security
Proactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Prevention:
- N/A
Detection:
-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?)
53

54. antonio.fontes@owasp.org / SDLC Security
Proactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
Prevention:
- Secure application deployment guidance
Detection:
-Vulnerability/Configuration security assessment
- Vendor contract: deployment guidance acceptance criteria
54

55. antonio.fontes@owasp.org / SDLC Security
Proactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
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
55

56. antonio.fontes@owasp.org / SDLC Security
Proactive risk control in the SDLC
Inception Design Implementation Verification Release Operations
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 your
system and/or if necessary, its source code, and/or access
to independent testing results.
56

57. antonio.fontes@owasp.org / SDLC Security
Agenda
What's happening right now?
From reactive to proactive
What others do?
What can I do?
57

58. antonio.fontes@owasp.org / SDLC Security
Secure SDLC examples
• Microsoft
• Mozilla
• OWASP
• BSIMM
58

59. antonio.fontes@owasp.org / SDLC Security
SDLC, SDL?
• SDLC:
– Systems Development Lifecycle
• SDL:
– Security Development Lifecycle
• By Microsoft originaly
• but many companies now have their 'SDL'
59

60. antonio.fontes@owasp.org / SDLC Security
Microsoft SDL
(collaboration with Adobe and Cisco)
http://www.microsoft.com/security/sdl
60

61. antonio.fontes@owasp.org / SDLC Security
Microsoft SDL
61

62. antonio.fontes@owasp.org / SDLC Security
Mozilla
https://wiki.mozilla.org/Security/Reviews/Secure_Develo
pment_Lifecycle 62

63. antonio.fontes@owasp.org / SDLC Security
Mozilla
63

64. antonio.fontes@owasp.org / SDLC Security
OWASP OpenSAMM
https://www.owasp.org/index.php/Category:Software_Assurance_
Maturity_Model
64

65. antonio.fontes@owasp.org / SDLC Security
OWASP OpenSAMM
65

66. antonio.fontes@owasp.org / SDLC Security
BSIMM
http://bsimm.com
66

67. antonio.fontes@owasp.org / SDLC Security
BSIMM
67

68. antonio.fontes@owasp.org / SDLC Security
BSIMM
68

69. antonio.fontes@owasp.org / SDLC Security
Agenda
What's happening right now?
From reactive to proactive
What others do?
What can I do?
69

70. antonio.fontes@owasp.org / SDLC Security
"Custom" SDLC-security integration
Inception Design Implementation Verification Release Operations
Security Secure Coding Security Secure Incident
requirements design guidelines testing deployment response
Automated
Risk Threat Risk Vulnerability
source code
analysis modeling assessment management
review
Design Penetration
review tests
Training & awareness program
Policy & Compliance watch
Governance (Software security group, taskforce, strategy , metrics and dashboards)
70

71. antonio.fontes@owasp.org / SDLC Security
Get inspired
• Don't underestimate checklists!
• Preliminary triage check:
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. 71

72. antonio.fontes@owasp.org / SDLC Security
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?
72

73. antonio.fontes@owasp.org / SDLC Security
Get inspired
• Most of these models were built in years
and adopted by large software vendors.
• 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!
73

74. antonio.fontes@owasp.org / SDLC Security
If you got lost…
1. Document your API-based solution
to each item of the OWASP Top 10
2. Integrate an automated run of a security testing
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? 6. Access to 3rd. Parties?
2. Authorization? 7. Sensitive data storage?
3. Audit? Log? 8. Sensitive data transport?
4. Input? Validation rule? 9. Use of cryptography?
5. Output? Encoding rule? 74

75. antonio.fontes@owasp.org / SDLC Security
If you got lost…
5. Get a documented threat model and
how you respond to each threat
6. Formalize your incident response team and process
7. Establish coding guidelines (and make them
available on the intranet)
8. Rearrange this list as it suits you best!
75

76. Questions

77. antonio.fontes@owasp.org / SDLC Security
Thank you!
Contact me:
antonio.fontes@owasp.org
@starbuck3000
https://www.slideshare.net/starbuck3000
Connect to your OWASP local chapters:
https://www.owasp.org/index.php/Germany
https://www.owasp.org/index.php/Switzerland
This afternoon talk:
Top 10 webapp intrusion techniques
77