For When You Can't Have The Real Thing
[ start | index | login ]
start > I Shouldn't Have To Tell You This

I Shouldn't Have To Tell You This

Created by dave. Last edited by dave, 6 years and 331 days ago. Viewed 1,762 times. #1
[edit] [rdf]
labels
attachments
(2017-05-24)

You Are A Systems Administrator

...or a network administrator. I shouldn't have to tell you this.

Lock Your Goddamn Terminals.

If you stand up from a terminal, lock it. If you are finished with a terminal, lock it. On windows it is idiotically simple -- Windows-L. On most other GUIs it will be in the desktop context menu or in the upper-right-hand-corner somewhere. On screen its Ctrl-A+X. It should be a reflex. It shouldn't matter if you are using a guest session, an Administrator session, or your own user session.

And if you can't lock a terminal when you are done, log the fuck out.

Be Aware Of Your Goddamn Terminals.

If you are using something like VNC or Bomgar, then what you see is very probably visible on the remote screen. The keyboard is probably also active, meaning if you disconnect without locking the screen or logging out, you've left an unattended, unlocked session somewhere.

Don't Log Into Things Inappropriately.

If you are on a customer machine, don't log into our password vault. If you are on a customer machine logged into an account that the customer has a password for, don't log into the password vault. And for the love of god don't leave the password vault logged in on the customer computer, ESPECIALLY IF YOU ARE LEAVING THE SITE. True story: one of our guys did this. He doesn't work here anymore.

Encrypt Your Goddamn Disks.

You will have customer data on your disks -- it is inescapable. At a bare minimum, any laptop which leaves the building should have full-disk encryption enabled. Better would be to have a boot-PIN/password. Ideally every disk in every computer would be encrypted, but we are not there yet. But for our workstations/laptops, Windows Pro lets you do this since Windows 8, so get it done. Linux CentOS/Fedora lets you do this too. With today's SSDs and processors there's no excuse.

Use The Goddamn Backup Software.

...because yes, very occasionally the encryption will barf or the disk will outright fail, right? We have backup software for a reason. Make your backups unattended. Check your backup completions. Try to restore files from your backups. Fix it if anything is broken.

Use Our Hosted Services.

We have hosted Exchange. Use it in cached-exchange mode. We have owncloud. Use it. We have other hosted services. Use them, because we have staff who make sure that it all A) works B) is backed up and C) is recoverable.

You Should Be Able To Lose Your Computer Without Data Loss Or Exposure

If you do all this, you should be able to lose your computer and only lose a very little bit of data. Ideally you won't lose anything, but we don't live in a perfect world. Your data should always live in more than one place and be well defended.

Keep Your Updates Up To Date.

WannaCry didn't hurt computers that were current before the outbreak. Chew on that. Let windows at a minimum download updates, but be sure to apply them at a minimum weekly. Run yum or whatever at least weekly on Linux computers. Monitor vendors we care about for security updates and roll firmwares when needed. And most of all: reboot the goddamn computer if the update needs it. a Kernel update won't help you if you never boot into it. Massive uptimes should not be a source of pride any more -- they are proof of negligence.

Design Your Networks And Systems To Account For This

You need to patch and reboot regularly, so you will either need some kind of cluster for availability or a corporate culture that understands such interruptions are necessary to maintain your security posture. So: two AD servers. Two DNS servers. Firewall/router cluster.

no comments | post comment
This is a collection of techical information, much of it learned the hard way. Consider it a lab book or a /info directory. I doubt much of it will be of use to anyone else.

Useful:


snipsnap.org | Copyright 2000-2002 Matthias L. Jugel and Stephan J. Schmidt