Why not activate S_RFCACL in SAP_ALL? (no, really!)

[former_member279014]

This should be a fun Q&A ... but I'm not (only) doing it for the fun ...

First, I expect this will offend some sensibilities and stir some emotions (much like when someone says "I use RAID as my backup"). That can easily lead to automatic or knee-jerk answers that I would like to avoid. Let me note that I've been doing SAP Security/Authorizations for 17 years, so, while I don't know everything / there is a lot I still don't know (the trusted RFC area being one of them), there's no need to answer as if I am a newbie who has zero idea of what he's doing.

[I hope that noting such will save a lot of wasted time & text that may try to teach me the basics.]

Second, I am aware of the following (specific to this question):

• the intended function and controls of S_RFCACL: to allow a user to use a trusted RFC into the assigned client (I have both reading and practical-use knowledge in this area, e.g., we've implemented some Fiori here)
• the default restrictions on S_RFCACL (e.g., how hard it is to get a star into some of those fields; the default exclusion from SAP_ALL, obviously)
• that there exists a flag that allows S_RFCACL to be incorporated into SAP_ALL with each regeneration
• that "everyone" says to never activate that flag

Sample Use Case:

• In a non-Prod system, someone needs some quick "emergency" access to get something done that is unusual for them and there is (supposedly) no time to get the authorizations "right," so it is authorized by management and considered acceptable to grant SAP_ALL to that user's ID for a short period of time (and possibly even "open the system", but that's a Basis' task). [I expect this is fairly common and familiar to a lot of us.]

Here's what I don't know that I really want to know (i.e., "The Question"):

• If I'm going to give SAP_ALL to a user, what actual further damage can they do with S_RFCACL being a part of said SAP_ALL?

PLEASE NOTE: I am looking for very practical answers to this question. I am not at all interested in concepts and theories and "best practices" as an answer. Answers that essentially boil down to, "you shouldn't because you shouldn't" will be dismissed. As will scenarios that have little chance of actually occurring. "Everyone" may say "don't do it"; I want to know exactly why, as it pertains to the above Use Case and question. And I suspect there is such a "why" out there. Best practices became so for a reason, and it is the practical sources of said practices that I am seeking. Also, answers that suggest other solutions that skirt around the issue, such as "use a firefighter," will be similarly dismissed. I don't want a "solution" per se, only an answer to this narrow scope of questioning.

Background Architecture:

• Besides SolMan, Trusted RFCs are only created between systems at the same level in the landscape.
  • In other words, QA systems only have trusted RFCs to/from other QA systems. Not Dev or Sandbox, and certainly not Prod.
• Even so, the direction of the non-SolMan trusted RFCs (if that matters with trusted), are from non-ECC system into ECC systems. Again, if it matters, trusted RFCs are not overtly created with the intent for ECC to get into any other type of system.
• If a user has an ID in ECC, then he/she has that same ID in every other system at that level in the landscape. At minimum, every user exists in ECC QA, BW QA, and SRM QA, guaranteed.
• Logins occur via SSO. Backend passwords could be setup and used, but are almost never "needed."

The best I can figure (to answer "The Question"), the only thing a user in ECC QA can do with SAP_ALL+S_RFCACL vs. SAP_ALL-S_RFCACL is:

• they could access ECC QA from BW QA or SRM QA, over the trusted RFCs that have to already exist, and do no more than they can do by logging into ECC QA directly ... which they can do .... and my reaction to that is: "big whoop!" (slang for "so what?!" / "who cares?")
• I must be missing something. What is it?

The Benefit (i.e., why I want to do it):

• When I grant SAP_ALL, I want it to be SAP_ALL! When I need it fast in a given client, I don't want to be concerned with having a second role/profile ready there to give "the rest" of SAP_ALL. I don't want myself or my team to forget to add the "extra" thing in a critical situation, and then have it be called, leading to needless troubleshooting and upsetting the customer only to figure out it is this ... especially when the alternative to make this simple & easy is a "big whoop" risk-wise.

So, unless someone knowledgable in this area can articulate a real-world, practical example of a real risk associated with adding S_RFCACL to SAP_ALL under this "Architecture," I aim to misbehave and set that flag to allow S_RFCACL to be generated into SAP_ALL. [Please somebody stop me! ... but only with a good, solid argument.]

Thanks, friends and fellow security peers!

Steve :^{D

[Colleen]

Hi Steve

Thanks for this discussion as I've had the same reaction too (hands up admitted that I updating PRGN_CUST to allow it to be added before learning the "you should never add it" mantra)

The other part that confuses me is if it is trusted then it's still your account. So even if I do have the access to jump systems I still need authorisations against my account to execute items in the target system (unless dodgy code is the risk here?)

The PFCG build part that gets me is the field requires to you to specify system id instead of a system alias. Therefore, if I transport my roles I have to allow add the dev, QA and production SIDs to my role and transport so I can use the role throughout the landscape (i.e. I need to test my production end user role in QA so I need the QA system to be in the role).

I take the approach of not granting SAP_ALL at all in end user clients. I build non production support roles and still push that system users get appropriate roles. It takes time to do and quite frustrating on a greenfield where you have to argue this. So in this case, if people aren't being granted SAP_ALL permanently what is the risk of the authorisation being in the role. Basis teams end up building a ZS_RFCACL role and assign it to themselves with the auth having astersisk.

Could part of the answer be just having this as an extra layer of security. By not adding it you have to be conscious in granting the permission so if someone does configure a trusted RFC connection it won't work. Also, if there are jobs running out of 000, 001, etc clients they won't get the trust value? Users in these clients typically do have SAP_ALL.

Regards

Colleen

[Former Member]

Colleen Hebbert wrote:

The other part that confuses me is if it is trusted then it's still your account. So even if I do have the access to jump systems I still need authorisations against my account to execute items in the target system (unless dodgy code is the risk here?)

If you have not activated the "equals user" field of the object OR you have not restricted the "RFC names" field for the users when activated to 'Yes", then you can, from any client of the remote system with a trusted system entry in the target, logon as any user you want to as long as you can find their name as having SAP_ALL, as long as you in the source system have either access to SM59 OR have access to execute function modules (see SAP note 587410).

Game over and I cannot see any implementable way of preventing that from happening, except for only granting trust at all to systems within the same user administration AND being very restrictive with S_RFCACL for all users in the system, particularly non-Dialog SAP_ALL users who will not notice or complain if their user IDs are used and you will probably never notice the misuse either.

It does not belong in SAP_ALL and that is a good thing.

Cheers,

Julius

[Former Member]

I quite like the current construct where you have to show intention to add S_RFCACL to SAP_ALL and it does not "just happen" like magic. The reasons I am aware of are:

• The object is not a control of authorization. It controls authentication. So it belongs to the login family of security controls and not "all authorizations for the system".

• It is high up on the list of misuse candidates, and there is not effective way to prevent a person from discovering which users have SAP_ALL as a myriad of search helps in SAP provide the option to F4 users by Profile name. Searching for users by objects and authorization values is in contrast protected by SUIM access or table access. This is particularly true for non-Dialog users which can then easily be entered into external RFC connections without requiring knowledge of the target system password anymore.

• In the semi-likely event of the SAP system loosing cabin pressure due to S_RFCACL access granted to passengers, an oxygen mask will drop from the ceiling above the pilot's seat only...  :-). SAP themselves have not included this object by default into any roles outside of the Z and Y namespace, it is not included into SAP_ALL automatically, in higher releases you cannot via SU24 nor the "distribute full value to open fields" button in PFCG provide any * access to some of the fields. You definitely granted this access yourself and it is optional to have used trusted RFC anyway.

So in conclusion your idea is a way to make your life even easier for SAP_ALL users, but I don't see that ever being implemented or changed now. On the contrary, the recent changes in the area show that SAP is becoming more restrictive and selective about defaults for security relevant features in the system which are optional to activate. That is a much safer approach than turning everything on by default and expecting diligence and audits to bend it back again - we know how that works from the past and don't want to go back there.

Cheers,

Julius

[former_member279014]

Julius, I was hoping you would be one of the responders to this. As much as I am a fan of some of your posts here, I will risk being difficult about this in order to get to the answers I am seeking. I expect you will not take this as a lack of open mind for other ideas (and I pretty much know you will not take it personally).

Also, I’m going to break this up into little pieces-parts (3).

Julius von dem Bussche wrote:

I quite like the current construct where you have to show intention to add S_RFCACL to SAP_ALL and it does not "just happen" like magic. The reasons I am aware of are:


The object is not a control of authorization. It controls authentication. So it belongs to the login family of security controls and not "all authorizations for the system".

OK, interesting. I don’t often have situations where I have to mentally separate those two concepts to take an action, but you are absolutely right. I’ll think on that. But for this question that seems sort of academic. I see that S_RFCACL controls authentication and, since that is acceptable to me in the given use case, I don’t see this (by itself) as a reason not to use it for this.

BTW, please note I am not expecting anyone to give me a blueprint on how to hack into a system where an ID has SAP_ALL+S_RFCACL. (How secure would that be? ) What I am asking for is between here and there. Such as, “it would take someone who can program ABAP (and/or other XYZ skill sets), who also has auths to transaction ABC (etc.) in a system that has LMNOP setup in the architecture, and with that these aspects of S_RFCACL would authenticate them, and here’s basically the damage that person could do (which they could not do otherwise) if they had all that.” I also think that "LMNOP" is underused in examples.

Julius von dem Bussche wrote:


It is high up on the list of misuse candidates, and there is not effective way to prevent a person from discovering which users have SAP_ALL as a myriad of search helps in SAP provide the option to F4 users by Profile name. Searching for users by objects and authorization values is in contrast protected by SUIM access or table access. This is particularly true for non-Dialog users which can then easily be entered into external RFC connections without requiring knowledge of the target system password anymore.

The salient point I see here is that people in that system can see which users have SAP_ALL. Agreed/point taken. However, the next step is “why should I be concerned with such a thing in this use case?”

I think you attempt to answer that question with your comment about “can then easily be entered into external RFC connections.”

However, I do not yet see how this could happen. Are you speaking of someone who has access to create RFC Destinations? If so, only Basis has SM59 and S_ADMI_FCD to NADM … done. Otherwise, how easy (or even plausible) is it really for someone who has their normal, non-SAP_ALL QA access in a non-ECC system to get to a place where they can control the user launching across to the target ECC QA system. I don’t think that’s a hack, so I don’t mind asking, do you have a practical example of how one could do that? Ultimately what I hope to find is what auths they need on the non-ECC side in order to do that.

[former_member279014]

Julius von dem Bussche wrote:


In the semi-likely event of the SAP system loosing cabin pressure due to S_RFCACL access granted to passengers, an oxygen mask will drop from the ceiling above the pilot's seat only...  :-). SAP themselves have not included this object by default into any roles outside of the Z and Y namespace, it is not included into SAP_ALL automatically, in higher releases you cannot via SU24 nor the "distribute full value to open fields" button in PFCG provide any * access to some of the fields. You definitely granted this access yourself and it is optional to have used trusted RFC anyway.

Funny, but I’m sorry -- this bullet amounts to, “SAP does it, therefore we should, too.”

This is the same SAP that, in a semi-recent support pack on my systems, changed how they applied roles to transports (i.e., now only truly adding the role data upon release) apparently only to account for those (few? inexperienced?) SAP Security admins who could not remember to add/re-add a role to a transport before releasing it. In doing so, they have made it significantly harder for us to distribute roles within our multi-client development systems before we release to QA (i.e., no more SCC1). This is the lead we should follow?

This is the same SAP where I have no hair left when dealing with most of my incidents because the processors don’t read or don’t understand the situation presented, often even at the higher levels, even when written painstakingly clearly.

And this is the same SAP that provides paltry security training which essentially forces one to take a class in an entire product in order to learn any security about it in a classroom setting. So beyond ADM940, HR940, and BW365, we are left to on-the-job crash-course training for just about every other product.

I suspect you don’t do everything Microsoft tells you to do, either.

No, if there is anything I have observed about SAP over the years, it is that shockingly few in the organization really know (and/or care) about the authorizations/security aspect of their product. I don’t give them much credit just because they are “SAP” – I listen to what the individuals have to say before I can respect their opinion.

I understand that building/maintaining SAP is a monumental task, and they have given me jobs for many years, but what they do is deliver a mostly generic product and tell us what all the levers and dials do, and it is up to us (the “royal” us) to understand what we are given and decide how to change and customize it for our own environments. Their opinion on that does not rule. They include a flag that allows what I am suggesting. So, all points that boil down only to “SAP does it” or “said so” or “made it hard” for unspecified reasons are not impactful in this discussion. As I said, I am looking more toward practical examples.

Julius von dem Bussche wrote:

That is a much safer approach than turning everything on by default and expecting diligence and audits to bend it back again - we know how that works from the past and don't want to go back there.

Wait, just remember the use case here. Don’t make it sound like I am giving SAP_ALL to everyone permanently in Prod. This is about temporary access in a non-Prod system (while admitting many non-Dialog IDs have SAP_ALL essentially permanently, but still not knowing exactly how that matters). In our case, only our Prod systems even get audited, so that’s a moot point for me.

We’re not talking about going back to SU02 and manual profiles here, but you make the addition, and working around of, one object sound a lot like that. And I still don’t know exactly why. This is the kind of overblowing of smoke I would like to avoid. I don’t want the 100% safest approach; I want “safe enough” (as determined by "us"). So I want to know why in order to determine what’s safe enough for our environment.

[former_member279014]

But here is your best response so far (and it wasn’t even to me … wahhhhh). Though it doesn’t intentionally address my use case, because in my case you are jumping systems into an ID you know has SAP_ALL on purpose (otherwise, you don’t have S_RFCACL with stars on your normal account), but the answer does shed some important light.

Julius von dem Bussche wrote:

Colleen Hebbert wrote:
The other part that confuses me is if it is trusted then it's still your account. So even if I do have the access to jump systems I still need authorisations against my account to execute items in the target system (unless dodgy code is the risk here?)

If you have not activated the "equals user" field of the object OR you have not restricted the "RFC names" field for the users when activated to 'Yes", then you can, from any client of the remote system with a trusted system entry in the target, logon as any user you want to as long as you can find their name as having SAP_ALL, as long as you in the source system have either access to SM59 OR have access to execute function modules (see SAP note 587410).

Game over and I cannot see any implementable way of preventing that from happening, except for only granting trust at all to systems within the same user administration AND being very restrictive with S_RFCACL for all users in the system, particularly non-Dialog SAP_ALL users who will not notice or complain if their user IDs are used and you will probably never notice the misuse either.

Very, very good points there. This is getting at what I’m looking for. I agree about not noticing the non-Dialog users. I’m not yet sure this is “game over” though.

So what you are saying is (skipping over SM59, previously/easily addressed): If someone can execute a function module from the source system (so, SE37 with S_DEVELOP 16 to type FUGR or the like) as part of their normal authorizations, someone I didn’t intend to have SAP_ALL in either system, they could use said access to call that same function module (if it exists) over on the target system as any ID they can determine has SAP_ALL on it. Is that what you are saying?

Now we have a real discussion here. So my follow-ups are:

• Still, can they really control which ID they are using to RFC into the trusted target system if their ID exists in both systems? (repeat of question above)
• If there is a non-trusted RFC destination from that same source to that same target using a static ID that has SAP_ALL, is that not exactly the same thing? (Yeah, I need to look into that. ) Except that they can’t control the ID in this case, of course …
  • … or can they switch the ID if the non-trusting RFC uses “current user”?

• This all is still governed by having trust between the 2 systems, correct? I have no fear of someone jumping from SRM QA to ECC Prod, or even ECC Dev to ECC QA, if there are no trusted RFCs between them. Of course! (Right?) This is what you mean by “except for only granting trust at all to systems within the same user administration”? That was part of my Background Architecture.

• Finally, back in the day, I'd think this would not apply to “Background” IDs, which we don’t have anymore. I assume Dialog, Service, Communications are all in play here today, but do we have the luxury of not worrying about System IDs in this scenario? (I cringingly expect not.)

Thanks for a rousing discussion so far.

[Former Member]

Steve Quinn wrote:

... admitting many non-Dialog IDs have SAP_ALL essentially permanently, but still not knowing exactly how that matters). In our case, only our Prod systems even get audited, so that’s a moot point for me.

You should be more careful providing such information in public chat forums when your employer's details are in your business card and their systems contain patient data.

Cheers,

Julius

[Former Member]

Steve Quinn wrote:


Finally, back in the day, I'd think this would not apply to “Background” IDs, which we don’t have anymore. I assume Dialog, Service, Communications are all in play here today, but do we have the luxury of not worrying about System IDs in this scenario? (I cringingly expect not.)

Are state hospitals in the US not expected to have security training, pen-tests, adhere to some sort of minimum security requirements which are reasonably up-to-date?

Trusted RFC does not discriminate against any user type, except Reference users which cannot logon at all and DDIC and SAP* (guess why? -> known user IDs with full authorizations for the system by default).

I would suggest ADM960 for you.

Cheers,

Julius

[former_member279014]

Be careful about assuming too much, Julius. You have made an incorrect inference that tells me you have not been inside this organization.

The systems of which I speak contain no patient data (and I won't be mentioning what we do use for patient data). My comments also do not speak to the level of auditing that takes place outside the systems. And a discussion of all of the layers of security to even get this far is also out of scope here.

And if you are referring to the non-Dialog SAP_ALL IDs, remember that the given use case is non-Prod ... and, really, who does not have that situation below Prod? I'm just admitting we are as imperfect as nearly everyone else.

So, I see where you're coming from and appreciate you looking out for me and all, but I think we're good here. I also hope this will not be your final response on this thread.

[Former Member]

Patient data, credit card numbers, personal data of all sorts, payment program, RFCs and file interfaces to systems which do have that data... I am sure you have something of interest in your SAP system or systems it is connected to via RFC...  🙂

A downfall of S_RFCACL is that it has the system ID as a field. How do you build a role and unit test it in DEV, functionally test it in QAS and use it in PROD if your non-Dialog users have SAP_ALL in non-Prod systems but something restricted in PROD?

Given the information you have provided I would make a safe bet that that those users have SAP_ALL or a copy of it with S_RFCACL * in PROD as well.

I know of some administrators who even see the feature in this -> a user ABC tells them that Tcode XYX does not work. So they put user ABC into a trusted RFC connection in SOLMAN or any other under their control and just logon and start XYZ to take a look for themselves. An RFC call and also a batch job logon (also no password needed for the step user!) is not classed as a multiple login and knowledge of the initial or productive password is not required.

Your non-Dialog users are a bigger risk though than the dialog users. They can also logon. They also execute business functions. They often have SAP_ALL. They are just not capable of attaching the SAPGui to the session in the case of SYSTEM users, until they change themselves via RFC to SERVICE users. COMMUNICATION users are obsolete - do not use them anymore.

You should use SYSTEM users for RFC, jobs and also webservices. In a similar way to trusted RFC for DIAG and RFC clients, SYSTEM users cannot issue Logon Tickets in trust chains for http clients.

-> Not including S_RFCACL in SAP_ALL is intentional and should stay, as it protects people from themselves. This thread is a nice proof of that, so that should answer your own question...  🙂

Cheers,

Julius

[Former Member]

ps: As such changes to default behaviour (particularly if they are heading in the direction of less secure) are likely to be classed as a development request, perhaps a better bet for you is to launch your thoughts via ASUG?

Opening an OSS note will with little doubt lead you to SAP Note # 11.

Another option is the SCN Security Functionality Wishlist -> Security Functionality Wishlist-Topics - Security and Identity Management - SCN Wiki  - it has a good hit rate if the idea is well thought out, which in this case I have my doubts about.

You are welcome to refer to this discussion in all 3 which promises to continue to be lively, up to you. But I have some doubts that in this case community motivation will have much impact, even with the "We are customer" slogan from one auditor and references to other frustrations you have added... 🙂 (I did not comment on them as they are irrelevant to this discussion - but feel free to open threads about them as well - also interesting stuff and backgrounds to it, but I do also understand your frustrations with some of them combined with old habits - I am well versed in that, but that is just me).

Cheers,

Julius

[former_member279014]

So, I take it you will not be responding to the 3.5 bullet points above that, which were listed in relative order of importance (and you only picked the last/least one)?

BTW, given the attitude, 3rd bullet point doesn't really need an answer. It's just re-stating the obvious and keeping the scope narrow, which you seem to insist on expanding.

[former_member279014]

Julius von dem Bussche wrote:

ps: As such changes to default behaviour (particularly if they are heading in the direction of less secure) are likely to be classed as a development request, perhaps a better bet for you is to launch your thoughts via ASUG?

Opening an OSS note will with little doubt lead you to SAP Note # 11.

Another option is the SCN Security Functionality Wishlist -> Security Functionality Wishlist-Topics - Security and Identity Management - SCN Wiki  - it has a good hit rate if the idea is well thought out, which in this case I have my doubts about.

You are welcome to refer to this discussion in all 3 which promises to continue to be lively, up to you. But I have some doubts that in this case community motivation will have much impact, even with the "We are customer" slogan from one auditor and references to other frustrations you have added... 🙂 (I did not comment on them as they are irrelevant to this discussion - but feel free to open threads about them as well - also interesting stuff and backgrounds to it, but I do also understand your frustrations with some of them combined with old habits - I am well versed in that, but that is just me).

Cheers,
Julius

Well, now it's just clear that you have no idea what I'm asking anymore. You seem to be having your own conversation now.

This is a flag, among many others, which can be set one way or another without a development request. Or did they not teach you that in your SAP classes?

The only question on the table is, what is the *real* risk of setting that flag? If it was never to be used, it wouldn't be there.

So, anyone else want to actually address the question/discussion being had here? I welcome all comers (if you keep it on topic).

[Former Member]

Which bullet was 3.5? They were not numbered. I spotted several errors and commented on the biggest one.

I read the entire answer and you need to understand the impact of this object in a role with specific values or SAP_ALL (for all users for whom the authorization requirements are unknown or full authorization for the local system as themselves is OK - which is not the case with S_RFCACL).

Asking questions which excludes a lot of details and assumptions about the scope of your question and ignoring consequences, has generally not found conclusive answers here. I cannot remember any.

Yes, you can limit your question and doubts about it's back-tracking scope can be dismissed. From the information which you have provided and information which can be assumed and extracted from your systems (particularly if SAP changes the default behaviour! - which is your question) you are easily toasted.

What are you trying to achieve? Are you in a bunker in a deserted bird sanctuary in Oregon? 🙂 (just joking)

Lets get back to the topic and the ball is in your court -> try it in a sandbox, or better said FROM a sandbox. Think about it and consider what this change in default behaviour of SAP_ALL would mean for customer SAP systems. In your SAP system you can change the behaviour as Colleen mentioned in PRGN_CUST, but that is your decision and your problem for the consequences. You are not prevented from adding S_RFCACL to SAP_ALL in your system - it is just not default behaviour of the system and that is a good thing.

Cheers,

Julius

[Former Member]

Steve Quinn wrote:

there's no need to answer as if I am a newbie who has zero idea of what he's doing.

Is it possible that you are already an ASUG member and they sent you here?

The people I have contact to in ASUG are well aware of Trusted RFC and also requested many of these features which you are now encountering with EHP7.

So I am a bit confused now between the regional : functional paradigm?

Not having S_RFCACL in SAP_ALL is however correct for sure. You can use or create your own Z_RFCACL role (see above...) and assign it to all users. You can also give everyone SAP_ALL if you want to.

It is your responsibility if you use it!

Cheers,

Julius

[Former Member]

That is also fine for me, and as mentioned you are best advised to contact ASUG.

Folks can, who understand Trusted RFC, read this thread and make their own conclusions. Those who don't, can rant and assign S_RFCACL to all users and particularly non-Dialog users... your problem.

But then don't complain afterwards that you were not warned or the defaults were not correct and you were too busy with some other changes to default things...!

Cheers,

Julius

[Former Member]

Steve Quinn wrote:

So, I take it you will not be responding to the 3.5 bullet points above that, which were listed in relative order of importance (and you only picked the last/least one)?

Steve,

IMHO that was pretty rude and not really consistent with SCN's Rules of Engagement. Julius, and in fact any of us here, does not owe you a(nother) response. SCN is not free consulting on demand. Members are free to post their questions, and members including Moderators respond as they are able. Julius has already given you quite a bit of time in well-reasoned responses, and I happen to agree with them. If you want to change the way SAP delivers SAP_ALL, perhaps ASUG's Security SIG  leadership will entertain creating a survey aimed at launching an Influence Council on it, if there is adequate customer interest. I personally see the value in SAP's approach to not including this authorization in SAP_ALL, for the reasons already outlined by Julius,  so if they put out a survey on the question, I would vote no.

Regards,

Gretchen

[Former Member]

Well, SCN does have something similar to voting in surveys. It is the "Likes" on each post.

Going by that, it is 1 like in favour and 12 likes against and 1 which I interpret to be sitting on the fence.

But anyway... my hope is that Steve will have tested this by now and been earthed a bit since yesterday's spectacular rant..  🙂

Cheers,

Julius

[former_member279014]

Hi Gretchen,

I really don't want to have a back & forth about this, but I also can't have you unjustifyably publicly framing me as someone who is rude, out of line, demanding free consulting, etc., especially based in error. And you, of anyone else here, know me better than that. Or at least I thought so.

I think of you as a fan of debates, Gretchen, so I think you will agree that I deserve a rebuttal to your comments here, so I will offer a polite one to clear my name and be done with it.

Gretchen Lindquist wrote:

Steve Quinn wrote:

So, I take it you will not be responding to the 3.5 bullet points above that, which were listed in relative order of importance (and you only picked the last/least one)?

Steve,
IMHO that was pretty rude and not really consistent with SCN's Rules of Engagement.

I politely disagree. I think that you assume too much intent here.

I ended my post with 4 bullet points + one inset (which I refer to as 4.5 bullet points; not numbered, just counting them). I think a fair, understanding read of them is clearly that the first 2 bullets were real, important questions, absolutely critical to furthering the discussion, and that the second 2 bullets were only confirmatory (basically throw-aways, but wanted to double-confirm and round out the whole picture, anyway).

Fact: Only the last one was responded to. Even if I give you that the importance of each bullet was not clear, I was asking if that would be the end of the answers on those bullets, or if there was an intention to come back around and address the other bullets. In my mind, the first 2 bullets were/are critical to move forward. That was not a demand nor an expectation; only a question, and a fair one, I think. If Julius did not intend to answer, that's fine, he didn't have to and anyone else could ... or not. I never once insisted that Julius must answer my question(s). Whether or not I phrased that question rudely, I think that accusation is arguable and up to broad interpretation. Please understand.

However, IMHO, the following were blatantly rude (esp. the first one), given what was in this thread at that point (e.g., 17-years experience, demonstration of knowledge, etc.).

Julius von dem Bussche wrote:

Are state hospitals in the US not expected to have security training, pen-tests, adhere to some sort of minimum security requirements which are reasonably up-to-date?
...

I would suggest ADM960 for you.

...

... if the idea is well thought out, which in this case I have my doubts about.

The first one especially was a direct attack on my knowledge, training, experience, and ability to do my job, apparently based only on a merely confirmatory throw-away question that I basically already knew the answer to. And the last one is based on something I never suggested, was created entirely by Julius, and is now wrongly believed by others.

But I did not complain about that overt rudeness. I have seen Julius treat people as such in other threads. I think there is overwhelming evidence here (that I need not cite) that I treated Julius in a very friendly and fun manner, even being a fan (while also challenging his ideas), at least up until that point. But I will admit that these (his) comments did put quite a chill on the conversation going forward. I just wanted to brush aside his rude comments and get to the back to the heart of the question, i.e., the other bullets. Perhaps that "brushing aside" is what you were reading into my comments as rude (which was still just asking a question).

Gretchen Lindquist wrote:

Julius, and in fact any of us here, does not owe you a(nother) response. SCN is not free consulting on demand. Members are free to post their questions, and members including Moderators respond as they are able.

I am in complete agreement with you with this. I never said that Julius or anyone owed me anything. (And I don't know what this business is about moderators.) As I said, I was asking if he was going to answer those bullets or not. That's all, and I think when someone skips over critical bullets, that's a fair question for the sake of keeping the discussion moving. He could have responded "no" sometime next month, or never, for all I care or expect, and that would have been fine.

I also believe someone else out here other than Julius has capacity to answer these questions and can jump in if/as they choose. The point, from the beginning, was to have a challenging, thought-provoking technical discussion on this topic with whomever wants to.

Gretchen Lindquist wrote:

Julius has already given you quite a bit of time in well-reasoned responses ...

Well, this is the one thing I say you have in error. Lots of posts have passed since then; don't incorporate them into that moment. Remember, at the time I made my post you questioned here, all that Julius provided was 2 responses (one each to me and Colleen), and when I picked those apart and asked for more more focused/specific info, he only provided challenges to the data in my systems (which he doesn't know and is irrelevant and out of scope), his response only to my last bullet (which I took to be rude to boot), and a silly offer for me to take his idea that I wanted to change SAP standard and post that idea to three other places. So, while I can give you that took him some time, I can't fairly call them all "well-reasoned" or agree with your unspoken implication here that the "well was dry" and there was nowhere else practical to go with this.

Gretchen Lindquist wrote:

If you want to change the way SAP delivers SAP_ALL ...

I don't. I never did. Julius made that up and ran with it. I challenge anyone to find evidence of that in any of my posts in this thread (but I wouldn't recommend anyone wasting one's time with that ... it's just not there).

So, Gretchen, I love ya, I really do. And I appreciate where you were coming from. But I had to set the record straight on me here. Sorry we had to do this publicly.

[former_member279014]

All readers (i.e., this is not directed at Julius, who has helped some here),

Folks are confused. And, clearly, I am now being misunderstood (even by those who should know me better than that), so I'd like to set the record straight now. And I’m truly very sorry that this became such a mess like this. So far, it seems that only Colleen totally clearly understood what I was asking for (before it got confusing). I ask that you give me another chance.

Note: “lots of text” <> “rant.” To me, “lots of text” means a mix of lots of info plus lots of couching to prevent further upsets, like the rest of this post). Yes, I put a lot of work into this, because I think it is an important question that never gets discussed in enough detail. I'm trying to get at that detail.

