Security: Who's inside your network?

Network security is beoming more of an issue every day, with concerns of privacy, trust and data protection at the front of many network managers' minds. Despite the attention, many breaches are still the result of basic mistakes

  • E-Mail
By  Jon Tullett Published  September 3, 2000

Introduction|~||~||~|By far the majority of security violations occur because of a simple oversight or easily-patched vulnerability.

While there certainly are highly-skilled crackers able to examine and penetrate very secure systems, the chances of such a dedicated attack being made on your network is small.

Although that is true, there is no such thing as a completely secure network. All you can do is make yourself as difficult a target as possible.

That serves two purposes: it discourages “casual” attackers who are browsing for easy targets, and it increases the likelihood of detecting and averting an attacker targeting you specifically.

There are a number of common errors made in dealing with security issues. This article will enumerate some of the most common, then move on to a specific example and how the damage done could have been avoided.

||**||Common Mistakes: 1 — 3|~||~||~|Mistake 1: Do nothing
The most common and most deadly mistake is to do nothing. Simply assume that because you are only one fish in a whole ocean, you will never be targeted.

That is disastrous, firstly because modern cracking tools are able to quickly probe large numbers of Internet sites looking for vulnerabilities, and even automatically attack them, and secondly because 80% of reported attacks are generated from inside the organisation.

Whether as a practical joke, experimentation or because of a disgruntled employee, by far the most common attacks happen inside the “secure” bounds of the network.

An effective security policy is absolutely vital. Even if it is not watertight to begin with, the first step is to recognise that there is a danger, and to take steps to address it.

Start small: deploy a firewall and identify routes into and out of your network. Put anti-virus software in place and keep it up to date.

Perform internal security audits to spot likely vulnerabilities and deal with them regularly. These steps are not complicated, but they do require dedication and resources.

Mistake 2: Fight fires
Leading on from the first point, the second is a logical step. Without an active security policy, then in the event of an intrusion of even a suspected attack many companies do nothing more than damage control. Merely isolating that vulnerability and patching over a hole is not enough.

A single incident should alert the security or IS manager that the company has become a target, and a comprehensive strategy to prevent further incursions needs to be put in place.

Naturally the damage done from a specific attack needs repairing, but from that a number of related questions need to be asked. What was the attacker really after? Was it just a random scan, or was there something in particular they were looking for? What techniques did they use to hit the network? Is the attack traceable, and can steps be taken to lock out the attacker more thoroughly? Are you sure that the attack you did notice was the only one: check for signs of tampering elsewhere.

Healthy paranoia is an important trait of an IT manager tasked with security. He needs to do far more than deal with isolated issues, instead looking at the network as a cohesive entity to be protected from harm.

Mistake 3: Trust the firewall
Far too many companies deploy a firewall and expect to be kept safe from the rest of the ‘net. To an experienced cracker, that is almost laughably naïve.

While a firewall will keep out many casual attackers, it will present nothing more than a minor obstacle to a concerted attack, for many reasons.

Firewalls are themselves vulnerable. Most firewall solutions on the market are very well understood by the cracking community, and many have easily exploited holes of their own.

The vendors update the solutions all the time to patch the vulnerabilities, and new ones are discovered: that is the normal ebb and flow of security.

Failing to keep your firewall up-to-date is practically inviting an intruder into your network.

Firewalls don’t stop every attack. A firewall is great for preventing unauthorised connections into a subnet, but bad at preventing just about anything else.

A custom-built Trojan (often reusing existing ones such as Sub7 or BO2K) can be mailed to an unsuspecting user inside the firewall, and be used to effect a breach from the inside. Denial of service attacks are not stopped by a firewall, because they exploit the way a firewall is designed to operate.

||**||Common Mistakes: 4 — 6|~||~||~|Mistake 4: Downplay risks
As companies move towards the Internet for doing business either via e-commerce or just as an information channel, their reputation and relationships are increasingly dependent on that medium.

A great deal of damage can be done to the business in the course of an electronic attack. Partners who receive forwarded email Trojans are likely to view subsequent documents with suspicion, and rightly so.

