Показаны сообщения с ярлыком Web. Показать все сообщения
Показаны сообщения с ярлыком Web. Показать все сообщения

1.11.17

DNS как улика

Выступал на Russian Internet Week с рассказом про угрозы со стороны DNS и использование DNS как инструмента для проведения расследований инцидентов, защиты бренда, поиска сайтов-клонов и т.п. задач. Выкладываю презентацию:



Скачать ее можно с Dropbox. Кроме того, сегодня вышла и одноименная статья, которая по сути является текстовой версией (пусть и немного урезанной и менее иллюстрированной) этой презентации. Я ее писал для "ИТ Менеджера".

ЗЫ. Самое интересное, что описанные в презентации методы хакеров (тот же Fast Flux или DGA) могут использоваться пользователями для обхода блокировок анонимайзеров и VPN, закон о которых вступил в силу сегодня. Раньше ИТ-подходы находили свое отражение по ту сторону баррикад, а сейчас, похоже, будет обратный процесс.

4.8.16

Когда безопасность только мешает бизнесу, нанося ему реальный финансовый ущерб

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

Я не буду приводить скучные и набившие оскомину примеры про блокирование выхода в Интернет или торможение персонального компьютера антивирусом (хотя они тоже измеримы). Поговорим о системе защиты финансовых транзакций по платежным картам 3D Secure, используемой как Visa, так и Master Card. Считается, что эта технология призвана защитить от мошеннических операций и это верно. Но значит ли это, что применять ее надо всегда и везде? Например, приложение "Парковки Москвы" от Электронной Москвы не использует 3D Secure. И Аэрофлот при покупке билетов тоже. А еще AppStore, Amazon, Одноклассники и куча других ресурсов. Значит ли это, что эти компании не беспокоятся о своей безопасности? Ни в коем случае. Просто бизнес важнее.

Посмотрите на статистику социальной сети Badoo. В России 3D Secure была включена принудительно с самого начала. После ее отключения число успешных платежей выросло на 20% (!). В Италии включение 3D Secure привело к падению объема платежей на 10-15%. В США включение 3D Secure привело к тому, что пользователи Badoo перестали платить вообще, а в Южной Африке число успешных платежей после отключения 3D Secure привело к положительной динамике.

Доля успешных платежей до и после включения 3D Secure в разных странах присутствия Badoo
Это очень хороший пример того, как технология безопасности, которая призвана помогать бизнесу, может ему мешать. Разумеется, данные Badoo не означают, что 3D Secure плоха и не нужна. Совсем нет. Просто надо четко осознавать место и область применения 3D Secure. Необходимо проводить соответствующие исследования, чтобы иметь на руках цифры, помогающие принять нужное решение. Например, на конференции Payment Security, на круглом столе, посвященном дилемме "Удобство или безопасность" представитель Сбербанка привел интересные цифры. Оказывается, число опротестований платежей в "Парковки Москвы" составляет всего несколько... десятков рублей (!) за 3 года работы сервиса. Несколько десяткой рублей! И зачем при таких цифрах внедрять 3D Secure?

В случае с Аэрофлотом ситуация схожая. Зачем там 3D Secure? Есть ли там мошенничества при продаже билетов? Ведь все равно билет будет выписан на конкретного человека с паспортными данными, позволяющими его идентифицировать. Да и этот покупатель физически придет на рейс и его можно задержать, если он мошенник. Видимо в Аэрофлоте посчитали объем мошенничества и конверсию (то есть отношение числа покупателей билетов с числом посетителей сайта Аэрофлота или с числом тех, кто билеты забронировал) и оказалось, что снижение конверсии от включения 3D Secure приводит к бОльшим потерям, чем мошенничество при отключенной 3D Secure.

Аналогичная ситуация с конверсией и для других сайтов с большим числом клиентов и покупок по картам - Amazon или AppStore. Снижение числа успешных платежей на 20% - это огромные деньги в масштабах этих компаний, которые они не готовы терять. Тем более, что существуют и другие способы защиты от мошенничества, без 3D Secure. Например, в платежной системе ASSIST работает своя антифрод система, которая снижает число мошеннических операций без снижения конверсии и без 3D Secure (по данным ASSIST процент успешных платежей при использовании 3D Secure ниже на 15-20%, чем без этой технологии). Badoo тоже разработала свою антифрод-систему, чтобы не ухудшать бизнес-показателей.

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


Аналогичная ситуация с временем загрузки страница - чем дольше грузится сайт из-за тех же проверок безопасности, тем ниже лояльность пользователя, выше их отток и ниже конверсия (если сайт что-то продает). В качестве примера возьмем сайт ФСБ. Я не знаю, как у других, но у меня главная страница грузится просто омерзительно долго и длительное время (десятки секунд) выглядит вот так:


С сайтом ФСБ, правда, ситуация с конверсией не работает, - он не зарабатывает денег и никакой альтернативы этому сайту нет. Поэтому приходится подолгу ждать отображения контента. На других же сайтах долгая загрузка приводит к потерям. Допустим сайт продает в день на 100 тысяч рублей. Всего одна секунда задержки загрузки страницы из-за проверки WAF или встроенными в сайт модулями проверки вводимых в поля форм значений приводит к годовым потерям в 2,5 миллиона рублей. 1 секунда = 2,5 миллиона рублей! А если это не 100 тысяч рублей, а столько же тысяч долларов? Потери составят уже 2,5 миллиона долларов! По статистике односекундная задержка в загрузке странице приводит к снижению конверсии на 7%, то есть к прямым потерям. И кто в такой ситуации будет положительно относиться к безопасности?

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

16.6.16

А ваш блог защищен?

А продолжу-ка я тему блогерства, подумал я, и продолжил. Навеял мне эту заметку репортаж о деле ростовского блогера, которую в начале года взломали неизвестные лица (и делали это трижды) и разместили в блоге информацию, порочащую неких московских адвокатов, которые и подали в суд на блогера (суд состоится 30 июня). От блогера, а также от владельцев нескольких иных ресурсов, также разместивших порочащие репутацию сведения, требуют 150 тысяч рублей. Аналогичный случай был и в 2014-м году, во время конфликта России и Украины, когда в аккаунте одного солдата в одной из социальных сетей была якобы размещена информация об артиллерийском обстреле Украины с территории России.

Но написать я бы хотел не о об этом деле, а о том, насколько защищен блог, который ведется или создается кем-либо? Ведь о чем обычно думает создатель блога? Какую площадку или CMS выбрать и какой шаблон использовать? Вот, пожалуй, и все. О безопасности блога не думает почти никто (даже среди безопасников) исходя из мысли, что если площадка чужая (тот же Blogspot), то она якобы уже защищена от различных кибер-посягательств. Однако то, о чем мы привыкли говорить с высоких трибун, советовать заказчикам или применять в своих компаниях, не так уж и часто применяется в собственной личной жизни. Кто-нибудь составлял модель угроз для своего блога?

Сходу я могу набросать несколько вариантов атак на личный блог:
  • перехват пароля владельца блога, например, через фальшивую точку доступа или троянца на домашнем компьютере,
  • подбор пароля владельца блога,
  • устаревшая и уязвимая версия CMS или платформы для блога,
  • уязвимости в темах оформления,
  • уязвимости в плагинах.

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

А чего делать, чтобы обезопасить свой блог от взлома? Советы будут просты и банальны, но действенны:
  • выбирайте надежные пароли
  • регулярно меняйте пароли
  • проверьте свой компьютер на вредоносный код
  • не используйте незащищенные соединения при работе в Интернет
  • выбирайте надежного хостера и, очень желательно, выделенный IP для своего блога
  • выбирайте последнюю версию CMS или блогерской платформы и следите за ее регулярным обновлением
  • избегайте неизвестных или непопулярных плагинов и тем оформления - ориентируйтесь на официальные библиотеки и отзывы/рейтинги пользователей
  • уточните у хостера (если площадка не своя), фиксирует ли он адреса и время, с которых осуществляется доступ к сайту и предоставляет ли он такую информацию пользователям (а если у вас иностранный хостер, то на каком языке он ее предоставляет)
  • делайте резервные копии блога и проверяйте возможность их восстановления
  • почитайте про механизмы защиты своей CMS/блогерской платформы и попробуйте их реализовать на практике (в зависимости от площадки/CMS они будут разные). Например, можно запретить изменения конфигурационного файла, а также ограничить число попыток аутентификации на сайте для пользователей.
  • проверяйте статус безопасности своего сайта через Google Safe Browsing Site Status,  Senderbase или Sucuri
Google Safe Browsing Site Status
Sucuri Website Malware and Security Scanner
  • используйте специальные плагины для защиты своего блога, которые позволяют, как минимум, отслеживать любые изменения на сайте и сообщать вам о них.
Вот как-то так... В свое время именно этот вопрос отвернул меня от создания собственного сайта в сторону блога на площадке Google. Не готов я был ежедневно отслеживать свой сайт, мониторить его безопасность, реагировать на инциденты и выполнять другие важные задачи. 

24.9.15

Всегда ли надо бороться с инцидентом ИБ?

Так удачно сложилось, что сегодня у меня на курсе по промышленной ИБ как раз идет тема по реагированию на инциденты, где инструктор рассказывает в чем отличие между этим процессом в обычной ИБ и в промышленной. Ну и по ходу приводит различные кейсы и примеры из жизни. Если коротко, то его идея заключается в следующем - в отличие от "обычного" корпоративного ИТ-мира, в промышленных системах надо в первую очередь оценивать воздействие инцидента на технологический процесс. Есть он? Значит с инцидентом надо бороться до конца. Нет его? Ну и фиг с этим инцидентом. Разумеется, это не значит, что про инцидент надо забыть, просто ему не надо уделять столько внимания, просто контролируя ситуацию и отслеживая статус - не начнет ли инцидент в какой-то момент влиять на технологический процесс. 

