Tag Archive | McAfee

10 заповідей оператора McAfee

“The deadliest weapon in the world is a marine and his rifle..
Your rifle is only a tool.”
(c) Gunnery Sergeant Hartman, Full Metal Jacket

 

Контент буде корисний як новачкам так і досвідченим користувачам корпоративних рішень McAfee.

Як показує мій скромний досвід тех. підтримки, ~ 70% проблем можна вирішити одним або кількома із цих 10 кроків.

30% – це вже різні апаратні або програмні конфлікти чи помилки у коді, яких не вирішити без виправлень чи хотфіксів.

10 заповідей оператора McAfee

McAfee – не панацея і не срібна куля. Це лише інструмент у моїх руках і його ефективність залежить від того, як саме я користуюся ним.

Перш ніж звинувачувати в усіх бідах розробників, інтеграторів чи партнерів, я докладу усіх зусиль і перевірю наступні кроки:

  1. Аби бути в курсі виходу нових версій, виправлень чи рекомендацій я підпишуся на розсилку SNS і буду періодично читати ті листи (!)
  2. Щоб уникнути проблем з розгортанням рішень на різні платформи я буду перевіряти відповідну статтю з таблиці KB51109
  3. Маючи справу з Windows 10 я буду оновлювати модулі McAfee _ перед _ розгортанням оновлення Windows згідно KB85784
  4. Чекаючи на нову версію рішення я буду відстежувати розклад релізів за таблицею у KB91587
  5. Якщо, не зважаючи на попередні пункти, я виявлю проблему, перше що я зроблю – пошук в Google за фразою “McAfee _продукт_версія_ Known Issues” і уважно вивчу відповідну KB (як приклад KB з проблемами по MAR)
  6. Якщо попередній крок не дав результатів, я перевірю свіжі дописи у відповідному розділі форуму McAfee Support Community
  7. В процесі вирішення проблеми я тричі переконаюсь, що дотримався системних вимог (описані у відповідному Installation Guide) і надав модулям усі необхідні мережеві доступи (для прикладу стаття по портам для DXL, TIE та ATD)
  8. В процесі вирішення проблеми я перевірю журнали (логи) відповідного рішення. (розташування логів я шукатиму у відповідному Installation Guide)
  9. В процесі вирішення проблеми я намагатимусь зрозуміти логіку роботи рішення або комплексу рішень згідно матеріалів McAfee Expert Center
  10. Тільки пройшовши попередні кроки, перезавантаживши проблемну систему, перевстановивши модуль, я зберу логи MER і створю Service Request

Сподіваюсь, наведені тут джерела стануть вам у нагоді.

Цей пост не повинен розглядатися як єдиний (універсальний) засіб проти усіх можливих проблем.

Це лише спроба узагальнити 10 ключових джерел, які свідомий оператор повинен перевірити переш ніж опустити руки і просити допомоги.

Будьте уважні та обережні.

 

 

 

 

 

 

 

 

VR

Advertisements

Fxmsp_AdvIntel_McAfee

Усім доброго вечора.

Нещодавно в мережі було опубліковано інформацію про компрометацію трьох виробників антивірусного програмного забезпечення.
Вчора ввечері замовники McAfee отримали розсилку (SNS) стосовно цього інциденту:

У багатьох виникли питання – чи варто хвилюватися?
Ми зі свого боку дослідили ситуацію.

Основні тези (коротко):

#1 Офіційна позиція McAfee на зараз – за фактами опублікованого AdvIntel проводиться розслідування.
Поки що реальних доказів чужої присутності не виявлено. У разі виявлення фактів компрометації компанія не збирається це замовчувати.

#2 Станом на сьогодні ми звернулись до McAfee за подробицями. Очікуємо від них більше конкретики.

#3 Компанія AdvIntel, яка на даний момент залишається єдиним (і поки не підтвердженим) джерелом інформації, до цієї публікації не з’являлася в інформаційному полі.
Їх офіційний сайт та сторінки у соц. мережах були створені на початку травня перед публікацією розслідування. Поки достовірної інформації обмаль, та ще зарано говорити про маніпуляції, але не варто відкидати і таку можливість.

