Podcast: Beyond SAP Security - Nipun Mahajan

Raghu Boddu: Hi Nipun, very good morning.

Nipun Mahajan: Raghu, first of all, thank you so much for the invite to be on the SAP Security Expert podcast. I think we've all grown up reading your blogs and following what you have done for the community, so I do appreciate all the work you have put forward for the community, especially in SAP. You asked how I moved from SAP security to SAP cybersecurity. It was always my thought process that I wanted to do information security work. In 2018, after eight years in SAP security and GRC, I opted for a master's degree program at Colorado State University in Fort Collins.

Raghu Boddu: Thank you, thank you.

Nipun Mahajan: Within that program, there were some great courses like networking, ethical hacking, and programming. That helped me build an understanding of what information security exactly is. What I realized was that if you have an understanding of a product, let's say SAP, and you have an additional understanding of information security, that makes you a master of the art. You know the product, and you know the other side of the house. That way you can integrate the different skill sets and help the community, as well as your company, stay secure. So that's my journey.

Raghu Boddu: OK. A lot of times when I talk to customers and to some of my connections in the SAP security space, for them security is part of Basis. They feel security is work delivered by SAP Basis consultants. Even explaining what security is becomes a challenge many times, especially with customers. So I see this gap. They wonder, is it part of Basis, or is it just user creation? Personally, I feel it is not easy to tell customers that security in SAP is entirely different. How do you frame the idea that SAP cybersecurity goes far beyond SAP security?

Nipun Mahajan: Great question. I think we should start by defining what is critical for an organization. What's the crown jewel? If the majority of a company's transactions sit in its SAP systems, that makes SAP more critical for them. Every organization should determine what its crown jewels are, and what happens if those stop working. Second, application security. Yes, there you have some level of controls, because external auditors look into some aspects of it. But when it comes to cybersecurity for an SAP system, you need to understand that the scope of how SAP works has changed a lot. Initially, many of those systems were on-premise and not exposed to the internet. The whole landscape has changed, and that is where a person like the CISO should be involved in SAP cybersecurity. It cannot be handled only by the SAP security team or the SAP Basis team. There should be reliance on the information security team, who can provide relevant inputs on how to include SAP in the threat landscape and then implement proper controls and monitoring.

Raghu Boddu: I think you made a really good point, Nipun. What I see is that many customers are now moving to RISE and GROW, the private and public cloud offerings. When I talk to customers about security, I speak about how they should secure it, especially when a lot of their data is moving into the public domain. People can access SAP from any location. It is no longer restricted to their boundaries. And most of the time I hear one thing: customers say, "Now SAP is managing everything. We don't have to worry. We don't get access to the database, so it is SAP's problem. SAP should safeguard it. SAP is patching it from time to time." I see this as a clear gap in understanding. Many CIOs and CISOs feel they have already transferred the risk to SAP, which is definitely not correct. So I want you to speak on this point. What is right, and what message do you want to give to people who think the risk has been transferred to SAP?

Nipun Mahajan: Great question, and Raghu, I agree with you. A lot of these customers think they have transferred the risk to SAP. What I ask a lot of people, and I raised this point during a conference, is: have you gone through the contract for your RISE or GROW landscape? Who would ultimately be accountable in case of a cyber breach? You will have to determine that based on your contract. A company is also responsible to its own customers, so it will be held liable in case of a breach. That is where they should start.

The other thing is the shared responsibility model, where there is a clear gap. SAP only looks after a specific level of infrastructure and OS-related work. Some services are available to customers, but only if purchased as a top-up.

Raghu Boddu: Correct. Yeah.

Nipun Mahajan: For example, there is a basic understanding that development, quality, and production systems should have VLAN segmentation in place. But when you actually look at the SAP contract, it tells you that they are in one VLAN. You would have to purchase a specific service called Firewall as a Service to implement that. That alone should ring bells for people to look at what service SAP is actually providing and what falls in their area.

