J Peter Brady

Sergey Bratus

Sean Smith

DYNAMIC REPAIR OF MISSION-CRITICAL APPLICATIONS WITH RUNTIME SNAP-INS

This chapter proposes a solution that provides reliable, non-disruptive updates to critical systems using a novel design pattern called a "snapin," which is able to install replacement routines embedded in shared libraries during system execution. Most system updates are performed in a static or maintenance state. However, dynamically updating software reduces the time required for adding functionality and applying security upgrades. The proposed snap-in solution improves on previous work by adopting the novel approach of using the target's application binary interface to first load shared libraries that contain replacement routines into a running application, supplanting the original routines with replacement routines without having to modify the existing code. An automated toolkit is provided for scanning application binaries and determining where the replacement routines are to be added.

1.

Introduction

In 1992, researchers studied the software faults discovered during integration testing of the Voyager and Galileo spacecraft code at the Jet Propulsion Laboratory [START_REF] Lutz | Analyzing software requirements errors in safety-critical, embedded systems[END_REF]. The bulk of the faults were directly attributed to errors in understanding or implementing requirements, and to miscommunications between development teams. Not surprisingly, "there's no such thing as a bug-free application" [START_REF] Varshneya | There's no such thing as a bug-free app[END_REF].

Not all faults in modern computing systems are found during internal integration and testing. As a result, faults found during field deployments become part of the maintenance cycle. Maintaining software during its lifetime is a significant and costly problem.

A NIST report [START_REF]The Economic Impacts of Inadequate Infrastructure for Software Testing[END_REF] reveals that the costs to repair system defects increase rapidly after the requirements stage. Table 1, taken from the report, shows that the cost of repairing a defect in the field is up to 880 times the cost of repair during the requirements stage (x denotes a normalized unit of cost).

Standard application maintenance generally has the following cycle:

Revision: Decide what is to be changed, such as repairs based on bug reports from users or the addition of new functionality.

Development: Make the changes to the application, rebuild and test in the engineering environment, and pass a release candidate to configuration management.

Testing: Run the release candidate through a quality assurance process to ensure that it is ready for release.

Deployment: When the new application release is ready to be installed, shut down the old version of the application, execute an installer program that loads the new release and start the new application.

This maintenance cycle does not work well for all systems. The ability to do dynamic updating as opposed to a restart-style deployment is necessary, especially in the case of mission-critical systems that cannot have any downtime. For example, a communications satellite, the Mars Rover or a power grid cannot be switched off entirely to update their software. While the Mars Rover had extensive planning and infrastructure to allow for software updates [START_REF] Finley | NASA pulls off 160-million-mile software patch[END_REF], not all systems have the level of resources needed for repairs, so devising an alternative technique is imperative.

Examples of other systems that do not have the standard maintenance lifecycle are those that are obsolete or that were created by vendors who are no longer in business. An inability to update system software can have disastrous consequences, such as not being able to contain a virus like Stuxnet [START_REF] Langner | Stuxnet: Dissecting a cyberwarfare weapon[END_REF] or a potential wide-spread failure.

Industrial control systems, which operate complex and dispersed infrastructures such as electric grids, oil and gas pipelines, and power plants, are good examples of critical systems with challenging maintenance cycles. Several guides for securing industrial control systems have been published (e.g., [START_REF] Stouffer | Guide to Industrial Control Systems (ICS) Security[END_REF]). However, concerns have been raised about hardware obsolescence [START_REF] Guzman-Miranda | Coping with the obsolescence of safety-or mission-critical embedded systems using FPGAs[END_REF] and that industrial control systems became operational before the latest security techniques were developed [START_REF] Gold | The SCADA challenge: Securing critical infrastructure[END_REF]. Additionally, some industrial control systems may run on old or obsolete platforms that no longer have vendor support for their hardware and/or operating systems.

Internet of Things (IoT) devices have similar maintenance problems. Many consumer devices -as well as some industrial Internet of Things (IIoT) deviceshave non-upgradeable firmware, meaning that there are no easy system upgrade paths. Additionally, integrators often incorporate low-cost circuit boards in their systems with no opportunities for firmware updates. Internet of Things software systems often have security issues. For example, developers may put together software from various sources in an ad hoc manner, resulting in security holes such as default or non-changeable administrative passwords [START_REF] Palmer | Is 'admin' password leaving your IoT device vulnerable to cyberattacks?[END_REF] and buffer overflows such as those exploited by the Mirai botnet [START_REF] Kolias | DDoS in the IoT: Mirai and other botnets[END_REF].

To address these challenges, this chapter presents a new design pattern called a "snap-in" that facilitates the insertion of new or modified software in a running system. Information in the application binary interface (ABI), in this case in the Linux executable linkable format (ELF), is leveraged to find faulty routines that are subsequently replaced with updated versions even while the system is operational. This novel approach ascertains information about an application and uses it to replace routines without changing the structure of the application. This is an important point because modifying application code directly can leave it in an inconsistent state.

Snap-ins are designed to quickly repair faulty code (e.g., validating SSL certificates in Internet of Things devices [START_REF] Leyden | Samsung smart fridge leaves Gmail logins open to attack[END_REF]) or to make rapid repairs to programs that experience "zero-day blooms" [START_REF] Smith | The Internet of Risky Things -Trusting the Devices That Surround Us[END_REF] (i.e., latent errors that can affect a wide range of programs, and program or operating system versions). Snapins also enable the layering of security proactively at a global control point in a piece of unmodified software [START_REF] Ruoti | Layering security at global control points to secure unmodified software[END_REF]. For example, secure input-handling parsing of command inputs to Internet of Things devices via the application of language-theoretic security [START_REF] Anantharaman | Building hardened Internet-of-Things clients with language-theoretic security[END_REF] can avert potential security holes by creating parser-combinators that enforce input validation to prevent malicious data manipulation.

Snap-in Overview

The snap-in system has three major components:

Shared Libraries: Shared libraries contain the patches to be installed. The patches modify or augment the operation of the target application. Shared libraries are employed to leverage standard software engineering techniques for aggregating custom routines or for modifying later versions of shared libraries used by the target application that is being repaired.

Mapping Data: This data maps system executables to the repaired routines.

Snap-In Controller:

The snap-in controller reads the mapping data, searches for running target executables, pauses the execution of the target Details about the operation of the snap-in toolkit are provided later in this chapter. However, in order to understand how snap-ins work, it is necessary to discuss the binary format underling Linux applications, specifically, ELF.

ELF Files

Snap-ins require the ELF ABI [START_REF]The Santa Cruz Operation, System V Application Binary Interface, Edition 4.1[END_REF], the current standard binary executable format for Unix and Linux systems. An ELF file is a dual-use object. It initially serves as a container for a compiler to store machine code and data and for the linker to assemble all the selected files into an executable program. The compiler creates a set of sections that contain the compiled code, data, relocation information and external references to other routines. ELF establishes a section header table that is accessed by the linker to resolve and update the reference sections in each file.

When a linker creates an executable file, it writes a program header table into the resulting ELF file. The program header table points to a set of segments. A segment has zero or more sections; for example, a read-only segment may contain code in an executable text section while constants reside in a read-only section.

An ELF file is also used when a loader reads the program header table of an executable file to map the file segments into memory and resolve run-time symbols via the shared libraries. As discussed later, the file segments are also used by the snap-in program to modify the software. Table 2 lists the ELF segments used by snap-ins. Interested readers are referred to [START_REF] Levine | Linkers and Loaders[END_REF] for more information about ELF.

Most Linux binaries are dynamically linked -they rely on a loader to connect required external system calls or functions to the correct shared libraries. For example, if an application wishes to call function read(), the linker writes information into the application that says it is located in the GNC C library libc along with the offset in the library. The linker does not write the actual address into the application for reasons of flexibility -if one or more libraries are upgraded, then all the applications that use the libraries would have to be re-linked to work properly.

Modern Linux systems use address space layout randomization (ASLR) [START_REF] Spengler | PaX: The guaranteed end of arbitrary code execution[END_REF] to map the shared libraries required by an application at randomized locations in the application memory space. This approach prevents malicious applications from using memory corruption to access resources that are denied to them. Attempting to write a hard-coded address into an application would make this feature unusable.

Since a loader must ascertain the memory space at runtime and resolve the connections just before the application runs, it needs to do its job quickly. The design of the ELF file makes this possible by establishing connections to the shared library as and when they are needed.