#4 Фактично усі докази компрометації базуються на крихтах інформації, опублікованих AdvIntel.


Дві інші компанії (Trend Micro та Symantec), про які йдеться у публікації AdvIntel, обмежились суперечливими і не чіткими заявами.
Symantec спростовує можливість проникнення, а Trend Micro припускає часткове проникнення на некритичні системи.

Ми розуміємо серйозність даної ситуації.

Саме тому ми закликаємо вас зберігати спокій і чекати на остаточне підтвердження або спростування факту компрометації систем McAfee.

Залишайтесь з нами. Як тільки ми отримаємо нову інформацію – ми вас повідомимо.

Посилання на саме розслідування та додаткові деталі:
https://www.advanced-intel.com/blog/top-tier-russian-hacking-collective-claims-breaches-of-three-major-anti-virus-companies
https://www.bleepingcomputer.com/news/security/hackers-selling-access-and-source-code-from-antivirus-companies/
https://www.bleepingcomputer.com/news/security/new-details-emerge-of-fxmsps-hacking-of-antivirus-companies/
https://www.bleepingcomputer.com/news/security/fxmsp-chat-logs-reveal-the-hacked-antivirus-vendors-avs-respond/

Будьте уважні та обережні.

OptiData LLC

VR

McAfee DLP 11.3 vs Google Chrome

Усім привіт. Маю добру звістку для користувачів McAfee DLP.

Як ви певне пам’ятаєте, влітку 2018го з оновленням Google Chrome до версії 68 правила класу Web Protection перестали блокувати публікацію даних.

Багатьом замовникам довелося пристосовуватися і шукати workaround щоб не було витоків через Chrome.

Розробники McAfee дбають про рішення і тому обіцяють повернути контроль над Chrome у DLP 11.3:

… we are re-introducing functionality supporting the blocking of Chrome file uploads in the DLPe product. This feature will provide blocking capability for all Chrome versions; there will be no need for an updated offset.xml file for each new Chrome release.

McAfee SNS Notice

Нагадую, що поточна версія McAfee DLP зараз – 11.2

Оновлення 11.3 з підтримкою блокування Google Chrome очікується:

  • RTS (release to support) – в травні 2019
  • GA (global availability) – в червні 2019

Таким чином, орієнтовно вже в середині травня можна буде отримати 11.3 через запит у підтримку.

Що стосується правильного циклу оновлення/переходу на іншу версію DLP Endpoint, то тут McAfee зазначає наступне:

If you are currently running DLP v11.2, you may continue to do so; support will assist with troubleshooting any issues encountered. However, any hotfixes if needed, will be based on DLP v11.3. Likewise, future update releases will be based on DLP v11.3. Upgrading to DLP v11.3 follows the standard upgrade process. We will offer assistance to any customer that requests help with the upgrade process.

If you are currently considering upgrading to DLP v11.2, we kindly ask you to please wait a few more weeks for the release of DLP v 11.3 so that you can benefit from the new feature and future updates.

McAfee SNS Notice

Якщо ви вже перейшли на 11.2 – ви можете продовжувати користуватись нею і після виходу 11.3 (червень 2019), але усі подальші виправлення та оновлення будуть випускатися уже для версії 11.3. Тому раджу не затримуватися на 11.2, навіть якщо контроль Chrome не входить у перелік ваших пріоритетів.

Якщо ж ви тільки готуєтеся до переходу на 11.2, тоді виробник радить зачекати кілька тижнів до появи 11.3, оскільки в подальшому саме цей реліз буде основним.

Якщо хочете бути  в курсі оновлень та зміни функціоналу рішень McAfee – підписуйтеся на розсилки SNS тут.

Про доступність версії 11.3 та роботу з Chrome повідомлю додатково.

Будьте уважні та обережні.

VR

McAfee DLP vs Chrome 68

Увага. Важлива інформація для користувачів McAfee DLP Endpoint.

 

Google внесе зміни в роботу розширень Chrome починаючи з версії 68 (поточна – 67).

Таким чином починаючи з Chrome 68 правила Web Protection втрачають можливість блокувати публікацію даних.

Це пов’язано з тим, що Google змінює механізм роботи розширень (через які працює перехоплення DLP).

