search

DEFRA / software-development-standards

Standards and guidance relating to software development in Defra
https://defra.github.io/software-development-standards/
Other
47 stars 17 forks source link

Unmanaged devices #44

Closed ben-sagar closed 4 years ago

ben-sagar commented 4 years ago

Some guidance on unmanaged devices that I started drafting a long while ago but never completed as someone else got given the job of doing it, but I never saw anything from that so thought we could start reviving this one.

It is out of date but probably could still do with some initial discussion/review.

Starting out with a draft PR as it's only partially completed.

nigejohnson commented 4 years ago

I can see how there is merit to this and agree with most or possibly even all of the content, but, although I can understand why we have enough "skin in the game" to want to have a big say on this one, should it really be coming from us as "Software Development" and not from somewhere in GIO or Corporate Security?
One other question too: I'm unclear what the instruction about only being able to access "officially approved online resources" really means. If it's referring to an exact list then that begs other questions such as, in that case, why aren't those sources accessible on managed devices, possibly meaning the unmanaged device isn't needed at all? Also, could we have a link to the most up to date list? If it's not an exact list, but really means "only access sources that comply with such and such general guidance", should this say that instead?

irisfaraway commented 4 years ago

Given that we're shifting towards using more "managed" devices now so we can stay on the wifi, will we still need this guide?

Cruikshanks commented 4 years ago

I think we still need the guide. For example, I have been telling contractors for years they cannot use their own devices, but never had anything "official" I could point to that confirmed this. Also, we need to make it clear going forward that Linux on bare metal is no longer supported. Plus a great shout about BIOS passwords (seen a couple of machines that are effectively borked because someone has set a BIOS password but no one knows who)

What I would suggest is updating the guide to work with the new inTune managed device policy. So we

I would drop some sections (or radically update them). Specifically echoing @nigejohnson point, there is no point talking about approved resources if the first time anyone asks what those are the only response we have is 🤷‍♂ .

So to keep this moving forward perhaps we can split the work e.g.

Texel22 commented 4 years ago

The stuff in here is really helpfull for me - I just read things i didnt know I didnt know - so had no idea that I needed / shouldnt do them. So my windows device is all good now - looking forward to reading the mac advice ....

ben-sagar commented 4 years ago

Generally absolutely fine, but I do have a comment on the new "Controls for Macbooks" section: "Most importantly, you must ensure that your device is configured to automatically install system and security updates." Seems to contradict: "It can sometimes take a while for application vendors to support new macOS versions and there's no going back, so you can allow yourself a month or two before moving to the latest macOS operating system. But you should upgrade as soon as it is safe to do so.."

I was specifically referring to this: https://support.apple.com/en-gb/guide/mac-help/mchla7037245/10.15/mac/10.15#mchl68bc9c68

The "Install system data files and security updates" setting, which covers anti-malware configuration, not actual operating system updates.

I'll amend the wording a bit to try and make it clearer.

pmshaw15 commented 4 years ago

Looks good to me. A couple of things that we might want to clarify in the document:

ben-sagar commented 4 years ago
  • do we need to mention antivirus/firewall protection?

Added a section on built-in threat protections.

ben-sagar commented 4 years ago
  • use of unsecured public WiFi. It is mentioned in the security principles link but should we discuss it in our document?

Not really sure what to say about this. Is there any specific guidance to link to?

nickblows commented 4 years ago

There is some guidance on the intranet on use of unsecured public wifi, its pretty light but might be relevant:

https://intranet.defra.gov.uk/how-to/services-and-equipment/it-support-equipment/3g-access/

Using public WiFi hotspots

You may be able to connect your Defra laptop to WiFi in: •other offices •hotels •coffee shops

depending on how the WiFi is set up. 1.If it’s ‘open’ there won’t be a password. You should be able to connect straight to the WiFi. 2.If it’s password protected, you should be able to connect. You’ll usually see the password written up somewhere, or staff will give it to you. 3.If you need a username and password to get onto the WiFi, you won’t be able to connect. This is for Defra security reasons.

We don’t provide support for connecting to any public WiFi service.

Be security conscious if you’re using an external WiFi service.

ben-sagar commented 4 years ago

3.If you need a username and password to get onto the WiFi, you won’t be able to connect. This is for Defra security reasons.

Pondering what "Defra security reasons" means...

Basically, the VPN client won't be able to establish a connection, but I don't know if it's just for that technical reason or whether fundamentally there's an inherent security risk in captive portals. Possibly a bit of both.

I could put something in about "be wary of captive portals"?

Be security conscious if you’re using an external WiFi service.

Feels like good advice, but doesn't actually say what to do.

ben-sagar commented 4 years ago

Agreed to approve on call 27/7/2020