Архив метки: средства защиты информации

Темы битвы: почему не растут угрозы?

Эх, давно не писал. Сильно скучал я по этому делу. Как вы знаете, меня рекрутировали за корзину печенья и банку варенья участвовать в Кибербитве. Неожиданно, но я даже победил. Говорят, все любят андердогов и сравнивали меня с Исландией :)

before

На мероприятии было довольно интересно, но были и свои минусы:

  1. Крайне мало времени на вопрос, что является следствием большого количества вопросов, достаточно 3-4.
  2. Олег, не стоит менять тему за день до битвы. Уж не знаю, откуда там взялись роботы.
  3. Общее голосование вместо раундового.
  4. Крайне неудобно смотреть, нет чатика, не работает капча (!!) в форме вопросов.

Т.к. времени было немного, а позиция моя по многим вопросам была крайне неортодоксальной, я решил полнее раскрыть тему. И сегодня про угрозы.

Кстати, кто пропустил — полная версия:

Тема 1. Какой будет динамика роста внутренних угроз в ближайшее время?

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

По сути, роста внутренних угроз не происходит. Если взять классическую формулу риска, то в ней вообще нет угроз (и тем более уязвимостей), которыми мы так привыкли пугать директоров в СМИ и на конференциях. Классическая формула из ISO:

Величина риска = вероятность события * размер ущерба

где

Вероятность события = вероятность угрозы * величина уязвимости

сделав подстановку, получаем

Величина риска = вероятность угрозы *величина уязвимости* размер ущерба

Классическая схема рисков ИБ

Классическая схема рисков ИБ

Как видим, угрозы и уязвимости — это переменные второго порядка. Это такие переменные, которые могут быть неважны, если известна величина первого порядка. Например, вероятность попасть в авиакатастрофу составляет 0.00001% (вероятность события). И уже не важно, вследствие каких угроз или уязвимостей это произошло – теракты, ошибки и т.п. Все отрасли работают с вероятностью события, мы же зарываемся все глубже и глубже. Например, страховщики уже давно все посчитали и создали даже свой раздел математики (актуарная математика).

При этом под «вероятностью угрозы» здесь понимается likelihood (а не классическое probability), что тоже переводится как вероятность, но характеризуется частотой реализации угрозы за определенный период времени. Крайне не надежная величина.

Величина уязвимости – вероятность того, что угроза будет реализована с помощью данной конкретной уязвимости. Т.е. вполне может быть, что супер-пупер критичная уязвимость может никогда не реализоваться.

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

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

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

Между тем с биологической точки зрения все эти утверждения одинаково верны. Вот несколько разных «мы», узаконенных современной биологической наукой. Мы многоклеточные. Мы эукариоты. Мы жгутиковые. Мы животные. Мы вторичноротые. Мы хордовые. Мы позвоночные. Мы челюстноротые. Мы четвероногие. Мы амниоты. Мы синапсиды. Мы млекопитающие. Мы плацентарные. Мы приматы. Мы обезьяны (или, что то же самое, антропоиды). Мы узконосые обезьяны. Мы человекообразные обезьяны, или гоминоиды (по-английски apes). Мы большие человекообразные обезьяны (great apes). Мы большие африканские человекообразные обезьяны (african great apes). Наконец, мы люди.

В наследство от наших предков и родичей нам досталось три основные доминанты поведения (мотивов) (в порядке убывания):

  • еда
  • размножение
  • доминантность

(кстати, если вы адепт Пирамиды Маслоу – вам надо пересмотреть свои взгляды).

И именно это мы упустили, когда кинулись надувать наш пузырь страха. А теперь не понимаем, почему нас задвигают подальше. Посмотрим, как в связи с этим меняется наша картина ИБ рисков на реальные риски.

Классическая схема риска

Классическая схема риска

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

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

Например, на данной битве было два мотивированных человека: Олег с точки зрения доминирования и Дима с мотивом еды (победителя покормят на BISA Summit). Понятно, что при прочих равных Олег не будет тыкать Диме ручкой в глаз. В то время как Диме отступать некуда.

Например, в нашей отрасли сейчас кризис. Увольнения, задержки зарплаты и т.п. Из наших вендоров и интеграторов уже вынесли все более или менее ценное. От клиентов до листов рассылки для спама. Голодный человек обойдет наши CPB и глазом не моргнет. Тогда зачем мы?

В поИБэ мы ставим способ реализации во главу угла. Все наши ЧМУ пестрят действиями (например, Кража носителей информации или Установка ПО, не связанного с исполнением служебных обязанностей), а субъектам уделяем 3 абзаца в модели нарушителей. Мы ставим DLP и не знаем, что ответить на вопрос заказчика – а от фотографирования экрана защищает?

Не даром ни одно внедрение СЗИ не может обойтись без оргмер. Зачем ломать сложный пароль, если можно подсмотреть?

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