Вот, например, возьмем какую-нибудь газовую компанию "имярек". Известно, что на ее объектах "сидит" Stuxnet. Но он ничего не делает, на процессы не влияет, информацию о них не собирает, ни с кем не взаимодействует. Надо ли срочно останавливать процесс добычи и транспортировки газа или можно повременить, вычистив системы от Stuxnet в процессе планового обновления системы или иных регламентных работ? Если воздействия нет, то и спешить не надо. Останов системы обойдется гораздо дороже.

И вот сегодня же произошло другое событие; даже можно сказать инцидент. Взломали сайт конференции "Код информационной безопасности", которая сегодня проходит в Челябинске. Разместили на сайте вот такую картинку и надпись:



Возникает вопрос - надо ли срочно что-то делать организаторам?  В данном случае, как минимум, надо понять, а к чему это приведет? Отменится мероприятие? Врядли? Участники откажутся от прихода? Ну так мероприятие уже идет. Участники не придут на следующие мероприятия (а их еще 6 должно быть)? Тоже врядли - они выбирают исходя из качества докладов, а не качества сайта. Спонсоры отвернутся? Тоже маловероятно. Скорее даже наоборот. Взлом сайта - это пусть и не самый лучший, но PR. Кто помнит, пару лет назад уже была схожая ситуация. Сайт Уральского форума по банковской ИБ был взломан. Так вот после этого был всплеск посещаемости и самого сайта и смежных ресурсов организаторов. Полезно? Безусловно.

А что там с репутацией? Ведь она может пострадать. Отчасти да. Но взлом организатора обычных мероприятий и взлом ИБ-компании - это две большие разницы. Для второй такой инцидент несет гораздо больше негативных последствий, чем для первой. Для того, кто создавал и поддерживал сайт такая "слава" тоже не нужна. А вот организаторам рисков почти никаких. Хотя само событие, безусловно, неприятно.

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

Но... Из этого события можно сделать замечательный ход, например, рассказав на следующем мероприятии, в Самаре, рассказ о том, как ломали, как расследовали, как восстанавливали и какие уроки извлекли. Такие презентации на "живых" примерах просто отлично воспринимаются аудиторией. И не самое приятное событие оборачиваются кучей плюсов.

ЗЫ. И вообще, как отмечают коллеги, сайт любой ИБ-компании должен быть хотя бы один раз взломан :-) Это полезный опыт, который позволяет перейти от общих и красивых слов о важности ИБ к реальному опыту, которым потом и поделиться не стыдно (если не стыдно).


24.9.13

Как расейский сайт государев защитить от супостатов заморских?!

На прошедшей DLP Russia я в очередной раз говорил о законодательстве в области информационной безопасности, а точнее о тенденциях его развития. Тогда я высказал мысль, что раньше безопасники жаловались, что у нас очень неадекватные и неактуальные документы и жить по ним нельзя. А сейчас ситуация ровно обратная - документов с требованиями выходит столько, что впору уже прекращать работу этого принтера и начинать разбираться с уже выпущенными нормативными документами. Масла в огонь подливается огромным количеством регуляторов, которые так и норовят выпустить в свет очередное свое творение и застолбить себе имя в истории. И дело не столько в ФСТЭК, ФСБ или ЦБ (с ними нормально удается сосуществовать), сколько в других регуляторах, которые вдруг выплеснут ни с того, ни с сего обязательный нормативный документ, которые залезает на чужую поляну и мало что не учитывает уже разработанных требований, так еще и конфликтует с другими.

Вот возьмем к примеру наше Правительство, которое через ФМС России, разработало Концепцию введения удостоверения личности гражданина Российской Федерации в виде пластиковой карты в качестве основного документа, удостоверяющего личность. Ну почему нельзя было в разделе по информационной безопасности этой концепции просто написать, что требования по ИБ должны соответствовать правовым актам ФСТЭК в области защиты персональных данных? Нет, надо изголяться и надергивать требования из разных документов. Зачем? Чтобы в очередной раз убедились, что на этом пластике будет работать сертифицированная в ФСБ криптография? Или что разработчики из ФМС и Правительства мало знакомы с российским законодательством, если позволяют себе использовать термин "отраслевой стандарт"? Вот зачем?

А еще случай хотите? Возьмем к примеру такую простую сущность, как сайт государственного органа, размещенный в государственном сегменте сети Интернет. И представим, что надо его защитить от супостатов заморских, так и норовящих открытые данные с этого сайта украсть, а админов его в полон забрать. Какие требования могут распространяться на такой сайт?

На первый взгляд все просто - есть приказ ФСТЭК №17 (почти как Балтика №9), который, распространяясь на все государевы информационные системы, должен и покрывать сайт как бык корову. Ан нет, и другие желающие найдутся. Во-первых, Минкомсвязь с его 149-м приказом от 27.06.2013. Новехонький такой приказ. Называется "Об утверждении Требований к технологическим, программным и лингвистическим средствам, необходимым для размещения информации государственными органами и органами местного самоуправления в сети "Интернет" в форме открытых данных, а также для обеспечения ее использования". И там есть, как ни странно, раздел по защите информации. Странно потому, что у Минкомсвязи свое понимание защиты информации. Оно неплохое и нехорошее, оно свое. И оно плохо сочетается с требованиями ФСТЭК и ФСБ.

