MCAFEE MVision Endpoint 18.10 first view review

We just did finish our first look at the new MVSION Client when already a new Release came out the last days. https://kc.mcafee.com/corporate/index?page=content&id=SNS1746

This report reflects version 18.10.2.2.

Main reason business drivers for the MVSION version for us are:

  • AMSI integration and usage of Windows Defender as base pattern scanner (You can only scan malware where it runs in un-encrypted form > Thus only MS can do…) So powershell malware is captured by MS Windows Defender. Why not do it for the rest of the pattern stuff?
  • A slimmer Plattform for VDI solution where the FULL ENS Suite 10.6.X would be too heavy. We still think the full ENS 10.6.1 with ATP Module as 3rd module brings the best security together with TIE and ATD-Sandbox. We did take a look at MOVE but from a long term view this would throw the customer back 5 years from what he has NOW on FAT clients with the working suites. We are very happy with what the FULL ENS 10.6.1 does for all our customers from small to Enterprise. They key changer is just the packet storm, re-setup of VDI Clients.

Main reason we think Mcafee pushes MVSION:

  • Push the MVision Mobile Version > New company the bought > Zimperium
  • Push their SAAS Cloud

For the Cloud?

Here are some impressions from MVSION ONPREMISE. You don't want to manage EPO in Cloud when a brute force DOOS rips you LAN and WAN interface apart right? You also don't want an OUTBREAK when mcafee schedules their CLOUD downtime and reports to all malwares coder via SNS Alerts?

The 18.10.2.2 Package and Extension (EPO on premise)

Deployment of MVSION client fails if ENS 10.X on machine.

You can see the error in the Event

Run a JOB to Uninstall ENS from BOTTOM 2 TOP (Reverse order you install it)

After a reboot you can deployment MVSION client.

The Client show up on Windows 10

Here is the information you see in Agent:

 

Some Directory structure

Logfiles

Windows Defender appears as it did before you do not notice anything there.

Policies

First Exclusion GENERAL

 

Second Policy: EXCLUSIONS

Here what we clearly miss today is:

*The granular drilldown to exclude process on single functions

* The exclude with MD5. You don't want really FILESNAMES like 10 years ago?

We understand that Mcafee runs the simpler and were too complex line but this goes too far. We see the first problem here in the DUAL Management (1 Windows Defender and 2 Mcafee Module).

The Windows Defender does not allow Hash Exclusion and they wanted a central exclusion. We were so happy they finally included the ONE POINT Exclusion for VSE 8.8 Patch 12 bur here we miss something in the opposite way.

 

On existing EPO 5.9.1 you see following after integration of the MVSION POLICY

EPO GUI which has the same feel and look as under EPO 5.10 (New style….) Look like the new security vendor styles with lots of colors for managers.

Here they have colors on the TIE Server we had to beg for years so we see with GREEN OR RED of a file would run.

 

If you Like graphs in EPO 5.10 style? Well we have 73.7% because older server OS has to run older Mcafee Agents. On the other hand even a newbie sees now that there is VSE 8.8 Patch12 out OR 40% of the server has not been migrated (Maybe complex Exchange DAG cluster in isolated VLAN etc. or OLD Server OS) That was kind of never useful we think.

 

 

 

 

Browser Isolation V2.0 (Zusammen mit kommerziellen Proxy [MCAFEE | Symantec])

Ich habe einige neuere Präsentation zu neuen Webisolationen Konzepten angesehen. Arbeite selber zu 90% mit Mcafee seit 12 Jahren kenne aber diverse Symantec Enterprise Produkte von früher.

 

Symantec bewirbt derzeit Ihre Web Isolation Loesung. (Fireglass gekauft und integriert in Ihre Serie der Produkte)

 

Der key Punkt ist, dass dies bei Grossfirmen NUR in Verbindung mit PROXY und anderen Security Sachen effektiv ist. Und zwar so, dass die IT nicht immer manuell eingreifen muss läuft. (Bei 100% Browser Isolierung in Serie nach bestehenden Webfiltern).

Dazu kommen fast monatlich neue Public und Private CLOUD Sachen welche dann nicht mehr gehen. (Intranet Content in Cloud)

Symantec hat den Ansatz, dass nur unrated oder neue suspicious Sites der HTML5 Isolierung übergeben werden. Die Produkte

welche einfach alles zu 100% in HTML5 konvertieren hatten doch das einte oder andere kleinere Problem. Dann ging das manuelle Whitelisten wieder los.

Also nicht nur auf den PROXY (Fortiguard/Webgateway) sondern dahinter auch auf MENLO usw.

 

Web Kategorien waren zu kompliziert?

Alles zu 100% durchlassen geht dann wieder und vor allem in der Schweiz aus rechtlichen Gründen nicht.

