online backup and file sharing "Dropbox"

Discussions around the setup, operation, replacement, and disposal of clerk computers, not to include using MLS
User avatar
aebrown
Community Administrator
Posts: 15057
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Tue Aug 07, 2012 4:40 pm

ldsrussp wrote:I guess you guys already realize it but dropbox, google docs, etc.. are all not really in compliance with the handbook as last I read it. The reason is due to the storage of data on third party servers not controlled by the church. .


Where does the handbook mention third-party servers? I know that Handbook 1, Chapter 13 talks about protecting information, keeping it secure, and password protecting. But I see no prohibition on using third-party servers. I'm not saying that this guarantees that third-party servers are okay, but I see nothing that unambiguously prohibits them, either. So in the absence of a clear directive, it is up to local leaders to familiarize themselves with the policy and make their decisions for the units within their stewardship.
Questions that can benefit the larger community should be asked in a public forum, not a private message.

User avatar
johnshaw
Senior Member
Posts: 2032
Joined: Fri Jan 19, 2007 1:55 pm
Location: Syracuse, UT

Postby johnshaw » Tue Aug 07, 2012 7:58 pm

ldsrussp,

Owncloud is pretty cool, I've setup and played around with it recently as well, but doesn't that limit access to within a specific church building? I'm pretty sure that is limited in usefulness with that consideration. In addition to what aebrown has stated, remember that there are levels of data that a ward or stake uses to conduct the business of the church. A list of people in the stake with their phone numbers, address, etc... has more concern to me than the agenda for stake conference. Through our Stake Presidency's guidance we've taken a layered approach and used some encryption in areas as well. When I think about the number of people who have access to a clerk computer, and the data that typically resides on the desktops or My Documents, I have to think that a carefully thought out cloud storage strategy may be just a safe and secure. But as aebrown mentioned, the Stake President is the 'Key' to the whole thing.

ldsrussp
Member
Posts: 80
Joined: Wed Jul 16, 2008 4:34 pm

Postby ldsrussp » Wed Aug 08, 2012 8:53 pm

I reviewed this with the Stake Clerk and Stake President about 8 months ago so I can't remember which sentence made us believe any third party servers were not in compliance. I'll see if the stake clerk remembers tomorrow. Of course it did not use that exactly language but we all concluded anything not controlled by the church directly would be non-compliant based on what we read.

ldsrussp
Member
Posts: 80
Joined: Wed Jul 16, 2008 4:34 pm

Postby ldsrussp » Wed Aug 08, 2012 8:57 pm

Owncloud can be accessed outside of the church building easily enough. Unfortunately it probably could not reside behind a church firewall (in fact I'm sure not). What I plan to do is this:

cable-modem -> basic router -> owncloud server. Basically, it will be behind a normal home router to give it basic protection with most ports locked down and will sit side by side with the church firewall but outside of it.

If you all can convince me that offsite storage is ok I'd be glad to have them use something like skydrive instead but I'll go look into the handbook again and find where it had us convinced we can't use google docs or skydrive or such for anything church related.

ldsrussp
Member
Posts: 80
Joined: Wed Jul 16, 2008 4:34 pm

Postby ldsrussp » Wed Aug 08, 2012 9:29 pm

Here you go. Aebrown himself gave a link to what I believe it the key reason to not use google docs or other 3rd parties for most church data:

http://broadcast2.lds.org/eLearning/ics/KeepingRecordsSafe/KRS_ENG_19_namehtsinosretepnairb/player.html

Basically, I would like to create areas for two things, both of which involve sensitive confidential information that according to that instruction should not be placed on third party services.

1) offsite backups for mls
2) area for bishopbrics to keep documents that may have some confidential information.

A private cloud on church owned and controlled computing resources I think meets these qualifications to allow this. You can create groups (for example, a ward bishopbric) and restrict only those who belong to this group to have access to those documents. Additionally, as per the guidance above these records would be help on church owned storage kept behind locked doors. Of course, it could always be hacked but it's not likely to be.

Hence, if you are just using google docs and such for say, bulletins or maybe planning lists for activities I don't see an issue. I was once told though that we could not even use it for lists of inactives and notes on them when doing ward missionary work so don't know just what qualifies as "church confidential".

Also, depending on how you use even owncloud you could be in violation of this one from that presentation:
"Never save copies of confidential information to mobile devices".

russellhltn
Community Administrator
Posts: 23743
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Postby russellhltn » Wed Aug 08, 2012 9:54 pm

ldsrussp wrote:cable-modem -> basic router -> owncloud server.


Except that's against the policy of not bypassing the firewall.


ldsrussp wrote:2) area for bishopbrics to keep documents that may have some confidential information.


The problem with that is this policy that says:

Other confidential files should not be stored on the hard drive. They should be saved on external media and locked in storage when not in use.


OTOH, there's nothing that says that we need to use a cloud storage. The church makes it's own offsite backup once a month. And since CUBS came out, I have to wonder just how much information is strictly local any more. Maybe some things like sub-classifications of expenses or HT/VT details.

Also, consider the next person that comes along in your calling. While it's great to try and use all you know to magnify your calling, I'd be cautious about setting up a system that takes that level of knowledge to service.
Have you searched the Wiki?
Try using a Google search by adding "site:tech.lds.org/wiki" to the search criteria.

User avatar
aebrown
Community Administrator
Posts: 15057
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Wed Aug 08, 2012 10:15 pm

