четверг, 29 декабря 2011 г.

Взломы профилей в социальных сетях


Бизнес все больше расширяет свое присутствие в социальных сетях.
При этом, если выгоду от использования социальных сетей бизнес начинает понимать довольно быстро, то область рисков, связанных с социальными сетями пока является Terra incognito. Как подтверждение этого, взломы страниц компаний в социальных сетях продолжают набирать обороты.
Так, недавно хакерами была взломана страница представительства производителя каш Nordic.  Я уже писал о взломе страницы проекта "Психология денег" Геннадия Балашова.  Даже страница создателя Facebook Марка Цукерберга была взломана, что подтверждает русскую пословицу о "сапожнике без сапог".
Для того, чтобы уберечь свою личную страницу от взлома пользователям нужно следовать хотя бы элементарным правилам безопасности.
Компании, являющиеся операторами социальных сетей также стали больше уделять внимания вопросам безопасности и проводить "инструктаж" пользователей. К примеру, такая практика наблюдается у Facebook. Некоторые же социальные сети явно отстают в этом плане, что отмечается сообществом информационной безопасности.
Общий совет таков: перед тем как использовать какую-либо новинку, лучше провести хотя-бы базовую оценку рисков.

пятница, 9 декабря 2011 г.

Результаты глобального исследования Ernst & Young по информационной безопасности за 2011 год


29 ноября 2011 года в Киеве прошел четвертый ежегодный Security Innovation Forum 2011. Я выступил на этом форуме с результатами глобального исследования Ernst & Young по информационной безопасности за 2011 год. Материалы выступления:


суббота, 19 ноября 2011 г.

Методология проведения Penetration testing

У начинающих специалистов по информационной безопасности возникает вопрос: политикой информационной безопасности компании требуется проведение тестов на проникновение или, другими словами Penetration testing, но как подходить к этой процедуре? Какие действия выполнять внутренними силами информационной безопасности или что обсуждать при заказе выполнения процедур от внешних организаций?
Привожу ссылки на наиболее распространенные руководства по этому вопросу. К сожалению, все руководства не русскоязычные.
  1. Technical guidance for Penetration Testing Execution Standard
  2. Open Web Application Security Project (OWASP) Testing Project
  3. A Penetration Testing Model
  4. NIST Special Publication 800-53 “Recommended Security Controls for Federal Information Systems and Organizations”
  5. Open-Source Security Testing Methodology Manual
  6. NSA IAM (National Security Agency Information Security Assessment Methodology)
  7. Cybersecurity Vulnerability Assessment Methodologies (Cybersecurity VAMs, Primatech Inc.)
  8. Information Systems Security Assessment Framework, OISSG (Open Information Systems Security Group)

среда, 2 ноября 2011 г.

Защита персональных данных в Украине. Требования закона.

В связи с введением соответствующего закона в Украине у руководства многих компаний возникает два вопрос «Что грозит за невыполнение требований этого закона?» и «Как обеспечить выполнение закона?».
Попытаюсь дать краткую информацию по этому вопросу.
В Украине действует закон № 2273 «О защите персональных данных», который вступил в силу с 1.01.2011. Этот закон регулирует взаимоотношения между субъектами, связанные с защитой персональных данных во время обработки. Основные требования, которые выдвигаются законом № 2273 к обработке персональных данных следующие:

  • Цель обработки персональных данных должна быть сформулирована во внутренней нормативной документации «владельца базы персональных данных»
  • Нужно обеспечить достоверность и правильность персональных данных, а также их обновление
  • Состав персональных данных должен отвечать цели обработки и быть ограничен подписанным соглашением физического лица
  • Первоисточником персональных данных являются выданные документы на имя физического лица либо подписанные данные, которые физическое лицо предоставляет о себе
  • Обработка персональных данных выполняется согласно целям, которые согласованы с физическим лицом
  • Обработка персональных данных без согласия физического лица запрещена кроме отдельных исключений
  • Персональные данные в форме, которая допускает идентификацию физического лица могут обрабатываться в течение срока, необходимого для достижения законной цели обработки данных
  • Обработка персональных данных в научных или статистических целях может выполнятся только в неперсонализированном виде
  • Типовой порядок обработки персональных данных в базах определяется уполномоченным государственным органом по вопросам защиты персональных данных

