wissel.net

Usability - Productivity - Business - The web - Singapore & Twins

Securing your CxO's mail file


In a recent customer session the question popped up: How can you really secure your inbox against unauthorized access including access by nosy admins. The admin part can be particularity hard since by definition administrators should have the ability to administrate which can mean to access your file. In Domino you actually can lock down the environment, even if you have to go quite a number of steps. It is a typical case of "who controls the controller" This is my wash-list
  1. Encrypt the database on the server
    This encrypts the database, so on the server only the server.id can access this database. On a server this is what actually happens. The server task identified by the server.id is the only one that actually accesses the database (physically). All other server or users get access via that server. Encryption here protects the database from being stolen physically (e.g. when the server is shut down and the NSF is copied or someone gets hands on a backup tape)
  2. Set the property: Enforce consistent ACL
    This enables local security. So anybody who might have access to the database in an un-encrypted location can't open it if the name is not in the ACL.
  3. Remove any group or wildcard entries from the ACL
    That is a little bit a tricky one (and somehow dangerous). Typically the group LocalDomainServers and LocalDomainAdmins is in the ACL. So an attacker could bribe the admin and get her name added to the group. Without the group entry that is not a possible attack vector anymore. Of course you need to make sure that all servers (especially in a cluster environment) where the mailfile is have access to the database.
  4. Ensure that all ACL entries have an entry type
    Since we have removed all groups only the entry types "Person" or "Server" would be feasible. The only 2 entries without a type are -Default- and Anonymous which both are anyway set to "No Access". This setting prevents that someone accesses the mail file as a user using a server id.
  5. Limit access to hardware
    As the old rule goes: if you can't touch it, you can't break it. Good practice here is also to give server ids a password, so if someone gets a copy of an server id (stolen backup tape) it wouldn't help.
  6. Switch on "Compare Public Keys"
    in the server document. This prevents an attack using a forged or outdated ID file. An ID file can be forged if someone stole the cert.id and the cert.id password. (Which should be fiercely protected anyhow).
  7. Secure your certification process
    Several steps here: make sure your cert.id has multiple passwords (I suggest 6 passwords with 2-3 needed). So no single person can create new users on her own. Also implement the CA process and actually remove the cert.id from access of anybody. Move the creation of users into the responsibility of a different group than server administration. This limits temptation to play with black accounts.
  8. Set preferences to: Encrypt incoming email.
    With this option set all incoming messages will be encrypted. Even if and admin gets full access.... without the notes.id she can only read the subject lines but not the content of the messages.

    Use that with care and proper ID management. If the Notes.id gets lost so go the messages!


In theory that would be all.... If IBM hadn't on pressure from the users introduced the concept of "FullAccessAdmin". As the name nicely goes... the Full Access Admin has full access. So to go full circle measures have to be put in place to safeguard the activation of "FullAccessAdmin" mode. Here you go:
  1. Create a special user
    for the sole purpose of being the full access admin. Slap multiple passwords on the ID. Make sure it is locked away and never stays unattended. Make sure only that name is in the full access admin field in the server document.
  2. Lock down your name and address book
    Demote access to the NAB or put other measures in place (a loooong topic) to make sure an admin can't change the server document to add him as full access admin.

Posted by on 23 June 2008 | Comments (6) | categories: Show-N-Tell Thursday

