Scott M. Mcdermott

UNIX Systems & Network Administrator
available for contract or salaried positions
site location:

Overview of Security Issues

It has recently been suspected that our company has an information leak, providing premature intelligence to business competitors about our operations and sales engagements.

While the security threats posed by information leaks are generalized, they include, and are comprised largely of, threats to the security of our Information System in particular. In response to this threat, we have analyzed the state of security for our company's Information System.

History

In fact, this is not the first incident where the security of our Information System has been compromised.

Not long ago, a web server host on our internal network was penetrated by automatic exploitation tools that targeted Microsoft Internet Information Server (IIS) web server installations across the Internet. This host had a firewall hole exposing it to the Internet for demonstration purposes, and the system itself was not maintained, only used.

Fortunately, the intruder was an automaton, satisfied defacing web pages. We were able to wipe the exploited system clean and rebuild, and there did not appear to have been any other damage resulting from the intrusion.

What did result was some real proof of what sort of injurious things could happen if the security of our systems was not taken seriously. At this time in our company history, there was (and to some extent, still is) no clear delegation of systems maintenance throughout all corporate units, and while the people responsible for generic computing infrastructure were interested in maintaining their own systems properly, there was often no one assigned to maintain or properly configure user systems that development or sales teams were responsible for.

One reason this occurred was because users of these systems were not interested in reducing the convenience, features or accessibility of their systems in trade for increased security, and the team normally concerned with maintaining systems would not accept responsibility for a system they could not lock down securely. The result, unfortunately, was a lack of maintenance which resulted in compromise.

After security compromise occurred, some sorts of concessions were made from business entities that had a desire to expose their information to the Internet. During the remainder of the year we were able to set up a segmented network for specially exposed machines like the cracked web server.

While setting up this network was a needed action to protect us from damages resulting from breakin, it did nothing to address a more fundamental problem within our company: lack of an institutionalized security policy. It's great that our corporate systems aren't as affected by a compromise of a demo system any longer. But without long-term, documented procedures and formal policy in the minds of every employee that has private information, we will always be playing a catch-up game and trying to tape over leaky seams in our information systems.

Reaffirmation

The "security concern" has come up again recently as sales teams have revealed to us that competitors seem to have unusually -- or impossibly -- accurate and timely information about our sales engagements and some data regarding operations with established clients that are not public.

Assuming this is not mere coincidence, we might surmise that the information was leaked. This could be through any one of the following methods:

  • malicious internal party: disgruntled employee, spy
  • benign internal party: loose tongue, trusted third party
  • unauthorized system intrusion: competitor or cracker
  • data leakage: lack of protection in transit or disposal

This document provides an overview of each of these scenarios.

Information Leak Vectors

We summarize each considered means of leakage and discuss in generic terms what kind of precautions and changes to our IT system are necessary to combat such information leakage.

Malicious Internal Parties

This class of information leakage is perhaps the most difficult problem to address because all manner of precautions to limit network access to authorized parties can be completely bypassed by an insider. We could cut off all Internet access, unplug all our computers from the network and require direct console access to important information, and this still would not protect us from an insider sitting at the computer and putting sensitive or valuable data on portable media, or even using an ink pen to record it.

Obviously, the ideal solution to this problem is to eliminate it from occurring by keeping the employees happy and giving no one a reason to harbor malice toward the company. But even in the case of such a perfect corporation, there's nothing preventing a spy from being hired, gaining trust and infiltrating an organization for the explicit purpose of carrying sensitive information offsite, for whatever incentive that person had.

Since we know there's no such thing as a perfect corporation anyways, we don't even have to go that far. We know that sometimes employees can be upset: disagreements with management, internal competition, unfair layoffs, or any myriads of reasons why an inside agent could go turncoat.

In the year 2000, the Computer Security Institute's (http://www.gocsi.com/) annual survey of several hundred Systems Administrators and industry Security Analysts revealed that a startling 70 percent of unauthorized network access originates from internal entities in the employ of the organization in question. This only stands to reason if employees operate with the assumption that their fellows are also their friends and are all working on the same team. That is an admirable attitude, but in real life we know it isn't always the case.