P.S. Уже стал известен мой оппонент по полуфиналу — Эльман Бейбутов из Solar. Мой прогноз: мне надерут задницу. Ведь в Solar работает больше 100 человек. Но я буду биться.

Хотите это видеть? Поставьте напоминалку.

КЦД – святая троица безопасности? Или MaxPatol апостол всея безопасности

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

Holy_Spirit_IB

И вот, сижу я и думаю: «Риски доступности информации реализовались, что привело к ущербу…» Так, стоп. Что там говорит теория про информацию? У информации есть три свойства – конфиденциальность, целостность, доступность. Есть еще куча, мне, например, очень уж нравится неотказуемость. Святую троицу я изучал по буржуинскому ISO, а там еще куча свойств. Хотя некоторые утверждают, что любое свойство можно выразить через КЦД – нашего отца, сына и святого духа. Но об этом как-нибудь в следующий раз.

Сижу, значит, и думаю, а как там с доступностью? Наверняка тоже по трынде пошла. Базы покорежились, восстанавливать надо. Зато с конфиденциальностью полный порядок, никто мою информацию не узнает, т.к. доступа к ней нет. Зато узнают, что она недоступна. Но это другое.

Помните, когда-то был «приказ трех» по персональным данным? Алексей Лукацкий тогда на каждом углу говорил, что у нас нет типовых систем, а есть только специальные, т.к. надо обеспечивать еще доступность и/или целостность окромя конфиденциальности. Тогда все было красиво, действительно целостность и доступность важны.

А на практике? А на практике выходит, что безопасник может воздействовать только 1 одно свойство, максимум на 1¼. Например, мы никак не можем воздействовать на доступность. Во всяком случае, на доступность информации в информационных системах, т.к. это чисто айтишная тема: если системы не работают – никакой безопасности не надо. Что мой случай наглядно и показал. Нет системы – нет проблемы. Можно сказать даже больше – безопасники вредят доступности. Все эти наши железки, ставящиеся в разрыв, или хитрый софт обогащающий пакеты идентификаторами и метками. Все это для ИТ службы черный ящик и дополнительная точка отказа. В одном крупном банке воткнули железку по обогащению трафика, так она на 2 часа всю сеть и положила. В общем, с доступностью мы не помогаем и даже вредим.

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

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

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

Всего вам доброго.

Инструкция Роскомнадзора для сотрудников и экспертов при проведении проверок в области персональных данных (Секретно) Часть №1. Выездная проверка

Общие положения

    1. Каждый сотрудник Службы по надзору в сфере связи, информационных технологий и массовых коммуникаций (далее – Служба) обязан быть готов провести выездную и документарную проверку Операторов персональных данных в любое время, 365 дней в году.

Совершенно секретно

    1. В ходе проверок необходимо руководствоваться положениями Федерального закона от 27.07.2006 N 152-ФЗ (ред. от 21.07.2014) «О персональных данных» (с изм. и доп., вступ. в силу с 01.09.2015) (далее – Закон), внутренними инструкциями Службы и здравым смыслом…
  1. Сотрудник Службы должен проверять исполнение Закона во всех проявлениях гражданской жизни у юридических лиц и индивидуальных предпринимателей, с которыми сталкивается по вопросам бытового получения товаров и услуг. В случае выявления признаков нарушений следует воспользоваться Инструкцией №1 по формированию плана проверок.

Проведение выездной проверки

    1. Если вам выпало проводить выездную проверку, расслабьтесь. Посмотрите, привлекаются ли аккредитованные эксперты? Если да – хорошо, они братюни, и можно будет хорошо провести время. Если нет, не отчаивайтесь – повезет в следующий раз.
    2. Хорошенько выспитесь.
    3. Перед проверкой распечатайте последнее уведомление об обработке Оператора.
    4. Если в уведомлении указан один юридический адрес, а Оператор находится совершенно по другому адресу – смело езжайте по первому. Будьте внезапным. Это заставит понервничать ответственного у Оператора. Приятная поездка на другой конец Москвы плюс легальный выходной. Помните наш девиз № 42: Служба в радость!
    5. Вы на месте, внимательно посмотрите, кто пришел со стороны Оператора. Если он пригласил юриста, консультантов и того парня, чей блог вы иногда читаете, значит, ему есть что скрывать. Не паникуйте! Вы тут главный.
  1. Сразу запросите весь перечень проверяемых документов в электронном виде. Если ответственный их предоставляет – он душка, плюс в карму. Если нет, то подумайте, что делать с таким букой. Может быть, дать ему печеньку?
  2. Попросите Ответственного перечислить ИСПДн с персональными данными. Если среди них нет:
    • Бухгалтерской;
    • Кадровой;
    • Системы контроля доступа;
    • Электронной почты;
    • Домена Active Directory (при наличии),

