Bring Your Own What?
A five step process to control Portable Device Risk!
Right off the bat, let me acknowledge that yes, I’m using the term “portable device” instead of “mobile device.” I have reasons. But hey, I still referenced the BYOD buzzword in my title . . . did it catch your attention? That’s because when we see that buzzword, it makes us feel like partying!
Unfortunately, the risk exposure created by portable devices is no party. Some of us have already let the cat out of the bag. That fact, coupled with the intrusive nature of the necessary controls, requires an expenditure of what little political capital ISO’s have left. Let’s face it: the compliance burden saddling our management teams has intensified in the last two years, and they simply want to use their mobile phones to ease that burden. That we information security people add more “yes, but’s” to the picture can be irritating.
Still, the risk is there. We can’t escape the two differences between portable devices and all the other systems we’ve been protecting: 1) they are portable, and 2) they connect to many different wireless networks. They can be lost, and man-in-the-middle attacks are more likely. Thus, if we’re going to issue bank-owned devices to our management team, and especially if we’re going to let them “Bring Your Own Device” (BYOD), we need to control that risk.
Let’s start by summarizing the top half-dozen vulnerabilities that lead to that risk, and their corresponding controls:
- Lost or Stolen Devices: The best way to control this is by requiring screen lock on the device and implementing an ability to remotely wipe the device. Both are easy to do, even if you can’t afford to invest in “Mobile Device Management” applications (MDM.) If you use Microsoft Exchange, you can use Exchange ActiveSync (EAS) to require screen lock and implement remote wipe. However, don’t do this without adequate awareness training. It will only work if your team members know to report the lost device, and they’ll want to know in advance that they could lose their pictures, apps, and music!
- Vulnerable Apps: People fall in love with their smart phones because they can choose from hundreds of thousands of apps and quickly and easily install them on their phones from anywhere at anytime. And it would be political suicide to prevent smart phone users from installing those apps. But these apps can have the same vulnerabilities (and more) as the application vulnerabilities we have been fighting in the non-portable world. The best control for this is application whitelisting, where somebody with experience chooses which apps can and can not be installed on the device. This control, however, doesn’t come free with Exchange ActiveSync (EAS), and thus many smaller banks are relying upon awareness training until Mobile Device Management (MDM) reaches the late majority (and thus lower cost) phase of adoption. Meanwhile, as always, one important control is to keep portable operating systems and apps updated and, unlike our internal network, where we have our vaunted patch management systems, we have to rely upon awareness training to remind our employees to install those updates. MDM applications will do that for us, if we can afford the investment at this time.
- Fraudulent Apps: Especially in the non-Apple world (but don’t buy into the myth that Apple is free of malware risk), the bad guys are reverse engineering good apps (like Angry Birds) and using that to insert Trojans that can do things like forward text messages (and thus compromise many new two-factor authentication systems), monitor use of sensitive systems (and thus learn how to log into mobile banking sites), and even take pictures of you and your work area (and thus . . . . ??). The controls? Again, application whitelisting is the most graceful, but since EAS does not offer this, awareness training will have to suffice for those awaiting the lower price of MDM.
- Malware: The same issues exist that have always existed, and we are even starting to see malware in the Apple marketplace, though I agree that Apple does a better job of controlling their apps. But Zeus has given birth to Zitmo (Zeus in the Mobile), and the attacks are directed squarely at American banks. Just like vulnerable and fraudulent apps, the attacks are orchestrated and meant to steal credentials and authorization numbers. The controls are malware on non-Apple devices, and awareness training to make sure everybody knows what the malware will look and act like, and to use anti-malware.
- Smishing: If you think phishing has a high likelihood, smishing (like phishing using SMS, or text messaging, as the medium) is even more likely. I’ve already had a client experience a smishing attack, and it wasn’t pretty. The bad guys texted a message to everybody in the area that appeared to come from the bank. The text message said, “your account has been locked. To unlock it call (901) xxx-yyyy.” When you called that number, an automated attendent asked for online banking usernames and passwords. Unlike phishing, where law enforcement has developed a decent level of cooperation to assist in bringing the phish site down, smishing requires us to work with the good old phone company. Beware the 901 area code! Awareness training is the most important control.
- Man-in-the-Middle Attacks: Traffic sniffing has always been a vulnerability, but since our portable devices can connect to the wild wild west using Bluetooth, Cellular, 3 and 4G, WiFi, and other wireless capabilities, the likelihood of this attack vector on portable devices is much higher. This is especially true because in almost every case, the network is configured by novices. The control: teach your team how to configure their home wireless access point to NOT broadcast the SSID, to use WPA2 encryption, and to leverage MAC Filtering.
Notice that awareness training was listed as a control in all six of the above vulnerabilities. It is the most important control, especially in the quickly evolving mobile technologies. Usually, you can fish for your users, or you can teach them to fish. In this case, I’d suggest you have no choice.
Having run through the top six vulnerabilities GENERICALLY, I am now ready to go over my five point plan for mitigating portable device risk.
- Conduct a risk assessment. There’s a reason I capitalized “generically” in the last sentence above. My top six vulnerabilities do not necessarily mean they are your top six vulnerabilities. You need to roll up your sleeves and focus in on a drill-down risk assessment this time. The process, especially if multi-disciplinary, will lower the political capital costs, and will allow you to prioritize controls. Of course, a good risk assessment always starts with a solid asset inventory, and in the case of Portable Devices, we believe you should include both issued (bank-owned) and authorized (employ owned . . . .BYOD) devices. It’s why we use Portable Device instead of Mobile Device in our template titles . . . . we want to exude we’re talking about all devices that can leave the bank and connect wirelessly, not just smart phones and iPads. Our risk assessment templates list as many as 29 vulnerabilities for smart phones, and we break the assets into wireless access points, tablet pc’s, smart phones, and laptops.
- Develop the non-technical policies. This is where you really need to leverage the FFIEC’s requirement that risk measurement be a multi-disciplinary approach. It’s already going to be hard enough to ask your management team members, when the cat is already out of the bag, to restrict the applications or amount of email they store on their phones. If you involve them in the risk assessment, they will already know why when you show them what. The policy should achieve the following objectives:
- Define what you mean by portable device, including both issued and authorized devices.
- Define who gets to have issued devices and who gets to have authorized devices. Some of our clients are doing this in their employee handbook and then referring out to the IT Governance Program for those lucky ones getting issued or authorized priviledges.
- Define the non-technical controls which are required in order to maintain the priviledge of having an issue or authorized device.
- Establish an agreement between the bank and the employee which codifies the employee’s contractual obligation to enforce the non-technical controls, and which gives the bank the right and responsibility to audit portable devices (whether issued or authorized.)
- Develop the technical configuration standards. Our templates scale from Exchange ActiveSync to more robust Mobile Device Management tools. Beyond guidelines for the configuration of your MDM approach, your configuration standards should also establish who does the auditing, how the auditing is done, the importance of the auditing, and how often the auditing is done.
- Conduct an Awareness Training meeting for all employees issued and/or authorized. The training should have three components: The risks, the controls, and the agreement.
- Audit the devices. You should audit every device annually, and randomly audit at least 25% of authorized devices. Our mobile devices security kit includes an audit checklist for wireless access points, smart phones, tablet pc’s, and laptops.
Like anything else, portable device security requires layers of security and not silver-bullet controls. But the above fix step process should put you in a position where you are adequately managing portable device risk.
So in five simple steps . . . . okay, they’re not really simple . . . . but in five steps you can substantially mitigate the risk exposure of BYOD and other portable devices. If you need starting points, you might consider checking our our Mobile Devices Security Kit or, better yet, come to our workshop on March 27th!
2 Responses to “Bring Your Own What?”
In this short video, Mike, our “Envoy from the SIEM”, walks us through how data flows
Dan’s reflection on the past 20 years. A Dan’s New Leaf post about predictions. If yo
Welcome Webinar Attendees! You can download a zip folder with all three of the delive
Another awareness poster for YOUR customers (and users). Now that we have our own em