Thinking Workshop”. Cisco Small Business is excited to invite its
Silicon Valley customers to an exclusive interactive one-day session
customers and product Managers. If you are interested in this
workshop, please fill out the Registration
For more information, please check out our FAQ
Get the latest new and information the November issue of the Cisco Small Business Monthly Newsletter
My first post here, and a bit of a beginnger at Cisco stuff. For our small rack in a DC we purchased ASA5505 and 2911 in early 2016, with software support and on site hardware support - the support contract has been maintained since and is still current.
I recently found advisory cisco-sa-20190807-asa-privescala published on 7-Aug-2019. https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190807-asa-privescala
However it says that the only option is to upgrade to 9.4
Except the highest version of iOS supported by our router/ASA5505 is 9.2 - it is running 9.2(4)33
Since this ASA5505 is covered by our support contract, I opened a TAC requesting can we please get this security fix ported to 9.2 or get 9.4 ported to ASA5505 or whatever.
However the cisco support team seem to be adamant that even though the EOL clearly states that the product is supported until 2022, that they don't intend to fix published security advisories. They said they'll happily replace the hardware if it's defective, but not the software... They suggested I complain to my account manager instead... Except of course I have no idea who that is and the distributor I purchased from really doesn't want to deal with this - they want sales leads, not complaints and technical support.
Is anyone else facing this? Any feedback welcome....
I'm pretty sure that under UK law, cisco need to provide service for at least 5 years for such a product, quite possibly 8. Hobbling the product by not providing security updates is certainly against the spirit of the law, and quite possibly against the letter of the law too. But I really don't want to refer this to my solicitor, it'd probbaly cost more than buying new gear.
Oh, and of course this equipment is remotely located. In fact we recently moved it from one site to another and upgraded to the 9.2 software etc, and this advisory came out a few days after we flew out of the country. So replacing the equipment is a real pain. Besides we have a plan to replace the equipment in 2021 based on the EOL and I don't see why we should change that. What's the point in Cisco publishing EOL's if they then retire it years earlier, it makes a mockery of TCO analysis.
The 5505 replacement, the 5506-X was released around ~2012, seeing as they both fit in the same SMB platform space the impending EOL should have been obvious (especially in 2016). Whoever placed your order didn't do their research and shame on your reseller for not making you aware!
I have only seen software updates for products that are deep into their EOL when a critical vulnerability is discovered, ie SSL libraries, heartbleed etc.
In the case of the vulnerability you have highlighted, the technique of limiting subnet access to the HTTP service as detailed (http 10.10.10.0 255.255.255.0 Management) will go a great deal towards mitigating the risk especially if the only permitted subnet is your infrastructure management subnet. For this reason it is easy to see why cisco don't want to dust of the old 5505 codebase and update it.
Thanks for the reply.
For the record, the ASA5506-X was released 17-FEB-2015 according to the cisco page:
That date is only about 6 months before we began planning this deployment, and less than 12 months before our order date. Going with such 'new' tech in a 'remote' location was not something we were prepared to do. Besides, we already had several ASA5505's deployed in similar remote locations, and having this new location use different equipment would have increased our administration costs significantly. You may not have made the same choice as us, but we didn't enter into this purchase blindly or unreasonably.
Thanks for pointing out how to limit access to the management interface. This is already done. However since the advisory does not specify that this is a valid workaround, I assume that cisco know something about the detail of this security issue that means this is not a valid workaround. Besides, I personally feel that it's best to design security assuming miscreants can get inside the firewall, so having a firewall is no excuse for not having security advisories patched.
I am sure I had a 5506 sat on my desk back in 2012, but maybe that is senility creeping in. Defer to the official document!
I agree with your sentiment about the desire to not have kit in production with unpatched security advisories, but I've worked in industry long enough to know that a security audit will evaluate each advisories against the ease and impact of an exploit.
Agreed the config supplied is not a workaround merely a method to reduce the number of source subnets which could be pivoted from to execute the attack on the firewall. I'd like to think that the operators who use devices on a designated infrastructure management subnet would have squeaky clean OpSec behaviours so the possibility of an attack being launched from that subnet are close to Nil.
That said, if you ever have a pentest conducted, they will most likely ask to be connected to said management subnet and will quickly discover the discussed vulnerability!
I think you are missing my point. The issue is that the EOL clearly states that this is supported equipment until 2022, but without security updates it's hobbled. I'm sure there will be another advisory in the next 6 months, then another. Maybe these can me managed, or maybe not. But I have a support contract on a device whose EOL is 3 years away, so I should not need to worry about this.
What's the point in issuing and EOL plan and me calculating ROI based on the published documents, when they just ignore them and retire the device early?
If this is not fixed by cisco I'll never get authorisation to buy their equipment again, because apparently they are happy to withdraw issuing security updates at any time with no notice to the customer.
The tech is solid, but I need gear that is supported for more than 3 years, because replacing this gear in remote sites around the globe every 3 years is unreasonable.
Every admin of every Cisco appliance should be awake sleepless at night wondering if tomorrow Cisco are going to publish a security advisory and no software update for their supported and non-EOL gear.
The final states of EoL only covers service contracts and hardware replacement, it is in Cisco's interest to keep this option alive to help shift old stock instead of ultimately scrapping it.
The EoL policy however does state:
After the first year and for Operating System SW -where available- we will provide bug fixes, maintenance releases, workarounds or patches for a period of 4 years for operating system software. Bear in mind that it may be necessary to use software upgrade release to correct a reported problem.
...so you are still within the 4 year window, but the 'where available' gives a discretionary tone probably because the software engineering teams are reluctant to retool and support an old platform. It is probably worth quoting the above paragraph back to Cisco support and see what they say.
Thanks - that's a big help - I'd been looking for that document, and had it on my list today to do a proper search for it.
I think it's pretty easy to argue that since they have published a security advisory and have done a bug fix, that the fix 'is available' it's just not been ported to ASA5505.
I've been trying to explain to the support/TAC that I'm sure it's just an oversight, and that someone will thank them for bringing the oversight to their attention, but the message hasn't gotten through yet. Maybe with this they'll feel a little more confident to raise it with their boss or whatever the next step is.
And now there are two more advisories, not fixed for ASA5505:
I thought they'd actually fixed one, but on closer inspection I see it was just fixed in an old release (188.8.131.52) and we're already running 184.108.40.206:
So it looks official - Cisco are in breach of contract and have retired ASA5505 well before the EOL date. How are we ever supposed to calculate ROI or plan our data centres hardware upgrade cycles?