Building Rugged Software in a DevOps World

In this talk, Matt will tackle the challenges of building robust secure software in a world of continuous delivery. To start, Matt will introduce a visual model of a typical delivery pipeline and illustrate how and where different security tools and processes can be layered into the model in an additive non-blocking way. Of course, DevOps adoption presents both challenges and opportunities. Understanding security and DevOps in the same frame of reference makes it possible to make Rugged part of our DNA. One of the foundations of continuous delivery is strong unit testing. To satisfy those seeking deep technical examples and practices they can take home with them and implement tomorrow, I will demonstrate and walk through a suite of common security related unit tests that can be used to ensure that security is a first class consideration that gets tested with each delivery.

Transcript

1. Building Rugged Software
   in a DevOps World
   Matt Konda
   @mkonda
   

   View Slide

2. OWASP?
   

   View Slide

3. Introduction
   1997 2006 2014
   Consultant
   Engineer
   Software
   Architect
   Director of
   Engineering
   Rabble Rouser:
   Perl
   Java Applet
   C++
   J2EE
   J2EE

   Spring
   Analytics
   Certificate Authority
   Vulnerability Scanner
   Penetration Test Manager
   Pricing
   Retail
   Banking
   Manufacturing
   Pharma
   Healthcare
   Research
   Ruby
   Rails
   Chicago BSides 2011, 2012
   Defcon Skytalk
   OWASP Chicago, MSP 2013
   AppSec USA 2012, 2013
   ChicagoRuby 2013
   Secure 360
   Lone Star Ruby 2013
   WindyCityRails 2013
   Chicago JUG 2014
   RailsConf 2014
   Converge 2014
   Chicago Coder Conference 2015
   MS in CS
   Founder
   Consultant
   Agile
   Clojure
   Graph Database
   Trying to hack a
   business model that
   succeeds while
   helping developers.
   Domains:
   Projects:
   DevOps / Automation
   Training
   Coaching
   Code Review
   Plugged in to SDLC
   Consulting
   Assessments
   @mkonda
   mkonda@jemurai.com
   DevOps
   Growing
   

   View Slide

4. View Slide

5. Rugged
   

   View Slide

6. Reminiscent of the Agile Manifesto Perhaps?
   

   View Slide

7. View Slide

8. This was a setup. Chicago style.
   

   View Slide

9. View Slide

10. But in Chicago, we make the best of every situation.
    

    View Slide

11. View Slide

12. I recognize that software has become a foundation of our modern world.
    I recognize the awesome responsibility that comes with this foundational role.
    I recognize that my code will be used in ways I cannot anticipate, in ways it was not
    designed, and for longer than it was ever intended.
    I recognize that my code will be attacked by talented and persistent adversaries who
    threaten our physical, economic and national security.
    I recognize these things – and I choose to be rugged.
    

    View Slide

13. I recognize that software has become a foundation of our modern world.
    I recognize the awesome responsibility that comes with this foundational role.
    I recognize that my code will be used in ways I cannot anticipate, in ways it was
    not designed, and for longer than it was ever intended.
    I recognize that my code will be attacked by talented and persistent adversaries who
    threaten our physical, economic and national security.
    I recognize these things – and I choose to be rugged.
    

    View Slide

14. I recognize that software has become a foundation of our modern world.
    I recognize the awesome responsibility that comes with this foundational role.
    I recognize that my code will be used in ways I cannot anticipate, in ways it was not
    designed, and for longer than it was ever intended.
    I recognize that my code will be attacked by talented and persistent adversaries
    who threaten our physical, economic and national security.
    I recognize these things – and I choose to be rugged.
    

    View Slide

15. Threat model
    

    View Slide

16. View Slide

17. View Slide

18. View Slide

19. View Slide

20. View Slide

21. DevOps /
    Continuous Delivery
    

    View Slide

22. View Slide

23. What does a delivery pipeline really look like?
    

    View Slide

24. Database
    What does a delivery pipeline really look like?
    AppServ1 AppServ2 AppServN
    WebServ1 WebServ2 WebServ3
    LB1 LB2
    

    View Slide

25. View Slide

26. View Slide

27. Database
    What does a delivery pipeline really look like?
    AppServ1 AppServ2 AppServN
    WebServ1 WebServ2 WebServ3
    LB1 LB2
    

    View Slide

28. Database
    What does a delivery pipeline really look like?
    AppServ1 AppServ2 AppServN
    WebServ1 WebServ2 WebServ3
    LB1 LB2
    

    View Slide