внимательно к ним присмотритесь.

    1. Спросите, есть ли биометрия?
    2. Потролльте ответственного вопросом о видеонаблюдении. Если ответ оригинальный – запишите в книжечку для размещения на нашей Доске крутых отмазок (ДКО).
    3. Проверьте актуальность уведомления и всех данных, в нем представленных.
    4. Посмотрите, кто делал документы по защите персональных данных. Если лицензиат – попросите договор. Если сами – попросите документы о соответствующей подготовке или переподготовке (минимум на 2 человек).
    5. Посмотрите на дату последнего отчета об обследовании. Если ей больше года — мы красавчики. Если меньше, ответственный – красавчик.
    6. Если у Оператора есть самописные или самостоятельно дописываемые системы (1С, SAP, SharePoint, сайт и т.п.), обратите внимание на решение вопроса с НДВ. Если угроза НДВ нивелирована, послушайте объяснение. Если оно хорошее, запишите для добавления в ДКО.
    7. Не будьте букой.
    8. Если Оператор использует облака, мы в Эльдорадо. Если облако зарубежное, то в Эльдорадо-плюс-плюс. Сразу напишите смс коллегам во ФСТЭК и ФСБ, они должны это увидеть.
    9. Посмотрите договор на использование облака. Попросите показать вам пункты, отвечающие за безопасность вообще, и безопасность персональных данных в частности. Попросите копию договора. Ну, а вдруг?
    10. Посмотрите модель угроз. Если много неактуальных угроз – выберите наугад 3 и попросите объяснить. Лучшие ответы запишите для ДКО.
  1. Посмотрите проект на систему защиты персональных данных. Если с вами нет братюнь-экспертов или коллег из ФСТЭК или ФСБ, вам нельзя оценивать технические меры – печалька. Зато можно выписать используемые средства защиты.
  2. Попросите акты установки на все используемые средства защиты.
  3. Послушайте и запишите лучшее, почему вы этого не можете получить.
  4. Не будь букой.
  5. Попросите сертификаты ко всем используемым средствам защиты.
  6. Послушайте и запишите лучшее, почему этого нет.
  7. Не будь букой.
  8. Переходите к осмотру помещения…
Неожиданный конец документа
Найдены новые фрагменты… Сканирую… распознаю

Что делать, если вы специалист по персональным данным, или услуги, вышедшие в тираж

Недавно я писал про средства защиты, вышедшие в тираж. Сегодня поговорим об услугах. Сподвиг меня на это Евгений Бабицкий, который подумал, что я «наехал» на его любимый PCI DSS, назвав его вышедшей в тираж услугой. О чем мне сразу и написал. Евгений, как бы это было не прискорбно, но это факт. И вы, и я в одинаковом положении. В чем суть?

Услуги вышедшие в тираж

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

1. Это услуги, которые предоставляют все.

2. Это услуги, на которых уже так просто не заработаешь. Т.е. можно, но сложно. В отличие от тех же антивирусов.

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

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

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

То же самое происходило и с PCI DSS. Я помню те благословенные времена, когда у нас было всего две компании со статусом PCI QSA (ох, какие они чудесные срачи устраивали между собой на форумах). Когда-то обследование по PCI DSS можно было продать за 400 тысяч долларов. И это не какой-то удачный случай, это поголовно так было. Именно с того времени тянется большинство внедрение ArcSight, который ставили в сегмент PCI DSS и больше не трогали. Сейчас эти времена прошли, ASV-сканирование сейчас можно взять за 100 тысяч рублей, внешний аудит и комплект документов за 500. Печалька :(

Назовем их всех

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

<реклама>

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

<реклама>

2. СТО БР и НПС. СТО БР был с самого начала мертворожденным. Отличный стандарт, огромная работа, но легкость присоединения к нему убила этот рынок. Плюс к этому узкая отрасль, на которой уже все сделано. НПС примерно такой же.

3. PCI DSS. Все крупное сделано, осталась лишь поддержка. Если вам это надо, обращайтесь в Compliance Control, они давно этим занимаются (Евгений, с тебя причитается :)).

4. Pen-test. Тут ситуация двоякая. Есть два вида: просканировать сканером (так называемый assessment) или реально поломать. Не знаю, как со вторым, а вот с первым просто швах. Помню, разговаривал с директором ИБ топ-3 банка, он рассказывал, как сделал запрос нескольким интеграторам на пентест, и один подмосковный интегратор ему предложил это сделать за 35 т.р. С поправкой на желание «зайти в клиента» это стоит те же 100-200 т.р.

5. Аттестации. Как по конфиденциалке и персональным данным, так и по гостайне. Лицензиатов много, ценники мизерные и зависят только от количества компьютеров.

Все так плохо?

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

Всего вам доброго.

SOC-forum как квинтэссенция отечественных конференций

Пойти на SOC- forum меня сподвиг исключительно конкурс от Андрея Прозорова на лучший отчет о форуме (если вдруг будет голосование, голосуйте). ;) Надо сказать, что на различных мероприятиях по ИБ я бывал достаточно. Например, 9 лет подряд ходил на Infosec (теперь уже нет).

