Configuration and Security Analytics

Advanced Configuration Monitoring capabilities within Focused Run comprise the application Configuration & Security Analytics (CSA) with Validation, Changes, Search and Store Browser and Configuration & Security Analytics Administration. The Administration provides information about the Collector Framework for CSA.

The Capabilities are available after the setup (Single System Integration, SSI) has been done. CSA detects and records common technical changes in a managed system. A change tracking is performed during upload of the extracted configuration information.

On managed system side the configuration data is collected and transferred via Simple Diagnostics Agents (SDA) to the Focused Run system. There the data is compared with the previous snapshot to identify changes. Data is stored in HANA database tables (starting with CCDB_DATA_) comprising the Configuration and Change Database (CCDB). For the general architecture and data flow of the application see also the below picture.

Figure: CSA data collection

The Configuration and Security Analytics (CSA) application collects configuration items and support different views on them:

  • Validation checks the configuration items against a defined policy, e.g. whether the setting for the password length fits to the security requirements
  • Changes displays the changes over time
  • Search and Store Browser help to find configuration items and the objects
CSA is launched via the FRUN launchpad.

CSA Applications

Validation

Validation provides a reporting to understand how homogeneous the configuration of systems is. Using centrally stored configuration data in Focused Run to perform a validation of many systems using a sub set of the collected configuration data defined by the selected policy (see also the below figure):

  1. Validation shows the results of a validation run based on rules of a policy (policies are maintained in policy management including check id and description).
  2. In systems the validation results are aggregate on system level.
  3. Details for a system shows all items checked by the chosen policy for a system.

Figure: Validation of systems

Policy Management

The validation rules collected in a policy are stored in a XML file. The rules are organized via checks. Each check has an ID and a description. It's possible to define a compliant and a non-compliant rule for a check. Each check is referenced using a check Id and a check description. Finally, the XML document is transferred to a SQL statement which is used for the validation of the items. Thus, validation can apply the policy to many systems in one run.

  1. Rules organized via checks. Each check has an ID and a description
  2. It's possible to define a compliant and a non-compliant rule for a check.
  3. Join-combinations of rules are supported (within one store and between different stores)
  4. Defining store hierarchies is supported (e.g. instance to host)
  5. Compliant and non-compliant columns correspond to the config store structure available in browser.
  6. The compliant and non-compliant rule itself are defined using a sub-set of HANA SQL.
Exemptions for Policies

In Exemption for Policies application the exemptions of the rules defined in the policies can be specified. There are two kind of exemptions: One exemption re-defines the validation outcome for a check id for assigned systems for a period. During this defined period the combination of system and check is not validated. The other exemption prevents a check id from becoming active at all before a due day is reached which is system independent. The validation application applies the exemptions by default but offers also to run the validation without the exemption.

Changes

Changes provides an overview of the changes that have been applied to the managed systems. It also displays the number of changes per system, store and day. It reports changes of configuration items of a system (for example, OS, DB, ABAP parameters, Java parameters, transport requests, and Support Packages). Changes helps to keep track of the changes in the solution landscape. The development system might behave differently than your production system. Or, J2EE instances of your productive system behave differently and you need to find out the reason. Therefore, regular snapshots of the configuration settings are taken and stored in the configuration and change database (CCDB) of Focused Run. With this information, changes enable to identify the adjusted items. Changes displays the number of detected changes for a technical systems in scope (see also the below figure):

  1. Drill down on changes (sum) or on the number of changes per day.
  2. Drill down into changes for a system
  3. Drill down into changes for a config store
  4. Drill down into change history of an item
  5. Change the time frame selection (date range)

Figure: Changes

Changes are a common starting point for analyzing issues in the solution landscape. Imagine that something worked yesterday, but it is not working anymore today. The first question would be what changed in between?

Changes is the tool to analyze issues like this. The tool starts with an overview on the overall changes which have been applied to the landscape. You can use the timeframe selection, to limit the timeframe to the point when the problem occurred first.

Search

Search finds configuration items by an entered string. The search is done by looking for field contents that fit exactly, except when the wildcard * is added. The wildcard * stands for any characters. If the character * should be found as a character the back slash must be placed in front of it for escaping. E.g. sap* finds all items having the string sap followed by some additional characters stored. Search will find the user SAP*, if sap\* is used as search string.