Continuing with the example, the first time that function read() is called by the executable, the mainline code calls some interlude code in the procedure linkage table (PLT) that triggers the loader to connect function read() to libc. The loader places the address entry in the .got.plt segment following which the function read() is called in libc. Subsequent calls made to read() automatically use the address written in segment .got.plt, so only the first call to the shared library function incurs a small time penalty. This procedure is crucial to the operation of snap-ins.

Mapping Data

Since the ELF ABI underpins the target applications to be repaired as well as the shared libraries to be installed, this research has a designed a toolkit containing a program that can read either. The toolkit extracts from the ELF data the entry point name, its relocatable address and, in the case of an application, the library name pointed to by the entry. It also identifies writable data that has to be relocated.

If the target application is multi-threaded, then additional data is collected to find the best places to stop code execution safely, primarily in blocking routines such as select(), sleep(), fork() and pthread cond wait(). These points, which are referred to as "thread markers," are stored in the mapping data.

The collected data is then used by the snap-in controller to match the repaired routines with target applications.

. Snap-in controller in operation.

Snap-In Controller

The snap-in controller is a daemon that runs on the system that is to be updated. The controller uses the collected mapping data to insert shared libraries into an operator-selected set of running programs.

The controller runs in a loop to query all the running applications on the system. If an application matches the pattern in the mapping data and has not already been updated, then the controller checks to see which shared libraries need to be loaded. After the shared library information is found, the controller briefly pauses the program in situ in the case of single-threaded applications. In the case of multi-threaded applications, it uses thread markers in the stored data to identify the appropriate places to pause.

Figure 1 clarifies the operation of the snap-in controller. Note the controller does not perform any modifications when the target application is executing; in such a situation, the controller pauses and it tries again after a timeout period.

The controller first reads the replacement table to find the target application that is running without modifications. The running target application initially uses function g() in shared library A (Figure 1(a)). Function g() has a bug and will, therefore, be replaced with the repaired function g'() located in a new shared library A'. Note that if multiple shared libraries are to be installed, all of them are installed into the process memory during this step.

Next, the ELF structure is used to connect the new library calls. In Figure 1(b), the controller installs the new snap-in library A' into the target address space and modifies the address pointers and data to point to the new function g'().

The controller first checks if the loader has completed a lazy or a full binding to the entry points in the original library. If the routine is fully bound, then the controller checks the saved program counter to ensure that g() is not being accessed; if it is being accessed, then the controller restarts the executable and checks the state at an alternate quiescent point or thread marker to ensure that g() is not running.

After the controller is sure that g() is not in the execution stream, the ELF segment .got.plt is modified to change the address of g() in the old shared library routine to g'() in the new shared library; all future calls in the executable point to g'(). The address also gets the proper offset to match the address space layout randomization used for the application. Interested readers are referred to [START_REF] Levine | Linkers and Loaders[END_REF][START_REF] Tomaschik | GOT and PLT for pwning, System Overlord Blog[END_REF] for details about this technique.

The controller loops through all the calls to be modified using the same technique. Certain libraries, such as DIABLO [START_REF] Van Put | A reliable, retargetable and extensible link-time rewriting framework[END_REF] and ERESI [START_REF] Eresi Team | The ERESI Reverse Engineering Software Interface[END_REF], facilitate the rewriting of ELF binaries. However, these libraries were not employed in this work.

On the other hand, if the loader has performed a lazy binding of the library call (i.e., the dependency is loaded when referenced for the first time), the controller does an explicit binding to the new version of the call by loading its address in the .got.plt segment.

After the snap-in controller completes the changes, it releases its connection to the target executable, updates its internal table to mark the executable as repaired and searches for the next executable to be repaired. The target application runs with the new library (Figure 1(c)). Calls to g() now go to g'().

Snap-In Toolkit

A snap-in toolkit was created as part of this research. The toolkit contains utilities for source control and for system administrators to install snap-ins on target systems.

The toolbox supports the following functions:

Searching Executable Targets for Patch Points: An automated scanner reads a selectable set of executables on a target system and saves entry point and patch point data in the XML format for each executable in an executable descriptor file (EDF).

Creating Patches for Executable Targets: Software engineers develop patches, which they link to shared libraries for each target executable. The automated scanner is executed on the shared libraries to create a patch control file (PCF) with XML data for each library.

Creating a Replacement Table:

A source code administrator obtains the patch control files for the released patches and selects the executable descriptor files associated with the target executables to be patched. A replacement constructor program (RCP) takes the two files and generates a replacement table.

Installing Patches on Running Executables: A system administrator receives and loads the patches and replacement tables for each target system. The snap-in controller, which runs as a daemon on the target system, reads the replacement table and checks if the applications listed in the table are running. The patch or patches of each running application are installed automatically.

Searching Executables

A Python-based program named snapdata was developed to scan and read the ELF symbol table information of an executable and output the executable descriptor file. The executable descriptor file contains specifics about the executable, such as the architecture for which it is built, the system libraries and names of external entries it calls and, optionally, the location of re-entrant or threaded code.

Figure 2 shows the process of creating an executable descriptor file. The target server executes snapdata -e to create the executable descriptor files (Step (a)). The system administrator pulls the descriptor files (Step (b)). The system administrator decides which programs need updates and releases the descriptor files (Step (c)). Finally, the released descriptor files are sent to <?xml version='1.0' encoding='utf-8'?> <edf version="1"> <!--Executable Descriptor File (EDF)--> <info> <!--File location and information--> <!--File: /usr/bin/apt--> <path>/usr/bin</path> <filename>apt</filename> <class>ELFCLASS64</class> <OS>ELFOSABI_SYSV</OS> <type>ET_DYN</type> <machine>EM_X86_64</machine> <entry>0x1890</entry> <ABI>3.2.0</ABI> <buildID>e4e5bbe239a65880c6b7d1b9f51bfded6c61220d</buildID> </info> <!--External entry points--> <entries> <entry name="strlen"/> <entry name="dgettext"/> </entries> <!--External shared libraries--> <libraries> <library name="libapt-private.so.0.0"/> <library name="libapt-pkg.so.5.0"/> <library name="libstdc++.so.6"/> <library name="libgcc_s.so.1"/> <library name="libc.so.6"/> </libraries> </edf> another system administrator for processing with the replacement constructor program.

Figure 3 shows a sample executable descriptor file output from /usr/bin/apt on a Ubuntu Linux system.

Applying snap-ins while pausing all the threaded code is important to prevent state changes; therefore, it is necessary to identify locations where code execution can be stopped safely. If snapdata determines that an executable is threaded, it looks for natural pauses in the code -the most straightforward places are at blocking calls such as select(), sleep(), fork() and pthreadcond wait(). These thread markers are stored by snapdata in the executable descriptor file. The snap-in controller uses the thread markers to pause the program when installing the replacement library.

Creating Patches

As mentioned above, patch files are standard shared libraries that contain the modified routines for a particular target library. They enable the use of a pre-built, later version of an application library as a patch, which reduces the time required to repair a critical program. For example, if a new version of an application has a bug fix and it is not possible to upgrade to this version, a library from the new version could be used without any modifications.

A shared library is just a particular type of file that contains one or more compiled object files that were built in a positionally-independent way; this enables it to be loaded into the address space of any executable when the executable is running. Building a new shared library is straightforward; interested readers are referred to [START_REF] Arora | Intro to Linux shared libraries (How to create shared libraries), The Geek Stuff Blog[END_REF] for details. It is important to note that the patches must line up with entry points (subroutines) for this technique to be successful.

Another way to create a patch for an old or obsolete executable with no source code is available is to translate or "lift" the target. Lifting is a process that creates an intermediate representation (IR) bytecode from the machine code of the executable. After this is done, the patch is created by modifying the intermediate representation bytecode and recompiling the fixes into a shared library for use. Lifting executables to an intermediate representation is outside the scope of this work; interested readers are referred to [START_REF] Goodman | Heavy lifting with McSema 2.0, Trail of Bits Blog[END_REF][START_REF]LLVM Compiler Infrastructure, Getting Started with the LLVM System[END_REF][START_REF]Trail of Bits[END_REF] for additional details.