Мероприятия эти делятся на три вида: общей направленности (тот же инфосек), вендорские, маркетинговые или партнерские. SOC- forum был вендорским мероприятием, маскирующимся под общую направленность. Почему вендорским? Потому что главным спонсором выступала компания Solar Security, она же держала большой стенд и читала львиную долю докладов. Только не подумайте ничего плохого (Денис, все норм).

SOC-forum в глазах слушателей

SOC-forum в глазах слушателей

В общем, все это я примерно представлял, и пошел туда в новом качестве. В качестве блоггера. Что значит быть блоггером? Это значит надо везде ходить и все слушать. Я так и делал.

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

Раздаточный материал странный, блокнота не дали (было три листа для заметок в программке), зато дали 2 ручки. Все началось с опозданием на 10 минут, так и катилось до конца. Залы совсем не были приспособлены для подобного шоу, экраны как-то странно расположены – если сидеть по центру, то голову свернуть можно. И навязчивая реклама по центру. Я сам был на пленарке и секции Андрея Прозорова. У Алексей Лукацкого зал был в 3 раза меньше, и все не поместились. А так ничего – на троечку с минусом организовали.

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

Главный вывод по конференции – все собрались, потусовали, но дельного ничего не сказали. Конференция прошла впустую. Человек неподготовленный не смог даже узнать, что такое SOC. Пленарку вообще начали со срача. Лукацкий и Маннаников на предложение утвердить определение SOC хором сказали «НЕТ!». Но зал в лице представителя Дипакадемии надавил (уважение). И все стали пытаться дать определение. Виталий Лютиков попытался перевести разговор в научно-техническую точку зрения (и в целом говорил интересные вещи про процессы в соках, но мало).

Самое дельное по определению «Что такое SOC?» сказал Иван Мелехин: как переведем Operation в SOC, так сразу сложится картинка — лиибо управление, либо мониторинг.

Настала первая очередь всех высказаться. Игорь Ляпунов начал сразу с рекламы Solar. Иван Мелехин спросил «а существуют ли SOC , или это новый маркетинговый ход»?

Лучшее место, что бы слушать и задавать вопросы

Лучшее место, чтобы слушать и задавать вопросы

А потом все свалилось вообще в Ад. Кстати, ни один заявленный вопрос пленарного заседания так и не получил ответа. Хотя голос разума иногда возобладал. Что удивительно – это было со стороны регуляторов, за что им респект. Все заспорили о… госрегулировании соков. Не буду описывать, лишь цитаты:

Ляпунов: госрегулирование – хорошо, разумное вдвойне хорошо.

Мананников: нужен пряник, необходимо сертифицировать SOC.

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

Лютиков: создайте свой стандарт по SOC, не ждите регуляторов.

Финогенов: Я еще не знаю, что такое SOC. В начале практика, затем регулирование.

Все слушают пленарное заседание

Все слушают пленарное заседание

Следующим кругом ада стало обсуждение ответственности соков перед Заказчиками. Опять только цитаты:

Ляпунов: Ответственность за информационную безопасность на заказчике, нельзя ее переложить на аутсорсера.

Лютиков: включайте в договора солидарную ответственность.

Лукацкий: у нас и за ЗПД никто ответственности не несет, у нас не защита персданных, а защита о регляторов.

И поговорили немного про банки.

Сычев: Отслеживает ли DLP унесенную базу дропперов? А надо.

Курило: Инциденты в банке могут не возникать годами. SOC – это армия в постоянной боеготовности.

По итогу пленарное заседание потерпело фейл. Сокрушительный. А надо было изменить всего лишь малость, уменьшить количество экспертов. Я бы с удовольствием послушал, например, регуляторов – Виталия Лютикова (ФСТЭК) и Дмитрия Финогенова (ФСБ). Крайне разумный подход к проблеме. Я отдельно послушал бы критику Лукацкого и Мананникова. Отдельно – представителей вендоров. Но всех вместе – это фейл «клуба любителей SOC» и Авангарда.

Затем начались секции…

Я был на «Тематическое заседание 1 «Опыт построения и эксплуатации SOC». Сам я сделал чуть-чуть SOCов, поэтому было интересно услышать опыт коллег. Тут не буду подробно описывать – презентации можно посмотреть в интернете, напишу лишь свои записи к каждому из выступающих. Это те вопросы, которые у меня возникли к ним, и которые я старался задать (два раза меня прокатили, хотя уже держал микрофон в руках). Кстати, всю секцию я один практически вопросы и задавал – блоггер, что с меня возьмешь?

Top3 блоггер, на секции по опыту построения SOC

Top3 блоггер на секции по опыту построения SOC

Опыт построения и эксплуатации центра мониторинга ИБ в ОАО «РЖД»

Александр Глухов, заместитель начальника Департамента безопасности ОАО «РЖД»

Рассказывали, как ЦБИ внедрило SOC в РЖД.

Агентская технология? Сертифицирован ли агент? НДВ? Является ли агент угрозой и точкой отказа? Какие контроли используются? Все теперь делают геопривязку. РЖД еще не подключено с СОПКЕ.