Because this threat can never be eliminated, it should be assumed and planned on. We should never feel that because a given system is not accessible from the Internet, it is safe; while it may be true that the system cannot be accessed externally, there's nothing stopping the disgruntled employee from accessing the system, and there's nothing stopping an intruder who has gained access to one internal system from using them to access others. For these reasons, there should ideally be no distinction made between external and internal systems; these labels should only confer the system's location in the network topology, and no assumptions should be made just because the machine is located behind a firewall, as is so often cited (this author just walked out of a room where four (4) people told him he was wrong for insisting on the use of authentication and encryption behind our corporate firewall is unnecessary complication).

To this end, we as individuals and us as a corporation need to always ask the following questions about data systems we set up internally:

  • can the data in this system be read anonymously?
  • do accesses to the data in this system need to be logged, and are they?
  • can the data in this system be read by unauthorized parties?
  • is the data access mechanism susceptible to eavesdropping, and if so has the communications path been restricted and encrypted?
  • is the authentication mechanism accessible by means which it does not need to be?
  • can the authentication mechanism be considered reasonably foolproof and secure ("reasonable" to be determined by the importance of the accessible data in the system at hand) ?
  • is the data in the system accessible through other means such as backup tapes, and if so have said means been secured to the same standards as the means in question?
  • could there be other means to access data in the system that are unknown or require qualified appraisal?
  • can the data be overwritten by anyone that is not trusted with this ability?
  • are all components of the data system used in making the above assessments understood, maintained, and current?

If the answer to any of these question is "no" then there is an attack vector available to a malicious internal party. Stop now, do not pass go, and move straight to locking down your data system.

Benign Internal Parties

Not everyone is an evil corporate infiltrator. Or are they?

Treating all systems and networks as suspect, assuming the worst scenario in all cases, mistrusting all of one's comrades, and harboring general suspicion is merely dutiful paranoia, a recommended practice for all boys and girls.

Seriously, let's consider a few questions which might be considered paranoia:

  • is there an electromagnetic signal sniffer installed in your keyboard right now as you read this sentence?
  • did someone break into the building yesterday, hack into network conduit, splice wires and install a signal sniffer on the LAN bus?
  • did the employee that set up your computer install backdoors or eavesdropping software?
  • has your workstation been shut down in the night and its network interface card replaced with one that sends a copy of all transmitted packets to that funny looking system in the closet?

Do you really know the answer to these ridiculous questions? The answer is of course, that you do not. These are perhaps not feasibly entertained suspicions in many circumstances, but the lesson here is that we need to always be cautious, always consider the security of our data, and always give only as much trust as is necessary and reasonable after a full evaluation of the risks involved and the importance of the data.

