The validation engine of Configuration and Security Analytics is running directly on SAP HANA database level. It is basically using HANA SQL as described in the SAP HANA SQL and System Views Reference. However, not all features are supported. The actual SQL used for validations is generated automatically based on the XML coding of a policy.

This page provides an overview on syntax rules, common check types and useful best practices for creating policy content.

Policy Structure

Policies are written in an xml format. Out of this the SQL coding for the validation is created automatically when the policy is generated. This section provides an overview on the syntax elements that are required in every policy.

Each policy starts with an element containing the attributes related to the used xml version and encoding. When creating a new policy, this element is created automatically. It must not be changed.

<?xml version="1.0" encoding="utf-8"?>

All other elements of a policy are opened and closed. Elements are specified in <>. The closing element starts with </.

<targetsystem> </targetsystem>

A policy must contain at least the following elements:

                                       <targetsystem>

                                              <configstore> 

                                                     <checkitem>
                                                       <compliant>
                                                       </compliant>
                                                       <noncompliant>
                                                        </noncompliant>
                                                 </checkitem>

                                                  </configstore>

                                          </targetsystem>

Some of these mandatory elements do not necessarily need to contain content, e.g the noncompliant rule can remain empty in some cases. In this case the syntax can be shortened:

<noncompliant/>      instead of:      <noncompliant> </noncompliant>

In addition the following elements can be used:

                                           <complianttext> <complianttext/>

                                          <noncomplianttext> <noncomplianttext/>

                                          <joinstore> <joinstore/>

                                          <joincomplianttext> </joincomplianttext>

                                          <joinnoncomplianttext> </joinnoncomplianttext>

You can also add comments to the policy:

                                          <!--        -->

While you can learn many syntax elements by starting your work directly with the use of policies published on the SAP Github, additional documentation may be useful in some cases. Each of the elements given above may contain additional attributes. These are explained on the next sections of this page. After this we provide documentation on typical syntax for check items. At the end we will provide syntax examples from the perspective of typical validation needs (driven by semantics rather than by language).

Rule example: Password length is compliant if the parameter value is greater equal 8

    <configstore name="ABAP_INSTANCE_PAHI">

       <checkitem desc="First item check " id="1.0.0.0">     
            <compliant>name= 'login/min_password_lng' and value&gt;= 8</compliant>
            <noncompliant>name= 'login/min_password_lng' and not ( value &gt;= 8 )</noncompliant>
      </checkitem>

   </configstore>

Note:

• The correct configstore name must be specified before the first check. Config store name and structure and check content must fit together (bold characters).
• Names must be put in single quotes, values without quotes are numbers
• SQL syntax (italic characters) is applied (some syntax like <  > needs be to escaped for XML: &lt; &gt;)
• Checkitem description should be meaningful. Some customers choose a description that indicates a check group (e.g. "password policy") and the specific check (e.g. "login/min_password_lng")
• Check id usually corresponds with the id of the specific rule in the hardening guide. The check id must be unique in a policy. 
• Multiple checks can refer to the same configstore. The group of checks is closed with </configstore>
• Explicit definition of a noncompliant rule is recommended. This helps to minimize the occurrence of no data found results.
• You can add additional columns of the configstore to your rule, even when they are not relevant for the validation result. Syntax is like column='%' where % indicates that any value or null value is allowed. 
• The validation UI shows columns in the order that is specified in the check

The following is an example of a HANA parameter check:

    <configstore name="HDB_PARAMETER">

       <checkitem desc="1.1. sslCryptoProvider" id="001">
            <compliant>FILE_NAME = 'global.ini' and SECT = 'communication' and NAME = 'sslcryptoprovider' and 
                   VALUE = 'commoncrypto' and LAYER like '%' and HOST like '%' and TENANT like '%' </compliant>               
            <noncompliant>FILE_NAME = 'global.ini' and SECT = 'communication' and NAME = 'sslcryptoprovider' and  
                   NOT VALUE = 'commoncrypto' and LAYER like '%' and HOST like '%' and TENANT like '%' </noncompliant>

       </checkitem>

       <checkitem desc="1.1. sslMinProtocolVersion" id="002">
            <compliant>FILE_NAME = 'global.ini' and SECT = 'communication' and NAME = 'sslminprotocolversion' and
                     VALUE = 'TLS12' and LAYER like '%' and HOST like '%' and TENANT like '%' </compliant>
            <noncompliant>FILE_NAME = 'global.ini' and SECT = 'communication' and NAME = 'sslminprotocolversion' and
                    NOT VALUE = 'TLS12' and LAYER like '%' and HOST like '%' and TENANT like '%' </noncompliant>
       </checkitem>

    </configstore>

Figure 1: Validation Result of 2 check examples

Basic Syntax

Compliant or non-compliant rules are defined as a subset of SQL WHERE clause. The following syntax could be used:

Note:

• You cannot use sub-queries. 
• You cannot use SQL comments -- or /* */

The following section gives you examples for the use of basic syntax elements. Focus is on checking simple numerical values. 

This section demonstrates some use cases of advanced syntax elements.

Each policy contains exactly one element targetsystem. Tag <targetsystem> is placed in the line directly after the specification of xml version and encoding. Tag </targetsystem> is the corresponding closing bracket. It is placed at the end of the policy.

Each policy contains at least one configstore.  It is mandatory to specify the name of the config store through the attribute name. All other attributes to this element are optional and only used in exceptional cases.

Tags <configstore>  and </configstore> are the opening and closing bracket for a configstore.

In addition to the attributes of element configstore you can use the following attributes for joinstores. When building a join condition for a check item, the element joinstore allows to implement a join against configuration items from any config store.

Tags <joinstore>  and </joinstore> are the opening and closing bracket for a check.

Checkitems are the element that contain the actual validation rules for determining compliance and noncompliance of a configuration. A policy can contain multiple checkitems. Checkitems should be grouped by config store. Tags <checkitem>  and </checkitem> are the opening and closing bracket for a check.

Various attributes can be used to control the behaviour of check items in a validation run. This section provides details and some examples.

The FAQ section is currently empty.