After the shared libraries containing the patches have been created, the snapdata program is used to scan and read the ELF symbol table information of the executable, run with a patch scanner flag set in order to scan the libraries and create a patch control file that maps the routines in each library. The first section of the control file gives the name and version range of the target library that is modified (it can be allowed to operate on all or selected versions of the target). The second section of the descriptor file lists the routine names in the target library to be replaced. The names in the patch file should typically match those in the target library, but a command developer may map the target name to another routine name in the patch library.

Figure 4 shows the process for creating patch control files. Developers select patches and create snap-in libraries and store the completed patches on a patch server in preparation for transfer (Step (a)). A configuration manager decides when to apply the set of patches and executes snapdata -p on the patch server to create the patch control files (Step (b)). The configuration manager decides which patch control files are to be included in a specific release (Step (c)) and sends the released patch control files to another administrator for processing with the replacement constructor program snaprcp. This process enables the targeted servers to receive the new shared libraries.

The snap-in shared libraries are installed in the /lib/snapin directory on the target system. Keeping them in a single location is straightforward for an operator; the directory tree is protected so that only the superuser can make modifications. An operator can install all the released snap-ins on a target system, but their use by the snap-in controller is determined by the installed replacement table, which is unique for each system. In fact, as described below, the installed replacement table may optionally be protected with encryption.

Creating a Replacement Table

The snaprcp tool creates a set of mappings between system executables and the created patches. The mapping data is used by the snap-in controller to decide which routines should be overridden in a program. The snaprcp tool reads the executable descriptor and patch control files created by parsing the executables and patches, respectively. It stores the routine of each executable and its matching patch in the replacement table for the snap-in controller.

Figure 5 shows the process involved in creating a replacement table. A system administrator receives the released executable descriptor and patch control files for a target system (Step (a)). The system administrator then executes the snaprcp program to produce the replacement table for the target system (Step (b)).

Installing Patches

The snap-in controller inserts new libraries into running programs and uses the replacement table to connect the appropriate subroutines to the repaired code. The basic operation of the controller was discussed above (Figure 1), but some additional points need to be clarified. When a shared library or libraries are installed, the snap-in controller pauses the target application to perform the installation at one of the selected thread markers and then restarts the code. When the new routines are connected via the global offset table/procedure linkage table mechanism, checks are made to ensure that the thread marker is not in the code to be changed and, in the case of a multi-threaded application, all the threads have been paused. If the conditions are not met, an alternate thread marker is chosen and the procedure is repeated until the conditions are met. If the replaced code section has static, non-constant variables, then the current states of the variables are preserved in the data section of the new routine.

Authorizing Updates

The snap-in approach enables patching without taking applications down. Mission-critical systems, such as those running in operational technology environments, require extra diligence to ensure that the snap-ins are not corrupted accidentally or maliciously. Additionally, it is important to ensure that the target system receives the correct set of snap-ins. Authorization of patches is an orthogonal question; however, the toolkit provides an option for public-key authentication [START_REF] Smith | The Craft of System Security[END_REF] of updates.

Specifically, a set of unique public/private key pairs is created -one for each target machine on which the snap-in toolkit executes, one for the configuration manager to sign snap-in patches and one for the replacement table constructor. Table 3 shows how the public/private key pairs are used for signing and verification.

The following operations are available:

Signing Executable Descriptor Files: The target system signs each executable descriptor file with its private key. Each target system has its own set of keys to ensure that only patches assigned to it can be loaded on the system.

Signing Patch Control Files and Patches:

The configuration manager uses its private key to sign each patch control file and patch that are to be delivered.

Signing and Encrypting a Replacement Table:

The administrator who creates a replacement table first verifies the executable descriptor and patch control files with the respective public keys. If all the files are verified, the administrator runs the replacement constructor tool as described above.

The final operation of the replacement constructor tool is to sign the replacement table with its private key, compress the table and all the patches into a single compressed archive file, and encrypt the output with the public key of the target system.

Installing Snap-Ins: When a snap-in controller detects a new compressed archive file on a target system, it attempts to decrypt the file with its private key. If this is successful, the snap-in controller attempts to install snap-ins on running applications. It then verifies the signed replacement table with its public key and continues the installation if the verification is successful.

Related Work

Updating software dynamically is not a new problem. Several solutions have been proposed over the past decade.

Systems such as JavAdapter [START_REF] Pukall | JavAdaptor -Flexible runtime updates of Java applications[END_REF], a runtime replacement agent for Java systems, use features of the Java Virtual Machine (JVM) along with a system of containers and proxies to replace running Java classes. While JavAdapter is platform independent, it only works with Java-based applications. In contrast, snap-ins operate on ELF binaries; they are device hardware and language agnostic and can be recompiled for any platform that uses ELF. Other formats that have defined ABIs, such as the Windows x64 ABI [START_REF] Pietrek | Everything you need to know to start programming 64-bit Windows systems[END_REF], are easily incorporated.

Ksplice [START_REF] Arnold | Ksplice: Automatic rebootless kernel updates[END_REF] is an object-code layer patching system for a running Linux kernel. One or more patch files are merged with kernel source code to create a new object segment, which is loaded into kernel memory. The existing code is modified with a trampoline to jump to the new object. However, this system only works with a Linux kernel and requires the original source code.

POLUS [START_REF] Chen | POLUS: A powerful live updating system[END_REF] also uses a trampoline mechanism to jump from an old function to a new one. In contrast, a snap-in modifies the pointers at the ELF level, which precludes having to modify existing code and potentially makes it easier to roll-back changes.

Kitsune [START_REF] Hayden | Kitsune: Efficient, general-purpose dynamic software updating for C[END_REF] employs application source code and programmer-supplied transformation files to facilitate the migration of a complete process from an older to a newer version. This requires access to the original source code and the insertion of Kitsune-specific functions to control the migration. Snap-ins do not require any modifications to the original source code.

Katana [START_REF] Ramaswamy | Katana: A hot patching framework for ELF executables[END_REF] is the closest to the snap-in concept in that it uses ELF to do its modifications. However, it relies on source code to build patch objects whereas a snap-in does not require source code. Katana also uses a trampoline mechanism to modify the functions in running code. An advantage of Katana is cleaner migration of modified data from old to new functions; this feature will be incorporated in a future version of snap-ins.

Next Steps

The snap-in project is currently moving from a prototype to an initial release of the toolkit. The toolkit includes all the utilities, installation guides and sample use cases. The utilities, which are written in Python (version 2.7), are approximately 1,000 lines of code. The snap-in controller is written in C; its compiled executable is 75 KB. All releases of the toolkit will be available on GitHub (github.com/jpbdart/snapin).

Future versions of the snap-in toolkit will include:

New Algorithm for Collecting Thread Markers: The snapdata collection application uses a brute-force approach to search for thread markers and data that needs to be moved. A new algorithm will be incorporated that creates a network graph of the ELF binary; this should make the algorithm faster and more accurate.

Developers of new applications may add "quiescent points" as discussed in [START_REF] Hayden | A study of dynamic software update quiescence for multithreaded programs[END_REF]. This would simplify the work of the snapdata collection application because it would only have to search for the quiescent points in code instead of looking for thread markers. The developers would be implicitly guaranteeing that the quiescent points are safe places to stop the target executables as opposed to snapdata making educated guesses that stopping at thread markers would not cause execution problems.

Rollback of Application Repairs:

The current toolbox programs collect all the data necessary to perform rollbacks. Additional code will be incorporated to enable snap-in controllers to return applications to their original running states.

Repairs to Statically-Linked Code: Small Internet of Things devices and many real-time operating systems have code that is statically-linked to applications (i.e., no calls are made to external shared libraries). Efforts are underway to collect the internal program calls to facilitate code repairs.

Other Hardware Architectures: The current implementation targets the Intel x86 platform. The next hardware target will be ARM. The toolbox code, which is written in Python and C, should be portable to most hardware platforms.

Another area of research is the operation of snap-ins in highly-regulated systems, such as those used in the energy sector. For example, snap-ins cannot be incorporated in a power plant control system without evaluating the changes to be made and the liability incurred in making the changes. One possibility is to obtain approval from the regulator for repairs made using snap-ins. In such a scenario, the regulator would sign off on each snap-in, adding its own authorization key to the final code along with the entity that created the code. Thus, the power plant operator would only be able to install authorized snapins.

Future research will also investigate the compatibility of snap-ins with realtime operating systems. As mentioned above, research is currently focusing on repairs to statically-linked applications. Once this feature is added, the toolkit collection programs should obtain the target application data that is needed. However, research has to be conducted to see how the snap-in controller can make changes to systems with hard timing constraints.

