Ранее мы отвечали на вопрос о необходимости аудита ИБ и о его видах, в том числе, о сертификационном аудите по ISO/IEC 27001 и о аудите соответствия SOC 2 и 3. По результатам аудитов соответствия SOC 2 и 3 формируются заключения, которые можно обнаружить на сайтах крупных компаний, например, в рамках процесса их отбора в качестве контрагента.
Данные заключения содержат информацию о том, что компания выполняет взятые на себя обязательства по обеспечению контроля за защитой данных в ходе оказания услуг с учетом критериев 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (AICPA, Trust Services Criteria).

Указанные заключения представляют собой отчет SOC 3 по результатам аудита системы контроля сервисной организации.
По сути, отчет SOC 3 является краткой общедоступной сводкой отчета SOC 2 type II. Отчет SOC 3 подходит для тех компаний B2C, которые не желают раскрывать клиентам детали контролей и процедур тестирования.

Отчет SOC 3 — это не только независимое подтверждение эффективности системы контроля, но и способ оценки собственных подходов к безопасности, которые развиваются внутри компании, на соответствие ведущим мировым практикам.

#ИБ

Вступило в силу 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Отвечает