locked
EMET Follow-up RRS feed

  • Question

  • Assuming support for a group of workstations that are logging their EMET events centrally and wondering how folks react to and follow-up with user EMET mitigations.  Is the assumption that EMET protected against a real threat and if so are there efforts to isolate the cause/source of the mitigation and is this done proactively or reacting to a user complaint?  Should one assume that the mitigation and application shutdown took care of the immediate threat and another tool (or EMET) will address the problem going forward.  Freely admit my age and lack of technical skills but have done a good deal of log reviews preceding and following mitigations without identifying the source.  In some cases, it appears that the application was crashing prior to the EMET mitigation being fired so perhaps naively assume that the application fault caused the EMET event.  Would be interested in hearing how others determine the validity of the mitigation and what follow-up activities should take place.  Is is worth having someone look at the machine forensically?  Are there other tools that allow some rapid assessment?  Large parts of my environment is comprised of non-persistent virtual desktops so could have the user log off which shuts down the machine and they will pull a fresh image when they log back on.  If the problem is associated to a specific file then assume that I have only temporarily escaped the issue.  Have posted other threads about EMET Service and Agent failures and am not able to explain those and the percentage is high enough to concern me --- low from a percentage across total machines but significant as part of the total EMET mitigations.  What's a "normal" number --- have heard other organizations say that they rarely see them.  Would love to hear how the smarter folks are handling these things?
    • Edited by JimLKelly2 Friday, September 18, 2015 12:40 AM
    Friday, September 18, 2015 12:40 AM