Conclusions

Attacks on operational technology systems, especially those that provide essential services, are increasing in scope and frequency. Even the best systems and software age from a security point-of-view, enabling attackers to discover and exploit previously-unknown holes. Quickly repairing these systems and software is of prime importance.

Snap-ins are a powerful mechanism for quickly updating system applications that cannot be shut down or that do not have traditional maintenance plans in place. Emergency repairs such as vulnerability patches and program enhancements can be seamlessly delivered in real time by snap-ins without any downtime. Security measures that prevent tampering with the patches ensure that only the correct patches are delivered to the targeted hardware.

This chapter describes work sponsored by an agency of the United States Government. Neither the United States Government nor any agency thereof, nor any of their employees, make any warranty, express or implied, or assume any legal liability or responsibility for the accuracy, completeness or usefulness of any information, apparatus, product or process disclosed, or represent that its use would not infringe privately-owned rights. Reference herein to any specific commercial product, process or service by trade name, trademark, man-ufacturer or otherwise does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or any agency thereof. Additionally, the views and opinions of the authors expressed herein do not necessarily state or reflect those of the United States or any agency thereof.

Figure 2 .

 2 Figure 2. Creating an executable descriptor file.

Figure 3 .

 3 Figure 3. Sample executable descriptor file.

Figure 4 .

 4 Figure 4. Creating patch control files.

Figure 5 .

 5 Figure 5. Creating a replacement table.

Table 1 .

 1 Repair costs during various lifecycle stages.

	Lifecycle Stage	Repair Cost
	Requirements	1x
	System Testing	90x
	Installation Testing	90x to 440x
	Acceptance Testing	440x
	Operation and Maintenance 470x to 880x

Table 2 .

 2 ELF segments used by snap-ins.

	Segment Writable Definition
	.header	No	ELF header and segment table
	.hash	No	Symbol hash table
	.dynsym	No	Dynamic linking symbols
	.dynstr	No	Dynamic linking strings
	.plt	No	Procedure linkage table
	.text	No	Executable code
	.rodata	No	Read-only data
	.data	Yes	Initialized data
	.got	Yes	Global offset table
	.got.plt	Yes	Global offset table for procedure linkage table
	.dynamic	Yes	Dynamic linking information
	.bss	Yes	Uninitialized data
	application, injects the new libraries, modifies the function addresses to
	point to the new libraries and then resumes the target application.

Table 3 .

 3 Use of public/private key pairs.

	System Function	Signer	Verifier
	Target Machine	Executable descriptor file Replacement table
	Configuration Manager Patch control file	N/A
	Replacement Table	Replacement table	Executable descriptor file,
			patch control file

Acknowledgement

This research was supported by the Office of Cybersecurity, Energy Security and Emergency Response of the U.S. Department of Energy and by the Directorate of Security Science and Technology of the U.S. Department of Homeland Security under Award No. DE-OE0000780.


Seungoh Choi

Yesol Kim

Jeong-Han Yun

Byung-Gil Min

Hyoung- Chun Kim

DATA-DRIVEN FIELD MAPPING OF SECURITY LOGS FOR INTEGRATED MONITORING

Keywords: Security, event logs, integrated system monitoring

As industrial control system vulnerabilities and attacks increase, security controls must be applied to operational technologies. The growing demand for security threat monitoring and analysis techniques that integrate information from security logs has resulted in enterprise security management systems giving way to security information and event management systems. Nevertheless, it is vital to implement some form of pre-processing to collect, integrate and analyze security events efficiently. Operators still have to manually check entire security logs or write scripts or parsers that draw on domain knowledge, tasks that are time-consuming and error-prone.

To address these challenges, this chapter focuses on the data-driven mapping of security logs to support the integrated monitoring of operational technology systems. The characteristics of security logs from security appliances used in critical infrastructure assets are analyzed to create a tool that maps different security logs to field categories to support integrated system monitoring. The tool reduces the effort needed by operators to manually process security logs even when the logged data generated by security appliances has new or modified formats.

Introduction

The vulnerabilities of industrial control systems used in critical infrastructure assets and the sophistication of attacks have increased significantly in recent years. In 2016, the U.S. Department of Homeland Security's ICS-CERT reported 257 new vulnerabilities in industrial control systems [9]. Meanwhile, new operating environments and wireless technologies used in industrial control systems are increasing their attack surfaces.

Security devices are being incorporated in operational technology environments to combat cyber threats to industrial control systems and the critical infrastructure assets they manage. The growing demand for security threat monitoring and analysis techniques that integrate information from security logs has resulted in enterprise security management systems giving way to security information and event management (SIEM) systems, whose security logs contain valuable information about the security status and traceability of the operating environments. The information, which is in structured or unstructured formats, helps detect anomalies and analyze the causes of security incidents, contributing to the development of appropriate countermeasures. Big data technologies are actively being applied to security log datasets to enhance attack detection, security incident investigations and mitigation techniques.

However, operators of critical infrastructure assets have great difficulty integrating the diverse formats of security data in multiple device logs to perform security monitoring and analyses. Figure 1 shows the challenges involved in integrating security log data of different formats. The fields in white are specific to security devices whereas the fields in grey are common to security devices. However, the levels of risk have different data types and semantics.

Although standards exist for presenting security event information from individual devices, the standards may not be supported by device manufacturers and/or the formats may differ considerably. Even in the case of the Common Event Format (CEF) [START_REF] Arcsight | Common Event Format[END_REF], which is designed to support interoperability in security information and event management systems, different manufacturers use different extension fields. Manufacturers that use the Syslog standard often add new fields according to their needs. The formats and contents of security events also differ based on the security policies applied at field sites where the devices are configured and operated.

Additionally, even when security logs have data fields with the same semantics, the logs are difficult to integrate because the data is in different formats. For example, data in an attack severity field may be expressed numerically as 1, 5 and 10 in one log, but may expressed using the strings "caution," "severe" and "serious" in another log. Such correspondences cannot be solved simply by identifying the same expression type in order to analyze the fields correctly.

Furthermore, depending on the nature of the infrastructure assets, various security devices are employed to enhance security or monitor the operating environments; this requires the integration of diverse security logs. The problems are acerbated because it is often difficult to acquire data specifications from manufacturers. As a result, operators require pre-processing modules for the security logs or they have to apply manual efforts that draw on their knowledge and experience.

In order to overcome these problems and support integrated security monitoring, security logs were examined to identify the target fields needed for security analysis and context awareness. The results were used to create a tool that derives the characteristics of security logs and identifies fields that match the target fields. The tool enhances security monitoring by enabling the integration of security logs and new formats in security logs from newly added or replaced security devices while minimizing the manual effort required on the part of developers.

Related Work

RFC 4765 [START_REF] Debar | The Intrusion Detection Message Exchange Format (IDMEF)[END_REF] published in 2007 by the Internet Research Task Force (IETF) specifies the Intrusion Detection Message Exchange Format (IDMEF) as an information exchange standard for operating and managing security devices and systems (e.g., intrusion detection systems (IDSs) and intrusion prevention systems (IPSs)). IDMEF specifies the heartbeats that pass status information between equipment and systems, and alerts that pass network attack detection information. In 2008, MITRE released the Common Event Expression (CEE) format [START_REF]The CEE Board, Common Event Expression[END_REF] that expresses and standardizes log exchanges between systems and end users, log providers and security information and event management system vendors. CEE provides a common representation language through the profile, Common Log Syntax (CLS) and Common Log Transport (CLT) throughout event handling, including event structuring, event encoding/decoding and event transmission. In 2013, MITRE introduced the Structured Threat Information Expression (STIX) format for organizing and expressing cyber threat information. STIX has been adopted for the trusted automated exchange of indicator information about cyber threats in real time.

Other entities have developed and released common event specifications. Some of the important specifications are:

Common Event Format (CEF): ArcSight [START_REF] Arcsight | Common Event Format[END_REF] designed CEF for logging and audits, and for security information and event management. CEF is primarily used with Syslog and provides custom fields for scalability.

Log Event Extended Format (LEEF): IBM [START_REF]International Business Machines, IBM QRadar: Log Event Extension Format (LEEF), Version 2[END_REF] developed LEEF as a custom event format for its Security QRadar products.

Cisco Intrusion Detection Event Exchange (CIDEE):