С 21.06.2011 вступило в силу положение Кабинета Министров Украины № 616 «Про Государственный реестр баз персональных данных и порядок его ведения». В этом документе излагаются требования по регистрации баз обработки персональной информации. По каждой из баз обработки персональной информации необходимо предоставить в Государственную службу по вопросам защиты персональных данных как минимум следующую информацию:

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

Дополнительно можно предоставить еще следующую информацию:

  • Форму предоставления согласия на обработку персональных данных субъектами персональных данных
  • Способ ведения баз (электронный, бумажный и т.д.)
  • Источники получения персональных данных
  • Информацию о распространении и передаче персональных данных (третьим сторонам)
  • Информацию о передачи персональных данных за границу
  • Категории субъектов, относительно которых осуществляется обработка персональных данных
  • Категории персональных данных, которые обрабатываются
  • Типы информации, содержащиеся в базе (классификация)
  • Описание принятых мер по защите персональных данных от незаконной обработки и незаконного доступа

Невыполнение требований законодательства в области защиты персональных данных грозит штрафом в размере от 100 до 1000 необлагаемых минимумов. Если невыполнение закона приведет к незаконному доступу к персональным данным, сумма штрафа может составлять 10000 необлагаемых минимумов.

среда, 26 октября 2011 г.

Драйверы замены технического парка

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

  1. Функциональность старого оборудования не удовлетворяет пользователей и бизнес-владельцев;
  2. Производительность старого оборудования не удовлетворяет пользователей и бизнес-владельцев;
  3. Условия технической поддержки и гарантийного ремонта оборудования не удовлетворяют бизнес-владельцев;
  4. Оборудование часто выходит из строя. Как следствие, существуют потери в виде рабочего времени сотрудников, упущенных клиентов, трудозатрат сотрудников ИТ на поиск и установку замены, затраты на приобретение замены;

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

вторник, 18 октября 2011 г.

Риски социальных сетей

Прочитал статью А.Г. Капустиной "Минные поля социальных сетей" опубликованную в журнале "Inside" №4 2011 года. Статья посвящена вопросам безопасности использования социальных сетей.
В ней рассматривает основной риск, связанный с использованием социальных сетей - потенциальными нарушениями авторских прав при распространении контента. При этом в качестве иллюстрации разбирается судовой иск ВГТРК против ООО "В Контакте" по нарушению авторских прав при размещении пользователем фильма "Охота на пиранью".
У меня возник вопрос: неужели это основные риски, связанные с использованием социальных сетей?
Я думаю, что значительная доля рисков лежит в области взаимодействия людей, раскрытия персональной информации, раскрытия конфиденциальной информации работодателей и т.д.. Эти риски более существенны и их можно оценить (хоть и приблизительно). Так, например, два года назад в Англии оценили ущерб экономике страны от использования социальных сетей..
Часто неразумное использование социальных сетей может стоить человеку рабочего места.
Основной момент социальных сетей в том, что такие сети делают человека более открытым и, если он ведет нечестную игру, ему более сложно контролировать что и кому он говорил, а что и кому не говорил. И тут "тайное очень часто становится явным", к тому же в самый неподходящий момент. Так что новые технологии тут не причем. Весь вопрос в человеческих взаимоотношениях. А это старо как мир.

пятница, 14 октября 2011 г.

О безопасности в социальных сетях