Another example is disaster recovery. I'm an information security guy, so disaster recovery matters to me. You have to opt in for a disaster recovery service, and within that, SAP will help you with disaster recovery scenarios. But you have to be involved with them. It's not as if they will do all the work. You should define a process. If you have an SOP for your on-premise systems, you should have a similar one for your RISE systems. Suppose your system suffers a ransomware attack and your backup is gone. Do you have a backup in the form of tapes or something else? Can you actually recover and get back on your feet? If you look at the attacks happening right now, they are bringing companies to their knees because of so many advanced threats to the SAP landscape.

Raghu Boddu: I understand. I also want to speak about a couple of other services that enterprises really need to look at, which are pretty important. Maybe you can add your points here. One is LogServ, which collects all the logs from the SAP instance. That is a fantastic product that every company should pick up, whether it is part of the contract or not. I feel it is really relevant for organizations to subscribe to LogServ to collect the logs and ship them to an external SOAR. Similarly, there is the SIEM service and the dashboard where log analysis is done, in Sentinel, if I'm not wrong. SAP is also pushing Sentinel. That has to be connected for you to understand what kind of threats exist in the system and what potential attacks are happening. What is your view on these services?

Nipun Mahajan: Exactly, I would agree. Again, look at the threat landscape, Raghu. SAP is not a standalone system. It connects to your manufacturing units. You have manufacturing execution systems, OT systems, and maybe some billing devices connected. So what happens in SAP doesn't stay within RISE; it gets pushed further. Interestingly, not every SAP security consultant has a background where they look at an integration scenario and ask whether the right level of controls is implemented. Is the authentication up to standard, or is it just basic authentication? I was recently attending a seminar where it was shown that Cloud Connector logs could easily reveal the password for an RFC user. You should have a control like SNC, Secure Network Communications, for that. These are things that have not been talked about, and again, the threat landscape has changed. People need to start looking at it.

Raghu Boddu: Yeah, I agree. I normally tell people that wherever SAP security ends, that is where cybersecurity begins. They go hand in hand, but they are not one and the same. Even C-level executives feel that security and cybersecurity are the same thing. For example, I speak about UCON, Unified Connectivity, a standard solution offered by SAP, and the Security Optimization Service (SOS) report. These are fantastic built-in tools, available free of cost, that help you understand your potential threat surface. But people feel this is part of SAP security, part of authorizations, to be precise. I'd like you to add your observations, views, and experiences here.

Nipun Mahajan: Sure. I can talk a little about my job profile. I am part of a pharma company, where I serve on the SOC team, the security operations center. The reason I'm there is that I understand SAP. I understand reports like SOS and EarlyWatch, and the basic functionality you need to recognize what an SAP threat might look like. So I am closing the gap that exists between the SAP security team and the CISO or information security team.

A lot of times, Raghu, I've seen an increase in insider threat when it comes to SAP Basis. Suppose an employee leaves the organization and that person is from SAP Basis. They know the system inside and out. You need someone who can monitor what is happening in the system and implement the right level of controls. Think about SAP BTP. BTP is used to connect to your back end and your other integrations.

Raghu Boddu: Integrations.

Nipun Mahajan: And this is something the authorization team is not even involved in. If SAP Basis is handling it, it's a gateway to heaven. If that person goes wrong in BTP, you're in a position where you cannot do anything.

Raghu Boddu: You're giving the keys to the other guy.

Nipun Mahajan: Exactly. My role is to make sure these people know I'm monitoring them. If you don't do that, they are free to do whatever they want. Not everything gets logged. If you look at SM19 logs, for example, a debug change, not everything gets monitored by the authorization team. This is where we, as cybersecurity consultants, need to understand why a debug change was performed by a user. Was it authorized? If not, it's a concern. And I think even external auditors have started to look into it.

Raghu Boddu: Yes, exactly. I think this is where you need proper SIEM and SOAR solutions. SIEM and SOAR are key at this point in time. I usually tell people that the way I managed SAP security when I started my career, probably 22-plus years ago, is the same today. I'm still using the same SU01, the same SUIM, the same PFCG, the same SU53. The transaction codes we use to manage SAP security have not changed in the last 20 years, including the screens. But the threat landscape is not the same. The threat actors are not the same. The intensity of the threat is not the same. Organizations should understand this and bring in more sophisticated tools, techniques, and people. But you are the cybersecurity expert, and I know you can add a lot of value to my comments. So let me pack everything into one simple question: what is the core cybersecurity gap you see that enterprises should be aware of today?