Der Arbeitgeber muss dafür sorgen, dass der Mitarbeiter keinen Zugriff auf verbotene Inhalte hat wenn dies mit einfachen technischen Mitteln möglich ist. (Das nennt man Web Filter mit Kategorien > Fortiguard > Webgateway usw.)

 

Das Ganze und alles zu streamen klappte aber in der echten Welt dann doch nicht wie es sollte. Deswegen ist der Ansatz dort grosse Hersteller wie Mcafee oder Symantec zu wählen sicher die bessere Wahl.

https://www.infinigate.se/fileadmin/user_upload/Vendors/Symantec/Promotions/SE/Symantec_Isolation_Infinitech2018_presentation.pdf

https://www.symantec.com/products/web-isolation

 

Mcafee wird nachziehen da es keinen Sinn macht die bestehenden Lösungen und Infos welche man korreliert hat (TIE/ATD/SANDBOXEN/WEBGATEWAY) da nicht zu nutzen. Derzeit nur mit Partnern wie Ericom Shield.

Mcafee geht derzeit stark in Richtung Partner und OpenExchange (Tausch zwischen Herstellern) und Opensource Plattformen.

 

Einige Links in der Richtung:

https://www.mcafee.com/enterprise/en-us/assets/solution-briefs/sb-syncurity.pdf

https://www.mcafee.com/enterprise/en-us/assets/case-studies/cs-multinational-software-company.pdf

https://www.mcafee.com/enterprise/en-us/assets/solution-briefs/sb-ericom-shield-mcafee-web-gateway.pdf (ERICOM und Webgateway)

https://www.brianmadden.com/opinion/Why-hasnt-Bromium-taken-over-enterprise-antivirus-and-antimalware-yet

(MENLO VS Fireglass) Die damaligen Nachteile von Fireglass wurden ja jetzt mit der Integration in die Symantec Kette (Proxy) behoben und isoliert.

https://ignition-technology.com/wp-content/uploads/wp-content/private-uploads/Fireglass-Competitive-Comparison-Document.pdf

 

 

SYMANTEC

 

MCAFEE

So actual Fortinet could change their partner education ;-)

And by the way centralized management with one console is one of the MAIN bonus points from MCAFEE EPO-Server for over 10 years.

 

 

Event 10009 on Server 2008R2 Exchange 2010 Distributed COM

Event 10009 on Server 2008R2 Exchange 2010 Distributed COM

If you RUN:

  • Exchange Analyser
  • Powershell command get-owavirtualdirectory (Or any other command the connects to CAS to enumerate values)

This OBSOLETE and you COULD leave it as it is. If people from Event or SIEM are nagging you could solve it. We recommend leaving it as it is.

Behaviour:

You will see an EVENT 10009, Distributed COM in SYSTEM Event.

DCOM was unable to communicate with the computer CAS123.EMEA.butsch.ch using any of the configured protocols.

 

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778012(v=ws.10)

https://social.technet.microsoft.com/Forums/en-US/0c21a35d-1b9a-4ec4-a81e-c0ba388718d4/dcom-10009-error-every-night-shortly-after-midnight?forum=exchange2010

Solution: On the CAS Servers and also on the Server your get the Error do following:

 

SOLUTION1: Create a registry key: IgnoreDelegationFailure

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 (remark Butsch also to Server 2008R2)

HKLM\Software\Policies\Microsoft\Windows NT\Rpc\IgnoreDelegationFailure (If IgnoreDelegationFailure is not there make a new DWORD)

Set the value to:

0 = TURNOFF (As it is without the SubKey)

1 = TURNON

Stores configuration data for the policy setting Ignore Delegation Failure.

Solution2: Change GPO which sets the same key

To change the value of this entry, use the Group Policy Object Editor (Gpedit.msc) to do this local. The corresponding policy is located in Administrative Templates\System\Remote Procedure Call.

You can SET this by GPO from Active Directory but we do not recommend doing that for all your Servers. I would do a separate GPO and ONLY apply that to the Exchange Servers.

https://getadmx.com/?Category=Windows_10_2016&Policy=Microsoft.Policies.RemoteProcedureCalls::RpcIgnoreDelegationFailure

Samsung SSD + Bitlocker leak

Check if you are affected by the 11/2018 SSD Bitlocker Leak.

ADV180028 | Guidance for configuring BitLocker to enforce software encryption

Security Advisory, Published: 06.11.2018

Producer: Samsung and Crucial

Affected models proof: Crucial MX100, MX200, MX300, Samsung EVO 840, 850, Samsung External USB T3/T5

 

There is a leak with certain SSD Hard disk (Solid-state) together with Microsoft Bitlocker. If you ONLY use software encryption you should not be affected.

