本节书摘来自华章出版社《黑客大曝光：移动应用安全揭秘及防护措施》一书中的第1章，第1.2节，作者 （美）Neil Bergman ，更多章节内容可以访问云栖社区“华章计算机”公众号查看
1.2 移动风险模型
好的，目前我们已经确定了：
移动应用规模巨大；
移动应用看起来非常不安全。
那我们现在应该怎么做？！
这里有一个可能会让我们感到震惊的答案：我们在之前做过同样的事情！与天花乱坠的广告宣传相反，我们认为移动“似曾相识”。从根本上来说，我们仍在讨论“客户端–服务器”架构：
好吧，我们可能有些但没有过多夸大。让我们通过更多的细节来做进一步的叙述或说明。思考一下，从客户端的角度来看，下图展现了我们将20世纪90年代和21世纪都使用的传统三级架构修改成移动架构的情况：
上图对不同之处进行了强调，数字部分对应的描述如下：
- 本地代码 本地应用的开发可使用不需要虚拟机或沙箱环境即可执行的编程语言。这些应用可能会涉及不安全的编程语言（例如：Objective-C），并且与基于浏览器的应用相比，增加了对其他应用和资源的访问。甚至当移动平台实现了应用沙箱时，用户也可能很快就被迫同意一个高而广的权限，这样平台所提供的大量控制机制很容易就被绕过了。
- 操作系统访问 浏览器中运行的软件只有有限的权限，可用于对底层的操作系统、库、文件系统的访问，或用于进程间通信和系统调用。
- 互联网访问 无论是家用个人计算机，还是便携式计算机，通常通过家庭网络访问互联网，而移动设备通常使用移动网络或者公共无线网络去连接互联网。这些访问方式能够为中间人攻击提供更多的机会。
正如你在本书中看到的，大部分由中间人攻击带来的手机应用威胁是在变化的，无论是我们提到的MiTB（浏览器）、MiTOS（操作系统），或者是老式的MiTM（网络）。从应用角度看，关于移动模型有一个公认的结果—它被恶意（至少不可信）软件所包围。
我们必须开始重新使用我们曾经学过的课程，去了解安全的分布式计算机系统。即使我们还不能够很好地真正实现它们（例如，对低级密码的持久而广泛的使用），但也不意味着我们应该不分精华糟粕全盘否定。当我们指出移动设备在架构方面存在不同时，我们也应该使用以前我们学过的安全架构。
这种方法可以称为坚持原则。原则是前人已经学习的东西，并且经过了实践检验，由于采用这些方法比其他方法好很多因此一直坚持到了今天。
我们最喜欢的原则之一是安全从理解风险模型开始。本书第8章会对移动威胁模型进行深入分析和拓展，本章仅对该内容做一个简短的介绍。
要理解风险模型首先要提出以下问题：谁是利益相关者？这是移动平台引入新观点的一个关键领域。大量利益相关者都在争夺对典型移动设备微小生存空间的控制，包括：
移动网络运营商（MNO、aka carrier、telcos和那些一直中断我们通话的#$%&*公司）；
设备制造商（aka OEM、硬件制造商等等）；
移动操作系统（OS）供应商，例如Apple和Google；
应用商店管理者（例如，Apple、Google、Amazon等等）；
IT组织（例如，关注安全的移动设备管理软件）；
移动应用开发者；
终端用户。
上面列表显示的是对个人用户设备感兴趣的各类利益相关者。对于iPhone，Apple承担了应用商店管理者、制造商和操作系统开发者3个角色。Android设备通常拥有更多的风险相关者。
当我们已经知道谁是利益相关者后，我们的下一个问题是，哪些因素对于这些利益相关者是有价值的呢？（我们称之为资产（assets））。有趣的是，每个利益相关者在移动设备资产中存在不同的价值。例如，操作系统制造商认为所有应用都是威胁。手机用户对操作系统来说同样也是威胁；用户在拿到手机后会尽快对手机进行越狱。然而对于手机用户来说，操作系统也可能是一种威胁，系统会为了“统计目的”而获取数据并输出，用户认为这是侵犯了他们的隐私。MNO预装的应用就可发现类似情况。
各种威胁通过攻击界面攻击每个利益相关者持有的资产。基于浏览器的互联网应用大部分将攻击界面局限于互联网连接点、服务器数据存储或者浏览器渲染和脚本引擎（还记得大部分移动开发框架定义了若干机制用于显示类似浏览器的网页视图，与本地应用相对无缝嵌入）。为移动设备创建的应用程序都共用这些攻击界面，但是新增了几个特别的，如下图所示：
上图包括了一些特别针对移动设备的攻击界面：
物理窃取允许对用户接口、物理存储、输入输出总线和音频进行访问。通过获得访问物理设备的机会形成威胁意味着移动设备与其他客户端有着非常大的区别。
应用程序发布引入了一种威胁，在该机制下允许集中散播带有特洛伊木马的应用程序或者其他恶意软件，这些软件外表看起来一切正常，而且由移动应用商店授权发布。就如我们已经提及的，带有威胁的应用应该已经弱化了对操作系统资源的访问、进程间通信，在无沙箱的运行环境下攻击它的目标对象，不过这取决于移动平台的状态（已经越狱/获得root权限）、应用权限配置存在缺陷和终端用户的超权限设置等等。
在得到了可能的攻击面之后，我们如果要完成风险模型，就会问第三个基本问题：从利益相关者的角度来看，与资产相关的威胁有哪些？只有解决了这些基础问题条件,你才能完善你的设计和开发,从而降低这些风险。
对于这个过程，可能会有不一样的名称：风险建模、设计审查、架构风险分析、威胁建模。在这里，我们不需要对专业名词吹毛求疵，而仅仅是研究风险在安全会话中的基本角色。
一旦你确定了风险模型，就能基于它进行更加合理的设计和完善后续工作。（例如，使用代码审查和渗透测试等方法对开发进行检查）。你还需要从这个过程中不断学习并确保受过培训的人员不再发生同样的错误。在相同点的典型过程方面，这开始有点像“安全开发生命周期”，如图1-2所示。
由于风险模型是最重要的，因此，让我们对移动风险环境进行一个高层次的概述。通常，关于移动风险模型我们需要关注哪些因素呢?
尽管我们认为事物没有发生本质的改变，但其实在移动平台上有些方面还是不同的。很明显，由于混杂的通信方式（广域域和内部）、物理访问，外加常规软件攻击和邮件、移动网页应用程序等外联因素，客户端的威胁模型会更具有攻击性。
折中的结果就是更加“人性化”：位置、照相机/照片、即时信息—有大量让人不安的公用数据需要去核实。Weiner一定会有一个更不幸的姓吗？以及有了好几个不行的姓名？（不好意思，我们不能够接受）。
拥有宇宙间无穷的力量……但却挤在小小的灯里。
但是再一次重申，这并不意味着移动安全工作在本质上与众不同，只是表明你必须了解风险模型的改变，同时能够将这些变化明确告知所有利益相关者，并掌握实际的缓解措施。相同的工作，在不同的时间里会产生不一样的好坏利弊。我们对移动威胁模型已经有了一个比较高度的概括，现在让我们对一些具体的不同点进行深入的讲解。
图1-3表示的是我们理想化的移动应用生态系统。当然，任何“实际的”风险模型都需要根据所给的场景进行定制，这只是一个重点关注我们在调查和研究中已发现事物的通用模型。接下来我们更加详细地讨论风险区域。
1.2.1 物理风险
图1-3中的风险区域1说明了一个真理，这是通过我们在这个产业持续不断的反复学习得到的：设备的物理访问很难做长时间的防御。大范围的root权限获取和越狱现象无疑证明了这点。因为这种方式非常难实现或者说基本不可能，即使是Google和Apple（两个非常成功的公司）也未能做到。在我们的调查和研究中，我们一直在找一个我们不能阻止其已有物理访问的应用程序，包括很多基础的反越狱机制，甚至还包括了移动设备管理（MDM）软件。如果你的移动风险模型假设信息在移动设备上可以绝对安全的储存，那么你可能开始于一个错误的假设，当遇到一个例外，你需要重新学习这个痛苦的课程。整本书都基于这个基本的假设，物理损害是一个高成功率的结果，你在每个章节都能看到它不可改变的事实。
我们所举的这些例子是显而易见的：计算机安全准则第3条指出“如果一个坏人可以对你的计算机进行没有受限的物理访问，那么它也不再是你的计算机了，”technet.microsoft.com/en-us/library/cc722487.aspx。
再回到图1-3，以将电线连接到手机底部为代表的物理攻击方式，即本书中我们常常会谈到的典型“调试”连接，再次说明了对设备及设备上软件的直接访问对设备拥有者和设备上存储的敏感数据来说，通常意味着“游戏结束”。
这个规则一个经常被忽略的推论是，与移动设备近距离的交互和物理攻击是同等有效的。换句话说，如果攻击者使用一个伪基站并保持与你足够接近时，你的手机就会加入这个伪基站覆盖的移动网络，同时攻击者就从较低的层（基本上是完全）掌握了你的设备。这样整体上你什么也不能做，只能把你的设备设置为飞行模式，将它作为一个昂贵的、无法连接的板砖来使用。在图1-3中，我们将这种危险作为#4，紧邻“基带”无线电芯片硬件和固件，将所有从移动网络的连接转到WiFi、蓝牙、GPS、近距离通信（NFC）等等。我们会在第2章中进一步讨论伪基站（rogue cellular base station）攻击。
1.2.2 服务风险
让我们看一下图1-3中的风险区域2，下一个移动生态系统里主要的风险产生区域是哪儿呢？不会在你想到的地方……
通常，绝大部分关于移动平台的焦点会集中在移动设备以及与之相关的客户端软件。与这种关注相反，事实上我们在调查和研究过程中注意到更多的问题发生在服务器端。例如，在最近一项长期的调研合作项目中，我们得到了这样一个结果：65%的服务端bug对25%的客户端bug。
当然，大部分代码/逻辑也是在服务器端，所以这是不希望发生的。同样，如果你已经正确做了设计，那么那里也是有价值的数据存储的位置。只针对“钱所在的位置”进行攻击的攻击者威利•萨顿（Willie Sutton），是一个臭名昭著的银行抢劫犯，在被问及为什么要抢劫银行时，他说 “因为那里有钱”。我们在图1-3中的#8中，突出强调了通用服务器端风险。
另外通常被忽略的现代网络应用中的一个因素是客户支持。这种疏忽是不幸的，因为一个现代的威利•萨顿可能会为了复仇而利用这点：通过设计，支持帮助人们重新获得对有价值数据的访问权限—一个黑客的梦想就此实现！从近20年来大多数灾难性漏洞的经验中我们看到，一些问题是由例如自助密码重设等客户服务相关的功能所导致的；如果你在这里犯了错误，那么将会产生巨大的影响。设想这样一个缺陷：允许匿名攻击者通过网站重设账户密码—能想到后果吗？在之前提到的调研项目中，大概有12%的bug是与客户服务相关的。然而，这些都有可能导致最高级的风险，这与我们刚才谈到的用户密码重置漏洞类似。我们在图1-3中#9标注了此类风险，紧挨着微笑客服，甚至是非常有帮助的客户服务代理商。
举一个内部关系出错的真实案例，参考有线记者Mat Honande的噩梦经历，这段经历是关于黑客如何利用社会工程学从存在缺陷的客服功能中侵入他的Gmail账户，并以亚马逊数据为中心，远程删除了他的iPhone、iPad和MacBook上的所有数据，同时受牵连的还有他的Twitter账户。（wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/。）
这是一个反复发生而且很重要的问题，我们正在逐步走出来：另外一个可怕的客户服务漏洞的真实案例，可参考《Verge》(theverge.com) 2013年3月刊，关于AppleiForgot自助密码重设工具严重漏洞的报道，这个漏洞允许任何人通过你的邮件地址和出生日期来重置密码。哎！
如果服务端有银质内里，那么性能好的ol安全网关仍然能够在保护面向互联网的服务方面有良好的表现。实际上，我们已经看到了Vordel应用网关（vordel.com）有效地保护了移动终端XML服务，使其免受熟练的渗透测试者的攻击。你完全可以考虑采用如Vordel这类的产品，并将其作为你移动应用安全架构的一部分。
1.2.3 应用程序风险
我们来到了在我们的移动风险区域里最后但并非最不重要的部分，真正的接口——移动应用程序。
应用程序（符合平台特征的接口）是移动客户端上的最主要的攻击面。毕竟，应用程序和移动操作系统是终端用户和其他软件的基本接触点，所以这也是所有问题发生的地方。
以应用程序为中心的当今移动风险模型，在某些方面反射出其他平台的安全演变，如桌面计算机：早期的攻击集中在网络层，然后转移到操作系统（特别是最流行的操作系统，例如，Microsoft Windows）。最近，我们看到了大量已经公开的针对桌面应用程序的攻击和利用，如网页浏览器、Adobe Acrobat和Microsof Office。在这种演变的顶端，我们看到了针对“第8层”的攻击，换句话说，攻击是针对使用这项技术的人。如网络欺诈等社会驱动攻击就代表了这种趋势。
在移动平台，相对缺少公开的底层利用方式，表明供应商正在重新使用我们已经了解的网络和操作系统安全。然而，甚至在移动平台上，第7、8层问题一直很难解决。也许特别是在移动平台上，用户和应用之间被赋予了比桌面计算机平台上更加紧密的关系。经常在线的网络连接会产生一个明显的结果，任何人可与你的手机进行连接。这通常不是一个可取的事情，对“任何人”的一种可行的定义会包括图1-4中的角色。
事实上，很多人会不断地连接你的移动手机，即使他们已经通知你了也很难判断哪一个是友好的。你应该允许谷歌地图获取你的位置信息吗？当你在约会日历中点击相关链接时，你会允许思科WebEx移动应用程序自动加载吗？当AT&T告诉你手机账单已经准备好了，你会点击SMS里的链接吗？
你可能希望能够有一个直接解决所有问题的解决方案，从而带来安全的移动体验。这几乎不可能，因为移动的发展速度如此之快，同时面临如此众多的危险问题（见本章开头的数据），在行业中没人真正能有足够的时间一一去完成。让我们来浏览一些典型的移动应用程序的安全问题。
- 分化
我们多年来学到的一个安全原则是，为存在漏洞的系统快速打上补丁，这样做通常能够降低风险。这种风险来自于在互联网上传播的本地恶意软件，这类恶意软件往往能够利用未打补丁的知名漏洞。不幸的是，为你的移动软件打补丁是极具挑战的，源于当前市场的一个关键特点：分化（fragmentation）。
分化源于一个技术行业的古老争议：平台的开放与封闭，见图1-5。在移动设备领域，我们将看到这一幕会在当今两个最大的竞争对手：谷歌和苹果之间上演。
在本书写作的同时，甚至著名的手机黑客查理•米勒都认为苹果iOS系统更难被侵入，主要是由于该平台严格的控制机制：代码必须获得Apple的签名后才可运行，地址空间随机化（ASLR）、更好的代码沙箱、没有shell等。与之相对应，在Android平台上，由每一个设备制造商开发各自特有的操作系统需求带来的分化，直接导致了安全方面一系列的负面结果。例如，Android系统升级到最新版本依赖于设备的硬件厂商和移动网络运营商（MNO）之间的合作，这就限制了如ASLR等新安全功能，也使得分布式安全补丁和其他重要的更新变得难以实现。
“封闭”的Apple平台在智能手机的市场份额在早期一直处于领先。通过这样一个被认为是副作用的设计，Apple设备的安全成绩一直保持良好。相反，开放的Android平台的安全成绩是不理想的，但是它迅速成为市场份额的领导者可能因为它在数字上的优势：谷歌，摩托罗拉，三星，HTC，LG等等众多厂商对唯一的苹果。
我们之前看到过这一幕。尽管遭受了不良的安全信誉问题，但是微软通过将自己的操作系统授权给多个硬件厂商从而成为个人电脑市场的主宰者。尽管有高品质的集成硬件和软件设计声誉, 苹果最终被边缘化。
我们重新理性地看一下市场，今天的消费者更倾向于接收边缘化特征的事物，安全性的考虑则放在之后。事实上，许多Android和Apple的用户破解/越狱他们的手机是市场中的一个不成熟的例子。微软只是用了10年之久的努力就使得个人电脑用户不用高权限的管理员用户登录。许多因素都在变化，但是对比是有趣的（我们当然不是第一个做这个对比的）。随着市场逐渐成熟，最终的赢家会是具有更高质量、更多控制和安全经历的那个吗？
有一件事跟过去有所不同：应用程序的市场，比如Apple App商店和Google Play。这些集中的应用程序交付机制，又一次不是出于安全而是出于控制用户体验，用简单的分布式模型吸引开发者，并且让软件下载到设备上。但是不管动机是什么，结果都是：有一个中央应用补丁渠道，通过此渠道开发人员可以很容易地定期更新他们的代码，包括安全补丁。PC甚至都没有取得这类第三方软件的集中目录。
当然这样一个渠道仍然不能保证补丁能被制定出来。正如前面提到的，开发者获取安全漏洞信息仍然需要规则约束（微软的Windows系统的错误报告，又名“沃森博士（Dr.Watson）”，是一个很好的例子），制定好安全补丁并且可以使用它们。
还有其他的渠道颠覆了标准的应用程序市场。最受欢迎的当然是用手机设备的网页浏览器直接下载并且安装程序，就是所谓的“旁加载（side-loading）”。也有能够与标准的应用程序商店同时安装的第三方的应用程序商店。
当今分化的手机软件市场和过去微软与苹果之间竞争的另一个不同之处是，大量的手机设备制造厂现在仍然处于主导地位，多种的Android个性化定制就是结果。这种多样化能将安全漏洞引入具体设备上，而不能被谷歌集中确定。比如，三星的TouchWiz的Android界面容易被恶意网页的一行简单代码攻击，从而可以消除在Galaxy系列手机上的用户交互信息（查看androidcentral.com/maior-security-vulnerability-samsung-phones-could-trigger-factory-reset-web-browser）。用户不得不等待三星发布新的固件，而且许多更老的设备可能仍然易被攻击。
- 敏感信息泄露
敏感数据泄露是移动设备最大的风险之一，因为在移动设备上所有的数据本来就存在更大的危险。不幸的是，在移动设备上设计了许多机制用于存储各类数据。在我们的工作中，看到了如下的数据：
调试模式下Google系统日志中的鉴权PIN码；
Web View中缓存的会话标识符和身份凭证；
本地数据库SQLite中存储的敏感数据；
当应用程序中断时，带有敏感数据的iOS应用快照记录；
敏感凭据如应用PIN码被记录到iOS键盘缓存
有一个公布了的例子：美国国土安全部旗下的电脑警备小组（US-CERT）的攻击记录中，VU#251635“三星和HTC安卓手机信息泄露的漏洞”描述了如何确定三星和HTC安卓手机在设备驱动程序日志（所谓的dmeg缓冲）中存储某些能够被恶意程序访问的用户输入信息。某些制造商在ROM中配置错误的UNIX文件权限，使得dmeg可以执行手机设备上的任何应用程序。
而且，记住应用程序沙箱（又名重新授权许可）的可传递属性，当一个应用获得许可进行应用程序没有权限执行的特权任务时，这个属性就会出现。比如，如果善意的应用程序X有权读取安卓系统日志，恶意的应用程序Y可能请求X代表它来调用日志API（无用户参与），这样可能会看到一些X程序开发者不期望看到的东西。2011年底的Carrier IQ-HTC监控软件按键记录事件是一个很好的例子，该事件发展到白热化程度，以至于美国参议院也被卷入进去。这是一个有趣的话题，值得从以下几个角度进行思考：
Trevor Eckhart，安卓系统安全研究者，最早研究这个话题，把Carrier IQ监控软件称为恶意软件（androidsecuritytest.com/features/logs-and-services/loggers/carrieriq/）。
安全调查员Dan Rosenberg在他个人博客上发表的一些相关主张“Carrier IQ监控软件：一个真实的故事”（vulnfactory.org/blog/2011/12/05/carrieriq-the-real-story/）。
一个关于Carrier IQ监控软件的详细报告，基于Trevo和Dan的研究，介绍了这个软件是如何设计的并且被网络使用者利用的（carrieriq.com/company/PR.20111212.pdf）。
把最初的宣传鼓动放一边，Carrier IQ监控软件事件表明复杂的生态系统如移动创建内置障碍物，以快速解决全球数以百万计的部署设备发现的问题。最终，我们不确定是否有人能够真正学到一些有用的东西，但是关于Carrier IQ监控软件可能在未来被滥用的舆论仍然继续，即使这不是它们本身的过错。
在监控软件事件发生后的一些时间里发生了其他类似事件，美国联邦贸易委员会提出一个对HTC的指控，关于它的安全业务，特别是引用在其他事情上“重新授权许可”的问题。
这导致了我们经常见到的另外一个同样很典型的问题：应用输入验证。如果一个应用程序不能小心地处理输入，那么它可能被利用来攻击其他应用程序。我们在这本书的许多章节中列出了基于这种缺陷的很多攻击，包括：典型的JavaScrip teval函数滥用，通过JavaScript bridge不恰当执行本地代码，发送恶意制作的JavaScript可执行代码，使用URL查询字符串来执行应用程序功能。
- 设备上的安全存储
继续我们的关键移动应用风险列表，正如我们已经多次提到的，认为秘密可以安全地存储在手机软件中是错误。我们可以把从硬编码密码到AES密钥的一切从移动设备上移除。这并不是指“不要这样做”，但是你不得不把数据的价值与风险画上等号。在设备上这种风险是很高的，因为（我们现在都认同）攻击者物理访问=高可能性=游戏结束。
当然，一些应用程序需要在设备上存储高价值的数据。比如，移动支付应用需要一些方式来存储支付手段，以确保像“点击购买”这样的场景。我们为移动应用程序开发者提供几个关键的建议。
不要这么做。如果不需要在设备上储存敏感数据，那么你的应用程序在设计上就更加安全。让应用正确执行将会花费大量智慧和努力（见下面两条建议）。这样，你可能会超出原有预算。
使用已有的安全存储设备;不要让自己失控。举个例子，Apple的iOS KeyChain在平台中用来安全地存储敏感用户数据，甚至当攻击者对设备进行物理访问时，也能够保护敏感用户数据。尽管不是完美的，通过使用iOS5及其以后版本，并通过几个最佳实践（主要是设置一个6位字母数字锁屏密码），KeyChain就会比传统的开发者自己编写安全例程提供更多的保护。参见sit4.me/ios-keychain-faq，可以获取iOS KeyChain在健壮性和脆弱性上面更多的细节。
使用特殊设计的硬件区储存秘密数据。安全元件（SE）是一种可以集成在设备硬件上或者SIM、SD卡中的防篡改芯片（微控制器）中。由于在移动消费市场里激烈的竞争，SE的可用性不断增加，主要集中在谷歌钱包（Sprint手机上）和Isis移动钱包应用（由Verizon、AT&T和T-Mobile合作开发）。芯片之间的通信基于已有的智能卡标准，例如，ISO7816（接触）和ISO14443（非接触）。如果实现正确，就很难被攻击。“正确”意味着不会将秘密数据暴露给错误的接口。这里没有普通的场景给开发者去进行编码，我们也发现了几个存在错误的情况，允许我们不正确地访问SE上的数据。我们甚至通过使用接收设备上的应用程序（不良的完整性检查），移除了设备和被访问数据之间的安全元件；在已root的手机上通过恶意应用程序直接访问安全元件。
- 脆弱的认证
脆弱的认证通常来讲是一个典型的应用安全问题，在移动平台上这种情况不会更好。特别是，我们发现一个趋势，假设移动设备上的序列号是“秘密的”。例如，移动设备序列号（MDN）。我们曾经见过密码重置服务中只要求MDN用于重置账户密码（不包括由其他重置操作要求的安全问题）。多少人知道你的MDN呢？多少应用程序可以通过手机上的许可访问MDN呢？
第6章将会对使用流行标准（如OAuth和SAML）的移动设备身份认证进行更多详细的描述，包括已知攻击和对策。
- 未正确实现导致的失效
我们同样也看到了大量的问题，如果规范能够被正确实现，这些问题就能够避免。举个例子，WS-Security头中使用了明文的用户名/密码，而不是散列值。举另外一个简单（非常不幸，很常见）的例子，调试模式在产品中未被重置，这将导致如SSL/TLS验证失效等严重事件的发生，这对位于本地星巴克或类似地点的移动设备来说非常严重，其非常容易遭受中间人攻击。 - 更优秀开发者=更安全的代码
你不能忽视一个事实，优秀的开发者能编写更好的代码，也就是更安全的代码。这与我们经常看到的在移动开发过程中典型地追求速度是不同的。另外，我们看到在移动领域存在很多外包开发。甚至具有大型应用开发团队的公司也不能足够快速地应付移动开发以适应高速发展的商业创新，因此通常的措施是外包给某家专注于手机领域的第三方app开发商。要做好心理准备，花费更多的时间在移动项目上，因为这时你需要更加警惕。 - BYOD、MDM、老虎和熊！
自带设备（bring your own device，BYOD）现象得到了许多关注，但是在IT开发中对终端用户的易用性方面，我们没有看到有任何新的东西。我们在PC革命中“幸免于难”，因此看到只具有非常差的安全防护的终端用户设备上的数据和应用程序时，就感到非常烦心。但是，可以考虑将BYOD作为能够抓住数据治理的又一个机会，由于可能转向恶意的环境，因此移动设备上的敏感数据会带来巨大的风险，这应该可以让管理层暂停下来进一步进行思考。你有选择的机会：对高安全性数据仅使用在线/虚拟机方式，或者在整个客户端一侧，对所有非敏感因素进行旁路控制。让投资人做选择，并让他们负起责任。
移动设备管理（MDM）经常被认为是一个解决移动安全问题的权宜之策。在只针对paper-cut-class漏洞的多数情况下它确实是一个权宜性质的工作。在对一个主要的MDM运营商进行测试时，将一个调试器附加在手机上就可使我们绕开屏幕锁。我们再一次提到，防止物理攻击是非常困难的，你不应该期望MDM去解决这个问题，它只能缓解一些征兆。我们不是说不使用它，而是确保能够仔细评估这个解决方案并与你的组织实际的威胁模型相匹配。
但是也不要低估它们。MDM及相关技术如移动应用管理（MAM）和应用程序完整性保护（例如，反调试和混淆）一旦能够被合理地设计和部署，将对整个移动安全形势作出很大贡献。我们将在第7章进一步介绍相关领域的潜能和缺陷。
