New Computer Policy

[russellhltn]

I was responding to RussellHltn, who did seem to be asserting in reply to me that tomw's comments actually did mean something that strong.

Just for the record, what I said was "have we now strayed into the "3rd party server" rule?"

My logic being what Alan expressed:

we have been told here not to upload exported data to a third-party server because of concerns about confidentiality. When a third-party server is involved in transmitting data from the screen of a computer running MLS, it seems that we have most of the same issues.

I'm picking on GoToMyPC simply as an example of server-based remote control software. Having used one of its close relatives, GoToAssist, in my job, I have no concerns with that particular vendor. But that still makes my very uncomfortable with the idea of remoting MLS.

[RossEvans]

I'm picking on GoToMyPC simply as an example of server-based remote control software. Having used one of its close relatives, GoToAssist, in my job, I have no concerns with that particular vendor. But that still makes my very uncomfortable with the idea of remoting MLS.

As you can see, I also am uncomfortable with that idea, and with the idea of remoting to the Windows box that houses it. But my reasons have nothing to do with the "third-party server" issue. Since that server-side issue -- or at least an issue with that particular vendor's server -- really seems not to be the root of your concerns, it seems odd to base the objection on a "third-party server" policy that is at best unclear.

Getting back to the policy issues themselves, the new document clearly does not state any provision that resembles tomw's carefully crafted comments on this forum about uploading to third-party servers data that was downloaded from MLS or LUWS. I still find that omission notable. But since he has not retracted those comments here, I personally still consider them -- within the four corners of what he wrote -- to be in effect. (I don't know where that leaves the 99.9 percent of MLS users who do not dissect all LDSTech Forum comments. Presumably they will just govern themselves by the written policy of the Presiding Bishopric this thread is discussing.)

I still am not convinced that even tomw's comments extend to remote-access applications, and it seems a stretch to infer that they do. Such an application does not include downloaded or uploaded data. And in the comments I found, the third-party servers tomw was addressing all involve, by design, persistent storage of the uploaded data in files or databases. That is easily distinguished from a server that is simply passing encrypted packets of virtual-terminal data back and forth in a communication channel. The latter type of server more closely resembles all the servers on the Internet backbone in function.

[russellhltn]

Since that server-side issue -- or at least an issue with that particular vendor's server -- really seems not to be the root of your concerns, it seems odd to base the objection on a "third-party server" policy that is at best unclear.

How would you feel if someone in the forum offered a remote service? There's no exception in Tom's statement for trustworthy vendors such as Google Docs.

That is easily distinguished from a server that is simply passing encrypted packets of virtual-terminal data back and forth in a communication channel. The latter type of server more closely resembles all the servers on the Internet backbone in function.

Just keep in mind those packets are encrypted by the vendor, not from the vendor.

[jdlessley]

I think that many contributing to the discussions about the policies and guidlines, as well as others, recognize that security of confidential information and its unauthorized disclosure is an important driving concern when addressing any technology used in connection with the administrative computer, or software that may be installed on it, as well as how that data is handled. We can take the Security section of the new policy and guidelines letter and interpret it or read as much into it as we will.

The first sentence of the Security section says:

Information about members, donations, and financial transactions is confidential and should be protected from unauthorized disclosure.

This should be a driving objective when evaluating any proposed solution to an issue that would change or add to the systems configuration and software the Church provides for units.The same is true in using the data away from the administrative computer.

The Security section of the policies and guidelines letter goes on to provide further guidance in how to provide this protection when working with the data. It is this further guidance I am inclined to measure any other method of handling confidential data against; and I hope others do also.

Some people may find a proposed solution to an issue and then look to see if there is a policy or procedure that explicitly prohibits implementing that solution. Others appropriately measure the solution against the security objective.

The post that tomw madein response to questions about mapping programs and applications expands further the understanding of how to protect confidential data. Some have come to refer to this as the 3rd party server rule. It just reminds people that some processes and applications have the potential to place confidential data in places where control of that data can be lost and jeopordize its confidentiality.

Remote access of an administrative computer opens questions about two aspects of protecting confidential data. The first centers around exposing access to the data at a location possibly not protected in a private manner as described in locating administrative computers.

Computers should be located in secure areas where bishopric or stake presidency members and ward or stake clerks can work with and print this confidential information in private.

Is this precaution being taken at the computer now controlling the administrative computer? The potential that it is not is quite high. The second is the protection afforded the data when transmitted from the administrative computer to the remote control location and the potential for the data to be stored or routed to locations where control of that data can be lost. As much of the discussion in this thread and another shows this is the area some are concentrating. I think both need to be addressed and satisfied.

[RossEvans]

How would you feel if someone in the forum offered a remote service? There's no exception in Tom's statement for trustworthy vendors such as Google Docs.

It's hard to answer that question, because my interpretation of policy is not based on feelings. It is based on my reading of what the actual words and sentences of the policy say, not what I wish they would say. And I don't see how the actual words of tomw's comments cover the case of remote-access applications. It may be that some policy ought to cover it, but that is a different matter.

As I mentioned before, the local instructions in our unit preclude the use of such a service or any other software when the machine is unattended, and that's fine with me. It seems better to address the security issues directly that way.

