Tag: exemption

SAP Focused Run security baseline validation

With the help of Security and Configuration validation you can quickly get an overview of the security compliance of your systems.

Questions that will be answered in the blog are:

  • How to convert your security baseline into a SAP Focused Run Policy XML file?
  • Does SAP provide best practices for security baseline?
  • How can I run a check against many systems?
  • How can I see which security parameters are ok and which ones are not ok in one overview?
  • Can I apply a temporary exemption to the policy?
  • Can I be alerted if a security parameter is changed from compliant to non-compliant value?
  • How many security policies should I create?

SAP Security baseline

SAP publishes a generic SAP security baseline template. For more information on this template, read this blog.

On the SAP github for Focused Run, SAP has put the XML policy files that correspond to this security baseline:

The formally published version of the SAP security baseline is version 2.4.1. The published github files are only updated until version 2.4.0.

Company security baseline

The SAP security baseline can be used as a quick start. But it still needs to be tailored to your company:

  • Values might need to be altered (example; length of password)
  • Values might not be relevant for you (this normally not the case, but it could be)
  • Extra checks that are not in the SAP baseline need to be added

Exemptions

We will explain later below in the blog how to deal with exemptions. A good example of an exemption is that you have a rule, but cannot apply it to all systems. Example is the login/disable_multi_gui_login parameter. By definition you want to set it to 1 to forbid multiple logons. But for 1 older system this is not possible and you have agreed with security team on an exemption. In this case, you don’t want to have a new policy. You keep the single policy but apply the exemption.

Creating the policy file(s)

With the help of the examples in the SAP security baseline, you can build your own company security baseline policy XML file.

In this file I have made an example which contains a lot of password and logon parameter related checks for the ABAP stack:

Generic-password-baselineDownload

Goto the Policy Management FIORI tile:

Create a new policy and give it a meaningful name and description:

Now press the edit button and copy and paste the content:

Now Save the policy, Check and Generate. Now you are ready to run.

You can modify the existing values in the XML sample to your need. After it is changed, Save, Check and Generate again.

Running the baseline policy

Start the Configuration and Security Analytics tile:

Select the Policy, and let the system run to get the results:

By clicking on the tab Checks you can zoom in on which items are not ok:

By clicking on a specific check you get the details for that check, which systems are not ok, and what the current value is in the system:

In this case the value 0 for special character is not ok. It should have been 1.

The tab System/Checks gives you an overview of all systems and all checks in one shot (you do need to expand the columns to more values):

Applying an exemption

Ideally you want to solve all the issue by changing the security parameters to meet the security baseline. This is not always possible. After agreement with your security team an exemption can be applied.

When you have done the security baseline run, click on the bottom left the Links icon and select Exemptions for Policies:

In the next screen press the create button to create an exemption:

Select the policy and the specific check you want to exempt (in our case we use the logon password compatibility as example) and set a due date or date range for which the exemption is valid. By setting the due date, it is valid for all systems.

With a date range, you can make the exemption applicable for selected system(s):

Remark: this one is using date range!

Now you can run the security policy again:

You can see in the text exemption have been applied. Also the tick box for Apply Exemptions has appeared. You can untick the box to run the policy without the exemptions.

Alerting on non-compliant changes

Once you have everything under control and all green (meaning all systems are compliant to baseline, or exemptions are applied), you can set up alerting to inform you that a security parameter was changed into a non-compliant value.

When running the check, go to Links on bottom left of the screen and select the Configuration Validation Alert Management option:

In the next screen now create a new alert:

Important here: carefully set the frequency. Do select the System Scope. If you want to check ABAP systems for production only, do set this into the scope section. And Set it to Active. And Save.

Every day the check will run and you will get an alert upon detecting a new non-compliant item for this policy.

More information on using the alert management function can be read in this blog.

How much policies should I create?

You can have as much policies as you like.

As a best practice, create one big one for your companies security baseline per system type:

  • All ABAP security parameters
  • All JAVA security parameters
  • All HANA security parameters

The initial setup might be quite some work, but once setup and cleaned up, the system will do all the work for you, and you need to check the alerts only.

For ABAP OSS notes you can also create policy files. See this dedicated blog.

For special cases you can create dedicated policies.

Use case for checking existance of client 001 and 066

Security & configuration validation can be used to check for the existence of clients 001 and 066.

The 066 early watch client and old delivery clients 001 are only security risks (unless in rare cases 001 has been chosen as execution client). Best to delete them from security point of view (see reference blog).

<?xml version="1.0" encoding="utf-8"?> 
<targetsystem xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" desc="Test CLIENTS Store" id="TEST_CLIENTS" multisql="Yes" version="0000" xsi:schemaLocation="csa_policy.xsd"> 
  <configstore name="CLIENTS"> 
    <checkitem desc="CLIENTS_CHECK" id="1.0.0.0"> 
      <compliant>
        MANDT = '000' or MANDT = '010' or MANDT = '100'
      </compliant> 
      <noncompliant> 
        MANDT = '001' or MANDT = '066' 
      </noncompliant> 
    </checkitem> 
  </configstore> 
</targetsystem>

In the compliant section add more clients that are valid and/or change the numbers to your own situation.

Basically the rule says: 001 and main client(s) listed are compliant. 001 and 066 are not compliant.

Result:

<< This blog was originally posted on SAP Focused Run Guru by Frank Umans. Repost done with permission. >>