День добрый. Выше, в первой части статьи, автор писал о том, что из-за постоянно меняющегося окружения невозможно построить 100% Ролевую модель. Т.е. обеспечить полностью работников необходимыми правами на долгое время. Меняются функциональные обязанности, меняется структура – это естественный процесс. Если даже предположить, что можно выстроить в моменте 100% ролевую модель, то через месяц мы обнаружим, что она уже не соответствует реалиям.
Поэтому правильным подходом будет обеспечение пользователей базовыми необходимыми правами. Причём, в зависимости от конкретной позиции и подразделения количество базовых прав может быть разным. Где-то это будет 80%, а где-то придётся остановиться на 20%. Остальные необходимые права можно оставить для запроса по отдельным заявкам.
Кроме того, сама Ролевая модель – это живой организм, который нужно поддерживать постоянно (как человек не может обходиться без пищи, он просто умрёт). Должен быть разработан отдельный процесс, который обеспечивает поддержание Ролевой модели в актуальном состоянии, в этом процессе должны быть тоже распределены роли и обязанности. Но об этом в следующей части нашей статьи. Скоро опубликуем :)
Спасибо за комментарий. Жаль, что вам так показалось, но вы сделали не вполне верные выводы по статье.
Red Teaming — это и есть учения и пришли они из военной области, поэтому и методы будут как на учениях.
Сценарий нужен больше для старта проекта и он будет изменяться в зависимости от ситуации. И согласованный сценарий, конечно, может иметь общие признаки с «армейскими учениями времен СССР».
Сценарий должен согласовываться ответственными людьми, а Blue Team не должна знать о проводимых работах. Тогда ситуации, когда все знают, откуда атакуют, не возникает (если мы говорим про классический Red Teaming).
По поводу того, что APT действуют не по playbook, — спорный вопрос.
Если рассматривать разборы атак различных APT, то они имеют общие тактики, в которых могут меняться техники, но часто даже техники повторяются.
Главная задача Red Teaming'а — это тренировка и оценка эффективности применяемых TTP Blue Team и исходя из того, что заказчик хочет получить, подбираются и методики, и сценарии и т.д.
Часто мы сталкиваемся с атаками, когда конечной целью служит один из клиентов оператора, но хакеры пытаются “завалить” всю инфраструктуру. При этом, конечно, могут пострадать и другие клиенты атакуемой инфраструктуры.
Тут двоякая ситуация.
В Ipv6 нет nat-а. Каждый чайник имеет свой IP. И часто имеет много дыр в безопасности. Соответственно, без NAT можно иметь доступ к каждому такому устройству и эксплуатировать дыры в безопасности.
Но если, действительно, за NAT все-таки будет злой бот, то могут заблокировать всех.
Если мы говорим про IoT, то возникновение первопричины блокировки устройства за NAT — его взлома — уменьшается в разы.
NLA действительно включен в Windows по умолчанию и делает невозможной эксплуатацию части уязвимостей, поскольку требует аутентификацию до установления сессии, однако по-прежнему можно осуществить подбор учетных данных, и в нашей практике встречались случаи подбора пароля к RDP при включенном NLA с последующим внедрением вредоносного ПО на системе. К сожалению, практика показывает, что далеко не всегда в инфраструктуре организации возможно оперативно установить свежие обновления безопасности (именно поэтому к каждой исправленной уязвимости пишутся временные меры для тех, кто не имеет возможности установки обновлений). Ситуация с использованием RDP с доступом из сети Интернет для личного использования все же немного отличается от использования удаленного доступа для сотрудников организаций, в последнем случае требуется больше внимания уделить защите этого процесса.
С минимальными телодвижениями, быстро и бюджетно — это все-таки про сервисную модель. Если интересно, варианты для организации безопасного удаленного доступа, которые предлагаем мы, можно посмотреть тут www.youtube.com/watch?v=FJ9ADBtMF8A
В начале статьи написано — если исходники не доступны. Например, такое может быть в случае с унаследованным ПО. Исходников нет, а проанализировать код на уязвимости нужно.
В целом через nginx конечно же быстрее, но так как веб-сервер собственного изготовления и http заголовки свои, то остается достаточно высокая вероятность ошибки конфигурации и обработки собственных http заголовков, поэтому в итоге остается возможность RCE и OS commanding большое. В данном случае анализ защищенности данного веб-приложения был бы логичен. Это поможет оценить состояние целиком и понять актуальность применения WAF. Действительно, может оказаться, что векторов развития атак немного и их все можно закрыть без использования специализированного класса решения.
Фактически вы путем настройки nginx закрываете функционал WAF, фильтруя те параметры, которые возможно вписать в заполняемые поля. Дальше идет вопрос вероятностей – уверены ли вы, что учли все варианты. В целом кейс очень занятный, поэтому интересно было бы посмотреть в логах WAF, какие именно запросы отправляются на сервер. Можем предложить пилотный вариант и посмотреть на результаты. В качестве альтернативы также можем предложить услуги команды пентеста;)
Да, Ваш принцип построения понятен. Но Вы в основном описали именно принцип построения АСУ ТП. При этом общий тренд – это переход на Industrial Ethernet, подключение к MES и иным системам. Понятно, что компьютер не подключен к сети, но при этом суть в том, что не доверенные съемные носители могут быть элементом комплексной сложной APT, вот о чем речь. По хорошему нужен регламент, т.е. организационные меры, и технические меры, которые предотвращают несанкционированное подключение. Хорошо, если вы один обслуживаете этот АРМ, а если их много? Вы делаете харденинг ОС? Про вторую часть я бы предложил еще организовывать ДМЗ, в нее выносить сервисы, нуждающиеся в удаленном доступе. Подумал бы о применении PAM.
В статье оговаривался человеческий фактор при преодолении воздушного зазора. Либо халатность, либо результат соц. инженерии.
Именно так. По преодолением воздушного зазора подразумевалась конкретная стадия APT-атаки или халатность, или действия нелояльного сотрудника.
В МЭК 62443 к информационному тракту, организованному и использованием съемных носителей также подразумевается предъявление требований по кибербезопасности.
Поэтому правильным подходом будет обеспечение пользователей базовыми необходимыми правами. Причём, в зависимости от конкретной позиции и подразделения количество базовых прав может быть разным. Где-то это будет 80%, а где-то придётся остановиться на 20%. Остальные необходимые права можно оставить для запроса по отдельным заявкам.
Кроме того, сама Ролевая модель – это живой организм, который нужно поддерживать постоянно (как человек не может обходиться без пищи, он просто умрёт). Должен быть разработан отдельный процесс, который обеспечивает поддержание Ролевой модели в актуальном состоянии, в этом процессе должны быть тоже распределены роли и обязанности. Но об этом в следующей части нашей статьи. Скоро опубликуем :)
Red Teaming — это и есть учения и пришли они из военной области, поэтому и методы будут как на учениях.
Сценарий нужен больше для старта проекта и он будет изменяться в зависимости от ситуации. И согласованный сценарий, конечно, может иметь общие признаки с «армейскими учениями времен СССР».
Сценарий должен согласовываться ответственными людьми, а Blue Team не должна знать о проводимых работах. Тогда ситуации, когда все знают, откуда атакуют, не возникает (если мы говорим про классический Red Teaming).
По поводу того, что APT действуют не по playbook, — спорный вопрос.
Если рассматривать разборы атак различных APT, то они имеют общие тактики, в которых могут меняться техники, но часто даже техники повторяются.
Главная задача Red Teaming'а — это тренировка и оценка эффективности применяемых TTP Blue Team и исходя из того, что заказчик хочет получить, подбираются и методики, и сценарии и т.д.
Не мешает, но вопрос в том, будет ли кто-то реализовывать такую архитектуру подключения утюгов и чайников в IPv6
В Ipv6 нет nat-а. Каждый чайник имеет свой IP. И часто имеет много дыр в безопасности. Соответственно, без NAT можно иметь доступ к каждому такому устройству и эксплуатировать дыры в безопасности.
Но если, действительно, за NAT все-таки будет злой бот, то могут заблокировать всех.
Если мы говорим про IoT, то возникновение первопричины блокировки устройства за NAT — его взлома — уменьшается в разы.
Именно так. По преодолением воздушного зазора подразумевалась конкретная стадия APT-атаки или халатность, или действия нелояльного сотрудника.
В МЭК 62443 к информационному тракту, организованному и использованием съемных носителей также подразумевается предъявление требований по кибербезопасности.