Biblio

For modern Automatic Test Equipment (ATE), one of the most daunting tasks conducting Information Assurance (IA). In addition, there is a desire to Network ATE to allow for information sharing and deployment of software. This is complicated by the fact that typically ATE are “unmanaged” systems in that most are configured, deployed, and then mostly left alone. This results in systems that are not patched with the latest Operating System updates and in fact may be running on legacy Operating Systems which are no longer supported (like Windows XP or Windows 7 for instance). A lot of this has to do with the cost of keeping a system updated on a continuous basis and regression testing the Test Program Sets (TPS) that run on them. Given that an Automated Test System can have thousands of Test Programs running on it, the cost and time involved in doing complete regression testing on all the Test Programs can be extremely expensive. In addition to the Test Programs themselves some Test Programs rely on third party Software and / or custom developed software that is required for the Test Programs to run. Add to this the requirement to perform software steering through all the Test Program paths, the length of time required to validate a Test Program could be measured in months in some cases. If system updates are performed once a month like some Operating System updates this could consume all the available time of the Test Station or require a fleet of Test Stations to be dedicated just to do the required regression testing. On the other side of the coin, a Test System running an old unpatched Operating System is a prime target for any manner of virus or other IA issues. This paper will discuss some of the pro's and con's of a managed Test System and how it might be accomplished.

Automatic test systems designed to validate the performance of military and aerospace products have always been held to a higher standard; moreover, emerging threats to data security and instrumentation integrity continue to raise this bar. Engineers are faced with growing pressure to not only ensure that the unit under test (UUT) meets all design criteria, but that it remains safe from malicious attacks aimed at gaining access to test parameters or results, controlling of test sequences and functionality, downloading malware, or impacting functionality by way of counterfeit parts installed in instrumentation. This paper will delve into the cybersecurity issue from the perspective of the test development environment, including the use of test executives, and the challenges associated with minimizing impact to data integrity and access to control. An undetected data breach on military / aerospace automated test equipment (ATE) holds significance beyond just the test system, since mission critical electronics associated with avionics, radar, electronic warfare and missile assemblies must also be protected. One topic discussed will be the impact of adopting methods and procedures detailed in the Department of Defense's (DoD) Application Security Technical Implementation Guide, which is based on NIST documents and details how to manage and maintain a secure software-based system such as an ATE system. Another aspect of cybersecurity that is often overlooked in the world of commercial-off-the-shelf (COTS) instrumentation and switching systems is the potential impact on the UUT from substandard counterfeit parts and those embedded with malware. Concerns with counterfeit material can encompass a range of threats including the re-purposing of used parts and new knockoff parts with substandard operating characteristics represented and sold as new hardware. One of the most concerning aspects, parts intentionally infected with malware, can pose a significant risk to personnel and national security. We will discuss various strategies aimed at countering these threats, including the adoption of policies and procedures outlined in AS9100D and AS5553, which can mitigate these risks.

With the disconnected nature of some Automatic Test Systems, there is no possibility for a centralized infrastructure of sense and response in Cybersecurity. For scalability, a cost effective onboard approach will be necessary. In smaller companies where connectivity is not a concern, costly commercial solutions will impede the implementation of surveillance and compliance options. In this paper we propose to demonstrate an open source strategy using freely available Security Technical Implementation Guidelines (STIGs), internet resources, and supporting software stacks, such as OpenScap, HubbleStack, and (ElasticSearch, Logstash, and Kibana (ElasticStack)) to deliver an affordable solution to this problem. OpenScap will provide tools for managing system security and standards compliance. HubbleStack will be employed to automate compliance via its components: NOVA (an auditing engine), Nebula (osquery integration), Pulsar (event system) and Quasar (reporting system). Our intention is utilize NOVA in conjunction with OpenScap to CVE (Common Vulnerabilities and Exposures) scan and netstat for open ports and processes. Additionally we will monitor services and status, firewall settings, and use Nebula's integration of Facebook's osquery to detect vulnerabilities by querying the Operating System. Separately we plan to use Pulsar, a fast file integrity manger, to monitor the integrity of critical files such as system, test, and Hardware Abstraction Layer (HAL) software to ensure the system retains its integrity. All of this will be reported by Quasar, HubbleStack's reporting engine. We will provide situational awareness through the use of the open source Elastic Stack. ElasticSearch is a RESTful search and analytics engine. Logstash is an open source data processing pipeline that enables the ingestion of data from multiple sources sending it through extensible interfaces, in this case ElasticSearch. Kibana supports the visualization of data. Essentially Elastic Stack will be the presentation layer, HubbleStack will be the broker of the data to Elastic Stash, with the other HubbleStack components feeding that data. All of the tools involved are open source in nature, reducing the cost to the overhead required to keep configurations up to date, training on use, and analytics required to review the outputs.

For modern Automatic Test Equipment (ATE) one of the most daunting tasks is now Information Assurance (IA). What was once at most a secondary item consisting mainly of installing an Anti-Virus suite is now becoming one of the most important aspects of ATE. Given the current climate of IA it has become important to ensure ATE is kept safe from any breaches of security or loss of information. Even though most ATE are not on the Internet (or even on a local network for many) they are still vulnerable to some of the same attack vectors plaguing common computers and other electronic devices. This paper will discuss one method which can be used to ensure that modern ATE can continue to be used to test and detect faults in the systems they are designed to test. Most modern ATE include one or more Ethernet switches to allow communication to the many Instruments or devices contained within them. If the switches purchased are managed and support layer 2 or layer 3 of the Open Systems Interconnection (OSI) model they can also be used to help in the IA footprint of the station. Simple configurations such as limiting broadcast or multicast packets to the appropriate devices is the first step of limiting access to devices to what is needed. If the switch also includes some layer 3 like capabilities Virtual Local Area Networks can be created to further limit the communication pathways to only what is required to perform the required tasks. These and other simple switch configurations while not required can help limit the access of a virus or worm. This paper will discuss these and other configuration tools which can help prevent an ATE system from being compromised.

For modern Automatic Test Equipment (ATE) one of the most daunting tasks is now Information Assurance (IA). What was once at most a secondary item consisting mainly of installing an Anti-Virus suite is now becoming one of the most important aspects of ATE. Given the current climate of IA it has become important to ensure ATE is kept safe from any breaches of security or loss of information. Even though most ATE are not on the Internet (or even on a network for many) they are still vulnerable to some of the same attack vectors plaguing common computers and other electronic devices. This paper will discuss some of the processes and procedures which must be used to ensure that modern ATE can continue to be used to test and detect faults in the systems they are designed to test. The common items that must be considered for ATE are as follows: The ATE system must have some form of Anti-Virus (as should all computers). The ATE system should have a minimum software footprint only providing the software needed to perform the task. The ATE system should be verified to have all the Operating System (OS) settings configured pursuant to the task it is intended to perform. The ATE OS settings should include password and password expiration settings to prevent access by anyone not expected to be on the system. The ATE system software should be written and constructed such that it in itself is not readily open to attack. The ATE system should be designed in a manner such that none of the instruments in the system can easily be attacked. The ATE system should insure any paths to the outside world (such as Ethernet or USB devices) are limited to only those required to perform the task it was designed for. These and many other common configuration concerns will be discussed in the paper.