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.

[krnlpanick]

^^^  :clap:

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.

Chris's Rule #7 of Application Security, unused but enabled things are holes waiting for someone to discover.

Generally speaking, you wouldn't think anything of this, and there is no problem necessarily having an account that is that "superuser" or "contingency-user" per se, however - as was noted you want strong auditing on that user. Not only log auditing, but enabling alerting when that user account is accessed is also important. I have a few systems that have had similar "contingency-users" - if the user logs on, a file is accessed in that users home directory (read or write), or that user receives an email from a non-system account I receive a notification via email and SMS. Generally speaking, if someone is going to legitimately use that account for anything, I will know about it before-hand - so any time I receive that text at 0200 I am going to investigate immediately.

And back on topic for their password complexity rules:

First off, I <3 xkcd, arguably the best thing on the internet.

Human-Readable Passwords are the problem. I use 32 character randomly generated passwords consisting of uppers, lowers, numbers, and special characters. I use a password database to remember those passwords so I don't have to. I keep the key-file to that password database on a USB stick that is on my person, so if it is compromised I will know it. Doing that same math for one of my passwords:

My Random Password: ^j-}v& iKDvWC7_33w9M{z'%dF$A!E>N
Bits of Entropy: 165
2^165 = 4.68 * 10^49 Possible Combinations
1.483 * 10^39 Years at 1000/sec guesses

This results in me not having to remember anything other than where I put the key to my password database (or the backup of the key)

The problem is that we teach password complexity, but we do not teach implementation.

[Eclipse]

The problem is that we teach password complexity, but we do not teach implementation.

I agree.  I have a client with all manner of complicated security settings for their user IDs, and then they require everyone to have the actual password
on a post it in their drawer.

[JeffDG]

The problem is that we teach password complexity, but we do not teach implementation.

I agree.  I have a client with all manner of complicated security settings for their user IDs, and then they require everyone to have the actual password
on a post it in their drawer.

[a2capt]

.. and all this HIPPA stuff, I still find passwords written under keyboards, on the pull out "cutting board" ;-) thing on desks,  behind doors on the hutch, and .. even right on the monitor.

"It's too hard to remember, the software won't let me use the simple stuff" "If I use the finger print thing, then I can't call in and have people look up stuff they need, if I'm not here". D'oh!

[arajca]

.. and all this HIPPA stuff, I still find passwords written under keyboards, on the pull out "cutting board" ;-) thing on desks,  behind doors on the hutch, and .. even right on the monitor.

"It's too hard to remember, the software won't let me use the simple stuff" "If I use the finger print thing, then I can't call in and have people look up stuff they need, if I'm not here". D'oh!

Head, Wall. Wall, Head. Play Nice.

[coudano]

Don't forget,   your password has to be at least 15 characters, with 2 of everything, nothing too close to a dictionary word, AND you have to change them all every 6 months, and your password cannot too closely match anything that has been your password in the last 12 months...

Quite frankly, *I* write down passwords, for the systems I have to use that have stupid rules like this (and I generally abhor writing down passwords).

I don't keep them in the drawer, under the keyboard, or on the monitor.  But they are written down.
Really, I try to avoid using systems like that as much as possible, but sometimes it can't be avoided...



There is definitely some over-reaction there, and there is a "stupid line" that you cross, where you actually make your stuff less secure, by making the policies too strict.

[Phil Hirons, Jr.]

It is impossible to build idiot-proof software. The world keeps building better idiots.

[NIN]

I agree.  I have a client with all manner of complicated security settings for their user IDs, and then they require everyone to have the actual password
on a post it in their drawer.

I always like the Excel file with user IDs & passwords in the publicly accessible directory on the server.

Hackers assume its a honeypot.

[krnlpanick]

I agree.  I have a client with all manner of complicated security settings for their user IDs, and then they require everyone to have the actual password
on a post it in their drawer.

I always like the Excel file with user IDs & passwords in the publicly accessible directory on the server.

Hackers assume its a honeypot.

Insiders do not and a good hacker will profile his targets long before-hand knowing where the actual honeypots are.