Do I understand that you think the only problem with remote access is that it hypothetically might be offered by an untrustworthy vendor? You think it would be a good idea if CHQ just blessed Citrix GoToMyPC specifically for remote access? (The Church could do that if it chose to. It selects other vendors sometimes and approves certain software.) I don't think that would be advisable myself, because the inherent security weaknesses are in our own units. Our own security policy and practice are not very robust there, and I don't think weakening them further by remote access is a good idea.

[russellhltn]

And I don't see how the actual words of tomw's comments cover the case of remote-access applications.

As a reminder, never upload information that you have downloaded from MLS or LUWS to a 3rd party server (unless it is an official Church server).

So you see streaming screenshots as being sufficiently different that we can disregard whatever security concern that prompted that statement?

Do I understand that you think the only problem with remote access is that it hypothetically might be offered by an untrustworthy vendor?

Absolutely not. Check posts #2 and #5. In the absence of "thou shalt not", I'm building a case against it on what has been provided.

[RossEvans]

So you see streaming screenshots as being sufficiently different that we can disregard whatever security concern that prompted that statement?

No. I just see such facts as being so different from those covered by that statement that the situations are not materially equivalent. There would be no "upload," and no "information that you have downloaded from MLS or LUWS." And the third-party server tomw was talking about in the quoted case was, by design, a database or file server with persistent storage of the uploaded data, not a communications server designed to pass packets through on the fly.

And I do not presume to speculate about "whatever security concern prompted that statement." I am not even sure it was a "security concern" at all. It could have been a legal concern associated with uploading such downloaded data to someone else's server regardless of how secure the process is, as some other comments by tomw have indicated.

So maybe tomw's reasoning and motives would extent to this case, and maybe not.

Rather than put words in his mouth and spin my own speculation about what he might have meant into some more generalized and amorphous "third-party server rule" -- especially when the Presiding Bishopric document does not remotely allude to such a rule -- in the absence of more information I carefully go by what tomw actually wrote.

In some other cases -- for example, in the case of uploading to Google Contacts -- it is clear to me that the facts fit his guidance so I think it does apply, and I support it regardless of my own policy preference or opinion about the technical merits.

In yet other cases, such as email using third-party servers, tomw has stated that he does not mean to forbid their use as a matter of policy, and has deferred to the inspired judgment of priesthood leaders. So I am certain that he makes at least some distinctions between types of servers.

I don't know where he would draw the line in the case of remote-access utilities. I don't even know if he would attempt to draw a line in such a case. And, I suggest, neither do you.

I have noticed that tomw's comments about policy matters in this forum have always seemed deliberately restrained and carefully drafted. He certainly does not hold himself out to be the Policy Czar. When he does venture such limited comments about particular cases, I think we do not serve him or the Church well if we expand the comments to fit our own conceptions of what broad policy ought to be.

[RossEvans]

Just to clarify, my own substantive objections to remote-access are directed at what seems to be a certain grassroots clamor for using this method to make MLS accessible to its end-users (bishopric, clerks, quorum and RS leaders and secretaries, etc.) from home. I just don't think these desktop systems are well suited for that because their baseline security is relatively at-risk to begin with. The right way to provide MLS functionality online is to build a proper web-based application with some MLS-like functionality, which may yet happen.

I don't harbor such objections to a targeted installation of such a remote Windows utility for the use of authorized technical administrators such as the STS for troubleshooting and support. The policy document actually seems to authorize installation of some centrally approved remote-access utility, which so far has not been rolled out. Hopefully that sysadmin support role is what it would be used for.

[slmsz20]

Second there is a restriction that any other software must be approved by the stake president (not in the 2005 version). But then it must also not interfere with the operation of or compromise the security of the Church software and data already on the computer. The security of Church software and data is open for interpretation. Desktop 5.5 could be taken to be Church software since it mostly consists of operation system configuration customizations. Some of those customizations would have to be changed to accommodate most remote access applications. However, this leaves Dell Optiplex 740s open for installing remote access applications since there is not a Desktop 5.5 or similar setup for the 740.

An external CD/DVD drive will allow you to install Desktop 5.5 on the Optiplex 740. We ran into this issue when we updated our computers when broadband was authorized for stakes. The sata interface on the optiplex 740 and later Dell PC systems is not recognized correctly by the restore software built into the 5.5 disk, however it will recognize correctly on an external usb cd/dvd drive. The only other thing we had to do was install the system drivers when windows first came up.

Hopefully they release a new desktop version in the future since the old ide drive interface is no longer used on any new computers and while the external drive works it is kindof annoying to haul it to every ward in the stake.

[russellhltn]

An external CD/DVD drive will allow you to install Desktop 5.5 on the Optiplex 740.

That's what the instructions claim, but I've found it to be fickled and unreliable. I found it easier to drop the new hard drive into a older computer and do the initial loading that way. When it comes time for the first reboot, shutdown and move it back to the new computer.

But I think your point was that Desktop 5.5 CAN be installed on a 740. And indeed, with some additional equipment, it can.

Edit: That is assuming that you can lay your hands on the CDs. Some have reported that CHQ is no longer supplying them and with turnover in positions, some stakes have lost their only copy.