Фактично, з 68ї версії розширення будуть отримувати дані від браузера уже після здійснення upload.

Це значить, що у випадку публікації конфіденційної інформації через Google Chrome DLP Endpoint буде лише сповіщати, але не блокувати.

 

Що робити?

 

У вас є кілька сценаріїв як адаптуватися до цих змін:

  • обмежити Chrome парою правил Application File Access Protection та Clipboard Protection
  • на рівні proxy по User Agent обмежити доступ для Chrome, а трафік хмарних агентів перехоплювати через правила Cloud Protection
  • контролювати web на рівні Network DLP Prevent
  • скористатися функціоналом DLP на Web Gateway
  • посилити контроль через McAfee Skyhigh Security Cloud
  • заборонити використання Google Chrome

Детальніше про ситуацію з Chrome дивіться нижче:

Також допис на блозі McAfee: Google Chrome 68 Changes and Their Impact on Data Protection

Будьте уважні та обережні.

VR

McAfeeCybersecForum

31го травня  ми приймали участь у #McAfeeCybersecForum.

Раджу ознайомитися із слайдами. Суто технічний контент.

 

Моя доповідь стосувалася sandbox`у McAfee ATD та його інтеграції з Cisco, Fortinet та ін. рішеннями.

В презентації є слайди з демо TIE та DLX / OpenDXL іще кілька цікавинок (кейс про макрос та Нацполіцію)

Кому не зручно, можуть взяти pdf (~3 Mb)

 

Олег розповідав про практичне застосування McAfee NSP та Web Gateway.

Наводив багато цінних порад:

Кому не зручно, можуть взяти pdf (~6 Mb)

Будьте уважні та обережні.

Слідкуйте за нашою сторінкою у Facebook

https://www.facebook.com/Optidata.com.ua/

VR

why McAfee ? (ENS how to)

“выигрывает вовсе не тот, кто умеет играть по всем правилам;

выигрывает тот, кто умеет отказаться в нужный момент от всех правил,

навязать игре свои правила, не известные противнику, а когда понадобится — отказаться и от них…”

(с) Братья Стругацкие, “Град обреченный”

Як правильно користуватися антивірусом, або чому саме McAfee?

Усім привіт.

Нещодавно я мав честь виступати перед публікою на #Security Forum Kyiv.

Розповідав я про історію успіху одного із наших замовників (презентація у pdf), якому ми допомагали із побудовою комплексного захисту із застосуванням рішень McAfee.

Наприкінці доповіді один із слухачів запитав мене – чому я вже більше чотирьох років займаюся рішеннями McAfee?

Оскільки я був обмежений регламентом, у мене не було можливості надати вичерпну відповідь.

Давайте я вам покажу чому ж я віддаю перевагу захисту McAfee.


Перш ніж переходити до практичних екзерцисів давайте одразу чітко визначимось:

#1 ми не будемо покладатися на сигнатури.

ми достатньо освічені люди щоб усвідомлювати – один і той же зразок можна пропустити через то й же Veil , а потім вбудувати отриманий перепакований та пошифрований .exe-шник у цілком пристойний документ використовуючи широкий спектр вразливостей MS Office, наприклад 11882. Саме тому сидіти і чекати доки вендор антивірусу додасть чергову сигнатуру на документ-приманку по сьогоднішній розсилці (а завтра їх буде ще більше) – це програшна тактика. Як людина, котра більше 4х років займається тех. підтримкою я достатньо наслухався типових звернень “а ваш антивірус не розпізнав нову приманку із тисячі, він поганий, ось результати VirusTotal“.. Скажу так – моя задача як інженера показати вам що варто не влаштовувати лови на конкретний зразок (яких щодня генерують тисячами), а розбиратися із механікою і перекривати канали доставки.

#2 коли мова йде про спробу доставити шкідливий код через фішинг із соц. інженерією – ми можемо робити усе що нам заманеться, але рівно до того моменту, доки не запуститься основна частина (як правило .exe файл).

Все. Якщо це сталося – ми втратили систему, навіть якщо зразок не призвів до шифрування файлів. Чому так? Тому що у нас немає права на помилку. Просто тому що правильно побудована стратегія захисту не повинна розбиратися – що прилетіло сьогодні – троян чи шифрувальщик? Запуск шкідливого коду це вже інцидент. І досить часто замовникам не вистачає часу/бажання а іноді й компетенції щоб розбиратися – чи достатньо просто видалити сам файл, чи система уже переналаштована?

“А мы ошибаться не должны. Нам разрешается прослыть невеждами, мистиками, суеверными дураками. Нам одного не простят: если мы недооценили опасность. И если в нашем доме вдруг завоняло серой, мы просто не имеем права пускаться в рассуждения о молекулярных флуктуациях — мы обязаны предположить, что где-то рядом объявился черт с рогами, и принять соответствующие меры, вплоть до организации производства святой воды в промышленных масштабах.” (с) Братья Стругацкие, “Жук в муравейнике”

Знову ж таки, тут моя задача – зробити так, щоб у користувача-потенційної жертви не було можливості активувати приманку і запустити процес інфікування, і байдуже що там прилетіло. Це я (коли у мене є час та натхнення) можу займатися (і займаюся) аналізом зразків. А бізнес не буде чекати, доки ІТ/ІБшнік розколупає черговий семпл. Бізнесу треба щоб процеси не припинялися. Саме тому, наше завдання не ганятися за черговою мільярдною сигнатурою, а зробити усе можливе, щоб якщо фішинг все ж таки пройшов крізь фільтри, а жертва-користувач проявив людську необачність і перейшов за посиланням/відкрив приєднання – нічого не сталося. Щоб приманка не спрацювала і нападники облажалися по повній. Щоб вони витрачали час, зусилля і кошти знов і знов у спробах пройти захист, а ми просто відстежували чергову пачку спрацювань і займалися більш важливими справами ніж аналіз маркерів по черговій, сотій/тисячній розсилці.

Ви можете з якихось невідомих мені причин не поділяти мою точку зору по цим двом моментам, але дочитайте до кінця статті, і можливо ви зміните свою думку.


Не будемо брати якийсь уявний інцидент, давайте подивимось чого вартий правильно налаштований McAfee Endpoint Security проти останньої розсилки, яку ми детально розібрали.

Давайте уважно поглянемо на послідовність атаки:

  • жертва відкриває файл-приманку, у даному випадку надбудова Excel (xlam)
  • макрос, який міститься у файлі активується і передає кодовані інструкції на PowerShell
  • PowerShell завантажує, записує на диск та запускає основну частину

Наше поле битви – рівно до моменту запуску завантаженої основної частини. Якщо ми не зупинили атаку до цього – ми програли.

Отже, що ми можемо зробити у випадку, коли в компанії макроси використовуються і їх заборона на є прийнятною? Дозволю собі процитувати уривок із переліку контрзаходів:

  • Блокування мережевих запитів із локальної мережі з User Agent Mozilla/4.08 (Charon; Inferno) – не на рівні кінцевих точок
  • Заборона запуску макросів (параметри пакету MS Office або реєстр ОС або GPO) – бізнесу потрібні макроси, вимкнути їх не варіант
  • Блок запуску дочірніх процесів для додатків MS Office (Excel > CMD > PowerShell) – GPO або правило Access Protection
  • Блок запуску PowerShell з кодованими командами – GPO або сигнатури блоку Exploit Prevention ENS
  • Блокування доступу до мережі Інтернет для процесів PowerShell
  • Заборона створення та зчитування/запуску *.EXE з каталогів профілю користувача %appdata%, а не лише у %temp% !

Давайте я покроково продемонструю вам як це зробити засобами базового антивірусу McAfee ENS.

Отож я нагадаю, що поточна версія McAfee ENS може включати такі модулі:

  • ENS Platform – GUI, основний framework на базі якого запускаються інші компоненти
  • ENS Threat Prevention – антивірусне ядро + перехоплення експлойтів + блок HIPS + політики Access Protection
  • ENS Firewall – мережевий брандмауер із центральним керуванням з єдиної консолі McAfee ePO
  • ENS Web Protection – клієнтська веб-фільтрація, перевірка репутації та категоризація URL
  • ENS Adaptive Threat Protection – розширений захист, механізми DAC, Real Protect та передача файлів на ATD*

Мінімальний комплект – Platform + Threat Prevention. Усе інше – за бажанням.

*Adaptive Threat Protection в базовий комплект не входить. В рамках даного допису його не застосовуємо тому його вимикаю.

Трохи про можливості модулю ENS Threat Prevention:

  • OAS, ODS сканування – перевірка по DAT та GTI
  • Упередження використання експлойтів, контроль операцій в пам’яті системи
  • Сигнатурний HIPS, блокування відомих вразливостей як локально так і на рівні мережевого трафіку (привіт MS17-010)
  • Мої улюблені правила захисту доступу або ж Access Protection

Оскільки ми з вами на початку домовилися сигнатурами не користуватися, я вимикаю OAS сканування, а ODS відключаю від GTI.

Одразу попереджаю усі знімки екрану, які я буду наводити відображають не стандартні, не стокові (My Default) політики.

(Увага!) не повторюйте це на продуктиві, без підготовки та знань це може призвести до небажаних наслідків та інфікування систем


Отож почнемо з налаштування згідно переліку контрзаходів.

#1 Блок запуску дочірніх процесів для додатків MS Office (Excel > cmd > PowerShell)

У випадку коли макроси потрібні по роботі і їх не можна просто вимкнути, щоб вберегтися від документів приманок ми можемо заблокувати запуск дочірніх процесів від імені додатків пакету MS Office. Ну розсудіть самі – невже штатний режим роботи із документами Word та Excel передбачає запуск CMD та/або PowerShell ? Якщо я відкриваю документ, то  я очікую попрацювати з документом і зберегти його, я не очікую виконання якихось команд в фоні, правда ж?

Дану задачу досить просто і швидко закрити засобами правил Access Protection, увага на екран знімки екрану:

Створюємо дубль політики Access Protection, переходимо у новостворену політику і додаємо нове користувацьке правило з наступними умовами:

Вище ми вказали кому ми забороняємо запускати, далі ми створюємо Subrule щоб вказати що саме ми блокуємо:

Зберігаємо зміни в політиці, призначаємо політику групі систем, виконуємо виклик McAfee Agent щоб система швидко застосувала нову політику. Запускаємо документ і спостерігаємо за результатом:

Ой, я правда не очікував цього, чесно. Я збирався продемонструвати вам роботу Access Protection, а ENS відстежив і заблокував роботу макросу через переповнення буферу. Я ж попереджав, що у мене політики не стокові.

Ок, 1:0 на користь McAfee. Давайте вимкнемо механізм DEP щоб отримати спрацювання по Access Protection:

Запускаємо документ вдруге і спостерігаємо за результатом:

Ок, 2:0 на користь McAfee. Давайте вимкнемо блокування для нашого правила Access Protection і перейдемо до наступного пункту:

#2 Блок запуску PowerShell з кодованими командами (-e, pOWErshELL -EncODeDCOMmaNd)

В аналізі розсилки, приманку якої ми препаруємо ви можете бачити, що макрос містить кодовані у base64 інструкції, що через cmd передаються на powershell. У тому випадку, якщо адміністратори широко застосовують powershell для рутинних задач, можна не повністю блокувати запуск powershell, а з певними параметрами. У цьому нам допоможе HIPS, який інтегровано у модуль ENS Threat Prevention, дивіться уважно:

Отже я активував сигнатури 6108 та 6087 які дозволяють мені блокувати підозріле використання PowerShell. Втретє відкриваємо документ-приманку:

Ок, 3:0 на користь McAfee. Вимикаю сигнатури і переходимо до наступного пункту.

#3 Блокування доступу до мережі Інтернет для процесів PowerShell

А дійсно – наскільки часто в штатному режимі роботи powershell з клієнтських машин повинен завантажувати з Інтернет файли? Якщо це не є ключовим моментом роботи оператора АРМ чи працівника департаменту HR, то давайте це заблокуємо засобами модулю ENS Firewall:

Правило Firewall доволі просте – я забороняю мережеву активність для певного переліку додатків:

Отже я створив та активував правило для ENS Firewall яке дозволяє мені блокувати трафік процесу PowerShell. Відкриваємо документ-приманку в четвертий раз:

Хм, ми бачимо спрацювання Access Protection по іншому правилу – blk_exe_prof (заборона створення файлів типу .exe у каталозі користувача), але зовсім не Firewall (ті які видно в списку – 16:16 – 16:28 не мають відношення до powershell, то блок broadcast). Чому? Усе просто – я забув вимкнути наперед створене правило Access Protection, а при завантаженні файлів спершу виконується функція створення файлу, а вже потім його завантаження. Отже спроба створити файл була заблокована, а передачі мережевих пакетів так і не відбулося. Давайте вимкнемо блокування по правилу AP, бо це буде наступним пунктом і все ж таки побачимо спрацювання брандмауера:

Тепер у мене створення файлів не блокується і ми відкриваємо документ-приманку вп’яте:

Ок, 4:0 на користь McAfee. Вимикаю брандмауер і переходимо до наступного пункту.

#4 Заборона створення та запуску *.EXE з каталогів профілю користувача %appdata%

О, це справді досить суперечливий метод, проте максимально дієвий. Справа у тому, що 90% усього шкідливого мотлоху, який потрапляв мені до рук за останні ~3 роки, не залежно від форми та типу обгортки, в кінцевому результаті призводив до створення (завантаження або генерація) нового .ехе файлу у каталозі користувача.

Так, я знаю, що по цьому правилу буде багато, досить багато false positive завдяки сучасним програмістам, які вважають, що записати додаток у каталог користувача це простіше і легше а ніж помістити його у Program Files і навести лад із дозволами…

Але зрозумійте одне – варто один раз витратити кілька годин щоб прописати необхідні виключення і ми отримаємо універсальний захист від різноманітних розсилок, навіть від тих обгорток та вразливостей, які ще не застосовувалися. Адже ми блокуємо фінальний етап атаки – запис та запуск шкідливого додатку. Дивіться самі як це працює:

Важливо!

Останнім часом замість %temp%, payload усе частіше записують у %AppData% або ж у Public тому правильна умова для правила – C:\Users\*\**\*.exe

Отже одним або двома правилами (якщо розносити блок запису та запуску окремо) ми забороняємо усім процесам (мінус виключення) створювати та запускати .exe файли із AppData. Відкриваємо документ-приманку вшосте:

Хм, спрацювання є, але не потому каталогу, в якому ми очікували основну частину. Давайте поглянемо на WireShark:

Але ж я обіцяв вам показати усі способи захисту в дії. Що ж скористаємося засобами PowerShell для завантаження цілком легітимного файлу – пакету 7zip:

Правило blk_exe_prof_create відпрацювало як і було задумано – сповістило проте не блокувало. А тепер давайте спробуємо запустити .exe :

Отже 5:0 на користь McAfee. Навіть якщо payload усе ж таки буде доставлено та записано через 0day вразливість ми тупо блокуємо його запуск.

І лише після деактивації блокування для правила blk_exe_prof_create жертва зможе запустити умовний payload і відбудеться інфікування системи:


Таким чином, як ви самі можете тепер бачити, щоб інфікувати систему мені довелося вимкнути 5 різних механізмів захисту.

І це без сигнатур, в яких на момент тестування payload уже був:

Порівняйте це з простим очікуванням доки виробник антивірусу обробить запит постраждалого замовника і нарешті додасть черговий зразок у базу сигнатур. А наступного дня їх буде ще більше і сигнатур уже не буде розповсюджуватися на них…

Зверніть увагу – замість того, щоб зациклюватися на конкретному зразку, я блокую канали доставки. Таким чином я прибираю у користувача можливість помилитися і стати жертвою. Я не покладаюся на шлюзи/фільтри та сигнатури – я просто знаю як працює той чи інший тип приманок і перерізаю їм роботу, навіть не замислюючись що це було – черговий ransomware чи trojan. Коли чергова фішингова розсилка буде відбиватися вищенаведеними правилами – тоді у ІТ/ІБ фахівців буде час розбиратися із дійсно важливими та складними атаками, а не вовтузитися із кожною новою хвилею примітивщини. А поки для нашого сегменту атаки на кшталт badrabbit будуть сприйматися і розганятися по ЗМІ як “супер-пупер-мега-складна” атака – ми залишатимемося вразливими для більш тонких і справді складніших операцій.

Так, по замовчуванню, одразу після розгортання продукту політики потрібно переналаштувати. Але зверніть увагу, що показані мною правила не “заточені” під конкретний зразок чи ба, навіть, під конкретну розсилку, адже приміром блок створення дочірніх процесів захистить мене не лише від макросу але й від 11882 чи DDE, а блокування кодованих команд PowerShell від інших способів атаки, наприклад OLE. Що ж до блокування створення та запуску нових .exe – цей спосіб вельми універсальний, потрібно лише правильно прописати виключення.


Отже ми з вами на прикладі одного документу із макросом розглянули реалізацію наступних механізмів захисту:

  • Блок запуску дочірніх процесів для додатків MS Office (Excel > CMD > PowerShell) – ENS Access Protection
  • Блок запуску PowerShell з кодованими командами – ENS Exploit Prevention
  • Блокування доступу до мережі Інтернет для процесів PowerShell – ENS Firewall
  • Заборона створення та запуску нових *.EXE файлів з %userprofile%, а не лише у %temp% – ENS Access Protection

Крім того, ми отримали ще додаткове спрацювання Exploit Prevention на переповнення буферу при активації макросу (не стандартні політики, максимальний захист).

Так, частину із описаних вище контрзаходів можна реалізувати засобами ОС, проте дозвольте вам зауважити, що замовник, який правильно експлуатує  захист кінцевих точок, може оперативно вносити зміни в політики захисту, адаптуючи систему захисту під нові види загроз. І це в базовому варіанті, без можливостей розширеного захисту із застосуванням ENS Adaptive Threat Protection.

Слідкуйте за маркерами, знайте свою зброю проти сучасних загроз, вмійте правильно її використовувати та пам’ятайте – головне не конкретний зразок шкідливого коду, а перекритий канал доставки.

Будьте уважні та обережні!

 

VR

Защита для Yosemite

os-x-10-10-mcafee-secure

На прошедших выходных стала доступна новая версия OS X Yosemite. Для тех кто уже обновился или только планирует переход полезно будет узнать, что разработчики McAfee заранее подготовили набор обновлений для защитных модулей, который обеспечивают совместимость с новой ОС. (Решения, о которых речь пойдет ниже стали доступны уже 15/10/14)

Прежде всего стоит обратить внимание на Hotfix 972377 для McAfee Agent for Mac. Поскольку McAfee Agent является “фундаментом” для остальных модулей защиты, начать обновление нужно с него. Установку хотфикса рекомендуется выполнить до перехода на Yosemite, т.к. без хотфикса текущая версия McAfee Agent не будет запускаться. Тем, кто уже поставил Yosemite и обнаружил проблемы с синхронизацией политик и задач необходимо воспользоваться KB82993.

Следующим пунктом стоит отметить релиз новой версии Management of Native Encryption 2.0.1 (MNE), решения, которое отвечает за централизованное управление встроенным шифрованием (подробнее о решении см. заметка1 и заметка2). Совместимость с Yosemite была достигнута за счет того, что пакеты MNE получили новую цифровую подпись, согласно требованиям Apple. Инструкция по обновлению MNE доступна в KB83053.

Новая версия VirusScan for Mac 9.7.0 помимо поддержки Yosemite может похвастать улучшением производительности сканирования, которая была достигнута за счет использования новой версии антивирусного “движка”  5700 Engine. Заметки к релизу доступны по ссылке.

Обновился так же комплект Endpoint Protection for Mac 2.2, в который по мимо вышеназванного антивируса также входит защита приложений и брандмауэр. Основные изменения – новая цифровая подпись пакетов для поддержки Yosemite и новый антивирусный “движок”. Заметки к релизу доступны по ссылке.

ps

Не зависимо о того, в какой комплектации вы используете вышеперечисленные компоненты (антивирус, контроль шифрования, пакет защиты конечных точек) вам нужно установить хотфикс для McAfee Agent до обновления на Yosemite. Если же вы уже обновили ОС, обратитесь к инструкциям (порядок действий может отличаться в зависимости от конкретного решения).