Comments

  1. posted by Kevin Pettitt on Monday 23 June 2008 AD:
    Nice list Stephan. Re: #2 on enabling "Enforce Consistent", that is not going to protect you if the attacker has a local replica of the database. ScanEZ, and perhaps other tools as well, can "Unset" the enforce consistent flag with a couple clicks (as I just proved to you Emoticon wink.gif) even if you can't open the db in the Notes client.

    The value for me of "enforce consistent" for local databases has always been that it will allow any role-based interface elements to function properly (e.g. hide-whens).

    How was the jungle?
  2. posted by Philip Storry on Monday 23 June 2008 AD:
    Some comments...

    1. Encrypt the database on the server

    Check to make sure this has no adverse affects with regards to backup and antivirus systems. It should be OK, but testing would be very wise as it's by no means a standard configuration, and might cause issues.


    3. Remove any group or wildcard entries from the ACL / 4. Ensure that all ACL entries have an entry type

    You mention LocalDomainServers - if this group type is specified as Server Group, then it will remain secure even if a Person is added to that group. Since R4, the Type specifier on an ACL has allowed groups/entries to specify what kind of connection is to be made.
    This bypassed the famous R3 and earlier method of gaining access, which was to take the ID file for the server (which often had no password) and switch to it in your client.
    As such, you can leave server entries and groups in the ACL providing that they have the correct Type specified.
    Also, be aware that it's not uncommon for Admin groups to contain the access for things like monitoring software and utility code. If you run anything - in or outside the mail template - that does automatic housekeeping on mail databases, then it will need access. Removing the Administration groups will probably cause an embarrassing failure in this case - check the DB history to see who/what's accessing the database before doing ANYTHING to the ACL.


    5. Limit access to hardware

    Get the CEO to sign off on the use of passwords on server ID files, as it has obvious availability issues - specifically, if you add a password then the server will sit there waiting for it in the event of a restart due to failure.


    8. Set preferences to: Encrypt incoming email

    I would strongly recommend against that, for the following reasons:
    If the ID file has to be recreated for whatever reason (failure of ID recovery, etc.) then your CEO loses all access to their mail. The mail also becomes unreadable in a web browser (unless you have an X.509 certificate), and may be unreadable by remote devices like Blackberries etc.
    Worse, this could also affect discovery in legal situations, and may be against policies for the archiving and retention of email as required by regulatory bodies in your industry.


    Otherwise, a good list.

    I'd add that you should also ensure that the Database History is recorded - it's sometimes turned off for performance reasons, but can be very useful in post-incident analysis or even just for ongoing monitoring.

    Of course, I'd argue that you should seek to use more social engineering to keep your administrators happy, and therefore reduce the likelihood of them peeking anyway.

    And measures which remove my access as an Administrator mean that diagnosing problems will take longer, or may not be possible at all. That should be stressed before any of this is done, and the CxO should sign off on the fact that they're aware of this. Otherwise, at some point their security requirements WILL clash with their support requirements, and nothing in this world will fix their problem until they grant access.

    Lastly, I'd also point out that in my current job, if my CxO asked me to implement this list, I'd also HAVE to report them to the corporate governance/compliance team. That's because just asking (without evidence of wrongdoing) could be regarded as suspicious, and should be investigated.

    Frankly, if a CxO is this paranoid, it may be better to write up a tool which tells them who accessed the DB in the last 24 hours, and how many reads/writes they did. Drop that in an email each day, and let them (or more likely,their PA) monitor accordingly.

  3. posted by Dave Harris on Monday 23 June 2008 AD:
    re #6, I'd also add check password. so that a lost/compromised ID file can be locked out. Other than that, It all depends on how trustworthy the administrators are. Most of the measures above can be defeated if an admin has Manager access to the NAB (and someone has to, in the end, in order for the estate to function smoothly).
  4. posted by ursus on Monday 23 June 2008 AD:
    Hi Stephan

    I had the same request a couple of weeks ago - I am still of the opinion that this cannot be done with any measure of success. My problem with your "lock-down" would be that the admin's need to know the server password (to restart a server) and could therefore always get around your lock down. Basically all you need do is copy the server.id, copy the mail file and then use the server.id on your local machine to access the mail file.

    Or have I missed something?
  5. posted by Dave Armstrong on Monday 23 June 2008 AD:
    This is really more than any IT org should have to worry about. At some point, the business just needs to trust their employees. Even with everything you outlined above, a group of disgruntled admins could, together, get out the full Admin ID and poke away.

    Security is not a technical issue, and never has been. It is a business issue, to decide what level of risk is acceptable, and to then have a technical implementation that mitigates that risk.

  6. posted by Darren Duke on Wednesday 25 June 2008 AD:
    I agree with 5. But, if you really are that paranoid, put all the "important" mail files on a separate server and lock down access to it via Domino security (crap, you can even use a partitioned server you don't want to buy new hardware). Only give access to the server to a single IT person or a consultant who has more to worry about than reading someone else's email (and they are liable too, just ensure they have errors and omissions and employee liability insurance).

    Then follow the suggestions above, except don't would not encrypt it. And server passwords cause issues all unto themselves.