А еще у Минкомсвязи есть приказ №104 от 25.08.2009. Называется он - "Об утверждении Требований по обеспечению целостности, устойчивости функционирования и безопасности информационных систем общего пользования" и разработан он в целях реализации пункта 2 постановления Правительства Российской Федерации от 18 мая 2009 года N 424 "Об особенностях подключения федеральных государственных систем к информационно-телекоммуникационным сетям". Парадокс, но во исполнении этого же Постановления (только пункта 3, посвященного защите информации) нашими традиционными регуляторами ФСТЭК и ФСБ на двоих разработан в 2010-м году совместный приказ от 31.08.2010 №416/489. Спрашивается и в чем разница между информационной безопасностью во 2-м пункте и защитой информацией в 3-м?..

А есть еще приказ Минэкономразвития (ну эти-то куда суются) №470 от 16.11.2009 "О Требованиях к технологическим, программным и лингвистическим средствам обеспечения пользования официальными сайтами федеральных органов исполнительной власти". И там... фанфары... тоже есть раздел про защиту информации. Вы думали это все? Нет, это еще не все..

Напоследок добавлю полено (или поленом) от ФСО, которая 07.08.2009 выпустила приказ №487 "Об утверждении Положения о сегменте информационно-телекоммуникационной сети "Интернет" для федеральных органов государственной власти и органов государственной власти субъектов Российской Федерации". Если сайт размещается в этом сегменте, то будьте добры соответствовать еще и требованиям Федеральной службы охраны.

Стоп-стоп-стоп... Не все это, судари и сударыни. У нас же еще есть Верховный Главнокомандующий, который в 2008-м году разродился указом 351-м от 17-го марта "О мерах по обеспечению информационной безопасности российской федерации при использовании информационно-телекоммуникационных сетей международного информационного обмена". В нем тоже немало про возможность передачи государственной информационной собственности по сети Интернет и особенно за пределы Российской Федерации, а точнее про запрет такой передачи (это в Интернет-то).

Ну теперь-то все? Похоже, что да. С требованиями по защите все, исключая, быть может, ФСБшные требования по защите персональных данных. Но они пока не вышли. Подытожим. У нас есть 7 нормативных актов, устанавливающих разные требования по защите информации к сайтам государственных органов, размещаемых в сети Интернет. Авторами этих нормативных актов являются 5 органов государственной власти (ФСТЭК, ФСБ, Минкомсвязь, Минэкономразвития и ФСО) и один Президент. Немного ли для одного простенького сайта?

Может все-таки вернуться к идее единого госоргана по вопросам информационной безопасности? Не такая уж и глупая идея...

15.1.13

Что включить в политику работы в социальных сетях с точки зрения ИБ?

Многие пользуются социальными сетями (читая эту заметку, вы уже ими пользуетесь). Кто-то в формате "read-only", кто-то активно участвуя в дискуссиях; кто-то трепется с бывшими одноклассниками в "Одноклассниках", а кто-то активно обменивается опытом с коллегами в Facebook; кто-то является членом публичных "ВКонтакте", а кто-то наборот предпочитает закрытые междусобойчики. Все эти ситуации объединяет одно - использование нового канала коммуникации, который несет с собой не только преимущества, но и риски. Причем риски не только типичные для любого Web-сайта и описанные мной ранее, но и риски утечки информации, нарушение этических норм, нарушения прав на интеллектуальную собственность и т.п.

Раз у нас есть риски, то должна быть и политика управления ими. Причем речь идет не о самой простой из них, которая заключается в полном запрете социальных сетей (хотя нашим чиновникам хотят такое запретить на высочайшем уровне - слишком уж много глупостей они пишут). И даже не о той, которая хорошо иллюстрируется приведенной картинкой (спасибо Alex Toparenko) и известной поговоркой "молчание - золото". Речь идет о полноценной политике использования социальных сетей в контексте информационной безопасности.


В целом данная политика должно состоять из 3-х блоков "об общего к частному":
  • Общее отношение компании к социальным медиа. Что используется, а что нет; для чего; какие полномочия даны пользователям; будет ли проводиться модерация контента и т.д.?
  • Что могут и что не могут сотрудники делать в онлайн-пространстве. При этом данный раздел должен включать в себя не только требования, но и лучшие практики и советы, как вести себя в той или иной ситуации, а также в зависимости от роли - пользователь, как частное лицо, или пользователь, как сотрудник компании. Общим должно быть правило "думай, прежде чем что-то опубликовать в социальной сети". Стоит лишний раз напомнить пользователям, что все, что опубликовано в Интернет, уже врядли может быть оттуда удалено. Поэтому надо взвешивать последствия любого своего действия в социальных сетях; и взвешивать ДО, а не ПОСЛЕ.
  • Что могут и что не могут публиковать сотрудники на социальных ресурсах, в которых им разрешено участвовать от имени компании. Очевидно, что врядли работодатель будет рад, если его сотрудники на ресурсах, ассоциированных с компанией, будут поливать грязью действующую власть или выкладывать контент, нарушающий чью-то интеллектуальную собственность (да и от своего собственного имени это не очень-то приветствуется).
