FireEye Endpoint Security FAQs

FireEye Endpoint Security (FES) is a small piece of software, called an 'agent', which is installed on servers and workstations to provide protection against common malware as well as advanced attacks. FES combines the best of legacy security products, enhanced with FireEye technology, expertise and intelligence to defend against today's cyber attacks. Based on a defense in depth model, FES uses a modular architecture with default engines and downloadable modules to protect, detect and respond to security events.

  • Why FES? How was it selected?

  • The short answer is because it works, it enables better response and investigation capabilities, and last but not least, because the cost is subsidized by the UC Office of the President.

    The UC System selected FireEye as our Threat Detection and Identification (TDI) solution several years ago. Initially, the primary focus was on deploying network detection capabilities but those technologies do not extend beyond the campus network and did not address issues at the local IT system level. Additionally, with more and more Internet traffic being encrypted, network-based detection solutions are somewhat limited in their effectiveness.

    Because FES is installed locally, it solves those problems. The protection provided by FES continues no matter where the IT system is located. Additionally, because FES operates at the system level, it can detect malicious activity that may occur even if the inbound or outbound network traffic is encrypted.

    IT Services was an early adopter of FES and had it deployed in our data center on most of our servers. We have seen firsthand where FES has prevented a security event. Other UC campuses have started adopting FES and have reported similar results.

    Last year, the UC suffered from a significant security event costing the UC over 1 million dollars. In reviewing the root cause of the incident, it was determined that FES could have prevented the event. After this event, the UC Office of the President decided to extend coverage of the TDI platform and fund the deployment of the FES agent for all campus locations.

    Because FES is part of the existing TDI platform, the campus benefits from the 24X7 FireEye Security Operations Center monitoring and the collective intelligence of the entire platform. This combined with the cost savings of having the solution subsidized by UCOP and the benefit of a "single-pane-of-glass" for our security team provides efficiencies and improvements in security posture.

  • What does the FES Agent Do?

  • The FES agent delivers advanced detection capabilities that will help UCLA Information Security and IT professionals to respond to threats that bypass traditional endpoint technologies and defenses. It uses detailed intelligence to correlate multiple discrete activities and uncover exploits. Endpoint visibility is critical to identifying the root cause of an alert and conducting a deep analysis of a threat to determine its impact and risk. 

    The functions of the agent include: 

    Malware Detection/Protection (Not Supported for Linux) 

    FireEye's Endpoint Security Agent malware protection feature guards and defends your host endpoints against malware infections by automatically scanning all files (upon read/write/execution) on your host endpoint for malicious code. Malware includes viruses, trojans, worms, spyware, adware, key loggers, rootkits, and other potentially unwanted programs (PUP). Malware protection uses malware definitions to detect and identify malicious artifacts. 

    File quarantine 

    Malware protection has two components: malware detection and quarantine. Malware detection, which includes MalwareGuard, utilizes two scanning engines to guard and defend your host endpoints against malware infections, the Antivirus engine, and the MalwareGuard engine. Quarantine isolates infected files on your endpoint and performs specific remediation actions on the infected file. This is similar to traditional off-the-shelf antivirus solutions. 

    Exploit Detection/Protection (Not Supported for macOS or Linux) 

    This is a Windows-only engine. Exploit detection uncovers exploit behaviors on your host endpoints that occur during the use of Adobe Reader, Adobe Flash, Internet Explorer, Firefox, Google Chrome, Java, Microsoft Outlook, Microsoft Word, Microsoft Excel, and Microsoft PowerPoint. The following are examples of the exploit types that can be detected in these applications: 

    o Return-oriented programming (ROP) attacks
    o Reverse shell attempts in Windows environments
    o Heap spray attacks

    o Application crashes caused by exploits
    o Structured Exception Handling Overflow Protection (SEHOP) corruption of programs
    o Null page exploits
    o Microsoft Office macro-based exploits
    o Java exploits
    o Access token privilege escalation detection
    o First stage shellcode detection
    o Drive-by downloads
     

    Real-Time Indicator Detection 

    Threat activity intelligence is collected by FireEye and made available to the Endpoint Agent products as indicators of compromise (also referred to as indicators or IOCs) through FireEye’s Dynamic Threat Intelligence (DTI) cloud. Endpoint Security uses the Real-Time Indicator Detection (RTID) feature to detect suspicious activities on your host endpoints. RTID monitoring uses FireEye indicators to detect the following: 

    o Unauthorized use of valid accounts
    o Command and control activity
    o Known and unknown malware 
    o Suspicious network traffic
    o Valid programs used for malicious purposes 
    o Unauthorized file access
    o Trace evidence and partial files

    Host Containment (Linux support in version 34 an above) 

    The host containment feature is a function that will ONLY be performed with the approval of the Information Security Office manager and/or CISO in the event of a high severity detection, and the Security Office is unable to engage the system administrator for immediate containment action. This function enacts a host firewall that will restrict all network access to the host with the intention to prevent lateral movement or data exfiltration by the threat actor. 

    Incident Response Triage Acquisition 

    This is a function that allows Information Security and FireEye analyst(s) to execute acquisition scripts on the host as it pertains to a detected threat. The scripts vary in content based on the operating system (OS). 

  • Where is the FES Agent being deployed?

  • The FES Agent is being deployed to all UCLA owned systems (workstations and servers). While personally owned devices are not mandated at this time, any system that will store, process, or transmit university data can have the FES agent installed. 

    It is important to understand that installing the FES agent on a personally-owned device will give UCLA Information Security staff and FireEye staff access to the same level of information on these devices as they would have on a UCLA owned device. This does reduce your personal privacy on that device but provides you with additional protection as well.

  • How is FES being deployed?

  • FES is being deployed through local IT Teams in collaboration with the OCISO Security Operations Team and Professional Services provided by FireEye engineers. There are three modes of deployment:

    • Self Managed - Unit IT is provided direction but they largely handle the implementation to systems on their own.
    • Fully Managed - OCISO and FireEye do most of the heavy lifting to implement on systems in the local Unit.
    • Partially Managed - Local IT, OCISO staff, and FireEye work together on the implementation of the agents on local systems.

    The typically deployment schedule is done in four phases:
    • Pre-Deployment: OCISO and FireEye staff meet with local IT to go over the process, expectations, and timelines, as well as answer any questions the local IT unit, may have.
    • Deployment: This phase can last up to 4 weeks and is where the agent deployment begins and any exclusion lists are developed. During this phase, the local IT team will typically deploy the agent to a sampling of IT systems at first and then to the larger population of systems. The OCISO team validates deployment via the FES console in collaboration with the local IT Unit.
    • Baselining: This phase typically lasts 2 weeks. During this phase, the teams work through any false-positive findings and fine-tune the agent for the Unit. This is also where Unit notifications are established and Prevention mode is enabled.
    • Validation: For the final week, the teams work together to validate the list of systems that have been included in the deployment and they test system features such as host containment and triage acquisition. A final step is to document any lessons learned during the various phases.

    This phased approach has been implemented across campus with the goal of having all UCLA-owned assets covered by December 31, 2021.

  • On which Operating Systems does it run?
  • FireEye offers clients for most versions of Windows, MacOS and many Linux variants, specifically:
     

    • Windows 7, 8, 10

    • Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019

    • MacOS 10.9-10.15, 11

    • Linux

        • RHEL 6.8-6.10, 7.2+, 8+

        • CentOS 6.8-6.10, 7.2+,8+

        • Ubuntu 14.04, 16.04, 18.04

        • SUSE 11.3, 11.4

        • SUSE 12.2, 12.3, 15

        • OpenSUSE 15.1

        • Amazon AMI 2018.3, AMI2

        • Oracle Linux 6.10 & 7.6

  • Can I install it on workstations, servers and VDI environments?
  • Yes, all of these environments are supported.
  • Do I need to uninstall my old antivirus program?

  • The FireEye Endpoint Security solution is designed to replace traditional anti-virus software (e.g. Sophos) and provide enhanced security and privacy through its use of multiple product engines:  

    -Indicator of Compromise (IOC) collects real-time events continuously on each endpoint (e.g.changes to file system, live memory, registry persistence, DNS lookups, IP connections, URL events, etc.) to instantly confine a threat and investigate the incident without risking further infection.

    -Exploit Guard applies behavioral analysis and machine intelligence techniques to evaluate individual endpoint activities and correlate this data to detect an exploit.  It allows for rapid response to new threats and false positives (e.g. heap spray, ROP, web shell exploits, crash analysis, Java exploits, Office macro exploits, SEHOP corruption analysis, unattended download, null page exploits, network events, special strings, OS behavior analysis, etc.)

    -Anti-Virus—powered by Bitdefender—allows for a real-time or scheduled scan of all files for Windows and MacOSX.

    -MalwareGuard uses machine learning classification of new/unknown executables. It is signature-less with a small client footprint and works in conjunction with the Anti-Virus engine. It has a disconnected model that does not require cloud lookups or constant model updates.

  • Will FES protect me against ransomware?

  • Yes, FireEye will recognize the behaviors of ransomware and prevent it from encrypting files.

  • Will FES slow down my system?

  • The FES client uses a small amount of system resources and should not impact your daily activities. However, each application and system is unique, and Information Security encourages all admins to install and test the agent in their own environment to validate that system and application performance remains acceptable.

    In some situations, the FES agent may be impractical to install and maintain. While these situations are likely limited, we do have an exception process that can be utilized to request and exception from implementing the FES agent.

  • How does the exception process work?
  • When a situation arises where FES is impractical, the Unit IT personnel can request an exception. Once the Unit IT has filled out the exception request the Unit Head (typically the Vice Chancellor, Vice Provost, Dean or University Librarian) will review the request and authorize it for consideration. The exception request will then be presented to the Campus Chief Information Security Officer (CISO) for review. If the risk posed by the exception request is reasonably mitigated, the CISO can approve the risk. In cases where the risk is not sufficiently mitigated, the CISO will forward the request to the Cyber-Risk Responsible Executive (CRE) for review. The CRE has the final authority on granting or rejecting an exception request.
  • Does FireEye Endpoint Security protect me while I am disconnected from the internet (such as during traveling)?

  • Yes, the client will protect against malware threats when the device is disconnected from the internet.

  • What can the FES Agent see and who has access to it?

  • The FES agent only collects logs normally created on your system. The types of logs collected are:

    -Image load events                           -Registry event
    -Process Lifecycle events                 -DNS lookup event
    -File Write event                                -Network event
    -URL event                                        -Endpoint IP address change

    This data does not leave your system unless an event is detected and usually only stays on your device for 1-6 days. If an event is detected, a subset of the logs are sent to the FireEye HX Appliance, a UCLA owned and operated, physical server in our data center. This data is referred to as alert data. In some circumstances, the FES agent will pull a snapshot of system activity 10 minutes prior to the incident and 10 minutes after the incident. This data is referred to as security event metadata (this is also referred to as a triage package). Data sent to our HX appliance is retained for a period of 1 year. 

    FireEye security operations also receive alert data and security event metadata sent to our internal appliance. This information is provided to FireEye and UCLA Information Security for investigation. No additional data can be reviewed without confirmation of an incident and specific authorization/approval consistent with the UC Electronic Communications Policy and UCLA Policy 410 : Nonconsensual Access to Electronic Communications Records. 

    If an investigation is warranted, the UCLA Security team can pull a full triage package using the FES agent. This capability allows our internal investigators to pull all of the log data available in the local system buffer (typically 1-6 days worth of logs). This is simply pulling additional logs not, individual files, and this data is not automatically shared with FireEye, it is only available locally.

    The FES console does allow our internal team to pull an individual file however, this is a manual process and only done in consultation with the local IT contacts in connection with a security event detection. Any files that are acquired by the internal security team are not shared with the FireEye team unless they are engaged to provide support during a significant security incident. FES only supports multiple file copies via API commands or recursive raw disk capture (Windows-only) which would first require hands-on enumeration of physical disks within a system (via Command Line Interface). This approach is not only extremely time-consuming but impractical from a storage limitation and bandwidth perspective. Neither of these methods would be part of any routine process.

    FES does not have the capabilities to do a full disk copy. Any investigation that requires a full disk image would require either the consent of the individual or authorization under UCLA Policy 410 : Nonconsensual Access to Electronic Communications Records. The acquisition of a complete disk image, if authorized, would not be performed by FES due to the limitations and lack of completeness cited above.

    The FES console provides a full audit trail for any information that is accessed by FireEye or the Information Security Office. This audit trail can be inspected by our internal auditors and campus leadership or other governing bodies determined appropriate by leadership.

    All data sent to FireEye during the course of operations is retained in their US datacenters for a period of one year. Any access to UCLA data is governed by our Electronic Communications Policy and contractual provisions which require a "least invasive" review. 

  • What does it mean to contain a host?

  • Attacks that start at an endpoint can spread quickly through the network. After the identification of an attack, FES enables Information Security to isolate compromised devices via the containment feature from the management console in order to stop an attack and prevent lateral movement or data exfiltration. Essentially, this feature allows UCLA Information Security to isolate a single computer, preventing it from communicating with any other devices until the investigation has been completed. Information Security will then conduct a complete forensic investigation of the incident without risking further infection or data compromise. 

  • Can I stop/start/remove the FES agent after install?

  • Generally speaking, once the FES agent is put into blocking mode it can not be stopped or removed by anyone other than the Information Security team. However, during the onboarding process, the local IT Unit can have a "break glass" password set. This will allow the local IT Unit to remove the FES agent if mission-critical systems or applications are impacted.

    If the agent blocks a legitimate service or application, the local Unit IT team can work with the Information Security team to restore the service or application. If mission-critical systems are impacted, local IT can also use a "break glass" password to remove the agent and restore services but only after it is confirmed that no legitimate threat exists.

    Extreme caution should be taken when using the "break glass" process. This can expose your system to compromise and could expose the campus to additional security exposure. It is important that the local IT team work with the Information security team to restore the FES agent to normal operation as soon as possible. 

  • What happens if the Information Security team receives a subpoena or other request for this data?

  • Responding to subpoenas is governed by UCLA Policy 120 : Legal Process - Summonses, Complaints and Subpoenas and UCLA Procedure 120.1 : Producing Records Under Subpoena Duces Tecum and Deposition Subpoena. Any legal process served to the Information Security Office is immediately forwarded to Campus Counsel for disposition. We do not release security-related information to law enforcement or other entities unless directed to do so by counsel. If and when legal counsel authorizes a release of information, counsel reviews the information before providing it to outside agencies.   

    Internally, at the campus or system level, this data is not released except in the course of an authorized audit, and even in those cases, great care is taken to release only the minimum necessary data. Provisions are being made to allow authorized individuals from a Unit to request a review of any access logs pertaining to systems or users within that Unit.

    The data collected by FES is generally considered 'Computer Security Sensitive Information' which may be exempt from public records disclosure. This data is not released without consultation with legal counsel. 

     

Get Help

Our Information Security staff is on hand to answer all of your questions about FireEye. If you have any questions, please contact the Information Security Office at security@ucla.edu.

Go to FireEye Security Website