8 Years since the Eastern Seaboard Blackout - Has it Been that Long?

Published: 2011-08-15
Last Updated: 2011-08-17 10:07:21 UTC
by Rob VandenBrink (Version: 1)
3 comment(s)

 

The Eastern Seaboard power blackout that occurred in 2003 (started at 4:10 on Aug 14, 2003, with the recovery varying by region) was a milestone in many of our lives. Not only was it full of personal consequences - I can remember my wife calling me in a panic as I was driving home, but it had some severe business and societal impacts, and changed how we view service interruptions in IT.

The blackout forced many businesses to seriously consider what an interruption in basic services could cost the organization, and also to consider how to do business without various services.  In short, we now do Disaster Recovery Planning (DRP) and Business Continuity Planning (BCP) a lot more, and a lot more rigorously than we did pre-2003.

The blackout also forced us as a society to consider just how critical our "Critical Infrastructure" is, and how long it had been since it was last looked at closely (post WWII in a lot of cases).  It also forced us to look at security in a whole new light - the electrical grid had been built on a "we trust our neighbours" model, which was one of the root problems that made the 2003 event so wide-spread.  Most utilities are now a lot more self-contained, or at least aware of the "good fences make good neighbours" design approach these days.

We're a lot more aware now of just how complex our utility infrastructure is now, we've seen first hand what happens when the power goes off, and how complex it was to get the power back on after a widespread hit. 

While NERC (North American Electric Reliability Council) has been around since 1968, the power outage was one of the catalysts in re-formulating it as The North American Electric Reliability Corporation, and re-writing the Critical Infrastructure Protection (NERC CIP) regulations in 2006.

Above all, to me the 2003 blackout illustrates just how short our memory is.  We had a power hit that affected New York City in 1977 (which I remember), and a much larger Northeast area event back in 1965 (I was 3 then, so before my time).  I guess as a society we're a lot like my cat - bad things need to take place a few times at least before it sinks in.  Hopefully, now that we've got critical infrastructure standards and particularly security written into regulations and law, it'll stick.  Also, now that we've got some momentum in BCP and DR planning, the private sector will follow along.

We'd love to hear your comments, either from your experiences during any of the larger power problems, or how they've affected your organization.



 

===============

Rob VandenBrink
Metafore

3 comment(s)

How to find unwanted files on workstations

Published: 2011-08-15
Last Updated: 2011-08-15 06:36:24 UTC
by Mark Hofman (Version: 1)
16 comment(s)

A few weeks ago I was asked to check every single workstation in the organisation for unwanted files.  The types of files I was asked to look for were media files such as music and video, but also torrent files. The main objective was to identify breaches of policy and to allow removal of the unwanted files from the network.  I will take you through what I did, which achieved the main objective relatively painlessly. Undoubtedly  there better methods than what I'm about to describe and in fact I'm kind of counting on it, so feel free to share how you deal with the challenge.  In the mean time this is what I ended up doing.

I obviously didn't really want to visit every machine in the organisation and search the hard drive. Junior has been good lately, so sending him wasn't an option either. The first challenge was to identify the machines currently on the network. Being a windows environment, I considered using dsquery to grab the machine names from AD, but that didn't really work out nicely as the company has computers in all different kinds of OUs. WMIC also had similar limitations and Powershell, well let's just say I'm no Ed, Hal or Tom.  I chose the easy option and used nmap.  Convenient in this environment as the workstations are quite separate from the servers on their own subnet. The following nmap  command does a quick ping sweep and places the results in a grepable output file.

nmap -sP <ip-range>/<mask> -oG <filename>

The the grep output from nmap looks as follows :

