1

We are currently working on a project to develop an "offline" mobile application that synchronises data with our current cloud software solution that would allow field workers in potential mobile black spots to still be able to carry out their work without a signal.

This would require (depending on the client size) up to 10GB of data to be downloaded to the device. Some of the data is of restricted classification (PII) and is just a defined read-only dataset specifically required for the role of the identity who downloaded them (not an entire db dump).

We defined a security policy that only one identity could be provided to the mobile phone app at any point in time (to protect the security of the data on the device). Although the burden would belong to the organisation on how they used it. This current policy defined proper rules such as device data encryption, and the correct AAA procedures.

With agreeable reason, customers have told us its not a valid to restrict the device to one user. As user A might work Monday, Tuesday but user B may work in the same role Wednesday, Thursday. Why should they fork the cost of multiple devices just to meet our policy.

My solution, is the downloadable device data must in entire belong to a defined set of roles which would be standard practice anyway. If the user must have those roles to be able to download the data, then a secondary identity must also have that role if the data has been downloaded (even if the user does not intend to use the offline capabilities).

Concerns then would be the integrity of the data. UserA could modify the device database to affect the work userB carried out (that may benefit userA). Having a separate encrypted database per user is not feasible (as its up to 10GB per user).

I can't seem to find any guidelines, or standards on this specific scenario of having a large subset of information on a device outside the central store. Is anyone aware of any material for this? NIST Special Publication 800-164 appears to be closest, but still doesn't really cover the problem

Any direction, or additional concerns would be helpful. I'm sure this is not a unique problem..

0

I am very interested in to know how you worked around that. NIST reference is good but does not cover specific scenarios like the one you described, My first thoughts were that following the principle of "grant access on a need To know" basis I would consider another role segmentation perhaps with a Logical Control within the devices itself, if they are capable of executing such control (not sure the firmware, os, version, model, etc of your case). If they don't definitely capable of doing that I would suggest a policy and addendum to their contract with some NDA clause that encloses the appropiate use of resources (I guess that already exists like in most cases but you can add verbiage that properly covers the mobile devices and the information within it).

Most solutions will only lead you to compensate for the risk but from a compliance perspective (for different regulations), as of now, you won't be allowed to do that and the answer will be to stop using that in a typical case of security over cost and effectiveness. If you continue with any compensatory control for it you should add this to your risk assessment as this is PII data, meaning sensitive information that the company should have to protect and I can tell you that the responsible parties for the risk acceptance will give it a second thought if they're smart enough.

HIPPA as an example won't allow you to do that (https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/techsafeguards.pdf). And you can review all the documentation but you will encounter the same barrier that overlaps regulations, certifications, best practices, etc: that access PII must be RESTRICTED.

Plus: Mobile Devices are often exposed, they are considered an easy entry point for criminals so sharing with a non-authorized person to access PII is not recommended as the risk calculation (risk=vulnthreatconsequences) will be really high.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.