Только 15% малого бизнеса в России считают свою кибербезопасность высокой

Только 15% малого бизнеса в России считают свою кибербезопасность высокой

Только 15% малого бизнеса в России считают свою кибербезопасность высокой

Большинство российских компаний малого и среднего бизнеса до сих пор выстраивают информационную безопасность не системно и делают ставку на внимательность сотрудников, а не на технологии. К такому выводу пришли Битрикс24 и Русская Школа Управления (РШУ) после опроса более 1,5 тысячи работодателей по всей стране.

Проблемы, как выяснилось, начинаются ещё при найме. Только 45% компаний на собеседованиях проверяют, понимает ли кандидат ответственность за сохранность корпоративных данных, а подписывать соглашение о неразглашении (NDA) требуют лишь 59%.

С обучением ситуация не лучше — половина компаний вообще не проводит его, а регулярно делают это только 19%. Ещё треть работодателей признались, что обучают сотрудников от случая к случаю.

С технологической защитой дела обстоят не лучше: системы предотвращения утечек данных внедрены лишь у 38% компаний. Ещё 62% обходятся базовыми средствами — антивирусом и надеждой на благоразумие сотрудников. Автоматические обновления программ, которые закрывают уязвимости, включены только у 21% работодателей.

Контроль паролей тоже часто оставляют на усмотрение сотрудников — в 40% организаций люди сами решают, когда их менять. Треть компаний разрешает работать с корпоративными данными с личных устройств без ограничений, и только 22% полностью это запрещают.

С увольнением сотрудников тоже не всё гладко: лишь 38% компаний блокируют доступ в день ухода. Почти половина делает это в течение недели, а 17% — тянут месяц или больше. У 4% доступ бывших сотрудников вообще остаётся активным.

Неудивительно, что только 15% участников опроса считают уровень своей кибербезопасности высоким. Более половины (52%) признали, что работают несистемно, а треть (33%) прямо говорят о низком уровне защиты.

Главные причины такого положения дел — ограниченные бюджеты (46%), нехватка специалистов (22%), сопротивление сотрудников (17%) и отсутствие поддержки руководства (15%).

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

На днях мы публиковали большую подборку средств для управления безопасностью и защиты МСБ. В статье рассказываем, как сосредоточиться на базовых мерах защиты, направленных на основные векторы атак.

Новая атака на кеш 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