Позавчера слушал на радио Бизнес.fm передачу Геннадия Балашова "Стресс-шоу психология денег". В нем Геннадий рассказывал о силе Facebook как движущем средстве продажи, маркетинга, развития бизнеса.
Он выдвигал тезис, что в Украине имея наличные средства и страницу в Facebook можно сделать многое и развить собственный бизнес очень быстро. Facebook позволяет не только проинформировать аудиторию о своем продукте, но и включить аудиторию в обсуждение своего продукта. Как подтверждение этого Геннадий ссылался на страницу самой передачи в этой социальной сети.
А не следующий день произошло интересное. Я залез на эту страницу и вижу, что она не обновляется, вопросы, которые задаются на странице в передаче не озвучиваются, статус не обновляется. Секрет этого раскрылся несколькими минутами позже. Геннадий в эфире сказал, что страницу у них "увели" злобные хакеры, но он надеется что в скором времени они смогут ее вернуть и дальше вести ее как средство общения.
Отсюда вывод: переход бизнеса на электронные средства продвижения товаров и ведения бизнеса вообще повышает зависимость компаний от уровня зрелости информационной безопасности. Если построить “стартап” бизнес на основе Facebook таким образом, как это предлагал Геннадий и не уделять внимания информационной безопасности, то такой бизнес может в один прекрасный момент стать достоянием другого индивидуума, при этом не нужно даже взламывать помещение и похищать устав.

среда, 12 октября 2011 г.

Анализ безопасности сети. Формирование рабочей программы.

Очень часто в компаниях возникает задача оценки информационной безопасности по отношению к корпоративной сети. Это может быть частью аудита информационной безопасности, частью оценки проекта модернизации сети, частью аудита на соответствие стандартам безопасности. При этом желательно иметь некий рабочий план, по которому можно проводит аудит. Как подходить к проблеме создания такого плана?
Аудит корпоративной сети немного отличается от аудита информационных систем. Для аудита информационных систем на уровне операционной системы, СУБД или приложения можно воспользоваться рекомендациями и руководствами. Эти рекомендации и руководства предоставляются разработчиком соответствующего программного обеспечения или организаций, занимающихся созданием, разработкой, стандартизацией и распространением знаний в области аудита и контроля информационных систем (например, методологическими руководствами таких организаций, как www.isaca.org, www.isc2.org, www.owasp.org, и др.). Методологические руководства носят характер контрольного списка, по которому можно оценивать защищенность системы.
Корпоративная сеть является распределенной системой по самой своей сути, в этой системе нет единственной точки или устройства, защита которого позволила бы защитить корпоративную сеть целиком.
К тому же, целью атак на корпоративную сеть (за исключением атак типа отказ в обслуживании) являются чаще всего корпоративные сервера, пользователи, хранилища данных и т.д. Сама сеть рассматривается как промежуточное звено. Это усложняет определение того, какая часть корпоративной сети попадает в объем аудита, а какая нет. С корпоративными серверами проще. К примеру, мы определили систему SAP как критичную с точки зрения требований информационной безопасности, поскольку информация, которая обрабатывается в этой системе, является конфиденциальной. SAP состоит из двух серверов: сервера приложения и сервера баз данных. Оба сервера работают под управлением операционной системы AIX, на сервере баз данных используется СУБД Oracle. Соответственно эти сервера и попадают в объем процедур аудита.
Для аудита северов и инфраструктурного ПО мы можем получить программу аудита для соответствующих систем на сайте ISACA (доступно только для членов ассоциации) и использовать ее при аудите. Там же есть и программа для аудита сети. Эта программа, кроме вступительной части и части, охватывающей описание общего подхода, содержит два раздела: дизайн безопасной сети (Network Security Design) и компоненты безопасной сети (Network Security Components). Программа охватывает дискретную сущность (отдельные устройства) и интегрированную сущность (сеть в целом) корпоративной сети.
Но, к сожалению, в программе аудита сети, предложенной ISACA, выпущен важный момент – люди. А ведь именно люди и человеческий фактор иногда составляет одну из наибольших угроз. Например, в августе 2011 года неправильная конфигурация (как следствие недостатков процедуры управления конфигурациями) привели к значительному сбою в информационных системах Yandex.ru.
Повлиять на этот человеческий фактор можно, внедрив соответствующие процедуры и разделив обязанности. Например, рекомендуется внедрить управление изменениями в сети, процедуру управление конфигурациями, процедуру мониторинга доступности и производительности, процедуру управления инцидентами на уровне сети и т.д.