ldsrussp wrote:...don't know just what qualifies as "church confidential".


There are some kinds of data, such as membership information, that clearly qualify as confidential and should not be posted on third-party servers. But I would think that a blank reimbursement form definitely is not confidential and could be. There are many levels of confidentiality in between. That's where judgment, listening to the spirit, and following priesthood leaders is essential.
Questions that can benefit the larger community should be asked in a public forum, not a private message.

ldsrussp
Member
Posts: 80
Joined: Wed Jul 16, 2008 4:34 pm

Postby ldsrussp » Thu Aug 09, 2012 12:46 am

aebrown wrote:There are some kinds of data, such as membership information, that clearly qualify as confidential and should not be posted on third-party servers. But I would think that a blank reimbursement form definitely is not confidential and could be. There are many levels of confidentiality in between. That's where judgment, listening to the spirit, and following priesthood leaders is essential.


I tend to think any kinds of lists of people with details probably qualify as confidential also. For example, maybe a PEC list of focus familes and some details that I could see Bishopbrics wanting to keep. I'd feel better about that being on a church located hard drive than google docs.

As for the MLS, thanks to Cubs it's not as necessary. What I see happening though now is the units only using the flash drives and not the hard drive as it apparently saves faster to the flash. Then they leave the flash there all the time plugged in. One ward lost it's flash drive and had a drive crash and was forced to use the monthly cubs backup and a lot of work to restore. Their fault but I did wonder if they had an easy way to push out their mls backup to a server if they would use it. Probably not though. :(

User avatar
sj3vans
New Member
Posts: 30
Joined: Sat Jul 14, 2012 2:11 pm
Location: Richmond, VA, USA

LDSDrive

Postby sj3vans » Thu Aug 09, 2012 1:17 pm

As the general user increases in knowledge about cloud technologies, they are going to use it regardless of policy, either intentionally or ignorantly. The solution is to architec a solution that meets the need and is non-intrusive. The obvious solution to me is for HQ to create a Dropbox or Skydrive like service based on LDSs.org credentials with access assigned according to calling. This way, non-MLS data can be backed up automatically, is made available when not at church, and HQ can monitor contents of such data if needed (Scan for viruses, DLP, etc). By creating a solution like this everyone benefits, and everyone will use it.

By-the-way, I think such a service could extend beyond unit PC's. Perhaps Young Women have their own folder, or the ward as a whole, etc.

Dropbox and other 3rd party sites might be fine for non-sensitive data, but as evidenced byDropbox recently being hacked, it is not a good idea for things you don't want out in the public. (EDIT: It was correctly noted by JohnShaw that Dropbox was not actually hacked so much as an employee's employed bad security practices. This included using the same password on both his Dropbox account and his Linked-In account (which was compromised). He also had a document containing usernames of real Dropbox users allowing them to receive spam in Dropbox only. However, I still contend that what happened to him will happen to others solely due to the weakest link in any security strategy: The user. Those on this list are not the ones I worry about. It's the user who is not computer savvy and just wants to get their calling done with minimal headache. It's a fine line between what you can force a user to do to ensure data security and their refusal to use it in favor of easier, less secure methods.)

User avatar
johnshaw
Senior Member
Posts: 2032
Joined: Fri Jan 19, 2007 1:55 pm
Location: Syracuse, UT

Postby johnshaw » Thu Aug 09, 2012 7:02 pm

sj3vans wrote:Dropbox and other 3rd party sites might be fine for non-sensitive data, but as evidenced byDropbox recently being hacked, it is not a good idea for things you don't want out in the public.


Just a quick note here... the issue with Dropbox being hacked is a technicality... There was a Dropbox employee who's dropbox account password was the same as his Linked In password... technically the breach was caused by the Linked-In hack... The Dropbox employee had a project folder that contained the usernames of Real Customer logins... those customers started to get spam in dropbox-only not used anywhere else email addresses.

ok. to the real solution, sj3vans you are correct, the only real solution is for the church to provide a storage location. There are currently a couple of really good commercial products that could fit the bill. Oxygen (the most robust back end storage options), Citrix Sharefile (on premise is releasing soon), Symantec has an offering-in-waiting and VMware Octopus is also an offering-in-waiting. These solutions all have a concept of a shared personal drive and a 'company' drive. A company drive could be setup as a Unit.

The issues around it, (1) generally if you are concerned about privacy and protecting data, you'll want pre-internet encryption, and encryption at-rest. This narrows the field, and generally means that the app must be wrapped in some kind of sandbox solution (Think private company app store) with a modified version of the app that doesn't allow exporting of the data. This is a bit of a bummer because then you can't use it for anything unless that private app store also gives you quickoffice, office, or something else useful to modify the data or view it. (2) LDS Account integration, this limits the playing field because most companies (Owncloud included, though I seem to recall a SAML plugin...) are already on Active Directory for accounts, so the rollout at the enterprise layer is focusing on LDAP integration first. We may need to do something a bit more unfriendly like sharepoint or something that stores data on the server only, and while bits are copied to be viewed, they are never permanently stored online.

What we really need is a good encryption tool that works on Android/IOS/Windows/MAC that could do the pre-internet encryption and then do the at-rest encryption, that way something like Dropbox, Drive, Skydrive, and the dozens of others might work for us.

Seriously... if you want to earn a gazillion dollars, write that encryption software...


Return to “Clerk Computers”

Who is online

Users browsing this forum: No registered users and 1 guest