Что такое чувствительная информация

Чувствительная информация: основные понятия и термины

© 2007–2021 «ФИНАМ»
Дизайн — «Липка и Друзья», 2015

При полном или частичном использовании материалов ссылка на Finam.ru обязательна. Подробнее об использовании информации и котировок. Редакция не несет ответственности за достоверность информации, опубликованной в рекламных объявлениях. 18+

АО «Инвестиционная компания «ФИНАМ». Лицензия на осуществление брокерской деятельности №177-02739-100000 от 09.11.2000 выдана ФКЦБ России без ограничения срока действия. Адрес: 127006 г. Москва, пер. Настасьинский, д.7, стр.2.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

ООО «Управляющая компания «Финам Менеджмент». Лицензия на осуществление деятельности по управлению ценными бумагами №077-11748-001000 выдана ФСФР России без ограничения срока действия.

АО «Банк ФИНАМ». Лицензия на осуществление банковских операций со средствами в рублях и иностранной валюте № 2799 от 29 сентября 2015 года.

ООО «ФИНАМ ФОРЕКС», лицензия профессионального участника рынка ценных бумаг на осуществление деятельности форекс-дилера № 045-13961-020000 от 14 декабря 2015 года. Адрес: 127006, Российская Федерация, г. Москва, пер. Настасьинский, д. 7, стр. 2.

Источник

Информационная безопасность

Практика информационной безопасности

Страницы

пятница, 12 июня 2009 г.

ISSP \ Домен 01. Информационная безопасность и управление рисками. Часть 10

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

Результаты классификации информации позволят компании определить, какие средства и меры защиты должны применяться для каждого класса, решить какие задачи защиты информации являются наиболее приоритетными. Первичная цель классификации информации – показать необходимый для каждого типа информации уровень защиты конфиденциальности, целостности и доступности. Кроме того, классификация позволяет обеспечить защиту информации наиболее эффективным (экономически) способом. Защита и содержание информации стоит денег, желательно расходовать эти деньги именно на ту информацию, для которой это действительно необходимо.

Коммерческие организации часто используют следующие уровни критичности: конфиденциально (confidential), для внутреннего использования (private), критичная информация (sensitive), открытая информация (public). А военные организации используют другие уровни критичности: совершенно секретно (top secret), секретно (secret), конфиденциально (confidential), критичная неклассифицированная информация (sensitive but unclassified), неклассифицированная информация (unclassified).

ПРИМЕЧАНИЕ. Также, не следует забывать про резервные копии классифицированных данных – к ним должны иметь доступ только те, кто имеет соответствующий уровень допуска. Большой риск для компании представляет технический персонал, который, не обладая никакими допусками, работает с классифицированными данными при выполнении своих обязанностей. Компания должна удостовериться, что каждый, кто имеет доступ к данным и их резервным копиям, ясно понимает уровень их важности, знает свои обязанности по отношению к ним.

ПРЕДУПРЕЖДЕНИЕ. Правила классификации должны применяться к данным независимо от формы, в которой они представлены: электронная информация, бумага, видео, аудио, факс и т.д.

При разработке набора уровней классификации информации, учитывайте следующее:

Источник

АНАЛИТИКА

Международные новости утечек информации, ежегодные аналитические отчеты и статистика по инцидентам за прошедшие годы.

Чувствительная информация: когда утечка становится шоком

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

Аналитический центр компании InfoWatch подготовил дайджест утечек чувствительных персональных данных.

Во Флориде медицинский центр AltMed был вынужден на время отключить свой веб-сайт после того, как один из клиентов заметил, что при поиске выдается конфиденциальная информация. Дело в том, что AltMed занимается распределением препаратов на основе марихуаны, и утечка рецептурных назначений в этой категории особенно чувствительна.

Минувшим летом скандальная история произошла по вине сотрудницы одного из британских госпиталей. Работая помощником администратора клиники, 23-летняя Эми Докер (Amy Docker) получила доступ к личной информации Кэндис Колльер (Candice Collier), бывшей девушки своего бойфренда. Узнав телефон и домашний адрес соперницы, Докер засыпала ее оскорбительными сообщениями. Руководство госпиталя инициировало в отношении ревнивой особы служебную проверку по поводу ненадлежащего доступа к защищенной информации. В результате девушка была уволена.

Популярный в Лондоне сервис Urban Massage скомпрометировал всю базу своих клиентов. Хранилище информации на облачном сервере забыли защитить паролем, в результате чего сотни тысяч записей оказались в свободном доступе по меньшей мере на несколько недель. Помимо имен, адресов, электронной почты и телефонов клиентов, утекла информация о мошеннических действиях заказчиков услуг, а также сообщения о сексуальных домогательствах в отношении массажисток, причем каждая жалоба включала подробные данные о клиентах.