Вопрос про агент задал разработчикам. Получил ответ, что 1 версия была сертифицирована, сейчас 3, и когда-нибудь ее сертифицируют. Получил интересное мнение, что если ЦБИ является сертифицирующей лабораторией, то софт пишет без НДВ.

<слухи mode on>

Уже в перерыве конкуренты открыто говорили, что решение у ЦБИ не работает.

<слухи mode off>

 

Опыт построения и эксплуатации коммерческого SOC

Владимир Дрюков, руководитель департамента JSOC Solar Security

Время на остановку атаки (с) – оно есть?

Готовы ли вы нести солидарную ответственность? Этот вопрос так и не дали задать :(

 

Технологии и опыт реализации распределенного SOC

Роман Назаров, начальник отдела систем управления рисками ЗАО НИП «Информзащита»

Информзащита тоже внедрила SOC в РЖД… Так и не понял, как они сферы влияния с ЦБИ попилили.

Сделали несколько территориально распределенных центров обработки инцидентов. Единой мастер ноды и корреляции нет. Разделено по инцидентам.

 

Опыт построения и эксплуатации центра мониторинга компьютерных атак и управления инцидентами

Алексей Васильев, руководитель центра мониторинга, ЗАО «Перспективный Мониторинг»

Была и дочка Инфотекса. Нишевой продукт для сетей VipNet.

Могут ли использоваться другие IPS? В какие SIEM/ SOC других вендоров вы передаете информацию? Инцидент, описываемый по ГОСТу? Вы заменяете собой антивирус? Много слов «будет» и «будущего времени»

Цитата: SIEM из коробки.

 

SOC: от идеи к результату

Андрей Янкин, руководитель отдела консалтинга Центра информационной безопасности компании «Инфосистемы Джет»

Хороший теоритический доклад.

Цитата: 46 функций SOC, но еще никто их не реализовал.

 

Эффективный SOC для критической инфраструктуры. Знания и инструменты

Евгений Генгринович, советник Генерального Директора АО «ITD Group»

Как иностранный GRC применять в РФ? Правильно ли, что вы предлагаете «консультант» с практиками по ИБ? Как происходит обновление фидов в сегменте АСУ ТП без интернета?

 

Фундамент для построения SOС

Руслан Бялькин, директор по продажам комплексных решений, SAFEDATA

Цитата: ЦОД и SOC не различаются с точки зрения инфраструктуры.

 

На секции у Лукацкого в каждом докладе была реклама себя любимых и тех решений, что они продают. Отличился только Positive, сказав, что не делает SOC и SIEM.

Дальше уже не мог быть, поехал по делам своего SOCa.

Итоги:

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

Идти или не идти в следующий раз? Если вас приглашают бесплатно – конечно, идти. А вот деньги за такое платить не стоит.

P. S. Усе, ухожу из блоггеров. Неблагодарная это работа. Андрею и Алексею по службе положено везде бывать и выступать. Грусть видна в их глазах. Не хочу так. Лучше я буду по-простому – графоманить на тему безопасности, и на конференции особо не ходить.

Про тренды в информационной безопасности: SOC, ЗПД и т.п.

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

Сразу жбахну картинку.

Количество проектов за последние 6 лет

Количество проектов за последние 6 лет

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

До 2011 года я активно выполнял работы сам и чуть-чуть пресейлил. После активно пресейлил и гиповал и чуть-чуть делал сам. Т.к. изменился спектр обязанностей, получился большой разрыв в количестве. Продажи занимают больше времени, чем исполнение (сравнимо с методическими рекомендациями Департамента образования). А ведение проекта не заканчивается с написанием комплекта документов.

Предлагал я весь спектр интеграторских услуг, но в итоге получилось следующее:

Разбивка проектов по типам работы

Разбивка проектов по типам работы

Сейчас пишу и вспоминаю, что еще делал pen- test, внедрял DLP и еще всякое разное, но уж как получилось. Как видно, персональные данные как стали трендом в 2009 году, так и не отпускают пальму первенства.

Количество проектов по защите персональных данных

Количество проектов по защите персональных данных

А вот в процентах тренд виден более явно:

Количество проектов в процентах по защите персональных данных

Количество проектов в процентах по защите персональных данных

И последняя диаграмма: разбиение по отраслям:

Количество проектов по отраслям

Количество проектов по отраслям

Что в итоге?

1. Персональные данные все еще тренд. Спасибо 242-ФЗ.

2. SOCи набирают популярность (надо похвалиться – я приложил руку к одному из крупнейших SOCов в Восточной Европе). Но ввиду масштабности проектов это могут потянуть не все интеграторы.

3. Анализ рисков – тема, о которой все говорят, но мало кто хочет за нее платить. Во всяком случае в отрыве от других работ. А с другими работами — это, скорее всего, с персональными данными.

4. Количество проектов мало влияет на выполнение квоты (но об этом как-нибудь в другой раз). С 2011 по 2014 – личное выполнение плана.

5. В основном ЗПД заказывают или те, кого обязали (госы), или те, кто под прицелом (образование, медицина).

Я знаю, в среде многих известных блоггеров принято ругать защиту персональных данных. Но надо понимать, что это хлеб всего интеграторского бизнеса по информационной безопасности (да и у заказчиков). В 2008 году я ставил CheckPoint и XSpider и выступал с презентациями, как круто аттестоваться по ISO 27001.

Всего вам доброго.

Выбор вендора как первая любовь

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

Задачи могут быть самые разные, как и решения. Последние делятся на два больших класса – услуги (консалтинг) и «железо», куда входят программное обеспечение и программно-аппаратные комплексы различных вендоров. И если задача не решается консалтингом, надо подбирать какие-то решения от вендоров. О последних и поговорим.

Как выбирать вендора?

Как-то мы с Аркадием Прокудиным говорили о том, как вендоры обманывают (Аркадий, оказалось, свой сайт запилил – уважуха). Поэтому сегодня не об этом. Главная наша задача — выбрать, с какими вендорами работать, а с какими нет.

Вас найдут

Если вы начинающий пресейл, единственная информация, которая у вас будет – листовки и другая макулатура от вендоров. У меня как-то в плане прохождения испытательного срока в одном пункте так и было написано: «Изучение маркетинговых материалов».

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

Четыре главные вещи

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

  1. Кто ваши конкуренты?
  2. В чем принципиальное отличие от них?
  3. Сколько маржи?
  4. Как защищается сделка?

Первые два вопроса чисто технические. Главное — уяснить суть, все равно знать всего нельзя.

Вторые два прямо вам интересны. А можно ли на этом выполнить квоту? Тут целый зоопарк. Есть вендоры с огромным прайсом и маленькой скидкой (большие западные компании и специализированные отечественные). Есть с большой скидкой, но малым прайсом (квоту не сделаешь). Мои самые любимые – с адекватным прайсом и существенной скидкой.

Помню, как-то пришел к нам вендор А10 (я про него и не слышал). Они сразу сказали: мы такие же, как F5, только в 4 раза быстрее и в два раза дешевле. Вот это правильный разговор, сразу интересно послушать.

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

Первым балуются западные вендоры. Например, Check Point с радостью закрепит за вами сделку и даст дополнительные 10% скидки, но если у вас бронза или серебро, вас любой голдовый партнер вынесет с вашей защитой. Печалька. Но, видимо, у них и выбора нет.

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

Моногамность

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

А вот Аркадий был в плане вендоров полигамен. Он любил всех, и все любили его. Но проектов всегда меньше, чем вендоров, и потом мы засыпались в подтверждении всех статусов, что у нас были.

Ищите своих вендоров.
Всего вам доброго.

Старикам здесь не место, или средства защиты информации, на которых не заработаешь

Как-то неожиданно все друзья и коллеги узнали об этом блоге, и настала популярность :) Самый популярный вопрос – зачем? Ответ: конечно, дикий и бешеный самопиар, чем я хуже.:) И, к тому же, я – графоман.

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

