Posting here for comments from the security team & other SA's at a minimum -
Currently, there's no way to suppress the emailed spreadsheet of an unencrypted data set to the person running the rule - I'm surprised we got this far without InfoSec review issues from one or more of our Jupiter/Venus customers.
I know that a product risk is being opened by Erik Grand for the new customer Carbon Black (and I'm pretty sure it's a blocker for them moving forward with implementation), but I think the priority may be even higher, given that it's just been luck so far that we haven't had to address it already.
We may need a short-term fix to this, at a minimum, where there's a checkbox for the rules engine to disable sending the spreadsheets - and if we add it to the UI for the individual rule, the admin should either be able to set a default, or the default should be "no spreadsheet" and then the user can use a checkbox to receive one for a test run.
Longer term, being able to download test results, or otherwise view on screen, would be the way to go, I'd assume.
I'll let others chime in, but wanted to get this started for wider discussion and prioritization beyond the product risk being opened. Thank you!
New Idea
Custom Rules rules engine: need checkbox to suppress emailed Excel data - significant security issue
+2Forgive me if this is a stupid question - but wouldn't any data that a user could extract via CSV fall into a group of data that they already have permissions to access? I thought (and could be wrong) that Gainsight respected SFDC permissions on objects. Is this true?
+4Scott - Security is definitely aware of this and I am kind of with you that we knew there would need to be better and more secure options than email that would be needed.
Dan - The issue we are raising is not as much user access to data - it is that email is an unencrypted communication channel and rule results are sent via email. Rule results likely could contain customer names and data. We have addressed the SFDC permission scenario (and added the option to disable general export capability) vs the bigger issue of email containing these attached files.
Dan - The issue we are raising is not as much user access to data - it is that email is an unencrypted communication channel and rule results are sent via email. Rule results likely could contain customer names and data. We have addressed the SFDC permission scenario (and added the option to disable general export capability) vs the bigger issue of email containing these attached files.
+2Thanks for clarifying Denise. I can see now where that could be a concern. Very valid!
I would like to add some details: The email sent (over the network) is TSL/encrypted channel. The vulnerability here should be the storage of this at (1) end user's email client - e.g. outlook/exchange, (b) the third party or ESP - Sendgrid.
Question: Is their ask limited to Rules Engine only. Could there be other areas where concerns may comeup later in the implementation?
Question: Is their ask limited to Rules Engine only. Could there be other areas where concerns may comeup later in the implementation?
+4Ankit - The other use cases that send info over email - large report exports - these are delivered via email. Emailing dashboards is another one but they can control whether they use that feature or not.
+3Quick question: are Rules Engine results emails sent via Sendgrid? Or are we launching them from some other source?
Same question for reports that are emailed - Sendgrid?
Thanks!
(sorry for delayed follow-up question Ankit - was on PTO early part of last week)
Same question for reports that are emailed - Sendgrid?
Thanks!
(sorry for delayed follow-up question Ankit - was on PTO early part of last week)
Yes. they are via Sendgrid. All the MDA notification emails are sent via Sendgrid - E.g. report export, rule/outreach/powerlist result email, aggregation completed notifications, std object installation, PDF/PPT export, etc.
If you are talking about Outreach's reports/charts - it depends on the customer configuration - Mandrill or Sendgrid. These emails are counted against the customer.
If you are talking about Outreach's reports/charts - it depends on the customer configuration - Mandrill or Sendgrid. These emails are counted against the customer.
Thank you for raising this, Scott.
Carbon Black is right to raise this issue. We need to be prepared for email to be unencrypted in transit over the Internet. I am unaware of any way, in normal email like we're discussing, to ensure that an email is encrypted over the network all the way to the end user's mailbox. If anyone sees that differently, please let me know.
If we reasonably believe that *any* transmission will contain sensitive customer data, then we should disable the ability to send that transmission unencrypted over a public network like the Internet. It's like how Google and other major Internet properties won't allow someone to browse with http anymore. They auto-redirect to https. They expect that the user wants to be safe, and disable the option for him to hurt himself. That's good security engineering, and we should do it too.
The best option seems to be to keep emailing the customer, but don't attach anything that we reasonably believe could have sensitive data. In the email, let the user know the report is now available in the portal. The user can go there to view it or download it over https. That seems to be the best approach for artifacts which may contain sensitive data.
Can we implement this approach for all transmissions which we reasonably believe may contain sensitive customer data?
Carbon Black is right to raise this issue. We need to be prepared for email to be unencrypted in transit over the Internet. I am unaware of any way, in normal email like we're discussing, to ensure that an email is encrypted over the network all the way to the end user's mailbox. If anyone sees that differently, please let me know.
If we reasonably believe that *any* transmission will contain sensitive customer data, then we should disable the ability to send that transmission unencrypted over a public network like the Internet. It's like how Google and other major Internet properties won't allow someone to browse with http anymore. They auto-redirect to https. They expect that the user wants to be safe, and disable the option for him to hurt himself. That's good security engineering, and we should do it too.
The best option seems to be to keep emailing the customer, but don't attach anything that we reasonably believe could have sensitive data. In the email, let the user know the report is now available in the portal. The user can go there to view it or download it over https. That seems to be the best approach for artifacts which may contain sensitive data.
Can we implement this approach for all transmissions which we reasonably believe may contain sensitive customer data?
+3Is the checkbox option at a minimum going to make it into the August release? This is one of those "crossing our fingers and hoping other infosec groups at our large clients don't notice" issues - it would be good to have the intermediate option of just turning it off . . .
+3... and the reason I'm focused on Rules Engine is that, unlike reports exports, etc., there's no option: if you use it, we're emailing attached, unencrypted data.
+4This is expected Summer release Scott. And actively being worked on.
1 person likes this
Reply
Rich Text Editor, editor1
Editor toolbars
Press ALT 0 for help
Sign up
If you ever had a profile with us, there's no need to create another one.
Don't worry if your email address has since changed, or you can't remember your login, just let us know at community@gainsight.com and we'll help you get started from where you left.
Else, please continue with the registration below.
Welcome to the Gainsight Community
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.