The Cisco CIDEE format [START_REF]Cisco Systems, Cisco Intrusion Detection Event Exchange (CIDEE) Specification[END_REF] extends the Security Device Event Exchange (SDEE) standard that provides specifications for the formats and protocols used to exchange events. CIDEE is a custom event format that is used by Cisco intrusion prevention systems to exchange intrusion information.

Commercial vendors of security appliances typically do not comply strictly with the standards for security log formats. There are some similar fields and formats, but the details are different for each vendor, product and version. Since security devices are not designed to interoperate with devices from other manufacturers, the formats of individual fields in the security information they generate are not disclosed.

Plaintext protocol reversing efforts have been conducted to extract information from communications protocols [START_REF] Caballero | Polyglot: Automatic extraction of protocol message format using dynamic binary analysis[END_REF][START_REF] Li | Automatic protocol feature word construction based on machine learning[END_REF]. Most research efforts have focused on open-text protocols such as SMB and HTTP. However, recent studies have attempted to obtain information about private communications protocols between command and control servers and bots in order to detect and respond to distributed denial-of-service (DDoS) attacks by botnets [START_REF] Caballero | Dispatcher: Enabling active botnet infiltration using automatic protocol reverseengineering[END_REF][START_REF] Caballero | Automatic protocol reverse-engineering: Message format extraction and field semantics inference[END_REF][START_REF] Sood | Dissecting SpyEye -Understanding the design of third generation botnets[END_REF]. These studies concentrate on the field separation of communications data and analyzing the context or state from server-client conversations. As a result, this work cannot be applied to map different security log formats to a single field required for monitoring purposes.

Analysis of Field Characteristics

Four security appliances that are widely used in critical infrastructure assets were employed to analyze the characteristics of the fields in security logs. Ixia's Ixload, which can reproduce security violation situations, was used to enable the appliances to generate security logs.

Table 1 summarizes the attacks used in this research. They include 13 wellknown flooding attacks and 6,740 vulnerabilities and malware attacks.

A total of 1,146,019 security logs were collected in the experimental environment over a ten-hour period. Table 2 shows a summary of the security logs. Note that the number of collected security logs differs from one security device to another due to differences in the types, numbers and detection methods of the security policies supported by the device vendors.

Target Fields in Security Logs

Analysis of the four types of security logs collected in the experimental environment confirmed that structural differences exist, e.g., for field numbers, types and contents. For security reasons, only limited information -not the detailed field structures -are described in this chapter. F i r e w a l l I V 1 8 8

Table 3 shows the target fields in the security logs. Note that the IDS/IPS from A has the fewest fields (13) whereas the IDS/IPS from B has the most fields (34), more than 2.6 times more fields than A. The IDS/IPS from C has more fields (27) because its manufacturer uses various field structures in its devices according to their models and functions. Furthermore, even if each security log has the same field name, the field type or content may be different. For example, the Protocol field is represented differently by case-sensitive strings or numbers, such as "TCP" or "Tcp" or 6, depending on the manufacturer.

It is not necessary to use all the fields because other fields in a log may contain the associated information. For example, when ID-Rule and Name-Rule have the same meaning, ID-Rule is the key value that uniquely distinguishes the security policy whereas Name-Rule is an annotation used by administrators for easy recognition.

There may be unnecessary fields in terms of the semantics when performing integrated security monitoring. For example, Type-CategoryAttack is mainly used to classify detection results. However, it does not precisely classify and identify the attack type because the classification is too broad. In the case of Length-RawPacket, there are some difficulties in deriving a security threat by only examining the packet length.

Therefore, original field structure analyses were performed for three IDS/IPS devices and one firewall from the perspective of security monitoring and analysis. This resulted in the exclusion of three (minimum) to 17 fields (maximum). A field that was not included in all the security logs was excluded, but it was retained if it was deemed necessary for security monitoring and analysis.

Field Categories in Security Logs

In order to categorize the target fields listed above, the meanings of the 47 target fields in the security logs were analyzed. The target fields could be represented using 17 field-category-consolidated fields. Table 4 shows the categories of fields included by the manufacturers along with their contents. Seven categories of fields were included in all the security logs -Time-Sent, IP-Attacker, IP-Victim, Port-Attacker, Port-Victim, Type-AttackProtocol and Type-Action. The other categories of fields were included in some of the security logs.

The analysis also confirmed that the field categories depended on the types of security devices. The field categories of the security logs generated by IDS/IPS devices mainly deal with attack-related information such as the attack name, type and direction. On the other hand, certain categories of log fields were common regardless of the types of security devices. For example, ID-Rule was generated by IDS/IPS devices for the signature-based detection function. In the case of the firewall with an access-control-list-based security policy, ID-Rule was used even in the deny rules.

Syntax of Field Categories

The data types and main features of the fields in the security logs were analyzed in order to map field information such as field name and field meaning based on the field categories.