So, I’m trying a new branch / reboot / clean slate (but informed by what has gone before). And a progress summary below.

MOST IMPORTANTLY: THIS IS STRICTLY A TECHNICAL QUESTION. That’s it.
[And, because of that, I don’t see why I would cross-post this to ASUG or why that would be suggested, except if this has been confused as a development request to change standard SAP, which this is certainly not.]

And that question boils down to: If one were to use a flag that SAP provides, what could possibly happen and how?

That’s all this is about. Absolutely everything else in this thread so far is noise (because it got misinterpreted and out-of-hand); don’t let it throw you or consume you. Importantly, this is certainly not a vote, or even a suggestion, about whether SAP should change anything at all. If you read through, I have never once suggested the idea that SAP themselves should change the SAP_ALL/S_RFCACL relationship throughout this thread, but somehow readers seem to be thinking that. No, this is only about us understanding what SAP provides if we choose to use it.

And I think this is a fair question because I don’t believe there should be such a thing as a flag SAP provides that we should never, ever use. I think we should seek to understand it completely and make our own decisions.

Now, I am not going to assume I know your environments better than you do, nor will I tell you how to secure your systems – you know your environments best. I think the best approach is that we know as much as we can about what the *real* risks are (vs. imagined risks), how they work, and from there we can each decide if those risk are acceptable in a given situation and how to mitigate them. That is, and has always been, the intent of this thread. (Unfortunately, it wandered off into other places and my best efforts so far to keep it focused were not good / good enough.)

