Defending Behind the Mobile Device

Editor's Notes

• #5: Everyone has a different definition of riskDevelopers look at threats different than IT peopleIT looks at threats differently than the CSO and CTO of an enterpriseMedia has a totally different view than the rest of the world pushing sensationalist headlines that really shapes how everyone is addressing the problem.Segmentation of population falls generally into two bucketsThe developersOperations people-different view points on what the problems are in mobile and what can be done to fix them
• #6: Securing the SDLC is the primary desire of the development side of the house. What can they do to increase the creation rate of secure code. For the longest time the only metric that mattered was, what can be done to increase the rate of creation of code. Bugs and security flaws didn’t matter. Only recently has the developer world really begun to embrace the creation of secure and low bug density code. Vulnerabilities is their primary priority when it comes to securing the development lifecycle. Identifying vulnerabilitieseducating the development team on what the vulnerabilities look like and how to fix themFixing the flawsAnd testing that their flaws were properly fixed.And the cycle continues. Developers traditionally haven’t cared as much about the capabilities of their code or the fact that malware may be embedded in their code.Reasoning: We wrote it. We know what it does and we know that it doesn’t have malware (not always true)Transition to BYOD…
• #7: In the Enterprise operations and IT world the priorities are reversed. They want to know first and formost that they don’t have any malware in the applications they are deploying to their user base.They then want to know what the applications are actually capable of doing on the device.And finally, does the application have any vulnerabilities that can be exploited on the device itself.These two types of views require two different types of execution if we are to help the Enterprise solve their mobile related problems
• #8: What makes up a risk rating? Risk is grey. It’s not binary, it’s not 0/1. It’s 1-1000000. It’s infinite shades of grey.Risk is made up of the security and privacy levels of application, and does that risk level fit within the acceptable threshhold that has been set by your enterprise risk policy.
• #9: We are at a mobile crossroads, an inflection pointJuniper Trust in Mobility Survey Results18% of people do not trust19% of surveyed people DO trust63% have no idea
• #11: Three distinct areas, mobile malware, application behaviors, and code vulnerabilitiesEach of these areas is a risk to the enterprise specific to the mobile spaceEach manifests itself in a slightly different attack model (yes we’ve seen each of these in the wild)Each results in a different method by which we must apply security controls
• #12: Mobile malware is shaping up to be the perfect storm.Describe perfect malware…DecentralizedInterconnectedMobileAbility to access targeted data quicklyDescribe mobile networks todayDecentralizedInterconnectedMobile – In every wayQuick content access and retrieval
• #13: Statistics, everyone has got them.What you see here are a bunch of statistics samples from different vendor researchNumbers are largely irrelevantWhat matters is the trending linesYou can dispute any individual group of statistics, but when every player in the ecosystem is claiming the same trends the data increases in value
• #14: Look into one specific set of trends.These results are from the McAffee annual report on threat predictions for 2012The trend is the same as every other report. Exponential growth.From July to November of 2011 there was significant uptick month over month demonstrating the typical exponential curveI’ve been predicting this type of uptick since end of 09 beginning of 10I was wrong. I was early. There was growth but nothing like we saw in 2011 and 2012I was also wrong in predicting where the out break would occur first. I saw the target as Blackberry (but we all know how that story went)It was Android…What I was RIGHT about was the distribution method for malware.. The public marketplace
• #15: So why was it Android and not Blackberry or some other player?Close technologyHarder to REStronger OS securityRealistically…Better app store securityNo fragmentation issue
• #16: North Carolina state did some significant research they called the mobile genome project.4 common types of infection vectorsRepackaging – 86% HugeDrive by – who caresStandalone – not really an issueUpdate – Coupled with exploitation based attacks and other repackaging for distributionDoesn’t total 100% because some samples contained multiple distribution and infection mechanismsSamples collected between August and October of 2011
• #17: What type of payloads were most common..Somewhat well distributed with the exception of remote controlEven spread between:Financial chargesInformation CollectionPriv EscalationRemote control was a larger number most likely because the attackers want to be an ongoing concernDon’t total 100% because some samples contained multiple distribution and infection mechanismsSamples collected between August and October of 2011
• #18: I ask developers all the time “Do you know what your code does”. Invariably the answer is “of course I do.. I wrote the code”. I then tell them they are wrong and listen to them fight with me for a few minutes.. And then I explain what I mean.Do you reuse or repurpose code – YESDo you use libraries that other people have written – YESDo you audit the source code of every library you use in your app? – NODo you use any third party binary only libraries – YESDo you reverse engineer and analyze the security of these libraries – NOThen you have no idea what your code really does.You are inheriting and accepting risk into your application every time that you use third party code or libraries
• #19: LinkedIn-Transmitted entire calendar entries-Included participant information-Times-Dialin numbers-NotesPath-Transmitted entire address book to the company-Did not disclosure this information to the userPandora-Transmitted GPS location-Phone identifying values (Android ID / iPhone identifiers)-Other sensitive data-Ad libraries-Likely third party library problem
• #20: -Sensitive Data Leakage-Unsafe Sensitive Data Storage-Unsafe Sensitive Data Transmission-Hardcoded passwords / keys
• #21: Layered APIs on common languagesBlackberry and Android use JavaNon-issue for Objective-C (it’s own language)
• #24: MDMGood -Strong policy and configuration mgmt-MAM support growingBAD-Security is secondary-MDM Differentiation is tough-Limited by API set provided by handset vendor-Expensive (40-60 per user per year)-MDM server security
• #25: Mobile AVGood-Catching the KNOWN malware-Awesome at killing battery lifeBAD-Inability to catch anything unknown (0day)-Same problem as traditional malware-Persistent resource issue (humans required)-Often highly priviledged apps running on the device(one bug to rule them all)
• #26: Good-Primary distributor of applications-Easy to locate desired applications-Trivial installation-Basic curating of applications occurs-Kill switchesBAD-Inadequate curating (incented by the app race)-Inconsistent application of checks-Speed of dissemination of applications
• #27: Good-Single source of applications (at the end of the day this is where all apps come from)-Generally not ill intentioned (but not always)BAD-Inadequate security education-Inadvertent code flaws-Intentional code flaws (backdoors)-Not incented to create secure code-Code reuse security paradigm
• #29: Capabilities mapping-Knowing what your application does.. EXACTLY what it doesMalware detection-Knowing if there is something hidden in your code (truly a subset of capabilities mapping)Vulnerability Analysis-Knowing if there are code flaws that can be exploited in your applications
• #30: Look at what the application DOES via static analysisLook for appropriate permissionsTrace sensitive data from sources to sinksCode flowData flowExecute dynamic runtime analysis as wellInform between the static and dynamic to create the most accurate capabilities picture
• #32: The traditional way is broken. Signatures don’t work. Easily evaded.When we put a new piece of malware into the hands of a malware analyst. What do they do with it?They do static analysisThey do runtime analysisThey add human intelligence to the system to determine what the application does and what the risk is of the programBest solution includes a machine learning system that determines what the application does and tries to understand how that maps to malicious intent
• #33: Application FlawsBad file permissionsUnprotected programmatic interfaces/APIsThe other usual suspectsSQLi, XSS, exfiltration, poor crypto, etc.Inherited risks via 3rd party libsEnvironmental FlawsRuntime and libraryidiosyncrasies or bugsPrivilege escalation vulns(OS or kernel)Other outdated, vulnerable components
• #34: Use all of the strategic control pointsNOT just oneImplement what each one is good atStrengthen each individually with good application security capabilities
• #35: PolicyOverarching security strategy drives…BYOD policy, access control, etc.I.R. plans should account for “computer-in-my-pocket”ProcessIdentifying/inventorying mobile devices, usage patterns, security modelsTechnical ControlsMDM and/or “enterprise-friendly” mobile AVDetection, lockdown, alerting, response optionsInternal analysis/testing lab? ($$$)Or just pay external firm to do it
• #36: “Mobile malware will continue to grow...”Especially on AndroidThe trajectory for mobile payment apps will eventually make them an enticing target, but not quite there yetThere’s yet an(other) opportunity to learn from previous failures, successes, and innovations in security, and apply them to the mobile spaceTake a holistic view of your ecosystemControl for problems at the choke pointsThis is going to be a journey… It won’t happen over nightIn the short term we have to add these new concepts and capabilities to our mobile environmentDesign your mobile security program keeping these concepts in mindIndividual point solutions will not work…Take a holistic approach