Mobile App Security Using Threat Modeling to Review Mobile Devices and Apps
Your Instructor Ken van Wyk ken@krvw.com 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 (http://www.vanwyk.org/ken) Wife, two spectacularly spoiled basset hounds 2
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
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
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
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
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
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
Design Review Threat Modeling
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
Enter threat modeling We seek to enumerate Who What How Impact Mitigation Order does not matter Spreadsheets can help 12
Who is the threat agent? Who has access? What are their motivations? How resourceful are they? How knowledgeable? 13
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
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
What is the impact? What is the business impact of an attack? Direct costs Indirect costs Reputation impact Down time 16
How can it be mitigated? How can we reduce likelihood of each attack? Mechanism Costs Feasibility User acceptance 17
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
Attack surface Enumerate the entire attack surface Top to bottom What interfaces are available, and how? APIs UIs B2B OS Signals Etc 19
Security zones Break down architecture into separate zones Client (PC) zone Middleware zone Application zone Database zone Enumerate all Components Agents 20
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
Include all components Key security components Authenticators Access controllers Input validators Output encoders Identify security controls explicitly 22
Consider data flow Identify and trace key data assets Credentials Account data Customer PII Crypto keys 23
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
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
Design Celltop Java app Renderer Authenticator Mobile prov engine Authenticator Prov engine 26
Threat analysis Who What How Impact Mitigation 27
What have we learned? What glaring problems surfaced through this analysis? 28
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
Mobile Threat Model 30
Mobile Threat Model 31
Getting Started Putting theory into practice
Where to begin? You re armed with good knowledge Perhaps too much? How do you build with confidence? 33
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
Include the key stakeholders Plenty of people/orgs have a vested interest in your success Business owner (or rep) Information security Privacy officer 35
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
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
Technology watch Keep an eye on relevant developments Vulnerabilities Security tools Participate in community Conferences Forums Associations l OWASP l FIRST 38
Kenneth R. van Wyk KRvW Associates, LLC Ken@KRvW.com http://www.krvw.com