Security Policy, Root and Custom ROMs Balancing Do’s and Don’ts

Security Policy, Root and Custom ROMs Balancing Do’s and Don’ts

We love our mobile devices – and for many of us here on XDA, we often face a struggle when we want to take that love for our devices and start applying that at the office.

For those of us that run our own business and understand those risks, we may have an easier case than the rest of us who must follow corporate policy. The challenge is that, for better or worse, things are getting more secure out of necessity. Larger corporations are chasing certifications such as ISO 27001 to help assure customers that their data is secure. The small-to-medium business (SMB) segment is reaching a point where modernizing means embracing mobile technology; this means they will have to address the risks of that as well.  So how can we find a happy balance between that need for a company to control the information that is shared with mobile devices with one flexible enough for us to take advantage of some of the great things we do here at XDA?


It’s important to note at the onset of this discussion that sometimes it’s just not possible to marry the two, and that some folks will have no choice but to carry a second, truly personal, device if they want do go beyond the restrictions of a corporate device. For example, those that follow the United States standards for device security – which many large corporations and governments may also be required to follow – will need to understand that they are there to protect far more than the data going out to your device but also what can get sent back in. The risk of losing sensitive information in cases such as health care is so serious that the U.S. government offers advice on how to approach this and may be further restricted by state or local laws. But that doesn’t mean that even some of the largest corporations in the world will force you into a “one-size-fits-all” approach.

Intel's Tiered Security Approach (2012 Case Study)

Intel’s Tiered Security Approach (2012 Case Study)

While attending an Intel conference in 2014, one of the speakers there covered Intel’s approach to device management and the Bring-Your-Own-Device (BYOD) trend.  What may surprise some readers is that that they not only welcomed but embraced this approach years ago. Instead of using one solution for all devices Intel uses a tiered approach to their information security that hasn’t changed much from its published case study in 2012. As the image on the right shows, the more risk associated with the data being accessed or needing to interface with results in increased security and management by the company.

As the speaker clarified after the session, this may be as simple as restricting users to public information or login-based systems. Others may require registration of the device’s MAC address in order to access data so that it is clear who has the access – necessary when trying to retain accountability. Finally, those that want or need full access will have to either segregate their personal device or accept the restrictions of an MDM solution provided by Intel. The good news about this sort of approach is that it doesn’t outright deny the ability to root or run custom software on the device.  The speaker, an Intel employee, clarified that certainly at the lower levels this might be possible – where on higher levels they would require the containerized solutions (such as Samsung’s KNOX) to remain intact.

To a large extent, it’s helped me form a base model for BYOD and non-corporate devices at my day job as well. I generally restrict non-company devices to a low-bandwidth public wifi access point, but even then this is for guests only. Company devices, which currently do not directly interface with our operations system, are granted access to our e-mail. But as we approach a point where tablets will be distributed to employees and will exchange data with our operations systems – even if indirectly – these devices will become subject to Mobile Device Management. And there’s room for adjusting that in most of the major MDM solutions: When testing Airwatch for my previous employer, we were able to enroll a device, watch it drop off the moment it detected root access or the Knox flag triggered, or assign it to a group which allowed this access but then restricted what data and systems the device could access within the company infrastructure. Going through all the options allows me – or other IT administrators – to block those things that we don’t need in our environment (sorry, employees – no YouTube) while ensuring we retain the functions that are necessary to complete the job.

What about for people that are curious about what to do in their own workplace? Don’t worry – you’re not alone. Whether you’re a one man IT department for your company, a owner trying to navigate your way through this, an employee trying to figure out what can and cannot be done or a vendor that needs to understand what restrictions may be in place – a great deal of us outside of the enterprise environment are facing this now for the first time. With that in mind, we here at XDA offer a few “Do’s and Don’ts” for both Businesses and Users looking to help find that balance.


  • DO understand the risks. Even something as simple as allowing people access to e-mail or wi-fi networks can expose a risk to the company. At the same time do you want devices – even TVs now that come with Android installed – to have unfettered access to things that you would rather they don’t?
  • DO make a plan on how to mitigate those risks. Don’t be afraid to call in a security expert to help you assess those risks, especially before undertaking a massive change in the way mobile devices will be handled in the workplace. It may not be MDM but a policy that employees have to sign – but doing nothing makes your environment the equivalent of the “Wild West.”
  • DO communicate this plan with your users. The more you make it clear what employees/guests can and cannot do, the easier it should be to not only adhere to the plan but also enforce it if necessary.
  • DO regularly review the plan to make sure that it still fits the needs of the business. More importantly, take action and adjust the plan if necessary.
  • DON’T ignore the need to address this. With the myriad of security issues present and only growing daily, the proverbial head-in-the-sand approach will only delay the pain, not avoid it.
  • DON’T go with a model or security plan that you haven’t invested the time to research. One of the biggest reasons that a security plan fails is because it hasn’t been designed based on your company’s needs but rather on what someone else suggested.

Users of a Business – Employees, Vendors, Guests:

  • DO respect the need for a company to have security in place, especially with mobile devices. The policy could be as simple as not even allowing devices on company premises, but in the end it’s their business, and how to properly secure that is their choice.
  • DO ask, especially if you don’t know, what your options are for BYOD or accessing company data on a mobile device. It could be they may have something in the works and haven’t announced it yet. I have yet to know a single employer to discipline an employee, vendor or guest for asking what they can do before actually doing something in this realm.
  • DO offer suggestions or feedback to your company if you feel the current security plan doesn’t serve your needs. Many companies offer a feedback or improvement policy to help exactly with things like this. But make sure when you explain this, explain why and how it needs to be changed. Details matter a lot here.
  • DON’T do whatever you want or try to circumvent the policy… unless it is your job to do so. Most companies place this under such a level of severity that even unintentional breaches of security policy can lead to disciplinary action, termination or worse.

Are you a business owner or user that’s faced this situation? Facing this situation now but unsure how to proceed? Feel free to add your thoughts in the comments below and let’s continue the discussion!

About author

Daniel Moran
Daniel Moran

Former PC Hardware Editor for XDA.

We are reader supported. External links may earn us a commission.