There is a limited possibility then that the producer of the SSD disk still does encryption without feeding that info upwards to the OS but as we understood those are really a small size of disk.

Original text Microsoft in Advisory:

 

Microsoft is aware of reports of vulnerabilities in the hardware encryption of certain self-encrypting drives (SEDs). Customers concerned about this issue should consider using the software only encryption provided by BitLocker Drive Encryption.

On Windows computers with self-encrypting drives, BitLocker Drive Encryption manages encryption and will use hardware encryption by default. Administrators who want to force software encryption on computers with self-encrypting drives can accomplish this by deploying a Group Policy to override the default behavior. Windows will consult Group Policy to enforce software encryption only at the time of enabling BitLocker.

 

Advisory Microsoft

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV180028

https://redmondmag.com/articles/2018/11/06/microsoft-ssd-security-advisory.aspx

 

Germans Ct Heise security Magazine

https://www.heise.de/security/meldung/Daten-von-einigen-selbstverschluesselnden-SSDs-ohne-Passwort-einsehbar-4212191.html

 

SC Magazine

https://www.scmagazineuk.com/ssd-encryption-security-failures-revealed-researchers/article/1498191

 

Samsung

https://www.samsung.com/semiconductor/minisite/ssd/support/consumer-notice/

 

Niederlande University

https://www.ru.nl/icis/news/recent_news/@1181122/radboud-university-researchers-discover-security/

https://www.ru.nl/publish/pages/909282/draft-paper.pdf

 

 

Here is how to check if you are affected:

Run elevated (Run as administrator)

Manage-bde.exe –status

 

This client is NOT affected since there is no Hardware Encryption:

 

Possible affected client (Check further if SSD model is affected)

 

 

Missing entry in Fortigate Application Filter ROOT.CERTIFICATE.URL and OCSP source of W10 Setup failing

Fortigate Application Filter Certificate wrong/missing Entry sample for an important laptop driver (W10 Deployment fails because of signed Driver Revocation Lookup)

OR HOW a missing small ENTRY I a FORTIGATE FIREWALL IPS/APP filter can ruin your Windows 10 OS-Deployment work.

 

Reason: Missing entry in Fortigate Application Filter "ROOT.CERTIFICATE.URL" and "OCSP" source of failing deployment

 

Windows 10 Deployment with commercial Deployment Products (This includes HP client hardware, Microsoft SCCM, Landesk or Ivanti Frontrange).

During the Unattend phase the driver for MASS storage or NIC does a Certificate Revocation Lookup. However the as sample mentioned

URL pki.infineon.com (Hardware Driver URL, CRL FQDN) is missing in Fortiguard definitions. Thus the Fortigate does block the access to WAN. Since this is an early setup phase of W10, group Policy or special GPO do not pull at that moment.

 

Fortigate has already missed several PKI URL the last few months confirmed by ticket resulting in large trouble and delay on client and Server OS of customers who route their Client or Server traffic through Web proxy and because of security do not want to route computer account proxy traffic standard to the proxy.

 

Why this is so important. Why this is generating a lot of work and trouble for OS-Deployment teams.

 

The normal way in larger companies is that all outgoing traffic from client VLAN goes to Firewall which it blocks. All Web/Application/Socks traffic that should go outside goes to a Proxy, Web filter.

Because in early phase of Deployment those options are not set already and normally not needed. However if the driver is older than the Expiration of the Code Signing Certificate W7/W10 will check

The Certificate Revocation list from WAN/Internet. If that fails it may refuse to integrate the driver in Windows PE or early Windows Setup phase. If example this is a driver which

handels NIC (network) or mass Storage driver (Disk) they deployment can't run through this early process.

 

 

 

Workaround:

URL we need open in our sample: pki.infineon.com which prevents a complete Enterprise Deployment system to fail

 

 

 

Sample from Fortigate for other Certs they missed:

 

F-SBID( --name "Root.Certificate.URL_Custom"; --protocol tcp; --app_cat 17; --service HTTP; --flow from_client; --pcre "/(crl\.microsoft\.com|\.omniroot\.com|\.verisign\.com|\.symcb\.com|\.symcd\.com|\.verisign\.ne t|\.geotrust\.com|\.entrust\.net|\.public- trust\.com|\.globalsign\.|\.digicert\.com|crl\.startcom\.|crl\.cnnic\.cn|crl\.identrust\.com|crl\.thaw te\.com|crlsl\.wosign\.com|www\.d\-trust\.net)/"; --context host; --weight 15; )

 

In our case:

 

F-SBID( --name "Root.Certificate.pki.infineon.com"; --protocol tcp; --app_cat 17; --service HTTP; -- flow from_client; --pcre "/(pki\.infineon\.com)/"; --context host; --weight 15; )