I have a few questions about the TIE Reputations in ePO. After running the TIEScanner, which is unsupported as I am aware, I have just under 45.000 files in my TIE database. Some of these files have a GTI reputation, others do not. At this point, it is unclear to me why some files have GTI reputation "Not Set" and others have a reputation of "Not Available". The GTI connection was always available during the TIEScanner process and almost all files in my TIE Server come from clean Windows 7 and Windows 8 installations. In other words, the whole setup is very stable and I imagine that GTI reputations are available for all files in fresh Windows installations as they are benign files that can be found on almost all workstations in the world.
Another thing that strikes me about the TIE Reputations is that when I sort the files in alphabetical order, I get around 275 files with no information as can be seen in the screenshot below:
Interestingly, there is no file name, no certificate information or anything else indicating which files I'm looking at. In some cases however, there actually IS a TIE reputation available for those files. That means there is a hash for it and sure enough, this is displayed under the file details. But there is no indication of which file this is. When I check the "Where Has File Run" option, it becomes clear that my Web Gateway has encountered these files (yeah, I connected that one too). I read that Web Gateway cannot publish any information to DXL yet, but the files are in the TIE database sure enough...
So these are my questions:
1. Why isn't there a GTI reputation for all default Windows files?
2. What's the difference between "Not Set" and "Not Available" reputations?
3. Is the Web Gateway file reputation going to improve in future releases? It would be very helpful if there was an easy way to identify files seen by specific products under TIE Reputations
4. Is it possible to remove reputation records from the TIE Database? In some scenario's, I think this would be helpful. For example to remove the MWG reputations that are pretty useless at this point in time, but in other cases as well.
Be carefull with my answers ;-) because I just started playing with it.
=> check if there is a related certificate with a rating. This should be the case.
I had discussion with engineering and as far as I can test, for all "not available" rated files, there is a certificate with a rating.
this depends on the product so if GTI is giving this, it should be that GTI doesn't know this file
In addition to your findings: I'm seeing the same behavior, where quite a bunch of files don't have any info like File name, product name, company name, etc. The only values that actually have a value are the hashes.
|All File Names:|||
|All File paths:||Not Available|
|Enterprise Reputation:||Not Set|
|GTI Reputation:||Not Available|
|SHA-256 Hash:||Not Available|
|Certificate SHA-1 Hash:||Not Available|
|First contact:||Not Available|
|Last update:||Not Available|
|File Name count:||0|
|File Path count:||0|
|Signed Bits Hash:||0|
|Last Detection name:|
|Local Reputation minimum:||Not Set|
|Local Reputation maximum:||Not Set|
|Local Reputation average:||0|
|Pre-Prompt Reputation minimum:||Not Set|
|Pre-Prompt Reputation maximum:||Not Set|
|Pre-Prompt Reputation average:||0|
|Parent Reputation minimum:||Not Set|
|Parent Reputation maximum:||Not Set|
|Parent Reputation average:||0|
|Good Reputation count:||0|
|Bad Reputation count:||0|
|ATD Reputation:||Not Available|
|MWG Reputation:||Not Available|
Information like "Where has file run" can be used and show me that it originates from a Windows Server 2012 installation. Additional info like certificates are not available.
TIE has reputations but no file information
Information from Intel Security:
"There is a known issue with the current TIE client. The TIE-Client is able to send 2 kinds of information to the TIE-Server. Only the basic information, which means the hashcode and the Reputation. Or the complete set of information like filename, certificates etc (also called Meta Data).
Usually the complete set of information should be sent to the TIE-Server, at least for the first reply from the TIE-Client to the Server.
What you have here is only the basic-information were sent.
There is no chance in the moment to get this changed, but there is a case open for this in engineering.
Intel Security expect to get this solved in a future version. There is no date when this will happen.
Well, here we are some time later and I still don't have this resolved.
Today I have installed the product again in a test environment that is very simple. It looks like this:
1 Domain Controller that also has SQL and ePO (5.3.2).
2 DXL Brokers (3.0.1-something, latest version)
1 TIE Server (2.0.1-something, latest version)
I have one managed system, namely the ePO Server, that has Endpoint Security 10.5 installed, along with Adaptive Threat Prevention and the DXL Client. The whole situation is happening in the same VLAN, connectivity is fine. No special configuration has been performed, except we have ATP in Enforce Mode (verbose, it reports to the user). There is nothing special whatsoever in this configuration.
So, I said to myself, let's put it to the test. Start simple and go from there. I downloaded Rufus, a small tool used to image OS'es to a USB drive. I chose Rufus because it's a single, small executable, but I could have downloaded any executable. Running it, appears to work well.
So having a look at the TIE Reputations, it doesn't look like we've been moving to better things. Firstly, I was surprised that I didn't see the rufus.exe file and corresponding reputation after running it. I saw 3 files, none of them of particular interest. So it should be working. But no rufus-2.12.exe in any case. It wasn't code-signed, so finding it by certificate as a workaround is not an option.
The funny thing is that when I select the Unnamed Files preset, I see a whole bunch of unnamed files. With a little digging, I found it through virustotal. Antivirus scan for cdae63982321d72aacb332c44c57438ad4a10b829f76c93e5bf427f18df1170a at2017-02-16 15:...
So hey, why is the file unnamed? I was running it as a Domain Admin, the file name is rufus-2.12.exe when I run it... Why doesn't it show up, what's the deal with that? And more importantly, how am I supposed to find files like this? By the time I finished writing this message, I ended up with 59 named files and 109 unnamed files in my TIE Reputations. The Product Guide doesn't mention the issue at all, yet there is a special preset for unnamed files. The whole thing makes absolutely no sense to me.
As a matter of fact, with TIE working like this, it's not much use to me at all. I wanna do things like find a file by its name, check its properties, look up virustotal information, sandbox it with a big fat ATD cluster for my own pleasure, whatever. I want control over those files. But I need the file NAME in order to trace it as I am a simple mortal and seem to have trouble remembering more than 3 md5 hashes... Also, asking my users to run md5sum to identify files seems a little over the top to me.
So here are my questions.
1. Why are files unnamed in the first place?
2. How do I find unnamed files when I need to manage their reputations?
3. Is there a way to prevent files from being unnamed?
3. Is there a way to get unnamed files named?
Any help is greatly appreciated.
Update: After some time, the file appears to have a name indeed. Straaaaange.
In my environment, I'm trying to finish up testing ENS 10.5, including ATP/TIE. I currently have it on about 50 systems; I've got about 30,000 files listed with no filter, and 95,000 files listed if I filter by no filename (Filename --> Value is blank). I've got a support request open with McAfee; it's currently with the TIE Tier 3 team, who are going to speak with the ENS Tier 3 team, as it looks like ENS isn't sending info back (ENS response to TIE metadata query is empty). PS: You can remember 3 MD5 hashes? You're better than I...
...imagine how bad I felt when they released SHA256
It looks like some files initially are unnamed and sometimes they get named after a while, though most of the time they don't.
I'll consider this a bug and wait for a bugfix. Glad to know though, that this issue does apparently not adversely affect protection.
Would you be so kind as to post any solutions here when you get them? I'll be very interested to know.
It is really interesting to see this subject going on for 2 years and still no solution. I'm new on ePO and all the modules and we are suffering also with the same thing, thousands of files not identified and marked as "not set" as well by GTI ,where the connection is just working fine. I have escalated this on McAfee and no explanation at all, check this and that and still.
I'm still investigating this and I will post here if something new comes up.
Good to know that I'm not alone on this.
We're not talking about files with reputations not set; that's fairly normal for TIE. There's a host of reasons why a file doesn't have reputation set, but most boil down to McAfee hasn't had a chance to come to a determination about that file yet. This is where something like a Gold Image system with all your software installed on it comes in. Once you install the applications, let it sit for a little while, and from the System Tree, select the system and check TIE --> Show Certificates in use on system; anything without a TIE reputation should probably be set to Known Trusted. Then do the same with TIE --> Show files in use on system.
What we're seeing is entries in our TIE reuptations table where the File Name field isn't populated. There's no file name. So when we search for a file that should be in there, we can't find it. If you get the hash of the file, you can find it that way, but it doesn't seem to be retrieving the filename when it checks the file.
As an update to that, I'm still working with their Tier 3 support to find out why that's happening. We've so far done a full vacuum on the PostreSQL database, and updated all our endpoints to the latest 10.5.1; I need to collect some more MER logs today and send them in.