Customizing Hardening Policies

The KHIKA Hardening Compliance Report internally uses a sqlite database (www.sqlite.org) to maintain the hardening templates and the sqlite database is available on the KHIKA Application Server at the following location:

• For Windows Servers -> /opt/KHIKA/Apps/Dashboards_n_Reports/WIN_GRC/policy_db.dat
• For Linux Servers -> /opt/KHIKA/Apps/Dashboards_n_Reports/Linux_GRC/linux_policy.db

Customization of Hardening policy may include anything from creating your own hardening policy template to editing an existing hardening policy. To know more, please read on:

Policy Database
In-order to customize the server hardening parameters, it is important to understand the server hardening policy database. The policy database has the following important tables:

Policy_Definition -> Policy_definition table is used for defining various group of policies e.g. 'Password Policy' is the policy group for various password related parameters/settings. Please refer the picture below:

Policy_Details -> For each Policy Group, there are several parameters that need to be checked and the policy details table is used to define these parameters. e.g. Within Password Policy, there are parameters like minimum password length, maximum password validity period, etc which need to be evaluated. The Policy_Details table is used to capture the configuration such that each parameter will have its own record containing details such policy_value(desired value), policy_desc(concise description of the parameter), etc. One of the most important configuration settings for a parameter is the 'operator' column as it define how the collected value is evaluated against the desired value. The possible values for operator are LT(Less Than), GT(Greater Than), NE(Not Equal To), EQ(Equal To), SUBSTR and CONTAINS. Please refer the picture below:

Server_Group -> This table defines the group of servers and the mapping of the group to the set of hardening policies applicable to all the servers within the group.

Server_Details -> This table is used to capture the details of the server and the server_group to which the server belongs.

Let us consider the following example to understand the role played by the policy database in the workflow of Server Hardening Report. Please assume that hardening data is collected from the server 'khika-pc'. To generate the server hardening report for 'khika-pc', workflow will proceed as follows:

1. To understand the hardening policies that need to be applied to check hardening compliance for 'khika-pc', obtain the server_group_id corresponding to the server_group for 'khika-pc' from the table 'server_details'.
2. From the server_group table, get the list of policies to be checked for server_group.
3. For each policy in the policy_details, get the list of hardening parameters,their desired values,description and other configured values.
4. Compare the collected value for the hardening parameters against the desired value and determine the result i.e. whether the parameter is configured properly or not.

To edit an existing hardening policy
The KHIKA Server Hardening mechanism internally uses an sqlite database to maintain the various hardening parameters and along with their expected values and in order to edit an existing hardening policy, you will need to update the sqlite database. This can be easily done by coping the appropriate policy database from the KHIKA Application server to the Windows Machine where SQLiteBrowser is available via WinSCP or any other equivalent utilities. Once the policy database sqlite file is copied to the windows server, open the policy database using SQLite Browser.

In order to edit the existing hardening policy, one has to identify the relevant policy group and then check the parameter within the policy group that needs to be updated. Typically it is either the column 'policy_value' or 'policy_desc' of the parameter that gets updated. Please refer the Policy Database section to see how this done.

Once the desired updated to the policy database are done, please save the policy database and copy the updated policy database to KHIKA Application Server. That is it - the updated to the hardening policy will get reflected the next time hardening report is run.

To create your own hardening policy template
In-order to create a new hardening policy, one has to figure out what are the hardening parameters that need to be covered under policy. For each parameter, one has to implement the collection mechanism that will be used to get the parameter data from server. The collection mechanism is typically run as an command via OSSEC agent that is installed on the server. The output of the ossec command for the parameter will be typically like

HostName <SERVER_NAME> SECTION <POLICY_SECTION> rule <PARAMETER> value <PARAMETER_VALUE>
e.g. HostName "khika-pc" SECTION Login_def rule "PASS_MAX_DAYS" value "99999"

Once the data collection mechanism is implemented for hardening parameters, one need to populate the hardening policy database for these parameters. The Hardening policy database is basically the template that is used to define:

1. Grouping of the hardening parameters into logical policy groups.
2. Mapping of data collected to applicable hardening policy parameter via policy_variable_name & policy_section
3. Description of hardening parameters which is rendered in the report.
4. Desired value for hardening parameters along with operation

For more information, you should use the hardening policy database that is shipped out of box with KHIKA as a reference and configure your database along the similar lines.

To add a server for hardening compliance report
In-order to add a server for hardening compliance report, open the sqlite database via sqlitebrowser. Open the 'server_details' table and add a record for the new server as shown below:

NOTE

To edit the sqlite database, it is recommended to use an open source utility named 'Sqlite Browser' which may be downloaded from the https://sqlitebrowser.org/ (please review the license policy before downloading & using the sqlite browser utility).