Welcome and Introductions
Lewis: I can see people starting to join. Thanks for joining us. Let’s give it a minute for everyone to drop in and then we’ll get started.
Hi everyone, thanks for attending the first-ever online version of Magento Leeds Meetup. I think we’ve got people attending from all over the world today and I know there are a few people viewing from across the pond at the moment. Hope everyone is keeping safe and well in the current times.
We’ve got a really good meet up for tonight’s event. To introduce myself, I’m Lewis, Managing Director at Pinpoint. For anyone who doesn’t know, we’re a dedicated Magento agency located in the UK and we’re an official partner of Magento. As I’m sure everyone hopefully knows by now, we’re only five days away from the end of life for Magento 1. Unfortunately, not everyone has managed to launch their new store in time for tonight’s meet up. What we’re aiming to do today is have a dedicated event to help shed some light on what you can do to ensure your sites are as secure as possible until you’re in a position to be able to migrate and keep them functioning on Magento 1.
For tonight’s meetup, we’ve got a really good line up for you all to listen to. I’ll let everyone introduce themselves and their respective companies shortly, but just as a very quick overview, we are today joined by Willem de Groot, founder of Sansec.I’m sure many people will recognise Willem as the creator of MageReport, but Willem has a huge amount of experience in tracking, skimming and payment fraud. Next up is Victor Santoyo from Sucuri – Sucuri clean and protect websites, offering a range of protection, monitoring, incident response and malware removal for Magento, WordPress and various other sites.
And finally, we’ve got Rico Neitzel who is CEO of Mage One. Many of you, again, will also recognise Rico from the Magento community. He’s part of the Certification Advisory Board of Magento and has been working with the platform since the early versions. Mage One offer professional Magento 1 support to merchants who want to stay on the platform as of the end of June.
We’ll be running tonight’s event as a panel, and have an option within Zoom for you to ask any questions that you have about the Magento 1 end of life. So, anything that’s relating to Sansec, Sucuri and Mage One, if you’ve got any questions, please make sure you use the question and answer functionality at the bottom of Zoom. Add them in as you want, and we’ll be doing a little bit of a Q&A at the end. If you want to ask all panellists, that’s absolutely fine, or if you want to direct it to one of our panellists, I’m sure they will be more than happy to help answer those questions.
A very quick thank you from my side for the help on today’s event. Doug, Emma and Gavin from Pinpoint, who have helped to organise tonight’s event. Obviously, the three panellists, without them, we wouldn’t be able to do the event, so thank you very much for giving up your time to help out on that side. And again, all of you guys for attending. Obviously, we are in unprecedented times at the moment, so we really appreciate you joining us today. I’ll pass over to the panellists now to introduce themselves in more detail, let you know a little bit more about their backgrounds and the services that each of their companies offer. So, Willem we’ll start with yourself if that works for you.
Willem: Thanks so much for inviting me. I’ve been working with Magento for years, I’ve been running a Magento hosting company in the Netherlands which was quite successful. But security really is my passion. I’ve been working with compromised Magento stores for years, starting in 2015 when the notorious shoplift bug was published and massively exploited at that time. With my team, we created MageReport, probably you’ve used it. And we started monitoring Magento stores around the globe to see if we can find malicious activity on the stores and really, it has become my passion to find more malware and be smarter than the guys who tried to hack into stores. So, I launched a different company called Sansec two years ago, and we focus exclusively on Magento stores and protecting them.
Lewis: Thank you very much. We’ll pass over to Victor now to introduce Sucuri.
Victor: Thank you, Lewis, and thanks again for the offer to participate. So, as mentioned, I’m a senior account executive for the company who I joined in 2015. My responsibilities really are working with other agencies, manage providers and small businesses, finding the best approach to securing their online presence. From those that have established online presence that are facing existing incidents, to those coming out of brick-and-mortar who are not certain of the landscape and try to identify the right solution for them. So, working with them has provided us a lot of experience over the years in terms of understanding the types of malware trends. Our company is built to both respond to existing incidents to clean up an existing infection and we will protect them ongoing with some of our firewalls styled solution. So that’s about what I do on a day to day basis. The job is 24/7 as you may imagine so, by all means, if after the webinar anybody has questions, you can always reach out to me.
Lewis: Thanks. And finally, last but not least, Rico.
Rico: Hi, my name’s Rico. I’m CEO of Mage One. We provide security and cumulative patches for Magento 1 past the end of life sometime next week. I myself have been working with Magento for 14 years. So, when was the earliest beta version? I was working very much with Magento 1 and also dived into Magento 2. But I had a lot of connections to merchants and agencies and they all decided that at some point it might be useful to switch to another platform, but it’s probably not yet. And that’s why they ask us if we have any kind of idea and that’s when we came up with the idea of founding Mage One to support those merchants and agencies.
Lewis: Brilliant, thanks everyone. We’ll jump into the panel questions now, but everyone remember, if you’ve got any questions, feel free to type them into the chat tonight and we’ll come to those at the end. So, I guess initially, a question for all panellists:
Panel Questions
Outside of security patches, what other risks do you see that merchants on Magento 1 would be facing post end of life?
Willem: I think the biggest issue is with third party software. The core of Magento is covered by excellent alternatives in code support, for example, Mage One. However, a typical Magento store has maybe 20 to 30 extensions installed, and those extensions will not be maintained after the end of life (EOL) – well most of them – and they may pose a security issue as vulnerabilities are found all the time. However, it may also be a functional issue if vendors of those extensions stop supporting integrations and your store may not be able to communicate with logistic systems, for example. So that’s one thing to take into consideration.
Lewis: Victor or Rico, have you got any thoughts on that side as well?
Victor: Yeah, I think part of the issue that we often see when we see other platforms reaching end of life with a particular version is a lot of people exercise a lot of the right habits at the end. So, people are going to be much more conscious of, like what Willem was discussing, identifying what part extension should be appropriate to ensure you remain compliant. But after that, once that urgency leaves these business owners, often people kind of let things go bad after a while. So now annually, you’re not exerting the same type of urgency to ensure that you’re keeping that up. So, for me, it’s making sure that you’re also maintaining those same types of habits and making sure you have visibility on the right software you’re using.
A lot of people are likely not realising that as part of ensuring they’re migrating over to Magento 2, there’s going to be a lot in terms of inventory management that they need to do and making sure they maintain that on an ongoing basis. I mean inventory management is critical in maintaining your compliance and you have to have these things identified. But people don’t make a habitual nature of always checking on a more frequent basis what’s being deployed in your environments. So, for me, it’s those types of things, being more habitual about those concerns. Yes, post end of life, people need to remain as vigilant as they were trying to make sure they remain compliant during this phase.
Rico: I mean as always, if you look through the versions that are out there in the wild, you can see a widespread. I mean, Willem you can probably give us numbers for that as well, we see sometimes even Magento 1.3 out there somewhere. A lot of people that didn’t care about security in the last years, having unpatched or unmaintained Magento stores, are now focusing on that part, especially driven through this PCI compliance discussion. But they care about that.
So, in the last weeks, we had a lot of tickets coming in from people that used the Magento 1.8 or 1.9.2, so those are slightly outdated, probably unpatched Magento versions and they are now conscious about their security and they think about that. And I think that is a very interesting turn that happened here, that a lot of people now look into security. As Willem already said, it’s not just the Magento core. So, we only care about the Magento core, that’s the thing here and it’s just a Magento Community edition, that’s another thing. Because we really tried hard to fight for the enterprise edition, but Adobe refrained from giving us any kind of permission to work for the clients. So, at the end, the customer can just upgrade or patch the Magento core, which is basically community addition, but they have to care about the enterprise parts themselves.
And for sure, besides that, you have third party applications. When we founded Mage One, we reached out to a lot of payment and solution providers to look for someone who is willing to continue supporting Magento 1 merchants. A lot of people actually signed up for partnerships that basically, I wouldn’t say forced them, but they agreed to continue their development and their care for Magento 1 customers. And I think that’s very great because we have partners in a lot of different areas of extensions that you need for Magento 1. So, checkout, shipping, whatever, and also payment providers, who also partner with us said “Okay, we don’t have a problem with PCI if our merchants have a bunch of security measures in place”. And that’s one thing with a patching service like Mage One, we are happy to service those merchants as well, so I think it’s a very interesting thing that happened here with the EOL of Magento 1.
Lewis: Definitely. Thank you for that. We’ve definitely seen with some of the clients that have come to us in the past, there are still a lot of people who are not on Magento 1.9. And we’ve seen, similar to yourselves, people who are on 1.3 still who are struggling to keep that site up to date and running.
Just out of interest Willem, and this is outside of the panel questions we had, but
Do you know what the split is of people on Magento 1, the percentage that is actually running on 1.9 at the moment?
I know you had some interesting stats that you were tracking on that side.
Willem: Yeah, we publish the stats daily. But I would say there are still just a bit more than one hundred thousand Magento 1 stores. And I think, when I last checked, about 35 thousand Magento 2 stores.
Lewis: So, they are moving across, around a hundred thousand Magento 1 stores, and do you know what proportion of those are on Magento 1.9?
Willem: I would say about 90 percent.
Rico: That’s very interesting. Just one thing here, because sometimes people think that there are a lot of abandoned shops like test installations and whatever. But if Willems says now about 90%, right? That actually tells me that these might be real life shops so it’s a huge number, I think.
Lewis: Yeah, very good point. So, a question for yourself Rico. I believe you’ve already touched on this, but you’re only looking to support users that are running Magento 1.9 and above.
What would you suggest to merchants who are using a version of Magento that is older than 1.9?
Rico: So, to be honest, we’re not only supporting 1.9, but only 1.9.4.5. Because what we want to make sure is that every merchant that uses our service has the same starting point and to keep our service as cheap as possible, we had to make some trade-offs here.
Our main point was to sustain a bug-bounty program. So, this is very important for us. This is one of the key facts that we have, because in other cases, I mean, we can just look through the code and that’s OK. And we can have security specialists scanning the code, that’s all fine. But still, there is the creativity of security specialists and hackers out there and we want to keep that. And it was a very successful program once Magento and Adobe signed up for HackerOne. And we want to keep up that spirit here as well. And I mean, as you all know, and Willem, you’ve been involved in this discussion on Twitter lately. People need some kind of incentives. They don’t want to look for security issues in old software only if it’s probably worth their time. And in that case, we have to make sure that they get their money if they find security issues on Magento 1. In order to make that viable for our merchants, we had to figure out how we can do that without taking a lot of money from every merchant. That’s why our pricing model also has a different take here.
So, it’s not a fixed fee for everyone, but it’s a fee that is based on the total revenue done through the online shop, so only the Magento revenue. And in that case, the smallest merchant that probably just does five thousand a year with a Magento store because it’s a side project or whatever, they can start with, twenty-nine euro per month for up to 100k Euro annual shop revenue.
In that case, it’s a thing where we had to make some decisions and one decision was to only start from 1.9.4.5 or 1.9.4.6 (If Adobe decides to put another version in the next five days), I have no idea, I mean, yesterday, I think they uploaded another patch for the new patch. So, in that case, we take over where they leave Magento and then we start from there and also from the security point of view, we think it’s the best to upgrade to the latest version.
Lewis: And then I guess on that side, if someone is on an older version, questions to all the panellists:
What would you recommend merchants do if they can’t upgrade to version 1.9.4.5?
So one of the things we’ve seen historically with sites is that a lot of the core of Magento has been affected, for example, and they’ve had a large amount of customisation done to the core of Magento, which has made it very difficult to be able to apply those patches. So, this is typically with maybe versions of 1.7 or 1.6 and they may have managed to, I guess scoot under the radar in terms of compromises as it were. Is there anything that these merchants could do to kind of help alleviate any ,or reduce the amount of, risk that they might have from being compromised on that side?
Victor: I think a lot of what can be helpful in a spot like that is, you know, is kind of identifying the landscape and looking for reliable vendors that can help us virtually patch those items in your environment. And we have a number of different platforms, of course, beyond Magento that we protect. But in that same principle, a lot of people make customisations of software that prohibit them from upgrading seamlessly to a more reliable instance. So, we provide, for example, ongoing protection through a web application firewall that we essentially find rules and signatures on our cloud network. So, we don’t place that responsibility on the end user to have to make sure that they themselves are counting for the next type of major card variance, for example and ensuring that particular store front is secure.
Another thing maybe is to also work with other assessors to look for compensating control based on how old you’re working off on Magento. Because a lot of times what’s going to happen is you don’t, beyond just the fact that you want to remain safe and reduce risk, you also want to fulfil compliance. So, you know, understanding what vendors can help patch those particular concerns or at least what assessors may recommend for compensating in light of what specific environment you have I think, for me, will be the best way to mitigate against those risks.
Lewis: Brilliant, thank you. And so, Rico, another question for yourself.
Will your service support any third-party extensions at all and especially down to things like payment gateways, such as Adyen, Braintree and PayPal should they make any changes to their APIs, or would this fall on merchant’s development agencies to solve these issues?
Rico: So, probably everyone who looked into this topic how to stay secure with Magento 1 came across OpenMage. OpenMage is an initiative based on community efforts and they are currently downloading and keeping a copy of every publicly available Magento 1 module from the Magento marketplace. So, in that case, they put them on to GitHub and people can work on these GitHub repositories and probably patch those extensions.
Especially because you mentioned Adyen. Adyen already decided not to service Magento 1 merchants anymore so, in that case, it makes no sense to upgrade the extension anyhow because they refrained from supporting their Magento 1 merchants, so you have to switch to a different payment provider either way.
For others, some of them already mentioned that they want to continue supporting their Magento 1 extensions. So, it’s the merchant who can count on the payment provider to upgrade the extension. Sometimes they will just patch it for security issues, but they won’t probably integrate API changes. While we personally think that it’s not very probable that a payment API will change rather soon because it’s a very stable system. And I know that PayPal has an API that has a huge bug, the rounding bug, which we know in Magento, is basically a bug in PayPal. But PayPal cannot fix it because they would break all the other implementations. So, in that case, I don’t think this might be an issue, no.
Lewis: Ok, that all makes sense, thank you. So, Willem, you’ve been a very active part of the community for a long time and have recognised the number of compromises on Magento stores over the past few years.
How many new compromises are you seeing directly affect Magento 1 stores on a regular basis?
And I think we’ve just had a very similar question on the chat from Ronald just asking
How many stores have been hacked in the past year or so?
Willem: Yeah, thanks for asking. I just mentioned, as we monitor all Magento stores globally since 2015 on a daily basis for signs of malware and I must say that we do so from a public perspective. So, we download the whole site and we see if any malicious code is present in the public assets. The figures for that are quite big, but I must say the real figures are much higher because not every hack results in a public asset malware. Not every hack is visible from the outside. So, I would say there’s 50/50 from our perspective. 50 percent of hacks result in JavaScript malware and the other half ends up on the server where the stolen data is exfiltrated through php code.
That said, the figures for Magento since we started monitoring, I guess we have discovered about 50 thousand stores that at one point had malware present. The number is quite big and still a lot of stores get discovered every day. I think for the last couple of months we saw about 1,500 hacked stores per month hacked Magento 1 stores. Compared to Magento 2, there are about two to three hundred Magento 2 stores getting hacked per month. And about three to four hundred other stores so that is anything from Big Commerce to Shopify to Open Cart to Salesforce. There isn’t really a platform that is secure. However, unfortunately for Magento, because they used to be the biggest and have the largest market share, they were the primary targets for criminals for many years and still are today.
To answer the question from the chat. This year, we found about 15,000 Magento stores getting hacked. And again, these are only the numbers from the data that is public, so the real figure is probably much higher. Now, you may also would like to know how these stores are getting hacked. Of course, I don’t have data for all these fifty thousand stores for the last year, but we do a lot of forensic investigations for Magento stores – probably a few dozen per month. And so, we have quite good visibility into the latest tech methods.
And it’s also our value proposition. We study these tech methods so we can protect our customers with the latest information and once we find new tech methods, we can distribute it instantly around the globe to all our customers so they can benefit from it. Recently, I would say the most common tech methods are, well, first of all, are bugs in third party components, either those are known bugs, but the merchant doesn’t know that there is a vulnerability in such a component, or the bugs are in custom code that hackers are actively searching for. So trends over the years is that, well, back in 2015 when there was this big security issue with Magento, hackers just wrote scripts and automated their operations, and they would hack into thousands of stores on the same day because it was all automated. And more recently, we see that hackers just pick a juicy target. For example, a store that we see during lockdown that they would expect would have a surge in traffic and they would spend weeks to get into this store. And once they were in, they had custom written malware to optimise their criminal profits. So, what they do is they search this store, they launch an automated attack and try to find programming errors in custom code that is present on the store. So that’s a big one.
Another one is automated password guessing which still happens. You really should use strong random passwords. And even better, you should restrict your admin panel to only your office IP or your VPN IP. A third one that is pretty upcoming in recent months is that we see maybe a couple of each week are social and email campaigns. So criminals, they look up website staff, sending them specially crafted emails with malware and once any of your staff clicks on such a link, they will have malware on the PC and this allows the attacker to take over the admin sessions. And yeah, there is not much that you can do apart from having proper antivirus software on your staff’s PCs. It can’t even be protected by two factor authentication or a proper firewall, because what we sometimes see is that they take over the connection from your office and you use your own office connection to log into your Magento store. So really, it’s important to run proper antivirus software.
Lewis: There are some amazing tactics that people use to try and gain access to some Magento stores, very creative. And I mean, it’s really interesting to see that 15,000 Magento breaches so far this year, and if we compare that to, I know the numbers will have dropped month on month, but if there are one hundred thousand active Magento stores at the moment running and that figure is underrated, there is a very large amount of, I guess, compromised stores out there percentage wise versus the number of active stores currently running. And so, Victor, a question for you.
Do you recommend any other services alongside Sucuri to ensure that users keep their Magento 1 store secure?
Victor: Yeah, I think the major players, for detecting unmasked parasites, you know and some of the other Magento malware scanners that we have touched on are really important. The biggest thing you want to do is have some visibility. I think Amasty, another core file integrity check that’s helpful. It tries to check the most vital folders that are there to ensure that no false positives aren’t often picked up, especially when you do have custom code written, because you just want to be aware of what type of outdated components you do have within your instance.
Actually, to take you back a bit on what Willem was touching on, we typically produce some like summarised data on everything we see from the group of our staff that removes malware. And so, a lot of what we saw in fall 2019, is within every Magento case we touched, 87% percent of those cases had outdated software from the core. So, it kind of speaks to, if you’re running on a version that’s below 2.0 or even 1.9, you’re really putting yourself at critically high risk. You know, this isn’t a potential issue here, once in a blue moon – you’re really critically vulnerable. And I think a lot of the trends in what Willem was touching on in terms of the types of attacks that are out there, are right in line with what we see percentage wise. I think all that he touched on comprise of about 55 percent of the types of infection in terms of the vectors we see from those Magento instances.
So I think for us, utilising some of those tools that we have and having a site check scanner as well on our site that can help identify the state of your software if there are stuff, you know, JavaScript injections or defacements. And so are the type of tools that are there. Credit card skimmers, are as big a thing now as they have been, you will find those do assess for that. And another thing to touch on is the environment you’re sitting in. Some of those tools will also touch on what version of software your server is running on. Are you on version seven? Are you not? How backdated is that? So I think for us, it’s just making sure you have scanners that can help assess those types of vulnerabilities and missing patches for not just your site, but your environment as a whole, which is just as critical.
Rico: May I add something to that? Because this is something that usually falls behind, and people are not thinking about that. You have a supply chain somewhere, so you’re using external services that inject code on your site. And in that case, it might be vital to check those services as well. In that case, you need some kind of supply chain security solution. I don’t know, Willem, we talked about that a few months ago. I don’t know if you have some insights? Otherwise I might know someone else, but I’ll give you the first try here.
Willem: Yeah, thanks. Our product doesn’t check for supply chain attacks. I must say, overall, there are relatively low volume. They happen occasionally. However, it is very solid advice to go through all your dependencies and validate them. Typically, a lot of dependencies, for example, a cookie consent pop up screen, those should not be loaded from a different site than your own. You should copy them to your own site so you can verify that they are safe to use and not tampered with later because every dependency you inject makes you depend on the security from this third party. And not a lot of them have security personnel on site. For my store, I would reduce the amount of external dependencies as a general measure. And I would only use third party dependencies that have a solid track record and a big customer base.
Lewis: That’s really helpful. Thank you. I think I saw a post that you may have put yesterday or the day before around cross site scripting compromises where someone has managed to load something in from a Google URL. And effectively that being an easy route to basically be able to compromise moving forward.
Willem: So, yeah, that was another supply chain attack because the sites got hacked so the code was injected on the Magento sites themselves and not only Magento, but also different sites. However, the actual thefts of the private data, customer data was happening in a very novel way.
Normally criminals hire servers in Russia or Indonesia, or a tropical island and they get sent there. However, this time they used the legitimate Google Analytics server to send the stolen data. And well, because pretty much everybody trusts Google Analytics, it didn’t get flagged for a long time before somebody discovered this novel way of stealing data. And it really illustrates how fast development goes on both sides of this divide, both on the bad and the good side. So, you really need to stay on top of it to secure your store.
Lewis: Yeah, I think that goes back to the people who are compromising sites who are exceptionally creative with their routes, with their methods, rather. Very, very creative ways. So, a question to all panellists again:
What process would a client need to go through if they are compromised post end of life Magento 1?
Victor: So, we work together with a company which is called Foregenix and Foregenix is a PFI specialist. And I just recently talked to Drew and he explained what needs to be done and how cost intensive it might be.
So just a sneak peek here, it’s about something between 15 and 30 thousand per incident. So, first of all, if some breach happens and you need a full PFI, so in that case, the PFI itself is something between 5,000 and 10,000. It’s an investigation. What happened? They tried to figure out how the breach happened. What data was compromised? What happened afterwards? They tried to find the proper countermeasures. Then you have an additional fee for the administration and all of that, which is also something around 3,000. Then there is a fraudulent card use happening on that server, it’s something between £15 to £20 a case because this is a UK company, per card. So that’s also something that can explode in seconds. And after that, you need the final report and the post-mortem, and that is another £4,000 to £12,000. So, at the end, it’s super, super expensive. And I think it doesn’t weigh in any kind of money, you have to spend upfront to keep your Magento 1 store secure.
Rico: That was a very interesting question, which is still here in the Q&A. Can the site really be fully secure if it’s on end of life software? The question is, can a site really be fully secure if it’s not end of life software? Because what means fully secure? I mean, even Magento 1 and Magento 2, and other software as well has a lot of bugs. And it’s just the question when a hacker just finds a way to combine vectors to create an issue here, to create a vulnerability or an exploit.
Victor: The tangible costs, you have to think beyond that, even if a store front were to be transparent, disclosed to customers about potential data that was exposed or wasn’t and all that. What business are you losing because maybe the next time you have someone looking to purchase from you doesn’t fully rely that your systems are proper for their purchase. So there are just these residual, like butterfly effects that happen where you have these upfront costs, but you just you never know what impact long term, a quarter out, a full calendar year out can be, impacting you fiscally at that point.
Lewis: Yeah, we have some very strict rules in the UK as well around GDPR. In terms of leaking customer data and things like that as well, which can add up to a huge fine. It has caused a lot of fun in the UK in terms of our methods for everything, all very interesting.
There’s a lot of talk at the moment around Visa and PayPal, whether they’ll support Magento 1 moving forward. Can any of the panellists, shed any light on this?
Rico: We recently noticed I know, let me just check Twitter again, because it was when I was heading to the office here for the meeting. MasterCard recently said that it’s not OK to have a Magento 1 store without compensating controls, which means it’s OK to have that store with compensating controls. So, if you have all the counter measures in place, you can run your Magento 1 store just fine and you are PCI compliant. So all that fuss around that from various payment service providers in the last couple of weeks is just useless because it always circles around the 6.2 part of the PCI DSS which says you need vendor supply patches, but it’s not defined what a vendor is. And in that case, it cannot be that the original creator of the software, because this was the company, Varien, which has been transformed to Magento and which has been sold multiple times. So now Magento as a trademark and the software has been sold to Adobe ultimately. So, in that strictly view of this PCI DSS point of view, it’s not even the vendor, if it’s Adobe. So, in that case, if you have a company, that sole purpose is making sure that Magento 1 is secure, then you have proper compensating control. And this is what we try to explain to everyone since years.
And the very interesting thing is that MasterCard now turns here to the public with this on LinkedIn – I can share the link once I’m done here. And that we have not been able to get in touch with PayPal and Visa here and it’s very interesting to see that it’s actually, it’s just PayPal freaking out the merchants here with this. I think it was a month ago when they said, “OK, we have an issue here, and if you are running Magento 1 you probably fall out of…” And that didn’t even say that you fall out of PCI compliance, it’s just if you have nothing in place. So basically, what they said is if you have something in place, we are fine, and we don’t punish you for that and we don’t stop servicing you. But it all happened in the brain of the merchant once they read the email, so it’s just threatening people. And it’s very interesting to see that a large company like MasterCard turns in and says, OK, we’re fine with that. I’m pretty interested to see what Visa and PayPal is doing, though.
Lewis: So, this kind of flows quite nicely into the next question:
Can merchants stay PCI DSS compliant past the end of June 2020 on Magento 1? And if so, how do they achieve this?
And then it goes into another question, that has just been asked on the Q&A panel from Laura which was:
What type of compensating controls are required?
So, we’ll pass that back to Rico first and then everyone else jump in.
Rico: I mean, PCI compliance is not just having patches for Magento. If it would be that, then a lot of merchants would have fallen out of PCI compliance for a lot of software, not just Magento 1 but also Magento 2. I mean 2.1, 2.2, they are also EOL since a few months and people are still using it and no one cares about that. I never heard a representative saying, “hey, you’re using Magento 2.2, I’m very sorry but we have a problem here.” So, in that case, it’s a bunch of things you have to do.
For example, you can scan from eComscan from Willem to make sure that you monitor the software on your server and see whether there is a breach or if you have outdated software or if there are any known vulnerabilities. You need something like a WAF like Sucuri here or CloudFlare. You might have the supply chain checks as well from several, you might have someone who takes care of your PCI compliance from the server software perspective, like PHP, the operating system software and so on, like Foregenix.
So, there are a lot of people out there who have solutions for that and if you have those countermeasures aside, as Willem already said, you need good passwords. You need people or you only have to give them restricted access to the back end. If you have someone who works with products, make sure that they only have access to the products section and not to the full company data, everything that is stored in the Magento 1 or in any kind of software. So, there are a lot of things in that you have to have in place. And then a PCI assessor, which can say thumbs up, I’m happy with that, just continue, we’re fine.
Lewis: Yeah, I think you’ve got a really good point there just around doing a bit of audit control on what users have access to within Magento. Quite frequently, we’ll see people who just mark everyone as administrator and obviously, you have leavers and new starters within a business all the time and some of those accounts may stay active for a long period of time and they need shutting down. So that’s a very good point that people can take note of on that side. Has anyone else got any kind of points to feed into the PCI discussion?
Victor: I think that visibility, I think to me is the most important thing, I think over the years. I think, as Rico was alluding to, it’s something that people often forget or don’t realise that a firewall of some form or some control of access control, whether you implement that DIY and you know your area can deny all or only allow from certain IP perspective. What type of visibility do you have over the people who have access? What access do they have? Are you disabling unnecessary services within your environment that you’ll never use so that nobody can inadvertently just sort of stumble under an either pose a risk or maliciously? You don’t want a previous employee who may be disgruntled coming back in if you didn’t quickly ensure their access was revoked.
You know, there are a lot of different circumstances, we both think like attacks often happen from that guy in the basement, you know, running that crime job against a list of domains. Or they can be people who’ve worked and who are disgruntled who you provided access to. If you’ve hired a third party developer to work and things didn’t work as well as the webmaster, as the site owner, you want to ensure that, you know immediately that you have removed that access and not make sure where else could this person have an impact on my site.
So just having a type of change management or inventory management is really critical and I think people need to really understand that it’s not so much about what you do specifically on patching and all that. You also need to know about what you have at all times. That always gets most people. They never realise about these extensions of modules that completely forgot about or these users that were created that had administrative access, that haven’t had a need to have that type of access in 18 months that often ends up being the biggest thing to try to help educate all of our customers.
Lewis: Yeah, I think we also see as well, the hosting partner that you choose to go with can make a massive difference to your security. We’ve got a lot of companies in the UK that aren’t necessarily geared up to host Magento sites and depending on the partner that you choose to go with, they can actually make your life, well, they can make your experience and your risk a lot lower.
So, companies like Sonassi in the UK, MageMojo in the US. I think we’ve got Eric and Peter and possibly Ben from MageMojo and Sonassi on the chat at the moment. Those are hosting partners that we’ve worked with previously and had great experiences with. It definitely gives merchants the ability to lock down their admin panel easily on that side and also provide some level of scanning tool – it just helps us to secure those stores as well. And kind of first level WAF protection that can be enhanced with the likes of Sucuri and additional scanning tools such as Sansec.
So next question is another kind of PCI question, which has probably being answered in a roundabout way. Requirement six of the PCI guidelines, you’re probably sick of those questions Rico. Requirement six of the PCI DSS compliance documentation states that you must develop and maintain secure systems and applications by installing applicable vendor supplied security patches. So, in the event of a breach, merchants will no longer meet the qualifying criteria for a full investigation, which I think based on kind of what Rico has said previously, you might still qualify for that area based on ticking various boxes.
Have any of you had any hands-on experience with PFI investigations and do you know the cost associated with these?
I think Rico just mentioned then the cost for a PFI full investigation was between was it £5,000 and £10,000?
Rico: This is just investigation. But in total, with all the other things, you end up with something between £15,000 and £30,000.
Lewis: And then for a light investigation, would merchants be looking at similar cost?
Willem: £2,000 to £3,000 for light.
Lewis: So, £3,000 for a scan, and then any penalties on top for cards that were compromised on that side?
Willem: Yeah, may I elaborate a bit because I was involved with quite a few PFI investigations and they’re not always as harsh as it may sound right now.
The usual procedure is they will ask you to conduct an investigation on your first breach and for that investigation. It’s perfectly fine to have your own development team perform it and if your report is sufficiently adequate and the conclusion to convince them that you have found the cause and it will not happen again, you may get away without a fine and without a full PFI investigation. However, if it happens a second time, or if you write a poor report, you are liable for a very costly investigation afterwards.
On the other hand, you may have bad luck because we have seen also cases where, for example, merchants had offloaded their full payments flow to a payment processor. So technically, they would not have to qualify for PCI compliance, for example, in the Netherlands, that is the case. Still, one merchant that got hacked, got an enormous fine because criminals injected the fake payments form on their site so customers would enter a credit card while this specific merchant didn’t even accept credit cards normally. But it was a fake credit card acceptance forum that was there for two, three weeks and then his payment processor charged him anyway. So, you really should look up the contract details with your payment processor to see where your liabilities are.
Lewis: Excellent advice. So, yeah, next question for everyone.
Can you explain how your services work and in terms of what would be needed to onboard you and what the process is and how it actually works and what your kind of price range is for merchants who are listening in?
Victor: Yes, I’ll hop onto that one first if that’s all right then. So, we provide three areas of security for merchants that require the service. The first is visibility through monitoring, which is primarily remote based. You know, we don’t have anything that would impart some type of employee installation or anything like that. So, we check for malware, you know, software checks, I think a lot of things we’ve been touching on to this point. Of course, in the event that you are facing an existing crisis, you know, some type of incident or hack, we do offer remediation services that are available 24/7. So, if you did need to get that cleaned up and of course, the list of files and directories impacted by that, compromised for those types of investigations, we have a group that’s available for that. And of course, at that point, the only thing we need is direct file access.
The big thing, though, is protection. And we use the cloud-based firewall, which is a record change on our side. I know that cloud was mentioned at a similar cloud type solution, in essence, in which we also have a CDN. But the primary thing is the firewall will help, of course, place a layer in front of your sites and should any requests that come through are either properly blocked if they’re known to be malicious or seemingly suspicious based on our both signature and behavioural based approach.
And, you know, there are a lot of things in terms of onboarding, that is more about fine tuning. If you want to restrict country, you know, like, say, access from certain regions in the world, that you’re not anticipating any type of eCommerce audience from. Suppose you’re in Europe, or a Europe based travel agency, let’s say, and you have a number of things on your site you won’t be purchasing and you are only specifically looking for a particular audience, you guys are blocking out certain areas of the world you don’t want that traffic from. But in reality, that’s just in the scope of everything. We virtually patch with a research group that works daily to uncover new vulnerabilities, whether it’s the tactics against specific modules or the cause themselves or, you know, a lot of times we end up seeing, you know, cross types of attack vectors that impact both – that’s in Magento and WordPress instance, the event that some merchants may be utilising something different as well.
So, it’s more or less essentially how we work. Cost wise a few hundred dollars, a few hundred U.S. dollars, depending on the number of, let’s say, domains in your inventory in that sense. But in reality, the one thing to keep in mind is of course that there is a lot of time saved in not having to, like, consistently look for new vulnerabilities, especially those that may stay on Magento 1. That’s something we take full responsibility for, for our customers.
We have some different plans that, depending on the exact nature of how large your inventory is, is in terms of how large your marketplace presence is but, you know, for a store, for a single store you’re looking at a few hundred U.S. for the full year.
Lewis: Well, thank you. Willem we’ll pass to you next.
Willem: Thanks. So, our product, eComScan, is specially made for Magento stores and we would like to describe it as a smart CCTV for your Magento store. It will monitor your store for malicious activity, and it will also alert you whenever there is an open window that criminals could use to gain access to your store. It does not only scan the core of Magento but also all of your third-party components which as I said, are responsible for more than half of all compromises.
And in the key, there is feasibility. We believe that you should have feasibility in your security risks in order to mitigate them. We do not do batching or life protection because we believe that if there is a vulnerability that exists in your store, you should fix it on a functional level. You should apply better or you should remove the cause of the security issue at the root to make your store secure. Our product is priced at 50 to 500 euros per month, depending on the store size and the functionality that you require. And at the moment, we have it installed on a bit more than 6000 Magento stores globally.
Lewis: Brilliant, thank you. And Rico, over to you.
Rico: So yes, as I already said it’s a bit harder for us, so we don’t have that price. It’s starting from $29 depending on the revenue, so if price lists, we can see all the different steps. So, it’s about 50 or 60 steps. So just look what you have as a total revenue based on your online shop conversion and basically that defines your annual contract and monthly rate.
So, what Willem said, and Victor already mentioned because basically that’s Victor’s business. A WAF is a very important step. But to really fix the issue, you have to change the core code. And this is what we want to do as well. So what we saw is that a lot of smaller merchants which are now aware of security, as initially said, I don’t know whether they can’t afford or if they probably don’t want to afford a full bandwidth of different security measures.
So, we saw that WAF is as a very important thing here for the first mitigation. And that’s why we have something that was called QPS. And QPS is a little feature that you can but you don’t have to install in Magento, which kind of mimics a WAF within Magento. So, the requests still reach Magento, but on the early stage, we have a rule based approach to figure out whether the request should be voided or not. So, we do not recommend that to merchants that already have a real WAF in place, which is much more powerful, has a lot of additional features that we cannot do within our Magento module. But for the smallest merchants, this is something that might help them to stop requests once the patch is done, then they are secure.
But if the security vulnerabilities are already exploitable in the wild and we tried to fix, in air quotes, we try to fix that by applying a rule that avoids those requests and stops them from being processed in Magento. So, you have at least some kind of WAF feature within Magento for smaller merchants as well. But still, as Willem said, it’s really doesn’t help at all, so you really have to rip out the issue at the root and that only works if you patch the core.
Lewis: Just to clarify for everyone, Mage One’s offering is you supply the patches and a development agency or in-house developer would apply that particular patch. You don’t apply or offer any kind of development.
Rico: So that just doesn’t work to work for one hundred thousand clients across the globe, we would have to have a team which is insanely huge. And that just doesn’t work. So, we just provide the patches, as Adobe did. And then you have to have an internal development team or an agency or a freelance developer or whatever, and they will then take care of installing that because you usually have some kind of customisation. And as Willem already said, a lot of breaches happened because of third party code and not core code. And this is why the third party in our case is the agency or the freelance developer or whatever. And they have to look with the customisations, extending the Magento core function that has been patched. And probably they have to patch the third-party software as well, because it just uses Magento code, which has been copied, which happens a lot. And this is a very important approach here for us not to patch the systems directly because we have no idea what kind of customisation has been made. But the agency is pretty aware of the instalment here, and they are also happy to continue to work for their merchants.
Lewis: Thank you. And our final question before we go into the Q&A section:
What would your advice be to Magento 1 merchants who don’t have a plan to move to Magento 2 at present?
Rico: So if I just answer that directly, I would say whatever you do, try to figure out a way to upgrade, at least to the latest version with the latest patch that has been provided by Adobe to make sure that you are secure, at least on that point of view.
And if you really don’t want or cannot spend money on your Magento 1 security, look for solutions somewhere in the internet where you, I mean, the community is huge, and the community is very highly skilled. So, there are a lot of great people providing solutions for issues also for free. And at least you should do that.
In any other case, I think best choice, an agency. They look into the different steps you have to take to be PCI compliant or to at least surpass a PCI certification. Go through that and make sure that you have for every step that has been written on this list, that you have something in place, that you have someone in your company that is responsible and knows about the technology, that you make sure that only people have all the stuff that we just talked about. So at least do that.
Victor: And just the only thing I would add on, is for those that aren’t sure about whom or how to make to get those pieces done, which I would echo what Rico said, is to find a PCI assessor who can help you understand what those compensator controls will look like so you know where to go.
Willem: I would say, first of all, don’t panic. For my Magento 1 store, I would first of all, I would get visibility into the current risks and future risks by using a monitoring solution, either ours or Sucuri’s. And second, I would ensure future batches to get a contract with Mage One. If you have a very experienced developer on site, you could go with an open source solution. But I think it’s better to get a commercial contract. You know what the risks are, you can implement mitigations. I would not lose a night’s sleep over it.
Lewis: Good advice. Thank you very much. So, we’ll move on to the questions that we’ve had through. So, I think a couple of these have been answered already, but I’ll just run through them quickly just in case anyone doesn’t have visibility on it. So, John asked:
How would I know if my Magento 1 site was hacked?
And I’ll pass it on to Willem to answer that.
Willem: Yeah, most merchants discover because they get a very angry note from their payment processor. However, that usually only happens weeks or even months after. So, if you can, you should be able to get knowledge beforehand.
The most common indicator of a hack is the presence of unauthorised code, either in the front end or in the back end or even in the database. Now it takes a very experienced developer to notice such unauthorised additions. And not all of your assets are in version control, for example, I doubt that you have database triggers in your version management system. So, either it takes a very experienced developer, or you should automate this procedure, and that’s why you need monitoring software to see what’s going on.
Lewis: Thank you very much. Laura’s asked:
Do you have any recommendations for PCI scanning companies?
I think Rico’s picked this one up.
Rico: Yes, I already mentioned Mage One partnered up with Foregenix. It’s a UK based company and they’re specifically built about all this PFI and PCI ideas and stuff. So, they also have a scanning solution in place. And the most interesting part, I think, of their service is that they have a kind of an insurance coverage whatsoever thing so if you have a contract with them based on the contract level, you have up to £50,000 for a PCI incident, which you can use for the fees and for the fines and the case, it might really help if you have an ongoing PCI scanning solution here.
Lewis: Yeah, we’ve worked with Foregenix previously, and that service is really good on their side, so we would definitely vouch for them as well. Deborah’s asked:
How can the hosting partners help with PCI compliance?
Rico: Upgrade their software, I think. That’s the most important thing. I usually see that you get emails from hosting companies saying, we now have the paid version of the extended support for PHP 5.4. Do you mind switching to PHP 7? I mean, to be honest, PHP 7.2 is EOL in November, if I’m not wrong. So, you really have to keep up there and especially here with Mage One, we notice a lot of hosting companies that are really behind security on their systems.
And I think you should make sure that you have a hosting company that is aware of security and really cares about that and also publicly talks about that. And they are also eager to help you with keeping a software up to date. Some of them, I think Nexcess and Webscale are two hosting companies that have patching services in place, for example. So, in that case, you can get patches from them. Webscale are partners of us, so in that case, there hosting customers get access to Mage One patches. Nexis, I think with a safe harbour, uses OpenMage and their internal development team to cater patches there. So, these are options that emerging use here.
Lewis: Thank you. Peter has asked,
How safe are merchants that are using payment gateways through an iframe, and does this offer a higher level of protection?
I think this one’s probably a good one for either Willem or Victor.
Victor: I think from an iframe perspective, I mean, if you’re embedding something like PayPal within the iframe, you know, from a risk standpoint, it’s fine. I think a lot of the issues that we’ve seen with people, it is often like you may have the sites, you may present itself and serves it over HTTP. But the iframe is actually HTTPS, which is what you want. But in reality, you don’t want the perception that you’re going in there to a site that’s not displaying that padlock and showing it properly, protecting your data, encrypting it, even though the iframe and maybe redirecting to PayPal or whatever else you need to make sure that you also have, even though, let’s say the site itself is not taking data or information, you still need that properly structured HTTPS because from a customer standpoint of a number of other things. But you just don’t want that perception that says “hey, I’m loading up some payment gateway in iframe that’s used to collect my data. But the site I’m navigating is running on HTTP” – that would seem strange.
And then, among other things, I also just want to make sure that you do have those types of like cross eyed scripting potential impacts, so you are not going to have the protections against scripting. So, if you direct the traffic and said somewhere else, you’d want to make sure you’re protected against threats like that.
Lewis: Willem, anything to add to that side?
Willem: Yeah. iframes are a technical solution for a whole load of technical risks and pretty good at that. However, once somebody has control over your payment flow, he or she can inject anything she wants. So, as I elaborated before, they can inject a fake payment form before that which would say, well, a fake payment form, you will discover it is instantly. But in most cases, this fake payment form stayed on the side for a far two to three weeks before it was discovered, even though customers entered the payment information twice because they used to fake form. Then click submit that goes to the criminal and they see an error which says oh please enter again, something went wrong. And surprisingly, a lot of people just think that’s OK and will not notify the merchants. So, using an iframe is good. You should do it, but you still need to make sure that nobody has access to your site in the first place.
Lewis: Thank you. And then next one is Gareth, who has asked:
What steps should third party extension developers be taking if they want to continue supporting, if they want to continue to support Magento 1?
Rico: Well, I think mostly here they have to make sure that there are compatible to Mage One and OpenMage. The difficulty with OpenMage is that it’s basically for Magento 1. They diverged from Magento 1 a few years ago, and they are including new features as well. They’re also fixing Magento core that have nothing to do with this security, just like a function box, UI box, whatever. In that case, at some point, OpenMage might be a slightly different product than the regular Magento 1 is, so in that case it might be more difficult for extension developers to keep up with both of the projects.
And on the other hand, I mean, yeah, I think that that’s the most important thing they have to make sure that they still use a skilled developer. I usually see a lot of Magento 1 extensions that are poorly written. So, it’s some kind of automatic ported code from other systems and it’s not really using the things that Magento provides them. Which also opens up a lot of issues which might lead to security vulnerabilities as well. So, it’s something that is a matter of skills by the developers and for sure, they look into security. Have a security specialist on their team that might help as well. I mean, they can have penetration tests with their software as well. I have no idea how many essential developers and companies in this fields have penetration tests for the extension code.
Lewis: And do you, out of interest, know if all the kind of core, third-party extension providers, so I guess Aheadworks and XTENTO and people like that, does anyone know if they’re continuing to support the Magento 1 extensions?
Rico: They do, yes. Yes. Most of them also partnered with Mage One.
Lewis: Thank you. And then final question. I think that we’ve got is from Laura, who’s asked:
Is implementing a content security policy doable on Magento 1 due to all of the online scripts? And is this something that can be considered compensating control?
Rico: This is a bit above my head, so it’s just hard to decide that, Willem that’s probably yours.
Willem: Yeah, I know some companies who have done so, so it’s definitely possible. However, as these recent Google Analytics attack shows, it’s really hard to do right. And I did a quick check on a portion of sites globally that have properly installed CSP policy and it was less than 0.001 percent. So, again, it is possible, but technically, the only secure way is to use nonces and hashes for all the assets that you include use a strict dynamic policy. However, this is huge overheads on your marketing team because they will need to verify all of the assets that you would include. So, in practice, I wouldn’t do it and I would have focused my resources on the other risks and mitigations.
Thank you
Lewis: Brilliant. Thank you very much. So, I think that kind of rounds up all of the questions that we’ve had today. So, thanks again Willem, Victor and Rico for joining us. Hopefully, everyone who’s joined us found that really helpful. And we’ve got some we’ve got a short feedback survey that will load up when you leave tonight’s event if you can fill that in, that would be very much appreciated.
And we’ll be sending around an email shortly after the event just with the details in for Sansec, Sucuri and Mage One, just in case anyone on here is interested in finding out more information. But if anyone has any questions or wants to reach out for any reason please feel free to get in touch with us. Thanks again for joining. And I don’t know about everyone else, but it is absolutely baking here at the moment so I’m looking forward to going outside for a bit of fresh air. Have a good evening everyone and thanks again.
Share