But, as noted by others, this is a topic for advanced users. If you are just starting out with SAP Security, I do not recommend you follow any particular prescriptions here until/unless you fully understand *all* of the associated risks. This may not be for the faint of heart.

As such, one has to come to grips with the concept of “acceptable risk” in order to get one’s head around this topic. As security folks, we have a tendency to want things as secure as we can make them. Security folks at all levels have trouble letting go of this. Anything that seems to make the system “less secure” (even when it is managed and doesn’t make it less secure in reality) is bad.

This, in my mind, is a lot of what can make our users “hate” us (I’ve heard that used against Security teams in the past). When we can’t let go of “100% secure” enough to come to the middle and secure a system only as much as it make sense to in a given situation, or to even understand each other about that long enough to have a technical discussion, then we come off as too strict and unreasonable.

So, disclaimers aside now, I am troubled by the fact that this particular topic generates such emotion about how it “should” be a certain way (i.e., the flag should always be left at default), yet no one can clearly and completely articulate exactly how someone could damage your system if you turned the flag on. As good security people, that should make us suspicious – why does it seem that we have an almost-religious belief about this flag being left as default, but we don’t know exactly why or what could really happen if we use it? Are we worried about risks that are not real? Maybe yes, maybe no. But if not real, we should not be worried.

As silly as it sounds, one of the main challenges here is with our use of the simple word “could.” As in, “someone could do this or that bad thing” … Is that “could” as in, they could really actually do those bad things with relative ease? Or “could” as in, it’s only in theory and we don’t know exactly how it’s even possible, but we think it just might be possible, maybe, so we say they “could.” That distinction matters to this discussion.

