Securing Corporate Data

Tailoring E3 technology to specific needs.

Get It Try It

Security and privacy are equally important matters for both the corporation and the individual yet for the individual privacy's been on the back burner for a while. Ever since the Love Bug hit in May 2000 punters - especially on Windows - have been obsessed with security and they've forgot about privacy. Every once in a while a story emerges about someone's hard drive turning up halfway across the globe or a bunch of old PCs donated to charity with full identities intact in files on disk. But people don't have time to worry about privacy. They may prefer not worrying about it. But they should.

Corporations have to worry about this all the time. They worry about security too but privacy was never off the table with them. Most importantly corporations need bespoke systems for privacy. You can't just take a 'web washer' off the shelf and guard against espionage.

Ordinary punters reckon privacy is a cinch. Just download some simple minded app (and hope it's not a trojan) and click on a few tabs and tick boxes and you're all set. And the snake oil salesmen out there aren't going to do anything to break the bubble for them. But things aren't that simple, have never been that simple, and guess what? They're never going to be that simple either.

First off: privacy software is never going to know what's sensitive. Software can't read your mind. It can't - and should not - try to guess from the names of files if you want something gone or not. And it shouldn't use the Google algorithm - in use only in the US naturally - to count the number of flesh coloured pixels to make an educated guess whether images are porn. No: you have to tell a program what you want to remove. Countless suckers who've been scared into the Evidence Eliminator trap assumed all they had to do was run the program and they'd keep the FBI away from their doors. Poor fools.

Second: most of the simplest tasks such as removing cookies and web caches are things your web browser is going to do anyway. Buying a privacy tool to do these tasks is downright stupid. Clicking around on a program menu (it takes but one finger and very little advanced thought) is all you need to access the routines already there for your benefit.

Third: a clean machine is also a machine that helps keep your secrets intact. Leaving junk around at any time is a bad idea. People who leave sensitive memos on diner tables, in insecure areas; people who let themselves be eavesdropped; people who quite simply put can't remember where they've put things: these people are asking for it.

If you're on your own: you need to control your own computing environment. If you find yourself saying 'I can't remember where I put that file - I don't think it's on my hard drive so it must be on my desktop' - then you need to take a crash course in IT by yesterday. You're so hopelessly clueless you're a disaster waiting to happen.

Farther down the line you have to understand a bit of how ordinary applications leave remnants behind and why it can be a good idea to scrub your disks from time to time.

And finally you have to understand that no process is final, that all privacy safeguards are iterative - in other words you have to 'keep it up'. You have to do it regularly. Something like brushing your teeth. You clean your system regularly. Perhaps several times a day. Possibly by setting up automated tasks.

For the corporate admin the domain is similar, a bit more complex, but ultimately as the admin is a professional somewhat easier to manage. The admin has to establish routines for all computers in his organisation - routines that work as much as possible no matter what the users feel, say, or do. He has to automate things so he protects the corporation from its own employees. In other words he needs automated routines the employees have no choice but to run. As part of a login process or whatever. As much as possible. Relying on people performing these tasks on their own - in other words outsourcing one's own responsibilities - gets the admin a pink slip sooner or later.

No matter what the situation there has to be a collection of privacy tools flexible enough to adapt. Your run of the mill $49 'web washer' isn't going to do it.

The original E3 Security Kit - back then called the 'Evidence Eliminator Eliminator' - was an attempt to counter the hype and scare sell of one of the most spammed products in the history of the Internet. The shameful way this sordid and incomplete product was marketed set new records. The first E3 releases duplicated Evidence Eliminator not only in appearance but also in design - and that wasn't a good thing. It might have looked grand to the child pornographer scared shitless the heat were going to bust down the door but it made no sense to the calm astute user. And certainly not to the professional network administrator.

Subsequent versions of E3 came about through the arduous process of literally ripping all the code up and starting from scratch. And not using internal functions to arbitrarily take care of one or another privacy target. Instead a completely scriptable metalanguage was built up. And it's this language E3 reads. The E3 recipe files are actually scripts fully comparable to shell scripts or Windows batch (BAT) files.

The Se7en Areas

Pursuant to creating a fully comprehensive scripting language for E3 was a study of exactly where the things E3 wants to remove can reside. In this respect a Windows system is far more complex than other more elegant operating systems where there are files and little else. Windows has in fact exactly seven nooks and crannies where compromising data can hide. Put another way: there are seven sovereign actions one might call on E3 to perform.

1. Contents of a directory. This to be distinguished from a directory itself as there is one case on a Windows system where you must never remove a directory itself - only its contents. This is the system's official 'temporary' directory for temporary or 'scratch' files. The system APIs for creating files in this directory do not take into account the possibility this directory may not actually exist. Surely they could - it'd be easy enough - but the fact is they don't. There must therefore be a special operation for this purpose.

2. Directories. By this is meant directories and all their contents - recursively. Once a directory is empty it is also removed.

3. Files. Self explanatory.

4. Registry keys. A Registry key is the equivalent of the hard drive directory (and follows the same rules). And Registry keys have contents fully equivalent to what directories on disk have. Removing a Registry key removes all its contents and then removes the key itself.

5. Registry values. Registry values are the equivalent of on disk files. Removing a Registry value removes all its contents and then removes the value itself.

6. INI file sections. The archaic INI files have linearity where the Registry has a full hierarchy. INI file sections are the equivalent of Registry keys but cannot be nested. Removing an INI file section removes all its contents and then removes the section itself.

7. INI file entries. INI file entries are the equivalent of Registry values and thus of on disk files. INI file entries have values comparable to Registry data or the contents of on disk files. Removing an INI file entry in a specified section in a specified INI file removes both the entry and its value (its data).

Paths to All

Given the above domains it is possible to construct a syntax for expressing a 'full path' to any of the above - given that a prior indication is given of which of the seven types is being used. Some examples.

1. C:\WINDOWS\TEMP
2. C:\Program Files\<DIRECTORY>
3. C:\Program Files\MyApplication\Files\<FILE>
4. HKLM\Software\Vendor\Product\<KEY>
5. HKLM\Software\Vendor\Product\Key\<VALUE>
6. C:\WINDOWS\WIN.INI\<SECTION>
7. C:\WINDOWS\WIN.INI\<SECTION>\<ENTRY>

In each of these cases the parser, already knowing the type, can figure out what's what and where it goes. The final component is always the target and as the type is already given the parser can know what it's looking at. In some cases the parser is also going to assume the next to last component is also something special; but this is trivial to compute.

Scope

It's also possible to see these seven types in terms of two distinct scopes. Some operations would like to scour the hard drive (or the Registry) for a distinct file or Registry key. It should be possible for example to scour the entire Registry for instances of 'MRUList' or 'LastMRU' or whatever's in vogue so as to remove lists of recent files accessed. Doing this through the above scheme would involve also using a global rather than a specific identifier.

5. **GLOBAL**: HKCU\MRU List

In this case the E3 engine recurses through the entire HKCU hive in search of recent lists - and eradicates them.

All in all this gives us not seven but fourteen different target types. Divided of course into seven types with either global or specific scope. It's therefore possible to eradicate all 'BAK' files in one fell swoop - just tell the system where to start and it will recurse from that point and find, remove, and optionally shred them.

Multiple Targets

A way the more pedestrian tools available lose out is through their lack of proximity to the file system. There are namely APIs for searching for any number of things all at once. Comparing strings in memory - even using regular expressions - takes no time at all but scanning a hard drive over and over for one search expression at a time takes years.

For example: in the harshest most merciless 'first clean' routine for E3 the following command starts things off.

*F**.---;*.!*;*.$*;*.~*;*.bak;*.bkm;*.chk;*.exp;*.fts;*.gid;*.idb;*.ncb;*.obj;*.old;*.opt;*.pch;*.plg;
*.res;*.tmp;Deleted Items.dbx;MSCREATE.DIR;netscape.dat

The first three characters indicate both the target type and the scope. In this case the type is 'F' (file) and the scope is given by the enclosing asterisks ('*'). After that one finds a fully legitimate search key for direct use by low level file system routines. Regular expressions in the array are separated by semicolons. Asterisks and question marks aren't necessary - MSCREATE.DIR and netscape.dat are evidence of that.

The 'F' is given in upper case as a further corroboration the operation is to be global: the specific file type uses the lower case 'f'. All target types are distinguished in this fashion.

What's important here is remembering where the bottleneck is. For example good old Evidence Eliminator lets you specify any number of file extensions to look for on disk - and then dutifully scours your entire system for each, one after the other. This of course takes ages.

Once a process has 'entered' a directory and can list its contents internally it's child's play to submit a comparison string such as the above for the file system APIs to deal with.

Considering a full run of E3 always begins with something similar to the above and that complete runs on relatively tidy boxes take but a minute or two at most it's easy to see E3 wins out over the competition by several orders of magnitude.

Standard Locations

Every Windows system has a number of standard locations. Unfortunately these standard locations are not static - they're language dependent amongst other things and their realtime values often kept in the Registry. Not using these 'variables' would be a big miss for any privacy tool.

The following are some of the standard locations in Windows with their E3 macros.

%T - temporary files. This is often C:\WINDOWS\TEMP but it's indeed defined by the system and as such should never be assumed by external software.

%C - the location of Internet Explorer cookie files. Again: this is configurable and so third party products should never assume things are the same on all installations.

%H - the location of Internet Explorer history caches. See above.

%I - the location of the 'temporary Internet files'. The actual web caches.

%W - the Windows directory. This differs from system to system. Its value may not be assumed (even though any number of short witted applications do it).

%S - the 'system' directory. May be 'system32' or 'SYSTEM' on older computers. It too is configurable.

By using macros E3 is able to provide scripts that work on anyone's computer whilst other 'web washers' - although perhaps not muttering a thing about it - will break.

Test Runs

You'll hardly find another privacy tool that shows you what it's going to do before it does it. E3 can not only log each and every thing it does - it can namely log all its actions without actually doing anything.

These log files are naturally excruciatingly (painfully) detailed but that's the name of the game - professionals have to be able to see what's going on. It's not a matter of troubleshooting software - it's a prophylactic measure to troubleshoot one's own E3 'recipes' before running them for real.

Again: E3 doesn't do anything on its own. The package comes set up with a standard configuration but E3 needs to be fed commands through its recipe file to do anything. This is naturally so the admin (or the adventurous punter) can configure an E3 run to a high level of precision. Being able to see in advance what is going to be done before it's done is an essential step towards honing one's own privacy routines.

File by file and line by line E3 states explicitly what's being read at what line in what file, prints the exact command as found in the file, translates the command into plain English, and then goes about finding the target. If the target is found E3 says so; if the target is not found (specific scope) E3 says so. If it's only a test run E3 will also say the target has not been removed (and not shredded). And so forth.

Especially for admins responsible for extensive networks with hundreds of workstations it's essential to peruse these logs for possible conflicts. The most accessible area of conflict is of course with file extensions. For example 'BAK' is commonly accepted as the domain solely of 'back' files but you might be surprised to find other third party vendors now wanting to appropriate it for their own use. A test run of E3 will produce a log that exposes these conflicts. A bad situation is avoided before it's had a chance to happen - something you wouldn't really want to risk with any other privacy product.

To Shred or Not to Shred

It's not always propitious to automatically shred target files when found. Shredding is a time consuming procedure involving 39 steps whereof fully 35 are shred passes. This is the Gutmann shred, claimed by some today to be 'overkill' but never to be 'not enough'. There is nothing short of physical destruction (incineration for example) which can better this type of shred.

The Gutmann shred involves a full eight passes of 'random' overwrites, four at the beginning and four at the end. Already here it surpasses what ordinary shredders do for you. And the lure of specifying any number of random overwrites is empty: it's not about bits and bytes at this level: hard drives are analog devices and do not adhere to the same digital rules as the rest of your computer. Which is where the twenty seven 'middle' passes come in. E3's built in SPX shredding engine is faster than you'd find in any other product anyway. The additional time needed to 'do it right' is negligible.

No - the real reason for opting out of an immediate shred of targets is you're planning to shred the rest of your disk immediately after. When files are destroyed their storage space is returned to the pool of unused resources; as things may have been written to these disk sectors previously it's crucial to shred them as well.

Files are written to disk sectors and for many reasons these 512 byte sectors are grouped together in disk clusters and the cluster becomes the 'atom' of file I/O. But files rarely fill this cluster storage to the last byte. Yet of course files previously using the same sectors on disk may have extended further than their current occupants. It's therefore imperative to get at these 'slack areas' as well.

Completing a disk cleansing therefore involves first removing unwanted files and thereafter scrubbing both the file slack and the disk slack. For each file found on disk - and of course this is a matter of thousands or tens of thousands - the file must be extended in size to appropriate the bytes remaining in its final cluster, performing a full Gutmann shred on this slack, and then returning the file size to what it was originally.

Once all files have been scrubbed in this fashion it's time to address the remaining disk clusters not in use. As the disk storage freed by removing files is going to be shredded anyway it's not necessary to perform this step twice.

Things are slightly different on a day to day basis. A typical user is not going to intermittently divert from ordinary job related duties to shred the entire hard drive. Instead individual files must be targeted for shredding.

E3 Wrappers

The easiest - the most automated - way to do this is through E3 wrappers. An E3 wrapper takes on the responsibility for being the interface between the user and a specific application to run; the user doesn't see a difference between this method and the 'ordinary' one. Whether it's double clicking an icon on the desktop or selecting a Start menu item: both the experience and the appearance are the same.

The E3 wrapper also contains a manifest: things to do when the target exits. The E3 wrapper is what actually launches the target application. Thereafter it sits there, consuming no resources whatsoever, until the target exits. When it's been notified the target has exited it begins its cleanup. The cleanup itself is specified in the E3 wrapper configuration file.

The E3 wrapper invokes the E3 engine to do the removals and shreds; it doesn't duplicate this logic. The E3 engine (E3 program) namely need not appear on screen to run.

And this is an important feature: E3 need not appear on screen. As it's fully scriptable there's no real reason to have the window there if it's not needed. And when configuring a network and hundreds of workstations it's a lot smoother if the individuals using these workstations never see the E3 Security Kit directly. If use of E3 is coupled to a procedure users cannot avoid then there's less 'outsourcing' of responsibility and the admin can know things are properly secured.

Routines can be coupled to any regularly occurring event: a login, a logout, or a task scheduler on a timer. E3 scripts can do anything at all within the realm of E3 - removing things from the system. Procedures can be established for scouring for junk files upon a network login and so forth. Anything can be done.

Case Study - 'CA'

Following is a case study of installing and integrating E3 into a larger network configuration.

'CA' was the contact for a major arm of the United States Department of Defense. His group dealt with extremely sensitive operations and data and CA had to find ways to protect this group from themselves and from outside intruders. Previously someone in the organisation had suggested Evidence Eliminator but for reasons too obvious this didn't work out. Thus CA's plan to deploy E3.

CA was acutely aware from the outset that his intentions no matter how noble would not be carried out if users were given responsibility. Things happen; CA could not be at all places at once; he couldn't possibly control everything everyone was or was not doing. He had to be sure they had no choice. He had to remain in control as far as possible.

Of primary interest to CA was constructing a 'ghost image' for use when distributing new computers. The image came with all E3 routines already set up and ready to run. These routines kicked in either at boot or shutdown or both or even in between.

In addition a special new utility was built for CA's group called 'E3 Nighttime'. E3 Nighttime is essentially an 'E3 Finalizer' for dummies - it requires almost no thought or interaction. It figures everything out by itself. All the user has to do - literally - upon launch is double click. Once.

E3 Nighttime was the solution to how to control users 'in the field' - in other words away from home. Again: this is not a situation CA could directly control. Here he had to rely on his ability to impress on the members of his group the vital importance of securing data. To this end the procedure he would ask these people to perform had to be so easy so as to not incur any discomfort - any resistance to use.

When group members took their laptops on field trips and spent the evening away from the office they merely set their laptops up on the hotel room desk, closed all other applications, launched the E3 Nighttime application, and double clicked once on its window. E3 Nighttime kicks in, scrubs all file and disk slack, and writes an activity log to disk when the operation completes.

This application was of course also necessary in the event group members took their work - and thereby their laptops - home for the evening. At all times CA had to know there was nothing more he could do to secure the group's secret data - that everything possible had been done, over and over again.

E3 Nighttime is now available to all clients as part of the E3 Security Kit.

When establishing privacy routines for a corporation it's essential the admin study where corporate computers can be 'forced' into situations with no alternative. E3 wrappers are a good example of this: the admin specifies exactly how applications are to be cleaned up once run - users do nothing at all.

The admin must also weigh these 'opportunities' against an approximation of the time needed to complete the desired operations. Having something running on boot is fine - as long as users regularly boot their machines. This can however delay the machine being accessible to the user. Having something run on shutdown might not impair user actions (away from the computer) but one must be certain users actually shut their machines down. Thus coupling an E3 run to an unavoidable network login can very often be the best way to go.

Get It Try It

Admins must also instruct users in the reasons and the need for data security. But with a series of transparent tools the difficulties for the individual user are kept to an absolute minimum and control of data is kept where the admins want it.

On their own desks.

See Also
Radsoft Gallery: E3 Security Kit
Radsoft Reviews: The Evidence Eliminator Eliminator is here!
Radsoft Products: E3 Security Kit