My take, if you have enough time to store your user-id and password in an excel spreadsheet, it is really any more difficult to use software that was designed to store your usernames and passwords in a way that is secure. I use KeePass, which has clients for iPhone, Android, Windows, Mac, and *nix as well as browser plugins for both Firefox and Chrome that allow you to bypass the need to even have the database "open" and auto-fills usernames and passwords for you so you don't really even need to interact with it - plus it generates secure random passwords that you don't know about thus eliminating the human factor from the equation altogether.

I have seen employment terminated for storing passwords in clear text - that one employee invalidates any compliance to any regulatory standards that an organization has to be compliant against - thing is, if that employee's spreadsheet provides passwords to either the insider to elevate their access or to the outsider to give them access to sensitive resources it is the organization that is punished with huge fines and legal actions, the employee gets fired and finds a new job where he does the exact same thing.

[A.Member]

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.

Umm, NO!!! 

No one should ever be in favor of using common IDs and passwords.  Contrary to implications later in your post, doing so does not align with any InfoSec best practices and is a direct violation of standards, such as PCI.  Each user should have a unique ID and password.  This allows for logging and tracking of activity. 

[JeffDG]

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.

Umm, NO!!! 

No one should ever be in favor of using common IDs and passwords.  Contrary to implications later in your post, doing so does not align with any InfoSec best practices and is a direct violation of standards, such as PCI.  Each user should have a unique ID and password.  This allows for logging and tracking of activity.

I've used a shared password at exactly one client...ever.

It was a high-security environment.  They were concerned to the point that they needed assurances that the IT folks could not get into certain parts of the system, even the CIO was not cleared for some of the projects.  That said, there was a need for administrative access to certain system functions at specific times.

Compromise was reached.  Two people were entrusted with half of the admin password each...and it was extreme, like 15 characters each...they each put their part of the password on a card, it was sealed in an envelope, initials on the seal, the whole 9 yards.  The seal had to be personally verified by both of them on a weekly basis (and it was written down in case one of them was hit by a bus), and changed once a month (with the original envelope being destroyed still sealed so nobody could find patterns in the passwords being set).

When it was needed, they both needed to agree, and would each enter their portion of the password, then they were required to observe the other performing the actions that required the admin account.  About 10 executives got alerts whenever the account was accessed, and a full report of why was due within 2 hours of access to them.

Beyond that, not a lot of need for shared passwords.

[A.Member]

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.

Umm, NO!!! 

No one should ever be in favor of using common IDs and passwords.  Contrary to implications later in your post, doing so does not align with any InfoSec best practices and is a direct violation of standards, such as PCI.  Each user should have a unique ID and password.  This allows for logging and tracking of activity.

I've used a shared password at exactly one client...ever.

It was a high-security environment.  They were concerned to the point that they needed assurances that the IT folks could not get into certain parts of the system, even the CIO was not cleared for some of the projects.  That said, there was a need for administrative access to certain system functions at specific times.

Compromise was reached.  Two people were entrusted with half of the admin password each...and it was extreme, like 15 characters each...they each put their part of the password on a card, it was sealed in an envelope, initials on the seal, the whole 9 yards.  The seal had to be personally verified by both of them on a weekly basis (and it was written down in case one of them was hit by a bus), and changed once a month (with the original envelope being destroyed still sealed so nobody could find patterns in the passwords being set).

When it was needed, they both needed to agree, and would each enter their portion of the password, then they were required to observe the other performing the actions that required the admin account.  About 10 executives got alerts whenever the account was accessed, and a full report of why was due within 2 hours of access to them.

Beyond that, not a lot of need for shared passwords.

I can't speak to what you did or that companies policies.  However, shared, interactive passwords in a prod environment will not pass any real security audit; no chance for complaince with standards such as PCI.   Trust me.

[Brad]

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.

Umm, NO!!! 

No one should ever be in favor of using common IDs and passwords.  Contrary to implications later in your post, doing so does not align with any InfoSec best practices and is a direct violation of standards, such as PCI.  Each user should have a unique ID and password.  This allows for logging and tracking of activity.

I've used a shared password at exactly one client...ever.

It was a high-security environment.  They were concerned to the point that they needed assurances that the IT folks could not get into certain parts of the system, even the CIO was not cleared for some of the projects.  That said, there was a need for administrative access to certain system functions at specific times.