Nipun Mahajan: One of the gaps I've seen is the belief that SAP systems cannot be hacked. If you present a report, people will often ask, "Has any company been hacked because their SAP systems were vulnerable?"

Raghu Boddu: Correct.

Nipun Mahajan: I think that is one of the biggest misconceptions. We have seen some recent attacks involving SAP, and in the current scenario, so many vulnerabilities are coming out as HotNews, with CVSS scores of 9 and 10. And to answer your question, Raghu, when it comes to SIEM and SOAR, most companies have these platforms. The gap is in getting the SAP audit logs into those SIEM and SOAR systems.

Raghu Boddu: Yeah, shipping them to the SIEM and SOAR system. I completely agree, Nipun. One of the biggest challenges I've noticed with many enterprises is that they filter what data goes into the SIEM rather than sending everything. They don't want to ingest the complete logs. I'll give you a typical example from one customer, without naming them. They had disabled the SM21 logs and were not shipping them to the SIEM. They had a SIEM platform and a SOAR platform, but they were not shipping SM21 logs at all. When I asked why, they said, "We share IDs, so we don't want our SIEM application to flag that IDs are being shared between people. The auditors should not point this out." That is why they simply stopped shipping those logs.

I asked them, do you know that the majority of incidents happen with insiders? Insider attacks are a huge challenge. And trust me, with this one customer, within 10 to 15 days after my meeting, there was a data breach. It was caused by an internal resource, an employee who had been with them for almost 15 years. It need not be something the employee did intentionally; it can be unintentional too. But who is the ultimate loser? What is the damage? It is reputation loss. It is data loss. Luckily, data protection and privacy laws there are not enforced to the level they are in European countries or the US. Just imagine this kind of incident happening in a regulated environment like a pharma company.

Nipun Mahajan: I would agree. Data loss from internal threat is definitely something I look into. SAP contains so much intellectual property. It might be recipes, vendor contracts, or customer contracts.

Raghu Boddu: Yes. It can be your design.

Nipun Mahajan: Exactly. Your whole company might depend on it. If production stops working, you are at a standstill. This is where, Raghu, I feel that no single tool is enough. You have to think about it from a holistic point of view, such as monitoring using your SIEM.

Raghu Boddu: Yes.

Nipun Mahajan: DLP, data loss prevention, is another area I look into. For example, for a table like MARA, you have to configure those details in your DLP so it can recognize what is leaving your platform. Yes, authorizations can restrict people, but what about the people who are authorized and are doing it on purpose? That's where DLP comes into the picture.

Raghu Boddu: Yeah.

Nipun Mahajan: I have seen people make careless mistakes and take data with them, and companies that are very serious about intellectual property will reach out, and people end up facing lawsuits. A lot of times people say, "I didn't know about it," but you are still guilty of doing something you should have avoided.

Raghu Boddu: Correct. I think people should understand the importance of this. Good. Let's move this conversation a little toward recent events. Last week, SAP released its patches. What is your view on Patch Day?

Nipun Mahajan: This year it has kept me busy. There are so many patches to look into, especially HotNews and high vulnerabilities. And interestingly, Raghu, you didn't see that many patches previously.

Raghu Boddu: In fact, that is my next question. What happened all of a sudden? You see a lot of patches, especially in the core of the product: the kernel, the protocols, the way the SAP system communicates, and the listener. Is this something that has just come up, or has the landscape expanded? What exactly is the reason?

Nipun Mahajan: The landscape was already there, and it has changed. But let me tell you a story. I was talking to a bug bounty vendor, and they told me, "Nipun, previously very few people used to report bugs. Now, because of AI and its capability, the number of cases reported to us is huge." At the same time, they told me that some of the reported cases are really good. That is where these CVSS 10s are coming from. So yes, SAP is changing, and so are other capabilities like AI, and for that matter, quantum as well. Quantum is coming. Think about how easily passwords...

Raghu Boddu: It's easy. It's easy to crack.

Nipun Mahajan: Exactly. Ten-character passwords are no longer enough. Interestingly, I'll tell you a story, Raghu, and it's a little funny. One time my password for a food chain in the US got cracked, and someone ordered food in New York on my behalf. I was wondering, what happened? How did it happen? It turned out my password had been revealed in a previous breach, and I might have reused the same password. A lot of times we don't realize it until we become victims. So now I use a password manager for all my accounts, so I don't have to remember them.

