SWIF Widgets
SWIF widget core capabilities act in concert to support all aspects of mission planning from target selection to concept of operations development. Target widgets focus on providing planners and analysts the ability to diagram and analyze government, economic, and social entities’ relationships in support of target and capability selection. Planning widgets allow the user to develop multiple courses of action (COAs) and visualize events within the context of the overall plan. Most importantly, third parties are allowed to use SWIF as a framework for developing, as well as hosting, widgets to enrich core capabilities. Existing non-SWIF widgets can be rapidly adapted to integrate into SWIF. However, all widgets within SWIF must undergo the SWIF Governance Process for certification and accreditation (C&A) prior to deployment.
SWIF Widget Governance Process
The SWIF goal is to foster innovation rapidly to field relevant capabilities in order to meet existing and emerging collaborative needs amongst all branches of the military and from disparate security access levels. Currently, new capabilities are subjected to lengthy testing and C&A processes. This necessary, but lengthy, process may take as long as nine months to complete in which time crisis planning needs may be unmet. The SWIF architecture allows for a decoupling of the hosting web-based infrastructure and the widgets where functionality resides. The infrastructure consisting of OWF, SWIF Security Services, and the SWIF database would be subject to the full gamut of C&A review. However, once the infrastructure was certified and accredited, it will only undergo C&A for upgrades—not when new widgets are added. Widgets, on the other hand, would undergo a governance process that would streamline the C&A process based on their capabilities, complexity, and security boundaries.
Widgets are characterized as simple or medium based on their capabilities, complexity and security risk posture in relation to the networks in which they operate and the applications with which they interface. Table 1 delineates the difference between a simple and medium widget category type in SWIF:
Widget approval is dependent upon the residual risks the widget poses to the network in which it operates and the systems it supports. These residual risks are then weighed against mission efficiencies, accuracies and overall improvements the widget creates in specific mission execution.
The widget governance process is streamlined into workflows dependent upon the widget’s profile. The Widget Submission Package of medium widgets will undergo a workflow with more rigorous testing and review as compared to the governance workflow for simple widgets. Both the Simple and Medium Widget Governance Workflows can be seen in Figure 2 with color-coded roles. The Developer role (in blue) is responsible for ensuring the Widget Submission Package is complete and submitted appropriately according to the Widget Submission Package Checklist. The SWIF Project Team/Approval Board role (in light red) is responsible for: reviewing the Widget Submission Package for completeness, functional testing, integration testing, and final approval. Finally, the Security role (in light green) confirms that all Information Assurance (IA) testing is performed appropriately for the widget type. This governance process ensures that widgets are tested properly but without the unnecessary waste of time and effort.
SWIF Components
There are a variety of components that make up the SWIF construct. These components include an unstructured database, secure web services, APIs, and banner service.
NoSQL Database
For data storage, SWIF uses a NoSQL database. The main feature of the NoSQL database that SWIF utilizes is the capability to provide a dynamic schema. Standard relational databases require all field information to be defined ahead of time before data can be entered into the table. Having a dynamic schema allows the operator to insert data into a collection (table in relational database terms) with different fields for the same collection. In other words, a collection is created to which data is entered, but fields are not defined within a collection. This allows a widget to be installed without having to initialize a database to define tables. The simplification of a widget installation enhances the accreditation process because the core system does not have to be changed to install a widget.
SWIF Secure Web Services
Based on the Representational State Transfer architectural style (REST), the SWIF secure web services are provided to give access to MAC data stored in the SWIF NoSQL database. The services include standard methods that allow a developer to retrieve, save, update, delete, search, and label a particular data entity. Widget developers are also allowed to insert any fields into a collection as needed. The only requirement with MAC data in the NoSQL database is that every entity inserted into a collection has a security label with the required system security attributes and the user must have the required security accesses to the label. REST services are url-based and are problematic for widgets when urls are modified. To address this, a JavaScript library was incorporated into SWIF to handle the communication with the secure web services.
SWIF JavaScript API
The SWIF JavaScript API allows the widget to communicate with the SWIF secure web services by executing JavaScript methods from within the widget. This greatly simplifies the process of creating a secure widget by abstracting the complexity of knowing which URLs to call from a widget.
Banner Service
SWIF contains a banner service that displays the current security information for all data inside a particular widget. The banner is updated by the JavaScript library whenever data is changed in the widget. This keeps the user knowledgeable of the security of a data residing in a widget. The SWIF banner service also creates a banner at the top of the browser window that is a union of all security labels for all widgets on the dashboard. All banners are always in sync with the data that is contained under them.