Приложение Grindr для знакомства представителей сексуальных меньшинств передавало своим аналитическим партнерам данные о местоположении пользователей, включая закрытую информацию о подписчиках с подтвержденным диагнозом ВИЧ. Данные могли использоваться для таргетированных рекламных кампаний. В связи с бурной реакцией, которую вызвала отправка конфиденциальной информации, руководство приложения приняло решения отказаться от сотрудничества с аналитиками.

В Израиле секретаря женской клиники Sheva Enaim и двух представительниц религиозной организации Hidabroot обвинили в нарушении неприкосновенности частной жизни. Скандал разразился после того, как сотрудница клиники передала имена женщин, которые собираются сделать аборт. Hydebroot по религиозным соображениям выступает против прерывания беременности. Работники организации успели связаться с большим количеством женщин, уговаривая их сохранить детей и предлагая финансовую и моральную поддержку.

Источник

Байки из склепа. Рассказываем, как не стоит обращаться с чувствительными данными

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

Немного теории

Начнем конечно с определения того, какие данные считать конфиденциальными. OWASP причисляет к ним пароли, номера кредитных карт, медицинские записи, личную информацию и бизнес-секреты. Помимо этого, за списком чувствительных данных следует обращаться к законам и отраслевым постановлениям тех регионов, откуда к вам могут прийти пользователи. Если речь о России, нужно заглянуть в Федеральный закон РФ № 152-ФЗ «О персональных данных», а в случае европейских пользователей, например, в Общий регламент ЕС по защите данных (GDPR) или в закон Великобритании о защите данных (DPA), которые регулируют использование персональных данных.

В любом случае, идем, изучаем требования и понимаем, какие данные пользователей мы обязаны содержать в целости и сохранности. Кстати, помимо этого есть еще и бизнес-требования. Закон может не требовать от вас применять строгие меры в отношении конфиденциальных данных, которые приложение создает или хранит для своих пользователей, но нарушение сохранности этих данных все равно нанесет вред вашим пользователям и, соответственно, вашей репутации.

В качестве конфиденциальных данных, хранящихся в приложениях, можно рассматривать следующее:

Время удивительных историй

Давайте обсудим некоторые из наиболее распространенных уязвимостей, которые в нетривиальном виде наши специалисты встретили на практике. Суть уязвимостей не меняется, это все тот же список OWASP, но рассказ о таких случаях поможет взглянуть на безопасность приложений под другим углом.

Ищем старые версии

Различных чек-листов по безопасности веб-приложений в сети вагон и маленькая тележка. Но, как показывает практика, за всем уследить нереально. Особенно когда речь заходит об использовании старых версий компонентов в большом проекте. Так, однажды на сервисе, использующем подменные номера телефонов, было найдено старое семейство API, где номер еще не скрывался. Подменные номера — хорошая услуга, позволяющая скрыть реальный номер продавца с доски объявления. Однако, если внимательно изучить отправляемые запросы, найти документацию (или самим угадать нужные методы), то можно было сформировать запросы к старому API и получить через него подлинные номера пользователей.

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

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

Смотрим шире на процессы

Проблемы больших проектов на этом не заканчиваются. Часто можно встретить бреши в безопасности из-за банальной несогласованности процессов. Проиллюстрируем примером: на одном из сервисов в чате с техподдержкой пользователи могли отправить вместе с жалобой номер карты, привязанной к сервису. По требованиям службы безопасности этот номер требовалось скрывать от сотрудников техподдержки. При более детальном изучении выяснилось, что номера карт в чате и правда маскируются, но при этом в ответе от сервера был ряд скрытых полей, которые в чат не подставлялись, но в трафике были видны. Если какие-то данные должны быть скрыты, оповестите об этом и фронтенд, и бекенд.

Лишнего не болтаем

Аналогичная проблема несогласованности процессов была найдена в функциональности сброса забытого пароля. После ввода логина (в данном случае — адреса электронной почты) сайт уточнял, куда отправить пароль: на почту или на привязанный номер телефона. Если был выбран второй вариант, то на странице появлялось оповещение с наполовину скрытым номером телефона. А вот в HTTP-ответе от сервера номер отображался целиком. Так можно было собрать целый список из пар “почта-номер телефона”. Раскрытие-с.

Кстати, к разговору о функционале сброса пароля. Если при реализации функционала регистрации только единицы забывают использовать общее предложение “неправильный логин или пароль”, то при восстановлении пароля информацию о наличии того или иного логина в системе раскрывают гораздо чаще. Конкретные ответы от сервера, подтверждающие наличие записи в системе, позволяют составить список пользователей и порой успешно использовать его в дальнейших атаках (фишинг, password spraying и т.д.). Но не только явные сообщения раскрывают информацию, вывод можно сделать по таймингу (например, таким страдали старые версии OWA — веб-клиента для доступа к Microsoft Exchange) или телу ответа.

Не храним лишнее

Существует хорошая практика — хранить только то, что действительно необходимо. Так, на неком сайте каждый раз, когда система отправляла email пользователю (например, при регистрации, анонсе мероприятий и т.п.), все сообщения записывались в лог. Этот лог на сайте был доступен, внутри хранились непосредственно текст сообщений, фамилия и имя пользователей, а также их почта. Интересно, что многие утилиты для поиска директорий данный файл не находили. Так как его размер был огромен (несколько ГБ), утилиты просто не могли дождаться, пока он скачается, и пропускали его. Но, перепробовав несколько вариантов утилит, аудиторы в конце концов добились своего.

В данной истории, помимо того, что в лог записывались избыточные данные, так еще и доступ к ним никак не был ограничен. Это, как ни парадоксально, далеко не редкий случай. Здесь стоит снова вспомнить ряд громких случаев (например, раз, два, три), когда утекали довольно серьезные объемы данных с Elasticsearch серверов.

Ну, не будем о грустном. Просто не забывайте правильно использовать авторизацию там, где она необходима.

Дружим с логикой

И все же самой распространенной болячкой, позволяющей утекать пользовательским данным, являются небезопасные прямые ссылки на объекты (Insecure Direct Object Reference, IDOR). В подтверждение расскажем две неклассические истории.

Обычно IDOR подразумевает чтение информации по идентификатору, минуя авторизацию или проверку прав. Но есть случаи, когда заполучить чужие данные возможно, отправив запрос на создание записи с уже существующим в системе идентификатором. Часть старых данных по этому идентификатору перезапишется, но остальные данные теперь будут доступны новому пользователю (и станут недоступны предыдущему — сменится хозяин).

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

В другом случае IDOR был найден при просмотре транзакций. В HTTP-запросе передавались три параметра:

, где 2315486 – идентификатор пользователя,
2315488 – идентификатор карты,
40117812222030001111 – номер счета.

На первый взгляд, перебрать 3 значения (34 цифры) не представляется возможным за обозримое время. Но, как выяснилось впоследствии, номер счета (40117812222030001111) в запросе можно было опустить: запрос все равно оставался валидным, как и ответ. Соответственно, оставалось только два числа для подбора — идентификатор пользователя и идентификатор карты.

Далее оказалось, что первое значение (идентификатор пользователя) может быть любым, например 1111111, но обязательно такого же размера, как идентификатор карты (7-значное число). Соответственно, параметр GT из 34-значного числа превратился в 7-значное, а перебрать его не составляет труда (в системе также отсутствовало ограничение на количество запросов от пользователей). В итоге, чтобы получить информацию о транзакциях, достаточно было знать только идентификатор карты (или перебрать его значение).

Уязвимости IDOR в целом не редкое явление, но чаще всего они встречаются в веб-приложениях со сложной структурой. Как и другие логические уязвимости, их довольно сложно выявить с помощью сканеров кода.

Еще раз всё проверим

Завершим наш рассказ случаем в онлайн-магазине, где использовались веб-сокеты. При оформлении заказа в системе для него генерировался ID, и пользователь подписывался по этому ID на все обновления касательно заказа. Но, как выяснилось позже, существовала возможность отправить подобный запрос “на подписку” не с конкретным ID, а с символом подстановки “*” на его месте. В результате можно было заполучить информацию обо всех заказах пользователей (с ФИО, адресами, телефонами и прочей сопутствующей информацией).

Заключение

Мы уверены, что подобных, а порой и куда более зубодробительных историй в практике специалистов ИБ предостаточно, но не всегда получается ими поделиться с сообществом. Обычно такое можно услышать в приватной беседе за кружечкой чая. И все же, делиться подобными случаями (обезличенно, конечно) — крайне полезная практика как для сообщества, так и для разработчиков. Поиск уязвимостей — это своего рода искусство мыслить иначе. Давайте вдохновлять друг друга.

Источник

• ← Что такое числитель и знаменатель в расписании вуза
• какая автономная канализация лучше топас или евролос →