Вступило в силу 1 июля 2024 г.:

· Стандарт Банка России СТО БР БФБО-1.8-2024 «Безопасность финансовых (банковских) операций. Обеспечение безопасности финансовых сервисов при проведении дистанционной идентификации и аутентификации. Состав мер защиты информации» (документ носит рекомендательный характер)
· Для кого: кредитные организации, некредитные финансовые организации и субъекты национальной платежной системы
· Что делать: зафиксировать в документации организации требования к уровням доверия результатов идентификации и аутентификации клиентов – получателей услуг, предоставляемых дистанционно.

Вступило в силу 27 июля 2024 г.:

· Постановление Правительства РФ от 18.07.2024 № 973 о внесении изменений в Правила уведомления организаторами распространения информации в сети «Интернет» Роскомнадзора
· Для кого: организаторы распространения информации в сети «Интернет»
· Что делать: действия от организации не требуются.
Постановление Правительства расширяет права Роскомнадзора в части принудительного включения организации в реестр, если:
· она не подала соответствующее уведомление,
· в отношении нее имеется вступившее в законную силу постановление суда об ответственности за повторное неисполнение требования по уведомлению Роскомнадзора о распространении информации

#ИБ
#ДеЮре

SQL-инъекция — это уязвимость, при которой злоумышленник может внедрить вредоносный SQL-код в приложение. Этот код выполняется на сервере базы данных, что позволяет атакующему получить доступ к конфиденциальным данным.
 
Принцип работы SQL-инъекции
Злоумышленник добавляет к легитимным данным (например, id=17) SQL-команду (например, id=17 union select null,null,version()-- ). Отправка сформированного вредоносного SQL-кода происходит через форму запроса или URL-параметр, который будет обработан сервером базы данных.
 
Существует три основных этапа эксплуатации SQL-инъекции:
1. Идентификация параметров приложения, уязвимых к SQL-инъекции. Выбор веб-приложения, которое использует SQL-запросы для взаимодействия с базой данных.
2. Сбор информации об используемой СУБД – версия, имя пользователя, названия баз и таблиц.
3. Эксплуатация уязвимости для извлечения данных из таблиц в базах данных.
 
В случаях, когда приложение не защищено от подобных атак, злоумышленники могут получить доступ к базе данных путем ввода произвольного SQL-кода.
 
Последствия от SQL-инъекций
Злоумышленник может получить доступ к конфиденциальной информации, хранящейся в базе данных (например, личные данные пользователей или финансовые данные).
Мошенник также может изменить или удалить данные, что приведёт к сбоям в работе системы. В худшем сценарии – злоумышленник сможет выполнять команды на сервере и получит доступ в сеть компании.
 
#ИБ
#ПолезноЗнать

Вопрос:

Как защититься от SQL-инъекции?

Ответ:

Для того чтобы защититься от SQL-инъекции, требуется реализовать ряд мер, направленных на предотвращение внедрения вредоносного SQL-кода.

Ранее мы уже рассказывали об SQL-инъекциях и последствиях, связанных с данным типом атак.
Чтобы защититься от SQL-инъекции, рекомендуется следовать следующим правилам:

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

· Использовать параметризованные запросы.
Эта технология позволит предотвратить включение данных непосредственно в запрос, что сделает инъекции невозможными.

· Использовать WAF-решения (Web Application Firewall).
WAF с помощью списка сигнатур позволят идентифицировать и фильтровать SQL-запросы.

· Управлять правами пользователей.
Пользователь системы управления базами данных (СУБД), от имени которого приложение выполняет запросы, согласно бизнес-логике должен иметь только минимальные права. Это поможет минимизировать последствия в случае эксплуатации SQL-инъекции.

· Своевременно обновлять ПО.
Разработчики ПО постоянно работают над устранением уязвимостей, в том числе и SQL-инъекций. Поэтому важно обновлять ПО до актуальных версий.

· Проводить анализ защищенности.
Регулярный анализ защищенности позволяет выявлять уязвимости и принимать меры по их устранению.

#ИБ
#KeptОтвечает

Защита информации от несанкционированного доступа является одной из ключевых задач ИБ. Для управления доступом могут использоваться разные модели.

Дискреционная модель (DAC)
В данной модели доступ к объектам предоставляется администратором с помощью списков или матриц доступа, в которых указано, какие ресурсы и права доступны конкретному субъекту.

