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.

Speed the Right Way: Design and Security in Agile

28 views

Published on

Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/2NeFoWE.

Kevin Gilpin discusses the renewed focus of the software design process and code complexity in software security, describing how design review can be modernized to help improve application security. Filmed at qconlondon.com.

Kevin Gilpin is an enterprise software engineer with over 20 years of experience spanning various industries including healthcare, automotive, logistics, and life sciences. He was recently CTO of Conjur, then CyberArk Fellow following the acquisition of Conjur by CyberArk in 2017. He is a pioneer in the adoption of DevOps, cloud, and containers in the enterprise.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Speed the Right Way: Design and Security in Agile

  1. 1. SPEED THE RIGHT WAY: DESIGN AND SECURITY IN AGILE KEVIN GILPIN, CTO @kegilpin
  2. 2. InfoQ.com: News & Community Site Watch the video with slide synchronization on InfoQ.com! https://www.infoq.com/presentations/ security-design-review/ • Over 1,000,000 software developers, architects and CTOs read the site world- wide every month • 250,000 senior developers subscribe to our weekly newsletter • Published in 4 languages (English, Chinese, Japanese and Brazilian Portuguese) • Post content from our QCon conferences • 2 dedicated podcast channels: The InfoQ Podcast, with a focus on Architecture and The Engineering Culture Podcast, with a focus on building • 96 deep dives on innovative topics packed as downloadable emags and minibooks • Over 40 new content items per week
  3. 3. Purpose of QCon - to empower software development by facilitating the spread of knowledge and innovation Strategy - practitioner-driven conference designed for YOU: influencers of change and innovation in your teams - speakers and topics driving the evolution and innovation - connecting and catalyzing the influencers and innovators Highlights - attended by more than 12,000 delegates since 2007 - held in 9 cities worldwide Presented at QCon London www.qconlondon.com
  4. 4. SPEEDING THE RIGHT WAY 2
  5. 5. WHO AM I? • Recently CTO, Conjur / CyberArk Fellow • 20+ Years of Enterprise Software Engineering in healthcare, automotive, logistics, data science. • Pioneer in DevOps, Cloud, and Containers • MS Aerospace Engineering MIT • Aviation enthusiast! 3
  6. 6. “BLAME THE PROGRAMMER” 4
  7. 7. AGENDA • Discussion of breach examples • How to review designs for security • How to modernize design reviews 5
  8. 8. COMPLEX SYSTEMS FAIL IN COMPLEX WAYS 6
  9. 9. Attackers carried out their attack with a series of steps that let them hop, skip and jump their way into generating access tokens for millions of Facebook users. SPEEDING THE WRONG WAY: FACEBOOK “VIEW AS” 7
  10. 10. SPEEDING THE WRONG WAY: FACEBOOK “VIEW AS” “control who can see what you share” 8
  11. 11. SPEEDING THE WRONG WAY: FACEBOOK “VIEW AS” 9
  12. 12. SUMMARY OF DESIGN FLAWS IN “FACEBOOK VIEW AS” PROBLEM EXAMPLE IMPACT Over-privileged service “Video upload” service able to obtain a token for any user “Video upload” service able to leak a token for the wrong user into the browser Execution of untrusted code “View as” did not whitelist the UI components which were trusted to operate correctly “Video upload” widget was improperly loaded and executed in the UI Lack of a secure sandbox “View as” rendered untrusted code directly into the user’s browser Flaw in “Video upload” was exposed directly to the user rather than contained in a sandbox 10
  13. 13. The “Swiss Cheese” model Image: https://en.wikipedia.org/wiki/Swiss_cheese_model … “likens human systems to multiple slices of swiss cheese, stacked side by side, in which the risk of a threat becoming a reality is mitigated by the differing layers and types of defences which are "layered" behind each other” 11
  14. 14. UK NHS BREACH “TYPE 2 OPT-OUT” Point of care system didn’t send the “Opt-Out” election to the NHS So the NHS used all the patient data for 700,000 people against their wishes 12
  15. 15. CASE STUDY “TYPE 2 OPT-OUT” NHS BREACH 13
  16. 16. SUMMARY OF DESIGN FLAWS IN “TYPE 2 OPT-OUT” PROBLEM EXAMPLE IMPACT Default allow Data access allowed unless denied Failure to propagate the opt-out election resulted in leaked data Expiration No time limit on opt-out election Impact of the bug extended for an unlimited time Lack of user notification User not informed about how their data was being used Failure to propagate the opt-out election was not reported by the users 14
  17. 17. BACK TO THE DRAWING BOARD 15
  18. 18. HOW WE COMMUNICATE: WHITEBOARDS Image: http://agilemodeling.com/artifacts/freeForm.htm 16
  19. 19. HOW WE COMMUNICATE: CHAT Image: https://www.thesprintbook.com/slack 17
  20. 20. Image: https://confluence.atlassian.com/doc/blog/2015/08/how-to-document-product-requirements-in-confluence HOW WE COMMUNICATE: WIKI 18
  21. 21. HOW WE COMMUNICATE: PULL REQUESTS 19
  22. 22. THE COGNITIVE ARTIFACT – A FOCAL POINT FOR DISCUSSION OAUTH2 PROTOCOL FLOW Source: https://www.onwebsecurity.com 20
  23. 23. PROPERTIES OF A GOOD COGNITIVE ARTIFACT 21 • Big enough and expressive enough for the design problem • Built on a collaborative platform • Lives close to the code • The quality of the artifact becomes the quality of the product
  24. 24. SIMPLE FORMULA FOR A DESIGN DOCUMENT 1. Overview 2. Diagram(s) 3. Design discussion 4. API specification 5. Q&A 22 ● You’ll get feedback here ● Use RFCs as much as possible
  25. 25. VISUALIZING “AS DESIGNED” VERSUS “AS BUILT” • Design changes made during coding must be reflected back to the design artifacts • Otherwise design artifacts get out of date 23
  26. 26. GET MORE EYES ON THE PROBLEM 24
  27. 27. WIDEN THE CIRCLE TO MAKE DESIGN MORE ACCESSIBLE • A variety of people can add unique and valuable perspectives to the design review. • To make design reviews more effective, make it clear to reviewers what’s being asked of them. 25
  28. 28. ELEMENTS OF A DESIGN REVIEW • Transforms individual risk into a shared responsibility. • Like a pull request. Agile, but less technical. • Performed upstream of the coding, and in parallel with prototyping. • Importance and frequency of review is according to the risk. • Microservice boundaries can be a helpful way to “tag” the code which needs extra design review attention. Traditional test cases can verify that the code functions properly 26
  29. 29. DESIGN REVIEW: WHO AND HOW MUCH? 27
  30. 30. KEY TAKEAWAYS • Security design flaws are not bugs… and flaws will be complex • Invest in the right visual artifacts to get more eyes on the design • Update the design artifact to accurately reflect “as built” • Clearly indicate in code, READMEs, etc where a visitor can find the security design used in each project. • For brand new designs, expect to invest heavily in design artifacts and design reviews in order to lower the risk 28
  31. 31. 29 DESIGN, A NOBLE PROFESSION I took this photo-of-a- photo Sunday (March 3, 2019) at the RAF museum in Hanger 2 (World War I).
  32. 32. THANK YOU @kegilpin https://www.linkedin.com/in/kegilpin/ Further Reading “Always Another Dawn” by Albert Scott Crossfield
  33. 33. Watch the video with slide synchronization on InfoQ.com! https://www.infoq.com/presentations/ security-design-review/

×