Author Topic: Bring-your-own-device (BYOD) Policy - An end-user's perspective  (Read 8390 times)

0 Members and 1 Guest are viewing this topic.

Online bingo600

  • Super Contributor
  • ***
  • Posts: 2047
  • Country: dk
Re: Bring-your-own-device (BYOD) Policy - An end-user's perspective
« Reply #25 on: September 16, 2023, 06:36:05 am »
We don't allow BYOD on the CORP network, also goes for VPN connections..
We have a "Guest" network for BYOD ... (WiFi internet connection)

Employees gets a CORP Laptop.
And a Mobile Phone (if needed), rest of us uses Teams as CORP Phone.
The mobile phone is being "Tax'ed ..But private use is then allowed", so ie. i don't want one, as i already have a private phone.

Could just be my opinion but:
I would never enroll my private device in ANY CORP MDM or Zscaler or .....



 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2276
  • Country: 00
Re: Bring-your-own-device (BYOD) Policy - An end-user's perspective
« Reply #26 on: September 16, 2023, 09:28:29 am »
Could just be my opinion but:
I would never enroll my private device in ANY CORP MDM or Zscaler or .....

I completely agree.
If it's my device, I decide the OS, and software installed and nobody else. If that's a problem for the company,
then they can provide a corporate device.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2276
  • Country: 00
Re: Bring-your-own-device (BYOD) Policy - An end-user's perspective
« Reply #27 on: September 16, 2023, 09:31:05 am »
I'd love to just go out and buy 50 brand new laptops that are all spec'd up, but I simply don't have the budget at the moment to replace everything (then there are people's desktop workstations to consider, I'd be looking at a $150-200k project).

In that case security will be a compromise.
Good security comes at a price.
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 4427
  • Country: gb
Re: Bring-your-own-device (BYOD) Policy - An end-user's perspective
« Reply #28 on: September 16, 2023, 12:42:34 pm »
Private cloud.

Don't send the devices to the people, bring the people to the device.

Let your staff use the rubbish they have, but only to access your managed infra in a private enterprise cloud on AWS/Azure or other "network in a box" style sites.

Then keeping the hardware and OS's up to date becomes a web based management activity.  YOU can choose to reboot a staff member's virtual machine to install updates.  You also get to put "Light switches" on the VMs so that they get suspended and parked overnight to bring costs down.

In my cases you can buy you time on a daily basis from "idle" unused hosts.  When someone discards an EC2 for example, instead of unprovisioning it, AWS will reset it's cloud config and make it available as a cheap EC2 instance.  So logging in there and picking a few cheap EC2s for your staff that day could save even more costs.

A cloud instance of a desktop Windows with 8Gb or RAM and 8 cores is going to cost you about $30 a month.  However that includes the electricity and network bandwidth.  If you self host a similar machine it will cost you at least that in running costs anyway and you have to keep the hardware up to date at your own costs.  In AWS increasing the amount of RAM, cores or disk space on a VM, or upgrading it entirely is a click, next, next, ok!

I would avoid layer 2 clouds.  Stick to the layer 1 providers.  The providers who provide you with low level infra and not "pre-canned, managed solutions".  The later will not give you privacy, security and are highly likely to lock you into subscription models which later tighten up or increase in price, leaving you stuffed.  Go for private, AWS, Azure infra such as VMs, a VPC or two.

For access your staff can use VMWare Horizons which I believe you can configure on AWS though I haven't tried.  VMWare Horizons supports multi-layer MFA auth.  You can put an RSA style token on the outer layer and rely on the Windows SSO (or AWS SSO) on the hosts them selves.  Usually the outer layer only provides access to raise a support ticket to fix login or VM issues.

EDIT:  For balance.  The downside with Azure and AWS is "internalisation".  All AWS and Azure services are about bringing your infra in to their cloud.  Once it's in their cloud getting it to integrate with your infra outside of their cloud is something they do not make easy or cheap.  Consider S3 for backups.  It costs pennies to upload and store dozens of gigabytes of data there.  However.  If you check the download costs they are orders of magnitude higher.  So while it might cost you $20 a month to sync 2Tb of backups to an S3 bucket.  It will cost you more like $100 to download those 2Tb when you need to restore a backup.
« Last Edit: September 16, 2023, 12:46:47 pm by paulca »
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline Fflint

  • Regular Contributor
  • *
  • Posts: 196
  • Country: pl
