If you are responsible for SAP security, then it is likely that you use dedicated security tools to protect SAP systems against exploitation and fraud. The effectiveness of your work is determined to a large degree by the effectiveness and quality of these tools.
So, apart from the obvious selection criterium: “having a large scope of security checks and covering all known high risks”; what else should you be looking for in SAP Security software?
SAP security software:
- Should be easy to use, self-explanatory and offer relevant information content about threats or vulnerabilities.
A good security application trains and educates its users instead of leaving them mystified by cryptic messages.
- Should offer meaningful ways of helping with remediation and mitigation of threats.
Only offering a list of what has been detected is not enough. One of the biggest frustrations by users of SAP security software is seeing a huge list of vulnerabilities displayed after a security scan and not getting any advice on how to deal with these. Every vulnerability discovered should be explained in detail and have pointers to the best remediation or mitigation practices.
- Should be robust and capable of handling large SAP systems
The software quality must be high enough to avoid and to handle exceptions and the SAP Security application must be scalable to be able to scan large SAP systems that have multiple large application servers.
- Should be efficient and only execute checks that are relevant to your systems
The SAP security software has to be “intelligent” enough not to execute Windows checks on Linux platforms or DB2 check in an Oracle database. In addition, it must not execute checks on services that are not offered by an SAP instance nor execute version-dependent checks on software components that do not meet the version requirement.
- Should be accurate and deliver neither false positives nor false negatives
False positives are huge time wasters for any SAP security organization and false negatives provide a false sense of security.
- Should be auditable themselves
An SAP security tool stores sensitive security data and therefore it should have some form of authorization structure (RBAC) and have changelogs that record user actions. The data stored in the SAP security application should be protected against data leaks or unauthorized access.
- Should not introduce new vulnerabilities
Example: a security tool may use software agents inside SAP systems. These agents must be secured properly and every possible means of exploitation of these agents must have been prevented.
- Must not interfere with business processes nor affect SAP system behaviour in any way
Some examples: when the software causes system dumps, performance problems or locks RFC destinations, this may adversely affect SAP satellite systems and even business processes.
- Should offer a clear and uniform risk metric along with an indication of remediation effort
This makes it possible to compare SAP systems in terms of risk and to concentrate efforts on those SAP systems that need it the most and high-risk vulnerabilities that are easy to solve.
- Should enable a process of continuous improvement
Continuous improvement is a cyclic process that makes your SAP systems more secure over time. It consists of:
- Scanning & verification
- Analysis & selection of remediation measures
- Execution of remediation.
Does your current SAP security software lack one or more of these features?
In that case, you should ask yourself whether your overall security processes are adversely affected or even limited.
Start using Protect4S which has all these features (and many more) for an attractive price.
Contact us to find out more about our software and get a quotation!