С точки зрения числа документов - это может быть одна политика, две, три и даже четыре. Количество не так важно - фокус смещается на содержание, а не форму. Описывая правила поведения в социальных сетях стоит акцентироваться не только на том, что нельзя, но и на том, что можно, чтобы для каждого из требований/положений можно было провести четкую грань разрешенного и запрещенного поведения.

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

Поэтому службе ИБ не стоит брать на себя всю тяжесть ответственности за данное направление, но свое слово она должна сказать и внести свою лепту в формируемый документ (а также отслеживать его изменени и предлагать их по необходимости). Какие разделы данной политики могут принадлежать перу безопасников:
  • Использование определенных платформ Social Media. Например, работникам может быть разрешен доступ к Facebook, LinkedIn и Twitter, но запрещен к "Одноклассникам" и "ВКонтакте". Это может быть как глобальное правило "для всех", так и гибкая политика доступа для разных групп пользователей, затем реализуемая на межсесетевом экране. При этом можно ограничивать доступ не только к сайту целиком, а к отдельным его разделам или микро-приложениям, которые в нем используются, или применять иные гибкие настройки разграничения доступа. Такие прикладные межсетевые экраны (application firewall или next generation firewall) сейчас есть у некоторых производителей (мы вот тоже имеем такой продукт - Cisco ASA CX).
  • Помимо ограничения на конкретные платформы или разделы социальной сети политика может ограничивать доступ и к материалам на определенную тему - от банальных порнография, реклама суицида и наркотиков, до посещения социальных сетей для поиска работы (исключая сотрудников HR) или страниц конкурентов на социальных сетях (исключая сотрудников отделов экономической безопасности или маркетинга).
  • Ответственность пользователей за нарушения правил общей политики информационной безопасности. Не мешает лишний раз напомнить, что нет никакой разницы как осуществлена кража и передача конфиденциальной информации - по e-mail, USB или через "Мой Круг" или Google+. Сюда же будет включаться и перечень наказаний за нарушения, например, отлучение от Интернет или иные формы дисциплинарного воздействия, согласуемые с Трудовым Кодексом.
  • Пароли и учетные записи. Хорошей практикой является включение в политику требования, чтобы пароли к учетным записям социальных сетей (исключая быть может корпоративные, если реализована единая система Identity Management) не совпадали с паролями, используемыми в корпоративной сети.
  • Время и цель доступа в социальные сети. Это вообще-то не функция ИБ, но уж слишком часто навешивают на безопасников контроль действий сотрудников в Интернет, контроль посещаемых сайтов, скачиваемых файлов и т.д. Если и у вас это так, то тогда стоит зафиксировать соответствующие правила. Например, "использование социальных сетей в личных целях в рабочее время запрещено" или "использование социальных сетей в личных целях в рабочее время разрешено в течение 30 минут ежедневно с 9.30 до 10.00 утра и с 17.30 до 18.00 вечера". На межсетевом экране это правило также легко зафиксировать, если межсетевой экран оперирует не IP-адресам в своих правилах, а именами пользователей.
  • Контроль контента. Поскольку социальная сеть подразумевает общение по принципу "один ко многим" или "многие к одному", то в отличие от переписки, где главенствует принцип "один к одному", контроль любого контента, размещаемого в социальных сетях от имени компании и с ресурсов, принадлежащих компании, никаких конституционных прав не нарушает. Поэтому в политике должно найти отражение правило, что любой контент может быть проверен сотрудниками с соответствующими привилегиями; обычно это ИБ, юристы и HR. Сюда же могут попасть правила, связанные с регистрацией действий и архивацией контента, связанными с сотрудником, сидящим в социальных сетях. Правда, прописывая условие регистрации и архивации будьте готовы реализовать его на практике, что не просто, т.к. требует немалых вычислительных ресурсов под данную задачу. Что же касается функции DLP для Web-контента, то это также возможно сегодня в некоторых продуктах.
  • Вредоносный код и фишинг. В приведенной по ссылке выше презентации описаны различные риски, связанные с открытием ссылок или запуском файлов от посторонних людей. Понятно, что этого делать не надо, но лишний раз напомнить (желательно с примерами скриншотов) не помешает. Это для безопасников очевидно, а для рядовых пользователей ничего не стоит кликнуть на флеш-ролик с "котэ", который в скрытом режиме устанавливает трояна или крадет пароли доступа.
  • Интеллектуальная собственность. Запрет на нарушение прав на чужую интеллектуальную собственность очевиден, но... его просто записать, но сложно контролировать на практике. По крайней мере по отношению к мультимедиа-контенту. Поэтому в некоторых случаях проще запретить выкладывание таких файлов или ввести их премодерацию.
  • Персональные данные. Также нелишним будет еще раз напомнить про правила работы с персональными данными клиентов, партнеров и иных лиц, которые оставили свои ПДн в социальных сетях, контролируемых компанией. Это если говорить о сотрудниках. Если же у вас есть собственная социальная сеть, то не забудьте опубликовать в ней политику работы с ПДн, выполнив тем самым требование ФЗ-152. Правда, не всегда понятно, как это сделать на чужих социальных ресурсах, на которых у вас всего лишь "страничка".
  • Информационные войны. Это нередкость в Интернет-пространстве. Ждать от сотрудников, что они будут уметь воевать, не стоит. Но лишний раз напомнить им, чтобы они не ввязывались в такие войны (троллинг, флейм и т.п.) стоит. Также можно включить рекомендацию сообщать обо всех случаях публикации негатива о компании. Главное, четко определить границы между негативом и шуткой (хотя это непросто). Этот тот случай, когда простого требования недостаточно, - необходимо чуть больше описания, рассмотрение примеров и т.д.
  • Спам. У нас на корпоративном блоге российского офиса Cisco нередко появляется спам в комментариях к заметкам. Бороться с ним можно разными методами, которые также должны найти отражение в политике работы с социальными сетями. Это и CAPTCHA, и запрет на публикацию комментов анонимами (так сделано у меня на этом блоге), и использование специализированных движков для контроля спама (так сделано, например, у Алексея Волкова) и т.п., включая и ручной просмотр, если комментариев немного.
