Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Моделирование угроз: делаем вовремя вместе с командой разработки

Моделирование угроз: делаем вовремя вместе с командой разработки

Доклад Алекся Рыжкова (EPAM Systems) для PDUG-секции на PHDays 9.

Transcript

  1. Заголовок ptsecurity.com Моделирование угроз: делаем вовремя вместе с командой разработки

    Security engineer EPAM Systems Рыжков Алексей
  2. Заголовок 2 Aleksei Ryzhkov 1,5 year with SDL in EPAM

    AppSec team​ 7 years in development Crypto fan (Ph.D.) Whoami
  3. Заголовок 3 • Secure Development Lifecycle • Threat modeling activity

    – aims to identify security flaws in system design What are we talking about?
  4. Заголовок 4 Want to threat model every story What are

    we talking about? How to cover all stories? This Photo by Unknown Author is licensed under CC BY-SA Every-sprint requirement in Microsoft ‘SDL for Agile’ X stories in one sprint * Y projects
  5. Заголовок 5 Problems 4 solutions Blend together How to start

    Agenda
  6. Заголовок 6 Ideal world: one small project (with long release

    cycle) Go to planning Learn all stories Threat model
  7. Заголовок 7 Problem 1: Scale Go to planning Learn all

    stories Threat model Need to replicate scale Security adviser is shared between projects. Every day I have a planning meeting..
  8. Заголовок 8 Problem 2: Criteria of ‘security-relevant’ story Go to

    planning Learn all stories Threat model Need for prioritization criteria I ask business analysts for help. They don’t know details. Now I have 100500 stories
  9. Заголовок 9 Problem 3: Criteria of ‘security-relevant’ story Go to

    planning Learn all stories Threat model Need easy-to-use triage solution I ask developers for help. They know details. But they forgot/overloaded.
  10. Заголовок 10 Problem 4: one size doesn't really fit all

    Go to planning Learn all stories Threat model Need different (express, deep) threat model approach Finally I got 100500 some security-relevant stories
  11. Заголовок 11 Threat model every story: problems we want to

    solve Scale AppSec team Criteria for priority Easy for use ‘Optimal’ way to TM
  12. Заголовок 12 Scale Application Security team • Part of the

    project team • Enthusiast • Security Single Point Of Contact • Do security activities, ex: threat modeling, prioritize stories Key #1: Security champions Security Champions Playbook Alexander Antukh ZeroNights 2017
  13. Заголовок 13 Checklist «security affected areas» • Fullness ‘False positive’

    better ‘false negative’ • Ease to understand No security jargon • Short Who like 100500 pages? *Select 2 out of 3 Key #2: Security-relevant criteria
  14. Заголовок 14 Checklist «security affected areas» Group Weight Affected areas

    (tag words) Description Security features 5 Authentication / Authorization Adding or changing an authentication/authorization method or mechanism (login, roles, permissions, privilegies, ACL, certificates, SSL, LDAP) Shifting the trust relationships between any components or actors in the system (change of user roles, change of data access permissions, etc.) 1 Auditing, monitoring and alerting Adding or changing application monitoring, notifications (Skype, HipChat), gathering analytics (google analytics, xiti), auditing and compliance requirements (PCI, GDPR, HIPPA) 5 Cryptography Adding or changing cryptographic functionality: hashing algorithms, salt, encryption/decryption algorithms, SSL/TLS configuration, key management, etc. Attack surface 2 New API New exposed or consumed web-services, 3rd party integration, SOAP, REST 1 New pages New controls (forms, inputs, buttons), new import/export, parsing and handling input data Threat models 1 New 3rd party dependency E.g. new jar, framework (OWASP dependency check) 3 New data storage Database, repository, cache, file system, configuration management system, new logging mechanism, registry Any logical data storage, data at rest 3 New data flow HTTP, HTTPS/TLS/SSL, RPC/DCOM, JMS, RMI, SMB, UDP, IOCTL, IPSec, named pipe, Binary, ALPC Any logical data flow, data in transit across subsystems Assets 5 Handling sensitive data Credentials, user personal data (PII), credit card data (PCI) 2 Handling new type of data We don't receive such data previously, new statistics, new business entities
  15. Заголовок 15 This Photo is licensed under CC 0 Simple

    and fast Integration with Jira • Checklist as field in ticket Script to calculate score • ‘Tamper-Monkey’ script Key #3: Easy-to-use triage tool
  16. Заголовок 16 3 level of analysis deepness: Key #4: ‘Optimal’

    TM: different analysis level 0 score: no TM by default: ‘Express’ with Dev-team if not enough: deeper analysis by AppSec
  17. Заголовок 17 Key #4: ‘Optimal’ TM - express threat modeling

    Value Driven Threat Modeling Avi Douglen - AppSecUSA 2018 simplify involve dev team have baseline threat model … Threat Model Every Story: Practical Continuous TM Work for Your Team - Izar Tarandach - AppSecCali 2019
  18. Заголовок 18 4 base questions (Adam Shostack) Express TM What

    are we working on? What can go wrong? What are we going to do about it? Did we do a good job? (at 1-3) Dev team AppSec Security testing
  19. Заголовок 19 Blend all together Security ‘impact analysis’ process Scale

    with Champions Scoring criteria Jira integration Express threat- modeling
  20. Заголовок 20 Developer selects ‘affected areas’ in Jira-ticket Step 1:

    prioritize stories
  21. Заголовок 21 Script (tamper-monkey) calculates «impact score» Step 1: prioritize

    stories
  22. Заголовок 22 Result: get prioritized backlog with stories for analysis.

    E.g.: Step 1: prioritize stories
  23. Заголовок 23 0/small impact • champion verify story by his

    own • mark with Jira-label (to filter-out from backlog)  security_impact_verified - all security requirements are gathered inside the story  security_no_impact - story doesn’t have impact on security Higher impact • story goes to the ‘security impact analysis’ meeting (Express TM) • champion organize meeting Step 2: Champion reviews backlog
  24. Заголовок 24 Who: • Developer(s) of analyzed story • Security

    champion • Security advisor • Security tester (optionally) When: • Regular: ~every week, adjust to backlog • Short: 1h What – 2 out of 4 questions: 1. What are we working on? 2. What can go wrong? Step 3: Security impact analysis meeting
  25. Заголовок 25 1. Developer describes feature & design. 2. Security

    champion creates DFD 3. All together discuss ‘what can go wrong’ No need to find out solution at this moment 4. Optional: security tester suggest testing plan Impact analysis meeting: how
  26. Заголовок 26 Short description, open questions Data-flow diagram STRIDE-based questions

    • Link created Jira-tickets Notes for testing scenarios (if any) Impact analysis meeting: template
  27. Заголовок 27 Organize & drive meeting • Create DFD •

    Ask questions • Document threats Role: security champion
  28. Заголовок 28 Knows ‘how it works’ • Describe feature and

    design • Help to create right DFD • Say «у меня все секьюрно» start to think about security Role: developer
  29. Заголовок 29 Part of AppSec team: give advice • Help

    with process • Help to not stuck on threats + • Understand story • Decide if deeper analysis required Role: security advisor
  30. Заголовок 30 Part of AppSec team: optional on the meeting

    • Help with questions • Maintain interest by real examples + • Understand story • Decide how story will be tested Role: security tester
  31. Заголовок 31 Answering question: «What are you going to do

    about it?» Security champion • Work with meeting notes/assumptions/threats • Create Jira-tickets for mitigations AppSec • Help champion with mitigations, tickets (when asked by champion) • Conduct deeper threat modeling (whenever deemed appropriate) Dev team • Work with Jira-tickets (Implement/close/move to backlog etc) Step 4: finalize analysis [after meeting]
  32. Заголовок 32 Question №4: «Did we do a good job?»

    Jira-ticket verified by Security tester ‘Gray-box’ testing (instead of black box) • If Security tester was at the meeting => he knows the context Step 5: Verify results
  33. Заголовок 33 • Process summary: continuous threat modeling Prioritize stories

    • Developers: check fields in Jira-ticket • Script: calculate score-create backlog Review backlog • Security champion: review zero/low-impact stories Express analysis • Dev+AppSec: express threat modeling session • Security champion + advisor: process results Deep analysis/ testing • Security advisor: thorough threat modeling • Security tester: gray-box testing
  34. Заголовок 34 R - Responsible, A - Accountable, C -

    Consulted, I - Informed RACI matrix Developer Security champion Security advisor Security tester Stakeholders (Project, Risk manager) Assess ’affected areas’ for new story R A Review backlog R, A C Conduct security impact analysis meeting R R, A C C, I Finalize analysis/process meeting results R C, A I Additional threat modelling C R, A I Security testing C C R, A I
  35. Заголовок 35 All stories are covered Scale nice on low-risk

    projects Proc & Cons: coverage & assurance Risk to miss story at design phase - if both Developer and Security champion set ‘no impact’
  36. Заголовок 36 Triage & analysis based on potential security impact

    • Min: checked by dev and champion • Default: express analysis session • Max: analysis by advisor Proc & Cons: story triage & analysis level 0-score doesn’t guaranty story has no security impact
  37. Заголовок 37 ‘Up-to-date’ threat models At least two people (champion,

    advisor) have ‘full picture view’ Proc & Cons: up-to-date view on security posture Need prerequisites: • Security champion program • Security advisor • Baseline threat models Not much automation
  38. Заголовок 38 ‘Gray’-box testing (instead of black box) • Knows

    context – attack target • Knows design/TM – attack vectors Pros & Cons: security testing Need security tester Need him to attend meetings
  39. Заголовок 39 Build ‘security culture’ • Share knowledge • Spread

    ideas • Security gets developers attention Proc & Cons: AppSec and Dev team collaboration Photo by Headway on Unsplash
  40. Заголовок 40 Pros & Cons: summary Pros Cons Coverage &

    Scale Risk to miss some at design time Analysis level & triage based on story potential security impact Not much automation ‘Up-to-date’ threat modes Need security champion, advisor, baseline models Gray-box security testing Building security culture
  41. Заголовок 41 Champion: at each project, 20-50% Advisor: shared on

    few projects Security tester: shared + Created baseline threat models: advisor + champion, weeks/months What do I need to start? – resources, depends on… Photo by SpaceX on Unsplash
  42. Заголовок 42 Recap: problems we want to solve to threat

    model every story Scale AppSec team Criteria for priority Easy to use tool ‘Optimal’ way to TM
  43. Заголовок 43 Recap: threat model every story Security champions Checklist

    ‘security affected areas’ Integration with Jira 3 levels: 0, Express, Deep threat modeling Threat model every story – it’s real
  44. Заголовок 44 Contacts: • Me Aleksei_Ryzhkov@epam.com • Security champion Aliaksei_Tatarynchyk@epam.com

    Contacts & artefacts Artefacts from this report
  45. Заголовок ptsecurity.com Спасибо! Спасибо!