If you tell enough stories, perhaps the moral will show up.


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.

No comments: