Risk Scan Engine Architecture and ExtensibilityUpdated Feb 20, 2024
Arctic Wolf Risk Scan Engine (formerly Joval) operates on three layers for managing the process of scanning target machines:
- Java System Access Facade (jSAF) ISession — The first layer that connects to the target and collects raw data.
- Joval IPlugin and adapters — The second layer that references the ISession and maintains a registry of schema object IAdapter classes. These adapters use the session to extract information from the target machine and may cache that information for future use.
- SCAP Language Engines — The third layer that processes OVAL and SCAP Datastream XML documents, called IOvalEngine and IXccdfEngine, respectively, which reference their own IPlugin instances.
With this three-layer architecture, you can:
- Create a single-object adapter to support both host-based and remote collection.
- Isolate the collection logic for schema objects outside the core document processing engine.
- Generate a data model from a schema, write the object adapters, register the model objects with the engine, and register the adapters with the plugin at runtime.
You can customize how Risk Scan Engine ingests data. For more information, see the User Guide files in the zip files for the components you license.
If you want to create a custom plug-in for Risk Scan Engine, you can create your own IPlugin implementations. For example, custom plugins can be helpful if your application stores information about target machines in a database, and you want to retrieve that information from the database instead of from the target machine. In this case, the custom plugin would inspect each object collection request the engine makes, and then either retrieve the information themselves, or delegate the collection to a wrapped Risk Scan Engine plugin instance.
If you want to perform compliance assessments on information that existing OVAL tests do not expose, you can use the
scap-extensions component in Risk Scan Engine to support custom schemas. See scap-extensions for more information.
Risk Scan Engine uses the abstract system interface defined by jSAF, so an object adapter can function in multiple contexts. For example, local, remote, and offline scanning. In rare cases, you could define your own jSAF provider.
For example, in a simple case, if you have a database containing configuration data about routers or mobile devices, you might want to create your own offline provider that would source information from that database. In a more complex example, you might already have your own native agent software distributed throughout the environment, and want to leverage that as a mechanism for data collection. Both of these use cases are possible if you can author your own provider implementation of the relevant jSAF interfaces.