Security Patch Alert From US Department of Homeland Security
When you build a data center you look for a location in a safe but accessible area. You don’t typically choose locations next to chemical plants, high crime areas and you don’t advertise with your name on the outside of the building. Putting “My Fortune 500 Global Data Center Inside” would be easy for your vendors to locate you, but so could anyone else. Pretty soon the Google map car drives by and captcha codes are updated and now the whole wide web knows your data center location.
So if we protect our data centers from physical threats, why do so many companies not protect their systems from electronic threats? I hear responses like these:
• Security patches require testing and we don’t have time to test them
• Patches fix known issues, but we do not know what else might be impacted
• We had an issue with a security patch in 200x and so we only put them on with support packs
• Our data center is protected from physical threats and our firewall rules protect us from electronic threats
Anti-Virus software vendors send updates as threats are identified and solutions are developed to protect against them. On the second Tuesday of each month (and sometimes the fourth Tuesday also) Microsoft releases batches of security corrections. On Security Patch Day SAP also releases batches of notes that meet specific requirements related to CVSS scores and risk. As with any other correction they must be categorized correctly in order to be included.
From a process stand point, having the Microsoft and SAP patches released on the same day is a benefit to companies who are trying to implement a recurring patch process. So why would you implement Anti-Virus packages and Microsoft patches without reservation, but you go sometimes years without implementing SAP corrections. This week an SAP correction from 2010 was highlighted in an announcement from the US Department of Homeland Security. You can find that announcement here: https://www.us-cert.gov/ncas/alerts/TA16-132A.
This announcement identifies a risk which was corrected in October 2010 by SAP, but many companies which are running obsolete versions of NetWeaver never implemented the correction. If you review electronic data breaches in the US, you will find alarming statistics from sources such as The Identity Theft Resource Center. This does not include all data breaches but this alone included 378 incidents through 4.5 months of 2016. Most of these incidents were electronic data breaches. Whether you have impenetrable firewall rules or not, implementing security corrections needs to be on your best practices.
For several years Frank Buchholz of SAP has provided monthly webcasts to DSAG, ASUG and even Australian user groups. These webcasts highlight not only the importance of specific notes, he provides steps to analyze what kind of testing is required and informs attendees of changes in the SAP security processes. One of those included information that the RSECNOTE tool was obsolete and what you should be doing now.
Even with this additional communication from SAP, there are at least 36 known organizations with this vulnerability. However, the actual number is more likely much higher than this. If you are on NetWeaver 7.4 or 7.5 for all of your SAP landscapes then you know that you are not one of them. But what if you have a landscape running SAP NetWeaver, releases: 2004, 7.0, 7.1, 7.2 or 7.3? Do you have the Invoker Servlet disabled? If you have any of these releases within your environment, I would strongly encourage you to initially take action by disabling the Invoker Servlet, but as a second step you really need a periodic patch process. Maybe you cannot implement support packs, but applying security notes has to be on your radar. Many of the companies that have an electronic data breach think their firewall rules are rock solid. They never thought they would be in one of these reports.
I attempted to attach the .pdf from the note as an attachment but it is not allowed. I strongly encourage you to review the alert and the notes attachment. The link below to the identity Theft Breach report shows that cyber crime is a big issue. We have to do what we can to protect data. The loss of data whether intentional or accidental can cause great harm to your companies’ image. The time to protect it is always before it occurs. A firewall alone is not enough protection when more applications or connected to networks which are exposed to the Internet.
What is your excuse for not learning more about security patching or even applying them?
SAP does have a great Monthly Patch Process and yes there area bunch of customers out there who don't pay attention to it.
What intrigues me about this particular alert is to question why such a big deal has been made of it? I've had numerous colleagues, acquaintances and organisations send out this same 'press release' about this vulnerability as though it's a zero day vulnerability and bringing down systems globally. It's made 'mainstream' IT news sites, ISACA and other organisations.
Yet, it's from 6 years ago!
The wording from numerous sites is the same paragraph - vaugue to cause some alarm and in some cases redirect you to the website of the security group (who are referenced in the article) to sign up with your details to read more.
I suspect companies with this vulnerability probably have a heap of other problems out there in their landscape.
And yes, Greg, I do agree that there is no excuse in not having a patch management process in place.
I've heard about this from non-SAP infosec sources. It seems like the problem is that nowadays people are getting actually owned via their SAP systems. In one way you could say that it's a progress that they are not getting owned via desktops or POS systems and the attacker shifted to something else :-).
But let's be honest. Many companies handle SAP as something that you do not want to touch unless you really have to. Hence no patches unless it's really impacting business process.
This alert from the Department of Homeland Security would not exist if customers treated at a minimum security patches differently. There would be no story, no alert and nothing to report if security patches were considered a must have by companies today.
However, I know of customers that patch their JAVA based applications monthly but have not touched their ABAP systems in years. Some believe "if it ain't broke don't fix it." I am sure that there are lost credit card numbers, bank accounts, vendor lists, customer lists and more from customers who thought that it was not broke.
I would hope that this starts the conversation for customers who have never considered security patching. However, some will stop again as they find that the older your kernel and support pack are the number of related patches grows as many will have prerequisites. Many do not realize that with analysis many notes have no impact other than to close a security issue. If you are not using the functionality, the testing should be a non-event.
Bad joke starts here: Maybe we should start giving names and logos to these vulnerabilities as it seems to help with convincing some people to start applying patches.
Hi Martin, this is no joke.
Vulnerability awareness and marketing is important!
Who would know of the SSL bugs of the last years if there had not been these catchy names and marketing activity for POODLE, FREAK, HEARTBLEED etc.
The implementation rate of corrections would be much lower if they had not been treated like this.
Did you know that any most recent SAP system ist still vulnerable to POODLE out of the box and needs manual activity to remove this vulnerability?
So yes! Let's give catchy names to vulnerabilities at least to those with manual activity that will accompany us for years like this one.
I do not agree. Yes, it increases patch adoption for that particular vulnerability but is it actually helping. My biggest problem is that it creates just an illusion that something is happening. If company's patching is driven by names and logos then probably the company can't even figure out what needs to be patched. If we add a catchy name to every vulnerability are they all going to be fixed. No.
I heard this joke: soon with all these names we will need some kind of database that assigns ID to these vulnerabilities to make sense of it. Something like CVE.
I also do not understand why the vulnerability with manual step are special. I know consumers are spoiled and usually just enable auto-update in their OS and browser and don't have to care anymore. Don't get me wrong, this is good. But this is not how it works in complex IT landscapes. You need to get the reports, analyse them, apply patch if available and test it. But you may also perform some other mitigations like disabling unused service and so on. So you should expect some effort required. Not take it as something special.
Very interesting post Greg, which raises great questions for the industry as a whole.
For those who are interested in the data behind the DHS US-CERT Alert, you can check the full Threat Report and additional resources in the following link:
I really encourage all SAP customers to check these resources, in order to further understand the risk and potential implications of this vulnerability, know if you are running unprotected systems and step-by-step mitigation information to protect your company. Here we refer to the relevant SAP Security Notes that would be important to analyze and some additional considerations.
I also specially recommend to read the FAQ, which captures common questions we have received throughout the process of developing this threat intelligence.
Colleen Hebbert - I agree with you that there is some noise and misinterpretations that has been generated in the press and by other individuals, and do not properly represent the nature of our research and findings. I'd strongly recommend to read the report and FAQ, which I hope provides some clarification, and feel free to reach out with any further questions that you may have.
We believe this information is critical to ensure SAP customers are better protected from cyber attacks.
Thanks for your reply. I hope my comment didn't come across as criticising your company - I do read your colleagues contributions frequently.
Perhaps this type of media attention is enough to continue to the conversation and concerns with patching. If a customer has a vulnerability which should have been patched 6 years ago, it would have been interested in the media attention posing the question as to how many other vulnerabilities exist
Hi Greg, I think this issue is one which cannot be solved by a typical patch process. Why? Because it involves manual activity (at least if your system is "older" than 7.20).
So even companies with a regular patch process might be hit by this issue.
This vulnerability is more about how we treat and keep track of manual activity.
Who will look at a security note of 2010 if he installs a 7.02 system including all available patches today (for whatever reason)?
There are more examples like this where a security note only gives a hint how to close a vulnerability manually. And very often corrections are attached to a note like this so that on first sight you think that everything is fixed by theses corrections. But these corrections might only enable manual activity (like this one).
So this is more about
So this issue is an example why a good patch process might not be enough.