Static IP addresses and segmented Clerk PCs

[eanderson]

After upgrading a few of the firewalls in my Stake I have a few questions. The instructions include setting static IP addresses for dedicated machines such as clerk PCs and network printers. I have done so. .

1. Are there any advantages to setting static ip addresses other than a guaranteed IP ?

2. I don't see anywhere in TM to view mac addresses or hostnames of those using the IP addresses. In fact I don't see anywhere I can see information about clients on the network other than aggregate information. I ask this because I see some buildings have more connections than the number of devices I would expect.

3. Why are the clerk computers on the same segment 192.168.108.x as the general public. Since the clerk computers contain sensitive information wouldn't it make sense to segment them differently?

[aclawson]

1. At the moment, no. Theoretically in the future? Yes. But with the new scope chances of running out of IP addresses is pretty slim in all but maybe the most extreme cases.

2. On the network tab click the icon that looks like a blue gear.

3. Yes. But they haven't done that yet. If they will at all. Eventually I'm hoping that MLS goes away completely and everything is done through lds.org in which case it will no longer matter.

[Biggles]

3. Yes. But they haven't done that yet. If they will at all. Eventually I'm hoping that MLS goes away completely and everything is done through lds.org in which case it will no longer matter.

Reading between the lines, although MLS will eventually be dropped, there will still be a Clerk computer, as the majority of Tithing, calling updates etc., will still be carried out in the Ward building. The Church wouldn't expect members to supply and use their own computer to carry out a Clerk type calling, at the building. At home that's a different matter.

In an ideal world everyone would be carrying out their business electronically, including Tithing, but there will always be those that can't, for whatever reason.

Apologies if this is too far of topic!

[aclawson]

The point is that once everything is up on the cloud then clerk computers will no longer have sensitive information so it won't matter if the clerk's office is on the same segment as the rest of the building.

In some (many?) countries tithing is already done electronically - that it doesn't happen in the US is just another indication of how far behind the curve this country's infrastructure lags. In Japan they've been paying for vending machine purchases using their cell phones for over 10 years (and they were doing it with flip phones). There are no technical reasons why we can't do this, nor are there any real cultural restrictions - the people who can make it happen simply haven't wanted to.

[jdlessley]

There are no technical reasons why we can't do this, nor are there any real cultural restrictions - the people who can make it happen simply haven't wanted to.

Do you have some inside information to verify this?

[aclawson]

"inside" information about what, exactly? That mature, well-established technology isn't being used to its full potential? In Japan (and other countries) people can easily make electronic donations to the church and have been doing so for years. One does not need "inside" information to verify that no decision has been made to make similar function widely available and publicly announced in the United States.

Technical factors blocking this? None, really. Electronic payments are fast, easy and secure.

Cultural factors blocking this? None. In 2014 easy electronic payments are in strong demand. I personally have written maybe five non-church related physical checks over the past 15 years. If not for tithing I wouldn't be writing *any* physical checks ever for any reason. I have, however, been making electronic payments to companies since 1994. In 20 years if somebody had devided to make this happen it would have happened.

[aebrown]

the people who can make it happen simply haven't wanted to.

One does not need "inside" information to verify that no decision has been made to make similar function widely available and publicly announced in the United States.

Your second statement is factual and I doubt that anyone would argue with it. It's your first statement that's really quite unsupportable. I'm not sure what you're trying to imply with it, but to me it seems obvious that given the Church's limited resources, other projects have had a higher priority. That's quite different in my opinion from saying that those in charge "simply haven't wanted to."

But even if systems were put in place for processing electronic donations, and we could get some large portion of the membership in North America to participate, we wouldn't get 100% participation for many, many years. So there will still be a need for processing donations in the clerk's office. I'm not so sure that this will move to an entirely online processing system anytime soon; after all, we all know that we don't have 100% reliability in our Internet connections. It will be interesting to see what happens in this area.

So bringing the discussion back to the original topic, there is a reasonable argument for segmenting the network to limit access from the general membership to the subnet where more sensitive information might be stored. That would be beneficial for quite some time into the future.

[russellhltn]

So bringing the discussion back to the original topic, there is a reasonable argument for segmenting the network to limit access from the general membership to the subnet where more sensitive information might be stored. That would be beneficial for quite some time into the future.

Agreed. I'm not sure if that would require putting them on a separate physical network or not. (It would certainly be more secure if they were separate. But I'll bet many meetinghouses weren't wired with that in mind.) Or how well it would be supported with the existing Cisco firewalls with the scripts that are running on them now. It's possible, but implementation may not be trivial and may not be cheap.

[aclawson]

Your second statement is factual and I doubt that anyone would argue with it. It's your first statement that's really quite unsupportable. I'm not sure what you're trying to imply with it, but to me it seems obvious that given the Church's limited resources, other projects have had a higher priority. That's quite different in my opinion from saying that those in charge "simply haven't wanted to."

Unmotivated desire is equivalent to not wanting to. But the "they" who "simply haven't wanted to" extend far beyond the church: in nations where easy electronic payments are ubiquitous the church is simply availing itself of an infrastructure that is already in place. In the US it is doable, but there would need to be extra steps taken and to the people who call the shots in SLC there is not sufficient motivation to follow that path for whatever reason. It isn't a question of limited resources - setting up a (non-optimized) electronic payment system that is secure and easy to use takes me about 10 minutes. Working out the details for an optimized system would take some effort but nothing that is particularly difficult and everything could be completed in a month.

But even if systems were put in place for processing electronic donations, and we could get some large portion of the membership in North America to participate, we wouldn't get 100% participation for many, many years. So there will still be a need for processing donations in the clerk's office.

It isn't about reducing the burden on the clerks, it is about making things easier for the entire generation of people who have never known anything except for electronic payments, plus the early adopters.

I'm not so sure that this will move to an entirely online processing system anytime soon; after all, we all know that we don't have 100% reliability in our Internet connections.

This injection leads me to believe that I must clarify that there are two topics at hand here.

1. Electronic donations from the members. As we approach 2015 we should absolutely have a simple, consistent method for members to submit their donations electronically, be it from their mobile device or their home computer or what have you. No manual account creations by people in an obscure office within the COB, no word of mouth campaigns and internet rumors that get distorted with every retelling, just a simple "here is a website and/or app, set up your account and click this button". Fin.

2. Weekly electronic donation processing, by the clerks, in the wards on Sundays using either a standalone app (MLS) or a web-based app. There will always be a need for somebody to process donations on Sundays, even if it is to count up the $20 in pennies and dimes from the Primary lesson on paying tithing. This is a completely separate issue than #1 above.

So bringing the discussion back to the original topic, there is a reasonable argument for segmenting the network to limit access from the general membership to the subnet where more sensitive information might be stored. That would be beneficial for quite some time into the future.

What is the threat model? And since all traffic goes through the firewall it wouldn't be particularly difficult to establish a filter rule that blocks all intralan traffic to/from those PCs. Installing a new admin PC? Register the MAC address with the Cisco and let the script create a deny rule. That'd be the cheapest way.

[russellhltn]

And since all traffic goes through the firewall it wouldn't be particularly difficult to establish a filter rule that blocks all intralan traffic to/from those PCs. Installing a new admin PC? Register the MAC address with the Cisco and let the script create a deny rule. That'd be the cheapest way.

• Are you sure that function is available given all the scripts currently running on the firewall?
• This would increase the burden on the GS when computers and changed out.
• This increases what the STS needs to do to change out the computer.
• This wouldn't protect against attacks from within the LAN - such as from wireless devices.