Unexpected server reboot equal security incident?

In practice do you consider a unplanned/unexpected server reboot a security incident?

I know that in theory it does (security incident = unexpected event) but I want to know what does everyone PRACTICE?

Further, what's the first step in your response process (security incident or not)? Contact the system administrator or the security office? If security office is not available is the system administrator allowed to act without security?

I'm looking into the possibility of implementing this in my company and am looking for information regarding how others handle this 'event'.

Thanks

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

Continuity and reliability are also part of your security. So yes, I consider it a security incident. I for one would definitely like to know why this server unexpectedly rebooted. It could mean anything though. From a DoS to a plain old hardware failure. But it threatens the reliability and continuity and it should be fixed a.s.a.p.

It is an (IT) incident for sure, but not necessarily security incident. As SirDice said, it could be just plain old hardware failure. Or, an OS/application problem.

Generally speaking, incident is any event that is not part of the standard operation of a service and that causes an interruption (or reduction) in the service quality. Standard operation is defined within the Service Level Agreement (SLA) to users.

Some companies implement incident management for handling incidents. Users would call a help desk/service desk "agent" who record the incident. The agent is then the 1st level support, and has a checklist procedure and access to some monitoring tools. If s/he can't determine the root cause, s/he can escalate the incident (and turn it into a problem) to the appropriate 2nd level support, like the system administrator. When the problem has been solved, the agent will notify the user and close the incident.

Peace always,
<jdenny>

Hi. I voted no. Mainly because after an unplanned reboot, a security problem does not first come to mind. I will usually think hardware problem and chase that.

But maybe I should change my thinking. In my neck of the woods, with the NOS's we use, server reboots don't happen too often.

Quote:

---

Continuity and reliability are also part of your security. So yes, I consider it a security incident. I for one would definitely like to know why this server unexpectedly rebooted. It could mean anything though. From a DoS to a plain old hardware failure. But it threatens the reliability and continuity and it should be fixed a.s.a.p.

---

I am with SirDice on this one.

"security" includes the integrity of your data and applications. Re-booting in mid-flight could corrupt both? that potential would also have to be addressed as part of your remedial preocedures.

:)

I would say yes also. Unexpected reboot can have bad consequence (Downtime if your server is a public one like eCommerce) and it should be thread as critical.

Quote:

---

Originally posted here by ric-o
Further, what's the first step in your response process (security incident or not)? Contact the system administrator or the security office? If security office is not available is the system administrator allowed to act without security?

I'm looking into the possibility of implementing this in my company and am looking for information regarding how others handle this 'event'.

---

If you want to impress your boss, try and implement ITIL.


Now I've got a question in return (I already know the answer ;) ) :
Do you consider backups to be part of your security?

I think IT security is a component of the total information assurance umbrella not the other way around.

An inconsistant database due to random reboot can but does not have to be a direct security
incident per se.

A single random reboot or shutdown is cause for alarm and investigation but not a total DEFCON 5 freakout.

Having an implemented incident response plan is always a great idea. Regardless of severity, it's a good idea to report up the chain of command any incident to ensure proper communication and documentation.

The original Security (CIA) Triad was confidentiality, integrity and availability. If the server is not available it is an incident.

Since 9/11 security has changed as discussed in many articles including this one

What's happened to availability?

http://www.nwfusion.com/columnists/2...schwartau.html

where he discusses the new triad that has emerged

Quote:

---

A new security triad, CPP, redefines the three main areas of security: Cyber (computer, network and information security), Physical (the wires, silicon, glass and structures) and People (employees, consultants, suppliers, partners and anyone in contact with your company).

---

Quote:

---

Originally posted here by SirDice
Do you consider backups to be part of your security?

---

Ah, good one. Yes I do...however implementation could vary. I personally consider backup policy definition a decision by the business (along with any regulations, etc) along with security providing input. Security office is then the 'custodian' of backups but may not actually DO the backups...that could be the IT operations function.

Some good comments everyone. You are reminding me of the best practice in security management that says an unexpected reboot is an EVENT but not necessarilly a security incident. That is to be determined upon initial assessment of the situation...and may actually change from being considered/classified as a security incident to a non-incident later in the investigation.

I personally consider availability as a security matter - to me that's a no brainer as it's part of what you're taught in security training and one of the triad (as noted by whatthe). But I do not feel that security is the actual implementer nor maintainer of the systems responsible for that. That's another no brainer. Just because security is responsible for availability doesnt mean they manage the networks, manage the backup systems, manage the systems....of course they dont...they coordinate with those responsible parties and also implement/maintain policies governing them. I digress a bit here.

Great comments...keep 'em coming.

Quote:

---

Originally posted here by whatthe
The original Security (CIA) Triad was confidentiality, integrity and availability. If the server is not available it is an incident.

Since 9/11 security has changed as discussed in many articles including this one

What's happened to availability?

http://www.nwfusion.com/columnists/2...schwartau.html

where he discusses the new triad that has emerged

---

While I appreciate the writers intent, I think he left out some important considerations.
Those of us that fight daily with CFO's to get funding for process and policy, run into companies revenue and budgetary hurdles that must be addressed. So once again there is the "perfect" world and the "current" world and the reality of creating solutions to problems with limited resources.
Sure, some orgs get it right and allocate resources in a way to provide the necessary tools to do the job but many do not and the reality is they are not just going to pull the plugs due to a poor security profile.

This column is VERY typical of current writing on infosec issues.
Allot of feel good theory without much substance in regard to specific recommendations to
solving specific problems.

Thanks for the link!!!

Most people summed up the important points. I'll still throw in my 2 bits...

First, you need to define what an incident is. Second, you need to define the scope of your incidents. This pretty much is where events come in. Event 1 and Event 2 mean that an incident level 4 has occured. Incident level 4 may translate to a hardware issue. The key here is not to have too many or too few incident levels. Seven would be the max. This makes trending and reporting much easier for you.

So, I voted, it depends. A reboot is an event. A defined incident is the culmination of events.

--TH13

Hi. I just felt I shoud add, it's related to topic of thread.

I pretty much follow same or similar as majority of other posters posted, but If I see network gear such as a managed switch or router freeze/crash/reboot out of the blue (especially if it happens twice in a row on same device), alarm bells start to ring in my head until I have ruled out a security incident, and then I start to treat it as an event and chase hardware networking troubleshooting steps.

It might be common sense for some of the more expeirienced, but perhaps not for others. Just thought I should add.

:-)