Raghu Boddu: OK.

Nipun Mahajan: Password manager facilities are available. Or you can do what my wife does: every time she has to log in, she does a password reset. That way, there are no worries about reusing the same password.

Raghu Boddu: I tell people it is no longer a password; it is a passphrase.

Nipun Mahajan: Yeah, it's a passphrase.

Raghu Boddu: Let's pause for a minute and have some water. Good. Great. I also want to talk about your ISACA article, which makes the point that the perimeter is not enough for SAP. Everyone believes SAP is internal. Even today, many enterprises manage SAP as an internal system within their boundaries. How does it end up being reachable from outside? And what should any enterprise look at to ensure its SAP system is not reachable from the outside world?

Nipun Mahajan: I think SAP systems are now getting exposed in many ways. You have platforms like Cloud Connector, or, for IBP, an agent sitting on your system to extract data and push it to the IBP cloud. So even if you are on ECC, you are already exposed to the internet. Restricting it to our own network is a thing of the past. Companies assuming this should definitely revisit their threat landscape.

Raghu Boddu: Yes, it is important. I think they have to relook at their existing SOPs and restructure them to ensure they are covering all of these things. This is where I'd like to raise another important point, Nipun: Unified Connectivity, UCON. When I executed it on one customer's landscape, which is on S/4HANA, I found about 7,000 remote function modules enabled to be triggered from the outside world. 7,000 RFMs can be initiated from outside. Someone with a basic understanding of how these RFMs work can simply hit a particular remote function module and get into the system.

Nipun Mahajan: Exactly.

Raghu Boddu: And this is on S/4HANA. What about people still on older versions of S/4HANA, or enterprises still running ECC? I think this is a clear gap people should understand. As you rightly pointed out, the threat landscape is not the same. You cannot even compare it with last month. There is a huge change.

Nipun Mahajan: Yeah, and Raghu, I would classify RFC as a very weak protocol, to the point that I would not let anyone use an RFC call from outside. If you want to do an integration, you should have middleware sitting in between, so you can at least use a different call, maybe SOAP or something that can protect your data. Even for RFC, there is SNC for encryption, but currently not everyone is using it. If you look at Wireshark and see the data being transmitted through an RFC, you would be surprised.

Raghu Boddu: Yeah.

Nipun Mahajan: So restrict it from the outside world. And yes, UCON exists, and you can control what is coming in, but you need encryption as well.

Raghu Boddu: Yeah. And the funniest part is that a lot of RFCs have a user ID with SAP_ALL or SAP_NEW.

Nipun Mahajan: Yes, exactly. Even to avoid an auditor, they will come up with a big Z role and say, "We don't have SAP_ALL." But if you look at it...

Raghu Boddu: Yeah, with S_TCODE set to star and all the objects.

Nipun Mahajan: Exactly. This is where my article comes in. I have seven fundamental points, Raghu, for a cybersecurity program for SAP systems.

• The first is: know your landscape. You should know what systems exist. If you don't know what you want to protect, you can never have the right level of controls.
• The second is: know the SAP SOPs that currently exist, for example disaster recovery or RFC user creation. If someone is starting from scratch, they should have those policies defined first. That is the primary aspect.

Once you have defined the policies, 

• the third is monitoring. You need to get all your logs into a SIEM, using any tools you like that are available in the market, so you can interpret what is happening in your SAP systems.
• The fourth is integration. What systems are trying to connect to my SAP landscape? This is where risk assessment comes into the picture, Raghu, because the authorization team is not involved in risk assessment. Whenever a company purchases a product, we need to know how that product will connect to the SAP system. What authorizations are required? What's the authentication? Is it encrypted? Are you going to use middleware? That risk assessment is very important to get the controls started from scratch. From an integration point of view, it's very important, especially with BTP. You should know which destinations you are connecting to.
• Fifth, once you have monitoring and your integrations defined, you start looking at the code level as well. There is so much technical debt, and you cannot miraculously fix everything in a day. But you define what is acceptable and what can be mitigated. At the code level, are there any hard-coded user IDs? Is there SQL injection?
• Once that is defined, the sixth is patch management. Patch management is an interesting area, and something I talk about is that SAP patch management is not like Windows patching. Why do I say that? Because there is a lot of analysis involved in patching SAP systems. It's not just one team. If a CVSS 10 comes out, you cannot simply implement it right away. You need to involve different teams.

Raghu Boddu: Yeah.

Nipun Mahajan: Your ABAP, authorizations, and Basis teams. And if the patch changes functionality, you will also have to test it with the end users. That's where the whole SAP patching process is very different from what other systems are used to, and not everyone is aware of that. Building the SAP patch management policy was the most difficult part for me, Raghu, because getting everyone aligned on implementing a patch within a defined time is very difficult. I think it's the same for RISE systems as well. Look at last week's CVSS 10. How long will SAP take to patch the impacted Web Dispatchers? Those policies should be defined.

And once you have your patch management policies defined, 

• the seventh step is to loop back. You check what you did previously and whether you missed something. It's like doing the assessment again based on how the threat landscape has changed. It's a continuous loop of understanding what has changed and what is currently being implemented.

Raghu Boddu: Yes. Everyone agrees on patching discipline. Everyone wants to patch their systems, but nobody manages it or owns it. Let's assume patching genuinely isn't happening. What controls are actually needed, and how should organizations handle this?

Nipun Mahajan: If patching is not happening, there are other controls you should have. First is monitoring. At the application level, you should monitor what's happening, and even at the OS level, you should have the right tools to make sure it's not being impacted. The other thing I would do is VLAN segmentation, because development systems are often very vulnerable, and attackers will try lateral movement from a less secure system to a more secure one.

You should also have cyber insurance. And another important point about cyber insurance is that insurance companies are now validating whether you did your due diligence on the hacked system. If you didn't patch anything, then given the number of breaches happening, there is a good chance your insurance claim might be rejected.

The last thing on my radar is to have a backup in the form of tapes.

Raghu Boddu: The old is always gold.

Nipun Mahajan: Exactly. Put it in a safe. That's what I'd take care of.

Raghu Boddu: Nipun, I also read about your ASUG session, which was titled around not waiting until it is too late. I want to know more about it. What are the honest first 90 days of standing up an SAP cybersecurity program in an organization that has none to date?

Nipun Mahajan: Great point. I would say those are the most difficult days. A lot of people say this can easily be done in 90 days. I took my time implementing the right controls. One thing that helps you, Raghu, is the support of your CISO. If you have backing from the CISO, vulnerabilities in crown jewel systems can be reported to your board. At that point, board members have visibility that the systems are at risk and the company's reputation is at stake. With the CISO's backing, you will not face as many challenges convincing others to implement the right controls. Otherwise, if you are a regular SAP person and you ask them to implement, let's say, SM19 logs, the very first thing they will say is, "We don't have enough space for it."

Raghu Boddu: Read Access Logging. Correct.

Nipun Mahajan: Really? So backing from senior management is crucial in the first 90 days. Then you get to know what policies exist and start reviewing them. That's how I would approach it.

Raghu Boddu: I agree. Let me put this to you. Suppose you meet a CISO who doesn't have a cybersecurity program in place, and you have about 20 minutes to make them understand and prove that they really need one. How do you handle that?

Nipun Mahajan: Sure. I would start by asking whether they consider their SAP system a crown jewel. If it is a crown jewel, how well is it protected? And if the SAP system is unavailable for a day, will the company survive? Those would be my three points for that person. I don't even need 20 minutes. I just need these three points.

Raghu Boddu: Excellent. Good. I think we've covered most of it, but in the last 10 to 15 minutes, I want to concentrate on some key things happening today and the gaps I see. I need crisp answers for this next set of questions, Nipun. Who should own cybersecurity? Is it Basis? SAP Security? The CISO of the organization? Or is it a joint function?

Nipun Mahajan: It should be the CISO of the organization.

Raghu Boddu: OK, so you don't think other teams should be part of securing the system?

Nipun Mahajan: It should be run by the CISO, and it should be owned by the CISO.

