«Взломайте нас, чтобы было красиво»



    Дисклеймер


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


    Мы попытаемся обратить внимание на то, что считаем проблемой современного российского рынка услуг в сфере информационной безопасности.


    Введение


    Чтобы читателям был понятен контекст, мы решили начать с бэкграунда. Статья написана аналитиком информационной безопасности (мной) и специалистом по тестированию на проникновение (моим коллегой InfiniteSuns ).


    Работая с заказчиками, мы систематически сталкиваемся с непониманием сути оказываемых нами услуг. Нередко это непонимание вызвано тем, что оно перенеслось на заказчика от компании, которая оказывала эти услуги. Однажды в ходе проведения внутреннего пентеста повышение привилегий и устранение средств защиты на предоставленной заказчиком офисной машине вызвало недоумение у начальника службы ИБ.


    Далее в ходе обсуждения выяснилось, что до этого под названием «пентест» заказчику продавали сканирование внутренней сети при помощи «nmap» с параметром «--script vuln». Естественно, в очередной раз заказчик ожидал от пентестеров подобного поведения и искренне удивился, когда они начали захватывать его контроллер домена.


    Временами случается, что при проведении работ отдельным этапом выделяют контроль устранения уязвимостей, выявленных в ходе предыдущего исследования. А также случается, что для этого заказчик предоставляет отчёт об этом самом предыдущем исследовании. Глядя в такой отчёт, иногда дивишься находчивости коллег по рынку.


    Автоматизированное сканирование уязвимостей временами продают хоть как пентест, хоть как анализ защищённости. В таких условиях неудивительно, что приходится слышать от заказчиков нечто вроде «Взломайте нас, чтобы было красиво». В какой-то момент мы поняли, что мы далеко не первые, кто это заметил:




    Оставляем читателю для размышления вопрос — почему нет четкого понимания заказываемых услуг и их результата? Из-за некомпетентности участников рынка инфосек-услуг? Или они намеренно водят клиентов за нос, продавая более простые услуги под видом комплексных и дорогих?


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


    CheatSheet


    Виды работ


    Давайте рассмотрим пять различных работ:

    • Тестирование на проникновение (Penetration Testing)
    • Редтиминг (Red Team Assessment)
    • Анализ защищенности (Security Analysis)
    • Сканирование уязвимостей (Vulnerability Scanning)
    • Аудит безопасности (Audit)


    Всю информацию, касающуюся перечисленных выше работ, для удобства мы разделили на два уровня:

    • Базовый (в основном теле статьи)
    • Расширенный (спрятан под спойлером для тех, кто хочет узнать больше)


    В «Базовом уровне» рассматриваются следующие ключевые моменты:

    • Цель
    • Фокус
    • Уровень зрелости ИБ
    • Результаты

    В «Расширенном уровне» рассматриваются следующие ключевые моменты:

    • Примеры задач
    • Методы достижения цели
    • План работ
    • Критерии завершения

    Тестирование на проникновение


    Цель:

    Определить, может ли текущий уровень защищённости инфраструктуры выдержать попытку вторжения потенциального злоумышленника с определённой целью.


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


    Фокус: Важнее глубина исследования, чем ширина.


    Уровень зрелости ИБ: От среднего до высокого.


    Результаты: Факт и/или вероятность взлома (проникновения) и получения информации злоумышленником.


    Расширенная информация:
    Примеры задач:

    • Получить несанкционированный доступ к информации о клиентах, их средствах и другим данным.
    • Проникнуть из офисного сегмента в «боевой», где расположены рабочие серверы.
    • Нарушить доступность определённого сервиса.
    • Получить доступ к файловой системе с некими правами.
    • Скомпрометировать исходные коды ПО из системы контроля версий.

    Методы достижения цели: Все доступные методы и средства, удовлетворяющие ограничениям, поставленным заказчиком (в т. ч. социальная инженерия, атаки перебором и др.). Исследователи ищут кратчайший и самый дешёвый путь достижения целей.

    Критерии завершения: Проект заканчивается либо когда поставленная цель будет достигнута, либо по истечению времени на проект (если рассматриваются многие вектора).

    План работ:

    1. Получить предварительную информацию об объекте (используются все доступные источники информации).
    2. Составить карту сети, определить типы и версии устройств, ОС, сервисов, приложений по реакции на внешнее воздействие.
    3. Выявить уязвимости сетевых служб, сервисов и приложений (включая базовый анализ веб-приложений с детектированием уязвимостей, способствующих достижению поставленной цели).
    4. Проанализировать уязвимости внутренних и внешних ресурсов.
    5. Подготовить подходящие сценарии атак. Провести атаки, связанные с социальной инженерией и/или атаками типа отказа в обслуживании (по согласованию).
    6. Осуществить проникновение.

    Редтиминг


    Цель:

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


    Повысить готовность организации противостоять Advanced Persistent Threat.


    Получить более реалистичное понимание риска для вашей организации.


    Фокус: Важнее моделировать вредоносные действия аналогично Advanced Persistent Threat.


    Уровень зрелости ИБ: Высокий.


    Результаты: Подтверждение возможности служб информационной безопасности организации вести противодействие реальной атаке.


    Расширенная информация:
    Примеры задач:

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

    Методы достижения цели: Все доступные методы и средства, направленные на многокомпонентную и всестороннюю атаку против программного обеспечения, оборудования, людей и объектов.

    Критерии завершения: Проект заканчивается либо по просьбе Заказчика, либо по истечению времени на проект.

    План работ:

    • План работ полностью зависит от бизнес процессов Заказчика.
    • Включает в себя планы работ по тестированию на проникновение, социотехническому исследованию и тестированию физической защищенности (офисы, склады и т.д.).

    Анализ защищенности


    Цель:

    Найти все известные и потенциальные уязвимости и недостатки, способные привести к нарушению конфиденциальности, целостности и доступности информации.


    Сформировать рекомендации по повышению уровня защищённости.


    Фокус: Важнее ширина исследования, чем глубина.


    Уровень зрелости ИБ: От низкого до среднего.


    Результаты: Максимально полный перечень обнаруженных уязвимостей и недостатков.


    Расширенная информация:
    Примеры задач: Провести комплексный анализ каких-либо IT-ресурсов: программно-аппаратных комплексов, веб-приложений, ДБО, мобильных приложений и т.д.

    Методы достижения цели: Исследования методом «чёрного / белого / серого ящика», анализ исходного кода, анализ структуры, функций, используемых технологий, подтверждение обнаруженных уязвимостей.

    Критерии завершения: Проект заканчивается по факту завершения проверок на наличие уязвимостей всех типов во всех заявленных подсистемах.

    План работ:

    1. Определить метод, который целесообразно использовать для анализа защищённости.
    2. Построить модели угроз и нарушителя, если необходимо.
    3. Провести инструментальные и ручные проверки для отдельных типов уязвимостей (отсечение ложных срабатываний и выявление уязвимостей, которые не обнаруживаются автоматизированными средствами).
    4. Исследовать уязвимости, чтобы подтвердить их наличие и возможность эксплуатации.
    5. Проэксплуатировать ряд наиболее критичных уязвимостей (по согласованию).

    Сканирование уязвимостей


    Цель:

    Найти и оценить все известные уязвимости в информационных системах организации.


    Регулярно поддерживать и актуализировать состояние информационной безопасности организации.


    Фокус: Важнее ширина исследования, чем глубина.


    Уровень зрелости ИБ: От низкого до среднего.


    Результаты: Максимально полный перечень обнаруженных известных уязвимостей.


    Расширенная информация:
    Примеры задач:

    • Провести сканирование внешнего сетевого периметра организации на предмет наличия уязвимых сервисов.
    • Исследовать изменения в открытых портах для сервисов на внешнем сетевом периметре организации.
    • Провести сканирование внутреннего периметра на предмет наличия уязвимых сервисов.
    • Анализ наличия известных уязвимостей компонентов веб-приложений.

    Методы достижения цели:

    • Автоматизированное проведение проверок в соответствии с выбранным инструментом.
    • Обработка исследователями и/или аналитиками результатов автоматизированных проверок и исключение ложных срабатываний


    Критерии завершения: Проект заканчивается по факту завершения всех проверок, предусмотренных автоматизированным инструментом.

    План работ:

    1. Определить инструментарий, который целесообразно использовать для автоматизированного сканирования.
    2. Провести инструментальные проверки
    3. Провести ручной анализ результатов проверки (исключение ложных срабатываний)

    Аудит безопасности


    Цель: Проверить, насколько информационная система (или её компоненты) и процессы соответствуют требованиям, лучшим практикам или рекомендациям нормативных актов, стандартов и документации производителей оборудования и ПО.


    Фокус: Важен объём выполнения требований и рекомендаций.


    Уровень зрелости ИБ: От низкого до высокого.


    Результаты: Заключение о соответствии требованиям / рекомендациям.


    Расширенная информация:
    Примеры задач:

    • Проверить соответствие информационной системы СТО БР ИББС.
    • Проверить соответствие информационной системы Приказу №21 ФСТЭК России.
    • Проверить веб-серверы на соответствие рекомендациям CIS.

    Методы достижения цели: Ручное или автоматизированное проведение проверок в соответствии с выбранной методикой.

    Критерии завершения: Проект заканчивается по факту завершения всех проверок, предусмотренных методикой.

    План работ:

    1. Адаптировать методику под объект исследования.
    2. Составить список проверок
    3. Провести ручные и/или автоматизированные проверки
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 26
    • +6
      Отличное структурирование, хоть на стену вешай
      • 0
        Внутренней безопасности и оргмерам надо уделять не меньше внимания.
        Часто вместо пентеста проще дать денег уборщице, чтоб что-то на флешку скинула.
        Или чуток побольше админу, добыть клиентскую базу целиком.
        Ибо несертифицированные СЗИ бывают дырявы, как дуршлаг.
        Недавно лично столкнулся: habrahabr.ru/post/343722
        • 0

          Что если не секрет подразумевается под внутренней безопасностью?) И причём тут СЗИ?

          • 0
            Защита от внутренних нарушителей, находящихся внутри периметра. Нелояльных сотрудников, в том числе админов, гостей.
            Собсно СЗИ для этого и применяют в комплексе с орг. мерами.
            В АСВН, не соединенных с открытыми сетями, пентест не очень актуален, а вот загремевший с 4 курса студент уже может попытаться дел натворить.
            • 0

              В рамках некоторых работ таких сотрудников тоже проверяют. Другими словами проверяются не только технологии но и люди.

              • 0
                Как отличить таких от не таких?
                Методика есть?

                Вопрос был про проверки внутренней защиты, а не про сотрудников
          • +1
            Справедливости ради, наличие сертификата у СЗИ тоже не гарантирует его непоколебимость, ибо у вышеупомянутого DeviceLock тоже есть сертифицированные версии, состав которых от не сертифицированных ничем не отличается, ага.
            • 0
              Нет у него ничего сертифицированного.
              В комментах к статье осуждалось.
              И в мою контору они пытались сунуться в МО пролезть, были посланы.
              В этой жиже бултыхаюсь 20 лет, так что мало-мало понимать.
          • 0
            Здесь не будут называться имена, ни на кого не будут показывать пальцем.

            А почему нет? Я действительно не понимаю.
            • +1

              Цель статьи обсудить проблему, а не тыкать в коллег по сфере.

              • 0
                Напоминает ремонтников, скрывающих схемки плат от телевизоров, чтоб конкурентов не плодить. :)
              • +2
                Чтобы не отпентестили в подворотне
              • 0
                Будет ли признан успешным тест на проникновение на склад, к примеру, если при входе показать охраннику договор на проведение тестирования с подписью директора? При условии, конечно, что он после этого пропустит незнакомца внутрь.
                • 0

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

                  • 0
                    Типичная ситуация: обязан ли рядовой в карауле пропускать полковника?
                    А генерала?
                    • 0
                      «207. Часовой обязан:

                      не допускать к посту ближе расстояния, указанного в табеле постам и обозначенного на местности указателями запретной границы, никого, кроме начальника караула, помощника начальника караула, своего разводящего и лиц, которых они сопровождают»
                      • 0
                        Только на отдел АСУ устав караульной службы не распространяется.
                        • 0
                          Это понятно. А надо, чтобы рспространялся, в том или ином виде, тогда и проблем будет меньше. Грамотно составленная документация плюс автоматизация, направленная на максимальное исключение человеческого фактора.
                        • +1
                          Напрашивается вопрос: что делать в случае смерти начальника караула, помощника начальника караула и своего разводящего?
                          • 0
                            В уставе имеются в виду не конкретные люди а «должности».
                            • +1
                              вспоминается
                              анекдот
                              Часовой на посту. Подходит майор.
                              — Фамилия?
                              — Рядовой Петров!
                              — Сколько человек в роте?
                              — Семьдесят!
                              — А в батальоне?
                              — Двести пятьдесят!
                              — А ты чего военную тайну рассказываешь? Вдруг я шпион?
                              Выстрел. Солдат:
                              — Ты посмотри, какая сволочь!

                              Собственно, вопрос был про разрешение таких коллизий, т.к. часовой может не знать об изменениях, вызванных вышеназванными потерями.
                              • 0
                                Ну, если бы точным, то не «должности», а «обязанности». Начальник караула, его помощник и разводящий — это не должности. Это обязанности, которые могут возлагаться на определенных должностных лиц.
                              • 0
                                В случае гибели начальника караула, его помощника и разводящего или физической невозможности для них выполнять свои обязанности снятие или смена часового производится дежурным по воинской части в присутствии своего командира роты или батальона.
                                УГКС
                        • 0
                          На мой взгляд сканирование на уязвимости можно рассматривать как часть аудита безопасности. Например, у нас есть описанный процесс обновлений или парольных политик. При аудите соблюдения процессов применяется и автоматизированное сканирование.

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

                            В итоге — если нужно, всё равно данные получат.
                            Гос секреты воруют, а вы про какие-то компании :)


                            ПС: но это не значит что нужно оставить всю инфу в открытом доступе, нет… Просто констатация факта :)

                          • 0
                            На «Меньшевике» примерно это сейчас и происходит.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.