Re: Bring-your-own-device (BYOD) Policy - An end-user's perspective
« Reply #29 on: October 07, 2023, 11:32:36 am »
Having been WFH for over half a decade for a number of Fortune 300 companies (currently working regularly for two clients, a big multinational telco, and a big software company) I have some opinions on BYOD policies from the user point of view :-)

First, do not require bloody 8 digit or an alphanumeric pin on Android devices an aggressive lockout policy with a time delay between tries is more than enough. Alternatively (I'm not sure if this is doable with the current software) require a long pin only when the work profile is active, when it's off revert to whatever settings the user had, requiring authentication on enable of the profile.

This "long pin required" is my only pet peeve on mobile devices. I'd never allow an employer or a client manage my personal device in its entirety, as long as I can "switch off the work profile" after hours and on the weekends so I don't get any notification etc and the employer can't remotely wipe my device by mistake I'm fine with BYOD.

With regards to laptops I always had clients send me their devices for use. Windows laptops all used bit locker, Linux laptops use some tool called "Dell security" and use full disk encryption too. On both systems there is always a VPN client, but details differ. One company for example locks down all local network traffic except their vpn until the vpn is connected, then after passing certain checks local network access is enabled again(so local printers can be used for example). Another company uses a windows vpn client that connects to the corporate DMZ before windows login (with 2fa), then it connects to a different network once you're logged in (allowing you to login a user for a very first time).

In all these companies local admin on these devices is given on as-needed basis following a long and tedious procedure of "proving why you need it" so I got quite adept at working without it (using WSL2 on Windows, installing everything I need in the home folder on Linux, etc).
 

Offline HalcyonTopic starter

  • Global Moderator
  • *****
  • Posts: 6153
  • Country: au
Re: Bring-your-own-device (BYOD) Policy - An end-user's perspective
« Reply #30 on: October 08, 2023, 01:32:07 am »
First, do not require bloody 8 digit or an alphanumeric pin on Android devices an aggressive lockout policy with a time delay between tries is more than enough. Alternatively (I'm not sure if this is doable with the current software) require a long pin only when the work profile is active, when it's off revert to whatever settings the user had, requiring authentication on enable of the profile.

This "long pin required" is my only pet peeve on mobile devices. I'd never allow an employer or a client manage my personal device in its entirety, as long as I can "switch off the work profile" after hours and on the weekends so I don't get any notification etc and the employer can't remotely wipe my device by mistake I'm fine with BYOD.

The problem with short PINs on both (some) Android and iOS devices is they can be easily brute forced or bypassed if the phone is lost. I've mentioned this in other threads but there are tools out there which will allow you to brute force a 4-digit iPhone PIN in hours (seconds if the phone is left on and not rebooted after first unlock). Some Android phones are similar (or PINs can be bypassed entirely).

How likely this is to occur I suppose depends on your industry and who you are.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6590
  • Country: nl
Re: Bring-your-own-device (BYOD) Policy - An end-user's perspective
« Reply #31 on: October 09, 2023, 04:38:33 pm »
First, do not require bloody 8 digit or an alphanumeric pin on Android devices an aggressive lockout policy with a time delay between tries is more than enough. Alternatively (I'm not sure if this is doable with the current software) require a long pin only when the work profile is active, when it's off revert to whatever settings the user had, requiring authentication on enable of the profile.

This "long pin required" is my only pet peeve on mobile devices. I'd never allow an employer or a client manage my personal device in its entirety, as long as I can "switch off the work profile" after hours and on the weekends so I don't get any notification etc and the employer can't remotely wipe my device by mistake I'm fine with BYOD.

The problem with short PINs on both (some) Android and iOS devices is they can be easily brute forced or bypassed if the phone is lost. I've mentioned this in other threads but there are tools out there which will allow you to brute force a 4-digit iPhone PIN in hours (seconds if the phone is left on and not rebooted after first unlock). Some Android phones are similar (or PINs can be bypassed entirely).

How likely this is to occur I suppose depends on your industry and who you are.
Report it to Apple and get a huge hack bounty. If the FBI could not get into a terrorist iPhone in months and requested help from Apple makes me think their security is pretty good and after three mistries the phone is locked.
 

Offline HalcyonTopic starter

  • Global Moderator
  • *****
  • Posts: 6153
  • Country: au
Re: Bring-your-own-device (BYOD) Policy - An end-user's perspective
« Reply #32 on: October 09, 2023, 11:52:42 pm »
First, do not require bloody 8 digit or an alphanumeric pin on Android devices an aggressive lockout policy with a time delay between tries is more than enough. Alternatively (I'm not sure if this is doable with the current software) require a long pin only when the work profile is active, when it's off revert to whatever settings the user had, requiring authentication on enable of the profile.

This "long pin required" is my only pet peeve on mobile devices. I'd never allow an employer or a client manage my personal device in its entirety, as long as I can "switch off the work profile" after hours and on the weekends so I don't get any notification etc and the employer can't remotely wipe my device by mistake I'm fine with BYOD.

The problem with short PINs on both (some) Android and iOS devices is they can be easily brute forced or bypassed if the phone is lost. I've mentioned this in other threads but there are tools out there which will allow you to brute force a 4-digit iPhone PIN in hours (seconds if the phone is left on and not rebooted after first unlock). Some Android phones are similar (or PINs can be bypassed entirely).

How likely this is to occur I suppose depends on your industry and who you are.
Report it to Apple and get a huge hack bounty. If the FBI could not get into a terrorist iPhone in months and requested help from Apple makes me think their security is pretty good and after three mistries the phone is locked.

Apple have known about it for many, many years and for whatever reason have decided not to fix it or simply can't fix it.

Security is always a balance which also impacts user experience. As I always say, you can have the most secure product in the world, but all bets are off once someone else gets a physical hold of it.

In relation to the "San Bernardino" iPhone case, the technology didn't exist at the time for this specific use-case. It's not uncommon for the first point of contact to be directly with the manufacturer, I've done it myself. After that option was exhausted, a company with some very clever people came up with a solution and made a crap load of money, which is still used today all the way up to the current iPhone and iOS versions. This solution also allows the PIN retry lockout (and some other security features which I'm not allowed to discuss under NDA) to be bypassed.
« Last Edit: October 09, 2023, 11:54:57 pm by Halcyon »
 
The following users thanked this post: Kjelt

Offline Fflint

  • Regular Contributor
  • *
  • Posts: 196
  • Country: pl
Re: Bring-your-own-device (BYOD) Policy - An end-user's perspective
« Reply #33 on: October 12, 2023, 03:23:21 pm »
>This solution also allows the PIN retry lockout (and some other security features which I'm not allowed to discuss under NDA) to be bypassed.

I wonder how long it takes them to do one attempt. However, there is a solution for that I'd love to see implemented. A short pin (let's say 4 digits) when you have your "work profile" off (which is most of the time I use my mobile) and enforcement of a long pin when it is active.

Or, having an extra password /pin to open the work profile. This assumes data is stored in an encrypted form(myknox on Samsung phones etc).

 
The following users thanked this post: Someone

Offline HalcyonTopic starter

  • Global Moderator
  • *****
  • Posts: 6153
  • Country: au
Re: Bring-your-own-device (BYOD) Policy - An end-user's perspective
« Reply #34 on: October 13, 2023, 12:00:31 am »
>This solution also allows the PIN retry lockout (and some other security features which I'm not allowed to discuss under NDA) to be bypassed.

I wonder how long it takes them to do one attempt. However, there is a solution for that I'd love to see implemented. A short pin (let's say 4 digits) when you have your "work profile" off (which is most of the time I use my mobile) and enforcement of a long pin when it is active.

Or, having an extra password /pin to open the work profile. This assumes data is stored in an encrypted form(myknox on Samsung phones etc).

It depends on the model of phone and iOS version. But brute forcing 4-digit PINs usually takes hours to days. 6-digit PINs can take weeks to months. There are a few strategies that can be employed to help bring that time down.

If the phone is kept on after it's first unlocked, the PIN/password discovery is usually minutes.

If it's an alpha-numeric password, that increases brute force time exponentially, but again, people are lazy so they usually stick to short PINs/passwords, re-use passwords across accounts/devices, or use weak/compromised passwords.
 

Offline Fflint

  • Regular Contributor
  • *
  • Posts: 196
  • Country: pl
Re: Bring-your-own-device (BYOD) Policy - An end-user's perspective
« Reply #35 on: October 14, 2023, 09:33:03 am »
>This solution also allows the PIN retry lockout (and some other security features which I'm not allowed to discuss under NDA) to be bypassed.

I wonder how long it takes them to do one attempt. However, there is a solution for that I'd love to see implemented. A short pin (let's say 4 digits) when you have your "work profile" off (which is most of the time I use my mobile) and enforcement of a long pin when it is active.

Or, having an extra password /pin to open the work profile. This assumes data is stored in an encrypted form(myknox on Samsung phones etc).

It depends on the model of phone and iOS version. But brute forcing 4-digit PINs usually takes hours to days. 6-digit PINs can take weeks to months. There are a few strategies that can be employed to help bring that time down.

If the phone is kept on after it's first unlocked, the PIN/password discovery is usually minutes.

If it's an alpha-numeric password, that increases brute force time exponentially, but again, people are lazy so they usually stick to short PINs/passwords, re-use passwords across accounts/devices, or use weak/compromised passwords.

Phone manufacturers could've resolved it a long time ago with a longer delay between checks. I'm assuming these methods work by either

 A: emulating a usb connected input device, in which case a simple user defined delay of 30s on the "enter pin" screen and lock after 10 unsuccessful tries wouod solve it.
B: They actually exploit some usb handling vulnerability in the phone and they call an internal api trying to unlock it - that api could have the same delays/lockout built in.

Also, many times these numbers are quoted in context of BYOD devices, I think most people are perfectly fine with the level of protection a 4 digit pin gives them if the device could be reliably locked after a number of tries (automated or not).

Company data is another matter, but that too could be made secure by requiring a password on unlocking the work profile itself (on encrypted storage). So cracking into a phone with a work profile disabled would be but a first simple step in getting to that sweet sweet company data...

There is also always an option of not using a BYOD device, but having a dedicated one... I think its good if this is a users choice which one to use.
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 4427
  • Country: gb
Re: Bring-your-own-device (BYOD) Policy - An end-user's perspective
« Reply #36 on: October 20, 2023, 09:55:05 am »
How likely this is to occur I suppose depends on your industry and who you are.

I know if I had a work phone and I lost it ... and I didn't report it within hours I would be in some serious shit, possible civil litigation and even potential criminal implications for failure to report it.

I have always had a strict work or personal policy.  I did break it at the start of COVID, but out of choice.  The client I was connecting to used VMWare horizons and couldn't care where you connected from, everyone was a hacker until proven otherwise by 2 layers of MFA.  You knew where you stood with that.

However I did allow my Windows PC to join the company O365.  Which was still permitted back then.  This was just to gain access to "Teams chat" and email.

The company got bought, that policy revoked, VPN only for O365 connection.  Work laptop was mandatory.   I removed it from the PC and other than being a bit confused when I wanted to log into microsoft as myself I never seen any bother.

Really big customers, their security is so tight you, yourself feel safe.  They are under so much regulatory scrutiny and are so massive if they make any mistake with YOUR data you can sue them for tens of thousands and they know this.  So they are usually pretty clean and when they are going to eves drop on you, they tell you up front when.

It's the middle ground, the startups and the exclusively USA based companies that are the real threats to home network security.  They still have the YOLO, your data is now mine approach.  They don't have clear privacy boundaries and if a single devops or IT guy wants to record your microphone or turn your webcam on, who's to know right?

So, when I got a few of these customers laptops in and onto the home Wifi I got hacked by them.  Mostly the MacBookPro auto discovery services, but it was getting awfully close to the loosely authenticated HDDs where I keep my Pron!  A customers laptop!

This is when I learnt how to VLAN and segment my network.

Only this morning I had to fix one of the two work laptops.  One of them has a fixed endpoint address for it's VPN and tunnels everything including DNS over it, the other uses local DNS and only puts O365 and other traffic over the VPN... it's DNS was broken.  I was redirecting their DNS traffic to PiHole to kill ads.  Turns out my PiHole just isn't interested in helping the guest network this morning, most likely because I redid the entire lab/office layer 1 last night, taking out every cable, moving the switches and routers and replacing the cables again.  I expect a guest VLAN tag is set wrong on the DNS server.... although they did get DHCP.  Odd.  But I removed the redirect and it's happy with 8.8.8.8
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf