Vulnerability/security patch management

Question

I'm looking for the best way to manage SAP security patches and vulnerabilities. We have to do a monthly assessment of the newly released vulnerabilities from SAP and determine if they relate to our systems. I'm having a hard time finding a good place to get a list of recently released notes.
I found https://websmp210.sap-ag.de/security - click on Security Notes, but the list doesn't appear to list everything, and doesn't show what is new or updated from month to month. This creates a lot of manual work looking at each note every month.
Does anyone know of any tools that can help with this. I'm looking for something like what Microsoft does with it's monthly security updates, and ideally a tool like WSUS that can analyze the systems to determine if they require the patch or not.

Answer 1

Hello Jeff,
Very good question! I have very often thought about this, and how I would like to have the information communicated to me without it being communicated to anyone else...
Specifically regarding the security notes page, I have observed that the notes are added to the list at the top. However, the release date of the note, an update to the version of the note, nor a related note does not bump it to the top again nor influence the specific order.
Certainly, the notes which are listed there are important ones (as indicated by Keerti)... or the principle is... some components are worth keeping an eye on, particularly if you use them or they are new.
Alone the fact that they are published for all OSS users and additionally on that (security) page, should be reason enough to think seriously about implementing it or considering it in your own developments... If you look at some of them, you might also see they are corrections which enable security controls, so regarding your patch management I can also recommend that you differentiate between your "program error patching cycle", and your "correction and activation instruction cycle". Of course, some notes are not intrusive on customers who do not require the correction or are oblivious to it.... so you can patch until the cows come home... it will not help you until you activate the new security feature or change your technique... User types are an example of this.
In some special cases, you need to have found the problem, before you are able to activate a solution for it. Sometimes you have to use the potentially problematic feature (setting up customizing or settings for it, and assigning authorizations to use it...) at which point the system will point things out to you. In other cases, the system will hassle you to change it for many reasons, not only the security reason.
It makes sense to restrict authorizations and settings to only that which you use. That helps a lot. See various threads here on transaction SU24 for some examples from the authorizations aspect of security.
Another tricky aspect is, once someone has a patch installed in their system or a security researcher has found a bug... should they make statements about it in the internet (followed by Smiley's :-)...? Often, a 90 day grace-period for admins is observed.
If you stick around here at SDN and read some of the posts here carefully, then you can also learn a lot in a relatively short space of time, on an ongoing sort of distributed space of time....
Reading the security wiki's and guides are also very helpfull of course.
Risk rating can also be tricky. You might find that if your security analysts are all security or authorization admins, then they might prefer to go for program corrections rather than role changes... or concept changes... Management might even resist changes, for fear of them, their costs, etc.
Regarding analyzing your systems, you might want to consider a "Security Optimization Service" session. You can also download this and maintain your own additional checks. That requires a small additional effort and cost. You can find more information on it by searching "OSS" and service.sap.com/security. In a 1 day or more detailed session if you want, you can cover many risks with a relatively low effort.
I have participated in two of these (we requested them) and it was helpfull. I also provided some feedback to SAP suggesting checks and some risks. My take on it is: If we contribute to improving standard solutions (and reporting bugs), then we all benefit from it "for free" in the standard products.
Last but not least, there is monitoring. You can learn a lot from the various monitoring possibilities (check your legal requirements for security there as well).
Some thoughts from me for your interesting question,
Julius