Anti-Virus Updating

April 29, 2013

The folks over at the SANS Internet Storm Center have a recent diary entry on keeping anti-virus (AV) software up to date.  This kind of anti-malware protection typically tries to recognize “evil code” on the basis of a set of heuristics, or by recognizing bit patterns in the code itself (these are sometimes called “signatures”).  These elements, especially the signatures, need to be updated as new varieties of malware are created and discovered “in the wild”.   (The defender is always, in a sense, trying to catch up, since a new type of malware has to be found and identified as such before a signature can be developed.)

The contributors to the article are all very capable systems administrators, and I think it’s well worth a read, especially if you are responsible for a bunch of PCs.  (There are also some comments following the article itself; they are, as usual, sort of a mixed bag.)  I’d take away these suggestions from the discussion:

  • You may need to schedule AV updates more frequently than your initial instincts (one participant suggests hourly), to account for the fact that the updates will not all run every time they are scheduled.  (Machines may be rebooting, or turned off, for example.)
  • Because updates are not guaranteed to occur on the advertised schedule, it’s important to measure how up to date your machines actually are — if there are big discrepancies, try to find out why and fix the problem.
  • AV software is one layer of defense, but is certainly not a total solution.

Probably the most important advice is this: if a machine has been compromised by malware, it is highly improbable that AV software, or anything else, will be able to clean or repair it.  Modern systems, and the malware that attacks them, are so complex that figuring out exactly what has been affected, compromised, or corrupted is effectively impossible.  The only reliable recovery method is “nuking from orbit”: wiping the machines hard drive(s), and reloading the OS, applications, and data from known clean backup copies.  Yes, it is a bloody nuisance, but it’s really the only way to make sure that you have a clean system.

Cyber Security Awareness Month

October 1, 2012

It has become customary, in the last few years, to designate October as National Cyber Security Awareness Month [NCSAM].  The aim of the event is to increase awareness of security issues, and good security practices, not just among technical people but among computer users in general.  Cyber security is a little like fire safety; if your neighbor’s house or property is a serious fire hazard, it affects you, too.   Similarly, if your neighbor’s or colleague’s machine is made part of a botnet, or gets a nasty malware infection, it puts others at risk, also.  The event is sponsored by the National Cyber Security Alliance, a consortium of tech and financial companies, educational institutions, and government agencies, also aims to promote the concept of cyber security as a shared responsibility.

The good folks at the SANS Internet Storm Center [SANS ISC] are planning to present a special diary (=blog) post every day on the theme of “Standards and Security”, to mark the month.  Although these posts will be at least somewhat technical, SANS also has its own awareness site, called Securing the Human.  (I wrote about this site back when it was launched, in late 2010; as I observed at the time, many security problems are characterized by the acronym PEBKAC: Problem Exists Between Keyboard And Chair.)   The site also offers a free security awareness newsletter, called OUCH!.  They will also feature some security webcasts during the month; see the main SANS ISC site for details.

This month, Random Walks will have a button linked to the main NCSAM page, and I will also try to focus on security topics that are of special importance to end users.  If you are a system or network admin, I encourage you to do likewise.

Microsoft to Block Insecure Certificates

September 10, 2012

Tomorrow is Microsoft’s “Patch Tuesday” for this month.  As I noted in the preview post, there are only two patches scheduled for release, neither of which is for Windows itself.  Many home users, especially, will have no patches to apply.

Dr. Johannes Ullrich, of the SANS Technology Institute, has a diary post at the SANS Internet Storm Center that suggests one reason that the patch load is especially light this month.

In part, the low number of bulletins appears to be intentional, to not distract from the more complex issue which will affect Windows users starting with the October update set: Windows will no longer allow SSL certificates with RSA keys that are less then 1024 bits in length.

These certificates are cryptographic credentials used to secure Internet connections via the SSL/TLS protocols, which create an encrypted connection between the user’s browser and the server.   The connection protocol also provides the user with some assurance that she is actually connecting to her bank’s Web site, and not to some Bad Guy’s imitation.  The certificates can also be used for encrypted E-mail.  I’ve written here before about some of the problems associated with these certificates and the Certificate Authorities [CAs] that issue them.

Microsoft’s intention is to disallow certificates that have a key length less than 1024 bits, on the grounds that they are insecure, which is certainly true.  Further details are given in Microsoft’s Security Advisory (2661254).  The change, which will be pushed as a patch as part of October’s “Patch Tuesday”, will affect all supported versions of Windows and its components.  (It will not affect Windows 8 Release Preview or Windows Server 2012 Release Candidate, because those versions already include this change.)

The potential problem for users is that some may have specialized or internally-developed applications that use certificates with short keys.  These will cease to work once the October update is installed.  Microsoft has a Knowledge Base article explaining the implications of the change; it also contains download links for the patch, which is available now for testing.  As Dr. Ullrich says, you really should test this while you have the opportunity.

As a first step, you should install the patch on a test system, and watch for any problems. You should also carefully inventory your certificates, in particular if you are using non-standard (internal) certificate authorities.

He goes on to say that you should, if possible, avoid creating new 1024-bit RSA keys, but use 2048- or 4096-bit keys instead.  This is also excellent advice.

%d bloggers like this: