Closing the net on back door access via custom developments
Custom SAP developments allow businesses to unlock new potential within their SAP systems and deliver SAP processes to fit the exact way they work. However, beneath this opportunity lies an equally important responsibility - safeguarding data just as rigorously as SAP standard developments do.
We go to great lengths to secure SAP data so that only appropriate people can view and process it. And rightly so, this is one of the cornerstones of managing application security. So why not for custom developments that often process the very same data we protect elsewhere?
In this, our third topic in a series about the real world problems that firms contact us about, we’ll talk about the importance of securing custom developments as a matter of course and how legacy custom programs can often be a free for all when security hasn’t been considered at the outset.
Functional risks of not considering custom development security
In the SAP standard world, data is meticulously protected, but custom developments often introduce vulnerabilities. Securing custom developments sounds like a really obvious thing to do but over the years, this has consistently been one of the biggest security weaknesses out there. This discrepancy can lead to unauthorised access where without a robust authorisation check, data that should be protected, becomes accessible to unauthorised users. Indeed, it can mean that even though you stop users accessing the data via your standard roles and authorisations, they get back door access to that same data and process via a back door.
In a sense, having this back door open via unprotected custom developments is far worse than providing unauthorised access via SAP standard transactions and roles because unless someone goes looking for these back doors, there is no general visibility of them and users that have unauthorised access will likely go undetected for long periods of time.
Establishing authorisation checks: a strategic imperative
To secure your SAP custom developments, it's imperative to establish robust authorisation checks which will ensure your data and processes are protected as expected. Consider the following steps to determine what checks should be built into your projects:
Data classification: Begin by classifying the data within your custom development. Identify what data requires strict protection based on sensitivity and possibly regulatory requirements.
Business process analysis: Understand how data flows within your custom development and identify points where authorisation checks are necessary to maintain data integrity. This will often be similar if not the same as the way similar SAP standard programs do it but each situation should be assessed and appropriate solutions defined on a case by case basis.
Role based access: Align authorisation checks with transactions, processes and roles to ensure access is strictly controlled and provided to the right users.
Retrospective authorisation checks: A lifetime of custom developments by-passing your intended authorisation checks?
Historically, most organisations never secured custom developments. So what about those custom developments that weren't secured when they were first written? For me, this is one of the biggest issues in the world of SAP security and it’s still a hidden issue in the main. The good news is you can retrofit authorisation checks into older custom developments to bolster security. Here's a roadmap for being able to do this retrospective project:
Custom development identification: You first need visibility of all the developments in your system and to perform an analysis of which ones currently have no authorisation check built in.
Data assessment and code review: Conduct a comprehensive assessment of the data within each custom development to identify vulnerabilities and access points. Examine the existing code to identify areas where authorisation checks need to be integrated.
Authorisation requirements: Define the authorisation requirements based on the data assessment. Determine which roles need access and at what level.
Testing and validation: Rigorously test the retrofitted authorisation checks to ensure they function as intended; the users that should be authorised must still be able to use the development so the business is not disrupted whilst unauthorised access is stopped once and for all.
Documentation: Often overlooked, document the changes made to the custom development, detailing the authorisation checks implemented and their purpose.
Closing the net
It’s also important to enforce strict procedures into your development process at the planning or design stage and into sign off gates so that security checks are built into the development as it’s designed and then have checks and balances built in to check they were done during testing and sign off ahead of the development being promoted to production. In my experience, all of these elements are required in a process to keep on top of ensuring all developments are protected as they should be.
The reality is that building in authorisation checks to custom developments and keeping your system and data secure is pretty straightforward. This is one of my “big ticket items” that I wish more companies would review. The fact that there is low visibility of the issue and that unauthorised access is hidden really is a worry. If I were accountable for system security, this is an area I’d be genuinely concerned about. Get in touch and let’s chat about your plans for tackling this.
#SAPSecurity #CustomDevelopment #DataProtection
