В 2016 году у меня было очень много задач, связанных с реагированием на инциденты информационной безопасности. Я потратил на них в общей сложности около 300 часов, самостоятельно выполняя необходимые действия либо консультируя специалистов пострадавшей стороны. Материалом для данной статьи послужили мои записи, сделанные в процессе этой работы.
Централизованное логирование
Подзаголовком этого раздела может послужить такой вопрос: «Чем стандартный инцидент отличается от катастрофы?»
Хорошее или плохое ведение логов определяет дальнейшую работу с инцидентом. Я каждый раз на практике убеждаюсь, что журналы аудита являются фундаментом хорошей политики безопасности и эффективного реагирования на нарушения ИБ (информационной безопасности).
Начиная работу с инцидентом, я первым делом стараюсь понять, можно ли положиться на логи потерпевшей стороны. От полученного ответа зависит успех всей кампании. К счастью, в CI/CD/DevOps-культуре использование централизованных систем ведения журналов и оповещения становится стандартом. Я уже начал рассчитывать на то, что созданная в последние три года компания предоставит мне большое количество данных, пригодных для анализа.
Если вы по тем или иным причинам откладываете модернизацию своей системы ведения журналов, настоятельно рекомендую пожертвовать всем, чем только можно, но постараться инвестировать в качественное журналирование. Надо стремиться к тому, чтобы получать как можно больше логов и хранить их в как можно меньшем количестве мест.
Очень важно вести журналы хостов, приложений, событий аутентификации и действий с облачной инфраструктурой. Эта информация поможет в расследовании инцидентов, проведении профилактической работы и будет полезна другим командам, например, для оценки доступности сервисов.
При настройке журналирования не забывайте о конфиденциальности пользователей, а также необходимых и достаточных сроках хранения данных в журналах. Общей практикой является уменьшение этих сроков (но многое зависит от специфики создаваемого продукта).
Вывод: хорошо оформленные, доступные, централизованные и полезные с точки зрения генерации тревожных сообщений логи лучше поставить в приоритет перед другими проектами ИБ. А новый тип оповещения, если все сделано правильно, должен попадать в production в течение десяти минут.
Вы можете так и не узнать основную причину взлома
Несколько инцидентов, с которым я работал в прошлом году, закончились тем, что первоначальный способ проникновения так и не был найден.
Это настоящий кошмар для специалистов пострадавшей стороны, которые должны проинформировать руководство о предпринятых шагах, на деле не основанных на достоверной информации. Локализация проблемы становится неполной и проводится по принципу «сделали все возможное».
Если известна основная причина, план по минимизации последствий выглядит примерно так: «Мы вычищаем этот ноутбук, заменяем этот сервер, блокируем одну учетную запись».
В противном же случае: «Мы чистим ВСЕ ноутбуки, заменяем ВСЕ сервера, блокируем ВСЕ учетки».
Нахождение основной причины инцидента — важная веха, определяющая эмоциональную атмосферу, в которой будет проходить дальнейшая работа. Эта причина может существенно влиять на конечный результат.
До тех пор, пока основная причина инцидента не найдена, в команде будет нарастать напряженность, которая может привести к внутренним конфликтам. Я стараюсь не допускать подобных ситуаций. Помню случаи, когда буквально один разговор на повышенных тонах отделял команду от всеобщей паники, взаимных обвинений и массовых увольнений по собственному желанию.
Независимо от того, какого размера ваша компания, очень важно «распределять роли» для членов команды и периодически отрабатывать взаимодействие во время кризиса.
Вывод: проводите регулярные штабные учения и тесты на проникновение. Отрабатывайте любую найденную уязвимость как полноценный инцидент. Практикуйте сценарии, в которых вы не управляете ситуацией, не всеведущи, не имеете нужных логов и не понимаете, что происходит. Не упускайте возможность тренировать навыки борьбы в партере из положения «лежа на лопатках», так как в реальности защищающаяся сторона часто начинает свои самые важные схватки именно в этой позиции.
Дом под прицелом
Фраза «Bring your own device» часто используется, чтобы категорично описать риски, которые сотрудники в буквальном смысле слова «приносят» на работу. Однако очень часто персонально направленные атаки под это определение не подпадают.
Многие помнят недавнюю историю с группой APT, когда взломщики атаковали личную почту и устройства сотрудников. Если там хранятся ключи и пароли или с этих устройств осуществляется доступ к корпоративным ресурсам, уже не имеет значения, приносят их в офис или нет.
Невероятно сложно оценить масштаб угрозы для информационной безопасности компании, которую представляют домашние устройства сотрудников, поскольку даже после произошедшего инцидента люди неохотно делятся личной информацией, что затрудняет расследование. Общей тенденцией является использование одинаковых паролей для домашних и корпоративных аккаунтов, а также хранение своих рабочих учетных данных на личных устройствах, в том числе и на тех, которые не используются для доступа к корпоративным ресурсам.
Также стоит упомянуть инцидент, при расследовании которого возникли серьезные основания полагать, что один из инженеров с целью удаленной отладки хранил важные учетные данные в личной облачной инфраструктуре.
Необходимо учитывать и тот факт, что проверка пользовательских устройств может оказаться слишком неприцельной и дорогой, и это также доказывает важность сбора качественных логов.
Вывод: находите способы повысить домашнюю информационную безопасность сотрудников. Оплачивайте использование менеджеров паролей, оборудования для многофакторной аутентификации и т. д. Убеждайте, что они должны привлекать сотрудников отдела информационной безопасности, если у них возникли проблемы с обеспечением личной ИБ или они заметили какую-то подозрительную активность, даже не связанную с работой. Учите сотрудников следить за информационной безопасностью членов их семей и в случае необходимости помогайте в этом вопросе.
Ваши биткоины в опасности, даже если у вас их нет
Интеграция используемой платформы с биткоин-компаниями ставит вашу информационную безопасность под угрозу. Для более подробного изучения вопроса можно почитать Blockchain Graveyard и SendGrid’s blog.
Вывод: если вы сильно зависите от технологий партнеров, найдите способ обезопасить себя. Если вы биткоин-компания, доведите свою паранойю до крайней степени обострения и примите экстраординарные меры по ограничению доступа к системам партнеров.
Изощренные методы взлома
В прошлом году многие сообщения о взломах упоминали «высококвалифицированных хакеров», которых далее начинали критиковать за тривиальный способ проникновения.
Многие атаки начинаются с фишинга, купленных эксплоитов, слитых ключей и некоторых других очевидных и сравнительно легко предотвращаемых способов взлома.
На самом деле «изощренная» часть обычно подробно не обсуждается. Слишком легко указать на «дилетантский» вектор атаки и проигнорировать все остальное.
Но не судите противника по его первому шагу. Он может показать, что такое «изощренность», развивая нападение с плацдарма, завоеванного простыми методами.
Например, первоначальный вектор атаки может и не представлять особого интереса, но способы, с помощью которых атакующий получил доступ или учетные данные, взломав стороннюю платформу, могут многое сказать о мотивированности и квалификации вашего противника.
Например, назвал бы Lockheed методы их взлома в 2011 году изощренными, даже учитывая, что нападающие хорошо подготовились, украв данные RSA SecureID? Если атака началась с обычного фишинга, значит ли это, что противник слаб?
Вывод: высококвалифицированные хакеры, начиная вторжение, не играют мускулами. Не делайте ошибку: не стоит недооценивать первоначальные неуклюжие попытки взлома. Возможно, атакующий просто хочет добиться результата минимальными усилиями. За очередной заурядной попыткой фишинга может последовать новый 0Day.
Управляйте своими учетными данными и ключами
Управление конфиденциальными данными является важным фактором информационной безопасности.
В прошлом году меня не привлекали к работе с инцидентами в компаниях, применяющих ролевые модели доступа и управляющих конфиденциальными данными с помощью специального хранилища.
Это может означать следующее: таких компаний не существует, их мало или они не сталкиваются с инцидентами, достойными привлечения специалиста по реагированию на инциденты.
В процессе работы я постоянно был свидетелем случаев, когда ключи прописывались в исходном коде, утекали в облачные платформы логирования, небезопасно хранились на персональных устройствах сотрудников или копировались в gist и pastebin. Все вышеперечисленные ошибки становились как первопричиной взломов, так и усугубляющим фактором (конечно, если атакующему удавалось завладеть этими данными).
Вывод: посмотрите на роли AWS, не вбивайте ключи и пароли в исходный код, не давайте разработчикам реквизиты доступа к боевым системам и будьте готовы разворачивать их быстро и часто.
Кража учетных данных до сих пор является одной из самых простых задач
В организациях, качественно информирующих пользователей (особенно руководство) об опасности повторного использования паролей, тем не менее произошло несколько инцидентов. Эти информационные сообщения, если только они не были адресованы лично определенным сотрудникам, теряли силу, когда дело доходило до персональных учетных записей.
Повышение осведомленности может отсрочить неизбежное, но гораздо эффективнее оказывается внедрение системы управления учетными данными на базе провайдера идентификации, а также интеграция технологии Single Sign On в облачные решения. Мне не приходилось сталкиваться с инцидентами, при которых был бы взломан механизм MFA, используемый в рамках корпоративного решения по идентификации пользователей.
Если Single Sign On не вариант, использование MFA везде, где это только возможно, способствует минимизации рисков. Отдельно упомяну GitHub, поскольку разработчики часто сохраняют конфиденциальные данные в исходном коде. В этом случае в качестве временной меры можно применить принудительную многофакторную аутентификацию, пока для ключей, паролей и прочих секретных данных не найдется подходящее хранилище.
Общие черты инсайдерских угроз
В прошлом году мне попалось совсем немного связанных с инсайдерами задач. Во всех случаях их мотивы были хорошо известны — я регулярно сталкиваюсь с ними вот уже на протяжении нескольких лет. 2016 также не стал исключением.
Можно выделить группу инцидентов, которая связана с деятельностью людей, считающих себя частью культуры стартапов Кремниевой Долины. Они очень активно общаются с прессой, стараясь привлечь внимание к своей настоящей или будущей компании.
В частности, инсайдер может думать так: «Если я сейчас солью что-нибудь интересное журналистам, возможно, они потом напишут о моей идее для стартапа».
Хоть это и достаточно специфический сценарий, сотрудники высокотехнологичных компаний любят передавать прессе IP-адреса и информацию о продуктах, получая взамен различные выгоды.
Эта проблема стала в достаточной степени общей и уже может называться тенденцией. От нее сложно найти эффективную защиту, так как подобные утечки допускают сотрудники, не имеющие высокого уровня доступа. Для этой проблемы трудно найти решение общего вида, которое одновременно не приведет к превращению организации в полностью закрытую Apple-подобную компанию. Большинство исполнительных директоров стремятся оставаться открытыми для своих сотрудников и готовы пойти на этот риск.
В следующую группу попадают случаи, связанные с внутренними инструментами поддержки пользователей. Как только у вас наберется определенное количество сотрудников с доступом к инструментам администратора, один из них обязательно напакостит (в одиночку или сговорившись с кем-то еще).
Знайте размер своих долгов и не забывайте их возвращать
Практически во всех организациях, которым я помогал в прошлом году, была отстающая область с огромной технической задолженностью.
Это наводит меня на мысль, что компании, которые считают такие долги частью инженерного процесса, обычно хорошо организованы, и риски у них заметно ниже.
Стартап может развиваться очень быстро, срезать углы, вести агрессивную конкурентную борьбу и быть готовым идти на риск.
В фазе разработки и успешного запуска проекта начинающие компании сильно отличаются друг от друга подходом к документированию случаев, в которых им приходилось идти на компромисс, и ретроспективному анализу накопившейся задолженности.
Затем они возвращают свои долги.
Крайне редко я был свидетелем того, чтобы компания закрывала абсолютно всю техническую задолженность. Но организации, которые по крайней мере знают, где и что они должны, никогда не отстают настолько, чтобы пройти точку невозврата и оказаться в положении, когда их уже практически невозможно защитить.
Долги приходят с разных направлений: масштаб, скорость разработки, надежность сайта, нюансы работы с пользователями, предшествующая автоматизации ручная работа и, наконец, безопасность.
Проблема долгов по информационной безопасности в том, что они громко о себе не заявляют. Другие формы задолженностей приводят к ошибкам, расходам, жалобам пользователей и ярости инженеров. Долги по ИБ приводят лишь к созданию уязвимостей, и размер этих долгов очень сложно измерить. Для этого требуется кропотливая ручная работа либо использование продвинутых технологий.
Инженерная компания, которая умело управляет своими техническими долгами, обычно имеет меньше проблем с безопасностью.
Я редко встречал это на практике, но даже просто осознание проблемы и желание двигаться в направлении ее решения — уже отличный знак. Google — одна из немногих компаний, которая структурировала свою «задолженность по ошибкам», связанную с выпуском релизов, и прописала соответствующие политики. Они смогли сделать проблему «долгов» измеримой и решаемой. Ollie Whitehouse из NCC Group также говорил об этом.
Многие организации и не подозреваю, что некоторые их стандартные процессы (ретроспективный анализ, разбор завершившихся инцидентов) помогают избежать накопления чрезмерных технических задолженностей.
Вывод: прежде чем делать следующий большой шаг вперед, убедитесь, что ваши самые крупные долги отданы.
Заключение
Инциденты информационной безопасности могут многому нас научить. Очень важно найти способы говорить о них и, работая с ними, повышать свое мастерство.
@magoo
Обо мне: я занимаюсь информационной безопасностью, раньше работал на Facebook и Coinbase. В настоящий момент являюсь советником и консультантом нескольких стартапов. Специализируюсь на реагировании на инциденты и создании команд ИБ, но берусь и за многие другие ИТ-задачи.
Спасибо Collin Greene и Rob Witoff.
Автор: Centos-admin.ru