29. Database
    What does a delivery pipeline really look like?
    AppServ1 AppServ2 AppServN
    WebServ1 WebServ2 WebServ3
    LB1 LB2
    

    View Slide

30. Database
    What does a delivery pipeline really look like?
    AppServ1 AppServ2 AppServN
    WebServ1 WebServ2 WebServ3
    LB1 LB2
    

    View Slide

31. Database
    What does a delivery pipeline really look like?
    AppServ1 AppServ2 AppServN
    WebServ1 WebServ2 WebServ3
    LB1 LB2
    

    View Slide

32. View Slide

33. Database
    What does a delivery pipeline really look like?
    AppServ1 AppServ2 AppServN
    WebServ1 WebServ2 WebServ3
    LB1 LB2
    

    View Slide

34. View Slide

35. continuous delivery
    

    View Slide

36. Running Pipeline from Docker
    1. docker-machine create --driver
    virtualbox default
    2. eval $(docker-machine env default)
    3. docker pull owasp/pipeline:0.8.7
    4. docker run —rm owasp/pipeline:0.8.7 -h
    5. docker run —rm owasp/pipeline:0.8.7 -t
    brakeman https://github.com/Jemurai/
    triage.git
    

    View Slide

37. View Slide

38. Some Specifics Around Process
    

    View Slide

39. Security in the SDLC
    • Building software is a process.
    • The best way to make software secure is to make security
    part of the process.
    • There are many ways to do this - none is perfect.
    • Find a way to make the security fit your process.
    

    View Slide

40. Requirements
    Design
    Code
    Test
    Maintenance
    Classic Waterfall Delivery
    

    View Slide

41. Requirements
    Design
    Code
    Test
    Maintenance
    Classic Waterfall Delivery
    Security
    

    View Slide

42. Story
    Continuous Delivery: The Unit of Work is a Story
    Requirements Design
    Code
    Test
    

    View Slide

43. Story
    Continuous Delivery: The Unit of Work is a Story
    Requirements Design
    Code
    Test
    Security Requirements
    Security Unit Tests
    Exploratory Testing
    Static Analysis on Commit
    Code Review
    Threat model / attack surface
    Checklists
    Understand Dependencies
    

    View Slide

44. continuous delivery
    

    View Slide

45. Classic security sees this
    and wants to …
    

    View Slide

46. continuous delivery
    

    View Slide

47. View Slide

48. Think incremental
    

    View Slide

49. Fully clean start each time
    

    View Slide

50. Being able to deploy quickly is
    my #1 security feature.
    - Nick Galbreath
    

    View Slide

51. Automate security tools
    

    View Slide

52. continuous delivery
    Security Tool Automation:
    Code analysis
    Security unit tests
    Dynamic scanning
    etc.
    

    View Slide

53. continuous delivery
    Security Tests Run
    Exploratory Testing Includes Security
    

    View Slide

54. Integrations
    

    View Slide

55. pre-commit
    

    View Slide

56. Running Pipeline on a Git Hook
    1. Copy /hooks/pre-commit to your project in
    /.git/hooks
    2. chmod +x pre-commit
    3. Edit pre-commit to reflect your path and tools
    4. Regular process:
    1. Change a
    2. git add
    3. git commit -m “Testing”
    

    View Slide

57. View Slide

58. chat ops
    

    View Slide

59. View Slide

60. View Slide

61. Jenkins
    

    View Slide

62. View Slide

63. View Slide

64. View Slide

65. View Slide

66. View Slide

67. View Slide

68. View Slide

69. View Slide

70. View Slide

71. View Slide

72. Recap of “Tasks”
    • File: AV, FIM
    • Code:
    • Ruby/Rails: brakeman, bundler-audit
    • JavaScript: NodeSecurityProject, eslint, retire.js
    • Java: owasp-dependency-check
    • Checkmarx
    • Live: ZAP
    

    View Slide

73. Continuous Integration
    

    View Slide

74. View Slide

75. View Slide

76. View Slide

77. Checklists
    

    View Slide

78. View Slide

79. View Slide

80. View Slide

81. View Slide

82. Let’s talk about adversaries…
    

    View Slide

83. View Slide

84. This year, organized crime became
    the most frequently seen threat actor
    for Web App Attacks.
    Source: Verizon 2015 Data Breach Investigations Report
    

    View Slide

85. View Slide

86. View Slide

87. Testing
    

    View Slide

88. View Slide

89. View Slide

90. continuous delivery
    Since its easy to provision
    we can do security testing
    safely in a new env.
    

    View Slide

91. Audit tools
    

    View Slide

92. continuous delivery
    Deployment checks
    includes security
    audit checks.
    

    View Slide

