Sunday, January 20, 2019

Системы и Сети

В предыдущей заметке рассказывал что база данных MITRE может быть использована для обоснования выбора тех или иных технических контролей и этапности их внедрения. Сейчас хочется коснуться темы эффективности сетевых СЗИ в сравнении с эндпоинтными. Сразу хочется оговориться, что являюсь сторонником многоуровневого подхода, что не раз отмечал.

На встречах мне почему-то постоянно пытаются доказать высокую эффективность NGFW/IPS в сравнении с EPP-EDR. Это совсем не так. Могу предположить, что непоколебимая вера в межсетевой экран как в основу корпоративной безопасности уходит своими корнями в те времена, когда мы много говорили о сетевом периметре и сетевой сегментации, а ключевая задача была - предотвратить угрозу. В то время сети делились на доверенные и недоверенные, трафик между ними надо было контролировать, и в этом трафике можно было увидеть следы сетевой атаки.
Сейчас мы узнали, что есть атаки которые невозможно предотвратить (если есть сомнения - закажите пентест у нормального поставщика), а поэтому ключевая задача отступила на (хотя бы) обнаружить угрозу (при этом никто не утверждает, что не надо по-прежнему пытаться предотвратить - простота вскрытия входной двери профессионалом не умаляет необходимость ее наличия); мы все стали мобильными, а, следовательно, периметр переехал на эндпоинт; весь трафик стал шифрованным, а, следовательно, его нельзя анализировать на SPAN-порту; а вредоносный трафик стал неотличим от легитимного как за счет эмуляции, так и просто за счет прямого использования по назначению.
Таким образом, в текущих реалиях за сетевыми СЗИ сохраняется их изначальная функция - предотвращения и некоторая небольшая телеметрия для расследования которой в большинстве случаев все равно потребуются данные с эндпоинтов. Тогда как современный EPP-EDR, напротив, зачастую может компенсировать отсутствие выделенных сетевых сенсоров, поскольку способен анализировать трафик непосредственно c эндпоинта.

Не будет лишним повторить, что я ни коим образом не пытаюсь снизить значимость NGFW/IPS для корпоративной ИБ, дело в том, что телеметрии только с них крайне недостаточно. И вот почему.
В самом конце моей предыдущей заметки есть табличка "Telemetry required for Techniques", показывающая для детекта скольких техники используется соответствующий вид телеметрии. Если эту телеметрию достаточно консервативно поделить на сетевую и эндпоинтную, то кратина будет следующая (для демонстрационных целей я привожу данные для Windows, но, поскольку все скрипты свободно доступны, читателям ничего не стоит оценить картину для других платформ).

Telemetry attack-pattern Telemetry Type
Process monitoring 136 Endpoint
Process command-line parameters 76 Endpoint
File monitoring 68 Endpoint
API monitoring 39 Endpoint
Process use of network 36 Endpoint
Windows Registry 34 Endpoint
Packet capture 32       Network
Authentication logs 24 Endpoint
Netflow/Enclave netflow 24       Network
Windows event logs 19 Endpoint
Network protocol analysis 18       Network
DLL monitoring 17 Endpoint
Binary file metadata 16 Endpoint
Loaded DLLs 12 Endpoint
Malware reverse engineering 8 Endpoint
SSL/TLS inspection 8       Network
Network intrusion detection system 7       Network
Anti-virus 7 Endpoint
System calls 6 Endpoint
Data loss prevention 6 Endpoint-Nerwork
Application logs 5 Endpoint
Host network interface 4 Endpoint
Network device logs 4 Endpoint
Web proxy 4       Network
Windows Error Reporting 4 Endpoint
Kernel drivers 4 Endpoint
Email gateway 4       Network
Third-party application logs 3 Endpoint
Services 3 Endpoint
User interface 3 Endpoint
MBR 2 Endpoint
Web logs 2 Endpoint
BIOS 2 Endpoint
Detonation chamber 2 Endpoint
Mail server 2       Network
Access tokens 1 Endpoint
VBR 1 Endpoint
Browser extensions 1 Endpoint
Disk forensics 1 Endpoint
Component firmware 1 Endpoint
PowerShell logs 1 Endpoint
Web application firewall logs 1       Network
Asset management 1       Network
Sensor health and status 1 Endpoint
Digital certificate logs 1 Endpoint
Environment variable 1 Endpoint
Named Pipes 1 Endpoint
DNS records 1       Network
EFI 1 Endpoint
WMI Objects 1 Endpoint
-->
Общий счет выглядит так
Telemetry type Techniques cnt
Endpoint 548
Network 102
Endpoint-Nerwork 6
-->
Выше я отметил "консервативность" деления на Network/Endpoint, и вот почему.
  • Packet capture - может быть получена с эндпоинта.
  • Данные, аналогичные Netflow/Enclave netflow тоже могут быть получены с эндпоинта.
  • Современные эндпоинты выполняют Network protocol analysis, как правило у них есть компонент IPS - считайте, что есть Network intrusion detection system.
  • SSL/TLS inspection эндпоинты способны делать.
  • Беря во внимание, что типовые вектора компрометации - Web и Mail даже старше меня, EPP-RDR давно умеют их анализировать прямо с эндпоинта, т.е. телеметрия Web proxy и Email gateway также доступны.
  • DNS трафик также может анализироваться на эндпоинте, поэтому DNS records - есть, в данном конкретном случае эта телеметрия указана для техники "Spearphishing Link", что перекрыватеся телеметрией Email gateway
В итоге получается, что никакой уникальности сенсор Network не добавляет, так как Mail server - перекрывается Email gateway, а Web application firewall logs - это серверсайд, что компенсируется все тем же наличием IPS на эндпоинте.

Конечно, я немного утрирую, поскольку абсолютно точно, что IPS в составе NGFW радикально функциональнее и эффективнее, чем в составе эндпоинта, и, будучи специализированным оптимизированным средством, и за счет отсутствия ограничений по производительности, тем не менее, с поставкой телеметрии о сетевых событиях, эндпоинт также вполне способен справиться.




2 comments:

Ryi said...
This comment has been removed by the author.
Ryi said...

А в каком эндпоинте есть нормальная настройка ips ids? В том же KES, только кнопка включить и выключить. Что там внутри неизвестно . Судя по маленькому размеру базы ids, вероятно она не дотягивает даже до коммунити снорта.