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.
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>= 8</compliant>
<noncompliant>name= 'login/min_password_lng' and not ( value >= 8 )</noncompliant>
</checkitem>
</configstore>
Note:
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
Compliant or non-compliant rules are defined as a subset of SQL WHERE clause. The following syntax could be used:
Note:
The following section gives you examples for the use of basic syntax elements. Focus is on checking simple numerical values.
<checkitem desc="3.1.1.1 System configuration (profile parameters)" id="001">
<compliant>NAME = 'login/failed_user_auto_unlock' and VALUE = '0'</compliant>
<noncompliant>NAME = 'login/failed_user_auto_unlock' and NOT VALUE = '0' </noncompliant>
</checkitem>
<checkitem desc="3.1.1.5. Logging (profile parameters)" id="002">
<compliant>NAME = 'rec/client' and VALUE = 'ALL' </compliant>
<noncompliant>NAME = 'rec/client' and NOT ( VALUE = 'ALL' ) </noncompliant>
</checkitem>
<checkitem desc="3.1.1.1. login/min_password_lng" id="003">
<compliant>name= 'login/min_password_lng' and value> 8</compliant>
<noncompliant>name= 'login/min_password_lng' and not ( value > 8 )</noncompliant>
</checkitem>
<checkitem desc="3.1.1.1. login/password_max_idle_initial" id="004">
<compliant>name= 'login/password_max_idle_initial' and value < 14</compliant>
<noncompliant>name= 'login/password_max_idle_initial' and not ( value < 8 )</noncompliant>
</checkitem>
<checkitem desc="System configuration (profile parameters)" id="005">
<compliant>NAME = 'login/min_password_digits' and VALUE >= 1 </compliant>
<noncompliant>NAME = 'login/min_password_digits' and NOT (VALUE >= 1) </noncompliant>
</checkitem>
<checkitem desc="3.1.1.1. login/password_max_idle_initial" id="006">
<compliant>name= 'login/password_max_idle_initial' and value<= 14</compliant>
<noncompliant>name= 'login/password_max_idle_initial' and not ( value <= 8 )</noncompliant>
</checkitem>
<checkitem desc="3.2.3. DDIC is LOCKED" id="007">
<compliant>CLIENT like '%' and USERNAME = 'DDIC' and ( LOCKED = 'X' or EXISTING <> 'X' )
</compliant>
<noncompliant>CLIENT like '%' and USERNAME = 'DDIC' and not ( LOCKED = 'X' or EXISTING <> 'X' )
</noncompliant>
</checkitem>
<checkitem desc="3.2.3. mandatory System Replication" id="008">
<compliant>FILE_NAME= 'global.ini' and LAYER like '%' and HOST like '%' and TENANT like '%' and
SECT = 'system_replication' and NAME = 'site_id' and length(VALUE) gt; '0' </compliant>
<noncompliant>FILE_NAME = 'global.ini' and LAYER like '%' and HOST like '%' and TENANT like '%' and
SECT = 'system_replication' and NAME = 'site_id' and not length(VALUE) gt; '0' </noncompliant>
</checkitem>
<checkitem desc="System configuration (profile parameters)" id="009">
<compliant>NAME = 'login/fails_to_session_end' and VALUE between 1 and 3 </compliant>
<noncompliant>NAME = 'login/fails_to_session_end' and NOT (VALUE between 1 and 3) </noncompliant>
</checkitem>
This section demonstrates some use cases of advanced syntax elements.
<checkitem desc="System configuration (profile parameters) - secret" id="00015" system_roles="PROD">
<compliant>NAME = 'login/password_max_idle_productive' and VALUE between 1 and 90 </compliant>
<noncompliant>NAME = 'login/password_max_idle_productive' and NOT (VALUE between 1 and 90) </noncompliant>
</checkitem>
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.
Attribute "name" specifies the technical name of the config store. The attribute is mandatory.
Syntax example: <configstore name = "COMP_LEVEL">
Attribute "name_extended" can be used as further attribute in case the technical name of a config store is not unique (optional).
Possible values of attribute "name_extended" can be identified with view CCDB_DIRV.
The attribute "sci_id" must be used in case the technical name of a config_store is not unique (mandatory).
Attribute "system_type" can be set additional to restrict the system type (e.g. dir.system="JAVA"). This may only be necessary if the same config store is used cross several system types (currently the case for COMP_LEVEL which contains the software components for ABAP and JAVA systems) (optional).
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.
The elements <joincompliant> and <joinnoncompliant> work the same way as <compliant> and <noncompliant> for a simple check item. They contain the technical rules that the configuration item is checked against.
The elements <joincomplianttext> and <joinnoncomplianttext> work the same way as the elements <complianttext> and <noncomplianttext> for a simple check item. They are used to replace the technical rule with a text describing the rule elements. If used those texts replace the SQL rules in the corresponding fields of the UI (optional).
Attribute "minus" applies only to element "joinstore". It controls the way the non-compliant join is transferred into SQL:
Attribute "no_data_found" helps to handle join conditions that do not apply to any configuration item.
The standard behaviour of the validation is that each check generates an SQL statement which returns the status “item not found” in case both statements for the compliant and non-compliant check do not return any results for a system. However, in some cases one of the join statements introduces a validity constraint. In such a case, it is possible to add this validity constraint also to the SQL statement checking “item not found”.
no_data_found="Yes"
Best Practice:
Example 1:
Value of HANA parameter: FILE_NAME = 'global.ini', SECT = 'parallel', and NAME = 'num_cores' should be checked, however, only for HANA systems running a version between 12202 and 12206. To avoid “item not found” results for HANA systems running on a version not between 12202 and 12206 it is necessary to add an attribute to this join to mark it to be used also in the “item not found”-SQL to include only those which are running the correct HANA version (optional).
Use of no_data_found="Yes" operator (Note: The operator can be applied in a join condition or in a check item)
Output of a "data not found" record when no_data_found="Yes" is not set.
In some cases the columns of the joined config store needs to be suppressed to avoid getting multiple tuples of the join result. This behaviour can be achieved with attribute "not_in_output".
Supported as of FRUN 2.00 SP00
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.
Attribute "desc" contains a description of the check item. Between " " you can enter any content that helps understanding the meaning of the check.
Attribute "id" contains the check Id of the check item. In most cases it will refer to an identifier that is used in your hardening guide or security procedure.
It is not required to have a numeric id. You can also use characters or special characters.
"store_attribute" allows to restrict the check item to specific records in a Config Store. The original use case for store_attribute was to limit a check item to a specific client, e.g.: "CLIENT:001"
Syntax Example: store_attribute="CLIENT:001"
not_found="negative"
Attribute "not_found" controls the compliance status of check item in case its rules does not select any config item.
Effect:
not_found="positive"
Effect:
Use of the not_found="positive" operator for a check item
With not_found="positive" a check item is rated compliant when not matching to compliant/noncompliant rules (default: "negative")
The attribute "operator" allows to apply certain predefined operators to the check item. One example are the operators "EXIST" and "NOT_EXIST".
Effect:
For checking obsolete or forbidden parameters you can use the operator "NOT_EXIST"
Note: " Operators "EXIST and "NOT_EXIST" do not support joins.
Syntax for using the "EXIST" operator
Validation output with the "EXIST" operator
The attribute "operator" allows to apply certain predefined operators to the check item.
For ABAP notes checks the "operator" attribute can be set to “check_note” or “check_note:<10 digits note number>”.
Attribute "system_roles" can be used to pin the check item to a specific system role (or IT admin roles).
Attribute system_attributes can be used to pin the check item to a specific system attribute.
Note: Attribute system_attributes may only filter with regard to attributes that are associated to the type of landscape object that corresponds to the given config store, e.g.: Config Store ABAP_INSTANCE_PAHI is implemented on instance level. Therefore it is not possible to apply the Extended Sid as system attribute (system_attributes="ESID:<ExtendedSiD>".
To overcome this limitation you can use LMDB custom attributes following the naming convention "_LA_*" and assign them to your object on the desired hierarchy level in LMDB. As of Focused Run 2.00 FP03 it is possible to use these special attributes as system_attribute.
***Note: Input fields of Report COF_CIM_TREE_TS can be taken from the LMDB Object Maintenance:
The FAQ section is currently empty.