paradroid wrote:
I still see Patch 5 on the download site... Isn't it time to revoke this ? Or at least come up with a fix ?
No, it's not.
This isn't the place if you were looking for any kind of official response to that first question. However, if you're open to a candid response to the candid question, then allow me...
The issue reported is of Access Protection exclusions not working, meaning we're talking about the "Processes to exclude" portion of an AP rule.
In our own testing of the feature pre-release we saw no such issue; had we done so we would've investigated prior to releasing the patch (reason #1 why we experience schedule delays). But that fact tells us, with respect to your own experience, that there is something more to this issue than simply having an exclusion.
This alone is reason to _not_ pull the patch, because you'd be affecting all customers based on the unconfirmed report of one. I open myself to 2 possible lashings there in saying it's unconfirmed and that there is one report only. So let me tackle those real quick -
- It's unconfirmed at this time, meaning, the behavior is still being investigated. This investigation work must conclude so we can assign the appropriate disposition of this behavior being a confirmed bug or why it's not a bug. The downside of anything being investigated is that it takes time to investigate, requiring the patience of those waiting for results. And sometimes that is a lot to ask but sadly a lack of patience does not hasten the investigation process, it only makes the process more unpleasant for everyone . We experience this ourselves when trying to hit release dates, so "Isn't it time" and "at least [do something]" are familiar expressions.
- It is one report at this time, being a measure of the number of customer escalations we have received to date for this behavior. Surely there are more customers than yourself who has experienced this right? Yes, I'm sure. But we have no data to tell us how many customers would see the same behavior or who do see the same behavior. When the investigation concludes we'll have a better idea of the potential scope of impact.
What do we know is that 1 report (or even 10 for that matter) for a behavior that isn't immediately apparent is not sufficient cause to make a judgment call that affects everybody; so the patch is not being revoked.
We also know it is a behavior that does need investigating, it needs to be understood with all its nuances (and mitigating factors if it is a bug) because it is impacting at least 1 customer. This is in progress. And as stated earlier, we'll update our Known Issues KB article if there's a bug here. We might need to update the article even if it's not a bug. We'll see.
What we might learn from this is that our testing should be expanded to include your scenario - I'm sure management types will clue in on that one.
Something I've learned from this is that Access Protection continues to be one of the least understood features of VirusScan Enterprise - because you sought to downgrade the software over this issue, rather than disabling a single AP rule and wait for the behavior to be researched; that's like finding out you have a tooth cavity and opting for a complete set of false dentures to fix it, then asking for the cavity to be looked at. Total overkill! But maybe it's because you found yourself in a desperate situation, which I think you alluded to earlier that had you been the one in control there would have been more testing done beforehand, but immediate action had to be taken instead of spending time looking for a workaround. That all makes sense to me. Even so, it still tells me that this Access Protection feature is not well understood because the knee-jerk response was to downgrade instead of looking at the Access Protection log file, or the Events coming in from ePO, telling you which rule was being violated... which would let you know the simple option was to disable that rule. (So, for everyone who's reading this: Please read my Blogs )
And I haven't forgotten your comment about this being reported months ago. I still think folks are going to be kicking themselves for that if this is confirmed to be a bug. I have some input there for when that comes up as an internal discussion, believe me.
And to your final question, a fix cannot be had until a) a bug has been found, and b) a fix is deemed plausible, and then c) a fix is deemed necessary. For customer-impacting issues if (b) is possible then (c) is a given; the question then becomes "when".
William W. Warren | S.I.R.R. | Customer Success Group | McAfee
You Deserve an Award
