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

В предыдущей заметке рассказывал что база данных 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 радикально функциональнее и эффективнее, чем в составе эндпоинта, и, будучи специализированным оптимизированным средством, и за счет отсутствия ограничений по производительности, тем не менее, с поставкой телеметрии о сетевых событиях, эндпоинт также вполне способен справиться.