If just one character is unknown, use the? for it, e.g. sap? finds strings that are four characters long and start with sap.

The result is displayed in a table having a common structure, because items of config stores having different structures (columns) might be found.

ConfigItemKey holds the collected keys and Value the collected data fields of an item. Type of event provides information whether the item is still unchanged which means INITIAL or has got ADDED or UPDATED after the very first snapshot. The History of Item displays the current and the previous value with its time stamp (column Element History).

‘Switch table view' displays the items of the selected config store in a table which creates a column for each key and value fields. The search has the following features:

  1. Search allows to search for item names and values in CCDB. Search output can be filtered per config. store
  2. The search result provides a common view for all items. A column view of a single config store is possible
  3. HANA search supports OR to combine patterns and supports wildcard *
  4. \* searches for the character *

Store Browser and the Role of Config Stores

The single configuration details of systems connected to the Focused Run are stored in the containers of a defined type called ‘Config Store‘ in the Configuration and Change Database (CCDB) which is a part of Focused Run system. There are different kinds of Config Stores dependent on the source of the data: Property, Table, File, Xml and Event.

In the example below, you can see the content of the Config Store SAP_KERNEL which contains details on both the currently implemented kernel attributes as well as the change history of the kernel. The Store Browser has the following features:

  1. Store Browser displays all technical systems having config stores
  2. Store Browser displays for a technical system all available config stores
  3. It's possible to drill down into the config store content and into the item history
  4. Timestamp shows the last extraction date. “Valid since” shows since when item is unchanged
  5. A config store is always referenced to a landscape element

 

CSA Administration

CSA Administration is launched via the FRUN launchpad. The systems view groups the collectors according systems. The collectors view lists the collectors and hosts and for which systems the selected collector is responsible. A collector is related to a host.

CSA Administration offers next to the application the links to ‘CSA – Template Management' and ‘CSA – Processing'.

Systems

The System status screen displays a table of selected systems and their status from CSA point of view. On top of this table the numbers of systems which collectors are working ‘Correct', have ‘Warning' or ‘Error' or are ‘Delayed'. There is also an information how many systems in ‘Total' involved or have a ‘Downtime' currently. In the application you can find the following information:

  1. Check amount of errors per system. Select system with status „Error
  2. Identify the collector item which caused the error and select it
  3. The Extractor/ Processor error message is displayed and can be analyzed

Collectors

The Collector status table holds information about the Load Status of the data, the Customer, the Host of a collector. ‘Changed at', ‘Sent at' and ‘Confirmed at' display the time stamps that are related to the configuration of the collector. The ‘Version' and ‘Started at' are related to an agent. In the application you can find the following information:

  1. Check all collector status information. Select collector with status „Error“
  2. Identify the system(s) which are using the selected collector. Start the error analysis
  3. Check the load status for each collector item and select one for further analysis
  4. The Extractor/ Processor error message is displayed and can be analyzed

CSA Processing

The CSA Processing helps the administrator to get an overview of the workload and times related to the data processing for CSA in Focused Run. It enables the administrator to identify potential bottle necks and special situations. The views are arranged in ‘Inbound', ‘Inbound Queue Reader', Inbound Queue Processor, ‘Local Batch Collector' and ‘Log'.

The Processing dashboards offer several statistical information regarding the performance of configuration data collection. The graphical statistics display (see also the below figure):

  • Number of Inbounds
  • Average Write Runtime
  • Number of Processed Packages
  • Processing Workload
  • Wait Times
  • Application Data Processing Times
  • Transferred Data Volume

Figure: Administration - CSA Processing

CSA Template Management

The collectors and the data to be extracted is controlled by templates. These templates are related to an application (CCDB or EWA), have a Description and a SCI ID which identifies a single template. It is possible to ‘Create', ‘Display' and ‘Delete' a template and to write the definition to a ‘Transport' request. The template definition is described via XML which is visible in a dialog, if ‘Display' is clicked. The template management is reserved for SAP experts.

Templates control the extraction and storage of data:

  1. In template management it is possible to create, display, delete or transport templates
  2. Display opens the maintenance app which allows to change the extractor (collector item) definition