Supervision, again

This week I realized that I’m seeing a problem repeat itself over time and organizations. Today I realized that there is a broader application to the problem, and I’m beginning to think that there may be a solution to the problem. I say Supervision, again because I believe that automation without supervision is doomed to fail. In the end, supervision is a major part of the solution to this problem as well.

I have watched as companies deploy computerized control systems using traditional project methodologies and the local maintenance personnel or users take responsibility for the administration of these systems once the projects end. The degree and quality of administration varies with the people who do it and the amount of time that they are willing to spend on this new and additional responsibility. Most of the time this includes physical inventory, backups and maybe anti-virus software, but only rarely does it include patch management, recovery exercises, or performance monitoring. The company makes a capital investment (the project), reaps the benefits of the new automated controls (return on investment), and dodges ongoing maintenance costs by hiding them in existing maintenance infrastructure or failing to perform them entirely.

More recently a central authority from elsewhere offers to provide administrative services to the system in the name of compliance or security. They have a project (another capital investment) to install centralized tools such as backup software, anti-virus software, patch management systems, performance monitoring systems, and sometimes intrusion detection or log management systems. A consequence of the centralization is that all of these systems are administered by the central authority and the local maintenance personnel cannot easily supervise the effectiveness of the tools. In some cases the tools are not visible to the locals, in others the locals are not provided meaningful training about how to reach or operate them, and in yet others the locals are encouraged to spend their time elsewhere and to simply trust the centralized authority to handle the responsiblity of administering the control systems.

In my long career I’ve seen what happens when the centralized authority fails to meet its responsibility for whatever reasons. A switch dies and the locals discover that a spare was never provisioned. A computer fails and we discover that the database wasn’t backed up by the software. A virus infects a computer and is reported to the centralized console, but nobody took action on the alert in time to prevent damage. Even when the central authority does perform some of the tasks it rarely helps to solve the problems that arise; and now the locals are trying to fix a reported problem that they do not understand using skills that they haven’t been trained to have with time that is borrowed from their full-time jobs.

In a similar way I am aware that some Owners hire Infrastructure as a Service (IAAS) providers and Managed Security Service Providers (MSSPs) to provide administrative services and later find that they were billed for services that weren’t performed completely, or were inadequate for their needs. The owner is responsible for their assets from beginning to end and can only delegate authority to others to help manage that responsibility.

In the end, the Owner is responsible for administering their cyber assets. When the Owner delegates authority to others, either internally or externally they are still responsible to ensure that the responsibility is met. If the Owner is not technically capable of supervising their delegates then they can delegate that authority to a third party and still meet the responsibility.

Local maintenance personnel end up in a curious place; when the systems fail they are personally responsible for repairing them. I have rarely seen a CEO or senior manager at the plant on a midnight shift, a weekend, or a holiday when the repairs are ongoing. Perhaps management pays a price in money, but this is significantly different than spending one’s personal time as the price. This harkens back to discussions about why a personally written Thank You card can mean more than an electronically transfered check.

Part of the solution is for the Owner to establish a Program to administer computerized control systems, to staff that Program adequately to meet the requirements, and to provide projects to enable everyone manage the program and any repair events. These projects may be to provide tools or to provide training. Part of the solution is for the Owner to supervise the Program to ensure that it is effective through a combination of audits and exercises.

DSL and VMWare

Today I’ve been struggling to remember how I once built a DSL guest in VMWare Fusion / ESXi.  DSL is a darn small Linux distribution that can run in 100 MB of storage.  Here are the tricks that I’ve relearned in order to make this work.

  • DSL v 4.4.10 requires VMWare hardware version 7.  Higher versions somewhat work, with the primary symptom being no mouse support.
  • To access root functions, enter a terminal session and then run sudo su.  There is no password, simply the command.
  • The virtual hard disk drive must be IDE (not SCSI).  DSL doesn’t seem to have other drivers.
  • Having booted from the ISO on CDROM, you must prepare the virtual hard drive using cfdisk /dev/hda. Begin with a zero table, and partition as follows:
    • Select New
    • Select Primary
    • Accept the available space, unless there is reason not to.
    • Highlight Bootable
    • Highlight Type, then choose 83 (Linux)
    • Choose Write, then follow the prompts.
    • Quit, then reboot.
  • Boot from the ISO; launch a terminal window and execute dsl-hdinstall
    • Use the target partition hda1
    • Do NOT support multi-user logins or the journalized file system
  • You may want to reboot one more time without the ISO available to verify that all is well.
  • If you want to make the swap space on a second partition, follow these steps:
    • Using cfdisk /dev/hda create the partition, same as above only type 82
    • swapoff -a
    • mkswap /dev/hda2
    • swapon /dev/hda2

Network Monitoring Tools

Today I’ve been watching an AlienVault webinar about how to use their product, and caught a glimpse of Nagios and the Paessler NetFlow simulator.  For years I’ve worked to build systems with adequate monitoring to provide either early warning of imminent problems or to provide sufficient forensic evidence to aid in incident response.  My earliest tools were MRTG and Solarwinds Orion Network Performance Monitoring.

MRTG required a lot of manual configuration to get information into a useful form.  Orion was simple to use, but expensive.

I wonder if Nagios would be a good middle ground?  This needs to be checked out!

As an aside, NetFlow information can be quite useful in defining what normal conversations are. Setting up a router or firewall to provide NetFlow information is not hard, but experimenting with collectors to find a good tool for analyzing the information is tougher.  Using the Paessler Netflow Generator to generate some NetFlow data might help this considerably.

FreeSCO

FreeSCO is an open source lightweight router based on Linux for use in lab environments. It has promise for use with VMWare Fusion in connecting the lab environment to the public NIC on the host computer.  This is now officially on my list of Tools to Check Out.

RPi Honeypot

I’m setting up a Raspberry Pi to use at work as a host that can respond to ping requests and provide a target to test monitoring software against. It occurred to me that this might be more useful if I add something to the Pi to spice it up a bit: honeypot software. What could be more fun than having a honeypot that one could drop onto a network at a moment’s notice?

Here’s where I found my first clues on how to do such a thing:
https://isc.sans.edu/diary/A+Honeypot+for+home:+Raspberry+Pi/18463

Here I go!