Security notes - how to stay in control?

[Former Member]

In the last months the focus on security has been increasing, which in itself is a good thing. The fact that code scans are being performed is, is a very positive initiative.

However, the downside of all this extra attention that a huge amount of security notes is being released. The result is that we are struggling - and failing - to keep the process of review and implementation in control. Even if we would do regular support packages, it seems impossible to manage all these notes for around 100 productive systems. Therefore the choice has been made for now to only do the exercise for our critical business systems and later on try to do the same for our less critical systems. However, this does leave residual risk in your system landscape for also the critical systems as most systems are connected in some way.

I don't think it can be that we are the only company struggling in this area. Therefore I'm curious about your experiences in this area? How are you managing the increased workload in this area? How do you set the priorities on review and implementation? And how do you manage the implementation?

Thanks,

Maaike

[Former Member]

The RSECNOTE tool together with the monthly patching on "Patch Tuesdays" has been a big help to organize automatable patching.

December's batch was IMO somewhat of an overkill in number (+ 500 notes) to release all in one go and some of them should have been included in an SP and let it be. Tricky are the ones with manual configuration instructions and it should have been easier to identify those once the coding part was in as the sheer number made a SP an attractive if not even easier option anyway. If HR systems can get it right then why not the rest?

I invested a week in going through them on an SP 7 system (7.01) and provided recommendations to my customers on what they should proactively implement, what would require an additional manual instruction and what was IMO okay to go in with the next SP or even ignore for the moment.

Hard day's work but fun it was

Julius

[Former Member]

The note 888889 describes the RSECNOTE tool which is very helpful. It differentiates which are the SAP Hotnews(priority 1 SAP Notes) which need immediate attention.

[mvoros]

Hi,

regarding that huge batch of security notes check note [1533030|https://service.sap.com/sap/support/notes/1533030]. There is an attachment which describes "the most important security notes to start".

Generally, I think that SAP admins are not pro-active and this has to change. Patching is not popular and usually avoided as much as possible. The systems are more exposed Maybe it's time to define and implement patching policy. I know more ranting than helping

Cheers

[Former Member]

Specifically regarding the directory traversals (which is many of them...) I can recommend SAP Note 1497003 (long read...).

A chance not to be missed is the Switch Framework. This is an extention of the Enhancement Framework combined with Support Packs for the components. It gives you the possibility to isolate the impacts of program errors and config activations between that which SAP changes and that which your implementation is infact using.

You will only find a very small number of the 500+ notes via the RSECNOTE tool, depending on whether they are flagged as "automatic" for you or not. Effectively useless for the December patches if you don't know what you are using....

Anyway, a huge December patch nicely caught the HCM legal pack cycles. In January it was only about 20 patches again.

The real nut crackers and tricky stuff is those with manual instructions to activate features when downward compatibility needs to be respected.

Cheers,

Julius

[Former Member]

It's a tough question in large environments. At a previous employer with a simple business suite deployment (1 ECC, 1 BI, etc) Red notes in RSECNOTE were reviewed weekly by Basis/Security with Config and WRICEF teams participating in code reviews and offering suggestions for test scenarios. the intent was to implement Red notes into PRD within 1 month of discovery in RSECNOTE. We made subjective decisions about other severity levels.

But I admit, keeping up with RSECNOTE across dozens of global systems is a major challenge. One idea we discussed was to identify the functional area relevant to a patch, and engage an FA in that area to make a decision (by working with the business counterparts) - accept the risk associated with the vulnerability or implement the patch. If patch, then they would need to provide testers (perhaps), manage the change into PRD, and coordinate with basis. Most of the time risks would probably be just accepted and the patch ignored, which wouldn't solve the vulnerability, but it would appropriately place the risk within a business or functional area. Another option we discussed was a quarterly implementation of all Red alerts, with only notifications sent to FAs and business areas. Real hard to do this in large environments as these are like mini-support packs sometimes.

How do you currently handle it?