Design and development of vulnerability management portal for DMZ admins powered by DBPowder

l Flexible implementation enables to expand DMZ User’s Portal to other sites Conclusions l DMZ User’s portal is implemented in a flexible manner. It enabled to extend the portal to other two sites in 2011 and 2016 (J-PARC, HEPnet-J) Extended DMZ User’s portal to other networks April Next March Self inspection ■ Got info about serious vulnerability ■ checked the config of my DMZ server ■ my server was not corresponded


Introduction
In KEK, there are various research groups within the fields of high-energy physics, material physics, and accelerator physics, and they offer various information and communication technology (ICT) services to various researchers around the world. Each field of physics has its own way to proceed their research.
Their services are also diverse, including experiments, GRID services, public relations, and login shell, among others ( Figure 1). Many of these services cannot fit within the standard ones provided by the computing research center. In the KEK-DMZ network, there are over 300 individual hosts, which are managed by about 100 administrators (DMZ admin). Each of the hosts has its own circumstances due to historical reasons. As a result, it is difficult to apply general security standards. Command-hierarchical manner is not suitable for research institutes since it is difficult to cover these various circumstances. Instead, each of the DMZ admins has his/her responsibility for security management, and they have to spend a lot of effort to maintain their security.
We have a vulnerability scanner, Tripwire IP360, which is used to analyze hosts and evaluate each one's vulnerabilities in the form of a score. The scanner is proprietary and has rich functions, but it is too intricate for non-experts in security to utilize.
To address these challenges, we developed DMZ User's Portal site, in 2007, that utilizes the vulnerability scanner. Since then, we have operated and improved the portal site. All of the owners of DMZ hosts have their own accounts.
Using DMZ User's Portal, each DMZ admin can perform a vulnerability scan on his/her own servers with ease. Then, each DMZ admin can grasp and manage the security by himself/herself. This paper shows the design and development issues of DMZ User's Portal.

Overview of DMZ User's Portal
The vulnerability scanner Tripwire IP360 evaluates each host's vulnerabilities in the form of a score. If the score is over 1000, its vulnerability is regarded as severe. The scanner is proprietary and has rich functions, but it is too intricate for DMZ admins to use because of these rich functions themselves.
To tackle with these challenges, we developed the first version of DMZ User's Portal site in 2007 that wraps the functions and promotes security self-management for DMZ admins. Since then, we have been improving the portal site with agility. All of the owners of DMZ hosts have their own accounts. The screen of the main page is shown in Figure 2.
There are three main features in DMZ User's Portal. One of the features provides an easy-to-operate user-interface to DMZ admins so that they can manage and handle the vulnerabilities by themselves. Using the portal, DMZ admins can use the vulnerability scanner easily with one click to run a security analysis of the owner's host. The results can be downloaded as a PDF report.
Another feature helps DMZ admins from both viewpoints of support side and commandhierarchy side in harmony. On the support side, DMZ admins can conduct the vulnerability scan on their own, and the portal collects and aggregates the information to maintain the security. On the command-hierarchy side, the portal helps the duty for DMZ admins to self-inspect their hosts annually, by providing a management interface. In other words, this delegates security vulnerability discovery and responsibility to individual DMZ admins that improve security awareness for them. It also brings scalability into security management.
The third feature provides feedback mechanisms of the vulnerability information of their host in multiple and continuous ways. Three scanners are set on the WAN, DMZ, and LAN networks, which assume attacks from each of their locations. While DMZ admins can conduct an on-demand scan, the portal conducts a regular scan of all DMZ hosts once a week. When serious vulnerabilities are found on a DMZ host, the portal notifies the owner of the host of the information through a weekly email. While DMZ admins can browse the vulnerability list all together, they can also download the vulnerability report of each host individually. As shown above, various feedback mechanisms help DMZ admins to determine the priority to measure, and security management can be executed by each user.

