Security Audit Log / Logging of downloads from query results?

[Former Member]

Hi everybody,

our data protection team has raised the requirement to log all data downloads from our BW system. As far as I know, it is possible to log downloads in SAP GUI using Security Audit Log, but does this also cover "Export to Excel" functionality of query results executed in the portal? And what about execution of queries with BEx Analyzer? I doubt, if that tool would log this. Are there any other tools available to cover that requirement?

Any comment and idea is welcome. Thanks in advance!

Regards,

Carsten

[Frank_Buchholz]

There exist many ways how to copy data from a screen to a PC... The function System->List->Save->Local File is secured with authorization abject S_GUI but there exist numerous other options.

I do not know how to block downloads completly or how to log downloads completly.

Kind Regards

Frank

[Former Member]

Frank,

Thanks a lot for your reply, but it doesn't make me much hope to find at least partly solutions for this problem. Of course, there are many ways to get data from the screen into local files, e.g. per paste & copy. However, it would be great to know, if there are any ways to prevent users from using download to Excel functionality in web queries (I guess, this has to be de-activated for the standard web template, hasn't it?), or to execute queries with BEx Analyzer. Is there any way, to allow a power user to use the Query Designer (as stand-alone), but to prevent him from using the BEx Analyzer? I'm not sure, but I guess transaction code RRMX refers to both, doesn't it? Any further comments are welcome!

Carsten

[jurjen_heeck]

our data protection team has raised the requirement to log all data downloads from our BW system.

Besides what Frank already said, just trying to block functionality or log certain actions in SAP isn't going to be secure in any way.

I would like to learn more about the requirement and especially what this data protection team hopes to achieve. If they want to make sure no data leaves the company without them knowing I think they should focus on internet/data connections, phone lines, doors and windows. And ban all mobile devices with cameras. Abolish pens and notepads. Fire everyone who has a good memory

Just my 2 ct.

Jurjen

[Former Member]

@Jurjen: The requirement has risen up, as it is an HR BW, so the data is very sensitive. There are data protection laws e.g. in Austria and Germany, which demand for strict control on person related data, to protocol each access on such data, and to check the legitimacy of usage of this data, including download or any other kind of transfer (see Austrian DSG 2000, §14 (2), or German BDSG, No. 4 in attachment to §9 sentence 1). So it would be interesting, too, how other companies handle this issue with HR related data in BW system.

Of course, I know that there are many possibilities to get data (for which one a user is indeed authorized to access by his roles) out of the system, and I also had and have many doubts if it makes sense to try to plug up some of the holes, when other ones are remaining, but can't reasonably be closed. However, both laws also tell, that protection measures shall be equitable compared with available technical security level and triggered costs, so I try to find out, what might make sense, and what is unrealistic to realize.

@Julius: I'm not familiar with the idea of tokenization. I looked in Wikipedia for the meaning, but have no idea how to use it for data output. It sounds to be rather complex and costly to implement, but may you add some more explanation to it, to better let me understand, what to do for realization? Thanks a lot!

Carsten

[mvoros]

Hi Carsten,

tokenization is a technique where for a piece of sensitive information you generate a token and use it in the system. For example it's used for protecting credit card data. E.g. you have a BI system where you use credit card number as an identifier of customer. You really don't need to have a real credit card number in that system. So you replace all valid numbers with tokens and you can still do your reporting. It's a common technique to minimize scope of PCI DSS assessment. In your case you might be able to use this technique for some fields.

In your case can't you just assume that executing report is equal to downloading report? Especially, in case of BEx Analyzer. BEx Aaalyzer transfers data into PC cand displays them using Excel. In my opinion that's same thing as downloading data unless you have a PC without internet access and USB.

Cheers

[Former Member]

If restricted to ALV I think it can be done, but even there... if the user executes it in background and mails or prints the spool request then the cat is out of the box...

Moral of the story: Do not grant access if the user should not be able to see the data (regardless where they log on from).

That you cannot monitor / log all (mass) download events is however a bit unfortunate, however once the data is outside of the system for those whom you do trust then you anyway need to train them not to park sensitive files on project or public file servers.

IMO the main problem here is front-end computing tools (like Excel, etc) which the users feel more confortable with to analyze data than the server side analytics tools (e.g. in the ALV task bars, or even the BOBJ Dashboards which are very "user-sentric").

In German it is known as "Bauern mentalität" (farmer mentality) which generally resides at the application surphase layer in the greater scheme of things:

-> You do not eat anything you have not slaughtered yourself...

Specifically regarding tokenization, you can consider not displaying the data in the portal. If the user wants to display these fields they have to navigate in their own context into the backend system to retrieve the token and then only display individual values.

--> A download of a list via the portal or BEX excludes these fields which the user can access, but not mass download.

I think this is possible, but it will be a challenge depending on whether the fields support tockenization. Credit Card numbers as mentioned my Martin is fairly vanilla and already used.

Custom fields&types, insufficiently critical elements and older programs will be a bigger challenge.

Please provide more details, as the generic answers are not well take care of IMO. If you cannot provide mre details, then SDN discussions speculating on answers is not efficient either...

Cheers,

Julius

[Former Member]

I am not sure whether this will work, but if you are using tockenization on the field(s) and they support it, then it is only the reference which is saved and the value displayed. When you download the list (here you must be aware that the user already had access to the displayed data!) then with some luck you might only have the reference tocken in the data and not the value.

I say "might" because I haven't tried with BEX and have some serious doubts about a portal supporting it.

In ABAP could look into the SAPGUI front end services methods for an exit or enhancement possibility to log or further prevent the download function of specific data, but for the portal I am not aware of anything like that possible on the Java stack.

Tough call. Tough requirement...

Cheers,

Julius

[former_member217320]

Hi Carsten,

Did you ever find a solution to this problem? We have a similiar requirement and any input from you would be much appreciated.

Thanks in advance.

Amber