четверг, 6 октября 2011 г.

Подход к разработке показателей эффективности работы ИТ подразделения

Ключевые показатели эффективности работы ИТ подразделения компании являются важным элементом взаимодействия ИТ подразделения и бизнес-подразделений, для который ИТ подразделение предоставляет услуги.
Поскольку ИТ подразделение часто является центром затрат а не прибыли, то применять походы к оценке работы подразделений, которые применяются к центрам прибыли, к подразделению ИТ невозможно. Например, отдел продаж мы можем оценить по количеству заключенных контрактов, средней стоимости контракта и т.д., но для ИТ подразделения это применить невозможно. Однако, при этом необходимо оценивать работу всего подразделения в целом и руководителя ИТ подразделения в частности. Тут к нам на помощь приходят показатели эффективности работы, которые необходимо разработать учитывая следующие факторы:
1. Отрасль экономики, в которой работает компания.
2. Организационную структуру.
3. Культуру компании.
4. Уровень зрелости бизнес-процессов.
5. Численность персонала.
6. Сложность ИТ архитектуры.
Ключевые показатели эффективности работы являются методом оценки "полезности ИТ подразделения для бизнес-подразделений". Такая оценка должна выполнятся исходя из приоритетов, которые ставит перед собой бизнес-подразделение. Соответственно бизнес должен решить, что для него важнее и выбрать соответствующие показатели эффективности. ИТ подразделение является сервисным подразделением и, как и в любой сервисной организации, его работа может быть оптимизирована исходя из следующих направлений: стоимость, качество, время. Одновременно оптимизировать все три направления невозможно.
В каждом из направлений можно выбрать несколько ключевых показателей эффективности. Примеры таких показателей:
Стоимость

  • Общая стоимость поддержки ИТ систем на протяжении периода времени
  • Отношение общих затрат подразделения ИТ к стоимость существующего (приобретенного за период) оборудования
  • Стоимость (средняя, минимальная и максимальная) обработки заявок пользователей
  • Расходы по обучению на одного сотрудника ИТ
  • Процент текучести кадров ИТ подразделения за период времени

Качество

  • Количество повторно открытых заявок
  • Количество заявок при обработке которых были ошибки ИТ специалистов
  • Количество жалоб пользователей
  • Результаты анкетирования удовлетворенности пользователей ИТ и руководителей бизнес подразделений
  • Уровень подготовки пользователей в результате обучения, проведенного ИТ подразделением
  • Размер корпоративной базы знаний по эксплуатации ИТ систем
  • Количество запросов к корпоративную базу знаний по эксплуатации ИТ систем
  • Количество часов на обучение для одного сотрудника ИТ подразделения

Время

  • Время (среднее, минимальное и максимальное) обработки заявок пользователей
  • Количество заявок, выполненных не в срок
  • Общее время простоя рабочих мест на протяжении периода времени
  • Общее время простоя серверного оборудования на протяжении периода времени
  • Частота предоставления отчетов руководству

Как видно, большинство из показателей возможно оценивать по статистике работе службы поддержки пользователей. Соответственно внедрение такой службы является важным элементом оценки взаимодействия работы ИТ подразделения. Для обеспечения объективности, обработка заявок в такой службе не должна быть полностью под контролем ИТ подразделения.

среда, 5 октября 2011 г.

Причины внедрения ИТ контролей в организациях

