in Operation Iraqi Freedom
|by Major Jerome P. Brock
When the 16th Corps Support Group (CSG), 3d Corps
Support Command, from Hanau, Germany, deployed to support Operation
Iraqi Freedom in October 2005, its Combat Service Support Automation
Management Office (CSSAMO) fell in on a logistics Standard
Army Management Information Systems (STAMIS) infrastructure
that did not take full advantage of modern Army networking
capabilities. Within the first 6 months, we modernized the
unit’s logistics automation operations in order to give
the commander access to more accurate and timely maintenance
and supply data on which to base his decisions.
Soon after arriving in Iraq, we discovered that the units
under our task organization were transmitting their logistics
supply data by floppy disk or email. They were doing so despite
the potential of the systems at their disposal—the Unit
Level Logistics System-Ground (ULLS–G), Standard Army
Maintenance System (SAMS) –1 and –2, and Standard
Army Retail Supply System (SARSS)—to transfer data
by file transfer protocol (FTP). They did not use FTP because
most locations, especially the motor pools, had no network
connectivity and very few locations had operators who had
with the FTP
process. This lack of FTP capability had profound negative
ULLS–G, SAMS–1 and –2, and SARSS are somewhat
antiquated in that, other than FTP, the only way to transfer
data between them is by floppy disk. Unfortunately, these systems
will not read data from universal serial bus (USB) flash memory
drives. The units that were using email exported the data to
floppy disk, copied the data from the floppy into an email,
and sent it. The recipient reversed the process.
When data are transferred between ULLS–G and SAMS–1,
ULLS–G provides SAMS–1 with direct support (DS)
maintenance requests and the status of organizational work
orders. SAMS–1 also provides ULLS–G with the status
of the unit’s open work orders. The use of FTP eliminates
the need to use unreliable floppy disks, a fact that cannot
be overemphasized. When using FTP, information flows in both
directions during the same session.
Floppy Disk Pitfalls
When a floppy disk is used for data transfer, ULLS–G
writes data to the floppy disk, the operator carries the disk
to the SAMS–1 location, and SAMS–1 reads the disk
and writes status information to it. The ULLS–G operator
carries the disk back to his computer, which reads the disk.
All of this travel takes time and exposes Soldiers to unnecessary
Floppy disks also are highly unreliable. This is especially
true in a sand-filled environment. System operators tend
to keep their floppy disks loose in a desk drawer, on their
or in their pockets, which results in sand contamination
that causes the disks to become unreadable. This causes
a data loss
and a corresponding loss of accurate transfer of maintenance
and supply data, which, in turn, leads to incorrect, incomplete,
and erroneous generation of data by the SAMS–2 for the
026 report, Equipment Deadlined Over XX Days by Battalion.
In Iraq, the inaccuracy of the report severely degraded the
16th CSG commander’s ability to manage maintenance effectively.
The in-theater STAMIS computers suffered the usual problems
of manually applied antivirus definitions and operating
system patches approved by the Product Director, Tactical
Systems (PD–TLS). Because it was too difficult, and potentially
dangerous, for CSSAMOs to keep antivirus definitions and operating
system patches updated by physically “touching” every
computer, most base system administrators were unwilling to
allow STAMIS computers to be included on their networks. As
a result, STAMIS computers were not maintained at the maximum
level of authorized protection.
To maximize the usefulness of in-theater STAMIS computers,
we developed a networking plan that would transfer logistics
and supply information and increase information assurance.
To transfer logistics and supply information more efficiently,
Improve floppy disk reliability
as an immediate fix.
- Provide network access to the STAMIS computers.
- Establish FTP data transfer between the STAMIS computers.
- Instruct operators on how to conduct FTP
To increase information assurance,
Since the unreliability of floppy disks was causing problems,
we needed a way to make them more reliable. We instructed the
operators to keep their floppy disks in a Ziploc bag. The only
time that a disk should be removed from the bag is when it
is inserted in the computer for reading or writing. The bag
significantly reduced the opportunities for sand particles
to contaminate disks and render them unreadable. The positive
effects were immediately apparent at a next-to-nothing cost
and with no real impact on usability or convenience.
Providing network access to our supported units’ computers
was more challenging. Roughly half of the units had no network
connectivity at their motor pools. To help establish network
connectivity for logistics systems, the Army has been fielding
Very Small Aperture Terminals (VSATs) and Combat Service Support
Automated Information System Interfaces (CAISIs). However, these
systems have not yet been fielded to the 16th CSG. Fortunately,
the Georgia Army National Guard’s 48th Infantry Brigade
Combat Team (BCT) lent us several CAISIs, gave us access to their
VSATs, and provided us with instruction on their configuration.
Thus, we were able to get started while waiting to receive the
CAISIs that we had requested from our higher headquarters, the
3d Corps Support Command.
Our first priority was to use the CAISI to provide network connectivity
to our core SAMS–1 and SAMS–2 servers. The supply
server (SARSS) already had access to a VSAT. After we established
network access for both maintenance and supply servers, we attempted
to configure the FTP so that the SAMS–1 computers could
send their data by FTP to both the SAMS–2 and SARSS computers.
We experienced the usual problems of getting accounts and passwords
straight and helping the operators through proper FTP procedures.
Very soon, though, the SAMS–1 servers were successfully
performing daily FTP transfers.
The next step was to emplace a CAISI at those motor pools that
had no connectivity to the base local area network (LAN). While
some of our Soldiers were doing this, others were working with
the units that had connectivity through the base LAN and coordinating
with the SAMS–1 and SARSS operators in configuring the
units’ ULLS–G for FTP. As the first group of Soldiers
completed a CAISI emplacement, the unit was handed off to the
second group for FTP configuration. Forming these two specialized
groups allowed us to make constant progress toward our goal.
Although many aspects of information assurance could be improved
in the day-to-day operation of STAMIS computers, we focused
on only four: ensuring that the antivirus definitions were
up to date, keeping the operating system properly patched,
maintaining configuration control, and creating backups.
Ensuring that the antivirus definitions were up to date. This
was the simplest of these procedures to implement. Using Symantec’s
LiveUpdate Administration Utility, we configured a non-STAMIS
computer to operate as a server and retrieve current virus definitions
automatically from an approved Department of Defense source.
Each of our supported STAMIS computers was then configured to
retrieve the updated definitions from that server. This allowed
us to minimize the traffic across the bandwidth-
constrained VSAT because the definitions made only one trip
across the satellite, regardless of the number of STAMIS computers
we used. The STAMIS computers also were configured to perform
an automatic daily virus scan of their disk drives.
Keeping the operating system properly patched. Applying patches
that have been approved by the PD–TLS was a longstanding
problem. Unlike some other systems, only approved patches can
be installed on STAMIS computers. We chose to use a Microsoft-centric
solution—Windows Server Update Service (WSUS). Unlike
the previous iteration, Software Update Services, WSUS allows
an administrator to set up various computer groups and approve
patch installation on a group-by-group basis. This was exactly
the functionality we needed. The most difficult part of setting
up WSUS for STAMIS computers is the initial configuration of
all of the patches that are currently approved for installation
on a particular STAMIS. Once this is done, however, upkeep is
simple. All an administrator needs to do is approve the newly
authorized patch, and, the next time that each computer connects
to the server, the patch is pulled down and installed automatically.
WSUS also allows the administrator to check the last time that
a computer was connected and verify that it has all approved
For both the antivirus server and the WSUS server, we chose
to use a “pull” technology. That means that the
STAMIS computers requested data from the server; the server
did not “push” data to them. In a tactical environment,
where the network may not always be fully operational and computers
may not always be on, “pull” technology seems to
be the better choice. It is important to note that our two servers
really should be referred to as “services.” We were
actually running them both on one computer, thus limiting the
hardware requirements for this solution.
Maintaining configuration control. Like any automated information
system, STAMIS computers
require strict configuration control. When we arrived in theater,
all of the systems that we were to support had software on them
that was not approved for that particular STAMIS. Specifically,
most of the ULLS–G
computers had Microsoft Office installed. While Office is part
of the standard array of software used in the Army, its unapproved
installation on a STAMIS computer presents problems. The CSSAMO
either must conduct the necessary testing himself to verify
that the patches do not hinder the proper operation of the STAMIS
application or allow the software to go unpatched. Since the
CSSAMO is not resourced to tackle the former and the latter
is unacceptable, unapproved software cannot be permitted.
We also rigorously enforced the requirement that operators log
in as regular users, not as administrators. Administrator login
was permitted only to perform tasks that required it, such as
adding a printer. This concept is known as “least privilege.”
Creating backups. Finally, we instituted an initially hidden
backup plan. Generally speaking, the most important part of
any information system is the information itself. A computer
can be replaced and all of the software reinstalled, but if
the data files are not available, the data either are gone forever
or must be recreated from other information sources. Since neither
of these situations is acceptable, regular back-ups must be
made. The backups must be saved on an external device, usually
a USB flash memory drive. Actually, one backup is not enough.
If an operator overwrites yesterday’s backup with today’s
backup, he has no way to recover from a problem that goes back
more than 1 day.
To avoid backup problems, we repeatedly notified the operators
and their chains of command that they needed to back up their
STAMIS data on a regular basis. Our hidden backup plan consisted
of using the Windows Scheduler, a part of the operating system,
along with Win-Zip, which was already installed on the STAMIS
computers, to schedule a nightly backup that “zipped” up
the data and saved it on a portion of the computer system not
accessible by regular users. Each nightly backup file was given
a filename that was the computer name followed by the current
date. The significance of this backup is that we could recover
from any data problem experienced by the computer, short of
the hard disk becoming unreadable, by restoring the appropriate
backup. We kept the existence of automatic back-ups from the
operators for as long as possible so that they would not be
tempted to stop making backups of their own, thereby robbing
us of protection against hard disk failures.
Together, the four information assurance measures we established
served as a layered defense. We kept the virus definitions updated,
which identified viruses that attempted to exploit vulnerabilities;
we kept our computers updated by installing patches, which mitigated
known vulnerabilities in the STAMIS; we disallowed new software
and enforced least privilege, which limited the damage caused
by users and previously unknown attacks; and we required regular
backups, which allowed us to recover in the event that a computer
As a result of our information assurance efforts, we attained
much greater accuracy of maintenance and supply data and in
the reliability of the STAMIS computers used to process it.
Thanks to the teams that handled connectivity and FTP configuration
and the computer operators, all of our maintenance and supply
system STAMIS computers performed regular, dependable data transfer
by FTP. This was particularly remarkable considering the challenges
presented by our harsh environmental conditions.
Because of our information assurance efforts, none of our configured
STAMIS computers fell prey to a virus. The automated nature
of our system allowed us to keep the computers fully updated
without having to “touch” each of them physically.
It would have been a logistics nightmare to go through the patching
cycle if physical access had been required.
The hidden backup process paid immeasurable dividends on many
occasions when operators brought in their STAMIS computers and
admitted that they did not have current backups. We easily recovered
the data from our hidden backup store. Had we been able to establish
a central server, each STAMIS computer could have sent its nightly
backup file to that server automatically, which would have allowed
us to recover from even total destruction of a STAMIS computer.
Unfortunately, bandwidth constraints made that
As a final note, any plan is just that—a plan. Without
the technically and tactically proficient Soldiers I was privileged
to serve with in the 16th CSG CSSAMO, none of these results
would have been possible.
Major Jerome P. Brock was the Combat Service Support Automation
Management Officer for the 16th Corps Support Group, 3d Corps
Support Command, during its deployment to Iraq from October
2005 to September 2006. He has a B.S. degree in computer science
from the U.S. Military Academy and an M.S. degree in computer
science from the Naval Postgraduate School. He is a Certified
Information Systems Security Professional.