Page 401 - Kaleidoscope Academic Conference Proceedings 2024
P. 401
Innovation and Digital Transformation for a Sustainable World
5. PROPOSED SOLUTION The system identifies five actors/external entities that can
interact with it, namely, the user, the administrator, the super
A solution to the above-mentioned research questions is administrator, the external vulnerability data repositories,
presented that addresses to the limitations discussed. This and the collaborating user/external systems (Figure 1). The
solution that has been developed as a web-based software user actor is the system user who will have access to the
application, can present insights in the form of vulnerability configured vulnerability intelligence dashboard and related
intelligence from known vulnerability information targeting user interfaces. The administrator actor is the system user
software applications built using either open-source authorized with privileges to configure the visualization and
technology stacks or proprietary software. This vulnerability repository parameters for the system. The super
information has been aggregated from two open-source administrator actor has the highest privileges to manage the
vulnerability databases, namely OSV database and NVD. role and access assignment of the remaining users in the
The software application has also integrated the attack system. This user also processes requests for registering
pattern repository from MITRE CAPEC (Common Attack collaborating users or external systems that wish to access
Patterns Enumeration and Classification) and utilized data the system’s APIs. The external vulnerability data
from the MITRE CWE list to map them with the repositories actor represents other external open-source
corresponding entries in the aggregated vulnerability databases being used to aggregate vulnerability data and
database. The web-based vulnerability intelligence platform, derive intelligence from. Lastly, the collaborating
alternatively referred to as WebVIP or “system” from user/external systems actor represent the users who wish to
henceforth, aims to function as a vulnerability intelligence access the aggregated data and intelligence data through an
platform with the following key features – API and not through the user interface. They represent the
external systems who wish to use, analyse, or build upon the
• It has defined a Unified Schema for the vulnerability data. They can also submit feedback through an API.
information into which the data from the integrated
vulnerability databases has been transformed and 5.1 Core Modules of WebVIP
persisted in a local database for consistency. This will
bring about convergence of the vulnerability The architecture has been illustrated in Figure 2.
information from multiple sources into a single,
standardized format.
• It has built in components that can periodically collect
data from the OSV and NVD databases and process it in
order to persist the data in the defined unified schema.
• It has the functionality to collect and persist data from
the CAPEC repository and the CWE list locally and use
them to link the data to the aggregated vulnerability
information.
• It processes the aggregated data to generate
vulnerability intelligence and link insights about attack
patterns that can be used for vulnerability management
and forensic analysis. Figure 2 – System architecture diagram
The users can interact with the vulnerability intelligence The core modules developed for the vulnerability
platform through two modes. First, a web-based software intelligence platform WebVIP are listed below:
application that will primarily present a vulnerability
intelligence dashboard through its user interface, and second, • Data aggregation module
a set of well-defined APIs that will be used for collaboration • Preprocessing module
with external systems.
• Optimization module
• Data augmentation module
• Web User Interface module
• Collaboration module
The data aggregation module is the module that periodically
collects vulnerability data for the system. This periodicity is
scheduled as per the external system constraints (For
example, if the external repository updates their database
every night, the periodicity can be set for every morning).
Once an iteration from the data aggregation module is
completed, the preprocessing module is scheduled to
perform the task of transforming the data into the consistent
Figure 1 – Context diagram for the system
format as defined for the system. After an iteration from the
– 357 –