[continued in next post ...]

[former_member279014]

(just to break it up)

Here’s what we’ve been able to truly learn here on this topic so far …

If you were to set the flag in question so that SAP_ALL automatically incorporates object S_RFCACL with stars (or if you were to create a separate role containing S_RFCACL with stars and assign that to every single user who already has SAP_ALL, which is exactly the same thing but more work), in order for that to constitute a real security risk an attacker would have to:

• Have access to a system where there is a trusted RFC between the source and target systems
• Must have access to SM59 to control or change RFC destinations (unlikely)
  OR
• Must have access to SE37 to an RFC-enabled function module that could actually do “damage” (including obtaining private info) … that includes having sufficient S_DEVELOP access on the source system
• Must be able to RFC over to the target system but also somehow change the ID they are logging into said target system as in the process. This is the main sticking point that I don’t think has been addressed to the point of understanding it if is really possible or likely. As such, I don’t know if it is actually very easy to do this, or if one needs to be a “black-hat” ABAPer (my made-up term) in order to accomplish it. Knowing that would help to understand the real risk and how to mitigate it.

But, for the sake of argument, let’s say there is a moderately do-able way to change the ID with which you are trusted-RFCing into a target system.

Therefore, if you have an environment with sufficient perimeter security (it’s hard to get into your systems to begin with; that’s assumed), where only QA systems RFC-trust other QA systems (and no others), where only the Basis team has any access to SM59 (and they are trusted and have robust access to every system anyway), and only your developers have access to SE37, and if you trust your developers (or are pretty sure they are not “black hat” level ABAPers), and if you know the data in your system and are not worried about what said developers could do with it, then you may have a potential use case for setting that flag to incorporate S_RFCACL into SAP_ALL with an acceptable level of risk (only if you feel that risk is acceptable in your own environment).