First, the field data types were analyzed and classified as String and Number as shown in Table 5. The String type is divided into Word (single length of text that does not contain spaces) and Sentence (collection of words separated Second, the field data was analyzed based on the field categories. The analysis yielded the data types shown in Table 6. To enhance understanding, each field category is arranged according to its type. The analysis confirmed that the field categories and types cannot be matched uniquely due to the different data formats in the security logs produced by the appliances. number of attacks detected per unit time varies, so various values (including zero) could result.

Finally, characteristics were extracted from statistical patterns. The fields Port-Attacker, Port-Victim and Count-TotalAttack, which are mapped only to the Variable type, have different characteristics in terms of distributions of values (e.g., variance, skewness and kurtosis). Figures 2 and3 show the significant differences that exist in the value distributions.

Tables 7 and8 summarize the characteristics of the field categories.

Mapping Security Logs to Field Categories

This section demonstrates how security logs are mapped to field categories via data-driven analysis of the security logs.

Overview

The data-driven mapping of security logs to field categories involves three phases:

Phase 1: Field Preparation: During this phase, the security log that is the subject of the field mapping is received as input. The security log is parsed to remove delimiters and produce individual fields.

Phase 1: Field Preparation

During the field preparation phase, the raw security log is processed as an input for the subsequent field analysis phase (Figure 4). Since raw security logs have different formats depending on the manufacturer and device model, they have to be grouped into the same format. The grouped security logs are separated into fields based on delimiters. The data is organized in a structure (e.g., matrix or data frame) that simplifies the analysis based on the field type that is conducted in the next phase.

Raw Security Logs

Grouped Security Logs

Segmented Security Logs

Phase 2: Field Analysis

During the field analysis phase, the field type is first analyzed based on the field data. Following this, the field characteristics are analyzed to assign the field characteristics based on Tables 7 and8.

After the field data type analysis is complete, field category candidates are identified and mapped according to the individual field types. However, as described above, there could be multiple candidates for a given field. For this reason, the field data characteristics also have to be analyzed.

The priority and frequency of data are assigned to each field of the String type (e.g., Word, Sentence, Keyword, IP and Time). Because the Variable type has multiple numerical values, the minimum and maximum, variance and skewness of the values are as recorded as characteristics.

Phase 3: Field Mapping

During the field mapping phase, the final type of each field is considered according to the priority of the candidate field category by analyzing the field type and characteristics provided by the field analysis phase. Upon applying the proposed method to the four security logs considered in this work, the field types were mapped as shown in Figures 5 through 8. The mapped candidates are presented in order of priority according to the data characteristics.

Table 9 summarizes the results of mapping security logs to field categories. As seen in the table, when the correct field categories were mapped to the first because the fields have the same semantics but different types. The limitations are discussed in the following section.

Discussion

The three principal discussion points are:

Dictionary for Semantics: The semantics of the same fields in the security logs must be reconciled. Fields may be semantically equivalent based on predefined information that is commonly used, such as standards and specifications, but there may be differences in the field categories. For example, in the case of the Type-AttackProtocol field, "HTTP" in the String type and 80 in the Number type have to be considered as having the same meaning. However, the semantics of fields can be different regardless of the field types according to the predefined information from the manufacturer. For example, in the case of the Type-Action field, even if the field type is Number and the value is 1, then the field meaning can be changed by the "Deny" or "Allow" characteristics, depending on the predefined information. In the case of the Level-Risk field, a value of 1 for the Number type may correspond to "Low" or "High" depending on the predefined information.

Correlated Analysis of Fields:

A priori information and the analysis results can support field inference. The analysis of security logs produced by the IDS/IPS device created by manufacturer A confirms that security events are configured in a key-value manner. In other words, since the key is already known, it is possible to derive the characteristics of the value corresponding to the key and to apply it to infer the fields in the same or other security logs with similar characteristics. The fields can be more accurately inferred using security log fields that are related to each other. For example, it is possible to apply association analysis between an IP (address) field type and a Variable field type such as Port-Number with the range 1 to 65,536 for more precise classification of an attacker or a victim.

Manual Field Mapping Process: This research is a preliminary attempt to support integrated monitoring of critical infrastructure assets because only four major security appliances were considered. In a realworld environment, monitoring personnel must handle all the formats in the security logs maintained in critical infrastructure assets. This is a highly manual process that relies on domain knowledge and experience.

Although the proposed approach has involved some manual analysis, it is still a useful first step to removing dependencies and providing useful information that can reduce operator error.

Conclusions

The data-driven mapping of security logs can support the integrated monitoring of operational technology systems in the critical infrastructure. The characteristics of security logs from security appliances used in critical infrastructure assets have been analyzed to create a tool that maps different security logs to field categories based on their field types and characteristics. This enables events in multiple security logs to be integrated automatically. Moreover, it reduces the effort on the part of operators to manually process security logs for integrated security monitoring when the logged data generated by existing or new security appliances have diverse formats. Future research will focus on improving the field mapping tool by considering a variety of security appliances and critical infrastructure assets and applications.

Figure 1 .

 1 Figure 1. Challenges involved in integrating security log data of different formats.

Figure 2 .

 2 Figure 2. Field characteristics in security log format II.

Figure 3 .

 3 Figure 3. Field characteristics in security log format III.

Phase 2 :

 2 Field Analysis: During this phase, the type of each field in the security log is classified. The classification results are mapped to the data characteristics. Details about the fields are presented in Section 3.2.

Figure 4 .

 4 Figure 4. Field preparation using security logs.

Figure 5 .Figure 6 .Figure 7 .Figure 8 .

 5678 Figure 5. Results of mapping field categories in the security log with format I.

Table 1 .

 1 Summary of attacks.

	Protocol Attack
	ARP	ARP flooding attack
	ICMP	Fragmented ICMP message attack
		Ping of death attack
		Smurf attack
	IGMP	Fragmented IGMP message attack
	IP	Fragmented IP message attack
		Teardrop attack
	TCP	Fragmented ACK flooding attack
		LAND attack
		SYN flooding attack
		Xmas tree attack
	UDP	UDP flooding attack
		UDP fragment attack

Table 2 .

 2 Summary of security logs.

	Manufacturer Device		Security Logs
			Format Total (Proportion)
	A	IDS/IPS	I	117,850 (0.10)
	B	IDS/IPS	II	672,624 (0.59)
	C	IDS/IPS	III	52,801 (0.05)
	C	Firewall	IV	302,744 (0.26)

Table 3 .

 3 Target fields in security logs.

	Manufacturer Device		Security Log Fields
			Format Number Targets
	A	I D S / I P S	I	1 3	1 0
	B	IDS/IPS	II	34	17
	C	IDS/IPS	III	27	12
	C

Table 4 .

 4 Categories of fields in the security logs. The Keyword type is a subtype of the Word type when the text is unique. In addition, special subtypes such as Time and IP are included for the String type. The Number type has the subtypes Constant (fixed numerical value) and Variable (variable numerical values).

	Field Category	Security Log Format Information
	Major Minor	I II III	IV
	Time	Sent				Time of sent log
		Attack	-	-	-	Time of attack start
		AttackEnd	-	-	-	Time of attack end
	IP	Detector	-	-	-	IP address of device
						that detected attack
		Attacker				IP address of attacker
		Victim				IP address of victim
	Port	Attacker				Port number of attacker
		Victim				Port number of victim
	Name Machine	-	-	-	Name of device that
						detected attack
		Attack			-	Name of detected attack
	Type	Attack	-		-	Type of detected attack
		AttackDirection	-		-	Type of detected attack
		AttackProtocol				Type of transport
						protocol
		Action				Type of action against
						detected attack
	Level	Risk			-	Level of severity of
						detected attack
	Count TotalAttack	-		-	Total number of
						detected attacks
	ID	Rule		-		Rule ID that detected
						attack
	by spaces).

Table 7 .

 7 Characteristics of field categories.

	Field Category	Type	Characteristics
	Major Minor
	Time	Sent	Time	Highest priority among fields of the
				Time type
	Time	Attack	Time	Corresponds to earlier time among
				fields of the Time type, except for
				the Time-Sent field
	Time	AttackEnd	Time	Corresponds to later time among
				fields of the Time type, except for
				the Time-Sent field
	IP	Detector	IP	Value of the IP type field is one
				(unique); predefined IP address
				resolution is required
	IP	Attacker	IP	Does not include a specific string
				(.1, .255); predefined IP address
				resolution is required
	IP	Victim	IP	IP fields except for IP-Detector and
				IP-Attacker; predefined IP address
				resolution is required
	Port	Attacker	Variable Fields with range 0-65,536; occurrence
				distribution is forward
	Port	Victim	Variable Fields with range 0-65,536; occurrence
				distribution is backward
	Count	TotalAttack	Variable Fields with 1-max range; kurtosis is
				high
	Type	AttackProtocol Word	Fewer word values and higher frequen-
				cies of occurrence; predefined protocol
				name verification is required
			Variable Fields with range 0-255; fewer num-
				bers of values and higher frequencies
				of occurrence

Table 8 .

 8 Characteristics of field categories (continued).

	Field Category	Type	Characteristics
	Major Minor
	Level	Risk	Word	Distribution is biased
			Variable Fields with range 1-5 (10);
				distribution is biased
	Type	Action	Word	Distribution is biased; predefined
				information verification is required
			Variable Number of field values is low;
				distribution is biased
	ID	Rule	Word	Meaningless text; no predefined
				information
			Variable Fields with range 65,536-max;
				lowest priority among fields of
				the Variable type
	Name Attack	Word	Predefined attack name verification
				is required
			Sentence Highest priority among fields of
				the Sentence type
	Type	Attack	Word	Low priority among fields of the
				Word type
			Sentence Longest text among fields of the
				Sentence type
	Name Machine	Keyword Highest priority among fields of
				the Keyword type
	Type	AttackDirection Word	Predefined string (E,I) verification
				is required

Phase 3: Field Mapping: During this final phase, a field category is identified by combining the mapped type and data characteristics. The output is a candidate field category for each field.

Table 9 .

 9 Results of mapping security logs to field categories.

	Security Log
	Format

Total Fields Correctly Mapping to Field Category 1st Candidate 2nd Candidate Total (%)

	I	10	9	0	9 (90)
	II	17	16	1	17 (100)
	III	12	9	3	12 (100)
	IV	8	6	1	7 (87.5)
	Total	47	40	5	45 (95.74)

CRITICAL INFRASTRUCTURE PROTECTION XIII

Semantics of Field Categories

The data characteristics are prominent in the case of a field category that maps to the Number type. To clarify the semantics, features were extracted from predefined information such as the communications protocol. The fields Port-Attacker and Port-Victim use numbers in the range 1 to 65,536 corresponding to two bytes of storage. On the other hand, Type-AttackProtocol has values from 0 to 255 because its values are represented by one byte in the IP headers.

Next, a situation was considered where a security event was generated in the operational environment as a result of an attack. Count-TotalAttack is always greater than zero because a security event occurs during an attack. Also, the


Alice Rogier

Adrien Coulet

Bastien Rance

Using an ontological representation of chemotherapy toxicities for guiding information extraction and integration from EHRs

Keywords: Knowledge Discovery, Drug-Related Side Effects and Adverse Reactions, Electronic Health Records

Introduction. Chemotherapies against cancers are often interrupted due to severe drug toxicities, reducing treatment opportunities. For this reason, the detection of toxicities and their severity from EHRs is of importance for many downstream applications. However toxicity information is dispersed in various sources in the EHRs, making its extraction challenging. Methods. We introduce OntoTox, an ontology designed to represent chemotherapy toxicities, its attributes and provenance. We illustrated the interest of OntoTox by integrating toxicities and grading information extracted from three heterogeneous sources: EHR questionnaires, semi-structured tables, and free-text. Results. We instantiated 53,510, 2,366 and 54,420 toxicities from questionnaires, tables and free-text respectively, and compared the complementarity and redundancy of the three sources. Discussion. We illustrated with this preliminary study the potential of OntoTox to guide the integration of multiple sources, and identified that the three sources are only moderately overlapping, stressing the need for a common representation.

