In my work as a consultant for more than 20 years, I never came across a customer who did initially state that security is not important.
Of course they all care about it to some extent. And even though resources are limited, they try to do what is necessary. However, when it comes to putting real security measures into practice, I faced two major obstacles that drain resources in a way that often result in not finalizing the work or even not beginning it.
First, there is the transparency issue: many times, enterprises feel more secure than they really are - which results in work not being started at all. A perfect example in the SAP space is IT staff who regularly patch their systems based on the publications from
SAP's security patch day (every 2nd Tuesday of each month). While that is already quite a feat, what is often overlooked is that many patches not just require the contained corrections being applied but also manual configuration to be done. A result, the corrections of such Notes are not utilizing their protective effect! This is exactly what happened for the
RFC Gateway and Message Server Security story in the past: too many SAP teams did not spot this and were very much surprised by
recent reports in the media that 9 out of 10 companies might still be at risk, including probably theirs!
What surprises many SAP customers here is when I point them to information that has been available to them for years, but has never been used so far: the
Early Watch Alert. This is a standard regular report created by the SAP Solution Manager system. And it always contains a detailed security section that should be processed with priority. This section would point any SAP customer – if the report is read of course! – to the missing Gateway security settings. And if the Early Watch Alert report (or its
cloud version) is still not sufficient for your purposes, you could easily make use of the
Configuration Validation application in the SAP Solution Manager and feed it with content from the
SAP Security Baseline Template. Within a couple of hours, you 'll have a fairly decent, customized reporting on missing configuration items at hand! In many situations I've been with SAP customers, both applications have been a real eye opener.
But let's now turn to the second, and even bigger issue: after knowing what needs to be done, security measures drain resources because they are tedious to implement. What makes it difficult is not the implementation itself, but getting away with its potential side effects. These are not easy to judge unless you have highly experienced staff available - and even then those guys might still not foresee some weird complication in a customer specific environment. Consequently, security settings very often require regression testing. And this is costly, as it needs to be done by the business to make sure none of their critical applications is impacted in an adverse manner.
As a result, companies often shy away from implementing security measures as they lack the time and skills to do all the required testing afterwards. However, it is of course a fairly bad idea to put stability over security all the time as the business applications will no longer be available either if the system ever gets hacked. I once had a customer who got hacked, and had to shut down a productive system for 6 weeks(!) to cover all the forensics and rebuild activities. While in this particular case it was survivable because the system ran a business application of "minor" importance only, partner logistics were down to some extent as well and this still did cost a lot of money. Got it? Security done badly = significant risk of downtime. Bad media coverage and data loss is of much lower importance typically.
So how can we minimize the efforts preventing enterprises from properly implementing necessary security settings and corrections? After all these many years of haggling with "business first" discussions, for me the following strategy works best: never run it standalone, but simply put security together with other change activities: 1. Implement high priority corrections together with normal business changes ("customer release cycles"). 2. Implement other security measures in one go with software upgrade activities. This latter one is my favourite these days: Within a major change activity, after the technical upgrade has been finalized by the SAP Basis team, I get the system for one day. And I put in all security settings still open. Only after this day will the system be opened again to the business for testing. Sound’s a bit like a no brainer, but still many security teams try it the hard way, implementing security as an individual activity. Which , of course, gets all the blame then if something goes wrong.
Recently, more and more companies have asked SAP why all of this is needed. If certain security settings are already recommended by SAP (read the
security whitepapers SAP has published in the past), why do we have to implement them at all? Why isn't SAP shipping them right away? Well, we do now! SAP delivers to this popular demand and since Sep 20, SWPM and SUM automatically maintain additional security settings when installing, copying or converting to S/4HANA 1909. See SAP Notes
2714843 and
2713544 for details. So instead of the implicit manual opt-in of the past, SAP is turning this principle upside-down and puts it into an active opt-out. If individual customers later on observe adverse effects, they can deactivate the settings themselves - which is more trivial than the other way around.
Bottom line:
- Use the SAP-provided tools and services, such as Early Watch Alert, Configuration Validation and System Recommendations (it displays missing security patches). These tell you about gaps in a cost efficient way.
- Always introduce disruptive security settings with good timing. The upgrade situation and new installations are very good points in time for this. No additional testing required - which is the most expensive part of security.
- SAP is now delivering with its new S/4 version as well, providing an up-to-date “secure by default” design. So in case you are running a conversion, nothing has to be done for a variety of settings.
With future versions and time passing by, many security settings will be upgraded automatically in customer systems, becoming the new secure default. And this frees up resources for the more complex issues at hand, like custom code security, interface authorizations optimization and other measures that cannot be as easily automated.