Устаревшие средства защиты

С точки зрения интегратора (продаж) – это средства защиты, на которых уже нельзя заработать. Рынок этого насыщен и/или это уже у всех есть. Этим нельзя удивить, на этом не сделать квоту, это вышло в тираж.

С точки зрения заказчика – это уже ставшее чем-то обыденным, чем-то являющимся само собой разумеющимся. Тем, о чем знает даже собственник бизнеса, который может говорить лишь о яхтах и сигарах.

— Имя, сестра, имя!

Возглавляют список антивирусы. Вот уж точно о них слышали все. Если его у вас нет, вы, скорее всего, сидите на линуксе. Интегратору здесь практически не заработать, особенно с нуля. Да, если у вас в пуле есть заказчик с 10 000+ станциями, вы получите 1 млн. маржи.

Касперский, ESET, Symantec и остальные — извините.

Следующие в списке – межсетевые экраны и VPN. Тут все разнообразней, ведь даже на Cisco можно включить ACL и получить простенький фаервол. Если в штате есть безопасник, то можно увидеть фаервол сертифицированный и с гостовым VPN. Но если его нет, любой айтишник ограждает свою вотчину извне. Заработать еще можно: при поставке сертифицированных решений (желательно с гостом), а также при расширении филиальных структур и постройке чего-нибудь нового. Один минус: фаервол — это надолго, на второй год, в лучшем случае, техподдержку продашь.

Тройку замыкают системы анализа защищенности. Этих уже поменьше, но если есть безопасник – значит в 90% случаев есть XSpider. Что может быть более любо, чем посканить и принести красивый отчет? Сейчас все больше разрастается Qualys. Ну, и старший брат паука – MaxPatrol. Интеграторы чаще всего закладывают сканеры для выполнения требований по защите персональных данных. Если деньги есть – MaxPatrol, если нет – Xspider.