Clients greeted with a defaced or unavailable web site may never return. Corrupt data with a company’s database can have a tremendous knock-on effect, affecting transactions and causing glitches long after the attack.

These are serious dangers to an organisation’s economic health. Realising that network security is closely tied to the operational success of a business is a vital step that many, to their detriment, never make. Just like backups: the chances are you’ll never need it.

But in the case of a disaster, if you aren’t protected, your entire business will feel the pain.

Mistake 5: poor follow-up
More than any other aspect of IT, security is something you cannot fix and leave fixed. Every day there are posting on security sites exposing new vulnerabilities in every type of software.

It is vital to keep up to date with what the current threats are and how to deal with them. After all, the chances are than when an attack does come, it will be using the latest cracking tools available. Your network needs to be equally as up-to-date.

Because the Internet makes it so easy to share information and software, what used to be an elitist group of crackers with home-grown tools has become a very active community, sharing knowledge and software all the time.

The result is a vast pool of untalented “script-kiddies”, downloading cracking software and looking for a site to despoil. Most attacks will take this form, and can be easily detected and prevented if the site is prepared for it.

Whoever is managing security needs to keep in touch with that community, understanding how and why targets are chosen, what the current crop of tools are and what applications are at risk.

On top of that, vendors (especially operating system vendors) produce security patches all the time. Patching systems once or twice a year with the latest service pack will mean you spend 90% of the year losing the security race, and at risk. Applying each patch and fix as it is available is laborious, but essential.

Mistake 6: no personnel
A common problem many companies face with security is finding someone to actually do the job. Typically, the task is delegated to the existing IT staff, who will occasionally check for updates and apply patches.

While that can work for a small organisation, a larger one really needs dedicated security personnel. That may sound like a waste of resources, but in fact the role can cover a lot of bases that your existing IT staff probably struggle to cope with, such as backup maintenance and other disaster-recovery related tasks.

These tasks are similar in scope and approach, and offloading them onto a specific person will take a load off the shoulders of your other staff.

A security specialist should be doing several tasks. First and foremost, the network needs to be secure. That means firewalling, filtering, logging, scanning and a myriad of other tasks to make sure that the network itself is as tight as possible.

Next, security policies need to be devised and maintained to ensure that users are protected. Password policies, data sharing and access, internal network routing and email policies are just a few of the tasks here.

A lot of this work involves working closely with users to ensure that they understand the situation, and the importance of the task. To the average user, passwords are an annoyance, and email policies forbidding delivery of executable attachments are restrictive. It is important that they understand why they need to comply with the security policy to keep the company safe.

At the same time, there is a threshold between “secure” and “restrictive”. Security is always a compromise between usability and vulnerability, and the security specialist needs to understand that.

Policies need to be user-friendly, or users will go out of their way to avoid them, thereby defeating the object.

Clearly, a security manager needs very different skills to a regular IT manager. He needs to be able to work closely with users while understanding the business impact that a mistake can make.

Existing IT support staff rarely have the resources to effectively manage a security framework in addition to their other tasks. The mistake lies in the management that assigns them the task in the first place: a mistake easily made.

The unfortunate reality is that finding specialised security skills is not always easy. Fortunately, many outsourcing and consulting companies offer comprehensive security audit and maintenance services, but they do not come cheap.

||**||Insecurity in Action|~||~||~|It’s easy to talk about mistakes companies make in security, so here is an excellent example of nearly all of the above points in action. Consider the destruction wrought by the Loveletter worm earlier this year.

Loveletter is a worm distributed by email, with 29 variants already in the field. It comprises a Visual Basic script disguised as a text file by adding “.txt.vbs” to the filename. On execution, it deletes some files and mails itself to everyone you know. The payload varies from one to the next, but that’s roughly it.

When if first hit in early May, the worm covered the globe in about a day, spreading from country to country and destroying millions of documents, causing damage that some analysts pegged at multiple billions of dollars.

The direct cause for all that damage was the worm, but indirectly was complacency and incompetence on all sides: vendors, users and companies. With better usage policies and tighter security, the damage would have been roughly $0. Walking through the path the virus took, it’s easy to pinpoint why that is the case.