Мандатная модель (MAC)
В данной модели предусматривается присвоение каждому объекту метки, определяющей уровень секретности, например: «не конфиденциально» и «конфиденциально». Уровень доступа к информации устанавливается работникам исходя из их задач. При этом ограничения работают не только снизу вверх, но и наоборот. Поэтому пользователь имеет право на чтение файлов не выше своего уровня, а право на изменение файлов – не ниже своего уровня.

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

Управление доступом на основе атрибутов (ABAC)
Данная модель основана на применении атрибутов, таких как свойства систем и ресурсов, пользователей и их окружения (например, время, геолокация, MAC-адреса, идентификаторы объектов и субъектов, тип операции и т.д.) для тонкой настройки политики доступа. Такие политики применяются при запросе пользователя, тогда происходит проверка атрибутов и принимается решение о предоставлении доступа.

#ИБ

Реверс-инжиниринг (обратная разработка или обратное проектирование) – это процесс анализа устройства или ПО в целях определения принципов его работы. Данный процесс может применяться в различных сферах, мы рассмотрим его в контексте ИТ и ИБ.
 
В разработке реверс-инжиниринг используется для восстановления исходного кода ПО, его структуры и функциональности. Этот метод позволяет понять, как работает программа, и выявить возможные уязвимости или ошибки.
 
Чаще всего реверс-инжиниринг применяется для:
 
· обнаружения и исправления багов в ПО;
· анализа вредоносного ПО для создания средств защиты;
· исследования ПО конкурентов и улучшения собственных продуктов;
· восстановления утраченного исходного кода.
 
Процесс реверс-инжиниринга состоит из следующих этапов:
 
1. Подготовка и выбор инструментов для анализа.
2. Дизассемблирование - преобразование двоичного файла в ассемблерный код.
3. Декомпиляция - преобразование двоичного файла в код на языке высокого уровня, например, «Java» или «C».
4. Отладка – изучение взаимодействия программы с системой для выявления скрытых алгоритмов.
5. Статический и динамический анализ – для выявления скрытых функций.
6. Документирование – комментирование кода и создание детального отчета.
7. Модификация – создание патчей для изменения функциональности программы.
 
Интересные случаи использования реверс-инжиниринга:
 
· Программа Wine использует реверс-инжиниринг для запуска Windows-приложений на Linux.
· Исследователи безопасности изучали код вируса Stuxnet, чтобы понять его механизм работы и разработать защитные меры.
· Исследователи безопасности изучали код вредоносного ПО Black Cat, чтобы понять его механизм работы и разработать защитные меры.
 
#ИБ
#ПолезноЗнать

Вопрос:

Зачем проходить аудит системы внутренних контролей ИБ c выпуском отчета SOC 2 / SOC 3?

Ответ:

Для того чтобы клиенты могли ознакомиться с особенностями контрольной среды обслуживающей организации в области ИБ и убедиться в ее эффективности.

Аудиты System and Organization Controls позволяют обслуживающим организациям, предоставляющим услуги клиентам, получить независимое заключение об эффективности системы внутренних контролей ­в виде отчетов SOC 2 или SOC 3. Отчет SOC 2 может быть двух типов:
· Type I – выпускается на определенную дату, покрывает эффективность дизайна и внедрения контрольных процедур.
· Type II – выпускается за период времени, покрывает эффективность дизайна и внедрения, а также операционную эффективность контрольных процедур.

Отчет SOC 3, о котором мы писали ранее, представляет собой сокращенную версию отчета SOC 2 type II.

Для подготовки указанных SOC-отчетов используются критерии надежности сервисов (TSC), разработанные Американским институтом дипломированных бухгалтеров (AICPA) на основе принципов COSO. Процедуры аудита выполняются в соответствии со стандартами аудита – МСЗОУ / ISAE 3000 либо SSAE-18.

В зависимости от области аудита отчет включает в себя независимую оценку по результатам аудита системы внутренних контролей ИБ в отношении одного или нескольких доменов:
· безопасность – обязательный домен;
· доступность;
· конфиденциальность;
· целостность обработки данных;
· защита персональных данных.

SOC-отчеты содержат заключение аудитора в отношении утверждений руководства компании об эффективности внутренних контролей ИБ с учетом критериев TSC, а также в отношении достижения определенных руководством компании целей обеспечения безопасности сервисов.

Помимо рассмотренных отчетов SOC 2 и SOC 3 существуют также отчеты SOC 1, однако они направлены на контроли в области финансовой отчетности, выполняются по другим критериям и на основе отдельного аудиторского стандарта – МСЗОУ / ISAE 3402 или того же SSAE-18.

#ИБ
#KeptОтвечает