Monthly we see news reports of embarrassing e-mails being stolen and revealed, credit card numbers being stolen, national security content being stolen, and on, and on. Here are some of jimc's suggestions for keeping your organization's data safe from the global hacking community.
It's imperative that you update the software on your computers aggressively. An unpatched machine on the Internet will be infested by multiple hackers within a few hours. My own machine is attacked (not successfully) about every 20 seconds. As hackers develop new exploits, software vendors fix the exploitable bugs (as well as bugs detected pro-actively). You should either turn on automatic updating, or should assign personnel to review and push out patches on a frequent schedule. I spend an hour on this task each week.
Don't neglect application software installed separately from the operating system, which likely will also have security updates.
The firewall blocks evil connections from your geopolitical rivals to your computers. Your enterprise, your department, and your individual computer should each have a firewall that lets through only the connections needed to do your organization's job. Generally very few services will be allowed and you need to ask yourself if any particular service is really necessary.
Each computer needs to be able to defend itself against a virus-infested neighbor; you can't just assume that everything on your local network is safe. You need group policies (or the equivalent in non-Windows operating systems) that insure that firewall settings are not forgotten or accidentally messed up.
Each computer should run server software only if it's needed to do that machine's job. The Black Hats can't hack a service that isn't running. For example, at one time Microsoft Windows was installed with Microsoft Internet Information Server (IIS) turned on by default, so users could share photos, documents and the like. People quickly learned to kill it, because it was attacked successfully so frequently. You need group policies to enforce which server software should run on which classes of machine.
You need someone on your I.T. staff who knows something about cryptography, to keep it up to date for the latest threats and for new algorithms. There is a webserver tester on Qualys (SSLlabs.com).
You should never give a password over a non-encrypted connection. On the web this means HTTPS rather than HTTP, and mail readers should be configured to require TLS. Similarly if the content of the web pages or e-mail is not for public viewing, you need to use TLS (HTTPS). Reputable e-commerce websites have adopted the policy that everything goes over HTTPS, and you should do the same on your organization's webserver.
It's a fact of life that discs die, computers are stolen or confiscated by
subpoena, and malware vandalizes your disc. You need to frequently make a
backup copy of your user-created data. Daily is recommended, and the user
needs a simple command to do it conveniently and error-free. An alternative is
for the backup server to have a remote execution privilege on user machines and
to initiate the backup on a schedule. You also need to do a fire drill
to verify that you are actually backing up all the important content and that
you can read the backup media and get the content back on a replacement
computer.
The backup media has to be stored in a survivable place that will resist fire, earthquakes, floods, and hostile bad actors. I personally have one copy ready for immediate use on my backup server, one copy on USB memory in my pocket, one copy (also USB) in a safe on premises, and one copy in commercial cloud storage. Of course the latter three copies are file encrypted with my own key. The procedure to restore is documented (unencrypted), in case the disaster puts me out of action.
I keep historical backup instances, but to limit legal liability, and for practical reasons, you need to limit the number of saved instances and you need to delete old instances according to an adopted retention policy that can be referred to in the response to a subpoena. Here is my favorite retention plan.
Backing up every byte on the computer is neither practical nor necessary. After a total loss you should expect to buy and install a new copy of the operating system and application software on the replacement computer. The backup plan should concentrate on users' work product: the content that directly gives value to your business.
Microsoft Windows has a tendency to open or execute files of uncertain provenance such as e-mail attachments. Therefore a cottage industry has arisen making software that can detect malware and head off opening or executing dangerous files. This is called anti-virus software. If your operating system is Windows, you need to have (and pay for) good anti-virus software, and you need to always keep it turned on, with very few exceptions. And you need to download virus signatures daily; these are patterns that the program uses to recognize the latest attack vectors.
Do not buy the least expensive (or free) anti-virus product! It will install a hacker control panel on your computer from which the product's vendor can do nefarious activities like sending spam or stealing your data.
Linux works differently and anti-virus software is not so useful for Linux. The emphasis is in detecting and junking virus messages on an e-mail server that are in transit to vulnerable Windows computers.
This isn't the name and address you put at the end of the mail, it's a hashed message authentication code (HMAC) appended to a mixed/multipart e-mail message by which the recipient can be assured who sent the message, and that it was not fraudulently (or accidentally) altered. If you send all unsigned messages to the spam pile or to your security officer, unread, you greatly increase the work for an attacker trying to phish you or trying to get you to do something else not to your advantage.
These mail programs can sign outgoing messages:
The URL, for Outlook 2007, tells how to turn it on for one message at a time, or for every message you send (recommended by jimc).
This help page tells how to sign (also encrypt) an outgoing message. It also tells how to install the needed plugin, how to create your private and public keys, how to send the public key to your correspondents, and what signals that the signature on an incoming message is correct.
The linked site offers a web browser
extension called Mailvelope for Mozilla Firefox and for
Google's Chromium/Chrome
which can sign, encrypt and decrypt messages on virtually any
webmail service. I just learned about it when preparing this
report, so I can't personally vouch for how well it works, but other
reviewers love it.
Many users have a dedicated mail reading application, which normally indexes the mail on the computer where it executes, and in some cases actually downloads the message bodies in advance of reading. This of course is a security issue, and there can be coordination problems if the user reads mail on multiple computers, e.g. one or more desktop machines and a smartphone.
An alternative is for the mail server to create a web page containing a list of messages in a folder, and to put up web pages, created on the fly, showing individual messages when requested. This paradigm is called webmail. Modern webmail servers can do almost everything the dedicated apps can do, and any web browser on any computer can read the mail without needing special software (authentication required). An advantage for security is that message content is volatile, and if you configure the browser to use only a memory cache (no disc allowed), the message content vanishes when the web browser exits.
Just about every commercial mail service provides webmail in parallel
with service to generic (IMAP) or proprietary (Microsoft Outlook) mail reading
apps. It is also very feasible for an enterprise or an individual department
that runs their own mail server to add webmail to it.
Roundcube
is currently the
market leading webmail product, and users seem to like it.
At my work as well as within my family, most users love webmail, and use it even though dedicated mail readers are installed on their various computers and phones.
See this Wikipedia article about phishing.
Phishing means sending a message to your users telling them some plausible reason that they have to authenticate to the phisher's fraud site. Then the phisher has their loginID and password and can steal things or can utilize their account for nefarious activity like sending spam. Actually the phisher sends a spam message to many users at random and hopes your users will be among those receiving the message.
Spearphishing involves carefully researched and crafted messages to specific users likely to have stealable value, for example an I.T. administrator with sufficient privilege that the hacker can use to install malware (BlackPOS) on company computers. In recent years there have been several high profile successful spearfishing attacks (and numerous not-so-high profile attacks) including Target Stores and Home Depot, each resulting in the theft of over 100 million credit card numbers. See the Wikipedia article for more.
Whaling is a spearphishing attack on a senior executive, who may have limited I.T. skills and thus is easier to hoodwink. It is common but bad practice to give executives high level privileges ex officio, but like the king in chess, executives should have only the privileges they need to do their jobs.
Clone phishing means fraudulently altering a legitimate message, e.g. replacing a work-related attachment with self-installing malware, and resending it.
Jimc says: First, you need to train your users to recognize and reject phishing attempts. Second, if the recipient insists on signed e-mail, the phishing message will not even be read unless the phisher has already phished the credential of a legitimate user.
Commercial web services generally require a user to authenticate with a user name (typically an e-mail address) and a password, independent for each service. An active web user may have fifty accounts or more, and managing them is difficult. But a worse consequence is that the users get into the habit of giving their password to any web page that asks for it. You should train your users to remember what is the normal login form for each service, including the URL, and to only give the password on that form. Remember that hackers can very accurately imitate a web service's login form, but it's very difficult to fake the host certificate that proves to the user that he has connected to the correct webserver and not a hacker's imitation. (But it's easy to get a host certificate for a hostname that's similar but not identical to the legitimate one.)
In your own organization you should go to considerable trouble to achieve
single sign-on
, which means that your user gives a credential, typically
a password, to her own machine, and then receives a secondary credential
(a small file) which servers elsewhere in the organization will believe in.
Microsoft Windows with Active Directory has this all set up. On Linux,
and particularly for web servers, you will need to do some work. Obviously
the users like single sign-on because it's less work for them, but it also
gets them in the habit of giving their password only to the computer's normal
greeter.
You should strongly discourage people from keeping their session overnight; when they go home from work they should log out. This reduces by a factor of three the interval of time during which attacks can work that depend on an active user session. When the computer is unattended, e.g. for a lunch break, it should be locked with a screen saver. This prevents an operative physically present in your building from perpetrating something on that computer.
Multi-factor authentication can make the hacker's job more difficult because he has to steal and present several credentials of different types. Each type has its weaknesses, but the combination is stronger than the sum of its parts.
Passwords are easy for the server to handle. But
users often pick horrid passwords that a hacker can easily guess. For
example, my department manager was once caught using NewYorkNewYork
(her home city) for a password. They also use the same password for
multiple services, and do not ever change them. With today's computers
cracking a password, the minimum length for marginal strength is 11 bytes
of truly random text, or 23 bytes of misspelled English text.
This usually means a fingerprint; a retina scan is also high quality. Face and voice recognition are also used but it is hard to get this right. We leave fingerprints on everything we touch, artificial fingers acceptable to the reader are not too hard to make, and revoking a compromised finger can be painful.
Well-known credentials of this type include a card that shows a number (that changes) that the user types in, a RFID tag, or a USB memory device or a smart card with a certificate on it. All of these are stealable physically, hence the name.
The VPN makes a secure connection between your computer in the field and the central server. VPNs have these issues:
Commonly, the firewall blocks connections from the global hacking community to sensitive services, and allows connections only from clients using a VPN.
The connection can only be made by a user who can give credentials, not by the global hacking community. Thus an exploit against a service restricted to the VPN can only be perpetrated by a hacker who has stolen the credential.
If you have a service with known exploits against it, you pretty much have to restrict it to the VPN. However it's much better practice to fix or replace the insecure service: no insecure traffic over the VPN. Even so, the VPN is valuable to protect you from exploits that you don't know about.
Your secure protocols keep your content away from prying eyes, but the adversary even so gets valuable information just from knowing that you connected, at a specific time from a specific place, to a particular service and server computer. The VPN server is usually set up so the client's connections to outside servers are routed through the VPN, so hostile snoopers won't know where the user is connecting to.
On the Internet, location does not matter, and you don't need a server at your home or any other special place. All servers should be maintained professionally by your I.T. staff and should be hosted on machines physically within your security perimeter. The various users should interact with the servers from anywhere in the world using intrinsically secure protocols such as TLS and HTTPS. The servers will be safe to use even from locations known to be subject to tampering by motivated and competent enemies,
Services that need to be secured include e-mail, PIM (contact list and calendar), sensitive web pages, virtual private networks, instant messages (XMPP), VOIP (voice chat, i.e. telephone service), and authentication.
A common justification for a private server is that a high profile user needs features or services which the I.T. staff are unable or unwilling to provide. Your security officer should always strongly reject such a justification. If you have software that is not flexible enough to support doing your job, fire it and install something that helps, not hinders. If you're requesting an insecure feature, your security officer should patiently explain why it's a bad idea and you should do your best to understand the security issues and to work out an alternative that gets your job done securely.
A common issue is commingling personal and work-related e-mail. Some users such as engineers can make a clear distinction between their personal and work lives, but others, e.g. in sales or politics, find the boundary to be elastic, and they cannot get their correspondents to send work mail to the work server, and personal mail to the personal server. Each user should do her best to file personal and work messages in separate and recognizable folders. It is much better to use the work server for personal communications, than to take a chance on accidentally getting work content onto a personal server with inadequate or nonexistent security, or worse, onto a commercial cloud service which is paid for by targeted advertising cued by the supposedly secret message content. Organization policy should recognize the problem of personal versus work e-mail and should tolerate reasonable amounts of personal traffic on their server.
You should make a practice of cracking your users' passwords using standard tools used by hackers. Any user with a weak, i.e. crackable password should get a lesson from your security officer.
You should phish your users, and again, anyone who responds should get a lesson from your security officer.
Developers of malware (software that does something bad on your computer) concentrate on the operating systems where their efforts are most likely to be rewarded. On the desktop, Microsoft Windows rules; more than half of mobile devices run Google's Android; and Apple's iOS has a large minority share.
You bypass all the Windows viruses if you run Linux on your desktop machines, as well as on your servers. Of course Linux vulnerabilities are exploited, generally on servers where Linux is dominant, and you need to take prudent security precautions, but the main hacker effort is directed to other than your computers.
A computer, and its software, is very complex. If you set up computers by hand, you will certainly mess up important security protections. Software exists to ensure that application packages, configuration files, and security policies that are supposed to be on the machine are actually there, and that potentially harmful software and policies are removed. Use it.
Security rules frequently specify that content on your computer's disc must be encrypted. Disc encryption has weaknesses which often are not understood:
The hard disc of your computer is divided into blocks of 512 to 4096 bytes each. A set of blocks is assigned to each file, and the content is written on them in order. For full disc encryption, each block is individually encrypted with a block cipher. There is no space for best practices such as individual initialization vectors. An alternative is file encryption: each file is encrypted as a unit with its own initialization vector and integrity hash, using a stream cipher. The encryption in this case is much stronger. Jimc recommends file encryption. However, file encryption works very poorly for a database file, which is accessed and altered blockwise.
If the encrypted filesystem is mounted, then your programs can use the files the same as if not encrypted, and so can your viruses, and hackers who exploit bugs or stolen credentials to get a session. A computer that is asleep (versus powered off) has its filesystems mounted, and a thief can wake it up and use the files.
If your computer is stolen when powered off, then the thief has to do an exploit against the crypto algorithm to get the content, which is very difficult and is beyond the resources available to common criminals. This is the major scenario where encryption on disc protects your content.
Some apps, particularly e-mail software, can encrypt their own files, in addition to full disc encryption. This improves attack resistance when the filesystem is mounted, but the extra steps to decrypt the file may reduce convenience unless the app carefully balances usability versus security.