Let's take a look at some things we can all do which are perhaps a bit more feasible. Consider if you, the reader, do sloppy things like:

  • lock your workstation each time you leave your keyboard or just let the inactivity timer do it?
  • give your password to a friend rather than go through the process of having said friend gain formal access themselves?
  • leave sensitive data burned onto a CD laying on your desk at night?
  • put post-it notes with passwords on your monitor?
  • use the same password for different accounts? Or use easily guessable passwords (after all, it's too hard to remember "0kjk%**Rtj2" isn't it)?
  • use unencrypted access because it's too hard to learn that new whizbang secure access tool and it just doesn't seem worth it (and of course we're "behind the firewall, so it doesn't matter," right?) ?
  • ignore security warnings on the assumption that it's just programmatic or configuration error?
  • leave data unprotected because it's a hassle for people to have to authenticate themselves all the time?
  • trust third parties with your data because they're probably not out to get you or the company?
  • put off applying that important security patch because surely the cracker will hold off making attempts until you've met your important deadline?
  • discuss private company information (innocuously) which you really don't need to share?

It is these sorts of questions that need to be asked by each individual routinely in order for the antithesis of security -- carelessness -- not to destroy our carefully implemented security measures. Taking the extra time for security's sake, asking questions if we don't know, and constantly maintaining vigil over our data will allow us all to rest easier knowing that the company's valuable information remains in our hands and ours alone.

The effectiveness of a security policy is only as strong as its weakest component. Each employee needs to do their part for those components they are responsible for.

Unauthorized Intrusion

There are three actual conduits for information to enter or leave our data system:

  • physical media (disk, cdrom, human brain)
  • through electrical conduit (Internet link, wiretap)
  • by way of radiation (wireless access points, EM tap)

When viewed as an encapsulated, quantified data system, company information can only be accessed by external data systems through explicit, defined inputs and outputs:

  • physical media
  • connection requests
  • replies to connection requests
  • established connection traffic
  • allowed connectionless traffic
  • access terminals

The job of a firewall is to occupy a sequence point in the input/output path and make decisions about what traffic is allowed to ingress and egress the data system it protects. It does this by inspecting the data packets' sources, destinations and content (to varying levels) and only allowing traffic through which has been explicitly accepted, or which is in reply to requests which have been explicitly allowed. All other traffic is unconditionally dropped.

This means that we, the keepers of the data system, will at any point be aware of all the potential points of intrusion; they will be finite, and thus quantifiable and manageable.

However, in the case of our company's implementation (and any other for that matter), there are several points which invalidate this premise.

Unrestricted wireless access

At present, there are two known Wireless Access Points which allow access to our internal network. These access points have utterly no firewall protection and are completely unrestricted outside of the (weak) encryption to the access point itself. A casual passerby with a wireless device will have complete, unhindered access to our internal network after running off the shelf traffic capture tools and using known attacks to crack our WAP, and any other rogue ones employees have set up impromptu (as have been discovered several times). They will then be able to communicate with all internal machines with impunity.

This is a fairly dangerous situation because any of our competitors could sit in the parking lot and rifle through any data they can access without authorization. What's more, the lack of encrypted communications internally will enable them to easily obtain adequate authorization credentials to exploit otherwise protected systems.

These wireless intrusion points were set up by individuals that thought it was "neat" (or maybe even useful) to be able to access our network from their wireless handhelds. At some point these have even part of sales demonstrations, but they existed long before that (we became aware of these after they were "essential" and could not be removed). The systems were set up without consulting anyone and with little or no thought given to the security ramifications of such a devices, including the invalidation of the security model assumed by administrators.

This highlights the most important point this document attempts to make, one which has already been made in each section if read carefully enough:

The integrity of any security system cannot ever be completely known, and because of this, it should always be assumed to be insecure and configured as though it were fully exposed.

This author cannot stress enough how the institutionalization of this mindset is absolutely essential to any kind of efficacious security policy. Many times has the author been told that some precaution was silly because we are "behind the firewall" or "who's going to be listening" or "it's too complicated [to use some secure access method instead of an easy one]." With this kind of attitude we might as well all go home and put a wrecking yard magnet over all our storage media, and flamethrow all our backup tapes. At least this will prevent others from getting rich from our free access system.

In the specific case of wireless access, we can implement restrictions, or remove it altogether (obvious recommendation). However this is largely irrelevant because we really should have no reason to fear an intruder behind our firewall; it only belies laxness and false assumptions made by people based on their hosts' location behind the firewall. In a properly secured network there wouldn't even be any firewalls; they would be completely redundant. That is not to advocate their elimination --- they protect from mistakes --- but to dilute their importance in peoples' minds. Firewalls are first-line measures only; no more.

VPN access

Here's another big problem which doesn't have any easy fix: the use of Virtual Private Networking to connect an outside entity to our system.

In short, a VPN allows a host from an external network to be a virtual extension of the internal network. That is, logically speaking, the external host is for all intents and purposes not external, and has all the same abilities as any host on the internal network. In reality this is done by proxy: a gateway machine (the VPN server) which is actually on the internal network establishes a tunnel through unprotected networks (like the Internet) to the remote system (the VPN client), accepts packets on its behalf, and relays packets there from to the internal network. This is all done transparently to the end user system, and they appear to actually be on the internal network to both themselves, and internal parties (only the VPN gateway knows the difference).

This is all well and fine, but think about how this works. The VPN client is not actually connected to the internal network, but instead, to the network of its Internet Service Provider (ISP). Now because the system is located "virtually" on our internal network, this means that anyone that has access to the VPN client, has access to our internal network as well. What we have done now is to reduce the security of our entire internal network to that of the single VPN client (indeed, to the least secure of all connected VPN clients). Many of these clients are unpatched home systems that have no firewalling, have insecure default configurations, no access restrictions, and run circa 1998 code that has years-old security holes.

Not only do we have to maintain internal systems and make sure they're patched and configured properly, but now we've taken on the same responsibility for each and every VPN client system.

Even when not VPNned, the cracker could -- for instance -- take over the machine and install keypress-sniffing software that transmitted to a site under her control. When a VPN user types his password to a company web site, presto, the cracker doesn't even need to enter your PC at all and can now stage an attack from elsewhere.

This is just plain scary, and really demonstrates well that security has a completely inverse relationship to access. We could disallow all access, but then what use is our data system?

Instead any feasible strategy has to approach security from the opposite direction: instead of one big layered ball of security with all the jewels at the center, we must instead protect each jewel separately and have no inter-jewel trust. Each component of the internal network should be able to withstand a directed, wide-open attack. Only these layers, already secure by themselves, can then combined into a multi-layered security barrier.

In the specific case of VPN, we can never hope that people will magically maintain their systems and keep them patched (or even magically do a "windows update" daily) no matter what incantations are used. We have tried forcing the use of personal firewalls on VPN clients which mutually exclude connections with the VPN and connections with anywhere else, but have invariably met resistance and even outright, unabashed violation. Probably the only solution to this problem is to completely disallow the use of VPN software, but it seems to be quite heavily utilized and allows greater productivity by enabling remote access.

We must secure the internal network completely if we want to allow VPN, and try our best to educate people about the dangers of VPN.

Firewall holes

The firewall rule set is designed to let in packets for services that we have chosen to expose to the outside world. Even assuming we had absolutely perfect security everywhere else, we would still be vulnerable to attack at these access points. Usually this means server software which serves up protocols we want to be accessible to employees externally, such as the mail server.

However, no software is infallible, and no code is bug-free, and in any case, the server software is only the end recipient of the data; the entire protocol stack is still vulnerable to attack at each level. This happens through programming mistakes and oversights, assumption of benign input, unmaintained or unregressed code paths, or misconfiguration of the server software.

The following basic guidelines, in addition to those already outlined for generic systems, should be followed for server systems:

  • Server software which is externally accessible should be secured: making up to date, performing exhaustive tests, and scrutinizing configuration.
  • Make sure that the entire server host cannot be compromised if the server software is compromised. This means running with only the necessary set of privileges, setting up a restricted jail environment for the process, making data read-only (even physically through media selection), et cetera.
  • Only take inputs from the least-inclusive subset of systems which is possible for the server to operate. For example the internal mail server only speaks to the outside through the external mail server, and vice versa. These are both explicit IP source/destination address restrictions at the firewall between them, and on the hosts (remember, assume security compromise of any system you are communicating with).
  • Make sure the server can't talk to hosts it will never have to talk to; this protects other systems, as well as the server system itself, by limiting exposure.

Again, to summarize, firewalling is not a panacea, and in fact is probably the opposite. Ask yourself if you would be comfortable running the system outside the firewall. Only when you can answer "yes" to that question should you run it inside the firewall.

Firewall Fallibility

All this talk about firewalls, and we're really inflating their egos. In fact firewalls are programs just like any other, are subject to all the same limitations, and prone to all the same errors. Because of their role as gatekeepers, they are also the most highly scrutinized --- by friend and foe alike --- and the focus of the most concerted efforts to circumvent, bypass or penetrate.

At annual security conferences, industry leaders and newcomers alike have in many instances disclosed vulnerabilities in firewall software that allowed attackers to tunnel arbitrarily through firewalls, and even to gain control of the firewall itself. These attacks exploited a variety of mistakes, including programming errors, configuration errors, insecure defaults, authentication weaknesses, poor encryption algorithms, et cetera.

There's two important issues here to note:

  • These attacks are usually known to an elite underground cracking community long before they were released to the general public or the firewall vendor. This means they were actively in use exploiting systems before administrators had any idea about the problem.
  • If we ourselves do not closely follow vulnerability tracking lists and instead just rely on the vendor or upstream community, we might know about these problems long after it is important to fix them (i.e., after our network has been cracked).

At the time these exploits are released, vendors of their respective firewall softwares are thought to be the "state of the art" in network security, and in many cases were thought to be the leader in providing secure firewall implementations. This goes to show just how fragile the dependence on a firewall really is, and how even people that know what they are doing (and base their whole company on this fact) make mistakes.

Here again we see that firewalls just can't be perfect; they are software, and there is no such thing as bug--free software. We should always assume the worst-case when planning for the security of our data systems. If a firewall is relied upon for data security and no other precautions are taken, this is really asking for trouble. Even if firewalls were perfect, there's still no guarantee that the administrator does not make a mistake configuring it.

When securing systems, pretend the firewall does not exist.

Did you read that sentence?

Data Leakage

The final route for information leaks that we will examine is real leakage of data: information leaking to an external data system when it wasn't intended to be. In today's world this is quite simply done by taking control of any systems -- or services on those systems -- along the path from sender to receiver, but outside our own data system. Have you recently checked email from offsite without using encryption? How about sent email in plaintext without using a tool like PGP to encrypt and sign your data?

This author can count 14 hops from his home ISP to the company network. And those are just the systems that we can see using conventional ICMP timeout tracing. Also keep in mind this is between two geographically similar points; a road warrior's packets travel through their local point of presence, over backbone routers, through the local carrier's access point, and on through to the end system. Additionally, there could be many systems along the way doing address translation, internal routing, etc. which are never seen.

A compromise of any one of these systems leaves our data exposed. Not to mention a whole host of other attacks (such as DNS cache poisoning, malicious source routing, etc.) which can cause our packets to take a route through the attacker's system. He can sit invisibly in the middle of our communications path and eavesdrop on all your packets (and you can even think it is secure, hence the need for complex authentication mechanisms in addition to encryption).

If the reader does not think this happens she is choosing to be willfully ignorant of history; this happens every day and we do hear about highly publicized events.

The best protected network in the world is useless when data is routinely (if benignly) leaked to the outside world by trusting third parties to carry the data.

Response

This document describes some specific areas where our Information System is weak and should be audited and replaced. Our Information System is confronted with not only infinitely varying possible threats, but several specific known threats (social engineering efforts by our competitors), and at least one case of a known, successfully completed attack on our Information System.

In order to thwart future attacks -- in addition to a full audit of our Information System and specific technical changes -- a comprehensive attitude adjustment needs to take place in the minds of all employees of our company. This will involve education, institutionalization of sane practices, heightened awareness of security threats, increased concern and importance placed on the security of our data, and willingness to use secure access tools

Most importantly, however, is to abolish reliance on the firewall as the sole provider of all security provisions. This is the single most important thing which must be done to secure our systems. Far too much importance, trust and reliance is placed on the firewall. Internal systems are too often classified as secure or otherwise not warranting security measures simply because of their location in the network topology. This view needs to be sought and destroyed; a firewall is a firewall, and no more. It is not a panacea and should not be treated as such. Because so many ways to get through even the most wonderful firewall exist, the security and vulnerability of internal data systems needs to be taken just as seriously as those that are external.

The set of information inputs and outputs to our data systems can be known, controlled and restricted within reason, but never completely. It is this author's sincere hope that this fact if not any other was communicated to the readers of this document.

Because there will always be something that is not accounted for, holes in thought-to-be-secure software are always popping up and a mad dash made to fix these holes, we can never have complete "security." It is not possible for us to ever create impenetrable barriers to our information and a clever enough attacker will always be able to gain access to our data.

We can, however, seek to limit the damage which can result from the certainty of eventual intrusion into our systems, prevent leakage of information which can be used to gain entrance to our systems or escalate privileges, stop accidental leakage of information and to restrict insiders from unauthorized access to data.

As the (ostensible) keepers of the Information System, we implore management to thoroughly consider these points, call for audits, institute awareness campaigns, and impose suggested security measures.

Thereby, our company's information can be kept safe.