OPNsense Forum
English Forums => Zenarmor (Sensei) => Topic started by: firewall on May 25, 2021, 11:18:39 pm
-
Hi,
I poked around with Sensei when it was originally released for OPNsense. Cool product but I ended up uninstalling due to the closed source aspect of certain components.
In the time since, has anyone monitored WAN ingress/egress traffic of their Sensei installation to gauge frequency or (better yet) type of data being shared?
Thanks!
Edit: Subject revision to reflect change of product name. Concerns still not addressed 1 year after initial post.
-
Hi @firewall, thanks for bringing this up. I think we can also spare some time and help with such an effort.
[Disclaimer: I'm from the Sensei team]
-
I use sensei but dont monitor what it does. Its a very useful layer 7 filtering tool though.
-
I'm neither a security expert, nor a paranoid dabbler. So for me Sensei protection is optimal.
-
I use Sensei from the beginning (September 2018) and can't say a single bad word for anyone from the Sunnyvalley team. Worked mostly with Murat and Matt. If I don't trust them, who to trust then? Cisco? Fortinet? Sophos? Zyxel?
This is the best NGFW solution for me. Worldwide. Period.
-
I use Sensei from the beginning (September 2018) and can't say a single bad word for anyone from the Sunnyvalley team. Worked mostly with Murat and Matt. If I don't trust them, who to trust then? Cisco? Fortinet? Sophos? Zyxel?
This is the best NGFW solution for me. Worldwide. Period.
this isn't about individuals but i'm glad you've enjoyed your experience using their products. we clearly have different needs.
@mb any updates?
-
@Antaris, @almodovaris, @allebone, many thanks for your trust. This will only increase our commitment and responsibility.
@firewall, we understand your concern and totally respect the need for a double-check. If someone signs up for this, we'll be happy to spare time and help.
-
I'm not overly concerned with privacy, I just need something that works. My websurf data are boring rather than sensitive.
-
I mean: just by analyzing publicly available data you would have a better knowledge of what I do on the internet and what my views are than by merely analyzing my Sensei logs.
-
I use Linux, I use FreeBSD, I use Android, I use Windows, but I'm not scared that Microsoft or Google might know what I type.
-
I asked this question too, but then came to the conclusion that even if it was open source i personally would not be fully able to code review it and be 100% sure.
Then again, something like ubiquiti´s firewalls... can you really trust them any more than the sensei guys? *shurg*
-
Hi,
what would you trust then? Everything in your network stack can be flawed (regardless of the big brands or not).
How much do you value your privacy and information you store in your network? If the answer is 'most than everything' then unplug the cable connecting to the internet and enjoy a 'solo' experience.
Best wishes..
-
In summary: a handful of responses from people who "have nothing to hide" concerning data collection and privacy threats.
Great, you do you (https://en.wikipedia.org/wiki/Nothing_to_hide_argument).
As @mb seemed willing to cooperate when this topic was first posted, I'd like to circle back to the intent.
If the "Cloud Management Portal" is disabled via Zenarmor-Sensei configuration options, what data is sent to systems operated by or affiliated with Sunny Valley; be it during installation, post-deployment operation, or otherwise?
-
Hi,
After disabling the Cloud Portal, Zenarmor queries web traffic for Threat intel and sends the heartbeat. You can configure both on Configuration - Cloud threat Intel and Configuration - Updates & Health.
-
If privacy is such a concern to you then dont use sensei. I has to have some data collection to manage licensing, sync with the cloud portal etc. Thats a fact of life for commercial products. Dont use Azure, dont use O365, dont use AWS, dont use anything where some data has to be stored elsewhere. IE nothing useful since everything is using cloud these days. Good luck but you will find it impossible integrating useful products like this if you cannot have a single bit of your data leave your site. Simple fact of life. Ship has already ailed on this. No turning back now.
-
If privacy is such a concern to you then dont use sensei.
I'm not even sure the developers would agree with that position.
Thats a fact of life for commercial products.
Only it's not. There's no need or requirement to egress data from a user's machine or network beyond those imposed by software manufacturers. Not licensing, not usage or bug reports, nor data/metadata collected through the use of their products.
Dont use Azure, dont use O365, dont use AWS, dont use anything where some data has to be stored elsewhere.
Huh? Utilization of cloud-based products and services always requires deployment of local assets? You seem to be misunderstanding my use case. This has nothing to do with "data stored elsewhere", rather what that data is comprised of and for what purpose it was collected in the first place.
Not everyone's needs are the same and clearly ours are markedly different. Again, you do you.
-
I don't plead "I have nothing to hide" (e.g. my credit card number).
But I do plead that I don't bother that SunnyValley reads my websurfing data.
You should know that lack of privacy may also work to exonerate you of committing a crime.
If I want to do something that passes unseen through Zenarmor, I use VPN (e.g. Opera with VPN).
But no, as long as you use the internet you have no privacy, you're just fooling yourself that you have privacy.
And sometimes not using the internet does not protect you from data leaks from the government, or insurance companies, or hotel chains.
As the saying goes, Google knows a lot about you, even if you have never used it.
So, it is all a matter of trust: do you trust security professionals or do you trust the DD-WRT or Lineage OS approach (if it works, fine, if not, wait till someone bothers to address that bug).
-
Hi, a new OPNsense user here. I was about to setup Zenarmor onto my router, decided to do a quick lookup on the topic and found this thread.
It’s ceases to amaze me how little people are interested in how their data is treated. I totally agree with firewalls posts.
I’d love to hear info on what data is collected and is it in any way anonymized. I understand that some data collection may be needed in some cases, but the data can be handled in many ways. And when handled badly, it can get in to wrong hands. Why would I use OPNsense among other things in the first place if I wasn’t interested about my data..
Zenarmor seems to be a great product, but if I don’t know how it works, I’m not sure if I need it that much.
-
Listen, my calculation is this: I will stop paying for Kaspersky (my internet provider provides me with 20 licenses for F-Secure, branded with the name of the provider). So, I will be still covered in respect to using an antivirus, and I will pay two licenses for Zenarmor: one for my house and one for the house of my parents.
So, whether it's Kaspersky or Zenarmor who reads my data it is pretty much the same situation.
-
Hello,
I would also be interested in understanding the data that Zenarmor shares with Sunny Valley server/services and other third party.
I have been using the free version in passive mode, and I would consider purchasing a license and use it in active mode. However, I would like a clear understanding of what data is shared, how often, why and how it is affected by the different options available in the configuration.
After all, I consider Zenarmor as a shield against not only malware and other cyber threats but also against the data collection done by so many companies and actors online. So if Zenarmor itself does some data collection/sharing, transparency about what data is shared as well some control over it seems pretty important.
@mb, I notice links to "View Privacy Policy" on most configuration page, but neither the privacy policy page or the documentation details the data collected by zenarmor and how to control it. (for example, when "Cloud Threat Intel" is enabled, does zenarmor shares any of my data with Sunny Valley or other third party ?, or when enabling "health check" ?). Would it be possible to get more information about that ? Thanks.
-
I might be missing something in this thread and not going to get caught up in the argument. But you can view their privacy policy here https://www.sunnyvalley.io/legal/privacy-policy (https://www.sunnyvalley.io/legal/privacy-policy). This will detail what they collect and how they use it. Read through this and you can make your decision if you are comfortable with the policy or not.
-
The privacy policies here https://www.sunnyvalley.io/legal/privacy-policy do give some information, but not enough details to build the trust that I would think a lot of users are looking for.
A lot of people implementing such solution (including me) are usually looking for both security and privacy (data security/privacy). Ideally, once such solution is implemented, it would not "leak" any kind of data at all.
While this is very difficult (but not impossible), I can understand that some data has to be shared for certain features.
In that case, I would like to have details and information about the exact type of data that is being shared, for how long and what controls I have over it.
It seems that some pieces are here (some in privacy policy, some in the doc (https://www.sunnyvalley.io/docs/opnsense/installing/web-ui-initial-configuration#5--cloud-reputation)), but it is not clearly spelled out and it feels like some features that "may" be sharing data are not identified as such.
We learn from sy that 2 features that send data out there can be disabled in configuration.
After disabling the Cloud Portal, Zenarmor queries web traffic for Threat intel and sends the heartbeat. You can configure both on Configuration - Cloud threat Intel and Configuration - Updates & Health.
While the configuration for Cloud Threat Intel was indicated in the documentation, I did not know that the heartbeat was actually also sending data out to Sunny Valley.
It would help building trust if it was clearly spelled out that those 2 features are sending data out (and what data exactly) and that you can disable them if you do not want your data to be shared (directly in the web ui - there's this little "i" icon to put descriptions and details for the different options/parameters).
It also makes me wonder if there could be other features/parts of zenarmor that may also be sharing data without my awareness ?
At the end of the day, once data has been shared, it is out of your control (unless you're being granted some control over that shared data) and trust is the only thing left.
For me, it requires more transparency and details to get that trust. It may also require giving more control over the shared data to the owner of said data.
So in the current state, there is not enough details, transparency and controls for me to trust and be comfortable enough to use zenarmor.
As said before, I have been considering purchasing a subscription (which requires sharing more information), because zenarmor does a good job at integration (with OPNSense), and detecting and blocking threats. But It lacks on the data privacy and controls side.
I do hope though that things will evolve on that side (more details and transparency in both documentation and product about what is shared and more control over what is shared) so that I can build that trust.
-
Hi @Styx13,
Thanks for sharing your concerns and suggestions. Very much appreciated and understood.
We've spent almost a year on both the technical and regulation (GDPR, California Consumer Privacy etc.) side of things to align industry best practices and our beloved users' expectations with our infrastructure.
Having said that, we'll go ahead and prepare a document which will provide detailed technical information and guidance on this topic.
We plan to make it available along with 1.11 Release and will update the thread once it's ready.
-
Hi mb,
I would like to draw your attention to the quote from the SUNNY VALLEY CYBER SECURITY INC. PRIVACY POLICY
https://www.sunnyvalley.io/legal/privacy-policy (https://www.sunnyvalley.io/legal/privacy-policy)
"…persistent identifiers that can be used to identify a user over time across different websites or other online services, purchase information, photographs, video or audio files, and other personal information"
As someone who has been collecting information for a government agency for decades I am very curious to know why you need this information?
-
@mb,
Thank you for your reply and I am happy to hear that you plan to get better documentation regarding the data that's being shared/collected.
I look forward to see and check it.
I also hope for "better" (or more) control over the shared/collected data.
If you are interested in ways to better explain and let the end user control how the data is shared and collected, I would gladly share my ideas.
-
Hi @Pitango, for the sake of clarification: were you referring to "other personal information" clause?
Hi @Styx13, my pleasure. And I'll be happy to listen to your ideas. I'll be contacting you with a PM.
-
Having said that, we'll go ahead and prepare a document which will provide detailed technical information and guidance on this topic.
We plan to make it available along with 1.11 Release and will update the thread once it's ready.
Hello @mb, was this document made available in parallel to the 1.11 Release, as described above? Perhaps I've missed something in the Release Notes?
https://www.sunnyvalley.io/docs/support/release-notes#111----march-31-2022 (https://www.sunnyvalley.io/docs/support/release-notes#111----march-31-2022)
-
Hi @firewall,
Thanks for the follow-up. We've discussed this with the team and decided that the best way to go would be to provide our users with a "Privacy Check Tool".
This way, any updates on the software could also be reflected through the Privacy Check Tool in parallel and without any delay.
This is already in the making and planned to ship with the next major release.
Please see the attached picture (from our Project Mgmt Tool) for the details.
-
Sorry to bring back the dead here, but i happend to stumble accross this. Jumping down the mans throat for being concerned of his right to privacy grinds my geers enough to post. I have nothing negative to say about sensei or zenarmor, but just riding a brand and keeping with an attitude of screw it is idiot and lazy. Asked and answered as far this goes so I would just like to leave you with a quote. Also, while i'm here, to the opnsense team, great job. Since coming from pfsense i couldnt be happier, ill be looking at spending some cash as a thanks soon.
"Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say."
-
Hi @sghost,
Thanks for sharing your thoughts. Much appreciated. Your point is well taken and we completely share your point of view.
Taking the chance I want to share Sunny Valley Networks' official stance on Privacy and provide an update on what we've been doing in this regard.
We've spent almost a year on both the technical and regulation (GDPR, California Consumer Privacy etc.) side of things to align industry best practices and our users' expectations with our infrastructure.
Reading our beloved users' feedback afterwards, it became apparent that we also needed to provide "detailed technical information" on what data we're collecting; for what purposes and how our users can manage zenarmor settings to control their data sharing status.
The first idea was adding these information to legal documents; but managing technical detail in legal documents appeared to be more challenging than we originally thought.
After doing an extensive research for industry best practices; It looks like the best method will be providing our users with a dedicated 'Privacy Settings Menu' where we can disclose which information you're sharing, the reasoning behind this and a quick on/off button to disable/enable related functionality so that you can easily control your Privacy posture.
This functionality will ship with the upcoming Zenarmor release 1.12. I'm attaching the screenshot of the aforementioned Privacy menu.
It's a cliche; but I'll have to say it anyhow just to express our stance: your privacy is utmost important to us. The product has been designed, from ground-zero, keeping this in mind. OPNsense user community is highly privacy-conscious. Working with such a community helped very much as well.
I guess we're the only product offering a Cloud Management capability and at the same time offering the option to store reporting data locally on the user's premises. We store only what is necessary to store in the Cloud. All cloud communications can be monitored through zenarmor agent's cloud agent logs. You'll notice that apart from the connection keep-alives; there'll be no messages going back / forth unless you're signed-on to the Cloud Interface and interacting with the related menus. From a product development perspective, this kind of approach brings with it a lot of challenges. However, we believe this is the right approach.
Our intent is to provide a privacy-safe and secure environment to our users. If the 'practice' does not align with this 'intent', please be noted that it is unintentional and we're all open to constructive suggestions like the ones in this thread and more than eager to revise our processes, products and services.
In that regard, we've already reached out to several forum users who shared their suggestions. Some of them were kind enough to contribute further ideas which eventually helped create our current approach.
Apart from that, I'd like to also re-iterate that we're open to helping people who might want to conduct an independent analysis of the privacy situation of the product. Please feel free to reach out to privacy - at - sunnyvalley.io . Your suggestions and ideas are always welcome.
Thank you
-
Concerning the data flow for
"Send Heartbeat: Every Zenarmor installation sends heartbeat information 3-8 times a day.
Heartbeat is a required functionality for the correct operation of the software and cannot be disabled.
The information shared in a heartbeat message is unique node identifier, IP address, Zenarmor software versions, platform version info, important Zenarmor configuration parameters, and Subscription related information like active subscription plan and number of devices in use."
and the error message
"Heartbeat is a required functionality for the correct operation of the software and cannot be disabled."
In my opinion, Sunnyvalley should check the position of the data protection supervisory authorities https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22019-processing-personal-data-under-article-61b_en, in particular page 14 (section 3.1).
-
Thanks @jf2001j, looking into that.
-
The only problem is if you tie such data to a person. If it is anonymised, it is not a privacy matter.
-
The only problem is if you tie such data to a person. If it is anonymised, it is not a privacy matter.
But it is. The effectiveness of security measures changes over time and attacks only ever get better. What was thought to be effective anonymisation today may turn out to be not-so-effective tomorrow, perhaps because someone has been very clever in their analysis of the metadata, or because an attack was made on the data in transit to anonymisation, or because mission-creep has introduced additional metadata that allows more dots to be joined. Security and privacy are an ongoing concern.
-
Suppose you have a schools community with 10 schools at different locations, with more than 1000 persons. It is not prohibited to tie the data to a location, it is prohibited to tie the data to individual persons.
-
Suppose you have a schools community with 10 schools at different locations, with more than 1000 persons. It is not prohibited to tie the data to a location, it is prohibited to tie the data to individual persons.
Which highlights the sort of assumption that gets people into trouble. If data collection assumes that linking data to a location is safe then it may tie data to individuals in homes, small business, or people working late or on weekends.
More obscure issues arise when product X identifies data by location and so does product Y, and if an attacker has access to supposedly anonymised data from both it can link the locations and draw conclusions not available otherwise. If you follow the various security blogs you can read about researchers identifying individuals by linking several supposedly anonymous data sources.
Of course services may need to collect some data, but the security and privacy issues are not simple, and they are ongoing.
-
The only problem is if you tie such data to a person. If it is anonymised, it is not a privacy matter.
I think that is not correct. The procedure is basically subject to the GDPR regardless of any subsequent "processing" on the server. Already the "collection" from the firewall (always with IP address, but according to text at Heartbeat also with "unique node identifier").
In addition, one must also see the legal regime separate from the GDPR, Article 5 Section 3 EU Directive 2002/58 (as amended in 2009), which regarding the "storage" and "readout" of information (regardless of the personal reference!) sees strict interpretations regarding "absolute necessity" and "expressly desired by the user".
Back to the personal reference of the GDPR:
There have been several ECJ rulings on personal reference (e.g. via IP address; like C-582/14), i.e. when there is basically the possibility of identification.
Arguments:- Here one must see the IP address of the firewall.
- Also, a static/long-lived identifier (as in Heartbeat: "unique node identifier") is explicitly listed in Art. 4 paragraph as "identification number".
- In addition, a fingerprint could already be created via the interaction of the information transmitted during the "Heartbeat" event, which would make recognition possible.
In my view, there is no legal basis for "Heartbeat".
- There is no "necessity" for a contractual basis (6.1.b GDPR) (the Zenarmor firewall functions also work without notification that an instance is online; of course, cloud management does not work, but that is already optional). The supervisory authorities have a strict understanding of the "core" of the contract.
- Likewise, consent (6.1.a GDPR) lacks "voluntariness" (7.4 GDPR).
- "Legitimate interest" would be conceivable (6.1.f GDPR), but then it is irritating why a non-selectable checkbox (sounds like "opt-out") is offered. Also, I wonder what the "usual expectations" of the user are.
For legitimate interests - cf. https://www.sunnyvalley.io/docs/opnsense/configuring/configuring-zenarmor-privacy-settings-on-opnsense-firewall#heartbeat-and-license-check :
- There is reference to "license verification". But with the free license, this is not necessary.
- Regarding "checks the state of packet processing worker" this is possibly a legitimate interest (low hurdles here), but in a weighing with the interests of the user I consider it very low and against it the interests of the user predominant.
(Example: what does it help the user if the manufacturer finds out that his installation with free firewall license does not work anymore? There is no automatic help from the manufacturer).
It might be the case - this is pure speculation - that the manufacturer wants to know about the number of running installations, but this potential "legitimate interests" of him is not listed (to my understanding) in the description of "Heartbeat". It would be preferable for the user if the manufacturer would allow a non-compulsory opt-out for the user (beside Art. 21 GDPR "on grounds relating to his or her particular situation"). Also I think the interests of the user are also predominant here.
I hope the manufacturer will check the current implementation.
-
Any update on this? Seems the last comment could use a reply, especially since there were good replies to the rest (which is very commendable btw.)
-
Hi @jf2001j, @TheForumTroll,
Thank you for sharing your feedback related to the Heartbeat.
We appreciate your feedback. As shared previously, we believe we are lucky to be serving a technically sophisticated and privacy-conscious user community.
Indeed, this is helping us very much in our quest to provide a great security product without sacrificing the privacy of our users. Compliance with applicable regulations, including CCPA and the General Data Protection Regulation (GDPR), is of utmost importance to us.
@jf2001j, as you correctly pointed out, there are several other technical points where heartbeat messages are helping us to improve the quality of the software:
The information about the number of unique installations provide us insights on several key performance metrics:
- Pro-active detection of software problems: After every release, an unexpected drop in the number of deployments generally signals us that there might be a software problem affecting some of our users, which allows us to act proactively and start a remediation process without any delay which might impact an even greater number of users.
- Ability to understand how new capabilities shipped with a new release is perceived by our users: We are able to assess this from an increase in the rate of new deployments after a software release.
- Understanding how the software is performing on a newly introduced vs existing platforms: The platform information in the heartbeat provides us this information.
- Understanding which releases are being used and on which platforms & versions: so that we can decide safe EOL dates for supporting individual platforms and releases
- Understanding which platforms Zenarmor is being deployed on, helps us focus our porting and integration efforts.
Also, the number of unique installations information allows us to provide this KPI to our investors so that they have an understanding of how the software is perceived in the field. This is one of the reasons with which we can justify a free tier in the eyes of our investors.
We take it as homework to add this information to the help section of the Heartbeat selection.
Regarding whether IP addresses and similar information which do not directly identify the user:
While we were working on the latest version of the PP and ToS, although there are several interpretations whether it's personal information or not, we decided that it would be safer if we handled them as sensitive information.
To that end, we've placed the necessary security mechanisms in place. The relevant sections in the Privacy Policy ensures that this information is legally safeguarded.
We respect an individual's right to have a differing opinion with our view of this data as information necessary to maintain our quality of service to our installed user base. We take very seriously our responsibility to protect all data from any purpose other than what’s been stated. We appreciate that individuals or organizations may not wish to share any data when using our service. In this case we understand their decision to uninstall and discontinue the use of our software.
Your feedback is well noted and appreciated. We’ll continue to carefully consider your input in our decision making processes as we continue providing the best possible service to our customers. Thank you.
-
@mb has there been reconsideration of allowing users to disable communication with sunnyvalley servers? you seem to have focused on the riders in this thread vs. the arguably more significant group. on one hand you have existing forum users whose ignorance of privacy maintenance rush to defend something they've already installed. on the other, several users created a forum account to add their concern after searching the web for similar answers.
how did your opportunity cost analysis manage to suggest that you forego an unknown number of free users in favor of data collection? how many of those same users could have been upsold & transitioned to your saas offering over the last 3 years? i imagine those KPI might also be valuable for to the investors you reference, yet you're operating blindly.
i've spent quite a bit of time with tools such as suricata, wazuh, maltrail, security onion / zeek / elk stack, zabbix / nagios in the interim, and i've found some combination thereof to meet (if not best) my understanding of zenarmor features & functionality. though i'd enjoy familiarizing myself with zenarmor i'm patient enough to wait for our ability to operate it in the absence of data collection. after all, you don't need it.