Posted on July 23, 2013|by: Clay Calvert| 1 Comment

For almost 10 years, I worked to maintain a secure IT environment in the State Department. My work stretched across three consecutive Secretaries of State: Secretaries Albright, Powell, and Rice. Over the years I’ve learned that some of the most effective security measures are also the most simple. Today, I’m outlining the top five network security threats facing government agencies, along with some simple things that you can implement in your own organization to address them:

1. Human error. Surprisingly, the biggest threat to an agency’s network can be its own employees. It’s usually not intentional, of course, but it does happen. Most agencies have software security systems in place, and for the most part, they are effective. However, there are dozens, if not hundreds, of new pieces of malware created every day, making it impossible for these solutions to stay one step ahead.

Virus writers know this, and they will test the viruses they write against security scans. Once they have a virus that can bypass those security checks, they’ll package it in an email that looks like a legitimate work email, and send it to several people in an organization (This is called phishing or, more specifically, spear-phishing). Then, sure enough, when someone opens it, malware is installed on the computer. That’s why it’s important to tell your employees not to open attachments, or click on provided links, that aren’t from someone they know. If they receive a suspicious email, they should run it by the security team, just to be sure. Even if it is from someone they know, they should think twice about clicking on links or attachments.

2. Improper permissions. A regular user should not be checking email or visiting web pages with an account having too many, especially administrative, privileges. Infected web pages, or emails, have much less of a chance of compromising a computer if the account does not have the ability to modify system files.

Permissions apply not only to user accounts, but also on computer and server settings. Too often a ‘service’ account has too many rights, or permissions, set in the file system and in the registry, allowing malware to ‘dig’ in. Trying to maintain permissions manually can be onerous, but taking advantage of tools such as Microsoft’s Group Policy can greatly help in proactively managing proper access levels.

3. Java. Oracle’s Java can be so dangerous to an organization’s IT environment that, most of the time, I recommend that agencies abandon it all together. Here’s why: In software security, an exploit is a piece of software, data, or sequence of commands that takes advantage of your software’s vulnerability, causing bugs and other unexpected behavior. In the last few months alone, there have been over 50 different exploits reported that are associated with Java.

Before I move on, I want to take a minute to discuss the difference between Java and JavaScript. Although they share a similar name, they are completely unrelated, and it’s important not to confuse the two when implementing the security measures outlined above. The main difference is that Java is a virtualized operating system running within your main operating system which could be Windows, Mac, Linux, etc., and JavaScript is computer programming language built into all major web browsers and primarily runs only on the web page you’re using that requires it.

There are sometimes instances when Java is needed. In that case, there are ways to greatly decrease your system’s susceptibility to the issues of Java. First, you should only use it for one or two servers, a handful at the very most. Next, you should set up your browsing environment so Java is only allowed to run when it accesses certain websites, and make sure that the browser disables Java as soon as it encounters anything other than those designated websites. These settings can be managed with Group Policy.

4. JavaScript. The vast majority of malware is deployed by web sites through JavaScript. Again, the simple way to solve this is to set up your environment so that only certain sites are able to run JavaScript when needed. JavaScript blockers stop not only malicious ads, but other elements that are specifically designing for installing viruses.

5. Outdated software. Keeping your systems, software, and programs up-to-date is a minimum security requirement, and one of the most proactive things any agency or private organization can do to ward off malware.

Once an exploit gets discovered, hackers quickly try to capitalize on vulnerabilities; the longer a system goes unpatched, the greater the chance of an attack being successful. For home users, Secunia PSI is a great way of identifying unpatched, or unsupported, software.

Newer operating systems are typically designed to be more secure. To illustrate why, let me explain the difference in security risks when Microsoft updated from Windows 7 to Windows 8. When building Windows 8, Microsoft made it a priority in the Surface RT (tablet) version to compartmentalize the applications so that if one should be affected with malware or a virus, it’s less likely to infect the entire system. On Windows 7 and earlier versions, if one app or program has a virus, then it can be easily spread through the rest of the computer.

But if upgrading to the most recent versions of every OS and program isn’t an option, don’t worry too much, just be sure you’re running the most up-to-date patches on the version you are running.

The good news: Not only are operating systems getting better, many application vendors are also improving. Adobe Reader would have made this list a year ago, but its’ risk factor has actually gone down recently. Once a significant risk to any IT environment (because it needed access to your entire computer in order to run), the latest version of Adobe Reader now runs in a sandboxed environment. This means it no longer needs that access to your entire computer. When you open a PDF, it creates a little artificial environment that it can run on.

But just because Adobe Reader now poses less risk to your environment doesn’t mean that you can run it blindly on every computer in your agency and not worry about security threats. Which brings me to the reason I wanted to address it in this list: Even though you know that Adobe Reader has improved, it’s still new software running on your computer, and you don’t know how it will impact your environment. It’s very important that every agency tests this new version to see how it affects them. For example, on one of my projects we embedded CBTs into PDF files to make them easier to view on many systems, but that feature no longer works in the newer versions of Adobe Reader.

These are just a few on what is certainly a long list of security risks for government agencies, but it’s a good place to start. Have questions on protecting your agency further? Reach out to me in an email.

Filed in: Collaboration, Cybersecurity, Modernization, Technology, Tips & Tricks, Web

One Comment

  1. November 24, 2013 at 10:42 am

    Oracle recommends that all Java applets be cryptographically signed regardless of the privileges required by the program. Unsigned Java applets will run within a web page with a scary red warning that, “Running this application may be a security risk.” One of Java’s most-touted features is a “sandbox” security mechanism that is supposed to prevent certain functions when the applet is sent as part of a Web page. But according to both Jongerius and Dormann, Oracle made the default behavior for signed code to be full access to the computer (essentially, negating the usefulness of the sandbox).

Your email is kept private. Required fields are marked *

*
*