Неоднократно говорил, но не помню писал ли... поэтому не будет лишним на фоне всеобщей истерии об APT повториться, так как не считаю это зазорным, ибо никогда не относил себя к гениям (напомню: Гений - это тот, кто никогда не повторяется).
Если вы работаете в компании, которая сама не производит ПО и технических средств в чем может быть обнаружена уязвимость нулевого дня, вам не надо сильно много думать об атаках на эти уязвимости. Логика тут проста - вы не можете в полной мере управлять этим риском. Банально, у вас нет механизмов исправить эти уязвимости (поскольку не вы разработчик). Вы можете налепить множество детектирующих (которые вам реактивно покажут, что вас атаковали) и компенсирующих (которые, может, помогут вам восстановиться быстро или сделают что-то что снизит ваш возможный ущерб) контролей, но закрыть 0-day вы не сможете - это может сделать только производитель.
Именно для этого мы исправно платим производителям ПО за поддержку, а они, в свою очередь нам исправно латают свои дырки - это, в целом, единственное, как вы можете повлиять на 0-day. Если вы действительно сильно озабочены 0-day и есть подтверждения, что они часто возникают, а производитель плохо выпускает заплатки - меняйте производителя (... ну или навешивайте детектирующие, компенсирующие контроли и всякие другие навесные штуки, которые снизят вероятность эксплуатации или снизят возможный ущерб).
Итак, мы не боимся 0-day, пойдем далее. Выходит, мы не боимся того, о чем не знаем (вот действительно подтверждение того, что многие знания преумножают печаль) - это уже хорошо, поскольку опасаться не зная чего - вполне определенный медицинский диагноз, который с трудом поддается лечению. Несложными умозаключениями приходим к тому, что APT (если слово кажется сложным, можно заменить на 0-day, концептуально смысл не поменяется) также не стоит опасаться. APT по определению всегда будет успешной, она всегда будет направлена туда, где нет защиты, в противном случае - это не APT. Поэтому всякие продвинутые системы для "защиты от APT" - не более чем ловкословие маркетологов, - не надо на это вестись.
Но пост о том, кому бояться... - да. да, есть такие и кто они - понятно - те, кто сами пишут софт для своих нужд. В целом, таких полно и сам я неоднократно прибегал к "наколеночной" автоматизации, - сказываются годы работы программистом - в ряде задач проще самому написать, чем искать готовое решение, его закупать, внедрять и т.п. или кому-либо объяснять что же я все-таки хочу. Как правило все эти "самописные" системы автоматизации ужасно дырявые, ибо проектировались с прицелом на быстрое достижение бизнес-выгод и конечно же никто не думал о безопасности. Да что далеко ходить - SAP тоже был дырявый, пока его не стали успешно пентестить и закидывать файндингами несчастных бюргеров Вальдорфа.
Вот на такие home-made поделки и может быть направлена APT, эксплуатирующая 0-day там. И с этим нужно и можно бороться. Как? Опять же, очевидными способами - внедрить SDLC и не допускать производства софта мимо этого процесса.
Если вы работаете в компании, которая сама не производит ПО и технических средств в чем может быть обнаружена уязвимость нулевого дня, вам не надо сильно много думать об атаках на эти уязвимости. Логика тут проста - вы не можете в полной мере управлять этим риском. Банально, у вас нет механизмов исправить эти уязвимости (поскольку не вы разработчик). Вы можете налепить множество детектирующих (которые вам реактивно покажут, что вас атаковали) и компенсирующих (которые, может, помогут вам восстановиться быстро или сделают что-то что снизит ваш возможный ущерб) контролей, но закрыть 0-day вы не сможете - это может сделать только производитель.
Именно для этого мы исправно платим производителям ПО за поддержку, а они, в свою очередь нам исправно латают свои дырки - это, в целом, единственное, как вы можете повлиять на 0-day. Если вы действительно сильно озабочены 0-day и есть подтверждения, что они часто возникают, а производитель плохо выпускает заплатки - меняйте производителя (... ну или навешивайте детектирующие, компенсирующие контроли и всякие другие навесные штуки, которые снизят вероятность эксплуатации или снизят возможный ущерб).
Итак, мы не боимся 0-day, пойдем далее. Выходит, мы не боимся того, о чем не знаем (вот действительно подтверждение того, что многие знания преумножают печаль) - это уже хорошо, поскольку опасаться не зная чего - вполне определенный медицинский диагноз, который с трудом поддается лечению. Несложными умозаключениями приходим к тому, что APT (если слово кажется сложным, можно заменить на 0-day, концептуально смысл не поменяется) также не стоит опасаться. APT по определению всегда будет успешной, она всегда будет направлена туда, где нет защиты, в противном случае - это не APT. Поэтому всякие продвинутые системы для "защиты от APT" - не более чем ловкословие маркетологов, - не надо на это вестись.
Но пост о том, кому бояться... - да. да, есть такие и кто они - понятно - те, кто сами пишут софт для своих нужд. В целом, таких полно и сам я неоднократно прибегал к "наколеночной" автоматизации, - сказываются годы работы программистом - в ряде задач проще самому написать, чем искать готовое решение, его закупать, внедрять и т.п. или кому-либо объяснять что же я все-таки хочу. Как правило все эти "самописные" системы автоматизации ужасно дырявые, ибо проектировались с прицелом на быстрое достижение бизнес-выгод и конечно же никто не думал о безопасности. Да что далеко ходить - SAP тоже был дырявый, пока его не стали успешно пентестить и закидывать файндингами несчастных бюргеров Вальдорфа.
Вот на такие home-made поделки и может быть направлена APT, эксплуатирующая 0-day там. И с этим нужно и можно бороться. Как? Опять же, очевидными способами - внедрить SDLC и не допускать производства софта мимо этого процесса.
No comments:
Post a Comment