Security self-inspection performed by DMZ User's Portal
We have been performing annual security self-inspection since 2007. In the self-inspection, DMZ admins use DMZ User's Portal themselves to check their hosts and submit reports. The reports are inspected by our security management committee.
In the self-inspection, each DMZ admin performs a vulnerability analysis from the scanner in the WAN using DMZ User's Portal. If the analysis detects any vulnerability that has a score of over 1000 point, the DMZ admin modifies the vulnerability and retries the analysis. The DMZ admin submits a report when there are no vulnerabilities over 1000 point    remaining. If the DMZ admin supposes that the result includes any false-positives, he/she can submit a supplemental report that describes how each of the false-positives is already fixed, with evidence. Besides, the DMZ admin submits Q/A reporting sheets. Finally, their submitted reports and sheets are investigated and examined by the KEK security management committee. Figure 3 shows an example story of admin tasks over one year, from April to March (JFY). If there is a serious vulnerability that has a score of over 1000 points, DMZ User's Portal sends an alert email weekly to the owner of the host, as shown in 'n 2 th, Jul'. While KEK security team also grasps the weekly alert mail, in these years DMZ admins modified such vulnerabilities by themselves in one or two weeks. Figure 4 shows the system architecture of DMZ User's Portal. The point is that it has a wrapper architecture. DMZ User's Portal mainly uses four middlewares: vulnerability scanner, relational database, web server, and email sender. All of these are always called via wrapper modules of their own. This reduces the module dependency.

System architecture
DMZ User's Portal has four wrapper components for the aforementioned middlewares: Portal module, Wrapper module for the vulnerability scanner (Wrapper module in short), DBPowder O/R mapper (DBPowder in short), and Template engine. The Portal module uses the other three core components and organizes the functions of DMZ User's Portal. The Wrapper module receives all requests related to the vulnerability scanner and handles them. DBPowder receives all requests related to the relational database and handles them. DBPowder also helps the development around the relational database. Template engine generates the web UI and email texts.
The vulnerability scanner also manages the data regarding accounts, hosts, results of vulnerability analysis, and so on. While the data can be accessed via XML-RPC or http in the vulnerability scanner, the performance is quite poor. The Portal module uses DBPowder to synchronize the data with the vulnerability scanner and realizes the data access with reasonable performance.

Wrapper module for the vulnerability scanner -flexibility and maintainability
The vulnerability scanner, Tripwire IP360, has an API with XMLRPC. However, the API does not have some of the essential functions such as the one to download PDF reports. To compensate for this, we developed a wrapper module that has an XMLRPC wrapper and html proxy. At the same time, to reduce the module dependencies on a specific vulnerability scanner, only the wrapper module can access the vulnerability scanner directly using API and https. It also adds a tolerance to the change of specification in the vulnerability scanner.
The flow of the processes of the XMLRPC wrapper is as follows: receive a Java method call, convert it to an XMLRPC call to the vulnerability scanner, receive the XMLRPC return value, convert it to Java class object, and return the object. The flow of the processes of the html proxy is as follows: receive a Java method call, convert it to an http request for the vulnerability scanner and send it, receive the http response that contains http headers and html from the vulnerability scanner, parse and interpret the html to extract the return value, and return the value in the form of Java class object.
In the wrapper module, we also developed several test case modules to check the API wrapper and html proxy. It is particularly useful in the update of the vulnerability scanner. The test case modules find the errors according to the update. When the modification of the errors is finished, the wrapper module is ready to follow the update of the vulnerability scanner.

Template engine of html and email
When interacting with the portal users, such as those through a web interface and email notification, it is preferable for the contents to be easy to edit. Therefore in DMZ User's Portal, the contents are separated from the codes into templates. At the same time, the templates can be switched using the hostname in which the program of DMZ User's Portal is executed, without changing the configuration in each site.