93. Self documenting for
    regulatory and
    compliance!
    

    View Slide

94. Chaos tools
    

    View Slide

95. Change is good
    

    View Slide

96. continuous delivery
    Change is happening.
    It can be an
    opportunity
    instead of a hassle.
    

    View Slide

97. Complexity is an enemy
    

    View Slide

98. continuous delivery
    Small releases reduce complexity.
    Decomposition to micro-services reduces dependencies and complexity.
    Right now, security hurts.
    

    View Slide

99. Shared responsibility
    

    View Slide

100. continuous delivery
     Another principle of software delivery: build security in!
     Done means
     secure!
     Empowered to
     do security right!
     

     View Slide

101. Event based model …
     (Reactive)
     

     View Slide

102. Commit
     • Security Unit Tests
     • Static Code Analysis (Pipeline)
     • Security Requirements
     • Check Dependencies
     • Code Review
     • Checklists
     

     View Slide

103. Deploy
     • Scripted Provisioning / Built in Change Control
     • Provisioning Auditing (Chef Audit, hardening.io)
     • Gauntlt
     

     View Slide

104. Periodic
     • Full app analysis (static, manual pen test)
     • Secure Development Training
     • Baseline Security Requirements Review
     • ASVS Review
     • Data Science on Results
     

     View Slide

105. View Slide

106. Security Incident
     

     View Slide

107. So how do tests make our code rugged?
     

     View Slide

108. Demo
     cucumber --name "person is restricted
     from putting input into a field that
     will be executed by the system"
     

     View Slide

109. View Slide

110. Root cause
     def destroy
     @project = Project.find(params[:id])
     name = @project.name
     `rm /tmp/#{name}.log`
     @project.destroy
     respond_to do |format|
     format.html { redirect_to projects_url }
     format.json { head :no_content }
     end
     end
     What if @project.name is :
     "; cat /etc/passwd > public/passwd.html;”
     

     View Slide

111. How many
     people here
     Write tests?
     

     View Slide

112. How many
     people here
     Use TDD?
     

     View Slide

113. How many
     people here
     Use BDD?
     

     View Slide

114. How many
     people here
     currently write
     security tests?
     

     View Slide

115. rspec
     

     View Slide

116. View Slide

117. View Slide

118. Feature
     Scenario
     Given
     When
     Then
     

     View Slide

119. Feature: person is restricted from accessing
     project they do not own
     Scenario: person accesses a project
     that is not theirs
     
     Given a new project created by a user
     When a different person attempts to access the
     project
     Then the system should prevent access
     

     View Slide

120. Demo
     cucumber --name "person is restricted
     from accessing project they do not
     own"
     

     View Slide

121. View Slide

122. Given(/^a new project created by a user$/) do
     uuid = SecureRandom.uuid
     @user1 = "fb_user_1_#{uuid}@jemurai.com"
     register_as_user(@user1, "password")
     new_project("Insecure Direct Object Reference #{uuid}",
     "Forceful Browsing Desc")
     @url = current_url
     end
     When(/^a different person attempts to access the project$/) do
     logout(@user1)
     uuid = SecureRandom.uuid
     @user2 = "fb_user_2_#{uuid}@jemurai.com"
     register_as_user(@user2, "password")
     end
     Then(/^the system should prevent access$/) do
     visit @url
     expect(page).not_to have_content "Forceful Browsing Desc"
     end
     

     View Slide

123. Handy
     http://localhost:3000/projects?name=%27A%27%29%20or%201=1%20--
     def index
     email = current_user.email
     conditions = "owner LIKE '#{email}'"
     if params[:name]
     conditions = "name like #{params[:name]} " + conditions
     end
     @projects = Project.find(:all, :conditions=>conditions)
     respond_to do |format|
     format.html # index.html.erb
     format.json { render json: @projects }
     end
     end
     SELECT "projects".* FROM "projects"
     WHERE (name like 'A') or 1=1 -- owner LIKE 'test@test.com')
     For illustration
     

     View Slide

124. View Slide

125. Feature: user is prevented from putting XSS in project form fields
     A user wants to be sure that others users can't
     put XSS in the projects pages
     in order to ensure that their sessions and information are safe.
     @javascript
     Scenario Outline: xss attempt
     Given the field is ""
     When the value is ""
     Then the field result should be ""
     Scenarios: xss in fields
     | fieldname | value | result |
     | project[name] | ProjectName | noxss |
     | project[name] | ProjectName alert('project[name]->xss'); | xss |
     | project[desc] | ProjectDesc alert('project[desc]->xss'); | nods |
     

     View Slide