So, unless I missed something, that is what I think we’ve learned from this so far. If there is more learning to be had here, anyone/everyone is welcome to offer their further knowledge and ideas about this technical question.

Message was edited by: Steve Quinn for spelling and clarity

[Former Member]

Are you trying to convince us that you don't have a SOLMAN which is connected to and from all systems?

Also no connections from this QAS-land of yours to the PROD systems and all your gateways are set to local only?

You can't just dismiss SOLMAN from the example because it does not suite your agenda...

The "flag" you want to change is also a client independent and workbench transported object. So changing it is going to go from DEV to QAS and then to PROD.

Your example or arguments here are riddled with "not so smart" ideas, many of which are covered in ADM960. It is correct to point this out for others who read this thread, as otherwise they might follow the advice you are trying to bully us into.

You can do that in your backyard but it does not work very well in public forums.

Cheers,

Julius

ps: have you now tried it with a foreign SAP_ALL user with S_RFCACL * access as well? Do you now believe me that you can logon with which ever user you want to from the remove system, you can even turn the authority-checks in SM59 off and create whatever RFCs you want to, then hop further and you can even do that as non-Dialog users. It is true. Try it.

[Former Member]

Steve you are not new to SAP security and know that all software companies prior to SOX, JSOX, etc, were not very restrictive on any system or batch account.  Although most including SAP documented required authorizations in Security Guides, these documents were stagnant and incomplete.  Each time functionality was added, the guide was out of date and the user was broken.  When this occurs many security architects do not understand how to perform root cause analysis and assign SAP_ALL to get around the missing authorizations.  Even SAP support would recommend this by mistake as a requirement.