DBPowder: object-relational mapping (ORM) framework
In DMZ User's Portal, a database is an important component for managing the data related to accounts, hosts, results of vulnerability analysis, and so on. We introduced DBPowder Object-relational mapping (ORM) framework [1][2][3] to bridge the database to the Portal module shown in Figure 4. In DMZ User's Portal, we can use the database, database access codes, and the web codes related to database access, via libraries in DBPowder. In our development, DMZ User's Portal improves DBPowder, and DBPowder improves DMZ User's Portal. The theoretical aspects of DBPowder have been already described in previous studies [1][2][3]. This section describes the software design and usage aspects of DBPowder.
ORM frameworks contribute to the efficient design, development, and maintenance of (a) persistent classes to deal with the persistent data in an object-oriented language, (b) relational schema to manage the persistent data in the RDB, and (c) data conversion between object states and RDB queries/responses [1]. We developed DBPowder ORM framework and utilize it in the development of DMZ User's Portal.

DBPowder-mdl: data schema description language
DBPowder-mdl [1] is a language to describe data schema in a simple and flexible manner. Figure 5 is a simple example of DBPowder-mdl. We can design data schema in the left-hand example of EER-style such that: The code generator of DBPowder generates the mapping codes using DBPowder-mdl. By default, the code generator generates classes along with the description of EER-style. It is desirable for data schema to be stable. On the other hand, it is also desirable that the data schema can be used in various way for classes used in an application. We can design classes in the right-hand example (in Figure 5) of ObjectView-style such that: The code generator also generates the classes along with the description of ObjectView-style.

Helper for database schema modification
In general, database schema modification is not a simple task because the modification does not end with the schema itself. At least, the modification also impacts persistent classes and All tables checked (6) DBPowderfactory detects diffs per table defined in DBPowder-mdl

(5) END (Succeed)
There are cases that compile errors are found in the codes that call DB access codes, around the schema modification. Even in the case, Java compiler detects the errors and you can modify all of them appropriately.
(1) START  Figure 6: Flowchart of the helper for database schema modification  Figure 7: Class structure of DBPowder. data conversion codes between object states and RDB queries/responses. To make matters worse, many persistent classes are referred to from the application codes. Therefore, many places in the application codes are also impacted by the modification.
DBPowder has the function to assist in schema modification, and it relieves the burden of the task. Figure 6 shows the flowchart of the helper. DBPowder checks the script in DBPowder-mdl, database schema, and classes generated by DBPowder, to keep consistency among them. If a table has one or more data records, any table modification may cause an adverse effect. In such a case, DBPowder tells a developer whether to modify or not. Each of the entities, presentation entities, and components has its own extension point. The extension point is a simple wrapper for developers. Since DBPowder does not modify any extension points, developers can add their own codes without fear of modification by DBPowder. from 2005 to 2014, and the number was inverted in decreasing since 2014. Most of the hosts end in category 1), which means that the submission was completed. In a few cases in 2012 and 2014, there were many hosts in category 4), which means to stop to use the host. In all years, all of the DMZ hosts ended in either of the categories from 1) to 5), indicating that the security self-inspection has been operated successfully.

Extended DMZ User's portal to other networks
The flexibility shown in Section 3.3 enables us to introduce DMZ User's Portal into the networks which have different operation policy from that of KEK. In 2011, we extended and introduced the portal to the network for J-PARC, a joint project with KEK. In 2017, we introduced the portal to the network for HEPnet-J, another joint project with KEK.

Summary
In KEK, various research groups offer various information and communication technology (ICT) services to various researchers around the world. Since each host has its own circumstances and it is difficult to apply general security standards, each host owner has his/her responsibility in security management. Although vulnerability management with a vulnerability scanner is a good solution, it is too intricate for non-experts in security to utilize.
To address these challenges, we developed DMZ User's Portal site that utilizes the vulnerability scanner. There are three main features in DMZ User's Portal. One feature provides a user-friendly interface for DMZ admins to manage and handle the vulnerabilities by themselves. Another feature helps DMZ admins from both viewpoints of support side and command-hierarchy side in harmony. The third feature provides feedback mechanisms of the vulnerability information of their host in multiple and continuous ways. The 13-year result from vulnerability scans show that the status of security in the KEK-DMZ has been kept in good conditions. Also, DBPowder ORM framework brings flexibility and efficiency in the development process of DMZ User's Portal. Flexible implementation has enabled the expansion of DMZ User's Portal to other networks that have different policies.