Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

New Era of Software with modern Application Security v1.0


Published on

(as presented at Codemotion Rome 2016)

This presentation will start with an overview of the current state of Application Insecurity (with practical examples). This will make the attendees think twice about what is about to happen to their applications. The solution is to leverage a new generation of application security thinking such as: TDD, Docker, Test Automation, Static Analysis, cleaver Fuzzing, JIRA Risk workflows, Kanban, micro web services visualization, and ELK. These practices will not only make applications/software more secure/resilient, but it allow them to be developed in a much more efficient, cheaper and productive

Published in: Software
  • Get access to 16,000 woodworking plans, Download 50 FREE Plans... ★★★
    Are you sure you want to  Yes  No
    Your message goes here

New Era of Software with modern Application Security v1.0

  1. 1. N E W E R A O F S O F T WA R E W I T H M O D E R N A P P L I C AT I O N S E C U R I T Y V E R S I O N 1 . 0 ( 1 9 / M A R / 2 0 1 6 ) C O D E M O T I O N R O M E @ D I N I S C R U Z
  2. 2. C O U P L E D I S C L A M E R S • This presentation has 233 slides and is designed to guide the delivery of this presentation and provide background information for offline reading • I speak really fast (for an English audience) • I have too much content - even when I deliver three-day courses :) • I abuse the term ‘Unit Testing’ : • for me the ‘Unit’ can be anything, from just a method to a full browser automation workflow • if it can be executed with a Unit Test Framework (NUnit, Mocha, Karma) then it is a Unit Test ( even if it is called an e2e or Integration test)
  3. 3. M E • Developer for 25 years • AppSec for 13 years • Day jobs: • Leader OWASP O2 Platform project • Head of Application Security at The Hut Group • Application Security Training for JBI Training • AppSec Consultant and Mentor
  4. 4. P E R F O R M E D H U N D R E D S O F S E C U R I T Y R E V I E W S • Found critical vulnerabilities in high profile applications (impacting millions of users) • desktop apps, websites, mobile apps, web services, security tools, frameworks, telephony, networks, etc… • Reported zero days to software vendors (before bug bounties) • 0wned data centres, networks, apps, databases
  5. 5. D E L I V E R E D T R A I N I N G T O 1 0 0 0 S O F D E V E L O P E R S • BBC • BAE Applied Intelligence • O2 • Alaska Airlines • Ocado • Capita (Orbit) • BSkyB • Harrods • Microsoft • Verifone • OWASP Conferences • BlackHat • TotalJobs • Cashflows • RunEscape • The Hut Group
  6. 6. I ’ M A D E V E L O P E R • Have shipped code • Have managed dev teams • Have written tests (with 100% code coverage) • Have created CI and CD environments (DevOps) • Worked on Secure Software Architecture and workflows (SecDevOps)
  7. 7. G R A P H S • I love Graphs • Recently I have realised that I have spend most of my life thinking about graphs and coding graphs • Graphs are great for data analysis and modelling • … but this is a topic for another presentation
  8. 8. @ D I N I S C R U Z
  9. 9. B L O G . D I N I S C R U Z . C O M
  10. 10. B O O K S • Published at Leanpub ( • Minimum price: 0 €
  11. 11. O WA S P O 2 P L AT F O R M • My brain in a tool • Very powerful but not easy to start using
  12. 12. N E W E R A O F S O F T WA R E W I T H M O D E R N A P P L I C AT I O N S E C U R I T Y
  13. 13. My thesis is that Application Security can be used to 
 define and measure Software Quality
  14. 14. • TDD with Code Coverage • Threat Models • Docker and Containers • Test Automation • SAST/DAST/IAST/WAF M O D E R N A P P L I C AT I O N S E C U R I T Y • Clever Fuzzing • JIRA Risk workflows • Kanban for Quality fixes • Web Services visualisation • ELK
  15. 15. J I R A W O R K F L O W
  16. 16. lets start with a view of the problem
  17. 17. S O F T WA R E I S E AT I N G AT TA C K I N G T H E W O R L D
  18. 18. W H O I S AT TA C K I N G Y O U
  19. 19. I F T H E AT TA C K E R T E L L S Y O U A B O U T T H E AT TA C K
  20. 20. Y O U S H O U L D T H A N K T H E M
  21. 21. The dangerous ones are the commercially focused criminals
  22. 22. It’s all about the money
  23. 23. … to hack you …
  24. 24. Buy botnet for $110
  25. 25. How much it cost to be an ‘internal user’
  26. 26. 100% Anti-virus non detection guarantee
  27. 27. But the credit cards were protected
  28. 28. E X A M P L E S O F AT TA C K S
  29. 29.
  30. 30. S Q L I N J E C T I O N
  31. 31. S Q L I N J E C T I O N T O O L - H AV I J
  32. 32. XSS
  33. 33. X S S AT TA C K - A PA C H E . O R G
  34. 34. X S S W O R M - M Y S PA C E
  35. 35. G E T PAY E D T O F I N D X S S
  36. 36. Man-in-the-middle
  37. 37. T J X ( PA R T O F T X M A X ) • 94 Million customer’s data compromised • $256 Million USD Settlement with Visa, MasterCard, Customers • Estimated cost to deal with incident (and improve security): 1 Billion USD
  38. 38. D O N ’ T A C C E P T I T
  39. 39. AT TA C K I N G C A R S
  40. 40.
  41. 41. D o S ( D e n i a l o f S e r v i c e )
  42. 42. S Y N F L O O D S 
 ( c r a s h i n g t h e f i re w a l l )
  43. 43. Brute force attacks
  44. 44. L O G I N AT T E M P T S
  45. 45. Attacking the Cloud
  46. 46.
  47. 47. Google Dorks
  48. 48. Punkspider
  49. 49. Web crawler that performs penetration tests and indexes sites based on the vulnerabilities they have. UK sites that have XSS and SQL injection
  50. 50. UK sites that have XSS and SQL injection
  51. 51. Attacking the Internet of Things (IoT)
  52. 52. Cyberwar
  53. 53. Attacking markets
  54. 54. R U S S I A N H A C K E R S M O V E D R U B L E R AT E W I T H M A LWA R E
  55. 55. A G U Y C H A L L E N G E D H A C K E R S AT D E F C O N T O H A C K H I M …
  56. 56. Attacks coming soon…
  57. 57. 1. Mass supermarket failure (no food, milk, water available) 2. Bank or Financial Company collapse 3. Fabricated News 4. Mass loss, sale and exploitation of Individuals Private information
  58. 58. 5. Mass Identify Theft! • Can you prove that YOU are YOU? • What if the ‘Computer says differently’? • What if your picture ‘in the computer’ is modified? • What if your date-of-birth and family name are modified? • What if you are shown as DEAD in the system? • How many databases would it take to kill you digitally • What if there is NO record at ALL that you ever existed? • in ID database • in Financial database • in Hospital databases • etc...?
  59. 59. 6. Medical systems exploitation: • Wrong medicaments delivered, sold • Manipulating hospital systems • Corruption of medial records • Sale of medial records 7. Car/Plane/Train crashes: • all lights are made green at the same time • maintenance records are fiddled or manipulated (Fake parts scam) • Remote control and manipulation • Manipulation of traffic guidance systems
  60. 60. 8. ID cards/Passport exploits • Government loses ability to issue new ID cards • Massive ID Card fraud 9. Companies are selling Fake ID carts with no ability to stop them 10.No Cashpoints 11.New laws introduced in parliament (without formal discussion/approval) 12.Fighter jet fires missile into crowd / building / city
  61. 61. 13. Mass hysteria at stadium, where a big message on screen says: •"...RUN!!!!!! The stadium is going to blow in 2 minutes..." •"...There is a terrorist in the stadium, here is his picture! Find him and kill him!!..." 14. Water poisoning 15. Manipulation of controls that introduce or remove chemicals in water 16. Attacks on electric grid 17. Mass compromise of online email systems 18.Corruption of Inland Revenue database (if they did not know who owed what and they could not be able to collect money from taxes) 19. Websites massively attack users and users are afraid to go online 20. Localised or global Internet shutdowns
  62. 62. I think you get the idea for more examples read:
  63. 63. TA L K TA L K
  64. 64. Where is 
  65. 65. committees-a-z/commons-select/culture-media-and- sport-committee/inquiries/parliament-2015/cyber- security-15-16/
  66. 66. “After police & PWC investigation TalkTalk CEO admits firm 'underestimated' cybersecurity and touts change in culture” “Investigation by PwC shown TalkTalk has been acting like a startup rather than a major company, (new services, innovate, move fast) and they saw security as a technology issue, not a business one and underestimated the challenge.”
  67. 67. …moving on to user’s identities
  68. 68. H AV E Y O U B E E N P W N E D ?
  69. 69. B U G B O U N T I E S
  70. 70. Bug bounties are a sign of Application Security Maturity
  71. 71. If you don’t have one you are saying … I’m a good target to attack …
  72. 72. G I T H U B
  73. 73. G O O G L E
  74. 74. L E T ’ S H A C K ( A L I T T L E B I T ) H T T P : / / N E W S . B B C . C O . U K 
 H T T P : / / M A N I F E S T O . S O F T WA R E C R A F T S M A N S H I P. O R G / Demo
  75. 75. …..basically…..
  76. 76. …..but…..
  77. 77. D O N T PA N I C
  78. 78. Unless you are directly targeted …
  79. 79. …the probability of 
 you, your company or your apps being attacked is still low
  80. 80. … not because you are secure
  81. 81. … but because there are not enough attackers
  82. 82. … and the business model of the current attackers has not evolved to the next level 
 (where they find a way to make money with your assets)
  83. 83. N E W G E N E R AT I O N O F A P P L I C AT I O N S E C U R I T Y T H I N K I N G
  84. 84. 1.TDD with Code Coverage 2.Threat Models 3.Docker and Containers 4.Test Automation 5.SAST/DAST/IAST/WAF 6.Clever Fuzzing 7.JIRA Risk workflows 8.Kanban for Quality fixes 9.Web Services visualisation 10.ELK
  85. 85. These tools/techniques are designed to 
 A) Improve code Quality
 B) Make AppSec possible
  86. 86. 1 ) T D D W I T H C O D E C O V E R A G E • All code changes must have tests • Code Coverage is key to understand the impact of those changes • Devs, QA and Security teams should be communicating using tests
  87. 87. 2 ) T H R E AT M O D E L S
  88. 88. 2 ) T H R E AT M O D E L S • Are ‘technical briefs’ (i.e. better briefs) • Should be the ‘source of truth’ in an organisation about their apps and code • Should be done for: • Applications • Components • Features
  89. 89. 3 ) D O C K E R A N D C O N TA I N E R S
  90. 90. 3 ) D O C K E R A N D C O N TA I N E R S • Provide repeatable and destroyable QA environments • Enable DevOps • Next paradigm of Secure Applications • Dramatically improve the quality and resilience of Tests
  91. 91. 4 ) S A S T / D A S T / I A S T / WA F • SAST - Static Application Security Testing • DAST - Dynamic Application Security Testing • IAST - Interactive Application Security Testing • WAF - Web Application Security Firewall
  92. 92. 5 ) T E S T A U T O M AT I O N • Tests must run automatically on all commits of all branches • AppSec tests must be used to ‘identify changes to attack surface’ • Empower two CI pipelines • Super fast - push to production • Pause - needs review
  93. 93. 5 ) C L E V E R F U Z Z I N G
  94. 94. 6 ) J I R A R I S K W O R K F L O W S
  95. 95. 7 ) K A N B A N F O R Q U A L I T Y F I X E S • SCRUM tends to be more of a Religion than Agile • Kanban WIP (Work in Progress) is key for Application Security Fixes
  96. 96. 8 ) W E B S E R V I C E S V I S U A L I S AT I O N
  97. 97. 9 ) E L K • ElasticSearch + LogStash + Kibana • Use it everywhere and everybody customises it • Also for developers (not just Ops)
  98. 98. Just to say it again …. These tools/techniques are designed to 
 A) Improve code Quality
 B) Make AppSec possible
  99. 99. Without them you are not really doing Application Security
  100. 100. … and you have a 
 Development Problem not an
 Application Security Problem
  101. 101. A P P S E C A N D Q U A L I T Y
  102. 102. Software Craftsmanship is about Software Quality
  103. 103. “I like my code to be elegant and efficient"
 Bjarne Stroustup, inventor of C++ “Clean code is simple and direct. Clean code reads like well-designed prose”
 Grady Booch, author “Clean code can be read, and enhanced by a developer other than its original author”
 ”Big” Dave Thomas, founder of OTI “Clean code always looks like it was written by someone that how cares”
 Michael Feathers, author “You know you are working on clean code when each routine you read turns out to be pretty much what you expected”
 Ward Cunningham, inventor of Wiki
  104. 104. a big problem with the previous comments and the Software Craftsmanship concept is 
 ‘How to define Quality?’
  105. 105. Everybody knows that Quality is key … but … ‘how to measure Quality?’
  106. 106. My thesis is that Application Security can be used to 
 define and measure Software Quality
  107. 107. Not all Software Quality issues are 
 Application Security issues
 But all Application Security issues are 
 Software Quality issues S h e r i f M a n s o u r, E x p e d i a
  108. 108. Application Security is all about the non-functional requirements of software* * s o f t w a re = a p p s , w e b s i t e s , w e b s e r v i c e s , a p i s , t o o l s , b u i l d s c r i p t s = c o d e
  109. 109. Application Security is all about understanding 
 HOW the software works* * v s h o w s o f t w a re b e h a v e s
  110. 110. Using Application Security 
 I can measure the quality of software
  111. 111. Because Application Security 
 measures the unintended side effects of coding
  112. 112. T H E P O L L U T I O N A N A L O G Y
  113. 113. T E C H N I C A L D E B T I S A B A D A N A L O G Y • The developers are the ones who pays the debt • Pollution is a much better analogy • The key is to make the business accept the risk (i.e the debt) • Which is done using the JIRA RISK Workflows
  114. 114. W R I T I N G S E C U R E C O D E M Y T H
  115. 115. “If only software developers had security knowledge they would be able write secure code”
  116. 116. This is a myth because secure code has little to do with developer’s skills and craftsmanship
  117. 117. Software security (or insecurity) is a consequence of the Software development environment 
 (namely the business and managers focus)
  118. 118. And I know that this is a myth because I cannot write ‘secure code’ 
 when I’m programming
  119. 119. J I R A R I S K W O R K F L O W
  120. 120.
  121. 121. ‘ F I X I N G ’ F L O W
  122. 122. ` ‘ R I S K A P P R O VA L’ F L O W
  123. 123. F U L L W O R K F L O W 
 ( f ro m D e v p o i n t o f v i e w ) 1. Vulnerability/issue is found (RISK ticket opened)  2. Dev understands the issue, writes test that replicates the issue, opens ticket in his project’s JIRA and tries to figure out the best way to fix it  3. Dev asks for guidance to AppSec team 4. AppSec team points to WIKI page (existing or newly created) 5. Dev uses guidance to fix it (and updates test so that is is now a regression test) 6. Commit(s) are made, RISK ticket is updated with link to commit(s) 7. Dev asks AppSec to review fix 8. AppSec reviews fix, and if all looks ok, close the RISK ticket
  124. 124. M A P P I N G T O I N F O S E C R I S K S Labels for reporting and filters
  125. 125. M A P P I N G J I R A T I C K E T S T O T E S T S
  126. 126. J I R A D A S H B O A R D S
  127. 127. W E E K LY E M A I L S W I T H R I S K S TAT U S
  128. 128. K E Y C O N C E P T S O F T H I S W O R K F L O W • All tests should pass all the time • Tests that check/confirm vulnerabilities should also pass • The key to make this work is to: 
 Make business owners understand the risks of their decisions (and click on the ‘accept risk’ button)
  129. 129. You have to make sure that it is your boss that gets fired
  130. 130. … he/she should make sure that it is his/hers boss that gets fired …
  131. 131. … all the way to the CTO (i.e. Board level responsibility)
  132. 132. T E S T I N G
  133. 133. If you make a change and 
 don’t have a test You are making random changes
  134. 134. How to solve this problem?
  135. 135. You don’t You sack your manager
  136. 136. As a developer you need to have pressure from management to deliver code that is:
 Solid Secure Testable Provable Readable Maintainable 
 Basically, deliver Quality Code
  137. 137. 9 9 % C O D E C O V E R A G E …is not the destination 
 …it is ‘base camp’
  138. 138. With 99% code coverage you are here
  139. 139. Without 99% code coverage 
 you have not solved really hard problems in the testability of your code
  140. 140. Import note: 
 If 99% code coverage is just an ‘management requirement’ 
 … and is being gamed by devs
 … and you have LOTS of stupid ‘Unit tests’ 
 i.e. 99 x 1% code coverage or
 999 x 0.1 % code coverage
  141. 141. then you also need to sack your manager
  142. 142. You manager’s job is to help you to deliver: Solid Secure Testable Provable Readable Maintainable Code
  143. 143. To make testing effective …
 …testing (from Unit Testing to Integration tests) needs to done in the IDE with real-time execution and Code coverage
  144. 144. Q A , R E G R E S S I O N A N D S E C U R I T Y T E S T S
  145. 145. Wallaby’s realtime Unit test Execution and Code Coverage
  146. 146. M I S S I N G T E S T S 
 ( a n d 1 0 0 % c o d e c o v e r a g e )
  147. 147. R E A L W O R L D M U TAT I O N T E S T I N G •
  148. 148. W H Y D O A P P L I C AT I O N S E C U R I T Y ?
  149. 149. Because you care about: 
 your users
 good engineering your application your company
  150. 150. You have been lucky so far due to lack of commercially focused attackers
  151. 151. This has been a Blessing and Curse
  152. 152. You are making an 
 Hedged bet
  153. 153. the Security of your code vs Skill and motivation of attacks will not change in next 2 years Your hedge bet is that :
  154. 154. Most of you are creating the perfect storm ….
  155. 155. User personalisation + Digital Payments + APIs
  156. 156. How insecure is your code?
 How many risks/vulnerabilities are you aware of?
 And have Accepted?
  157. 157. How long does it take you to Fix Security/Quality issues?
  158. 158. E X T E R N A L S I G N S O F L A C K O F F O C U S & L A C K O F A P P S E C P O W E R • Not 100% SSL (with HSTS and Secure Cookies) • No consolidation of Javascripts, which implies No CI (Continuous Integration) • Cookie Salad (caused by lack of State Service in back end) • Easy DoS by normal business activities • “We’re hiring for AppSec” jobs posts • Easy-to-find vulnerabilities (low-hanging-fruit) • No public bug bounty
  159. 159. D O E S Y O U R C O M PA N Y / T E A M H AV E : • AppSec team/person • Security Champion • Secure coding standards • Threat Models • OWASP contributors • Secure code reviews
  160. 160. If your answer was not YES to all of them... 
 Your Application WILL have a high number of Security Vulnerabilities
  161. 161. And you need to invest in Application Security
 Which if done correctly will improve the Quality of your code
  162. 162. M A N A G E R S A N D B U S I N E S S O W N E R S
  163. 163. S E N I O R M A N A G E M E N T O V E R S I G H T • ‘Security Memo’ (from God) • Incident response plans • Emergency response exercises (can you detect them?) • Cyber Insurance • Enterprise Cyber Risk management • Which C-level executive will get fired?
  164. 164. 6 M O N T H A P P S E C I N V E S T M E N T What Description Cost Head Of Appsec 1 x person £100K Senior Developers 2 x persons £120K Appsec Ops 2 x persons £80K External Security Company 100 x days £100K Security Tools Static, Dynamic, Interactive Scanners £100K Dev App Sec Tools CI , Collaboration, Cloud, IDE plugins £50K Education Training, Conferences, Bug Bounties, £50K Total £600K
  165. 165. W E H AV E S O L U T I O N S
  166. 166. O WA S P ! ! ! !
  167. 167. G R E AT P R E S E N TAT I O N O N S E C D E V O P S
  168. 168. O p e n S A M M ( S e c u r i t y A s s u r a n c e S e c u r i t y M o d e l )
  169. 169. B S I M M ( B u i l d i n g S e c u r i t y i n M a t u r i t y M o d e l )
  170. 170. S E C U R I T Y D E V E L O P M E N T L I F E C Y C L E
  171. 171. T I P S F O R B U I L D I N G A M O D E R N S E C U R I T Y E N G I N E E R I N G O R G A N I S AT I O N
  172. 172. H O W T O B U I L D S E C U R E W E B A P P L I C AT I O N
  173. 173. N E W S E C U R I T Y S E R V I C E S - 2 FA
  174. 174. D E P L O Y, D E P L O Y, D E P L O Y • Push to production and refactor without fear • Be like GitHub and use CI/CD to deploy 175 times in one day and 12,602 times in one year
  175. 175. •
  176. 176. •
  177. 177. F I N A L T H O U G H T S
  178. 178. U N W R I T T E N R U L E S O F A P I S “Every API is destined to be connected to the internet”
  179. 179. U N W R I T T E N R U L E S O F A P I S “All API data wants to be exposed in a Web Page”
  180. 180. “Would you fly in a plane that has the code quality of your APIs”
  181. 181. Application Security can be used to 
 define and measure Software Quality
  182. 182. Thanks, any questions?