My questions are very general. I need to test some behaviors from ATP on files and certificates with TIE. With files everything was very intruitive and easy. Like importing, detecting a new files, blocking a file with malicious reputation, etc. However, with certificate I haven't find a way for TIE to detected a new installed certificate or even to import the example in TIE product guide:
When imported, the page proceed to the Import Certificate Reputation Summary with all my imported XML informations but when I press OK nothing happens.
So, first of all, I would like to understand what is the certificat behavior in TIE? I mean, on which actions on the endpoint the reputation will be asks on the DXL fabric? On installation of a certificate? when signing or encrypting with a certificate? etc.
Secondly, without more information than the previous one in the TIE product guide about certificat importation, what do I lack for it to work?
thank you very much for your help !
TIE interaction with certificates is limited to signing certs used on the binaries that we evaluate. We do not inventory or access machines cert stores, etc. When a file is first launched ENS ATP will send TIE a reputation request for the signing certificate. We value the reputation of the signing cert prior to the individual file hash. If the certificate reputation lookup returns a good/bad then the appropriate action is taken against the file. If no certificate reputation is available the endpoint will then query for the file hash.
Manually importing the signing cert details is not required. If a file is run that is signed by that certificate....it will show up on the TIE Reputations > Certificate tab
Thank you for your help, it explains a lot. I would like to reformulate just to be sure because there is not a lot of information about certificates in TIE. You said : When a file is first launched ENS ATP will send TIE a reputation request for the signing certificate. So, a request will only be sent to TIE for a certificate when launching a file (which is signed by that certificate) that we enabled the file type in Configuration | Server Settings | Threat Intelligence Exchange Server | Enabled file types. So, the following test should trigger something in TIE:
With .exe files enabled, If I create my own certificate and I signed the .exe file. Then launch the .exe file. TIE Reputation > Certification Tab should show a “Unknow certificate rep”.
Then you said: When a file is first launched ENS ATP will send TIE a reputation request for the signing certificate. We value the reputation of the signing cert prior to the individual file hash. So, if a signed file is launch once (signed by certificate 1), then launch again (the same file with the same file hash) but signed with another certificate (certificate 2) will ATP send another request?
I understand that Certificate interactions in TIE are bound to files. No certificate is evaluated or populating the TIE database if not use on files managed by TIE. Am I right?
Otherwise, are there any other scenarios (actions with certificates) that would trigger a request from ATP for a certificate?
Finally, for the importation I understand that I don’t need to import manually, that using a certificate will make it show up on the TIE Reputation page, but I like to understand every detail of what I’m using. Do you have an idea why the import fails? In the future I’ll have to import reputations for of our own certificates because they won’t be recognized by any other reputation authorities. So, I’ll have to manually override the reputations after the endpoints detecting it or Import what we already got in lab.
Thank you again for your help! Have a nice day,
I believe you have opted to open an SR with support on this subject, so I will provide assistance to the assigned technician there. I will try to answer these current questions but future work can continue through the SR.
TIE server only stores certificate details for the signing certificates of executables. The end goal being providing meaningful file reputation to requestors. If a known signed file is run, it is much more efficient both from a product stand point as well as from an administrative standpoint to trust the authors of said files. For instance, Microsoft has a large number of signed files on your system. If an early request for reputation deems that the MS signing certificate should be trusted....than any future requests for files with the same digital certificate will automatically be trusted.
This is also true for certificates you wish to override. For instance, if you have your own in house development building applications. You can trust their signing certificate in TIE and any apps/future apps they build will automatically be trusted as well. Instead of having to issue overrides for every executable they create.
To answer a few of your direct questions:
"So, a request will only be sent to TIE for a certificate when launching a file (which is signed by that certificate) that we enabled the file type in Configuration | Server Settings | Threat Intelligence Exchange Server | Enabled file types. So, the following test should trigger something in TIE:"
The configuration you refer to is specific to TIE server and the file types it will allow to be stored in it's DB. However it does not control the requestors. For instance, in this case we are likely referring to ENS ATP, which only evaluates processes on execution. Meaning only executables. You could add "Office Documents" to the TIE configuration, but that would not cause ENS to start evaluating them. It's evaluation would be limited to word.exe for instance.
"Otherwise, are there any other scenarios (actions with certificates) that would trigger a request from ATP for a certificate?"
No, we only evaluate the digital signature of executables on launch of the process.
"Do you have an idea why the import fails?"
With the information provided no. However it seems you have already opted to open a service request on this topic. I would recommend all future work on the subject be handled through that SR. I will provide assistance to the assigned technician.