By the end of their first tour, every submariner is maintaining some kind of records. Small divisions sometimes have more administrative programs than they have sailors, and everyone has to do his or her part to keep the records which certify the submarine to operate at sea. Maintenance records, health records, supply records, training records, logs—they never stop, and each has its own review and retention requirements. Although necessary, the long and untracked hours needed to keep up with administration can become a distraction from operations, maintenance, and ultimately warfighting. With a hard limit on the number of sailors on a submarine, that means a deadlier ship. An attempt to unify these requirements into one large software system would take years and face an extensive requirements process with changing needs.
There is an alternative. On every boat, there are sailors developing software prototypes as they struggle to make their own work more efficient. Locally brewed Powershell scripts, macros, spreadsheets, and Microsoft Access databases are real solutions to problems in the fleet. A central group of software engineers could analyze, generalize, improve, or rewrite them as appropriate, and redistribute them to the fleet as cryptographically signed scripts, static webpages, or executables for general use. We can save time in the fleet, promote innovation, and improve retention for talented and creative sailors at minimal cost. Less time on administrative work means more time for maintenance, warfighting training, and well-deserved sleep.
These one-off scripts already benefit the sailors who make them and their ships. When I was assistant engineer at the end of the USS Springfield’s (SSN-761) engineered overhaul, the shipyard began to turnover two and a half years of maintenance records for the crew for input into the “official” Microsoft Access database. With our shipboard database format not authorized for use by the shipyard, and no means of transfer available, they could not meet the requirement to provide directly importable data and continued providing Word documents and binders. When our engineer realized that the ship’s electronics technicians were being committed to dozens of hours of manual transcription and review when they should be preparing for upcoming high-stakes testing, he tasked me with easing the burden. I worked with the shipyard to set a suitable data format, and they went to work transcribing their Word documents into an Excel spreadsheet. In the meantime, I wrote a Powershell script that turned the rows of the spreadsheet into entries in our database. After a few days of development the script was reviewed by the commanding officer, the data was provided by the shipyard, and the import was completed without time-consuming and error-prone manual entry.
Everyone on the ship with programming skills should seek ways to save time and focus the crew’s attention on areas where human judgment is truly necessary. On the Springfield alone, sailors also developed:
- A watchbill generator which uses a constraint satisfaction system, with features such as preferred days off, required subgroups, and multiple candidate generation.
- A Microsoft Access database to track all divisional lockers and their contents.
- Scripts to rapidly set up user accounts on a new network.
- An Excel spreadsheet to provide graphical simulations for tactical training.
- A web page to rapidly search through titles of files in the ship’s library.
- Scripts to search the share drive for illicit files and exam material.
- Scripts to download unclassified instructions formerly distributed by CD.
Innovation on this incremental scale is happening throughout the fleet. All of these applications could have been useful to any submarine, but generally are not worth an extended requirements and contracting process. The submarine force should cultivate and develop them for the benefit of every ship.
The individuals with the drive and thoughtfulness to work toward process improvement are a valuable resource for the Navy. Programming skills complement that urge, allowing software and regulations to work together in more efficient processes. By instruction, information technology specialists are supposed to learn the scripting skills necessary for any system administrator, but they have little opportunity or resources to do so. By providing those who are self-taught with opportunities for feedback from shore-side experts, the Navy can enable professional development by growing programming, administration, and cybersecurity skills. The sailors who have worked through this process by innovating and cooperating with shore-side engineers will be a filtered group with skills useful for both selective detail and future educational opportunities. They will be better able to communicate with software contractors and vendors, and if the Navy begins a program such as the Air Force’s Kessel Run, or expands programs such as the P8 community’s iLoc, it will have a preselected group with the right skills. Most important, sailors who contribute to tools that provide lasting assistance to their peers throughout the fleet will know it, which will improve morale and retention.
Today, cybersecurity processes make this difficult to do “right.” Modern web applications are rightly becoming more common in the Department of Defense, but that progress does not help underway submariners largely disconnected from the internet. The compliance processes to get a simple standalone application onto the submarine local area network (SubLAN) are so onerous that NAVFIT98a, a simple Access application that used to be on submarine classified networks, and is approved for use on the classified Navy and Marine Corps Intranet, was removed from new networks years ago and still has not been restored. The process to approve it occasionally is resurrected with emails and meetings involving dozens of members of the Navy’s cybersecurity administration, but eventually it grinds to a halt again.
This is a problem of the Navy’s own making. The Risk Management Framework has a relatively simple set of requirements for approving an IT product. The 8510.01 states that applications must be reviewed in accordance with relevant Security Technical Implementation Guides or Security Requirements Guides, that review must be documented in a security assessment report, which must be reviewed by an information system security manager, under the supervision of the authorizing officer. The process needs a security reviewer, an information system security manager, and an authorizing officer. Two individuals must have the expertise to review the source code and examine the application, and one to review the result and make a final decision. The current processes—involving many organizations and dozens of people—should only be applied when the complexity of the IT product being evaluated warrants it. Simple principles, such as aborting when run with administrator privileges, careful management of untrusted input, and source code review, will make a straightforward approval process appropriate. Finally, the approved script, program, or files should be cryptographically signed and provided an expiration date using a code-signing certificate to ensure that modified copies cannot be redistributed through the fleet.
To make basic onboard development possible, the SubLAN should provide some simple tools. Git, the world’s most widely used version control system, would allow sailors to reliably and incrementally work on their code. SQLite and the ADO.NET adapter would give access to all the power of relational databases and an effective means for serialization. A PKI-token enabled SSH client would support collaboration across the fleet. A simple open source text editor like Notepad++ or VSCode makes programming much easier. Finally, use of Microsoft Powershell should be encouraged, not locked behind administrator access restrictions as it recently was on NMCI. The documentation should be preinstalled as it was on older SubLAN versions. These changes would not require any modifications to security controls, but would make any programmer on the boat, including network administrators who already are using Powershell, more effective.
Shore-side, enabling these small innovations will require a code repository such as a Gitlab instance and a process managed by submarine force information technology specialists to solicit applications and distribute approved applications. The SubLAN authorizing officer should provide each project with an enthusiastic security engineer who can work with the submitting sailor to bring the application into compliance and hand it off to another engineer for review. The sailor who submits software will get a valuable learning experience in cybersecurity and application design and have a chance to use hard-won development skills to make a lasting contribution to their ship and warfare community. The fleet will gain in the uniformity and efficiency of processes across ships. Every bit of progress ultimately contributes to the lethality of our ships and our fleet.