Компании в процессе своего развития проходят через несколько стадий. Начинается развитие компании из стартапа или покупки франшизы. Если владелец бизнеса покупает его в виде франшизы, то вместе с разработанной бизнес-моделью ведения бизнеса, который покупается внедряются и необходимые внутренние контроли, включая и ИТ контроли.
Если же компания начиналась со старпата и развивается, то рано или поздно в процессе развития перед собственниками компании или перед наемными менеджерами возникает вопрос о внедрении ИТ контролей.
Для чего нужно внедрять ИТ контроли в компаниях? Вроде бы и без ИТ контролей хорошо.
Рассмотрим возможные причины внедрения ИТ контролей:
Причина1. Для соответствия требованиями.
В процессе развития компании она сталкивается с необходимостью привлечения дополнительных финансовых ресурсов для обеспечения роста, выхода на новые рынки, расширения бизнеса. Использовать только собственные ресурсы в этом случае означает упущенную возможность захвата открывшейся ниши на рынке. Если компания привлекает заемные средства в виде кредитов, выпущенных облигаций, эмиссии акций, то тут возникает ряд требований по аудиту финансовой отчетности и контролируемости бизнес-среды. Эти требования выдвигаются либо сторонами, предоставляющими заемные средства (например условия кредитования, предлагаемые банками) либо посредниками и операторами рынка (например, фондовыми биржами). Если компания работает в определенном секторе экономики (например, банковский или телекоммуникационный), то требования по контролям, в том числе и ИТ контролям могут выдвигаться регуляторами рынка (государства, ассоциации платежных систем).
Если компания не соответствует требованиям, то это ей может грозить штрафом или лишением лицензии.
Причина2. Для уменьшения ущерба от сбоев систем.
Сколько стоит для небольшой компании простой в течение 4 часов системы бухгалтерского учета или потеря данных за 1 месяц? А сколько стоит для телекоммуникационного оператора простой биллинговой системы и системы авторизации в течении 2 часов и потеря информации за 4 суток? Эти два события показывают, что ущерб от простоя системы и потери данных может сильно зависит от размера компании и специфики бизнеса. В процессе роста компании руководство понимает, что частые инциденты приводят к все большим ущербам и желательно от этих инцидентов избавиться. А инциденты происходят либо по причине технического характера (выход из строя компонент системы) либо по причине человеческого фактора (случайно выполнил не ту операцию, решил в системе исправить неправильную проводку, решил выполнить недозволенную операцию). Минимизацию частоты этих инцидентов и их последствий можно достичь внедряя систему внутренних контролей.
Причина3. Для повышения эффективности бизнеса.
Часто ли возникает в компании ситуация, при которой данные, которые несколько сотрудников старательно вводили в течение недели, были утеряны из-за сбоя системы и есть необходимость эти данные вводить повторно? Сколько времени необходимо потратить на повторную подготовку отчета или проектного документа, который был утерян за день до сдачи заказчику из-за сбоя в системе?
Часто инциденты с ИТ системами приводят к неэффективному использованию времени сотрудников компании. Если это время стоит дорого, то ущерб от таких сбоев очевиден. Если мы минимизируем последствии инцидентов, то мы в целом повысим эффективность ведения бизнеса.
Причина4. Для повышения прозрачности бизнеса и эффективного управления.
Задавался ли руководитель вопросом, кто из отдела продаж предоставил большую скидку клиенту и кто дал добро на это? Как быстро он сможет получить ответ на этот вопрос? Если компания небольшая и «все на виду», то руководитель знает, что происходит в компании и какие операции выполняются сотрудниками. Он также знает, выполнятся ли эти операции в интересах компании. А если компания насчитывает до 1000 сотрудников и офисы компании расположены в разных городах?
Решить эту задачу позволит внедрения ИТ контролей в систему учета и авторизации продаж.
Как видно есть несколько причин внедрения ИТ контролей. Представленный перечень причин является далеко не полным, однако он позволяет руководителям и собственникам компаний задуматься о такой вещи, как ИТ контроли.

четверг, 23 июня 2011 г.

Подходы к разработке политик и процедур в области ИТ и информационной безопасности

Политики и процедуры являются важным элементом построения системы управления информационной безопасностью компании.