Introduction

Chemotherapies against cancers are often interrupted or reduced due to the onset of severe drug toxicities, reducing treatment opportunities for patients, and limiting the therapeutic choices for the clinicians. Chemotherapy regimens involve complex combinations of drugs. Iatrogenic toxicities (adverse drug reactions) are reported and categorized using the Common Terminology Criteria for Adverse Events (CTCAE) [START_REF] Basch | Development of the National Cancer Institute's Patient-Reported Outcomes Version of the Common Terminology Criteria for Adverse Events (PRO-CTCAE)[END_REF] according to their severity into five grades, from one being benign side effects, to five the death of the patient.

Toxicities are collected in a very controlled and structured manner in clinical studies, but not in every day care. This makes challenging the secondary use of this information for retrospective studies or for the development of clinical decision support systems.

Today Electronics Health Records (EHRs) offer unprecedented opportunities for using patient data to study variable patient outcomes, including drug response. Information about chemotherapy response and adverse drug reaction occurrences is present, but not directly available in CDWs (Clinical Data Warehouses). This information is present in a variety of sources and formats from structured to unstructured, including structured clinical questionnaires, tables and text of narrative reports.

Several terminologies and ontologies have been developed to facilitate the reporting of adverse drug reactions. The Medical Dictionary for Regulatory Activities (MedDRA) [START_REF] Brown | The Medical Dictionary for Regulatory Activities (MedDRA)[END_REF] is used to describe adverse events in all types of pathologies. Prior to MedDRA, the World Health Organisation Terminology (WHOART) was used as the reference to code adverse reactions. In oncology, physicians can use the CTCAE to categorize the severity of toxicities, using precise description and laboratory values. Note that the CTCAE shares links to MedDRA. The representation of chemotherapy treatments and adverse reactions has received a great deal of attention over the years. For example, HemOnc [START_REF] Warner | org: A Collaborative Online Knowledge Platform for Oncology Professionals[END_REF] was introduced as an ontology on general information relevant to oncology. HemOnc recently adapted its chemotherapy content to the OMOP data model. Meanwhile, there has also been a growing interest in results provided by narrative reports extraction associated with NLP tools [START_REF] Datta | A frame semantic overview of NLP-based information extraction for cancer-related EHR notes[END_REF] and not only in the oncology field [START_REF] Neuraz | Natural Language Processing for Rapid Response to Emergent Diseases: Case Study of Calcium Channel Blockers and Hypertension in the COVID-19 Pandemic[END_REF].

NLP tools have also been used to populate medical ontologies. In particular, Monnin et al. [START_REF] Monnin | PGxO and PGxLOD: a reconciliation of pharmacogenomic knowledge of various provenances, enabling further comparison[END_REF] created a formal ontology that supports the comparison of pharmacogenomics adverse events heterogeneously reported in the literature.

The correct detection of toxicity events and of their severity is of utmost importance to improve cancer treatment. However, to the best of our knowledge, there is no ontology that aims at describing chemotherapy toxicities and their attributes. Although, such a representation is needed to allow the integration of information from heterogeneous sources.

In the work reported here, our objectives are twofold: [START_REF] Basch | Development of the National Cancer Institute's Patient-Reported Outcomes Version of the Common Terminology Criteria for Adverse Events (PRO-CTCAE)[END_REF] we introduce OntoTox, a simple ontology designed to represent chemotherapy toxicities and their attributes, and (2) we demonstrate the interest of OntoTox in a clinical use-case to gather and compare information regarding chemotherapy toxicities found in three types of heterogeneous sources from EHRs: structured clinical questionnaires, tables and free-text from narrative reports (semi-structured and unstructured respectively).

Materials The Clinical Data Warehouse at the European Hospital Georges Pompidou

The European Hospital Georges Pompidou (or HEGP) is a 700 beds teaching hospital located in Paris. It is specialized in oncology, cardiovascular diseases and emergency medicine. The hospital has deployed since 2008 a clinical data warehouse based on i2b2 [START_REF] Murphy | Serving the enterprise and beyond with informatics for integrating biology and the bedside (i2b2)[END_REF] integrating virtually all the data generated during everyday care. Among all the data sources, patients in oncology are associated with narrative reports, such as discharge summaries or histology reports, which include free text sections and semi structured tables and clinical questionnaires. Such questionnaires are well structured and some of them collect chemotherapy toxicities associated with their grades. Answers for such questionnaires are collected by caregivers the day before chemotherapy administrations.

Cohort definition

We queried the data warehouse using ICD code C34 ("Malignant neoplasm of bronchus and lung"), and its descendants to identify 3,239 patients treated for lung cancers. Out of the 3,239, we identified 470 patients with at least one narrative report and one questionnaire about chemotherapy toxicity. Out of 470, we randomly selected 330 patients to constitute our studied cohort. We left out 140 for a future evaluation (out of the scope of this work). For each patient, all narrative reports and toxicity questionnaires were extracted, representing 11,819 narrative reports and 71,140 questionnaire items.

Toxicities vocabulary sources

We relied on two reference terminologies to identify toxicity terms in French: the 5th version of CTCAE and WHOART. These two terminologies respectively brought 366 and 1,827 terms.

Methods

In this section, we first introduce OntoTox, our simple ontology to represent chemotherapy toxicities and their attributes. We then present a use case with the extraction of toxicities and their grading from three heterogeneous sources: clinical structured questionnaires, semistructured tables extracted from narrative reports, freetext from same reports; and their integration following the schema defined by OntoTox.

The OntoTox Ontology a shared conceptualisation Specification

The aim of the OntoTox ontology is to unify the information extracted toward toxicities and their grade from distinct sources. To this aim, we need OntoTox [START_REF] Basch | Development of the National Cancer Institute's Patient-Reported Outcomes Version of the Common Terminology Criteria for Adverse Events (PRO-CTCAE)[END_REF] to guide the normalization of extracted toxicities (2) to encode provenance information.

Conception, implementation and import of external ontologies

The ontology was implemented in OWL using Owlready [START_REF] Lamy | Owlready: Ontology-oriented programming in Python with automatic classification and high level constructs for biomedical ontologies[END_REF], a module for ontology management in Python and Protégé, the ontology editor [START_REF]The protégé project: a look back and a look forward[END_REF]. OntoTox is composed of 11 classes which are organized around the central class ChemotherapyToxicity. OntoTox also includes 8 object and data properties that serve to qualify toxicities. To this aim, the ChemotherapyToxicity class can be linked to Grade, StartDate and Patient classes through object properties. Grade class has 7 subclasses that are Grade0, Grade1, Grade2, Grade3, Grade4, Grade5 and GradeNull. GradeNull corresponds to the absence of a detected grade, whereas Grade0 denotes the explicit report of a grade 0, i.e. the absence of this toxicity, which is commonly found in questionnaires and tables. ChemotherapyToxicity instances can be associated with different data properties to characterize the context of the extraction of the toxicity (e.g., isNeg, isHyp qualify the fact that the toxicity may be extracted as a negated or a hypothetical fact). StartDate and Patient classes are instantiated using documents metadata. To identify the set of classes and properties necessary to represent toxicity information of various provenance, we selected randomly a small set of EHR (n=20) that we reviewed to instantiate manually the ontology. We instantiate UMLS and MedDRA concepts with OntoTox toxicities leveraging the PymedTermino library [START_REF] Lamy | PyMedTermino: an open-source generic API for advanced terminology services[END_REF]. An example of the instantiation of OntoTox is illustrated in Figure 1. OntoTox is available at https://github.com/TeamHeka/OntoTox.git .

Provenance encoding

OntoTox serves as a global schema for the integration of information from various sources. In such a context, preserving the information regarding the provenance is crucial. We used the PROV-O ontology [START_REF] Lebo | PROV-O: The PROV Ontology[END_REF], an ontology dedicated to express provenance in virtually all the realms of science. Here, we consider the chemotherapy toxicity extraction as an entity generated by our extraction algorithm, which itself is an Activity. The input of the extraction algorithm is an entity that is, in the context of our use case, either a free text, a table or a form.

Extraction and integration of heterogeneous toxicities guided by OntoTox

Recognition of entities of interest

