The Rules

I turned down a system last month. It needed a user to be permanently logged on at the server console, which implies a password shared among the support team. The chances of that being tough and regularly changed are nil, so my vote was no.

We'll see if I can make that stick! But I'm content, because I've only applied a published policy. Project people think that security imposes strange and unnatural demands on system design, and I suppose it's true that the demands puzzle people. But they're not unnatural and they're not arbitrary -- just misunderstood. So as my contribution to public education, taken from the handout I send to project managers, support people and anyone I can find, here are the rules. They way I present them is a checklist -- tick every box and you're on the right track.

First we have the Exemption Checklist for changes and small implementations -- Tick every box here and I won't bother you:

• No file, folder, registry or mailbox permissions changed or created.
• System is explicitly permissioned by our standard groups and does not rely on “Everyone”, ”Authenticated Users”, ”All Users”, 0x??7, “Domain Admins” or ”Administrator” permissions to work.
• No Windows local or global or Unix security groups are created, deleted or changed in meaning.
• No impersonal domain user accounts (service accounts), or any local or Unix or special device user or admin accounts are a) created, b) get new group memberships or c) are admins.
• All human users and administrators use their regular personal Insight workstation or app/admin/Unix accounts, and there are no shared accounts, and no non-Insight users.
• No changes to external data transfers, network security configs (firewalls/acls) or external accessibility.

For larger changes, I need to hear about it earlier. Here's the standard advice for project managers contemplating a new system. Again, if you can't check every box, we need to talk:

First, how about Unattended Processing (UP)? That's any processing other than discontinuous console session on a user or administrator workstation.

• All UP is on a server platform?
  (Servers are physically inaccessible. Console access is only granted to IT support users.)
• All UP runs as a service or scheduled task?
  (Not on the console or in a terminal session.)
• All UP runs without administrative privilege?
  (Not as Domain admin member, nor as server local Administrators member, nor built-in administrator including Local System)
• All UP runs without a profile?
  (No requirement for logons using service a/c.)
• All UP credentials stored in Windows SC password store?

Then there's Authentication of Users and Administrators

• All work done with personal accounts?
  (No shared users)
• Users and administrators authenticate using Windows workstation domain logons?
• Users and administrators authorised by membership of domain global groups?
• No user or admin credentials stored?
  EG in scripts or config files. (DPAPI and SC list storage is permitted.)

And finally there's the Application Structure itself

• Admin privilege can be withheld from business users without impeding function?
  (Users are not admins -- we can keep admin functions on the support desk.)
• Conformable with our app access model?
  (Role/Environment groups allow us to manage permissions through the helpdesk, using standard tools)
• All resource access via application-specific group membership?
  (Excluding: Domain *, Everyone, Auth users…)
• Administrative and security events logged in a supported means?
  (syslog, ftp upload, Windows event log, text file)
• Will be supported on platforms kept patched up to date?
  (No vendor qualification of Windows patches)
• Documentation identifies all resource permissions, and sensitive locations
  (config files, private keys)?
• All Internet/external access via authenticated proxy?

Once every application can check off all these, we will be getting somewhere.