Re: viruses that have been cleaned or quarantined

[Tim Doty <tdoty () MST EDU>]

On 06/22/2017 12:46 PM, Frank Barton wrote:
> This is a touchy subject...

I agree, it is a touchy subject.

> If the infection was contained before it was able to launch/take hold
> (i.e. AV prevented a file from being downloaded, or accessed after
> download), then "cleaning" is somewhat of a mis-nomer. remove the
> infected file, and you're all set.

Or not. Without forensics, how do you really know that nothing was executed?

As you say, this discussion is pretty much missing any context. The 
problem is, the more context that is applied the more specific and the 
less generalizable any comment is.

But for what its worth, my approach is based on accepting that, in 
general, we cannot know for certain whether or not a machine is infected 
and then taking action based on risk. This relies a lot on context and 
the specifics of the situation drive the decision making, but there are 
just three paths:

1. Take no action. Example, low confidence alerts don't warrant action. 
We would be putting out fires all day if we tried to address every alert 
or notification. Some sort of triage is necessary in order to ensure the 
important situations are dealt with.

Any time a rebuild is required (case 2 or 3) the system is blocked from 
the network until that has been done.

2. Three strike rebuild: user is informed of the situation and the three 
strikes. They are asked to rebuild the system. The first time we take 
their word for it, the second time we remind them of consequences before 
taking their word, and the third time we require the rebuild be done by 
support staff. This is for cases where there is high confidence in the 
compromise, but the danger resulting from continued infection is fairly 
low -- or for cases where our authority is less clear -- and is 
predominately used with student-owned systems.

Users typically employ their "cleaning" software of choice, but a clear 
and unequivocal statement that they have reformatted and reinstalled the 
system is required in order for network access to be restored. This is 
to have a clear case for dealing with repeat detections. Mostly this 
"works" (as in, not detected as infected after unblocking), but 
occasionally there is a recalcitrant user who refuses to accept that 
their system has been compromised. In the end, it is "comply in order to 
have network access restored".

3. Rebuild. May involve investigation depending on the nature of the 
alert and the system in question. Most lab computers would simply be 
rebuilt, but the compromise of an HR employee's system is likely to 
result in an investigation.

This method works well in our environment, mileage will vary. For 
infections that fall into the second category there is some leeway which 
is part of what makes it work for us.

In the end there are undoubtedly compromised systems on our network as a 
result of either no detection or failure to take action. And there have 
almost certainly been instances where a system was actually completely 
cleaned by AV and was reformatted and reinstalled anyway. You can only 
have so much certainty, and the closer you try to get to 100% the more 
costly it becomes.

> I've had cases where I had to give people the bad news that their data
> was lost. I found the key in those discussions is to make it easy for
> them to have server-side storage that is backed up regularly.

Our support staff have procedures for backing up a user's data before a 
reformat and restoring data from that (antivirus scans can be done at 
this point to reduce the risk of reinfection). Of note: infections can 
reside in any backup, particularly when the time of first infection has 
not been authoritatively determined.

So while I definitely subscribe to the "when in doubt, flatten and 
rebuild" group I do acknowledge that there is wiggle room, all depending 
on context.

One last thought: for an environment of any size there is going to be a 
need for quickly installing and deploying systems, whether for new 
users, failed hardware, or some other reason. By leveraging this system 
for dealing with compromised computers the cost of rebuilds is low and 
user impact minimal. This gives reasonably good certainty that the 
system is clean (but did you verify the drive's firmware? the bios?) 
without breaking the bank.

Tim Doty

> Frank
>
> On Thu, Jun 22, 2017 at 8:13 AM, Garmon, Joel <garmonjs () wfu edu
> <mailto:garmonjs () wfu edu>> wrote:
>
>     Very good thread.
>
>     There is another nuance that I consider in reviewing AV alerts --
>     was it caught in a real time scan (meaning the first time the file
>     was downloaded or used and stopped before executing) or in a
>     periodic scan (daily or weekly scan which means the virus has been
>     on the system for a while and already executed)
>
>     We also have special groups for departments that handle PII and have
>     alerts set up so we know when any virus hits these groups.  We
>     review every alert associated with PII.  This is a team effort
>     between security, service desk, and desktop support..
>
>
>     Thank you,
>
>     Joel Garmon
>     Director Information Security
>     Wake Forest University
>     336-758-2972 <tel:(336)%20758-2972>
>
>     http://infosec.wfu.edu/
>
>
>     On Wed, Jun 21, 2017 at 4:52 PM, Kevin Wilcox <wilcoxkm () appstate edu
>     <mailto:wilcoxkm () appstate edu>> wrote:
>
>         On 21 June 2017 at 15:50, Chelsie Power <cpower () csusm edu
>         <mailto:cpower () csusm edu>> wrote:
>
>         > If your virus scanner has cleaned or quarantined a
>         virus/malware/etc., do
>         > you do any additional scanning or followup on the endpoint? I
>         know virus
>         > definitions, though up to date, may potentially just be
>         catching a virus
>         > that have lived on the machine for several months and had only
>         been recently
>         > identified. Do you trust that "cleaned" means it took care of
>         any damage
>         > that had been done, if any?
>
>         Chelsie -
>
>         I see no difference between AV and IDS. The idea that AV can
>         "clean" a
>         system is one that I'd like to see eradicated.
>
>         That's not to say that it's impossible - just that it takes
>         known-good
>         cryptographic hash values for every file on the system, a trusted
>         off-system scanning agent and good alerting when something changes.
>         That's before having the same thing in place for registry hives, the
>         ability to detect/audit ADSs, etc.
>
>         If AV alerts on anything, and I can't otherwise determine it's a
>         false
>         positive, it's a re-image of the system. Again, AV alerts are
>         treated
>         the same as IDS alerts. There are some exceptions where it's profile
>         removal/recreation but generally speaking that's insufficient
>         for most
>         of our environment.
>
>         One massive hole to that approach - we backup data, re-image and
>         restore. If something is hiding in one of the backed-up files, it
>         comes back on the newly-built system.
>
>         It's certainly not perfect and needs some work but I've done too
>         many
>         forensic examinations of systems to trust that AV can do anything
>         beyond alerting on 25% of the stuff that's out there.
>
>         kmw
>
>
>
>
>
> --
> Frank Barton
> ACMT
> IT Systems Administrator
> Husson University

--
Information Technology
Missouri University of Science and Technology
Suite E 215E – PCRMC Annex
1100 West 10th Street
Rolla Mo. 65409-1150

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature