Новая услуга "ДиалогНауки": оценка соответствия требованиям Федерального закона "О персональных данных"

Новая услуга "ДиалогНауки": оценка соответствия требованиям Федерального закона "О персональных данных"

В настоящее время проблема защиты персональных данных является одной из наиболее актуальных для российских компаний. Это обусловлено тем, что 26 января 2007 года вступил в силу Федеральный закон «О персональных данных», в котором сформулированы требования по защите персональных данных. Необходимо отметить, что требования данного закона являются обязательными как для коммерческих, так и государственных организаций. При этом, согласно статье 25, информационные системы должны быть приведены в соответствие с требованиями настоящего Федерального закона не позднее 1 января 2010 года.

В первой половине 2008 года ФСТЭК (Федеральной службой по техническому и экспортному контролю) были разработаны технические требования по защите персональных данных. Данные требования ФСТЭК являются основой для реализации проектов по построению систем обеспечения безопасности персональных данных, соответствующих требованиям Федерального закона. Такая система представляет собой комплекс организационных, программно-технических и организационно-методических мер по защите персональных данных.

Компания «ДиалогНаука» оказывает консалтинговые услуги по проведению оценки соответствия (аудита безопасности) требованиям Федерального закона «О персональных данных». Процесс оценки состоит из следующих основных этапов, каждый из которых предусматривает выполнение определённого перечня задач:
- разработка регламента (технического задания) на выполнение работ;
- определение информационных систем, обрабатывающих персональные данные;
- классификация информационных систем;
- анализ бизнес-процессов компании с точки зрения соответствия положениям Федерального закона «О персональных данных»;
- разработка частной модели угроз безопасности персональных данных;
- анализ имеющихся в распоряжении мер и средств защиты;
- оценка соответствия техническим требованиям ФСТЭК по защите персональных данных;
- разработка рекомендаций по устранению выявленных замечаний.

В завершении процедуры аудита его результаты оформляются в виде отчётного документа, который предоставляется Заказчику. В общем случае этот документ состоит из следующих основных разделов:
описание границ, в рамках которых был проведён аудит безопасности;
описание структуры автоматизированной системы Заказчика;
методы и средства, которые использовались в процессе проведения аудита;
описание выявленных несоответствий требованиям по защите персональных данных;
рекомендации по устранению выявленных несоответствий требованиям Федерального закона «О персональных данных»;
предложения по плану реализации первоочередных мер, направленных на устранение выявленных недостатков.

В случае появления вопросов или интереса к описанной услуге, пожалуйста, свяжитесь с нами по телефону +7 (495) 980-67-76 или со страницы «Контакты», адресовав вопрос в «Коммерческий отдел». 

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

Если атакующий успеет первым положить в кеш ответ 404, пользователи вместо главной страницы будут получать ошибку до очистки записи. Получается CPDoS — отказ в обслуживании с доставкой прямо из кеша.

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

Защита выглядит до смешного просто: не склеивать значения вслепую. Между элементами ключа нужны разделители или структурное кодирование, например:

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

RSS: Новости на портале Anti-Malware.ru