Compromise was reached.  Two people were entrusted with half of the admin password each...and it was extreme, like 15 characters each...they each put their part of the password on a card, it was sealed in an envelope, initials on the seal, the whole 9 yards.  The seal had to be personally verified by both of them on a weekly basis (and it was written down in case one of them was hit by a bus), and changed once a month (with the original envelope being destroyed still sealed so nobody could find patterns in the passwords being set).

When it was needed, they both needed to agree, and would each enter their portion of the password, then they were required to observe the other performing the actions that required the admin account.  About 10 executives got alerts whenever the account was accessed, and a full report of why was due within 2 hours of access to them.

Beyond that, not a lot of need for shared passwords.

Jeff why do I picture this being your morning commute?

Michael Madsen in Wargames

[coudano]

Look, i've learned and passed test on, and gotten the alphabets after my title, all of the 'industry definitions' and 'best practices'.  They are a great baseline, and if you followed them verbatim, you certainly wouldn't be doing anything outright wrong.

At the end of the day though, information security is a practical application of policies based upon a balance of risk assessment vs functional needs.

I could train at least a dozen examples in front of you, where 'industry standards' are bent or broken in the interest of functionality or business needs, while still maintaining acceptable (risk calculated, and accepted) security levels.  Proper business policy documentation accomplished, auditor satisfied.

There is also a certain level of paranoia and trust that have to be balanced, and accepted as part of the risk of doing business.  You can separate out admin/root rights all day long, amongst a team of sysadmins, which is great, but they are still root/admin, and any one of them can still manipulate logs, to erase inappropriate actions, or even point the finger at someone else.  And look, at the end of the day, all of your admins probably have physical access, which is the same thing as just handing everyone the root password.  Unless you are going to put all your computers in a vault, and video record them 24/7/365, and require two person integrity every time someone physically touches a computer...  And so on.  Don't get me wrong, there are times and places where those strict measures are appropriate (and when they are, used them, by all means).  There are other times,   (like the CAP Squadron #123 webserver) when all of that is just silly, and you either trust your sysadmin(s) not to rip you off, or you don't...

I could also train (at least) four (PCI) auditors (that i have actually worked with) in front of you, who are complete morons.

That said, when CAP starts handling PCI or HIPPA or FERPA information, or other such information which comes with specific legal or regulatory baggage, then we can start talking about carrying that baggage.  If you don't have to meet those regulations (which no squadron website should), then it's silly to carry that baggage just because you can.  But don't let me quash your enthusiasm, knock yourself out



Here is a nice security centric white paper about the use of shared accounts in the 'real world' application of IT administration, versus the pristine world of theory (er, certification testing).
http://www.sans.org/reading_room/whitepapers/basics/administration-shared-accounts_1271

[NIN]

Many  years ago, I got the "Additional Duty" of "Wing Computer Guy" (I think it was on the personnel authorization as "Computer Consultant".. this was WAY before 110-1 and IT Officers). We were discussing putting a server in at wing, so that we had a central place for the Wing's administrator to put things, etc.

The wing commander says "Well, there is quite a bit of sensitive information that she has on her PC right now. I would want that secured in such a way so that not even the administrator can see it."

I told him "You can do it that way, but really, the administrator is going to have broad access, partly due to making the backups work, etc."

The wing commander makes a face and looks over at our Wing LO who was sitting in.

"What do they do in the Air Force?"

The LO shrugs. "Someplace in the bowels of the comm shop, there is a bored TSgt with the keys to the kingdom."

[a2capt]

The LO shrugs. "Someplace in the bowels of the comm shop, there is a bored TSgt with the keys to the kingdom."

..and he might bring in CD-RW's labeled "Lady Gaga" and do the swapperoonie on the contents..

Oh, wait.

[Tim Medeiros]

The LO shrugs. "Someplace in the bowels of the comm shop, there is a bored TSgt with the keys to the kingdom."

Add in a couple of airmen that report to said TSgt and that is right on the money 

[Devil Doc]

I have to remember numerous passwords at work. Not only that, we have to change them every 90 days. On top of that you cant use the same password twice EVAR!! Talk about frustrating!! I work for the Department of Veteran Affairs, so you know how locked down the VA is. Very time consuming when they all go out at once, takes you some time to change them.