With 1000's of these implementations implemented over a decade ago there had to be a better way to remove excessive access to S_RFC, S_TCODE, S_DEVELOP, etc.  In recent years SAP has made major steps to clean up the sins of the past.  ASUG, DSAG and others have pushed SAP to deliver software that does reduce risk from excessive RFC access, cross site scripting for web applications and even exploitation of an SAP system from the predefined RFC connections.

You have a risk of RFC hopping with RFC Destinations, log setting changes, escalation of privileges, impersonation, or even hopping through an entire landscape.  There are tools today which help you to identify function modules that are being used.  These can be assigned by name instead of by group greatly reducing risk.

SAP even has disclaimers like this now "We strongly recommend that you conservatively assign profiles SAP_ALL and SAP_NEW to users in your production system!  If you are not careful, these profiles can weaken the overall security concept in your production system."  Companies like Virtual Forge and Onapsis also provide services around the risks associated with S_RFC within your environment.

For some explanation on the S_RFCACL risk and where it no longer has unlimited authorizations automatically, check out the note  1416085 - PFCG: Authorization maintenance for object S_RFCACL.

[former_member279014]

Bullying, eh? Really, Julius? My words – twisted again. I am not giving advice. This is a technical forum for the sake of information.

But I have strong doubts you actually want answers to these questions because the record here indicates you are much more interested in character assassination, which I now have to make one final response to (because silence = consent). And then you can call me whatever you want after that.

