lfit/itpol

Useful IT policies

Useful IT Policies

In this repository we provide generalized IT policies adapted from those used internally by our IT staff in hopes that they will come in handy for other organizations, and especially for open-source projects who rely on volunteer admin efforts to manage their infrastructure.

We invite all others to participate, share and donate back their knowledge and expertise to help create a library of checklists and best practice documents that can be freely used and adapted by others.

License

Documents in this repository are licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.

itpol's Issues

Ad Blocking for browsers

Ad blockers have become an invaluable security resource, as many ads are often a source of various privacy/security concerns. Furthermore, common add-ons such as Adblock Plus provide the option to block malicious domains and tracking. With malvertising on the rise, would it be viable to recommend an ad blocking add-on for Chrome/Chromium/Firefox?

Remove use of Ghostery because it is proprietary and could contain secret security issues

Remove use of Ghostery because it is proprietary and could contain secret security issues.

I only learned about this recently!

FYI.

Encrypting /boot is in fact feasible

The guide says:

The /boot partition will always remain unencrypted, as the bootloader needs to be able to actually boot the kernel before invoking LUKS/dm-crypt. The kernel image itself should be protected against tampering with a cryptographic signature checked by SecureBoot.

However, it is fully possible to put /boot on encrypted partition, as described in:
http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS

Misleading passage about LUKS

Hi, you gibe the following recommendation:

We recommend that you use the same passphrase for your root password as you use for your LUKS encryption (unless you share your laptop with other trusted people who should be able to unlock the drives, but shouldn't be able to become root).

This might be misleading. As LUKS is able to store 8 different passwords for the same volume, you can share your laptop with 8 different people, each using his own, personal password to unlock the disk.

Use future-default ?

Given that GnuPG 2.2 (or 2.1.18) is anyway suggested, what about using creating ed25519+cv25519 keys? This is not yet the default because GnuPG 2.2 is not yet widely enough deployed. However for this use-case I consider it very useful to use them - the signatures are smaller and signing is much faster with appopriate tokens. ssh can also use and ed25519 key.

I do all my commits for a long time now using an ed22519 key and it is not even noticable using the gnuk token (which is the upstram version of the Nitrokey). A 4k RSA key on a token will introduce a quite noticable delay.

A drawback is that most tokens don't support these key algorithms. A middle ground would be to use an 4k RSA primary key (and take that one offline) and to use an ed25519 signature key.

CIS Benchmark Inclusion

I would recommend merging as many of the recommendations that your list does not cover as defined in the CIS Linux Benchmarks. They can be found @ https://benchmarks.cisecurity.org/downloads/benchmarks

Apple instructions link for encrypting storage device is broken

Located under: prepare-detachable-encrypted-storage

Coreboot is missing as alternate firmware option.

Hi,

coreboot is an alternate firmware for different platforms. See www.coreboot.org .
It also possible with coreboot to build a secure boot based on GRUB2. On chromebooks you can use chrome os firmware which is based on coreboot.
See https://chromium.googlesource.com/chromiumos/third_party/coreboot/ .
Google provides all firmware as open source even the embedded controller firmware is open.
See https://chromium.googlesource.com/chromiumos/platform/ec/ .
I guess the chromebooks are the most secure and open solution for firmware security...
Maybe this should be listed as alternative option for running a safe linux workstation

For more information about the chromebook boot process take a look at:
https://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-and-recovery

Regards Zaolin

default bit size for master key

Generate a 4096-bit RSA master key (ESSENTIAL)

But there's no reason why we should choose 4096 bit key in this guide, instead of default 2048/3072 bit key.

Suggestion: Mention expected errors from "cp -rp ~/.gnupg [/media/disk/name]/gnupg-backup"

Thanks for the great protecting-code-integrity.md guide.

When I did cp -rp ~/.gnupg [/media/disk/name]/gnupg-backup on macOS 10.13.2, I got the following errors:

cp: /Users/---/.gnupg/S.gpg-agent.ssh: Operation not supported on socket
cp: /Users/---/.gnupg/S.dirmngr: Operation not supported on socket
cp: /Users/---/.gnupg/S.gpg-agent: Operation not supported on socket
cp: /Users/---/.gnupg/S.gpg-agent.browser: Operation not supported on socket

If they should be ignored, I suggest that you add a note to that effect just below the command line.

Please give concrete examples of threat Git without GPG

This guide is very useful to configure GPG setting, however, I'm still not sure what is the benefit for using Git with GPG. Could you describe some senario that uses Git with/wihtout GPG? Commit without sign - what's wrong with it?

linux-workstation-security.md needs an update review

From a coworker:

- password crackers now support passphrase attacks, so a random password is the most secure option
- disabling the root account entirely and using sudo is preferable to having it enabled```

Additional Resources / References Section

It would be beneficial for those who would like to further look into workstation security if you provided some references of your research or resources for reading.

Here are a couple of resource examples I have come across that might be of interest:

• Fedora Security Guide
• CESG Ubuntu Security Guide
• Debian Security Manual
• Mac OSX Security

gpg: error reading key: No public key

I followed your guide and copied .gnupg to an encrypted external volume
but after running:
gpg2 --homedir=/volumes/gnupg/gnupg-backup --list-key [fpr]
i get this error
gpg: error reading key: No public key

Provision intel AMT by default

On systems equipped with intel vPro technology, it's desirable to provision / configure AMT.
If left unconfigured, attackers may enable it and use it for remotely controlling a victim's machine,
including KVM remote access.
This requires initial physical access but is still considered a high security risk by german national IT security institute (BSI). Heise also reported about it, unfortunately also only in german.

I think it could make sense to add this to the workstation policy -- before handing out systems
to end-users, AMT should be locked down using a strong password as this is deemed
more secure than leaving AMT unconfigured (with a default password of 'admin').
Actions required: Press CTRL-P at boot time to enter ME firmware and set a non-default password.

Great project so far, thanks for sharing!

Document steps to create subkey for a new machine

Let's say I have my backup on an external device. What steps do I have to take to create a subkey for a new device?

Git Commit Hashes

protecting-code-integrity.md says that a Git commit hash is done over "the checksum hash of the tree before the change (parent)" (and the other fields).

But as far as I see, a commit object (see e.g. the output of git cat-file commit HEAD) contains not the hash of the tree of the parent commit but the hash of the parent commit itself. After some web search I am quite sure, that the commit hash, too, is produced using the hash of the parent commit and not the hash of the tree of the parent commit.

So, most probably, the phrase should be changed into "the checksum hash of the parent commit".

Can you clarify the choice of RSA for `cert` and ECC for `sign,encr,auth` ?

I want to make a PGP key, just not sure which algorithms I should use for which keys (primary & subkeys). I'm following your suggestion:

• Certification Key: 4096-bit RSA
• Signing Key: 256-bit ECC (ed25519)
• Encryption Key: 256-bit ECC (cv25519)
• Authentication Key: 256-bit ECC (ed25519)

But I don't understand:

• why use ECC over RSA ?
• why use RSA for certification, but ECC for the rest ?