В канун празднования Нового года принято делать прогнозы на будущий год. Я никогда этого не делал именно под Новый год, не люблю повторять. Но, если считать, что будущее - следствие настоящего, то успех предсказания можно считать метрикой адекватности свой оценки текущей ситуации, ну а если мы адекватно интерпретируем происходящее, значит мы разбираемся в своей работе и отрасли. В этой заметке не хочется распыляться, а порассуждать о главном - развитии предложений по Защите от атак, и не на ближайший года, а на ближайшие 3-5 лет.
Но прежде перенесемся на более чем 10 лет назад, когда я работал в Заказчике и совмещал две несовместимые роли - администратора систем безопасности и аналитика службы мониторинга (удивлен, что отголоски того славного прошлого так легко можно найти в Сети). Спустя какое-то время штатного функционала используемых коробочных продуктов стало не хватать: нет возможности создать требуемые кастомные сигнатуры, нет возможности аккуратно отфильтровать ложные срабатывания, порой, даже не получается как следует расследовать инцидент, так как сигнатуры закрыты и понять на что конкретно они срабатывают далеко не всегда возможно. Поначалу я писал фичареки (feature requests), путешествовал по линиям эскалации техподдержки, спустя какое-то время, прочувствовав на себе скорость исполнения моих фичареков, забил. Причины ситуации очевидны: во-первых, ограниченный функционал коробки - это понятно, широкий функционал требует тяжелого operations-а, что, безусловно, становится проблемой и вендора, поскольку он все равно является окончательной точкой эскалации. Во-вторых, дело не только в том, что сложный функционал сложно (==дорого) поддерживать, его еще и сложно сделать сразу хорошо, без глюков, багов и точно как планировали - Закон сохранения здесь во всей красе. Поэтому, ввиду банальных экономических предпосылок, вендорское решение-коробка будет всегда ограниченного фунционала, чтобы в поддержке можно было посадить простых людей, или, еще лучше, чтобы поддержка не требовалась вовсе: идеальный продукт - реализующий принцип продал и забыл. И как на стороне Заказчика преодолеваются продуктовые ограничения? Мы идем в opensource! Самостоятельно находя компромисс между его плюсам и минусами. Так сделал и я тогда. Так происходит и до сих пор....
...Специализация уже давно плотно вошла мир киберкриминала и требует соответствующих ответных мер со стороны защиты. Профессиональная работа должна выполняться профессионалами и, чем профессиональнее атакующие, тем профессиональнее и опытнее должны быть защитники. Поэтому, если немного подумать, можно догадаться, что чем сложнее атаки, тем шире пропасть между возможностями по защите со стороны интерпрайзной безопасности со своими коробками\opensource-ом и вендора-провайдера профессиональных решений по безопасности. И дело здесь не в людях, - в интерпрайзах полно прекрасных профессионалов, - а в инструментах и инфраструктуре. Я уже писал, что принцип Алана Кея работает и в нашем случае, но в несколько измененном виде: если вы предоставляете сервис по борьбе с уникальными угрозами, вам нужны свои уникальные инструменты для их обнаружения, как минимум, для решения описанных выше проблем ограниченности функционала и медленного исполнения важных запросов на изменения: не будет возможности догонять киберпреступников, если необходимая для детекта телеметрия или ее инфраструктурная обработка будет реализовываться в течение нескольких лет, собачонка подрастет :).
Второй абзац этой заметки поясняет почему функционал коробочных решений ограничен (широкий функционал имеет большое TCO, что никому не нужно). Но, к сожалению, и гибкого opensource недостаточно. И, что самое главное, не хватает исследований, как операционного процесса Исследований на базе собственных расследований - недостаточно, но, в любом случае, это лучше чем ничего не делать вовсе, или гоняться за ведьмами. Как отмечал здесь, чтобы иметь возможность обнаружить уникальную атаку в конкретной инфраструктуре, нужно в принципе иметь практику обнаружения уникальных атак, поставленную на operations (как минимум, на уровне зрелости, когда процесс повторим, чтобы повторить его у Заказчика), а найти уникальную атаку - это исследования. Причем, это не только люди, занимающиеся исследованиями на постоянной основе, это и детектирующие сенсоры, и инфраструктура обрабатывающая телеметрию с сенсоров, и огромная база всевозможного Threat Intelligence, начиная от тупых IoC-ов и репутации объектов, заканчивая информацией о группировках, применяемых техниках и тактиках. Бесконечное развитие современных атак требует бесконечной гибкости от используемых инструментов, а защита от постоянно мутирующего атакующего требует постоянной адаптации СЗИ - это и есть тот самый процесс безопасности, о котором все говорят - иметь в любой момент времени состояние защитных мер адекватным современным угрозам.
Ну вот, мне кажется, я накидал достаточно умозаключений, чтобы описываемый далее прогноз показался Вам, уважаемые читатели, столь же очевидным как и мне. По моему мнению эффективность коробочных решений против современных атак будет продолжать снижаться. Поэтому, чтобы оставаться эффективными, вендоры-провайдеры будут выводить на рынок более сложные предложения комбинации технологий и сервисов. Именно технологий, так как коробочный продукт всегда имеет ряд ограничений, преодоление которых вполне может оказаться дороже создания с нуля полностью адаптированной под Заказчика экосистемы вокруг технологий. В Operations эти технологии будут нуждаться в постоянной доработке - это и есть часть обеспечения безопасности, а чем сложнее технологии сами по себе, тем эффективнее и результативнее эти технологии будут. И тут законно: если вы хотите противостоять дорогим атакам, ваша защита тоже будет дорогой, как для Заказчика, так и для Поставщика. Я думаю, что в будущем и Поставщики и Заказчики наконец-то поймут, что "продать и забыть" нельзя, как нельзя и "поставить, защититься и забыть". Постоянная работа киберзлодеев требует постоянной работы Голубых команд, а узкая направленность (целенаправленность) атак требует переноса театра военный действий из лаборатории Поставщика непосредственно в инфраструктуру Заказчика. Успешным здесь будет тот вендор-поставщик, кто первым научится поставлять не коробки, а решения, встраивать их инфраструктурно и процессно в Заказчика, и на протящении всего жизненного цикла их использования оказывать поддержку и развитие построенной системы защиты и персонала Заказчика. Специализация атак требует специализации защиты, которая, чтобы оставаться всегда адекватной угрозам, должна быть максимально гибкой, а, следовательно, дорогой в использовании и обслуживании. Кстати, это отлично увязывается с геополитическими проблемами современности и сложностями доверия.
Поскольку, пытаясь сказать много (причем, местами одного и того же, но разными словами; кто меня знает лично, вероятно, знает и как я приобрел эту особенность), я, возможно, размыл суть прогноза, поэтому подведу итог. На смену комплексным решениям из коробок+сервисов придут более интеграторские предложения из технологий+Сервисов, где Сервисы будут включать: доведение проданных технологий до необходимого Заказчику продукта, компенсацию отсутствующей у Заказчика необходимой экспертизы по использованию технологий и получившихся продуктов, обеспечение постоянной эффективности и результативности технологий в обнаружении и предотвращении атак (как legacy, commodity, так и advanced, targeted). Здесь уже речь о партнерстве с поставщиками услуг, причем ИТ, ибо безопасность - свойство, едва ли нужное само по себе.
Я любитель схемок и картинок, поэтому и этот совой прогноз оснащу изображением эволюции подходов к защите.
Но прежде перенесемся на более чем 10 лет назад, когда я работал в Заказчике и совмещал две несовместимые роли - администратора систем безопасности и аналитика службы мониторинга (удивлен, что отголоски того славного прошлого так легко можно найти в Сети). Спустя какое-то время штатного функционала используемых коробочных продуктов стало не хватать: нет возможности создать требуемые кастомные сигнатуры, нет возможности аккуратно отфильтровать ложные срабатывания, порой, даже не получается как следует расследовать инцидент, так как сигнатуры закрыты и понять на что конкретно они срабатывают далеко не всегда возможно. Поначалу я писал фичареки (feature requests), путешествовал по линиям эскалации техподдержки, спустя какое-то время, прочувствовав на себе скорость исполнения моих фичареков, забил. Причины ситуации очевидны: во-первых, ограниченный функционал коробки - это понятно, широкий функционал требует тяжелого operations-а, что, безусловно, становится проблемой и вендора, поскольку он все равно является окончательной точкой эскалации. Во-вторых, дело не только в том, что сложный функционал сложно (==дорого) поддерживать, его еще и сложно сделать сразу хорошо, без глюков, багов и точно как планировали - Закон сохранения здесь во всей красе. Поэтому, ввиду банальных экономических предпосылок, вендорское решение-коробка будет всегда ограниченного фунционала, чтобы в поддержке можно было посадить простых людей, или, еще лучше, чтобы поддержка не требовалась вовсе: идеальный продукт - реализующий принцип продал и забыл. И как на стороне Заказчика преодолеваются продуктовые ограничения? Мы идем в opensource! Самостоятельно находя компромисс между его плюсам и минусами. Так сделал и я тогда. Так происходит и до сих пор....
...Специализация уже давно плотно вошла мир киберкриминала и требует соответствующих ответных мер со стороны защиты. Профессиональная работа должна выполняться профессионалами и, чем профессиональнее атакующие, тем профессиональнее и опытнее должны быть защитники. Поэтому, если немного подумать, можно догадаться, что чем сложнее атаки, тем шире пропасть между возможностями по защите со стороны интерпрайзной безопасности со своими коробками\opensource-ом и вендора-провайдера профессиональных решений по безопасности. И дело здесь не в людях, - в интерпрайзах полно прекрасных профессионалов, - а в инструментах и инфраструктуре. Я уже писал, что принцип Алана Кея работает и в нашем случае, но в несколько измененном виде: если вы предоставляете сервис по борьбе с уникальными угрозами, вам нужны свои уникальные инструменты для их обнаружения, как минимум, для решения описанных выше проблем ограниченности функционала и медленного исполнения важных запросов на изменения: не будет возможности догонять киберпреступников, если необходимая для детекта телеметрия или ее инфраструктурная обработка будет реализовываться в течение нескольких лет, собачонка подрастет :).
Второй абзац этой заметки поясняет почему функционал коробочных решений ограничен (широкий функционал имеет большое TCO, что никому не нужно). Но, к сожалению, и гибкого opensource недостаточно. И, что самое главное, не хватает исследований, как операционного процесса Исследований на базе собственных расследований - недостаточно, но, в любом случае, это лучше чем ничего не делать вовсе, или гоняться за ведьмами. Как отмечал здесь, чтобы иметь возможность обнаружить уникальную атаку в конкретной инфраструктуре, нужно в принципе иметь практику обнаружения уникальных атак, поставленную на operations (как минимум, на уровне зрелости, когда процесс повторим, чтобы повторить его у Заказчика), а найти уникальную атаку - это исследования. Причем, это не только люди, занимающиеся исследованиями на постоянной основе, это и детектирующие сенсоры, и инфраструктура обрабатывающая телеметрию с сенсоров, и огромная база всевозможного Threat Intelligence, начиная от тупых IoC-ов и репутации объектов, заканчивая информацией о группировках, применяемых техниках и тактиках. Бесконечное развитие современных атак требует бесконечной гибкости от используемых инструментов, а защита от постоянно мутирующего атакующего требует постоянной адаптации СЗИ - это и есть тот самый процесс безопасности, о котором все говорят - иметь в любой момент времени состояние защитных мер адекватным современным угрозам.
Ну вот, мне кажется, я накидал достаточно умозаключений, чтобы описываемый далее прогноз показался Вам, уважаемые читатели, столь же очевидным как и мне. По моему мнению эффективность коробочных решений против современных атак будет продолжать снижаться. Поэтому, чтобы оставаться эффективными, вендоры-провайдеры будут выводить на рынок более сложные предложения комбинации технологий и сервисов. Именно технологий, так как коробочный продукт всегда имеет ряд ограничений, преодоление которых вполне может оказаться дороже создания с нуля полностью адаптированной под Заказчика экосистемы вокруг технологий. В Operations эти технологии будут нуждаться в постоянной доработке - это и есть часть обеспечения безопасности, а чем сложнее технологии сами по себе, тем эффективнее и результативнее эти технологии будут. И тут законно: если вы хотите противостоять дорогим атакам, ваша защита тоже будет дорогой, как для Заказчика, так и для Поставщика. Я думаю, что в будущем и Поставщики и Заказчики наконец-то поймут, что "продать и забыть" нельзя, как нельзя и "поставить, защититься и забыть". Постоянная работа киберзлодеев требует постоянной работы Голубых команд, а узкая направленность (целенаправленность) атак требует переноса театра военный действий из лаборатории Поставщика непосредственно в инфраструктуру Заказчика. Успешным здесь будет тот вендор-поставщик, кто первым научится поставлять не коробки, а решения, встраивать их инфраструктурно и процессно в Заказчика, и на протящении всего жизненного цикла их использования оказывать поддержку и развитие построенной системы защиты и персонала Заказчика. Специализация атак требует специализации защиты, которая, чтобы оставаться всегда адекватной угрозам, должна быть максимально гибкой, а, следовательно, дорогой в использовании и обслуживании. Кстати, это отлично увязывается с геополитическими проблемами современности и сложностями доверия.
Поскольку, пытаясь сказать много (причем, местами одного и того же, но разными словами; кто меня знает лично, вероятно, знает и как я приобрел эту особенность), я, возможно, размыл суть прогноза, поэтому подведу итог. На смену комплексным решениям из коробок+сервисов придут более интеграторские предложения из технологий+Сервисов, где Сервисы будут включать: доведение проданных технологий до необходимого Заказчику продукта, компенсацию отсутствующей у Заказчика необходимой экспертизы по использованию технологий и получившихся продуктов, обеспечение постоянной эффективности и результативности технологий в обнаружении и предотвращении атак (как legacy, commodity, так и advanced, targeted). Здесь уже речь о партнерстве с поставщиками услуг, причем ИТ, ибо безопасность - свойство, едва ли нужное само по себе.
Я любитель схемок и картинок, поэтому и этот совой прогноз оснащу изображением эволюции подходов к защите.
1 comment:
Сервисы в таком виде подразумевают наличие у продавца компетенций, покрывающих потребности заказчика. А ведь монетизация целевой атаки зачастую лежит в узкой сфере деятельности компании-жертвы, и, вероятно, необходимые инструменты и компетенции уже присутствуют у других подобных компаний. Думаю, поставщики технологий+сервисов должны предоставлять площадки для сторонней разработки и продажи 'приложений' для их 'платформы'. Создание инфраструктуры и рынка по обмену компетенциями и приложениями (поставщиками событий, корреляциями) будет выгодно всем. Есть, конечно, опенсорс по типу sigma, но всё, что там появляется, может быть использовано тёмной стороной, и многим компаниям это отобьёт всякое желание делиться забесплатно
Post a Comment