Как разрабатывать эти документы, какие существуют подходы? Существуют два принципиально различающих подхода: формалистический и практический.

Первый подход, формалистический, заключается в том, что мы разрабатываем ряд документов, в них описываем то, что должно быть (исходя из требований международных стандартов, исходя из требований регуляторов и т.д.). В этих документах излагается то, что "хорошо чтобы так было". При этом мы можем показать, что компания соответствует ряду требований в части разработанных политик и процедур (например, требования PCI DSS, которые введены недавно или требования SOX 404, которые были введены несколько лет тому назад). Не факт, что требования документов выполняются и не факт, что информационные системы и процессы соответствуют стандартам, но на бумаге выглядит все очень хорошо. Такие документы могут содержать требования, которые не всегда соответствуют здравому смыслу или общепринятым практикам. Для разработки таких документов в компании могут использоваться различные источники. Есть целый ряд готовых заготовок и шаблонов для разработки таких документов (например, Information Security Policy Templates от SANS.org или ресурс networkdoc.ru). Мы меняем шапку, немного изменяем формулировки и вот уже документ готов. Я на практике видел, как в целом ряде коммерческих банков Украины были разработаны формалистические документы для соответствия стандарту PCI DSS. На практике требования документов не выполнялись, да их и нельзя было выполнить. Например, PCI DSS требует наличия в компании плана обеспечения непрерывности деятельности - и вот он в компании есть. Другое дело, что документ содержит всего 8 страниц, из них 5 страниц - это шапка, ссылки, список авторов и т.д.
Но какая же польза от таких формалистичных документов для компании? Главная цель таких документов - показать соответствие чему-то. Но, согласитесь, для компании это не главное. Главная цель политик и процедур - донести до сотрудников компании основные принципы, по которым необходимо работать в компании. Это как законы, которые позволяют индивидуумам гармонично сосуществовать в рамках общества. Политики и процедуры должны помогать компании достигать своих целей. Это могут быть цели, направленные на получение прибыли собственниками, цели выполнения важных проектов для общества. Безусловно, может быть цель соответствия требованиям. Тут как раз формалистические документы помогут, но это только одна из целей компании.
Формалистический подход в нормативной документации аналогичен некоторым требованиям ПДД, которые либо устарели, либо рассчитаны на другие категории дорог и транспортных средств, но формально установлены и дают возможность сотрудникам автоинспекции применять штрафы. Но польза таких требований для безопасности движения сомнительна.

Второй подход, практический, позволяет разработать политики и процедуры, которые являются отражением текущего состояния вещей, то есть установившуюся практику. Главная цель этих документов - не требование выполнения навязанных извне принципов, а изложение на бумаге договоренностей между сторонами (владельцами, руководством, сотрудниками различных подразделений), которые и так уже достигнуты в компании. Это своего рода меморандум (от лат. memorandum — то, о чём следует помнить). Такие документы напоминают о том, о чем стороны уже договорились. При таком подходе все участники процесса понимают важность вопроса. Они пришли к какому-то общему мнению, согласовали интересы различных сторон (например, подразделения ИТ и подразделения информационной безопасности), потому как цели сторон могут немного противоречить друг другу. Такой подход более эффективен. Документы, разработанные по этому подходу, будут встречать меньше сопротивления со стороны сотрудников, поскольку это то, к чему сотрудники и так уже пришли путем переговоров.