Очевидно, что данная политика должна быть не только написана, но и доведена до сведения всех сотрудников (тренинг,  в т.ч. и онлайн, будет нелишним), а ее положения должны найти отражение в конкретных технических и организационных мерах, реализация которых ляжет на ответственные подразделения, включая и службу ИБ.

ЗЫ. Кстати, 1.5 года назад я уже давал ссылку на интересный документ по тому, что включать в политику работы с социальными сетями. Документ по-прежнему актуален.

16.4.12

Проверьте свои сайты. Быстро!

По плану сегодня я хотел опубликовать другую заметку. Но так получилось, что планы мои поменялись. В пятницу вечером я активно гуглил в поисках нужной мне информации. Сначала я искал просто ссылки, потом сконцентрировался на поиске конкретных презентаций, ну а потом затянуло ;-) Я стал играться с Google, вспомнив, как прошлой осенью в Интернете разгорелся скандал по поводу выкладывания многими госорганами у себя на сайтах конфиденциальной информации, служебной тайны, а в ряде случаев (по словам коллег) и гостайны. И вот я решил повторить тот же путь, задав соответствующий поисковый запрос, где в качестве ключевых слов были использованы "для служебного пользования", "конфиденциально", "секретно" и т.д. Нашлось немало всякой разной информации, содержащей эти грифы. Выложенные в открытый доступ паспорта антитеррористической защищенности многих объектов, места дислоцирования воинских частей и многое другое. Да и список критически важных объектов составить путем правильных запросов несложно (хотя сам сводный список является секретным). Но этим пусть занимаются тем, кому положено заниматься. Я же стал искать другие проявления халатности; уже в коммерческом секторе.

Нашлось тоже немало. Политики информационной безопасности, подробные описания систем защиты, схемы сетей с указанием всей адресации, отчеты, коммерческие предложения, списки цен, результаты тестирования продуктов (не всегда положительные), анализы рынка, проекты документов, файлы паролей, конфиги (с открытыми паролями)... Прошелся и по тематике персональных данных. Причем двояко. Сначала просто поискал различные ПДн на сайтах - нашел выше крыши. Причем явно такие ПДн находятся на сайте незаконно - видимо кто-то выложил файл на сайт, а служба ИТ/ИБ то ли не проставила прав доступа на разделы сайта, то ли забыла установить запрет на индексацию... Но итог очевиден - персональных данных полно. Также как и полно документов, регламентирующих вопросы обработки и защиты ПДн. И это не политика в области обработки ПДн, которая должна быть разработана по ст.18.1 ФЗ-152. Речь идет именно о внутренних нормативных актах, которые не должны светиться наружу. Причем доходит до смешного. Общался с некоторыми коллегами на конференциях. Спрашиваю - "разработали вы нормативку по ПДн?". Отвечают утвердительно. "Можете показать?". "Нет. Конфиденциальная информация". Ввожу их сайты в Google - получаю полный набор документов, которые они скрывали ;-)

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

Какова причина сего безобразия? Я вижу их несколько. Самая банальная - отсутствие взаимодействия между ИТ и ИБ службами организации. Первые делают и запускают сайт, не ставя в известность вторых. Итог печален. Вторая причина - низкая квалификация сотрудников служб ИБ, которые сами не всегда знают как защищать сайты. То есть общие-то принципы им известны, а вот конкретные шаги применительно к конкретной системе управления сайтом или Web-серверу им незнакомы. И вновь итог печален. И третья причина - отсутствие регулярного мониторинга защищенности и конфигурации своих сайтов. Может быть при создании сайт и был защищен, но он рос, развивался, менялся. В итоге первичные настройки уже забыты, а про новые никто и не вспомнил. Результат опять предсказуем.

