Author: TJC Group Chief Security Officer and Content Marketing team.
Recent research conducted by SAPInsider across an international sample of SAP users has identified that although ransomware attacks are still considered the biggest cybersecurity threat, a new threat is following behind as a close second. Today, the next biggest threat after ransomware and malware attacks relates to system patching. Or rather, threats that arise when system patching is not kept up to date.
“Unpatched systems are possibly the easiest way for any cybercriminal to gain access to IT systems, by targeting well-known system flaws and vulnerabilities.”
Highlights from SAPinsider report
This is the low-hanging fruit of the cyber security world, the really obvious entry points. Many organisations will invest hundreds of thousands of pounds, euros and dollars into buying the latest cyber security technology to try and thwart sophisticated attacks and yet fail to secure the hacker’s obvious routes.
42% of the organisations participating in the SAPinsider research admitted keeping up with patches and updates was an ongoing problem, rating it as their number one challenge
Why is patching complicated?
The issues that arise when trying to schedule patching are similar to the ones that admins experience when managing the decommissioning of legacy data. It can be difficult to schedule system downtime to complete a patching process (45%). Organisations have to manage competing business priorities (40%) and very often patching will be put to the bottom of the priority pile. IT departments can be reluctant to apply certain patches too, in case of a negative impact on system availability (40%). Some users will be unable to distinguish between the most vs. less critical patches (37%) and they may have limited IT resources available to apply the patches (34%) and then check that they have been implemented properly.
“Very often patches must be applied manually, which is time-consuming and resource-intensive. It can be a similar scenario for legacy system decommissioning and, just as with patching, it can be easier to sit tight and do nothing, but with potentially disastrous consequences for cybersecurity.”
Issues when patching SAP systems?
Patching SAP systems is known to be a complex process. This begins at the hardware level and embedded software updates, progressing through the operating system, virtual machine hypervisor (if applicable), the database, and finally finishing with the SAP solution itself. Each patching update requires an individual review to ensure its applicability and a test plan to ascertain that it solves the problem fully and does not introduce any new problems.
Specifically for SAP legacy systems, there are other complications when considering system patching, for instance, no longer having access to the primary DEV/QA/PRD landscape, but just a sunset PRD system. There may be other vulnerability management implications too, because the older system may not allow the integration of SAP logs into a SIEM (Security Information and Event Management tool).
Learn the difference between sunsetting a system and decommissioning a system.
The question of legacy systems management
When considering the issue of patching, dealing with current, productive systems tends to come to mind, because most organisations will mostly be concerned with implementing patches for the systems currently in use. What about legacy systems? Those that are lingering around but no longer in regular use. The ones containing legacy data that is also outdated, obsolete, and, to some, outlived its usefulness. This data needs to be archived off and decommissioned, but it can be a complicated task to decide whether a certain data set should be regarded as legacy, especially in highly regulated sectors such as healthcare and finance where it may need to be kept beyond its useful lifespan.
Legacy data can be a cybersecurity risk because it may not be encrypted or protected by other access controls, making it more vulnerable to data breaches and theft.
It is far safer to decommission legacy data and store it away from other critical databases, in a place where hackers would not be able to gain access. Find more insights in the following article: SAP vulnerabilities and why it is not safe to keep legacy data in an old SAP system.
ELSA (Enterprise Legacy System Applications) is a good option because it makes light work of data decommissioning. Designed and developed by TJC Group, it neatly ring-fences obsolete data and maintains its easy accessibility. In terms of security, ELSA is built on SAP BTP and therefore is a very secure application. Additionally, the application is connected to a database (such as MySQL, PostgreSQL or HANA Cloud) and blob storage with a private endpoint connection.
For SAP users, one the best feature of ELSA is that it’s a SAP native application, designed for use with SAP systems but equally compatible with non-SAP legacy systems. ELSA ensures all legacy data is stored securely, minimising any risk from cyber moles, and benefiting from both SAP and major hyperscalers security measures.
Final say
Many organisations today admit it’s difficult to stay on top of cyber security measures and are spending a growing amount of their IT budgets on technology to keep the cybercriminals at bay. SAP customers admit that it’s a challenge, but it doesn’t have to be this way. By focusing on low-hanging fruit to minimise vulnerabilities, like ensuring that patching is always up to date, and by decommissioning legacy data and systems, they can go a long way towards protecting their organisations.
Enforcing security on legacy systems is one of the main reasons for system decommissioning. Find more information in this webinar: the nuts and bolts of Legacy System Decommissioning for SAP and non-SAP systems.