Это были старички. Есть и потенциальный новичок – DLP. Если раньше можно было продать 1000 лицензий за 20 млн., теперь уже нет такой роскоши. Все, кому нужно было купить — купили. Подтянулись новые игроки, сбросили с себя пыль старички – и пошла заруба, кто меньше даст цену. Еще пара лет, и будет как с антивирусами.

И, чтобы уж было ровно пять, внесем в список IPS/IDS. Скажу честно, продавал я их только для персданных. Решение это не самостоятельное, и всегда берется в нагрузку к фаерволу. Купили Cisco или Check Point, и IPS там же купите. Со смертью StoneSoft и разнообразие ушло – либо безумно дорого, либо snort под разными соусами.

Не обижайте стариков. Всего вам доброго.

Управление инцидентами ИБ на основе SIEM-систем

По проблеме управления инцидентами пишутся целые книги. Тема эта обширная и жестко зависящая от конкретной организации (процесса). В данной статье предлагаю ограничиться вопросом автоматизации процесса управления инцидентами с помощью SIEM-систем.

Что же такое инцидент?

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

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

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

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

Инцидентами информационной безопасности могут быть:

  • отказ в обслуживании сервисов, средств обработки информации, оборудования;
  • нарушение конфиденциальности и целостности ценной информации;
  • вредоносные программы и т.д.

Каждый инцидент может быть классифицирован по множеству признаков. Я использую следующие:

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

Процесс управления инцидентами

Так как инциденты наносят ущерб работоспособности системы (реальный или потенциальный), целесообразно организовать процесс управления ими. Он включает в себя (рис. 1):

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

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

  • возможность мониторинга целевых систем и средств защиты с организацией выделенного хранилища инцидентов и log-файлов;
  • расследование инцидентов;
  • возможность получения информации от подразделений (в первую очередь IТ) по произошедшим инцидентам с высокой важностью реагирования и предоставления информации;
  • полномочия по форс-мажорному исправлению последствий инцидентов с привлечением необходимых специалистов других подразделений;
  • возможность создания корректирующих мер.

Сложности реализации процесса управления инцидентами

Процесс управления инцидентами сопряжен с некоторыми трудностями:

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

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

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

Данные препятствия значительны, но не смертельны. Любое из них может быть компенсировано различными организационными мероприятиями.

Автоматизация процесса управления инцидентами

Учитывая обилие целевых систем, возможных инцидентов и рисков, мы получаем огромное множество параметров, которые необходимо отслеживать. Делать это вручную не представляется возможным. Нам нужен централизованный мониторинг, который сможет определять инциденты, складывающиеся из штатных событий. Другими словами, мы должны автоматизировать процесс управления инцидентами (рис. 2).

Система управления событиями – это глубоко интегрированная с другими процессами система. Разумеется, большинство этапов можно сделать локальными, но тогда серьезно снизится эффективность автоматизации.

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

  • Подключать любые IP-системы и устройства. Если мы не можем направить поток событий в SIEM лишь потому, что у нас самописная система, дорого и трудно разрабатываются коннекторы или необходимо обращаться в штаб-квартиру на другом конце света, то зачем нужна такая система?
  • Подключать отечественные средства защиты. Учитывая специфику отечественной информационной безопасности, необходимо понимать, что немногие организации могут обойтись только западными вендорами.
  • Работать с Service Desk. SIEM должна уметь генерировать заявки об инцидентах и отслеживать их выполнение. Во-первых, это позволяет сократить время реагирования; во-вторых, вовремя необработанный инцидент – это тоже инцидент.
  • Инициировать управляющее воздействие. Необязательная, но крайне полезная функция. Существует много ситуаций, когда решение по инциденту должно быть произведено быстро. Например, изоляция рабочей станции от локальной сети организации путем «выключения» порта на маршрутизаторе для последующего разбирательства. Данная функция требует деликатного обращения, поэтому ее использование целесообразно после прохождения этапа решения ошибок 1-го и 2-го рода.
  • Организовывать инвентаризацию существующих и поиск новых информационных активов. Не существует статичных организаций, поэтому, если мы не имеем текущей картины существующих активов, наш процесс управления событиями будет иметь белые пятна, о которых он ничего не знает. Если карта активов хранится в SIEM-системе, она должна уметь поддерживать их в актуальном состоянии.

Необходимые документы

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

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

Дудко Дмитрий
Опубликовано: Журнал «Information Security/ Информационная безопасность» #3, 2014

Нужен ли вам IDM?

Системам Identity Manager (IDM) уже без малого 10 лет. За это время они прошли значительный путь в своем развитии. IDM – это системы, которые призваны автоматизировать процесс управления учетными записями. Цель, безусловно, благая – управлять однообразным и рутинным процессом по созданию, изменению и блокированию учетных записей, освободить административные ресурсы, избавиться от “мертвых душ» и т.п. Но так ли все радужно, как утверждают вендоры и интеграторы? Когда и кому выгодно внедрять IDM?

