CAPR 110-1, 27 Dec 12, CAP Electronic Systems and Data Administration

[kratclif]

Any IT folks read the new CAPR 110-1 yet? It was just posted today and I had a chance to skim it.

A few items of note:

There is now an Internet Operations restricted application in eServices. It's available to me as a unit IT officer; not sure what other duty positions get access. Apparently we're supposed to request approval for any internet operations (web sites, email, etc) using this application.

Of particular concern to me is that it requires the site Administrator username and password! As an IT Pro I hate password sharing; IMHO passwords should be kept secret for a number of reasons. If CAP NHQ requires a username/password for any system that I administer (I don't administer any CAP sites at the moment) they are getting their own username/password pair that will be only for their use (hopefully never).

And what exactly is meant by "Administrator password"? Root/system level access, or just access to the CAP resources on the server?

I wonder how this works when the ToS of a particular hosting server prevents sharing of credentials...

Am I overreacting to this?

Kevin

[Eclipse]

http://captalk.net/index.php?topic=16676.0

Yes, they want the root password.  There's nothing on a CAP website that should be super-secret or confidential.

The problem is that people build systems for units and activities, leave CAP, get bored, or sometimes quit in a huff, and take the
security info with them.  That or they build it on a machine under their desk and just turn it off.

This should help the former and discourage the latter, though it won't fix everything.

[kratclif]

http://captalk.net/index.php?topic=16676.0

Yes, they want the root password.  There's nothing on a CAP website that should be super-secret or confidential.

The problem is that people build systems for units and activities, leave CAP, get bored, or sometimes quit in a huff, and take the
security info with them.  That or they build it on a machine under their desk and just turn it off.

This should help the former and discourage the latter, though it won't fix everything.

I have a VPS that's hosted in a data center in California. When my unit's current hosting plan expires I was going to offer to host the unit web site on my server, which would save the unit money and not cost me any more since I can do whatever I want with it (I have root access, can reload the OS, etc).

However, I don't see how this is going to work. The only access to the server is through SSH/SFTP via private key authentication. I don't allow password auth at all on the server. There is no web management interface, it's strictly command-line. There is no "root" account, everything is done via sudo.

I understand the issue of people starting something and then leaving CAP, etc. My plan for this was to have backups of the site send to the unit commander monthly, and to have the unit commander, not me, keep the credentials to the DNS provider and domain registrar. Not foolproof, but if I left on bad terms the commander would still have the site files and could redirect the DNS to point to a different server.

As it stands now with the current reg, someone leaving on bad terms could just change the password before NHQ had a chance to do anything about it.

Kevin

[coudano]

As an IT Pro I hate password sharing; IMHO passwords should be kept secret for a number of reasons.

As an IT Pro, you should be in favor of limited and appropriate password sharing.
When only one guy knows the passwords to everything, then you get nonsense like this:
http://betanews.com/2008/07/18/one-admin-s-missing-password-leaves-san-francisco-in-a-lockdown-state/

As a solo IT Pro, you can know everything.
But if you work in a team, then others in your team need access too, just incase you, you know, get hit by a bus.

If CAP NHQ requires a username/password for any system that I administer (I don't administer any CAP sites at the moment) they are getting their own username/password pair that will be only for their use (hopefully never).  And what exactly is meant by "Administrator password"? Root/system level access, or just access to the CAP resources on the server?

That is in keeping with the principle of least privilege.
I take it to mean that CAP needs control the aspects of this official internet operation, so that it can control that operation.  That means, for example, an account on a server, being virtualhosted, the account password.  Possibly for a dedicated server (or VM) the root access.

While I don't disagree with the idea/requirement, I get the sense that the people writing the reg don't really have a full understanding of configurations of websites and the servers they run on.  And most certainly not of general IT security principles.

I wonder how this works when the ToS of a particular hosting server prevents sharing of credentials...

Most likely irrelevant.

Am I overreacting to this?

If you are panicing and running around your chair, then yes.
Remember, that official CAP operations belong to CAP, not to you, the bofh.

Easy enough to have a non-official "internet opration" (er...   uh...    website)

If you have set up your systems so that root access to the server a site is running on, and the site itself are inseparable, then well that's bad on you.  Your paranoia is probably reasonable in this case, however you have brought it upon yourself

[JeffDG]

Basically, I think it's to stop to orphaning of systems.

Member A gets all gung-ho and creates a wonderful site on GeoCities.  Then Member A gets disgruntled, and leaves, remaking the site into his personal vendetta against the squadron.  Lots of links have proliferated and voila, black mark to CAP!

Now, the new ITO gets access to the credentials for the site, and takes control of it and puts it back to its former state.  If not, the Group ITO or Wing IT guy have the same access to the information entered.

[Eclipse]

I have a VPS that's hosted in a data center in California. When my unit's current hosting plan expires I was going to offer to host the unit web site on my server, which would save the unit money and not cost me any more since I can do whatever I want with it (I have root access, can reload the OS, etc).

There is no reason for any CAP unit at any echelon to be paying for email, webservices or website hosting, and even less for it to be hosted on
any roll-your own webserver controlled by one person.

Units need simple, template-based systems that can be administered by anyone, and there are a number of robust, free services that offer everything
a unit needs, and the security to comply with regulations.

[JeffDG]

I have a VPS that's hosted in a data center in California. When my unit's current hosting plan expires I was going to offer to host the unit web site on my server, which would save the unit money and not cost me any more since I can do whatever I want with it (I have root access, can reload the OS, etc).

There is no reason for any CAP unit at any echelon to be paying for email, webservices or website hosting, and even less for it to be hosted on
any roll-your own webserver controlled by one person.

Units need simple, template-based systems that can be administered by anyone, and there are a number of robust, free services that offer everything
a unit needs, and the security to comply with regulations.

That depends somewhat on what you want to do.

If you want to just have a pretty website, you're right.  If you want to create a full-scale information portal, sometimes you have to pay for things like SQL server access and such.

Concur on the roll-your-own solutions however.

A website should be a tiny part of your internet operation if you're doing it right.

[Eclipse]

You're correct, but I can't imagine what kind of "information portal" the average unit is going to need that
doesn't simply replicate existing data that lives elsewhere and is generally out of date before its posted.

You can do a whole ton of stuff with shared docs in Google these days, especially if you're API savvy.

[JeffDG]

You can do a whole ton of stuff with shared docs in Google these days, especially if you're API savvy.

Tell me about it...just getting ready to roll out a new wing web presence (including heavy use of Docs) built on Google Apps for Nonprofits.

That said, I cannot grant "root" access to the server...the [darn] thing lives on hundreds of different servers that are entirely proprietary OSs (Research the stuff Google does...custom hardware, custom OSs, everything tuned), but I can create an account with "Super Admin" rights.

Additionally, anyone assigned as the Wing Director of IT will, within about 24 hours, be added to the Super Admins group anyway, so that's kind of a moot point.

[kratclif]

There is no reason for any CAP unit at any echelon to be paying for email, webservices or website hosting, and even less for it to be hosted on
any roll-your own webserver controlled by one person.

Units need simple, template-based systems that can be administered by anyone, and there are a number of robust, free services that offer everything
a unit needs, and the security to comply with regulations.

Agree, I see no reason for CAP to pay for services that can be provided at no cost to CAP. I did not set up the current hosting plan. I would be in favor of just using Google Apps/Sites, but as an ITO that isn't my decision, it's my commander's decision.

As far as roll-your-own hosting, it's an option, if appropriate precautions are taken. Such as having the commander control the DNS so that the server admin can't just leave CAP and turn it into a rogue site. It may not be the best option for everyone, but it's still available as an option if the commander chooses to do it.

BTW, anybody have Google's root password for when we migrate to Google Sites? 

Kevin

[Eclipse]

The Googleverse makes life so much easier.

I'm preparing to move on from my current assignment, and because the wing is still ramping their Google account, used
a bunch of docs in my personal Apps Business domain.

My CAP boss is using a non-for profit domain from his last assignment, so all I need to do is reassign ownership of the docs and
directories over to him and move on, no pain, much gain.

As Jeff said, the "root" in a Google Domain is the Superadmin ID.

[krnlpanick]

As an IT Pro, you should be in favor of limited and appropriate password sharing.

This is absolutely a false statement - individual user accounts should *always* be used, password sharing is incredibly bad at any level. The correct approach is to create user accounts for Joe and Tom; both users are administrators - so they are both added to the administrators group (or given sudo privileges if you are in the unix-verse)

Sharing a single account creates 0-accountability for that account. If both Tom and Joe know the password to the "Administrator" account and one of them logs in one night when they are drunk then it is Joe's word against Tom's. If you have to deal with any regulatory agencies this is not an option at all, it is required to check that box off in an audit. This approach is also a good defense against social engineering attacks. We teach people that they should never give out *their* password, however in audits you would not believe how easily people give up passwords to shared accounts - even to people that have never met.

I haven't had a chance to read the reg yet, but I assure you I will be giving it a thorough read-through and I will forward any comments I have back to NHQ/ITO by way of my CoC.

Regards

[coudano]

Yah granted, for many systems, although there are some applications which a password share (or a key share) is practially or functionally what happens.  The point that I communicated poorly is that admin or control access should be shared and not horded to one individual.

Here's an example that illustrates my point maybe a little better than my previous post...

My squadron uses google docs and calendar fairly extensively.
We don't really mess with apps too much though.

All of the squadron's google 'stuff' are "owned" by a google account that has a password.
However all of the documents within that account are shared out as appropriate to members' individual gmail accounts (we don't use a google domain).  Nobody accesses the squadron's docs from the squadron's account (the 'owner') it is just there for administration purposes.

A handfull of people know that 'owner' password, myself, the squadron commander, and another senior member.
It is shared access via a shared password.  When we need to access the docs, we access them using our own gmail accounts.




I work in a unix sysadmin team.
We use personal keys to ssh to our individual accounts.
We also use a /different/ key pair to access root (easy enough to grant/revoke access by manipulating the authorized keys).
There are cases where sudo works, but there are also cases where the use of sudo obfuscates what is going on the degree that separate user access becomes essentially irrelevant (in terms of an audit trail) and at that point it's just a useless annoyance so we just go directly to root.

On the windoze servers clearly individual accounts who are members of a security group which has assigned privs.  STILL on this setup, there are occasions where the actual server admin password are required (though they are admittedly rare)

[Eclipse]

In a CAP context there is nothing, no-thing, which requires the level of account security that even a small company needs.

Nothing we're doing online at the local level should have anything to do with finances, continuity of the organization, or
really even mission opsec.  That's all handled by national systems, so concerns about "root" passwords, especially
among trusted agents at the command level, should be a non-factor.

[kratclif]

In a CAP context there is nothing, no-thing, which requires the level of account security that even a small company needs.

Nothing we're doing online at the local level should have anything to do with finances, continuity of the organization, or
really even mission opsec.  That's all handled by national systems, so concerns about "root" passwords, especially
among trusted agents at the command level, should be a non-factor.

I can think of a lot of potential situations where having a shared root password could be a large problem for CAP.

Suppose a unit has a simple web site (or social media account) with a shared password. Then something happens and objectionable material shows up on that public site. There is now a large PR nightmare. You can bet that CAP will want to know who was responsible for it. How are you going to tell who-done-it if everyone is using the same credentials?

Sure, no confidential data was breached and nobody violated mission OPSEC procedures, but not being able to trace the source of the issue back to an individual is a serious problem.

There are times when shared passwords are needed, such as with software that doesn't allow for multiple accounts. Most modern sites I'm familiar with do allow for multiple accounts though, and it really isn't necessary to share a password. For example, web sites often allow for multiple SFTP accounts,  Facebook can have multiple administrators, and Google Apps can have multiple admins.

My suggestion (if anybody cares, LOL) would be to create a separate account for each member requiring access, and one for CAP NHQ IT if required, for each hosting provider whenever possible.

Kevin

[Eclipse]

Suppose a unit has a simple web site (or social media account) with a shared password. Then something happens and objectionable material shows up on that public site. There is now a large PR nightmare. You can bet that CAP will want to know who was responsible for it. How are you going to tell who-done-it if everyone is using the same credentials?

It's not a "PR Nightmare"  - no one cares. Websites get pharma and xxx spammed all the time.  No one is going to think CAP put it there purposely.  You take it down and move on.

Having a root / superadmin password also doesn't mean it's actually even in use, or "everyone is using it".  It can be in a continuity
envelope at higher HQ.  Used if needed, ignored otherwise.  Again, units are not doing ecommerce or other secure transactions,
and if the whole website goes *poof*, big deal.   It's back up in an hour.

[JeffDG]

Suppose a unit has a simple web site (or social media account) with a shared password. Then something happens and objectionable material shows up on that public site. There is now a large PR nightmare. You can bet that CAP will want to know who was responsible for it. How are you going to tell who-done-it if everyone is using the same credentials?

It's not a "PR Nightmare"  - no one cares. Websites get pharma and xxx spammed all the time.  No one is going to think CAP put it there purposely.  You take it down and move on.

Having a root / superadmin password also doesn't mean it's actually even in use, or "everyone is using it".  It can be in a continuity
envelope at higher HQ.  Used if needed, ignored otherwise.  Again, units are not doing ecommerce or other secure transactions,
and if the whole website goes *poof*, big deal.   It's back up in an hour.

Actually, I generally set up logging on "Admin" or "Root" logins, and investigate every single time they are actually used.

[kratclif]

Actually, I generally set up logging on "Admin" or "Root" logins, and investigate every single time they are actually used.

Same here, almost. There isn't a usable root account on any of my (non-CAP) production servers, but I log all sudo attempts and get a daily summary.

But we are getting off-topic from CAPR 110-01; this link should get us headed back in the right direction: http://cheezburger.com/3947751424 

[JeffDG]

And back on topic for their password complexity rules:

[Eclipse]

To that end I've gone with a less-complex password and 2-factor authentication.