Что могу посоветовать сделать прямо сейчас. Введите в Google следующий поисковый запрос: "filetype:doc site:"адрес своего сайта"" (в Google вводить все без кавычек). Этот запрос выдаст все файлы формата DOC, которые доступны извне. Можете сузить запрос и перед filetype ввести ключевое слово или фразу. Тогда будут найдены все файлы Word, содержащие искомый запрос. Кстати, учитываете, что расширения DOC и DOCX в Google - это разные результаты в поисковой выдаче. Можно попробовать и такой запрос "filetype:dat passwd" (не забудьте использовать оператор site с указанием своего домена). Он может выдать вам очень интересный результат. А вообще с помощью Google у себя на сайте можно много чего поискать - пароли, реестры, ключи, сертификаты и т.д. Главное, правильно составить запрос, используя стандартные функции Google.

Ну а что делать, если вы у себя нашли какие-нибудь дыры, открытые всем, я думаю, вы знаете.

3.11.11

Безопасность Web-приложений по версии ISACA

ISACA выпустила новый документ по безопасности Web-приложений "Web Application Security: Business and Risk Considerations". Как и многие другие документы ISACA этот на достаточно высоком уровне описывает риски и уязвимости Web-приложений, а также включает рекомендации по выстраиванию процесса защиты (включая этап создания кода) Web-приложений:
  • поддержка руководства
  • тренинги
  • политики и стандарты
  • технические меры
  • непрерывная программа сканирования кода
  • особенности работы с унаследованным кодом
  • управление проектом
  • управление инцидентами.
В целом документ достоен изучения; особенно тем, кто занимается разработкой собственных или заказных Web-приложений.

ЗЫ. К слову сказать, многие из этих рекомендаций (может быть не так систематизированных и привязанных к COBIT) я встречал у нас в Cisco, в политике разработки Web-приложений.

1.9.11

Интересные документы по безопасности Web и Social Media

За последнее время наткнулся на несколько интересных документов по ИБ. Информацию о них я кидал в Twitter, но не факт, что все видели эти ссылки.

Первый документ, а точнее его проект, подготовлен OWASP (The Open Web Application Security Project). Документ называется "Application Security Guide For CISOs" и это название говорит само за себя. Собственно сам документ сейчас как раз и создается ;-) Содержание документа ориентировано именно на руководителей ИБ и почти не содержит техники - один бизнес:
  • выделение бюджета на защиту приложений
  • измерение защиты приложений - потери, бизнес-воздействие, оптимизация затрат, ROI
  • ценность информации
  • выбор проблем, которые требуют внимания и выделения бюджета в первую очередь
  • метрики.
Первые три пункта уже описаны; остальные в процессе.

Второй документ "SOCIAL MEDIA RISKS AND MITIGATION" описывает риски и стратегию управления ими для социальных медиа (социальные сети, блоги, твиттер и т.д.). Документ очень подробный и описывает social media с трех сторон - использование для общения с заказчиками, использование сотрудниками в личных целях и использование сотрудниками за пределами компании. И хотя документ ориентирован на финансовые организации, он будет полезен и всем остальным.

Мне понравился раздел по compliance, который описывает применение social media с точки зрения различных нормативных актов (иностранных) - в контексте персданных, в контексте законодательства о труде, в контексте PCI DSS, в контексте законодательства о рекламе и т.п.

Второй раздел связан с описание рисков применения social media - распространение вредоносного ПО, кража идентификационных и персональных данных, социальный инжиниринг, утечка интеллектуальной собственности, снижение продуктивности и т.д. Третий раздел описывает применение social media в целях мониторинга репутации предприятия.

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

Резюмируя, могу сказать, что оба документа достойны для изучения. Они могут лечь в основу собственной стратегии использования social media в организации.

24.6.11

WhiteHat Security покупает Infrared Security

22 июня WhiteHat Security, известная на рынке Web-безопасности, анонсировала покупку технологии статического анализа кода у Infrared Security.

23.3.11

Безопасность социальных сетей

Сегодня у меня должно было быть выступление на Call Center Forum 2011 с докладом по безопасности социальных сетей. Выступить не удастся по причине участия в другом мероприятии, но презентацию выкладываю.

28.10.09

Cisco покупает ScanSafe

Компания Cisco объявила о покупке SaaS-провайдера в области безопасности Web - компанию ScanSafe. Цена сделки - 183 миллиона долларов. Решения ScanSafe дополнят систему IronPort Web Security Appliance, предлагаемую Cisco своим заказчикам. Защита Web-трафика на уровне периметра и в качестве SaaS позволит выстроить эшелонированную оборону от Web-угроз. Также планируется внедрение технологий ScanSafe в VPN-клиент нового поколения Cisco AnyConnect VPN Client.

27.7.09

Самопиар, security awareness или реальная помощь?

