What your employees know about your business may be of strategic value and provide that competitive edge.  It may be the special sauce that took the company years to develop and it may walk out the door prior to any exit interview or tender of resignation.

Recent surveys, media reports, prosecutions, and our investigations show an alarming number of ex-employees stealing company data, including when changing jobs.  Compromised data may include customer lists, contact information, know how, and other forms of intellectual property.  The majority do so in order to benefit in some financial arrangement or assist with a new job.  A recent theft of a proprietary trading platform at a major Wall Street financial institution is under investigation.  The platform enabled the firm to generate millions of trading profits each year.

There is a growing pervasive sense of entitlement to works for hire. Access to computers and technology without appropriate controls makes such theft inviting and simple for those inclined. How these thefts occur and remain undetected for extended periods of time has much more to do with the lax protective measures in place within the organization then the skills of the perpetrator.

In our investigative experience we have seen far too many cases where there is employee theft, limited binding agreements, no procedural or technical controls or measures, and far too much blind faith and trust extended to those who are not trustworthy.

Forgive me if my experiences make me appear cynical but I have seen thieves rob charities, business owner’s life’s work compromised by over zealous employees, and organizations hobbled and made vulnerable by employees gone bad.

Too often the lack of detective measures, extended periods before suspicion and investigation, further compounded by the lack of protocol in disengaging employees compromises critical evidence.  Lacking sustentative evidence, it is increasingly complex and costly for the organization to pursue justice in what may have been otherwise a clearly defined case.

Organizations must take comprehensive controls and measures seriously to avoid a potentially devastating event precipitated by a individual to which the organization has extended its trust.  This starts with the appropriate legal, technical, and procedural controls from engagement through discharge, employer beware.

To understand why this is so, let’s look way back through the mists of time to a different epoch, to the early nineties when Bruce Springsteen was still making hits, Grunge was hitting its stride, and some of us dedicated ourselves to the crazy antics of those kids in Beverly Hills.  Before the early nineties, when I deployed my first corporate “Internet” connection and “firewall” (router with an ACL), few corporations had Internet connectivity.  What connectivity there was generally consisted of some point-to-point leased line connectivity; perhaps some dedicated frame relay, X.25, microwave, satellite links and often banks of modems for dialup.  The vast majority of these connections were internal to the organization, generally connecting remote facilities together, occasionally for special business partner connectivity, and for support staff and remote access by at-home workers.  Generally there was no service provided to the general public, everyone who connected to us was a known entity.  Those connections to outside entities were dedicated to special application, often simple messages, such as automated re-ordering from a MRP system between customer and suppler.  All the connected sites were considered trusted; there were no concepts like DMZ.

Then came the Internet, web sites, services aimed at the unwashed masses of Internet connected pubic.  Providing services to those entities who were completely unknown to us.  Cheswick and Bellovin’s landmark work “Firewalls and Internet Security” (Addison-Wesley , 1994) documented and cemented the concepts of the Internet perimeter, DMZ networks, and the placement of firewalls.  This work and the thinking of the time followed the paradigm of “us vs. them”.  This was probably appropriate for the time, back then many corporate network infrastructures did have something that could approximate a perimeter, a point or set of points on the network on one side of which all network connections were trusted, on the other side of which they weren’t.  That often amounted to the Internet on the outside and everything else on the inside.  But times changed, and the perimeter has slowly blurred to the point, in many organizations, where it simply doesn’t exist any longer.  How did that happen?  Let’s consider some of the services and connectivity most corporations now provide on their networks.

One of the biggest drivers for the blurring of the perimeter is the use of VPN technology.  For site-to-site VPN this essentially connects two remote networks into one.  In many cases this is easier to secure as a control can be applied to the single point of connection.  Client VPN is a different story.  Often provided for remote workers, ROHO/SOHO, remote and after hours technical support, vendor access, this provides a direct network connection between a remote workstation and one or more systems on the corporate network.  Due to the way it proliferates, it becomes much harder to control, as it has to be done on a host by host basis.  However as a corporation you generally have very little control over the machines at the other end of the connection.  For example unless you are providing workstations with locked down images you have only a modicum of control, and even then it isn’t fool proof.  How do you prevent remote workstations transmitting virus or worm code?  What about remote tunneling where the remote workstation acts as a router for other Internet traffic?  What if the remote machine is part of a Botnet or is otherwise “owned” and has remote command and control software on it?  Finally there is the issue of management of the remote users.  If this is for vendor support, does everyone at the vendor have a single username/password?  How do you get plugged into the vendor HR processes to manage account and passwords when there is turn over?

Even worse than VPN is the “Reverse VPN” type of service by vendors like GoToMyPC where individual internal users can setup their workstation on the internal network to make outbound connections which are then used to command and control the internal machine.  These services have all the same problems as with VPN, and this is even harder to control.  Even a proxy won’t work if the data stream is HTTP compliant.  Some you may be able to control with IP address filters, but not all and especially the deliberately malicious ones.  Try Googling “reverse www shell” sometime if you need something to keep you awake at night.  Various browser based, virus, and other exploits deliver remote command and control software that makes outbound connections.