Host: aaa.bbb.ccc.20 (machine1.domain.com)    Status: Up
Host: aaa.bbb.ccc.45 (machine45.domain.com)    Status: Up
Host: aaa.bbb.ccc.62 (machine62.domain.com)    Status: Up
… snip ...
Host: aaa.bbb.ccc.100 (print01.domain.com)    Status: Up
Host: aaa.bbb.ccc.101 (print02.domain.com)    Status: Up
Host: aaa.bbb.ccc.102 (machine102.domain.com)    Status: Up
Host: aaa.bbb.ccc.115 (machine115.domain.com)    Status: Up
Host: aaa.bbb.ccc.150 (switch01.domain.com)    Status: Up
… snip ...

From the list I culled those devices that I was not interested in, e.g. the printers and the switch, before building the commands and creating the batch file.

To do the heavy lifting I used psexec from sysinternals, which allowed me to examine all the machines from one central machine. To create the command and resulting batch file I edited the output file from the nmap.

  1. find and replace Host:  with PsExec.exe 
  2. find and replace ( with -w  C:\ cmd.exe /c "dir *.mp3 *.avi *.mkv *.mov *torrent* /s /b " > audit-
  3. find and replace domain.com with .txt
  4. find and replace ) Status: Up with <blank> (i.e. clear it out)


What you end up with should look something like this for each of the entries in the nmap output file.

PsExec.exe aaa.bbb.ccc.45 -w  C:\ cmd.exe /c "dir *.mp3 *.avi *.mkv *.mov *torrent* 
     /s /b " > audit-machine45.txt

Save the file as a .bat file extension, make sure psexec is in the path of the user who will be running the batch file.

What will it do?  The command runs PsExec on the IP address, issues the command dir for those extensions listed and outputs the info in a local file called audit-<machinename>.txt.  Because we are using a standard dir command you can easily look for any kind of file you like, or partial file names.

Each of the output files will look something like this

C:\Documents and Settings\jdoe\
Desktop\MUSAK\The Police\Greatest Hits\11 - The Police - Spirits In The Material World - Greatest H.mp3
Desktop\MUSAK\The Police\Greatest Hits\12 - The Police - Synchronicity II - Greatest Hits_120113005.mp3
Desktop\MUSAK\The Police\Greatest Hits\13 - The Police - Every Breath You Take - Greatest Hits_1201.mp3
Desktop\MUSAK\The Police\Greatest Hits\14 - The Police - King Of Pain - Greatest Hits_1201130115.mp3
Local Settings\Temporary Internet Files\Content.IE5\HKNBKI0L\novotelrestc[1].mov
My Documents\private\vids\SouthPark DVDiv\X 809-814\813 - Cartman's Incredible Gift-AERiAL_mrtwig.net.avi

Someone will need to inspect each of the result files and check to see if the materials are permitted to remain on corporate machines or whether they should be removed.  Sometimes the owner wil not be obvious and you might need to examine the machine a little bit closer to determine the owner of the files. Once unwanted files have been identified I usually send the person a policy reminder and a request to have the materials removed.  Second/third/nth offences however are passed on to the appropriate area to deal with.

To give you an idea of the effort involved for a site of 400 plus machines (about 325 up when checking).

  • Running the nmap - 15 minutes,
  • Culling undesirable devices and doing the find and replace commands - 15 minutes.
  • Running the batch file - 2 hrs.
  • Checking the results - 1 hour,
  • Sending the emails - 30 minutes (will obviously depend on how much you find I ended up sending 15). 

All in all a reasonably straight forward process and easily adapted to different file types, or file names.

There are some limitations. The user running the psexec command must have privileges in the environment and the machines being checked should be part of the domain. Although you can pass alternate userid and passwords to the command if you want to.  You will leave a user profile directory behind on the machine being checked. Only those machines accessible when the batch file is run will be checked, but you could make this part of a login process and write the results file to a network location instead.

Quick and dirty I know, but does the job.  How do you find files on your network, including workstations, that should probably not be there?

Cheers

Mark - Shearwater

PS the diary editor seems to strip slashes so if it looks like there should be a backslash, you are probably right.

Keywords: unwanted files
16 comment(s)

Comments


Diary Archives