Unfortunately, what this thread is riddled with is nasty, incorrect characterizations (as if you would know). Is it really necessary to completely discredit a fellow member of your field, to the point where no one will listen to him again, just because you find him on the “wrong” side of one argument (which was never originally intended to be an argument at all)? Rhetorical: no, that is not necessary.

But, fine. You “win” … a thread that was never supposed to be about winning or losing … only sharing and understanding. Since we apparently can’t have a pure technical discussion about this, you get to win.

The elephant in the room for me is why someone of your talents feels the need to descend to that level of interaction in order to make your case, instead of simply “winning” on the technical arguments alone, which you are obviously more than capable of doing. Yours is a tactic normally reserved for those who have no point or no leg to stand on … but you do have those. So I don’t get it. It's quite disappointing and perplexing, actually.

But I have no room in my life for that level of negativity, so I’ll simply wish you well and safe travels.

=====

P.S. If anyone now or in the future ever did want answers (out of curiosity?) …

- I never once suggested adding S_RFCACL to SAP_ALL in SolMan, which I believe would be necessary for anyone to be able to hop through there. Since my original post, that’s never been an intended use case. For that matter, doesn’t “hopping further” require S_RFCACL in the next target? This thread makes it sound like S_RFCACL in one system amounts to a blank check into all other systems. Unless granting S_RFCACL in ECC QA somehow gives someone access to hop through a Solman that does not have S_RFCACL setup … which would be new and surprising information to me here.