First, there’s the mail server. The worm arrives by mail as [file-name].txt.vbs. While Windows desktops by default hide the extension (so it appears as a normal text file), the telling vbs part is always there. Mail servers should compare ever attachment to a list of known file types, rejecting by default any that do not match.

Acceptable file types might include graphics, word processing documents (provided you have protection against macro viruses), web pages (provided you have protection against inline script such as Kak.Worm), basic text of course, and so on.

Just as a firewall will reject packets that don’t meets its criteria, a mail server should do the same. It need not be inhibitive: by sending a message to both sender and recipient to the effect that the message was rejected because the attachment is not acceptable, both parties can find another way to exchange information. If the mail was unsolicited (as the worm was), it would never have found its way into a system.

Next, there is the mail clients themselves. Microsoft responded to criticism that its mail software should not be so willing to execute attachments by providing a mail patch to prevent it, but by then the damage was already done.

Scripts should not have been able to execute from the mail client. Since Loveletter, other types of script have appears, such as Scrap Objects, abused by the notorious VBS.Stages worm.

In trying to accommodate as much flexibility as possible, vendors of mail software opened the door to abuse. Although the argument for extra features can be made, the fact is that potentially billions of dollars of damage were done because the mail software did something it shouldn’t.

||**||Anti-Virus Software|~||~||~|Third, we have anti-virus software. Even up-to-date anti-virus tools didn’t spot Loveletter, nor its activity. And because of the speed at which it spread, updates could not be introduced fast enough to halt the destruction.

The vendors, so reliant on their window period between virus discovery and rapid infection, were caught by surprise. The users, trusting these vendors, were also caught by surprise. Could they have done more? Yes.

Even if not to catch the infected file, the software should have spotted its activity. Why would a VBS script be deleting every document file on the local machine and network? Isn’t that a bit suspicious?

The anti-virus solutions didn’t think so. Nor did they think it was odd that a script should be spawning multiple MAPI calls to send identical email messages out.

I asked an anti-virus vendor why this was so, and was told that detection of suspicious activity had been removed from their offering because it would occasionally trigger incorrectly while the user was doing something benign.

There’s the compromise: usability (the vendor wanted to avoid false positives) versus security (the virus destroyed every document on the machine). In this case, not a good compromise.

That same anti-virus vendor also failed to identify a variant of Loveletter. Having received the “Mother’s Day” variant and identified it as the same code as Loveletter, I emailed it to their virus submission department, only to be told “it’s clean, just a text file.”

Next, we have the users themselves. There is no excuse for not educating users. Although Loveletter was disguised as a text file, there is never a reason to open an attachment you don’t recognise, or any kind of executable attachment.

Networks that are infiltrated by Trojans such as NetBus or Sub7 are almost always due to an infected email attachment or download being executed.

Users need to understand the ramifications of opening what could be a dangerous attachment. Even if the file somehow manages to get past the mail server onto their mail client, it should never see the light of day.

||**||Backup Solutions|~||~||~|Finally, we have the networks (and their administration). So Loveletter destroyed every document on the network? No problem, just restore from the backup.

The problem is that very few companies have effective backup solutions.

Many perform weekly backups, or even less frequently. If the worm hits on the day before the backup, that’s a week’s work gone. Would those companies be prepared for another, similar, attack? Probably not.

A spokesman for Veritas said that after the Loveletter disaster, there was very little increase in sales of backup solutions. People saw it as an email problem, not a data problem, he said, and never even thought about data recovery.

Even if the worm had been allowed in, its damage should have been reversed in minutes, but very rarely was that the case.

At any of these stages, from mail server to data policy, the worm could have been stopped. That it was not indicates that those companies, of which there were thousands, were poorly prepared for every one of these points, and quite likely are still vulnerable.

Nevertheless, email policies have tightened up since then, and the damage caused by VBS.Stages was considerably less than Loveletter.
The conclusion is not complicated.

Nearly all security breaches and damage can be prevented or minimised by adherence to effective policies, and by keeping the tools current.

Paranoid attention to security is not an over-reaction, it is a realistic strategy for a connected world where the risk of attack increases daily.||**||

Add a Comment

Your display name This field is mandatory

Your e-mail address This field is mandatory (Your e-mail address won't be published)

Security code