Многофакторная аутентификация

Первое, что должен сделать пользователь для защиты своих учетных данных в интернете, – включить многофакторную аутентификацию (MFA). Как уже говорилось в главе 1, факторы аутентификации – это то, что у пользователя есть, то, что является частью пользователя, и то, что пользователь знает. Использование двух факторов означает, что злоумышленнику придется скомпрометировать оба, чтобы получить доступ к учетным записям жертвы. А значит, для атаки потребуется больше усилий.

Регистрирующийся на онлайн-платформе пользователь не может повлиять на то, как хранится его имя пользователя и пароль. В идеале все пароли должны храниться с использованием функции хеширования (англ. password-hashing function, PHF), которая усложняет пароли с помощью добавления к ним соли и создания хеша из полученных результатов. К сожалению, в реальности все не всегда так. Не каждая компания следует передовому опыту при создании пользовательского программного обеспечения. Поверхностный поиск в интернете показывает, что любые учетные данные можно приобрести в даркнете за бесценок, а в бесчисленных статьях на эту тему подробно описывается, через какое время пользователи получают уведомление о взломе. Некоторые люди так и не узнают об этом.

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

MFA должна быть активирована для каждой учетной записи, представляющей ценность для вас или вашего работодателя.

Реагирование на инциденты

Даже если вы не входите в группу реагирования, очень важно знать, какие действия от вас потребуются при возникновении инцидента. Никто не хочет узнать об этом, когда чрезвычайная ситуация уже произошла, поэтому лучше подготовиться к ней заранее. Представьтесь сотрудникам службы безопасности и попросите их рассказать, что вам нужно знать на случай возникновения инцидента. Скорее всего, они будут очень удивлены и рады вас услышать. Довольно часто службы безопасности забывают сообщить, чего они ожидают от всех остальных сотрудников организации в критической ситуации.

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

Расскажите им:

• что такое «служебная необходимость» и что нельзя распространять информацию о произошедших инцидентах без разрешения;

• кто должен быть доступен в рабочее время, а кого могут вызвать в срочном порядке;

• что у вас есть разрешение привлечь их к действиям по реагированию на инциденты, вне зависимости от выполняемых ими задач или дедлайнов;

• что инциденты безопасности – это чрезвычайные ситуации и службе безопасности требуется содействие, чтобы хорошо выполнить свою работу и защитить организацию.

В конце поблагодарите всех за внимание.

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

Пожарные учения

Проведение симуляций инцидентов безопасности для различных жизненно важных видов бизнес-деятельности – очень полезное использование времени. Подобно пожарным учениям, подготавливающим к действиям при пожаре, симуляция инцидентов безопасности готовит к чрезвычайным ситуациям, связанным с IТ-безопасностью. Данный вид мероприятий позволяет еще до возникновения реального происшествия выявить, в каких процессах могут возникнуть проблемы. Лучше всего узнать и устранить недостатки процесса реагирования на инциденты до того, как экстренная ситуация действительно возникнет. В «пожарные учения» могут входить: атаки красной команды; тестирование систем защиты и оповещения, которое позволяет убедиться в их активности и правильной работе; проверка доступности различных систем, которые в нормальных условиях используются редко; тестирование плана аварийного восстановления; проверка эффективности плана обеспечения непрерывности бизнеса и т. д. Необходимо протестировать все средства, которые могут потребоваться для урегулирования инцидента, и убедиться в их доступности в случае необходимости.

АВАРИЙНОЕ ВОССТАНОВЛЕНИЕ И ПЛАНИРОВАНИЕ НЕПРЕРЫВНОСТИ БИЗНЕСА

Несколько лет назад во время выборов Боб вел огромный проект по предоставлению технологических услуг. Заказчики хотели, чтобы у него был не только план аварийного восстановления (англ. a Disaster Recovery, DR), но и план обеспечения непрерывности бизнеса (англ. Business Continuity Plan, BCP). Они очень серьезно относились к соблюдению принципов демократии и осуществлению права голоса. Абсолютно ничто не должно было помешать в день голосования предоставить общественности результаты выборов. Боб составил планы А, Б, В, Г и Д как часть BCP. Использование технологии, разработанной в рамках основного проекта, было планом А. План Б подразумевал переход на имеющиеся резервные реальные сервера с совершенно другим интернет-соединением и интернет-провайдером в случае выхода из строя основной технологии. Согласно плану В, результаты выборов отправлялись вручную с помощью мобильной связи. План Г – использование спутниковой связи. План Д заключался в том, чтобы отвезти машину с результатами в ближайший город, где есть связь, и отправить их оттуда. Все было очень серьезно.

В рамках плана аварийного восстановления (DR):

• были автоматизированы все развертывания приложения с помощью системы CI/CD;

• был установлен «горячий» центр обработки данных с двумя отдельными центрами обработки данных, в каждом из которых работали точно такие же системы с постоянной синхронизацией;

• были отработаны откаты всех баз данных и серверов приложения;

• был разработан отдельный сайт на случай наводнения или возникновения любого другого физического препятствия, блокирующего доступ к основному операционному центру безопасности (SOC) и сетевому операционному центру (NOC). Это решение было дорогим, но целесообразным. Ничто не могло встать на пути демократии.

Было еще много решений и действий, но Бобу дали понять главное: несмотря ни на что выборы должны состояться, и от него требовался обеспечивающий это план (BCP). Заказчики также попросили его составить план аварийного восстановления, чтобы в случае настоящей аварии можно было в кратчайшие сроки восстановить работоспособность всех критически важных систем.