Mobile App Security. Using Threat Modeling to Review Mobile Devices and Apps. Copyright 2012 KRvW Associates, LLC

Transcription

1 Mobile App Security Using Threat Modeling to Review Mobile Devices and Apps

2 Your Instructor Ken van Wyk Work Experience 20+ years in Information Security l l l l CMU CERT/CC Founder DoD CERT SAIC, Para-Protect President and Founder, KRvW Associates, LLC Security Work Technical lead on hundreds of commercial engagements since 1996, including l l l l Application security assessments Enterprise risk assessments Secure network architecture Security testing of enterprises and applications Author of two popular O Reilly and Associates books l Incident Response: Planning and Management l Secure Coding: Principles and Practices Credentials BS Lehigh University 1985 l Mechanical Engineering Personal Interests Travel, world cuisine, wine, mountain biking, zymurgy Family ( Wife, two spectacularly spoiled basset hounds 2

3 Mobile platforms How secure are today s mobile platforms? Lots of similarities to web applications but... Gold rush mentality Developers are on a death march to produce apps Unprecedented rate Security often suffers... 3

4 Biggest issue: lost/stolen device Anyone with physical access to your device can get to a wealth of data PIN is not effective App data Keychains Properties See forensics results 4

5 Second biggest: insecure comms Without additional protection, ios devices are susceptible to the coffee shop attack Anyone on an open WiFi can eavesdrop on your data No different than any other WiFi device really Your apps MUST protect your users data in transit 5

6 Typical mobile app Most enterprise apps are basically web apps Clients issue web services request l SOAP or RESTful Servers respond with XML data stream Almost all web weaknesses are relevant 6

7 OWASP Top-10 (2010) 1.Injection 2.Cross-site scripting 3.Broken authentication and session management 4.Insecure direct object reference 5.Cross site request forgery 6.Security misconfiguration (new) 7.Insecure crypto storage 8.Failure to restrict URL access 9.Insecure transport layer protection 10.Unvalidated redirects and forwards (new) 7

8 8

9 OK then, so what can be done? Focus on the fundamentals Knowledge base l Vulnerabilities and attacks l Countermeasures Security activities l Threat modeling l Code review l Security testing Risk based l What s really at risk? 9

10 Design Review Threat Modeling

11 Design flaws are major Difficult and costly to fix post facto Too costly to fix? Often made because of false assumptions Trust models Underestimate attackers Naïveté Ignorance 11

12 Enter threat modeling We seek to enumerate Who What How Impact Mitigation Order does not matter Spreadsheets can help 12

13 Who is the threat agent? Who has access? What are their motivations? How resourceful are they? How knowledgeable? 13

14 What is the attack target? What is the target of the attack? From high level to low level Start with asset inventory Consider business value Technical significance Security dependencies 14

15 How will the attack work? This is the biggie What kinds of attacks are relevant? Available tools to automate Manual attacks Outside vs. inside Authenticated vs. not Remote vs. local 15

16 What is the impact? What is the business impact of an attack? Direct costs Indirect costs Reputation impact Down time 16

17 How can it be mitigated? How can we reduce likelihood of each attack? Mechanism Costs Feasibility User acceptance 17

18 Start with a diagram Top level to visualize functionality Think business, not technology NOT a network diagram Identify the assets Annotate with design patterns Servlet, thin client, session, MVC, etc. 18

19 Attack surface Enumerate the entire attack surface Top to bottom What interfaces are available, and how? APIs UIs B2B OS Signals Etc 19

20 Security zones Break down architecture into separate zones Client (PC) zone Middleware zone Application zone Database zone Enumerate all Components Agents 20

21 Enumerate attacks Attack trees help Start with high value outcome and reverse engineer l Dive into fine level of detail l List preconditions for each step It is OK to fail Some attacks may seem extreme and unlikely Consider abuse/misuse case attacks too 21

22 Include all components Key security components Authenticators Access controllers Input validators Output encoders Identify security controls explicitly 22

23 Consider data flow Identify and trace key data assets Credentials Account data Customer PII Crypto keys 23

24 Let s try a simple one Company background Global telecommunications company, USD$20B/yr Carrier grade reliability Brick and mortar Very little business on net Data processing in two groups Production data Administrative l Provisioning l Accounting/billing Provisioning done via legacy mainframe MVS/DB2 monster 24

25 Your project requirements Mobile app for provisioning Connects to DB2 back end Functional reqs Field techs securely access provisioning eng View/alter customer acct info All services of DB2 user Only authorized techs may use If device lost, no customer data lost If net not avail, app must cache commands and execute when avail 25

26 Design Celltop Java app Renderer Authenticator Mobile prov engine Authenticator Prov engine 26

27 Threat analysis Who What How Impact Mitigation 27

28 What have we learned? What glaring problems surfaced through this analysis? 28

29 Mobile device threat model Many considerations Platforms vary substantially Similar but still very different than traditional web app--even when heavy with client-side code It s more than just apps l Cloud/network integration l Device platform considerations 29

30 Mobile Threat Model 30

31 Mobile Threat Model 31

32 Getting Started Putting theory into practice

33 Where to begin? You re armed with good knowledge Perhaps too much? How do you build with confidence? 33

34 Dive deeper We re off to a good start, but you should take deep dive Build reference library l Technology docs l Vulnerability and attack descriptions Testing tools On-line sources l itunes University Stanford courseware Apple courseware 34

35 Include the key stakeholders Plenty of people/orgs have a vested interest in your success Business owner (or rep) Information security Privacy officer 35

36 Process practice Spend some time practicing what we ve done Threat modeling Code reviews Testing Small steps and practice help tremendously Small scale projects first 36

37 Design decisions matter Threat modeling is easily omitted Time spent here is time well spent Results help build overall understanding Feed code review process Feed test process 37

38 Technology watch Keep an eye on relevant developments Vulnerabilities Security tools Participate in community Conferences Forums Associations l OWASP l FIRST 38

39 Kenneth R. van Wyk KRvW Associates, LLC