Производитель продукта заинтересован делать качественные решения. Одной из важнейших характеристик "качественного" решения является низкая операционная стоимость (TCO), т.е. с учетом всех проявлений закона сохранения такое решение дешево поддерживать и пользователю и производителю. Производителю очень важно иметь низкую стоимость поддержки, так как, в противном случае, с бесконечным ростом продаж ему придется бесконечно увеличивать штат пользовательской поддержки, что, безусловно, производителю делать не хочется, и он предпримет все, чтобы максимально снизить рост стоимости поддержки с увеличением объема продаж.
Перейдем в плоскость продуктов безопасности, а точнее, - систем обнаружения. С точки зрения производителя Продукта, решение которое генерит множество ложных срабатываний - плохое, так как каждое ложное срабатывание - потенциальное обращение в поддержку продукта. "Потенциальное" здесь означает, что не каждое ложное срабатывание решается исправлением логики обнаружения, какие-то - контекстные - решаются кастомными фильтрами и тонкой настройкой, насколько это возможно, так как давать широкие возможности по кастомизации - тоже не совсем в интересах Производителя, ибо сложное решение, опять же, дорого и в поддержке. А стоимость поддержки, как отмечено выше, надо минимизировать. Это означает, что в Продукте детектирующая логика будет максимально точной, генерящей минимально возможное количество ложных срабатываний (ситуация может быть даже немного хуже: сложную телеметрию, которую сложно понять, для работы с которой нужна высокая квалификация, и, следовательно, которая будет причиной множества обращений в продуктовую поддержку - тоже вопрос, стоит ли показывать, поскольку словосочетание "низкая стоимость поддержки" относится и к стоимости персонала, работающего с продуктом).
На первый взгляд может показаться, что это - хорошо. Но это не совсем так. С позиции здравого смысла, великой науки, а также подтверждено практикой, что чем более скрытые (сложные, целевые) атаки хочется обнаруживать, тем более чувствителен должен быть наш детект, тем к большему количеству обрабатываемых ложных срабатываний надо готовиться. Из этого несложно заключить, что чем более "экзектовая" (точная) логика используется, тем меньше шансов ее эффективно использовать против сложных атак, как минимум, потому что обход точных детектов, зачастую, тривиален. На этот счет есть богатый личный опыт: во время подготовки к OSCP я успел стать фанатом HTB, и заметил, что часто в машинках средней сложности и выше приходится обходить какие-либо превентивные (хороший пример системы экзектовых детектов, так как любой prevention не допускает ложных срабатываний, поскольку вынос легитимного приложения представляет собой значительно больший риск, чем пропуск ВПО, аналогично можно сказать про блокировку трафика) системы безопасности: WAF или примитивные HIPS, на Windows - практически всегда надо победить Windows Defender. Плотно общаясь с коллегами-пентестерами из смежного подразделения, могу с уверенностью сказать, что мне до них в части offensive примерно также как до Блэкмора по игре на гитаре, но даже мне не составляет труда забайпассить Defender, а что уж там говорить о реальных профи. В общем, человек всегда сможет победить автомат, как бы ни был продвинут последний, вопрос в профессионализме человека, времени и предварительной осведомленности\подготовке. А сложные атаки всегда делаются профессионалами и хорошо готовятся.
Но вернемся к обсуждаемой теме. Получается борьба противоположностей: с одной стороны, чтобы результативно находить сложные атаки, нужно системы обнаружения делать более чувствительными и быть готовыми к множеству ложных срабатываний - (1). А с другой стороны, много ложных срабатываний и сложность потенциально увеличивают стоимость использования продукта конечным потребителем и одновременно - повышает стоимость вендорского сопровождения, так как каждая фолса - потенциальная эскалация производителю (2). (1) - это про качество детекта, (2) - это про деньги. Из (1) и (2) совсем несложно догадаться, что продукт всегда будет стремиться к максимальной точности детектов, так это соответствует минимальной стоимости сопровождения и для пользователя и для производителя.
Подсвеченная проблема в значительной степени решена в случае Сервиса. Сервис, безусловно стремится к минимизации костов (2), но и, вместе с тем, является конечной точкой ответственности за качество обнаружения (1). "Конечной" означает, что дальше эскалировать некуда: если Продукт пропустил APT - тому может быть масса объяснений - он неправильно настроен, его операторы недостаточно профессиональны, или, в конце концов, продукт реализует баланс между (1) и (2) в пользу (2); в случае Сервиса приведенные аргументы едва ли могут служить объяснениями: конфигурация инструментария и профессионализм команды - в руках поставщика услуги, а вариант баланса в пользу (2) означает "мы на вас экономим" - звучит смешно.
Написал достаточно много, но тому есть небольшое оправдание - хотелось наглядно донести позицию, поэтому соберу мысли в простые пункты:
1. Если есть желание обнаруживать сложные атаки, надо готовиться к ложным срабатываниям.
2. Ложные срабатывания - это косты сопровождения, которые никому (ни производителю, ни потребителю) не нужны и их всячески будут снижать.
3. В общем случае, человек всегда найдет способ обойти полностью автоматическое обнаружение.
4. Сервис всегда будет показывать более высокое качество обнаружения в сравнении с любым автоматическим продуктом.
Перейдем в плоскость продуктов безопасности, а точнее, - систем обнаружения. С точки зрения производителя Продукта, решение которое генерит множество ложных срабатываний - плохое, так как каждое ложное срабатывание - потенциальное обращение в поддержку продукта. "Потенциальное" здесь означает, что не каждое ложное срабатывание решается исправлением логики обнаружения, какие-то - контекстные - решаются кастомными фильтрами и тонкой настройкой, насколько это возможно, так как давать широкие возможности по кастомизации - тоже не совсем в интересах Производителя, ибо сложное решение, опять же, дорого и в поддержке. А стоимость поддержки, как отмечено выше, надо минимизировать. Это означает, что в Продукте детектирующая логика будет максимально точной, генерящей минимально возможное количество ложных срабатываний (ситуация может быть даже немного хуже: сложную телеметрию, которую сложно понять, для работы с которой нужна высокая квалификация, и, следовательно, которая будет причиной множества обращений в продуктовую поддержку - тоже вопрос, стоит ли показывать, поскольку словосочетание "низкая стоимость поддержки" относится и к стоимости персонала, работающего с продуктом).
На первый взгляд может показаться, что это - хорошо. Но это не совсем так. С позиции здравого смысла, великой науки, а также подтверждено практикой, что чем более скрытые (сложные, целевые) атаки хочется обнаруживать, тем более чувствителен должен быть наш детект, тем к большему количеству обрабатываемых ложных срабатываний надо готовиться. Из этого несложно заключить, что чем более "экзектовая" (точная) логика используется, тем меньше шансов ее эффективно использовать против сложных атак, как минимум, потому что обход точных детектов, зачастую, тривиален. На этот счет есть богатый личный опыт: во время подготовки к OSCP я успел стать фанатом HTB, и заметил, что часто в машинках средней сложности и выше приходится обходить какие-либо превентивные (хороший пример системы экзектовых детектов, так как любой prevention не допускает ложных срабатываний, поскольку вынос легитимного приложения представляет собой значительно больший риск, чем пропуск ВПО, аналогично можно сказать про блокировку трафика) системы безопасности: WAF или примитивные HIPS, на Windows - практически всегда надо победить Windows Defender. Плотно общаясь с коллегами-пентестерами из смежного подразделения, могу с уверенностью сказать, что мне до них в части offensive примерно также как до Блэкмора по игре на гитаре, но даже мне не составляет труда забайпассить Defender, а что уж там говорить о реальных профи. В общем, человек всегда сможет победить автомат, как бы ни был продвинут последний, вопрос в профессионализме человека, времени и предварительной осведомленности\подготовке. А сложные атаки всегда делаются профессионалами и хорошо готовятся.
Но вернемся к обсуждаемой теме. Получается борьба противоположностей: с одной стороны, чтобы результативно находить сложные атаки, нужно системы обнаружения делать более чувствительными и быть готовыми к множеству ложных срабатываний - (1). А с другой стороны, много ложных срабатываний и сложность потенциально увеличивают стоимость использования продукта конечным потребителем и одновременно - повышает стоимость вендорского сопровождения, так как каждая фолса - потенциальная эскалация производителю (2). (1) - это про качество детекта, (2) - это про деньги. Из (1) и (2) совсем несложно догадаться, что продукт всегда будет стремиться к максимальной точности детектов, так это соответствует минимальной стоимости сопровождения и для пользователя и для производителя.
Подсвеченная проблема в значительной степени решена в случае Сервиса. Сервис, безусловно стремится к минимизации костов (2), но и, вместе с тем, является конечной точкой ответственности за качество обнаружения (1). "Конечной" означает, что дальше эскалировать некуда: если Продукт пропустил APT - тому может быть масса объяснений - он неправильно настроен, его операторы недостаточно профессиональны, или, в конце концов, продукт реализует баланс между (1) и (2) в пользу (2); в случае Сервиса приведенные аргументы едва ли могут служить объяснениями: конфигурация инструментария и профессионализм команды - в руках поставщика услуги, а вариант баланса в пользу (2) означает "мы на вас экономим" - звучит смешно.
Написал достаточно много, но тому есть небольшое оправдание - хотелось наглядно донести позицию, поэтому соберу мысли в простые пункты:
1. Если есть желание обнаруживать сложные атаки, надо готовиться к ложным срабатываниям.
2. Ложные срабатывания - это косты сопровождения, которые никому (ни производителю, ни потребителю) не нужны и их всячески будут снижать.
3. В общем случае, человек всегда найдет способ обойти полностью автоматическое обнаружение.
4. Сервис всегда будет показывать более высокое качество обнаружения в сравнении с любым автоматическим продуктом.
No comments:
Post a Comment