126. new_project("XSS Name #{@field} #{uniq}","XSS Desc #{@field}"+ uniq)
     click_link 'Edit'
     fill_in @field, :with => @value
     click_button "Update Project"
     if @result == "xss"
     # This should have xss in it...did it stick?
     alerted = false
     begin
     page.driver.browser.switch_to.alert.accept
     alerted = true
     rescue
     end
     if alerted
     fail("XSS Used to create Popup in #{@field} with #{@value}")
     else
     puts "Good news, no xss where expected."
     end
     else
     expect(page).to have_content @value
     end
     

     View Slide

127. Demo
     cucumber --name "user is prevented from
     putting XSS in project form fields"
     

     View Slide

128. View Slide

129. View Slide

130. Tests in app
     Rails Application
     rspec / cucumber
     

     View Slide

131. Tests out of app
     Rails Application: Triage Cucumber | SWTF
     

     View Slide

132. Tests out of app
     Rails Application: Triage
     (Insecure)
     Cucumber | SWTF
     Rails Application: Triage
     (Secure)
     

     View Slide

133. This means they can
     be easily adapted to
     test different apps
     

     View Slide

134. Demo
     cucumber --name "user is protected from
     malicious content and having their page
     framed"
     

     View Slide

135. View Slide

136. Feature: user is protected from malicious content and having
     their page framed
     A user wants to be sure that effective browser protections
     are enabled
     in order to ensure that their information is safe.
     @javascript
     Scenario Outline: check for secure headers attempt
     Given a new project created by a user
     And the page is ""
     When the header is ""
     Then the header value should be ""
     Scenarios: headers in pages
     | page | header | result |
     | projects/ | X-Frame-Options | DENY |
     | projects/ | X-XSS-Protection | 1 |
     

     View Slide

137. cookies = Capybara.current_session.driver.browser.manage.all_cookies
     csrf_token = Capybara.current_session.driver.browser.find_element(:xpath,
     "//meta[@name='csrf-token']").attribute('content');
     # Switch mode to net::http
     uri = URI.parse(url)
     http = Net::HTTP.new(uri.host, uri.port)
     http.verify_mode = OpenSSL::SSL::VERIFY_NONE
     request = Net::HTTP::Post.new(uri.request_uri)
     request['Cookie'] = cookies
     request.set_form_data( {
     "_method" => "put",
     "authenticity_token" => "#{csrf_token}",
     "project[name]"=> "header updated and verified",
     "commit"=>"Update Project" })
     response = http.request(request)
     ...
     if response[@header] == @result
     #pass
     else
     fail("Header #{@header} not set to #{@result} as expected.
     Instead was #{response[@header]}.")
     end
     

     View Slide

138. Demo
     cucumber --name "users favorite album is
     in cookie"
     

     View Slide

139. View Slide

140. View Slide

141. Simplified Steps
     • Injection: inject commands into fields and detect functions being called.
     • XSS: inject scripts into fields and detect that alerts are thrown
     • Mass assignment: set raw form data with net::http and send it to see
     how the server responds
     • CSRF: alter CSRF token and send otherwise valid request
     • Headers: interact with system and verify that headers are being set
     • Sensitive Data: open session cookie and inspect
     

     View Slide

142. accountability
     

     View Slide

143. culture
     

     View Slide

144. Security Examples
     

     View Slide

145. SELECT "orders".* FROM "orders"
     WHERE
     (rewards_code = 'a')
     union select id, 'product', 1, 1,
     'cc', 'cvv', 'expiration',
     email as first_name,
     encrypted_password as last_name,
     created_at, updated_at,
     id, 'reward' from users; --')
     

     View Slide

146. Getting Rugged?
     Train.
     Search for string concatenation: +, append prefer
     parameterized queries!
     Do code review.
     Use static analysis.
     Use web app scanning.
     

     View Slide

147. Output Encoding
     < <
     > >
     

     View Slide

148. Getting Rugged?
     Train.
     Search for {{{, innerHTML, .raw, utext, etc.
     Do code review.
     Use static analysis.
     Use web app scanning.
     

     View Slide

149. Insecure Direct Object Reference
     Hani Joanne
     Salary Record Salary Record
     ?
     Authorization fail!
     

     View Slide

150. View Slide

151. View Slide

152. • https://speakerdeck.com/mkonda/security-automation-pipeline
     • https://speakerdeck.com/mkonda/security-from-inception-1
     • https://speakerdeck.com/mkonda/real-world-security-testing
     

     View Slide

153. View Slide

154. Thank you.
     

     View Slide