Hey Hey,

I don't, personally, think that a reboot is enough to indicate a security incident. The concern may exist, but if I trust the safeguards in place, I'd first lean towards hardware issues... this comes in to play expecially with very new (relatively ununsed and therefore untested... may have conflicts with other parts of the server) and older software that may be on it's way out.

As far as handling, bring it back up (offline if you're suspicious) but check on the Event Log or /var/log/messages or whatever depending on the operating sytem... See if there's anything in there to explain the reboot. Also check if anyone was working around the error... I've seen lots of cases where people have tripped over a power bar or knocked a plug out and just put it back in real fast and snuck away because they don't want to accept blame.

As far as procedures.... that company policy should already be in place.... A call list is the best way... As for the security office.... Physical security should already be accounted for.. Any server rooms should be alarmed so that security is notified if the reboot is caused physically while no one is around. As far as proceding with or without security.... that again depends, if you have an outside party doing physical building security, do you really want them around your equipment? Are you authorized to access the room on your own (as the sys admin)?. The biggest thing for unexplained lockups/reboots/etc is to have a call list in place... Security (should it be reported to them) should know to contact the on-call technical support (if there's currently one in the building)... otherwise a list of technicians/administrators should be created and an order in which to contact them if there is a problem.

This is what I see around the office (for the most part) and what I've learned in class anyways... Some of the more experienced people will probably have a better answer.

Peace,
HT