Raghu Boddu: Owned by the CISO. Got it. I agree. Now, everyone is talking about zero trust. It's a constant term we use, even in SAP. What do you want to tell our audience about zero trust?

Nipun Mahajan: Everyone is trying to implement it. One of the things I have done is multi-factor authentication for critical transactions in SAP. I think that helps a lot. Even in case of a breach, you should be able to survive to a certain extent.

Raghu Boddu: Protect it. Yeah. So do you think multi-factor authentication is still adding value?

Nipun Mahajan: I think so. It makes a lot of difference, and I'm not just talking from an SAP perspective, but from an overall SOC perspective. I see a lot of alerts coming from hostile countries, so even if the password is compromised, MFA is definitely a good control. Yes, MFA has its own concerns, but new controls like YubiKey are coming up.

Raghu Boddu: Yeah, overall.

Nipun Mahajan: This is very much required.

Raghu Boddu: OK. Interfaces and integrations are two areas where a lot of risk lives. What is the one statement you want to give enterprises on these two areas?

Nipun Mahajan: You might be connecting to a bank through an integration. If you don't protect it, you might go bankrupt as well.

Raghu Boddu: So an inventory is always required. They have to maintain a record of the integrations and interfaces they have, and ensure they are reviewed from time to time. Correct?

Nipun Mahajan: Exactly. That is true.

Raghu Boddu: OK. Custom ABAP code is a legacy asset for many enterprises. How do you see it?

Nipun Mahajan: I would say rate what you think is a priority for you, and remediate that.

Raghu Boddu: OK. Do you see AI as an opportunity, or as creating chaos? You mentioned that many bug bounty hunters are using AI to identify vulnerabilities today. With that, do you see this as an opportunity to patch and protect systems better, or do you think it is creating a lot of chaos?

Nipun Mahajan: I think, Raghu, we will all have to speed up to AI. That's for sure. We have to take it as an opportunity. Yes, there will be a lot of chaos, as with any migration. Once we are stable, we should have the right controls for AI products and also define governance for them. So I take it as an opportunity.

Raghu Boddu: OK. Now some rapid-fire questions. These can be one-word answers. What is the one SAP transaction code you have typed the most in your life?

Nipun Mahajan: I'm no longer an operational guy, so I would say SUIM. I don't go into SU01 much, but SUIM is something I use a lot.

Raghu Boddu: Ha ha. OK. Which do you prefer: a firefighter ID, or access with the SAP_ALL profile assigned?

Nipun Mahajan: Firefighter, any day.

Raghu Boddu: OK. Which is worse: a system with no security notes applied since 2019, or one where notes are applied, but new patches were brought in without proper testing?

Nipun Mahajan: I think the 2019 system. With the untested patches, yes, you might have some downtime, and that's fine. But if you cannot even get your system back up, that is more of a concern for me.

Raghu Boddu: OK. Complete this sentence for me, Nipun: You know an SAP landscape is in trouble when you see...

Nipun Mahajan: When I see the system down. That's trouble for me.

Raghu Boddu: OK. In this podcast, I usually ask guests to name one SAP security myth they would like to retire. So I'm asking you the same question.

Nipun Mahajan: That's a really interesting question. I think one of the myths is that Basis can do everything. We should get rid of that.

Raghu Boddu: Agreed. Good. One last closing statement. I want you to give your recommendation to SAP security experts. I'm sure you follow SAP Security Expert and the value we are adding to the community. What recommendation would you like to give our SAP Security Expert members?

Nipun Mahajan: Sure. Raghu, I think it's important that everyone volunteers and networks with the right people. A lot of my learning has come from networking with the right individuals. I would ask people to join information security groups like ISACA, ISC2, or OWASP, just to understand what is currently happening. Don't restrict yourself to your employer. There is an ocean of knowledge out there; get out there and learn. Interestingly, when I was in India, I started looking at ISACA. I even failed my CISM exam in 2013. Now I am the president of the ISACA Denver chapter, and I also hold a CISM. So don't let failure stop you from progressing. That's my two cents.

Raghu Boddu: Great recommendation for the community, Nipun. Thank you for your time and for being part of this episode for our SAP Security Expert members. Thank you very much.

Nipun Mahajan: The pleasure is mine, Raghu. Thank you so much.