Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2005-03-28 InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Infocon Changes; Remote DOS

Published: 2005-03-28
Last Updated: 2005-03-28 17:54:11 UTC
by Chris Carboni (Version: 1)
0 comment(s)

You Are The Driving Force

Taking Our Medicine

(Can I have some sugar with that please?)

One reader writes ..

"I agree with other comments that the almost constant green status makes the indicator something I don't consciously check any more. If it changed off of green, I'd probably miss it."

Ouch! I can't think of a better reason to change.

Next Steps

Suggestions have been arriving at a steady pace and continue to be discussed internally.

While no decisions have yet been made as to what the end result will be, it looks like the group consensus is for change.

One way you can help us determine what the best changes are, is to answer our new poll question.

Thanks for all the suggestions and keep 'em comming!

A Contrasting View

Ken writes ..

"Dear SANS,

I believe the Infocon Status monitoring is perfect where you have it. If its remained green for so long that nobody cares, then you must ask yourself why doesn't anyone care? Are we borded with no events occuring warranting a higher status?"

The question, in my mind, is what events warrant a change?

Another reader writes ..

"I'd prefer the criteria for changing the infocon level not be changed. However, if changes must be made, please take care not to make it over sensative, i.e. a new virus spreading through common methods (an .exe, .scr, .pif email attachment) or increased activity/new vlunerability on the "hack me" ports that should be blocked at the firewall anyway should not trigger a change in the infocon."

Another reason to upgrade XP to SP2

Shortly before we received an e-mail from Pavel, fellow handler Jim Clausing alerted us this morning to a vulnerability announced in XPSP1 that would allow a remote (authenticated) non-administrative attacker to shut down an XPSP1 system running remote desktop.

Details are available at

0 comment(s)
Diary Archives