HomeAbout UsBrowse This IssueBack IssuesNews DispatchesSubscribing to Army LogisticianWriting for Army LogisticianContact UsLinks































CSSAMO Experiences in Operation Iraqi Freedom

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.

Legacy Systems

Soon after arriving in Iraq, we discovered that the units under our task organization were transmitting their logistics and 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 experience with the FTP process. This lack of FTP capability had profound negative consequences.

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 risks.

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 desks, 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 Logistics 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.

Networking Plan

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, we would—

  • 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 operations.

To increase information assurance, we would—

  • Stand up an antivirus server and configure the STAMIS computers to regularly “pull” the updated definitions and perform regular antivirus scans.
  • Stand up a Windows Server Update Service server to provide Microsoft patches to STAMIS computers.
  • Control configuration.
  • Back up data.

Information Transfer

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.

Information Assurance

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 patches.

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 became compromised.

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 server impossible.

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.