3

We are considering a certification process for new internal server builds before they are allowed to be placed into production. That is, the system administration team will send the server up to the security team to be certified. Once the security team approves the server as certified, it will be sent back to the system administrators to be placed into production.

What common criteria should the server be evaluated against before it is "certified" and ready for use? Additionally and secondarily to the main question, how often should the server be re-certified once it is allowed to be placed into production?

3
  • What OS are you talking about?
    – Kenzo
    Feb 7, 2013 at 5:26
  • This would be for Windows Server 2003, 2008, 2012. Additionally, it would be for Linux distributions of SuSE, CentOS, RedHat, Ubuntu.
    – John
    Feb 7, 2013 at 5:41
  • Red Hat hardware certification: redhat.com/rhel/compatibility/hardware
    – Kenzo
    Feb 7, 2013 at 6:34

1 Answer 1

3

A lot of this will depend on your environment, but this is a generalised list I've used before (I've included compliance stuff under each point):

  1. All software patched and linked into a patch manager
    • Your patch manager should patch often and alert loudly if a machine falls out of compliance.
  2. All unnecessary ports closed
    • Set up nagios or similar to run a port scan regularly - alert if anything new opens.
  3. All unnecessary user accounts purged
    • Again, you should watch this with your monitoring and enforce it with GPO or similar.
  4. All unnecessary software removed
    • Get rid of all the debug stuff, you should ideally be logging every installation so you can check it off as 'uninstalled' in your first pass.
  5. Server linked into log server
    • You want it to alert you if anyone logs on interactively, if it gets rebooted, if anything happens really. What you care about will be environmentally specific.
  6. All alarms and alerts on log server configured
    • This relates to 5 - but check that all your alerts and alarms are appropriate - turn off any you will ignore so you don't end up habitually ignoring errors.
  7. End protection configured and hooked up, incl. application-level firewall and AV
    • You should centrally manage this, and as with the patch manager, alert if non-compliant. Turn on an application-level firewall and only allow stuff you want to connect in/out. Block everything else.
  8. All necessary software whitelisted
    • Now that it's in production - scan the system for all software you want to run, whitelist it and block everything else. This will be environmentally specific, and you need to work it in with your patching.
  9. Time synchronised
    • This is critical; a lot of the above all relies on timing working - AV, logging, etc.
  10. Network configured, all non-prod interfaces removed
    • Physically unplug, uninstall, disable, whatever is appropriate - make sure there is no link back to your test or dev environments.

The servers should be tested continually - you want to continually and automatically check with your monitoring and automation. The stuff you can't check automatically, look at as often as is practical.

The idea is that a recertification should just be to glance at a report, tick off that everything is green, log on, check the last few things and you're done in less than 10 minutes.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .