I received an email notification that one of my customers had a virus, and was shocked to find another 9 USERS on the circulation list.
I checked my dashboard, and found 9 uninvited Comodo staff had added themselves, without my knowledge or approval.
Bypassing security and 2fa.
I raised a ticket, and was advised to “just delete them” .
That’s not the point !
Extremely unhappy.
These Comodo Support staff are using a “Comodo Support” role, which doesn’t exist in my dashboard. I have no idea what permissions they have, or what they can access.
Hi @originalscan,
Its not a security breach, please check our Product Manager Ilgaz reply for a similar post
As you know, SOCaaP is a Co-managed SOC platform, where our SOC agents help on managing alerts/incidents. Once you started using SOCaaP, our SOC agents need access to your account and that is why you see additional users with the “Comodo Support” role appeared on your portal.
If you wish, you can turn off remote access support from Management -> Account -> Remote Access Support
Kind Regards,
PremJK
This kind of alarmed us too when we first saw this and we sent in a query to support@ to confirm that this was indeed part of the SOCaaP platform changes that took place.
We also began seeing a lot of NDR back scatter on our email server since the Service Desk began sending ticket notifications to all those API token access accounts that are not actually real email addresses. Our solution was to create a department on our Service Desk called SOCaaP and place all of those staff members into that department so that our ticket system does not attempt to send them email notifications for the fairly routine number of tickets we get on a daily basis from our monitors. We don’t have an issue with the Comodo engineers having access. They always have anyhow most likely kind of like how we see Microsoft and Google executing Powershell scripts on people’s endpoints like they own the devices. They don’t own the devices, but they do own the software being used on those devices.
We are attempting to test SOCaaP now with a few of our own devices. Excited to see this option available in ITarian now.
When you get the chance , looking forward to some real world feedback from your testing.
So far I have waited a bit before jumping in as I have not been pushing until a touch more info was available, not so much the endpoints but the bolt on 365 integration vs what’s currently out there like MS ATP / Trend Micro Cloud etc, also the network protection does not have much detail in implementation or working with perhaps current boxes, sophos/barrcuda/forigate etc.
mcfproservices
Right now we are adding notifications and asking for permission regarding SOC access.
@mcfproservices , we support all network appliances like you said sophos, barracuda, fortigate etc. This comes with the sensor installation
SOCaaS is very interesting but as msp located in EU I wonder how all this, that is to allow access to a SOC agents, is seen by the GDPR compliance.
Yes this is valid concern for our EU MSPs, let me try to explain it
With SOCaaP, Like Itarian your data stays in EU, live there, processed there. So does this mean that nobody other than EU citizens can access the data? in fact that is not true
Chapter 5 of GDPR is titled “Transfers of personal data to third countries or international organizations” and consists of Articles 44 through 50. https://gdpr-info.eu/art-46-gdpr/ describes this case.
Summary is if you transfer EU personal data out of the EU, company needs to be sure that this data still protected with the same level of protection it gets under GDPR.
This is true with SOCaaP where our SOC teams in different countries should access the data. This requires us when that we access the data to outside the EU, it must be under a legally binding obligation to follow GDPR data protection principles or the equivalent. This is what Comodo commits to do, access and transfer is not permanent, no persistence and all regulated with our security controls.
However, there is also regulation about the country that has data protection laws that are just as strong as GDPR. US was not one of them but there had been a EU-US Privacy Shield framework in place to make GDPR compliance but this agreement ended in June 2020. At this stage, the main alternative for us to transfer data to the US is to use Standard Contractual Clauses (SCCs). It is non-negotiable legal contracts drawn up by Europe, and are used in other countries and as well as US based companies.
Our Data processing Addendum also follows the Standard Contract Clauses so SOC team access to your data will not violate GDPR.
