Our case: <4-17441502971> currently at DEVELOPMENT after almost 4 weeks of waiting and OUT of ORDER TIE
As you must have seen the SR was escalated to Tier 4 and
the content team is reviewing the file / logging provided. As soon as we
receive feedback we will update you.
EMEA Business Support Product Lead – Malware / McAfee
Support Threat Escalation Group
OMG, this really sucks..... 😕
Dear community Support.... this thread is not finished, how can i Change back the Status of the thread
We already had the 137 from BEOBACHTEN (MONITOR) to AKTIVIERT (ACTIVE). This did not solve the case.
I wonder IF any other TIE rule may have an influence on this case.
Just upgraded ATD from 3.8 to 4.0 and we are happy that we can scan SMTP attachments. Since Mcafee discontinued Mailgateway and we are are Foritnet partner we used FORTISANDBOX to date for this.
I am glad we can to that on the ATD now. Was always a point we did not understood why it's not implemented and already almost started to code something ourself which rips out the attachment from Fortisandbox and puts them onto the ATD.
Gruss aus der Schweiz
Latest Info MCAFEE will TRY to handle those NEW ASSEMBLY as far as possible through the NEXT TIE Defintion update WHICH would come out 1 month OR more (Just so you think it's NOT next week).
Existing RULES 137, 138, 139 only cover those partly currently wiht the latest file from MS Patchdays 04/05/06.
We see a huge problem in using TIE at stage block all files at "UNKNOWN" like first wanted if they need 2 months for such a change...
Not convinced this solves the issue. I still had a lot off files being detected and send to ATD. Sending the files to TIE is one thing but uploading them to ATD for analyzing is something else. This just puts a huge load on the ATD box.
I know this is not Mcafe fault because it is Microsoft that generates the files unsigned and unique hash.
Does McAfee discuss this with Microsoft ?
One other suggestion I want to make is why not using techniques like in Application Control to link the files to the updating process from microsoft to influence the rating.
Knowledge is in the McAfee products just use it.
Adding the updater/installer technology fom application control into TIE would make it a very powerfull tool and not just for this.
We also wanted to end with putting TIE in a block "unknown" state.
This is not possible at this moment minimizing the return on investment for the TIE licenses.
I still have not a lot more security than before. What was bad should be blocked by VSE. Good should be allowed.
It is the grey stuff I want to block.
Yes you are right to be fair that a MICROSOFT problem or behavious. BUT (Mcafee Developer did not know?) it's well documented in MSDN Microsoft Development network since years.
The discussion we currently see is not IF Mcafee talks with Microsoft. The discussion we see if the ENS Department DOES talk to ATD or TIE department within MCAFEE.
We currently have the problem with the Framework Assembly on TIE/ENS ATP-Module and new the ATD-Sandbox. I did hear some states like yes BUT that's with the ENS team now from a TIE-engineer.
One of the MAIN marketing pushers now suddnely turns back. If all talks together (ATD/TIE/ENS/MWG/NPS) and soemthing is reated WRONG than it's wrong RATED on all points within an enterprise.
If they ATD rated an IASTOR driver as MEDIUM and TIE/ATP bocks a storage driver on all client machines WE don't need no NotPetya...
We have a new addiotional problem. The Deep Neural Network Prediction module from the ATD 4.X does rate the Assembly DLL as MEDIUM. https://community.mcafee.com/thread/111233
Your are right Mcafee also has to do more and indeed on Focus 2016 they announced it would be solved but a half a year later we indeed haven't seen any progress. Maybe until the assembly stuff is fixed we get som free ATD boxes to cover the load when microsoft releases security patches and a free mcafee engineer to change the enterprise rating manually in TIE so we can put TIE in blocking for unknown ;-).
Hi, am wondering if others are still seeing this in their environment?
We continue to see this on our side, and am curious if there is now a fix, or we are still waiting for one.