Rambler's Top100
Статьи
Майк БЕРСЕЛЛ  08 ноября 2018

Трюк или угощение – чему Хэллоуин может научить нас в плане безопасности

Надо быть готовым реагировать на угрозы и вместе с тем быть готовым что-то менять. Как этого добиться? А нужно разрешить себе пугаться. Люди учатся новому, когда сталкиваются с ним и получают небольшой впрыск адреналина.

Я категорически не принимаю участия в праздновании Хэллоуина. В основном потому, что я британский скупердяй и не вижу причин раздавать сладости бесплатно. Но однажды, когда я собирался запереть дверь, задернуть шторы и притвориться, что дома никого нет, мне в голову пришла мысль, что этот праздничный ритуал может кое-чему научить нас как специалистов по информационной безопасности.

Как объясняют мои североамериканские коллеги, смысл этого мероприятия со слоганом «трюк или угощение» состоит в том, что к вам на порог заявляются малолетние визитеры и предлагают вас напугать. И тут у вас два варианта: либо принять их предложение, либо откупиться от этих потенциальных «рэкетиров» пригоршней магазинных сладостей или экологически чистыми чипсами, если ваш район населяет претенциозная публика.

И вот что пришло мне в голову: все предпочитают откупиться, хотя всем нам вообще-то нужен страх. Если не разрешать себе испытывать его хотя бы время от времени, то мы – и как личности, и как организации – легко можем скатиться в одно из двух состояний: самоуспокоение или панику.

В состоянии самоуспокоения вы как бы в курсе, что где-то там есть угрозы. Но считаете, что они вряд ли опасны конкретно для вас, поскольку у вас есть средства защиты и вы стабильно устанавливаете все обновления, которые присылают вендоры, в течение 8--12 недель. Так чего тут, собственно, бояться? А бояться, если не врать себе, есть чего: когда случится информационная атака или утечка данных, работа вашей организации может полететь ко всем чертям, сама организация может оказаться в центре громкого скандала или судебного разбирательства за нарушение GDPR, а вы лично можете быть уволены.

С другой стороны, в состоянии паники вы постоянно ожидаете худшего: принимаете каждый всплеск сетевой активности за DDoS, лихорадочно ставите последние обновления без предварительной оценки последствий для продуктивных систем и тормозите процесс разработки, запрещая разработчикам развертывать что-либо без соблюдения 64-этапной процедуры, которую вы аврально придумали пять лет назад, когда днем раньше шеф спросил вас, что такое «безопасный жизненный цикл разработки». Что в этом плохого? Ответ: организационный паралич, взаимное недоверие и поиски виноватого, когда выяснится, что вы безнадежно отстали от конкурентов по скорости внедрения инноваций. И для вас лично все это тоже может кончиться увольнением, как в случае самоуспокоенности.

Однако впадать в одну из двух вышеперечисленных крайностей вовсе не обязательно. Просто надо быть готовым реагировать на угрозы и вместе с тем быть готовым что-то менять. Как же этого добиться? А нужно разрешить себе пугаться. Люди учатся новому, когда сталкиваются с ним и получают небольшой впрыск адреналина. Я, разумеется, не призываю вас открыть свои системы для всех и каждого, чтобы любой желающий мог атаковать их и устраивать там хаос. Однако вы можете в той или иной мере взять ситуацию под контроль и, главное, подготовиться к ней.

Первое, что вы можете сделать, – это оценка рисков. Какие данные, системы, люди и процессы важнее всего для вашей организации с точки зрения последствий того, что они будут скомпрометированы, утрачены или временно недоступны? На что это повлияет? Выяснив это, вы сможете решить, где нужно тратить больше сил на защиту. Вы также можете продумать наиболее вероятные типы атак и атакующих. Но не слишком зацикливайтесь на этом, поскольку здесь всегда есть большой элемент непредсказуемости. Однако с непредсказуемостью тоже можно работать, например, обратиться к внешним специалистам по пенетрационному тестированию, или устроить мозговой штурм своими силами. Если вы пойдете на это, заручитесь поддержкой и привлеките специалистов на всех уровнях своей организации: HR, юридический отдел, продажники и прочие сотрудники помогут взглянуть на проблемы безопасности с таких точек зрения, до которых вы никогда не додумаетесь самостоятельно.

Следующий пункт может показаться неочевидным, но значительная часть процесса подготовки заключается не в том, чтобы предотвратить инциденты, а в том, чтобы подготовить к ним людей. Не «если случится атака», а «когда случится атака» – если люди четко это понимают и знают, что делать в случае неожиданностей, они будут чувствовать себя гораздо увереннее и вы, кстати, тоже. Нужно объяснить буквально всем и каждому, от гендиректора до офис-менеджера, на что обращать внимание и что делать в той или иной ситуации. Пусть вас не смущает банальность инструкции, типа «написать на такой-то e-mail» или «позвонить по такому-то номеру». Суть здесь в том, что без четких инструкций у людей мало шансов поступить правильно, и когда случается неожиданность, они, как правило, впадают в панику или оцепенение, а ни то, ни другое вам не нужно.

И знаете, что важнее всего? Автоматизация. Пока никто не может сравниться с человеком в плане количества и скорости аналитической работы. Компьютеры не способны принимать умные решения, хотя прогресс в области машинного обучения и искусственного интеллекта приближает их к этому. Зато машины могут действовать согласованно и быстро. Но решать, что именно они должны при этом делать, все равно нужно вам. Например, стоит ли немедленно остановить продажные системы, чтобы устранить возможную атаку вредоносного ПО, или лучше подождать до конца рабочего дня? Ответ на этот вопрос завязан на оценку рисков. Кроме того, машины могут плохо справляться с неожиданностями, поэтому вам нужно продумать, на что они должны обращать внимание. Они никогда не увидят всего, будь то новости об очередном вирусе-вымогателе или странный посетитель в вашем офисе, сующий флешку в компьютер. Поэтому вы можете твердо заверить своих сотрудников, что во всем этом всегда найдется место для людей. Или для зомби. Или для оборотней, вампиров или что там еще придет вам в голову.

Майк Берселл, главный архитектор безопасности, Red Hat
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!