- We have the ability to stop transports in QA when there is a reason that is necessary. I assume others do, as well.

- Further, on “creating whatever RFCs I want to,” even if I achieved full SM59 access in ECC QA from outside it, I wouldn’t be able to create non-trusted RFCs into a Prod system, because I don’t know the passwords of the target SAP_ALL IDs. And I imagine I wouldn’t be able to create a trusted RFC into Prod if there’s no S_RFCACL in Prod waiting for me (as specified from the start) -- and if I could, that's bad.

- We certainly have no existing Trusted RFCs between QA and any Prod system, which is the only thing relevant here (except SolMan “Prod”, covered above) -- if there were non-trusted RFCs from QA into Prod, we’d have an existing problem not related to S_RFCACL.

- We do have a Gateway for each level of landscape, so QA has its own.

- I have not tried it yet because, as I mentioned/asked at least 3 times here, I don’t know how. And that “how” is not in ADM960 (I checked). That’s what I’ve been asking for -- a practical example. I don’t even want you to tell me at this point, but I also don’t understand why you would expect me to already know it when I’ve made it quite clear otherwise. So, until I can, I’ll have to take your word for it.

[former_member279014]

Thank you, Greg, for being someone who can point out problems with a theory without malice. Although 1416085 doesn't answer this technically enough, your broad perspective is very much appreciated and is worth reflection.

Now, if ever a thread needed a bow to complete it, this is one. And that bow will be, “why did this all happen?” It’s actually quite simple …

• Them: That incident with troubleshooting that access took too long. What happened?

• Me: Well, we gave him SAP_ALL but that wasn’t enough. Troubleshooting finally uncovered that he needed S_RFACL for this. That’s not in SAP_ALL. But we didn’t have a role in that system/client with S_RFCACL; in fact, we don’t really have one for that anywhere. We’ve never needed it. We had to come up with something. So this took longer than we would have liked.

• Them: Well, why isn’t this object in SAP_ALL? It is SAP “ALL”, isn’t it?

• Me: Well, S_RFCACL is treated differently, kind of special. Let me look more closely into it.
• << cue: research leading to Note 1416085 >>

• Me: SAP doesn’t put S_RFCACL in SAP_ALL on purpose because they say that would be very bad … “you allow the logon from any system, client, or any user” ... somehow. But not without trusted RFCs, I’d imagine. And that would only apply to people with SAP_ALL for the time you give it. Interestingly, there’s a flag mentioned here that could incorporate S_RFCACL into SAP_ALL by default. If we really wanted to do this to avoid this in the future, it seems we have a decision to make. Should we use this flag SAP offers or should we create a ready role with S_RFCACL in it in every client?

• Them: Well then, what would be the real risk of incorporating it? Can it be mitigated and how easily?

• Me: I don’t know. Let me find out.
• << cue: setting up a test environment, not knowing how a malicious person could get in, Googling & reading (neither went anywhere), and creating this thread >>

So, now what I have to show for it is: having a somewhat better idea of how a malicious person might get in (well, that’s something) without being able to answer all of "their" questions, withstanding personal attacks as if this is reddit or Twitter, and having old friends turn on me (well, that’s something, too, I guess).

But at least I now feel fully qualified to write a post entitled, “How to End Your Career and Years of Good Will in Just One Thread.”

The quick answer: “Publicly question anything the target audience apparently holds as sacred, no matter how well-intentioned the reason, no matter how you try to frame and limit the discussion to the technicals. And then don’t just give in immediately ... try to press on in the hopes of getting answers for you and your people.” Yeah, I didn’t see that coming until it was too late.

Anyone who might have had a similar conversation or supported the original intent is surely in hiding in that bunker in Oregon after witnessing this crucifixion. I wouldn’t recommend anyone Like this, either … too risky to be associated.

Since I don’t have someone like Julius here to bounce this off of at my desk, I figured someone in the community knew, so I tried to hold a public, technical conversation to flesh this out.

It failed.

[Former Member]

Take a look at how you introduce yourself, dismiss anyone not up to your standards, make provocative comments about SAP improvements which don't suite your agenda and an ego : skillset ratio in the technical part which is too out of balance to develop into a constructive technical discussion.

5 days down the line you have still not even tested the main and most obvious risk, which you will be taught about in ADM960.

Thread locked by moderator - enough noise and bloviating for me now...