I work in IT at an educational institution and I've recently been placed in charge of a new 'mobile' initiative with the goal of making our campus mobile device friendly for students and staff. At this point I'm investigating Device Management software and would like to hear from anyone who has experience in this area.
Google lead me to some promising looking open source software by Funambol. Can anyone provide some feedback about this or any similar solution?
Requirements:
1) Must be hosted in house. We cannot store any data on third party servers.
2) Must support multiple platforms (Android, iOS and BB are a must... windows not so much).
3) Must adhere to industry standards, such as the Open Mobile Alliance.
I would love to hear about your experience with implementing Device Management solutions. If you have information that you cannot share on a public forum, please PM me so I can send you my email address.
just wondering if you got any of your questions answered? I am in similar situation as you are for my company...
Have not heard anything yet, but I did spend a bit of time playing with Funambol before getting sidetracked with another project. Looks like it might do the trick, but it seems to lack the 'polish' that is expected of enterprise solutions. Being a proponent of open source I really want to give Funambol a serious run, but since my company is in bed with Dell I suspect we'll end up using their MDM solutions.
It'll be a few months before I have the cycles to get back on this project, but I'll try to keep this thread updated.
Device Management (DM) is one way to provision a device. Provisioning is updating the device after manufacture. This may or may not include bootstrapping a device. When an OEM or Operator bootstraps a device after manufacture, or makes any other update (except a firmware update) it is provisioning the device. When an OEM bootstraps a device during manufacture it is not provisioning.
Funambol DM not ready for Enterprise
I've had a bit more time to look into Funambol as a Device Management (DM) solution and determined that it is not going to work. They have a Device Sync (DS) solution that works well for backing up contacts/files/etc., but their DM system is incomplete. You have to compile the client software yourself and even then many of the key features are not yet implemented, such as remote lock and wipe. Funambol is something I plan to try at home, but cannot recommend it for business.
Take a look at this MDM report from Gartner. It is a very thorough examination of several of the top MDM solutions available today and might help you make a choice based on your requirements.
I'm in a similar situation and just evaluated Sybase Afaria.
http://www.sybase.com/products/mobileenterprise/afaria
It has a lot of features and as I've tested it, everything worked as it should - but the management website is just horrible. Afaik Sybase is aware of this issue and is working on a new management site.
Best Features: Working with Samsung and Motorola - means deep integration into its Systems, Touchdown integration.
MDM Solution
DeviceMax MDM can be a on-site solution where the hardware can be installed at the client’s server or a cloud based solution where the hardware is on the Kochar cloud and minimal integration with the client's network is required. It is a customized solution that can be either used as a licensed software or a managed service by the Enterprise. For managed service configurations, we can remotely support device diagnostics and even provide the end user service desk support for Enterprise.
MDM Solutions
We started using the Meraki MDM for our enterprise wide solution, but I highly recommend checking out Prey Project for personal or small scale use.
Question about Prey project
In reference to your recommendation of prey project, I see how they help with security of devices but how does it install the image of the tablet after a user uses it? I am looking for an MDM solution for an academic setting. Thanks.
Re: Question about Prey project
snpohrte said:
In reference to your recommendation of prey project, I see how they help with security of devices but how does it install the image of the tablet after a user uses it? I am looking for an MDM solution for an academic setting. Thanks.
Click to expand...
Click to collapse
I'm not sure if I understand what you mean by "install the image of the tablet"... do you mean install the PreyProject client application on a user's device after they have taken it outside of your physical control? As far as I know, all MDM solutions require the client to be installed before any remote administration can be done on the device. You could email your users a link to the app with instructions on how to install/configure it?
I'm not sure if PreyProject is the best solution for deployments of more than a few devices. It might work if each user wants to administer their own devices, but if you are in a scenario where a few IT people need to manage/maintain a fleet of mobile devices then something like the Meraki MDM solution is more suitable.
Hope this answers your question... if not then please clarify your query.
Regards,
Mobile Device Management
With increasing number of Smartphone’s and smart devices used within the organizations, Mobile device management (MDM) has become a vital discipline for IT departments. IT people are putting their focus towards mobile device management support where they will manage the mobile devices. Mobile device management solutions offer the security to the enterprises with full control on them. With mobile device management solutions you can configure your devices over the air, implement the corporate policies, wipe or lock the whole device etc. Nowadays organizations need MDM solutions that fully manage and organize all the devices and applications. It helps to give the whole picture of the mobile environment. It also analyzes the whole report and find out the gaps to resolve it. It also helps to get the critical device information.
The Main Problem with KNOX
Is that end-users are left-out cold without any form of privacy control.
As cool as MDM is to the "enterprise" developer and from a hacker's
perspective, there's nothing attractive with this to the end-user. How
can the end-user be certain that his store-bought KNOX enabled device,
hasn't already been compromised by some "enterprise"?
Without fully transparent, open source and public KNOX documentation,
this will be practically impossible to answer. As far as we know from
recent past experiences, on how "curious" enterprises like Google,
Samsung and NSA have been, why should we trust them this time? Or what
about the mobile service providers themselves? We know from many recent
examples how companies like Verizon and AT&T have been spying on their
customers before.
What follows is a few enlightening excerpts from the latest KNOX
white-paper. Before reading this and having recent major KNOX related
developer issues, I have gone from a "KNOX-who-cares" person, to a vivid
Anti-KNOX-er! I will most likely stay that way, at least until our
devices are sold without KNOX, and only available as a voluntary device
add-on/feature, using open source as it's basis.
What about you? Would you be happy to walk around the streets with a
laptop that has a remote access tool that constantly tracks your every
move, picture, sound and friends you meet and call, all while not
informing of any of that? While being way beyond you control? In fact,
you will not even have any choice, if Godzilla and Samsung gets their
way, in the next year.
Attestation
Attestation offers verification of a mobile device's core system
software i.e, the boot loaders and the kernel, at runtime based on the
measurement data collected during trusted boot. Attestation can be
requested at any time by the enterprise's Mobile Device Management (MDM)
system. All security critical operations of attestation are performed in
Trustzone.
When requested, the Attestation feature reads the previously stored
measurement information and the fuse value (see Trusted Boot above) and
combines these data to produce an Attestation "verdict". This verdict,
which essentially an indicate for whether tampering has occured, is
simply returned to the requesting MDM. The Attestation result is
returned to the requesting MDM server with a signature based on the
device's unique "Attestation Certificate" that is configured in the
device during the manufacturing process. This ensures that the
Attestation verdict cannot be altered during transfer.
Any further action is determined by the enterprise's MDM security
policy. It might choose to detach from the device, erase the contents of
the secure application container, ask for the location of the device, or
any of many other possible security recovery procedures.
The KNOX Container
...
The enterprise can manage the container like any other IT asset using an
MDM solution. Samsung KNOX supports many of the leading MDM solutions on
the market. Container management is affected by setting policies in the
same fashion as those traditional MDM policies. Samsung KNOX Container
includes a rich set of policies for authentication, data security, VPN,
email, application blacklisting, whitelisting, etc.
...
The new container also allows enterprise IT administrators to control
the flow of information between the container and the rest of the
device. This allows enterprises to strike the right balance between
security and user productivity. Users can also control the data sharing
capability based on their personal preferences, within the limits
specified by the enterprise IT administrator.
Mobile Device Management (MDM)
Enrolling an Android device into a company’s MDM system typically begins
with the user downloading the agent application from the Google Play
store and then configuring it for work. Enterprises are facing
increasing help desk calls as more and more users are activating mobile
devices for work and run into issues during this process. In addition
the user is presented with prompts, privacy policies and license
agreements at various stages resulting in a poor overall experience.
The KNOX platform provides a unified enrollment solution that is simple
and intuitive, and eliminates many steps in the enrollment process.
The process begins with the employee navigating to a web page and
clicking on an enrollment link. The link to the original web page may be
provided to the employee via an e-mail or SMS, or via the company’s
internal or external website. Clicking on the enrollment link brings up
a screen that prompts for the user’s corporate email address. The device
then displays all notices for the user to accept, which include privacy
policies and agreements from Samsung, the MDM vendor and the enterprise.
Upon accepting the terms, the user is directed to a screen to enter the
password for the corporate account. If authentication is successful the
enrollment is complete. Any agent application required by the MDM server
is automatically downloaded and installed, without user intervention.
MDM vendors can take advantage of this feature and simplify the
onboarding process for enterprise users and significantly improve the
user experience and reduce support costs.
In a nutshell, this is legalized control and spying.
I believe the quoted features have to be enabled by the company paying for the subscription (ie employer providing the devices), which is pretty standard MDM. If you are going to agree to use a MDM (as such an employee would have to) I see no issue here unless I am missing something.
I would be much more worried about abuse of the baseband, than MDM software which isn't enabled by default. Much more likely, and better target.
E:V:A said:
The Main Problem with KNOX
Is that end-users are left-out cold without any form of privacy control.
As cool as MDM is to the "enterprise" developer and from a hacker's
perspective, there's nothing attractive with this to the end-user. How
can the end-user be certain that his store-bought KNOX enabled device,
hasn't already been compromised by some "enterprise"?
Without fully transparent, open source and public KNOX documentation,
this will be practically impossible to answer. As far as we know from
recent past experiences, on how "curious" enterprises like Google,
Samsung and NSA have been, why should we trust them this time? Or what
about the mobile service providers themselves? We know from many recent
examples how companies like Verizon and AT&T have been spying on their
customers before.
What follows is a few enlightening excerpts from the latest KNOX
white-paper. Before reading this and having recent major KNOX related
developer issues, I have gone from a "KNOX-who-cares" person, to a vivid
Anti-KNOX-er! I will most likely stay that way, at least until our
devices are sold without KNOX, and only available as a voluntary device
add-on/feature, using open source as it's basis.
What about you? Would you be happy to walk around the streets with a
laptop that has a remote access tool that constantly tracks your every
move, picture, sound and friends you meet and call, all while not
informing of any of that? While being way beyond you control? In fact,
you will not even have any choice, if Godzilla and Samsung gets their
way, in the next year.
Attestation
Attestation offers verification of a mobile device's core system
software i.e, the boot loaders and the kernel, at runtime based on the
measurement data collected during trusted boot. Attestation can be
requested at any time by the enterprise's Mobile Device Management (MDM)
system. All security critical operations of attestation are performed in
Trustzone.
When requested, the Attestation feature reads the previously stored
measurement information and the fuse value (see Trusted Boot above) and
combines these data to produce an Attestation "verdict". This verdict,
which essentially an indicate for whether tampering has occured, is
simply returned to the requesting MDM. The Attestation result is
returned to the requesting MDM server with a signature based on the
device's unique "Attestation Certificate" that is configured in the
device during the manufacturing process. This ensures that the
Attestation verdict cannot be altered during transfer.
Any further action is determined by the enterprise's MDM security
policy. It might choose to detach from the device, erase the contents of
the secure application container, ask for the location of the device, or
any of many other possible security recovery procedures.
The KNOX Container
...
The enterprise can manage the container like any other IT asset using an
MDM solution. Samsung KNOX supports many of the leading MDM solutions on
the market. Container management is affected by setting policies in the
same fashion as those traditional MDM policies. Samsung KNOX Container
includes a rich set of policies for authentication, data security, VPN,
email, application blacklisting, whitelisting, etc.
...
The new container also allows enterprise IT administrators to control
the flow of information between the container and the rest of the
device. This allows enterprises to strike the right balance between
security and user productivity. Users can also control the data sharing
capability based on their personal preferences, within the limits
specified by the enterprise IT administrator.
Mobile Device Management (MDM)
Enrolling an Android device into a company’s MDM system typically begins
with the user downloading the agent application from the Google Play
store and then configuring it for work. Enterprises are facing
increasing help desk calls as more and more users are activating mobile
devices for work and run into issues during this process. In addition
the user is presented with prompts, privacy policies and license
agreements at various stages resulting in a poor overall experience.
The KNOX platform provides a unified enrollment solution that is simple
and intuitive, and eliminates many steps in the enrollment process.
The process begins with the employee navigating to a web page and
clicking on an enrollment link. The link to the original web page may be
provided to the employee via an e-mail or SMS, or via the company’s
internal or external website. Clicking on the enrollment link brings up
a screen that prompts for the user’s corporate email address. The device
then displays all notices for the user to accept, which include privacy
policies and agreements from Samsung, the MDM vendor and the enterprise.
Upon accepting the terms, the user is directed to a screen to enter the
password for the corporate account. If authentication is successful the
enrollment is complete. Any agent application required by the MDM server
is automatically downloaded and installed, without user intervention.
MDM vendors can take advantage of this feature and simplify the
onboarding process for enterprise users and significantly improve the
user experience and reduce support costs.
In a nutshell, this is legalized control and spying.
Click to expand...
Click to collapse
jcase said:
I believe the quoted features have to be enabled by the company paying for the subscription (ie employer providing the devices), which is pretty standard MDM. If you are going to agree to use a MDM (as such an employee would have to) I see no issue here unless I am missing something.
I would be much more worried about abuse of the baseband, than MDM software which isn't enabled by default. Much more likely, and better target.
Click to expand...
Click to collapse
I don't know to what extent you're playing devils advocate, but I am still a bit surprised, you can't see any issues with this.
The issue is, that we're not able to see how this enabling mechanism work, and therefore cannot even make any half-baked guess if this is actually secure, or can be easily broken, abused or circumvented, if not so, already. In addition the MDM software is enabled by default, at least as far as my processes and device drivers present, shows. It's just not visibly activated, until you go through the signup procedures. Furthermore it seem that the MDM features are very well weaved into the baseband functionality. Not that baseband is using MDMD, but that MDM makes extensive use of the baseband and features not documented. But to what extent that is true, I can 't really say at this time, as I have not spent any time on it.
One more thing. They say that KNOX is a security "addition" to the default SELinux policies, but that is not the whole story. Actually it seem more that KNOX is replacing or overriding the SEL policies already present. How can we actually test and see this, when we're not even allowed (or given) the tools to do so?
E:V:A said:
I don't know to what extent you're playing devils advocate, but I am still a bit surprised, you can't see any issues with this.
The issue is, that we're not able to see how this enabling mechanism work, and therefore cannot even make any half-baked guess if this is actually secure, or can be easily broken, abused or circumvented, if not so, already. In addition the MDM software is enabled by default, at least as far as my processes and device drivers present, shows. It's just not visibly activated, until you go through the signup procedures. Furthermore it seem that the MDM features are very well weaved into the baseband functionality. Not that baseband is using MDMD, but that MDM makes extensive use of the baseband and features not documented. But to what extent that is true, I can 't really say at this time, as I have not spent any time on it.
One more thing. They say that KNOX is a security "addition" to the default SELinux policies, but that is not the whole story. Actually it seem more that KNOX is replacing or overriding the SEL policies already present. How can we actually test and see this, when we're not even allowed (or given) the tools to do so?
Click to expand...
Click to collapse
I'm not playing devils advocate, I'm saying that I don't think this is the route the NSA would take.
puzzled
I don't get it - I thought "knox" was just that thing that counts how many times you've flashed a custom rom (which can easily be removed and reset).
b
jcase said:
I'm not playing devils advocate, I'm saying that I don't think this is the route the NSA would take.
Click to expand...
Click to collapse
We are not able to see how any closed source security component works, and you investigate it the same way you investigate any closed source feature.
jcase said:
I'm not playing devils advocate, I'm saying that I don't think this is the route the NSA would take.
Click to expand...
Click to collapse
I think it's pointless to speculate in which route they would take, as they would certainly take whatever route available to accomplish their mission. Together with Google own INSTALL ASSET methods, MDM makes that even more simple on Samsungs.
I'm sure we'll see more posts like this in the near future.
FYI - How the NSA can 'turn on' your phone
E:V:A said:
I think it's pointless to speculate in which route they would take, as they would certainly take whatever route available to accomplish their mission. Together with Google own INSTALL ASSET methods, MDM makes that even more simple on Samsungs.
I'm sure we'll see more posts like this in the near future.
FYI - How the NSA can 'turn on' your phone
Click to expand...
Click to collapse
I'll make sure to remove such paranoia posts in the future, one is enough. I think a baseband attack is more likely, as it is more likely to impact more phones, from more OEMs, running more firmwares etc. The baseband is much harder to investigate as well, less people looking at it, more potential for bugs living longer, easier not to get noticed.
jcase said:
I'll make sure to remove such paranoia post in the future, one is enough. I think a baseband attack is more likely, as it is more likely to impact more phones, from more OEMs, running more firmwares etc. The baseband is much harder to investigate as well, less people looking at it, more potential for bugs living longer, easier not to get noticed.
Click to expand...
Click to collapse
Well, I'm not sure that post fulfill all the criteria of "paranoia", especially since it is mostly grounded in truth, apart from the CNN journalism. But my point is already there. When people have no insight or control over what's happening in their pockets, they start getting religiously paranoid. I guess from an anthropological point of view, paranoia has some kind of good survival function for the group. So it serves well as a counter balance to being completely ignorant.
E:V:A said:
Well, I'm not sure that post fulfill all the criteria of "paranoia", especially since it is mostly grounded in truth, apart from the CNN journalism. But my point is already there. When people have no insight or control over what's happening in their pockets, they start getting religiously paranoid. I guess from an anthropological point of view, paranoia has some kind of good survival function for the group. So it serves well as a counter balance to being completely ignorant.
Click to expand...
Click to collapse
It has been removed from the security forum, it is a copy paste of an article reportedly from cnn (no source link to back that), without any citations to the claims made. I will make a better effort to keep the forum accurate, and fud free in the future.
It has factual inaccuracies, and seems to be just a promo piece for a custom Android ROM that indeed has it's own issues.
@E:V:A
I do appreciate your posts, they are welcome here, but some of the posts ive been removing are just FUD, way out there or unsourced.
when I got my phone rooted and opened supersu, it suggested to disable KNOX. Before then, I didn't even know what KNOX is. I searched some information about it, looks like it is just security solution.
explanation
yueyejinghun said:
when I got my phone rooted and opened supersu, it suggested to disable KNOX. Before then, I didn't even know what KNOX is. I searched some information about it, looks like it is just security solution.
Click to expand...
Click to collapse
It's just a feature that counts how many times you've flashed a custom rom to your phone; easily removed and reset.
FIRST Read the OP and then the KNOX whitepaper.
and maybe someone will open this thread again...or remove it.
So exploits are what hackers and programmers do best. They find windows in code that no one else can see through. They freeze executing code in its tracks analyze it and alter it to suit them. They don't just abide their digital environment, they create it. Does anyone know how specifically smartphones are flashed/imprinted with stock rom when they are made for the first time? Or how to alter boot up sequences to unshackle a bootlocked phone? Or how a bootlock even takes effect?
All of our phones were just hardware before someone enabled them to have software. The basics of computing with smartphones and insight to the barest level upon which they operate is what I am trying to gain. I have a, I guess you could call it a test phone. It is a Kyocera Hydro Icon c6730 with KitKat a phone that rightly nobody cares about, and more than enough end users have been vexed by. A perfect phone to deconstruct to its barest functions to fully grasp smartphone computing, Android and Linux. This case is also unique in the way that this device although handicapped very badly (by me) still turns on. It has no Dialer or settings apps and no conventional way to enable debugging mode for it to communicate with ADB. It has no root browser or file manager to receive .apks. The Hydro Icon is bootlocked by Kyocera or a boot menu was never created for the phone by them. The only apps on the phone are calculator, calendar, camera, clock, download, flashlight, gallery, kingroot, (it is rooted) panorama and sound recorder. Kyocera has given the public the source code for KITKAT and Jellybean for the Icon.
I have no hope that anything can really be done to fix my phone. I guess all I really want is to chat with developers and smartphone manufacturers and hackers. People to provide unconventional approaches or help me open this discussion to a broad range of minds and intellects. like I said before, all of our phones were just physical units of hardware before the distributor enabled the software. 0 to 1
This is a challenge to any hacker who thinks he or she a can do it. I'll even mail you the phone for you to experiment on. If you would mail it back when done and share your exploit with the users of this model phone.
mattvision09 said:
So exploits are what hackers and programmers do best. They find windows in code that no one else can see through. They freeze executing code in its tracks analyze it and alter it to suit them. They don't just abide their digital environment, they create it. Does anyone know how specifically smartphones are flashed/imprinted with stock rom when they are made for the first time? Or how to alter boot up sequences to unshackle a bootlocked phone? Or how a bootlock even takes effect?
All of our phones were just hardware before someone enabled them to have software. The basics of computing with smartphones and insight to the barest level upon which they operate is what I am trying to gain. I have a, I guess you could call it a test phone. It is a Kyocera Hydro Icon c6730 with KitKat a phone that rightly nobody cares about, and more than enough end users have been vexed by. A perfect phone to deconstruct to its barest functions to fully grasp smartphone computing, Android and Linux. This case is also unique in the way that this device although handicapped very badly (by me) still turns on. It has no Dialer or settings apps and no conventional way to enable debugging mode for it to communicate with ADB. It has no root browser or file manager to receive .apks. The Hydro Icon is bootlocked by Kyocera or a boot menu was never created for the phone by them. The only apps on the phone are calculator, calendar, camera, clock, download, flashlight, gallery, kingroot, (it is rooted) panorama and sound recorder. Kyocera has given the public the source code for KITKAT and Jellybean for the Icon.
I have no hope that anything can really be done to fix my phone. I guess all I really want is to chat with developers and smartphone manufacturers and hackers. People to provide unconventional approaches or help me open this discussion to a broad range of minds and intellects. like I said before, all of our phones were just physical units of hardware before the distributor enabled the software. 0 to 1
This is a challenge to any hacker who thinks he or she a can do it. I'll even mail you the phone for you to experiment on. If you would mail it back when done and share your exploit with the users of this model phone.
Click to expand...
Click to collapse
Hi,
Try posting your query here:
Android Q&A,Help and Troubleshooting
Experts there may be able to help you.
Good luck
Art Vanderlay
XDA Assist
by sophisticated government attack i mean something with virtualization technologies, several masking and hiding capabilities like FinFishers solutions.
Does:
Updating to the newest version of ios
hard reset the phone
securely remove the spyware?
1) i see more as a bonus question that is not really needed, but might be interesting too.
I would thank you for a careful but practical answer, since this question relates to some "moving parts" like: "Is it possible to load a "real" update from an infected phone, or will a sophisticated attack redirect those requests" and if there is something you can do to prevent this etc. or the question whether a hard reset really deletes everything or if the spyware can somewhat hide in "blocked" or wrongly addressed areas of the storage and so on.
On the other hand i do know that there never is absolute certainty and would be more interested in a "probabilistic view".
Thanks to the Forum!
I think your question is pointing to widespread security problems with most technology. Manufacturers often use closed source software and the same goes for most of the hardware devices. This makes security very difficult and of course these weaknesses are now being exploited by state sponsors.
Stuxnet was a good example and well worth reading about.
https://en.m.wikipedia.org/wiki/Stuxnet
http://itmanager.blogs.com/notes/20...e-protected-the-iranians-against-stuxnet.html
It infects microcontroller chips that do memory management. The introduced code returns modified data, maybe not even on each read.
So if the phone internal memory uses these microcontroller chips then even loading a new rom wouldn't help. You have to be able to have access to the microcontroller firmware and introduce your own access certification. It is very difficult to do this at present as most of the hardware information is not available, both for phone and internal chips.
Unfortunately this means that state sponsors can take the devices apart, inspect chips with an electron microscope, thus obtain a lot of secret information for their hacks.
Having had stuxnet on a laptop I became interested in these problems.
Contaminated updates again depend on the resources available. These rely on https and code signing.
https://arstechnica.com/information...ate-authorities-conspire-to-spy-on-ssl-users/
http://www.crypto-it.net/eng/theory/software-signing.html
A contaminated update requires access to the certificates and a delivery method such as intercepting a request from a known ip address.
Many states have access to the certificates and the means to target downloads. Using tor for updating might give some protection, as would a system to compare your download with that obtained by other people. We don't have this working automatically yet as far as I know.
https://www.torproject.org/docs/verifying-signatures.html.en
Phones have a second operating system where code may not be secure.
http://www.osnews.com/story/27416/The_second_operating_system_hiding_in_every_mobile_phone
https://www.rsaconference.com/event...ile-apt-how-rogue-base-stations-can-root-your
You can minimize risk by keeping a device in airplane mode and using a separate mifi device.
If you consider yourself an innocent target or just want to minimise risk then perhaps regularly buy second hand or new devices from shops, keep them in airplane mode, keep the necessary software to send by bluetooth and check the md5 sums.
Web browsers could be another security problem if they can run exploits, but this is probably outside the scope of your question.
Secure communications apps will probably work fine as long as they don't require updates. Beyond that, keep it all locked up in a safe you built yourself.