Infrastructure and the deployment of applications and services can also blur the perimeter.  For example systems in a DMZ network that can make inbound connections to networks of higher trust levels can provide a route inbound for malicious traffic.  Consider how your DMZ application layer systems access back end databases.  Or how webmail machines are accessed (Outlook Web Access is a huge offender).  Another huge offender is Blackberry Enterprise Server.  This remotely accessible system, which has had numerous issues in the past, and which can provide remote access capability to mobile computers (Blackberries) is frequently on an internal trusted network.  Wireless networks can extend your internal network a mile or more depending on your equipment and the use of remote login services over the Internet potentially extends your corporate network across the globe.

There are many more examples of the blurring of the perimeter, hopefully these few have at least conveyed the message that focusing on securing the perimeter, while important, is not the complete solution.  A good exercise to determine if you might be relying on perimeter security too much is to print out your network diagrams, point at a system and say “That machine is compromised, now what?” Or ask yourself what happens when a vendor’s network is compromised and they connect to yours.   Remember (gratuitous Matrix reference) “Do not try and secure the perimeter.  That’s impossible.  Instead… only try to realize the truth….There is no perimeter”.

There is a pervasive, and fallacious, belief that the Internet is some sort of wild middle-ages like kingdom full of marauding Huns and Visigoths but that once we are behind the fortress walls (firewall) all is peace and safety.  Nothing could be further from the truth.  In fact as I often tell clients, your corporate network is less secure than the Internet.

To understand what I’m talking about it’s important to stop thinking in terms of the castle walls and the barbarians outside (although perhaps it’s not such a bad analogy in that as many castles fell from treachery and internal attacks as from direct assault).  It’s important to stop assuming that anyone connected to our internal network, e.g. our employees and possibly vendors, are trustworthy.  Recent studies have shown that a high percentage of IT workers (effectively the holders of the crown jewels in many companies) regularly access data inappropriately and that all types of staff members regularly steal data when they move on to another job and the news is full of stories of DMV, bank, or hospital workers selling personal information.

Frankly, there isn’t a company in existence that doesn’t have at least one disgruntled employee.  A rogue in the user community is bad enough, but when that employee is a system or database administrator it can be fatal.  Even if you are that one company where everybody is happy, studies have shown humans are incredibly creative in circumventing security controls they feel are onerous, and that might open the door to real attacks.  Then there are browser based attacks, some of which can provide an external attacker full command and control access to workstations on your internal network.  I will leave the issues of VPN and partner/vendor connections to another discussion, but these things can significantly blur the distinction between what is inside your castle walls and what is not.  The upshot is, even the devices plugged into your own network must be considered potentially suspect.

Due to the way the Internet is constructed, how traffic is routed, and the vast amount of data flowing, it is practically impossible to just “jack in” midstream somewhere in Internet-land and capture a specific communication or even communication to or from a particular host or network.  Even if the malicious Visigoth is an employee of an ISP or backbone carrier this task would be momentous.   Not so on your typical corporate network.  Hubbed networks, which send all traffic to all ports, are obviously bad, although most of these have been replaced.  However, most corporate networks have at most two security levels (DMZ and Internal) and a few VLANs on a shared switched fabric.  There are plenty of attacks against switches ranging from the crude, simply turning switches into hubs, to more sophisticated attacks that can pin point specific hosts and even connections and use moderately sophisticated (but still point and click) tools to intercept, monitor, or even insert commands and data into the communication.  These tools and techniques make every RJ45 in the office a potential place to sniff or modify data.  Even SSL may not be safe.

Now consider detection of malicious activity and response to it.  Most ISPs, and certainly all the major ones, have monitoring in place for large scale malicious traffic.  Anomalous traffic is watched carefully, and information is regularly exchanged with other carriers to enable threat updating and management of the bad guys.  Wide scale malicious traffic can be blocked, slowed, rerouted or otherwise dealt with based on pre-established protocol and leveraging pre-established relationships with law enforcement, other ISPs, and the security community.   These organizations have well developed and tested incident response plans, team members have been trained, and tools are provided.

Many businesses however do very little effective monitoring of anomalous traffic on the network.  At best there is a poorly placed and implemented umbrella IDS sensor.  Following the “barbarian at the gate” mentality this is typically located at the Internet or DMZ boundary, where it wouldn’t catch any internal issues anyway, and configured so that it becomes ineffective, a noise generator, and is eventually ignored.  While many excellent sources of monitoring data exist in the infrastructure, including logs from switches, routers, servers, and applications, they generally aren’t collected centrally or analyzed except possibly for performance and troubleshooting purposes.  In many cases they don’t ever leave the device that generated them, placing them directly at risk of modification by any attacker.  Without detection, incident response becomes almost moot.  But many businesses have no Incident Response Plan, or what they have is boilerplate, untested, and out of date.  Teams have not been established, or are poorly trained and have no dedicated tools.  What I find fascinating is that many of these organizations have solid, well tested and documented disaster recovery plans.  When I ask my clients to pull out their DR plan and lay it alongside their Incident Response plan the differences are clear.  When was the last time a DR test went perfectly after a major system or network change?  So why would you expect an untested Incident Response plan to be effective without testing and training.

So next time you hear about the big bad Internet and the swarming masses of attackers, start considering how many are on your corporate network.