Один из примеров из другой области, который иллюстрирует эти два подхода - составление банковской гарантии. Во время проведения одного из тендеров необходимо было, чтобы участники, которые подают свои коммерческие предложения для участия в тендере, подкрепили "серьезность намерений" банковской гарантией. Если они не могут оказать услуги, описанные в коммерческом предложении, после выбора их победителем, то залоговая сумма через банковскую гарантию переходит от компании, которая объявляет тендер. В тендере участвовали два системных интегратора. Один из них работал на территории Украины, другой работал по всему миру. Украинский системный интегратор предоставил гарантию, выпущенную украинским банком. Это был солидный документ с множеством пунктов и условий, с мокрой печатью и подписью первых лиц банка. Другой интегратор предоставил гарантию, выпущенную ведущим международным банком. Это была факс-копия печатного документа на 8-10 пунктов уместившихся на одной странице формата А4 крупным печатным шрифтом. Мокрой печати и подписей на документе не было. Но, тем не менее, этот документ тоже был гарантией и не менее весомой. Поскольку компания дорожит своей бизнес репутацией (в данном случае банк), то этот документ это также меморандум, отражающий обязательства сторон. Вопрос юридической силы тут другой, поскольку одно дело - существующие законы, другое дело - их выполнение. Лично я доверял бы второй гарантии больше, поскольку репутация у второго банка намного лучше репутации первого банка. Законы в Украине, к сожалению, не всегда выполняются. И, имея на руках формальную юридическую гарантию от Украинского банка, мы на самом деле обладаем меньшей гарантией (прошу прощения за вынужденную тавтологию) того, что залоговая сумма будет передана при наступлении событий, указанных в условиях.

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

Компании в Украине могут выбирать, каким подходом им руководствоваться. "Выбирай, но осторожно, но выбирай" © Роман Карцев.

понедельник, 18 апреля 2011 г.

Пересылка цифровых ключей по почте

Недавно один из крупнейших банком мира HSBC объявил о том, что для обеспечния более безопасного доступа клиентов к своим счетам при помощи интернет-банкинга, он будет предоставлять инструмент многофакторной аутентификации. Это устройство, которое получило название HSBC Secure Key — «безопасный ключ» представляет собой цифровую карточку, которая генерирует одноразовый ключ аутентификации на основе пин-кода вводимого пользователем.
Эта технология не является новинкой и мотивы банка вполне понятны. Тем более, что недавно клиенты банка стали жертвой фишинговой атаки . Удивляет другое - банк начал рассылать это устроуство 23 марта по почте. Необычный способ передачи таких критичных устройств пользователям. Меня бы насторожило то, что устройства передаются не лично в отделениях банка, а через третьих лиц.

четверг, 14 апреля 2011 г.

Стандарты тестов на проникновение

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

понедельник, 11 апреля 2011 г.

Впечатления от мероприятия CSI Filter3

7 апреля прошла 4-часовая виртальная конференция Computer Secruity Insitute, которая называлась Filter3. В режиме онлайн видео мероприятие могли смотреть зарегистрированные участники.
Докладчиков было довольно много, были представители от крупных до маленьких организаций, работающих в сфере информационной безопасности.
Впечатления от мероприятия двойственные. С одной стороны затрагивались довольно глубокие и актуальные темы, с другой стороны формат презентаций уменьшил эффективность процесса восприятия.
Формат презентаций был довольно необычный. Никаких слайдов или наглядных материалов не было. Доклад воспринимался как интервью в неформальной обстановке. Докладчики в подавляющем большинстве сидели в креслах и рассуждали на тему как космические корабли бороздят просторы вселенной актуальных вопросов обеспечения безопасности в инженерных сетях, защите персональных данных, безопасности веб-приложений и т.д.
Отсутствие наглядных материалов и американский вариант английского языка лично мне, как визуалу, не позволил эффективно воспринимать информацию.
Интерактивность сессий была также не на высоте. Инструмент презентаций позволял задавать вопросы, но мои два заданных вопроса остались без ответа. Я даже не получил реакции, дошли ли мои вопросы до докладчика или нет.
Возможно эти сессии были не в прямом эфире, а в записи, но тогда возникает вопрос, зачем привязываться к определенному времени трансляции (которое, кстати, для европейских слушателей было не очень удобное)?
В целом могу порекомендовать это мероприятие как прослушивание новостей в фоновом режиме. На мой взгляд, при этом достигается наибольшая польза.

четверг, 7 апреля 2011 г.

С днем рождения, Интернет

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