Предоставление доступа – это процесс

Казалось бы, мысль банальная. Но за этой мыслью скрывается огромный фронт работ. Во-первых, если это процесс, он должен быть описан и понятен. У процесса есть начало (вход процесса) и конец (выход процесса). Давайте изобразим для начала процесс предоставления доступа на примере одного из банков, в котором IDM так и не был внедрен. Банк крупный, более 5 тыс. человек, 7/8 из которых работают в двух основных информационных системах. Всего систем не более десятка. IT-департамент хотел бы, чтобы процесс предоставления доступа начинался из кадровой системы, далее переходил на этап согласования со всеми заинтересованными сторонами, заявке назначалась соответствующая роль и предоставлялся соответствующий доступ к целевым системам. В то же время ИБ-департамент контролирует процесс согласования и выполняет верификацию выполненных прав доступа.

На рис. 1 представлена желаемая автоматизация процесса предоставления доступа при приеме и увольнении сотрудников.

Нужен ли вам IDM? Рисунок 1

Если же у нас происходит изменение роли пользователя (рис. 2), то IDM должна получать управляющее воздействие из Service Desk после этапа согласования.

Вроде все просто, но решение о внедрении IDM Нужен ли вам IDM? Рисунок 2не принято (о чем мы подробнее поговорим ниже). В данный момент процесс работает без IDM, хоть и не без проблем. Таким образом, IDM должна легко адаптироваться в существующую схему работы.

IDM стоит дорого. Несмотря на то что IDM-решения присутствуют на рынке довольно давно, стоят они как самолет. Высокая стоимость лицензий на программное обеспечение дополняется стоимостью работ по внедрению и кастомизации. Сюда же необходимо добавить техническое сопровождение. Рынок не стоит на месте – уже сейчас есть предложения даже от отечественных вендоров. Тренд рынка IDM устремился в средний бизнес.

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

В-третьих, автоматизация процесса должна оптимизировать время (и расходы) обслуживания процесса.

К сожалению, у IDM по всем пунктам появляются сложности.

Организационные проблемы

Все IDM используют ролевую модель предоставления доступа. Это хорошо и правильно. Каждый сотрудник должен иметь права, соответствующие его роли и должностным обязанностям.

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

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

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

Проблемы внедрения

Необходимо сказать сразу, IDM-решения – не «коробочный» продукт. Из «коробки» IDM работает с узким кругом систем. Если вам необходимо управлять учетными записями в AD, почте и СУБД, вам скорее всего хватит базового функционала. Но, например, в банке необходима интеграция с 1С, не самым популярным Service Desk, и программой, которая не поддерживает даже LDAP-каталоги, не говоря уже о большем.

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

Нужен ли вам IDM? Рисунок 3

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

Таким образом, IDM-решение должно быть кастомизированным, доработанным специально под заказчика. И тут в полный рост встает проблема целесообразности.

Проблема цены

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

Рынок не стоит на месте – уже сейчас есть предложения даже от отечественных вендоров. Тренд рынка IDM устремился в средний бизнес. Давайте вернемся к нашему примеру. Один из отечественных вендоров произвел оценку стоимости внедрения IDM и сделал выводы, что для компании в тысячу человек проект IDM будет стоить $200 тыс. и окупится за 2–3 года. В зависимости от курса цена этого решения 6–8 млн руб. в год. Сумма не такая уж и большая. Но в банке управление доступом занимает 6 человек full time. Как вы понимаете, для создания учетных записей не требуется высокой квалификации, а несложная арифметика подсказывает, что за те же деньги можно было бы нанять еще несколько человек. Это уже сомнительная экономия. А если учесть затраты на поддержание в актуальном состоянии ролевой модели (а учетные записи могут занимать многие и многие книги в Excel), то не проще ли оставить все на ручной обработке, написать пару скриптов, согласование доступа переложить на пользователей и т.п.? Тут требуется серьезное финансовое обоснование и учет специфики каждой отдельной компании.

После решения этих вопросов переходим к вопросам безопасности.

Необходимый функционал

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

IDM должен избавить нас от «мертвых душ», убрать лишние права пользователей и т.п. Но все это уже при внедренной IDM. Но все угрозы безопасности существуют в уже работающих системах. Следовательно, должны быть:

  1. механизм выгрузки существующей картины;
  2. механизм наложения ее на необходимую ролевую политику;
  3. коррекция прав доступа и удаление лишних прав.

Увы, но зачастую IDM-решения могут сделать лишь один пункт из трех. Все остальное дается на откуп консультантам и интеграторам, то есть все опять же будет делать человек.

Заключение

IDM-системы необходимы. Большинство описанных проблем кроется в том, что в самом начале, при планировании инфраструктуры и создании бизнес-процессов, никто не задумывался об управлении доступом.

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

Дудко Дмитрий
Опубликовано: Журнал «Information Security/ Информационная безопасность» #2, 2014