Долго думал, с чего начать эту заметку. Так и не придумал ;-( Решил дать рукам волю и пусть сами пишут то, о чем я сейчас думаю. Итак, наткнулся я на сайт nosecure.info. Очень интересный ресурс, ибо заметки на нем показывают неплохую квалификацию авторов. Но вот этическая сторона вопроса... Зачем писать о том, какие дыры есть на сайте Инфосистемы Джет, Вымпелком, RISSPA, Лаборатории Касперского, sec.ru, СекЛаб и т.п.? Как это влияет на повышение осведомленности или реальную защищенность? Сложно сказать. Самопиар? Но на сайте постоянно твердят, что помогают они бескорыстно и готовы консультировать любого вопрошающего бесплатно. В-общем, я так и не пришел к единому мнению, какие чувства вызывает у меня этот сайт...

ЗЫ. С другой стороны, почитав заметки на сайте, я обратил внимание, что часто грешу тему же - критикую всех без разбора ;-( Надо что-то с этим делать. Больше позитива добавить что-ли и советов с помощью?.. Надо осмыслить...

ЗЗЫ. Два часа спустя... Осмыслил. Если уж все позволяют себе ругать вендоров, то почему нельзя ругать потребителей... также с указанием их имен?

ЗЗЗЫ. И еще один постскриптум (наверное последний). После таких вот новостей о том, что на том-то сайте, специализирующемся на ИБ или на другом, найдены дыры, запускать свой сайт как-то не хочется. Сколько раз уже брался за это, но все время останавливает именно этот момент - не хочется, чтобы мой сайт был взломан. А самостоятельно обеспечивать защиту динамического сайта на каком-либо популярном движке я не готов - техническая квалификация уже не та ;-(

11.6.09

Сайт по безопасности взломан

В Москве недавно проходило мероприятие PCI Moscow. Оно входило в серию семинаров, посвященных стандарту PCI DSS, организованных некоей западной компанией AKJ Associates Ltd. Организованные в Киеве, Каире, Таллине, Амстердаме, Мадриде, Йоханесбурге и других городах мира мероприятия, должны были показать всю важность стандарта PCI DSS для защиты информации о владельцах платежных карт. К слову сказать материалы московской конференции выложены на сайте организаторов.

Парадокс в том, что это сайт взламывают уже второй раз за прошедший месяц. Первый раз их сломали перед самим мероприятием - во второй декаде мая. И вот опять та же ситуация. В списке презентаций с конференции напротив материалов ISACA стоит необычное имя закачавшего их пользователя - HaCKeD Xx_DoGaN_xX & ßy 78uS. Это имя ведет на отдельную страницу, которая лишний раз подтверждает факт взлома.

22.5.08

20 полезных сайтов по безопасности

Журнал NetworkWorld выбрал 20 лучших сайтов по информационной безопасности. В их числе:
  • Персональный сайт Брюса Шнайера - новости, аналитика, статьи, размышления одного из ведущих мировых экспертов по ИБ
  • Cisco Security Center - единая точка контакта по всем вопросам безопасности Cisco - бюллетени, сигнатуры, новости, эпидемии, аналитика и т.п.
  • Privacy Rights Clearinghouse - сайт, описывающий все утечки информации в США
  • OWASP - про безопасность Web-приложений
  • Microsoft - как мониторить действия пользователей в Интернет
  • Secunia - обширный список уязвимостей в разном ПО
  • Commtouch - сайт, посвященный эпидемиям вредоносного ПО
  • SecureMac - сайт, рассказывающий, как защищать Apple Mac
  • IT Security - сайт-советчик, посвященный тому, как выбирать и внедрять системы защиты. На этом же сайте опубликован список из 103 свободно распространяемых средств защиты для Linux, Windows и Mac
  • LiquidMatrix Security Digest - сайт Дейва Льюиса, аккумулирующий новости по ИБ
  • IronPort Senderbase - статистика в реальном времени о спаме и почтовых эпидемиях
  • CyberCrime.org - отчеты о штатовских преступлениях в сфере ИТ
  • IT Compliance Institute - новости, исследования и аналитика по IT Compliance
  • Microsoft Technet Security Center - бюллетени, статьи и практические рекомендации
  • по защите платформы Windows
  • Computer Security Resource Center - сайт американского института стандартов NIST, посвященный вопросам ИБ (кладезь информации)
  • SANS - еще одна кладезь информации от института SANS
  • CERT - про реагирование на инциденты + информация по уязвимостям
  • SecurityFocus - новости, статьи, аналитика по ИБ
  • Бунт роботов - нам неактуально, но читать прикольно

Приятно осознавать, что работаешь в компании, которой принадлежат два сайта, входящих в этот список (Cisco Security Center и Senderbase.org).

ЗЫ. Список американизированный, что закономерно, учитывая происхождение Network World.

17.9.07

Куды бечь, когда узнал о проблемах с безопасностью?

Опубликовал на SecurityLab очередную статью про рекомендации Vulnerability Disclosure Working Group в части создания на каждом сайте раздела /security, который является демонстрацией компанией или организацией своего стремления защитить своих клиентов и свои активы от различных посягательств.

Адрес статьи- http://www.securitylab.ru/contest/302888.php