среда, 6 апреля 2011 г.

О целостности данных в CRM системах

Целостность данных является одним из требований информационной безопасности. Различные организации по разному подходят к требованиям целостности данных и реализации механизмов обеспечения целостности. Одни считают, что целосность данных более критична, чем конфиденциальность; другие придерживаются противоположного мнения. Все критерии информационной безопасности, которые применяются к информации (целостность, доступность, конфиденциальность, наблюдаемость, эффективность, и т.д.) одновременно обеспечить очень сложно. Нужно определять приоритеты. На мой взгляд есть класс систем, где целостность наиболее важна - это CRM системы. Многие компании используют эти системы для маркетинговых целей, поддержки контакта с клиентами, привлечении и удержании клиентов. Информация, которая содержится в этих системах используется для общения с клиентом и целостность этой информации очень важна. Это “лицо компании”, ее имидж. Некачественная информация в CRM системах может препятствовать достижению целей этой ИТ системы, или даже давать обратный эффект.
Я подписан на бесплатный информационный журнал одного из вендоров. Получив текущий номер, я вместе с ним получил уведомление, что моя подписка на этот журнал истекла и этот (текущий) номер я не получу. Некрасиво получилось... Вместо того, чтобы проникнуться уважением к компании, которая персонально общается со мной, которой важны мои интересы у меня возникло ощущение, что я участвую в какой-то спам рассылке.
Похожая история. Недавно покупал в одном из интернет-магазинов бытовую технику. Позже они прислали мне письмо, где предлагали вступить в их группу в социальных сетях. В принципе разумное предложение. Все бы ничего, но в письме они назвали меня “Ольгой”. Хотя при регистрации я указывал свое имя правильно.
Вот так вот получается. А потом маркетологи сидят и ломают голову, почему бы это их эффективная CRM система не приносит плоды?

пятница, 1 апреля 2011 г.

Региональный broadcast используя атмосферные слои.

Региональный broadcast используя атмосферные слои.

Традиционно на первое апреля Internet Engineering Task Force выпустил шуточный стандарт RFC #6217. . Этот стандарт, как и другие шуточные ничем не отмечен в базе и находится наряду с обычными RFC документами. Так что, если у человека не обладает чувством юмора и не обратил внимания на дату, то вполне может приять документ за чистую монету. Документ содержит все необходимые атрибуты и разделы. Стиль изложения документа довольно строгий. Несерьезность документу придают лишь абсурдные идеи, например отражение на небосводе содержимого датаграммы. Хотя, возможно, кому-то эта идея и не кажется абсурдной. Например, компания Moon Publicity запатентовала схожую технологию отображения информации на луне . Так что, возможно, когда-то первоапрельские RFC и получат статус будут восприниматься как официальные.

четверг, 31 марта 2011 г.

Ущерб от инцидента с RSA. Видимая часть айсберга.

Ущерб от инцидента с RSA. Видимая часть айсберга.

После инцидента, произошедшего с подразделением RSA всемирно известной компании EMC об этом не писал на своих блогах только ленивый.

А к чему же привел этот инцидент? Какой ущерб для компании, собственников, клиентов он принес или может принести?

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

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

Анализ возможных последствий был приведен компанией NSSLabs

Попытаемся оценить хотя бы "видимую часть айсберга" в деньгах. Посмотрим, как же менялась рыночная стоимость компании после соответствующего инцидента. Об инциденте общественности стало известно 17 марта. Соответствующее обращение руководства компании было опубликовано на сайте EMC. На торгах нью-Йоркской фондовой биржи, которые последовали после новости, стоимость акций EMC упала на 1.25%. Учитывая капитализацию компании 55.55 млрд. долларов мы получаем убыток более 694 млн. долларов. Согласитесь, это не мало. Мы пока не учитываем возможные затраты связанные возможным "отзывом" брелков аутентификации, потерю рыночной позиции и т.д.

Думаю, этот инцидент будет хорошим уроком для многих компаний.