In this initial stage of our work, we only identified two types of entities of interest: toxicities and grades. Both are recognized by the same method independently from the considered source. We created a toxicities dictionary based on our toxicities sources terminologies (see Materials), and enriched it with synonyms to 4,038 terms mapped on 835 UMLS concepts thanks to PymedTermino. We relied on QuickUMLS [START_REF] Soldaini | QuickUMLS: a fast, unsupervised approach for medical concept extraction[END_REF], to extract toxicity entities using this dictionary. QuickUMLS is a Python tool leveraging Simstring [START_REF] Okazaki | Simple and efficient algorithm for approximate dictionary matching[END_REF] for approximate string matching. It was applied with a length overlapping criteria, jaccard distance similarity and a 0.9 threshold parameter. In addition to the identification of the toxicity, the dictionary approach also provided us with UMLS Concept Unique Identifier, enabling some normalization of the toxicities. We used a Figure 1 -Main structure of OntoTox, and an example of its instantiation with the following free text: "oesophagite de grade II" regular expression to detect grades, and normalized them according to their numeric value.

Extracting data from toxicities EHR questionnaires to instantiate OntoTox

We identified two EHR questionnaires directly related to chemotherapy toxicities. The questionnaires are composed of toxicity items (questions), and their values (answers) correspond to grade levels. We parsed the questionnaires and instantiated OntoTox accordingly.

Extracting data from narrative reports to instantiate OntoTox

Free text extraction. We leveraged QuickUMLS and PyMedExt1 , a Python library designed to process clinical text, to process the text. PyMedExt includes annotators to detect polarity (negation, affirmation), the experiencer (patient, family) and hypothesis in French. We leveraged the Stanza dependency parser to link toxicity entities and their grades [START_REF] Qi | Stanza: A Python Natural Language Processing Toolkit for Many Human Languages[END_REF] Stanza is a Python natural language analysis library that uses the Universal Dependencies formalism [START_REF] Nivre | Universal Dependencies v1: A Multilingual Treebank Collection[END_REF]. We processed all the sentences that contained at least one toxicity entity. The dependency parser provided the syntaxical structure of the sentences. We selected recursively all the entities that were under the head of the toxicity entity (see Figure 2). We linked the toxicity and grade if a path exists between the two entities.

Tables extraction. Our method to process free-text is not suitable to semi-structured tables. We identified and extracted all the tables from the original documents. We identified tables related to toxicities by searching for the terms effets indésirables (adverse event), grade, liée au traitement (induced by treatment) date de début (starting date) date de fin (ending date), in the header of the tables. These terms are found in the default template of the oncology department. We mapped each toxicity to a UMLS concept with QuickUMLS, and parsed the other pieces of information.

Unifying information from the three sources in OntoTox

We instantiated the ontology with inputs from the three sources. Each toxicity extracted from the three sources is thus an instance of the OntoTox ChemotherapyToxicity class. If this toxicity has been found to be related to a grade, a grade subclass is instantiated according to the associated number that is also extracted and normalized. Furthermore, we instantiated Patient and StartDate classes with questionnaire and document metadata. Depending on the source, data property of the ChemotherapyToxicity individual may differ according to specific attributes. For instance, individuals ChemotherapyToxicity instantiated with free text have boolean data properties covering the information about negation, context and hypothesis. We compared the distinct toxicities observed per month and per patient to evaluate the contribution of the three sources (see Figure 3). A toxicity is considered to be present in two distinct sources if the two sources share an instance of a specific toxicity within the same year and month.

Results

Extraction and integration of heterogeneous toxicities guided by OntoTox

Unifying information of OntoTox in the three sources

To generate the graph below, we selected UMLS concepts per Patient and per StartDate month grouped by sources by SPARQL querying OnoTox.

Discussion

Enriching OntoTox

With comparison use-case, we illustrated that classes and properties of OntoTox may be used to guide the integration of chemotherapy toxicities information of various provenances. In this initial effort, we focused on the extraction and integration of the type and grade of toxicities. Of course, more qualification of the toxicity, such as its associated treatment, and its duration are required to provide a view of the potentially available information. We plan on enriching progressively OntoTox, while we develop scripts adapted to various toxicity attributes.

Evaluating the quality of the extraction

Note that this work is not aiming at evaluating or achieving the best performances in recognizing entities related to toxicity, but rather at showing their possible integration in OntoTox. However, we are conscious that our approach, based on dictionary matching and regular expressions, is simple. Advanced approaches for named entity recognition and relation extraction would enable us to improve the quality of our extraction. To assess probable gain in performance and choose most adequate approaches, we plan on manually annotating EHR and its various sources of toxicity. Such annotation could also serve as a training set for supervised or semisupervised approaches. Despite our lack of evaluation, our experiments let us think that the use of dependency graphs help in disambiguating the extraction of the grade. Indeed, in oncology, grades may also qualify tumor stages. We avoid such false positives thanks to dependency graphs that verify that grades are connected to toxicity, and not tumors. In particular, additional statistics showed that only 7,809 of the 53,687 recognized grades were linked to a toxicity entity, recognized by our dictionary. Moreover, we think that dependency graphs could be beneficial to detect other qualifiers of interest. For instance, in Figure 2, we note the adjective "peptique" that could help qualify our toxicity. Possibly, we could also combine dependency graphs with a temporal tagger such as HeidelTime [START_REF] Strötgen | HeidelTime: High Quality Rule-Based Extraction and Normalization of Temporal Expressions[END_REF] to extract StartDate with better precision. Similarly, we could detect drug entities inspiring Lerner and al [START_REF] Lerner | Learning the grammar of prescription: recurrent neural network grammars for medication information extraction in clinical texts[END_REF], and instantiate a Drug class.

Instantiating and unifying OntoTox with the three sources

Table 1 shows the number of OntoTox class instantiations by source. We note that free text and questionnaires brought far more information about toxicities than tables. However, toxicities free text extraction are mostly not associated with the grade. This table highlights that questionnaires are structured data. Indeed, a grade instance is always associated with a toxicity instance. Figure 3 summarizes the contribution of the three sources. We note that there is far more information brought by free text and questionnaires alone. This can be explained by different reasons. The StartDate is a metadata that is not precise enough. Chemotherapy treatments are constituted of alternative few days cure and few weeks inter-cure events. Sides effects can occur all along the treatment. However, both questionnaires we selected were used by caregivers to collect toxicity events the day before their chemotherapy cure. Thus, the toxicity events collected in these questionnaires could have occurred in a different date. On the scale of the chemotherapy treatment, the gap between the two dates matters. Furthermore, maybe UMLS concept normalisation is not sensitive enough. For instance, "souffle court" (C0013404 "breathless") and "difficulté à respirer" (C0013428 "difficulty breathing") have a different identifier, whereas, in our context, they should be gathered.

Why an ontology ?

We chose to create and instantiate an ontology rather than another data model to represent the field of chemotherapy toxicity. One reason for this choice is that we could easily link our ontology to other knowledge models, as PROV-O MedDRA and the UMLS. Furthermore, this enables the further use of a reasoner.

For instance, SWRL rules could be implemented to deduce CTCAE criteria knowing the grade and MedDRA concept of a toxicity.

Conclusion

In this article we introduced OntoTox, a simple ontology to represent chemotherapy toxicities. We show that this ontology can guide the integration of information from various data sources. OntoTox is rather small, but aim at being enriched to enable integrating a maximum of information qualifying chemotherapy toxicities and response that can be found in EHRs. OntoTox constitutes the seed of a valuable resource for oncology research and will further serve as a brick of a clinical decision support software.

Figure 2 -

 2 Figure 2 -Link toxicity to its grade thanks to dependency parsing.

Figure 3 -

 3 Figure 3 -UMLS concept Per-patient and per-month intersection sets between the three sources

Table 1 -

 1 Number of instantiation of the OntoTox classes, per data source

	OntoTox	questionn-
	classes	aires	free text	table
	Chemothera	53,510	54,420	2,366
	pyToxicitiy
	Grade	53,510	6,366	400
	Grade1	9,981	2,100	87
	Grade2	1,832	1,996	52
	Grade3	191	817	23
	Grade4	19	422	0
	Grade5	0	2	1
	GradeNull	0	433	85
	Grade0	41,487	596	152
	Patient	330	330	330
	StartDate	1112	2782	372

https://github.com/equipe22/pymedext_core.