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

9.8.19

ИБ-фреймворки: какие бывают и зачем нужны?

На прошедшем "Код ИБ. Профи" еще одной активно обсуждаемой темой стали фреймворки, - о них рассказывал Илья Борисов, делавший обзор существующих распространенных фреймворков, и Андрей Прозоров, посвятивший свое выступление ISO 27001. Я решил тоже не отставать от коллег и поделиться своим взглядом на эту тему.

Я бы выделил три набора фреймворков, различающихся по своим задачам и цели применения - контрольные (от английского control, которое по-русски звучи длиннее - "мера защиты"), программные и рисковые. Большинство знакомо с первой категорией, которые представлены не только иностранными примерами - NIST SP800-53, горячая двадцатка CIS (бывший SANS Top20), а также отечественные документы ФСТЭК (приказы 17/21/31/239) и Банка России (ГОСТ 57580.1).


Эти фреймворки нужны для решения важных "технических" задач по ИБ:

  • определение базового набора защитных мер, подходящих конкретной организации
  • оценка текущего состояния уровня технической защиты информации
  • приоритезации защитных мероприятий и составления дорожной карты развития.
Отличительной особенностью хорошего фреймворка являются группирование (тут почти все упомянутые выше примеры на высоте) и приоритезация защитных мер. А вот с последним пунктом в документах ЦБ и ФСТЭК есть сложности. Каталоги защитных мер обширны и насчитывают около двух сотен наименований, но как из них выбрать те, что дают максимальный эффект, особенно в условиях нехватки ресурсов на внедрение, непонятно. У уже не раз мной описанных австралийских требований по ИБ, например, есть такая приоритезация. Есть Топ4, Топ8 и Топ35 защитных мер, которые позволяют достичь 80%, 90% и 98% результата. Аналогичная функция есть и у NIST SP800-53 - против каждой защитной меры в поле "Приоритет" стоит значение от 0 до 3, означающих важность реализуемого мероприятия.


"Программные" фреймворки предназначены для:

  • оценки текущего состояния программы ИБ на предприятии
  • построения всесторонней (хотя это все-таки не совсем так) программы ИБ
  • измерения зрелости программы ИБ и обеспечения возможности бенчмаркинга (сравнения себя с другими по отрасли).
Самым известным в Евразии и популярным фреймворком является ISO 27001, а в Северной Америке - NIST CSF. Первый интересен тем, что у него множество расширений под различные задачи. Например, есть ISO 27019 для энергетики, 27011 для телекома или ISO 27701 (совсем свежий стандарт) для персональных данных. В отличие от технических мер защиты, в ISO 27001 или NIST CSF меры носят более высокоуровневый характер - взаимоотношение с поставщиками, выбор средств защиты, управление активами, работа с персоналом, повышение осведомленности, управление инцидентами и т.п.





Часть этих мероприятий есть и в приказах ФСТЭК, но они все-таки ориентированы именно на техническую составляющую, чем на выстраивание программы. С ними можно построить и некоторое подобие программы, но для этого надо иметь достаточно большой опыт работы с документами ФСТЭК, - новичку это не удастся - многие пункты понятным далеко не всем. Да и процесс оценки текущего состояния или измерения зрелости программы ИБ по нормативным актам ФСТЭК невозможен. Я уже писал о возможных вариантах решения этой задачи, но они должны исходить от регулятора. ЦБ эту задачу решает лучше - у них скоро должен появиться еще один стандарт как раз по управлению ИБ на предприятию, который позволит и текущее состояние программы ИБ оценивать, и ее зрелость. 

Если первые два типа фреймворков хорошо дополняют друг друга, то третий имеет смысл применять только в очень зрелых компаниях, которые действительно понимают, что такое риски ИБ и знают как считать вероятность и ущерб (а это то еще приключение). В целом данный тип фреймворка, ярким представителем которого является FAIR или серия NIST, позволяет:
  • идентифицировать и измерять риски ИБ
  • приоритезировать защитные мероприятия
  • определить ключевые этапы управления рисками
  • структурировать программу управления рисками.
Резюмируя, хорошие фреймворки, опираясь на опыт уже множества внедрений и набитых шишек, позволяют сэкономить вам время и нервы, следуя описанному в фреймворке алгоритмы построения системы ИБ. Но не стоит думать, что вам нужен именно один из перечисленных выше фреймворков. По статистике Gartner 20% компаний разрабатывают собственный фреймворк, еще 16% дорабатывают существующие, а 20% - комбинируют компоненты из разных фреймворков. Еще 21% вообще их не используют вовсе, а 23% используют стандартные фреймворки (NIST CSF, ITIL и ISO 27001 входят в тройку самых популярных по версии NIST). 



Поэтому выбирайте то, что лучше подходит именно вам и именно под ваши задачи. Если вы государственный орган, то выбор у вас не богат - документы ФСТЭК и, возможно, ГОСТ Р ИСО/МЭК 27001 (сейчас как раз через ТК 362 проходит новая версия этого стандарта). Для финансовых организаций обойти ГОСТ 57580.1 (и последующие ГОСТы от ТК122) будет непросто. Остальные же имеют свободу выбора и я бы (если бы я выбирал), остановился бы на NIST CSF и NIST SP800-53. А если бы передо мной стояла задача выбора только контрольного фреймворка, то CIS Top20 у меня был бы на первом месте (или австралийский перечень).

ЗЫ. Практические аспекты по этим фреймворкам можно посмотреть в докладах с "Кода ИБ. Профи", которые скоро будут доступны на сайте (по подписке).

14.6.19

Почему сертификат ISO 27001 приводит к снижению инвестиционной привлекательности, а программа bug bounty лучше пентестов...

Есть такое классное мероприятие по ИБ (не в России), которое называется The Workshop on the Economics of Information Security (WEIS) и которое из года в год собирает доклады, посвященные различным исследованиям в области экономики ИБ. В этом году WEIS проходил в Бостоне 3-4 июня и в его рамках было представлено ряд интересных докладов, о которых мне хотелось бы немного рассказать.

Равив Марчиано-Горофф представил исследование о влиянии калифорнийского закона 2002 года о раскрытии инцидентов с утечками данных на инвестиции в информационную безопасность. В России после принятия ФЗ-152 ситуация с ИБ не менялась до 2008-го года, когда было принято первое "четверокнижие" ФСТЭК с требованиями по защите ПДн. После этого многие службы ИБ "подняли" денег на выполнении требований регулятора. А вот закон Калифорнии, как оказалось, не сильно повлиял на американский бизнес и его инвестиции по ИБ. Исследование проводилось среди 214 тысяч компаний, которые оценивались по одному параметру - установка обновлений безопасности на web-сайтах, обрабатывающих персданные. Выглядит достаточно нестандартно, но, видимо, это единственно публичная и унифицированная  информация, которую нашел Равив. Так вот оказалось, что только 1,8-2,8% компаний обновили свои сервера после выхода закона американского штата. Это позволило сделать вывод, что принятие аналога ФЗ-152 не сильно повлияло на инвестиции в ИБ. Примерно тоже самое мы видим и в России сейчас (хотя у нас таких исследований и не проводилось). Думаю, что GDPR немного изменит эту статистику, но только по одной причине - сумма потенциального штрафа.

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

  • Инвесторы не реагируют однозначно негативно на инциденты с безопасностью.
  • Невзломанные компании сталкиваются с отрицательной доходностью после объявления инцидентов в своей отрасли, а также с ростом затрат на аудиты на 6%.
  • Доходность акций страховых компаний также падает.
Третье исследование было посвящено экономической эффективности программ bug bounty. Я вспоминаю выступления Кирилла Ермакова из Qiwi на прошлогоднем "Код ИБ. Профи" в Москве, где он сравнивал экономику пентестов и bug bounty. На WEIS 2019 исследование базировалось на большем количестве исходных данных. Не буду перечислять все выводы; обращу внимание лишь на парочку:
  • Для фирм гораздо выгоднее запускать программу bug bounty для поиска уязвимостей в своих системах, чем искать высоквалифицированного и дорогого хакера (пентестера).
  • Bug bounty не заменяет внутреннюю ИБ. При отсутствии системы защиты выплаты вознаграждений по программе bug bounty будут слишком велики. При этом внедрение системы ИБ в компании приводит к снижении выплат и нахождению определенного баланса между размером выплат и стоимостью системы защиты.

В заключение упомяну еще одно исследование, представленное на WEIS 2019. Оно было посвящено изучению оценки влияния фондового рынка на инвестиции в проекты по ИБ, которые имели некоторую публичную составляющую. В частности, речь шла о получении сертификатов соответствия английской Cyber Essentials и ISO 27001. 145 сертификатов UK Cyber Essentials за период 2014-2018 годы привели к положительной оценке со стороны фондового рынка и рост доходности компаний, получивших сертификат. А вот с ISO 27001 ситуация оказалась прямо противоположной и даже парадоксальной. 76 сертификаций по ISO 27001 с 2001 по 2018 годы показывают значительную негативную оценку со стороны рынка. По мнению авторов исследования это связано с тем, что рыночные аналитики и инвесторы рассматривают дорогостоящие инвестиции в ISO 27001 как бессмысленную трату денег, которая только ухудшает финансовые показатели компаний и ничего не дает с точки зрения бизнеса. Интересная версия...

10.5.16

Сказ о том, почему цикл PDCA плохо работает в ИБ

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


PDCA является аббревиатурой цикла Plan-Do-Check-Act (Планируй-Делай-Проверяй-Улучшай) и впервые эта концепция была озвучена Шухартом и Демингом в рамках идеи повышения качества на производстве в Японии. Потом на ее базе стали выстраивать процессы и в других областях, в том числе и информационной безопасности, разумно полагая, что если этот цикл позволяет улучшить качество производства, то почему бы с его помощью не улучшить качество управления ИБ. Однако, если отбросить в сторону постоянно ведущиеся споры на тему “Зачем мне ISO 27001?”, то гораздо более интересен вопрос самой применимости цикла PDCA в области современной ИБ (обратите внимание на ключевое слово “современной”).

Какие отличительные особенности ИБ можно назвать? Во-первых, это ее нелинейность. Это в теории красиво выглядит - “21 шаг построения ИБ на предприятии”, “Горячая десятка ИБ-процессов”, “Поэтапное внедрение системы управления ИБ в компании” и т.п. Реальность, она иная. Либо регулярно появляющиеся новые вводные, либо новые угрозы, заставляющие менять подходы к ИБ, либо вовсе хаотическое развитие, неподчиняющееся упрощенному и выхолощенному лозунгу “Планируй-Делай-Проверяй-Улучшай” (кстати, меня всегда удивляло, почему Act переводят как “улучшай” и чем Act отличается от Do?). Это если не рассматривать и вовсе новомодные штучки типа Agile, которые прямо конфликтуют по своей идеологии с размеренным и долгоиграющим PDCA и ISO 27001 на его основе. Кстати, ряд экспертов, стоящих у истоков ISO 27001, прямо говорят, что текущий цикл обновления стандарта - это зло; он не учитывает изменений, происходящих в отрасли, что негативно сказывается на эффективности процесса управления ИБ на предприятиях.

Во-вторых, безопасность в отличие от системы качества требует учета “интересов” злоумышленников, которые могут разбить все благие намерения по линейному циклу обеспечения управления ИБ. Более того, система повышения качества вообще не предполагает конкурентной среды, которая есть в информационной безопасности и без которой она немыслима. Вас ударили туда, где вы вообще забыли провести анализ рисков. Или вы запланировали внедрение повышения осведомленности персонала только через 2 года (а раньше денег не дают), а основной вектор для злоумышленников именно в вашей компании - это и есть нерасторопность и невнимательность пользователей. Вы срочно меняете свои планы и внедряете систему обучения персонала, а злоумышленики уже переориентировались и бьют по вашим контрагентам. Как тут помогает линейный и последовательный PDCA? Никак.

В контексте отсутствия учета внешних конкурирующих сил никак не помогает и любая другая цикличная модель, используемая в ИТ. Например, тот же COBIT, который в предыдущей, 4-й версии использовал тот же PDCA, а в новой, пятой версии перешел на семишаговый цикл. Но и он не учитывает воздействия неотъемлемых для ИБ сил напрочь отсутствующих в ИТ. В модели ITIL ровно тоже самое - цикл PDCA во всей красе.


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

Кстати, первоначальная концепция PDCA была ориентирована на дополнительные улучшения уже существующих процессов, а не на перестройку всего процесса производства или построение его с нуля; да еще и в сложно организованной компании. Ведь понемногу улучшать существующее гораздо проще, чем строить все с основ. У нас же ISO 27001 рассматривается именно как стратегия построения или перестроения службы ИБ с самого начала и внедрения процессов ИБ по всему предприятию. Я нередко слышу от вновь пришедших на новое место работы коллег, что они будут внедрять там ISO 27001 (без сертификации пока). А все почему? Потому что это “стандарт де-факто”, который не принято критически оценивать. Отсюда и не очень высокое число успешных внедрений ISO 27001 и еще меньшее число повторных сертификаций. Многие эксперты отмечают, что ISO 27001 давно уже превратился из стандарта по безопасности в продукт зарабатывания денег для аудиторов и разработчиков новых реинкарнаций ISO 27001 для разных вертикалей и применений - финансов, операторов связи, промышленных предприятий и т.п.

Но ведь PDCA работает! В Японии он сильно помог поднять качество производства. Да! В Японии! 50 лет назад! Вы обращали внимание, где больше всего компаний, сертифицированных по ISO 27001? Не знаю, как сейчас, но еще несколько лет назад, когда эта тема в России была модной, я анализировал страны, в которых сертификация на соответствие ISO 27001 имела хождение. Оказалось, что чуть ли не 80% всех сертификатов выдано японским компаниям. Оно и понятно, в стране, где идея PDCA и родилась и культивировалась, грех было бы увидеть иные цифры. Но в мире картина внедрения ISO 27001 с его концепцией PDCA оказалась совсем иной. На нее очень сильно влияют культурные различия Востока и Запада.

Я в свое время изучал “историю” PDCA и оказалось, что то, к чему мы так привыкли, говоря про PDCA, немного отличается от того, что Шухарт реально делал в Японии 50 лет назад. В реальной жизни процессы, процедуры и мероприятия для улучшения качества были намного детальнее и обширнее, чем выхолощенная абстракция, заключенная в 4-х символах аббревиатуры PDCA, разработанной специально для Запада. На действующих производствах фаз повышения качества было гораздо больше четырех и разрабатывались они специально для Японии и ее культуры. Однако в мир ушла именно упрощенная модель (возможно именно потому, что она была упрощенной и более понятной), потянувшая за собой ворох проблем с ее интерпретацией. И чем больше людей было в цепочке интерпретаторов, тем дальше от исходной концепции уходила реализация. Кроме того, в исходной версии подхода Шухарта и Деминга предполагалось, что за улучшение качества будут отвечать выделенные сотрудники, эксперты, погруженные в тематику. Сегодня, в условиях когда требуется активное вовлечение и рядовых сотрудников в обеспечение ИБ, требовать от них понимания всех ИБ-концепций не приходится. В итоге они начинают очень вольно трактовать достаточно конкретные положения PDCA или того же ISO 27001 (интерпретации и трактовка - это один из бичей стандартизации вообще и ИБ в частности). Кстати, даже сами японцы за 50 лет существования концепции PDCA изменились. Об этом стоит помнить. Люди! Вот те, о ком мало говорится в цикле PDCA, но от кого зависит успех (или неуспех) его внедрения на предприятии. Почему различные японские модели (то же “бережливое производство”) так плохо внедряются за пределами Японии? Почему продукция из одинаковых запчастей, собранная на одинаковых конвейерах в России и Германии, отличается? Потому что люди разные и их восприятие и принятие процессов тоже разные. Пару лет назад в Высшей школе экономики я делал презентацию “Русская ментальность как фактор невозможности адекватного управления ИБ на базе западных практик”, которая вызвала достаточно живую (мягко сказано) дискуссию, которая, на мой взгляд, показала, что в России действительно не так просто внедрять западные (да и восточные) методики управления ИБ, родившиеся в совершенно иной исторической и культурологической среде. С PDCA ситуация такая же.

PDCA не говорит вам как решать те или иные ИБ-проблемы. Это речевка, лозунг из советских времен. Их восприятие зависит от многих условий и для эффективной реализации требует гораздо большей детализации, чем просто 4 шага. При этом большая часть усилий должно тратиться на самом первом этапе планирования, но как можно все, что нужно делать в ИБ, вместить в упрощенный донельзя один шаг “Plan”? Не случайно, видя проблемы с PDCA в области улучшения качества, на свет появились лучше детализированные и проработанные концепции DMAIC (Define - Measure - Analyze - Improve - Control) или “Шесть сигм”. Тот же COBIT в итоге отказался PDCA в сторону семишагового цикла.


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

Значит ли все вышенаписанное, что PDCA - это ненужная и неработающая концепция? Конечно, нет. PDCA может задать основу для построения службы и процессов ИБ, но он не является инструментом, которым можно пользоваться изо дня в день, особенно в “конкурентной” среде, коей является информационная безопасность. Помимо PDCA можно обратить внимание и на другие методы - DMAIC, IDEAL, ТРИЗ, TBBDI, EBBDI, из которых можно извлечь что-нибудь полезное. А вообще, не надо быть догматиком. Ключевой идеей, закладываемой в ISO 27001 в свое время, было создание на базе передового опыта базового уровня в области ИБ. Однако за 20 с лишним лет первоначальная идея была извращена и современный ISO 27001 - это неповоротливая конструкция, ориентированная на соответствие (галочный подход), от которого страдает реальная безопасность предприятия. И положенный в основу ISO 27001 цикл PDCA явно не помог эту конструкцию сделать более гибкой и адаптивной. Концепция PDCA в принципе не учитывает, что процессу улучшения ИБ могут мешать хакеры и регуляторы с генерируемыми ими динамическими изменениями, влияющими на обеспечение ИБ. Отсюда и сложности с ее применением, о которых надо просто знать и помнить.


5.2.16

Лицензия ТЗКИ для собственных нужд больше не потребуется

На портале проектов нормативных актов выложен неприметный документ с неприметным названием: "О внесении изменений в некоторые акты Правительства Российской Федерации по вопросам лицензирования отдельных видов деятельности", который при этом касается именно нашей с вами темы, а точнее вопросов лицензирования деятельности по технической защите конфиденциальной информации (ПП-79).

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

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

  • Требование лицензии на ТЗКИ при проведении мониторинга ИБ. То есть все SOCи и иже с ними потребуют получения соответствующей лицензии от регулятора.
  • Наладка средств защиты также теперь потребует лицензии ФСТЭК.
  • Четко прописаны требования к квалификации и количеству персонала у лицензиата.
  • Оборудование, необходимое для выполнения лицензионных работ, теперь должно быть только в собственности лицензиата. Больше никакой аренды.
  • Требование наличия системы менеджмента ИБ в соответствие с требованиями национальных стандартов. Иными словами, теперь все лицензиаты ФСТЭК должны у себя реализовывать ISO 27001. Что интересно, при подаче документов на получение лицензии необходимо представить копии документов, подтверждающих наличие такой системы менеджмента. Что это за документы? Сертификат соответствия, выданный BSI или иным органом по сертификации?
  • Появилось требование обязательного повышения квалификации один раз в пять лет.
Что можно сказать в качестве резюме по данному проекту нормативного акта. ФСТЭК снимает обременения с тех, кто занимается защитой для себя (а точнее ставит точку в бесконечных спорах о необходимости получать лицензию для собственных нужд). И это позитивно. С другой стороны, требование иметь собственное оборудование повышает порог вхождения в этот бизнес (оборудование недешевое). А уж требование иметь сертификат по 27001 и вовсе существенно сужает число потенциальных игроков этого рынка, оставляя только тех, кто реально понимает, что и зачем он делает. "Старперам от аттестации" больше не место в этой области.

Вторая часть проекта постановления посвящена внесению изменений в ПП-171, посвященное лицензированию деятельности по разработке средств защиты конфиденциальной информации. Тут изменения схожи с вышеописанными:
  • Четко прописаны требования к квалификации и количеству персонала у лицензиата.
  • Оборудование, необходимое для выполнения лицензионных работ, теперь должно быть только в собственности лицензиата. Больше никакой аренды.
  • Наличие системы менеджмента качества (ISO 9000), а также реализацию стандарта (пока проекта) по безопасному программированию (SDLC).
Собственно, ключевое изменение - последнее. Раньше наличие сертификата соответствия ISO 9000 не требовалось при получении лицензии на разработку средств защиты. С одной стороны это позитивный момент, так как с рынка уйдут фирмы-однодневки, решившие на волне импортозамещения по-быстрому состричь денег за счет выпуска какой-нибудь поделки. С другой - требование сертификации системы менеджмента качества выводит за скобки нарождающиеся стартапы, которые не смогут вкладываться в эту статью затрат пока не продадут достаточно количества своих решений. А продавать они их смогут только коммерческим компаниям, которым не требуется сертификация средств защиты (сертификат может быть выдан по сути только лицензиату). Так что решение неоднозначное, но интересное.

ЗЫ. Желающие могут высказать свои предложения (а не критику) на странице законопроекта.

8.7.11

Новости ПК27 ISO

ISO готовит еще один интересный стандарт "Information technology -- Security techniques -- Information security for supplier relationships", посвященный вопросам взаимоотношений с поставщиками продуктов и услуг. Он будет иметь номер 27036. Интересно, что еще несколько месяцев назад данный стандарт назывался "Guidelines for security of outsourcing". Возможно авторы расширили сферу применения, а может быть сделают несколько частей одного стандарта, описывающие различные аспекты взаимоотношений с внешними поставщиками продуктов и услуг (собственно их уже две - вводная и с набором требований).

В феврале я показывал список проектов стандартов, которые готовятся в ПК27 Международной организации по стандартизации. И вот обновление этого списка - новый проект стандарта ISO 27040 "Information technology – Security techniques -- Storage security" по безопасности систем хранения, а также ISO 27039 "Selection, deployment and operations of intrusion detection systems" и "IEC 62443-2-1:2010 Establishing an industrial automation and control system program" (должен был быть опубликован в прошлом октябре).

В ISO также  разрабатывают стандарт ISO 27015, который является переложением 27001/27002 на финансовую отрасль. Однако Visa и MasterCard против этого стандарта. Первая компания считает, что проект стандарта не содержит много нужной информации (например, по платежным системам), а если ее туда добавить, то стандарт надо переносить в другой комитет ISO. И вообще Visa считает, что эту работу надо прекращать ;-) У MasterCard предложение такое же, но мотивация другая - мол, в финансовой отрасли и так полно регулирующих тему ИБ документов.

Посмотрим на результаты этих предложений. Обычно, начатая в ISO работа, просто так не завершается. Возможно все выльется в создание того, что также рекомендовала ISO - сделать из документа технический отчет (TR), который не является стандартом, но просто аккумулирует лучшие практики или описывает состояние дел в конкретной области.

Вкратце так. Дойдут руки, опишу новые изменения и планы изменений в уже принятых и хорошо известных стандартах 27-й серии.

7.7.11

Стандарт ISO по безопасности облаков

В ISO (совместно с ITU-T, ISACA, NIST и ENISA) сейчас начата работа по созданию стандарта по безопасности облаков. Рабочее название - "Information technology – Security techniques – Guidelines on Information security controls for the use of cloud computing services based on ISO/IEC 27002". Несмотря на большой объем предварительной версии документа - это даже не проект, а альфа-версия проекта документа, выпуск которого планируется на 2013-й год.

Недурный документ получается - описано очень много важных тем:
  • Облачные модели и место в них облачных пользователей и провайдеров
  • Место облаков в политике безопасности
  • Организация ИБ - с внутренней и внешней точки зрения. Интересный раздел - описывает особенности разделения ответственности между участниками процесса, содержание соглашения о конфиденциальности и соглашений с третьими лицами, координация усилий и взаимодействие с внешними группами и организациями ИБ.
  • Управление активами. Еще один важный вопрос, который возникает в ситуациях, когда активами владеют разные компании и лица.
  • Управление персоналом. Раздел описывающий действия до и в процессе найма на работу, а также после завершение трудового договора.
  • Физическая безопасность.
  • Операционное управление и управление коммуникациями. Сюда попали вещи, связанные с борьбой с вредоносным кодом, мониторингом и аудитом, управлением сетевой безопасностью, резервированием, управлением пропускной способностью и изменениями, управлением носителями информации и вопросы обмена информацией с третьими лицами.
  • Контроль доступа, включая раздел, посвященный доступу с мобильных устройств и надомных работников.
  • Управление покупкой, разработкой и поддержкой систем.
  • Управление инцидентами.
  • Управление непрерывностью бизнеса.
  • Управление соответствие регулятивным требованиям.

Ждем этот замечательный документ.

24.6.11

Можно ли посчитать ROI по безопасности?

И вновь вернусь к этой животрепещущей теме ;-) Так и не выложил я реальные цифры по расчету ROI по методу Монте-Карло - руки все не доходят оформить это надлежащим образом. Но зато наткнулся неделю назад еще на одну статью, посвященную этому вопросу. А в статье дана ссылка на калькулятор ROSI (Return on Security Investment).

Забавный инструмент. Формула там "простая" - из монетарной стоимости снижаемых рисков надо вычесть стоимость защитных мер, направленных на это самое снижение. Калькулятор работает в два шага. На первом надо посчитать цену всех инцидентов (что может быть проще ;-), а на втором - стоимость защитных мер (security controls). Дальше калькулятор все сделает за вас и выдаст вам в результате расчет ROSI.

ЗЫ. Калькулятор бесплатный, но зарегистрироваться на сайте придется.

ЗЗЫ. От себя добавлю, что вывод, который я озвучил на форуме директоров по ИБ в презентации по финансовой оценке проектов по ИБ, верен и в данном калькуляторе. Чтобы посчитать стоимость инцидентов вам необходимы данные, которых обычно у служб ИБ нет - они в ведении ИТ-департаментов, финансовых департаментов и других бизнес-подразделений. Это вам не объем спама или число дыр считать ;-)

8.4.09

Малому бизнесу компенсируют затраты на сертификацию по ISO 27001

Иногда смотришь на наше законодательство и диву даешься - вроде бы и правильные вещи написаны... по сути, а на деле - чушь и полный бред. Возьмем к примеру Приказ того еще Минэкономразвития от 5 марта 2007 года №75 "О мерах по реализации в 2007 году мероприятий по государственной поддержке малого предпринимательства". Он конечно старый, но действует.

В приложении 5 этого приказа прописаны общие требования к бизнес-инкубатору и порядку предоставления помещений и оказанию услуг субъектам малого предпринимательства в бизнес-инкубаторе. В нем есть перечень затрат субъекта малого предпринимательства, связанных с оплатой услуг по выполнению обязательных требований законодательства Российской Федерации и (или) законодательства страны-импортера, являющихся необходимыми для экспорта товаров (работ, услуг), для выполнения которых предоставляется субсидия. И вот в этот перечень каким-то образом затесался ISO 27001, затраты на сертификацию по которому готово возмещать государство в размере 50%, но не более 250000 рублей.

Каким образом ISO 27001 попал в разряд обязательных? Зачем фермерскому хозяйству (а именно оно приведено как пример предприятия малого предпринимательства) сертификация по ISO 27001? У меня нет ответов. Но знание экспертами бывшего МЭРТа этого стандарта радует (правда непонимание его области применения - огорчает).

ЗЫ. Кстати, согласно этому приказу на субсидию можно рассчитывать и в случае иных стандартов и форм обязательной сертификации. Т.е. затраты на выполнения требований ФСТЭК или ФСБ по линии персданных можно попробовать компенсировать. Правда 250000 рублей по нынешним меркам - это копейки ;-(

10.2.09

Концепция аудита ИБ от ФСТЭК

Совершенно случайно наткнулся на сайте ФСТЭК на проект "Концепции аудита ИБ систем информационных технологий и организаций", который разработан НПФ Кристалл (они же основные разработчики стандарта Банка России по ИБ).

Дословно я не вчитывался, но беглый просмотр документа показывает, что читать западные стандарты у нас научились. Везде идут отсылки на стандарты BSI (PD 3003, 3004), ISO 17799, CoBIT, ФЗ "Об аудиторской деятельности", стандарты аудита российской коллегии аудиторов, федеральные правила аудиторской деятельности, цикл PDCA и т.п.

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

Документ был разработан еще в 2004 году, но до сих так и не принят ;-(

8.10.08

InfoSecurity Moscow 2008: день второй

Закончился день второй InfoSecurity Moscow 2008. Сегодня я рассказывал про малоизвестные стандарты в области ИБ. Когда готовил презентацию сам узнал много нового ;-) Как минимум про 27-ую серию ISO. Вместо 7 стандартов (от 27000 до 27006) 27-я серия будет включать 37 стандартов, в т.ч. и уже ранее выпущенных ISO, которые будут гармонизированы с новыми документами.

10.9.08

InfoSecurity Moscow 2008

Итак, остался месяц до InfoSecurity Moscow 2008. С точки выставки все понятно - ситуация не меняется из года в год. А вот конференционная часть достаточно интересна. К слову сказать мне удалось пробить для себя 6 выступлений ;-) Буду выступать как всегда, в качестве штатного пессимиста и критиковать все те "позитивные" доклады, которые будут нестись с трибуны ;-)

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

В круглом столе "Технические стандарты ИБ: приступ страусиной болезни в национальном техническом регулировании?" отмечусь с темой "Принцип Паретто в стандартизации по ИБ". Хочу показать, что не надо изобретать велосипед каждый раз, как это делается у нас в государстве. Достаточно сделать БАЗОВЫЙ стандарт, который покроет 80% типовых задач ИБ. А вот под остальные 20% и делать дополнительные документы и регламенты.

В круглом столе "Управление ИБ как Management и как Governance: небо и земля". Я эту тему двигаю уже не первый год и тут хочу лишний раз напомнить, что не надо зацикливаться на security management, как это происходит сейчас. Надо переходить на новый, более высокий уровень - security governance. Именно тут понимаешь, что ИБ - это не технология и даже не сервис, а бизнес.

В круглом столе "Международные и российские стандарты ИБ – практика внедрения и оценка соответствия" буду опять развенчивать миф о том, что ISO 27001 - это наше все ;-) В презентации "Как не потеряться среди 600 мировых и российских стандартов по ИБ?" покажу, что помимо ISO 2700x есть еще куча разных стандартов, которые можно и нужно реализовывать на своем предприятии.

В круглом столе "Управление инцидентами ИБ" я рассматриваю существующие "Стандарты управления инцидентами ИБ". Сегодня об этом говорят многие, но опять же ссылаются на один единственный стандарт ISO. А ведь есть еще, как минимум, стандарт ITU-T для операторов связи и ряд других документов.

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

А вот седьмое заявленное мной выступление "Почему законодательство о персональных данных выполнить невозможно даже теоретически?" не прошло. Видимо всем надоело, что я ругаю выпущенные документы ФСТЭК и мне решили малость перекрыть кислород ;-)

25.7.08

Очередная оценка рынка ИБ в России

Компания LETA IT-company выпустила второй отчет "Навстречу переменам: рынок информационной безопасности 2007-2008", посвященный рынку ИБ в России. У меня и к первому отчету были серьезные претензии, но видимо авторы второй версии не приняли во внимание всю ту критику, которая на них свалилась. При этом авторы смело заявляют "Первый отчет был выпущен в начале 2007 года и многие его оценки стали признанными фактами на рынке информационных технологий".

Что же меня смутило в этом отчете? Во-первых, названный объем рынка в 912 миллионов долларов. Наверное, приятно причислять себя к почти миллиардному рынку, но эта цифра не просто взята с потолка, - она притянута за уши. Причем авторы противоречат сами себе. В прощлом отчете объем "белого" рынка ИБ составлял 250 миллионов; в этом - 431. При этом цифра рост объявляется в 45-50%! Как у математика (в прошлом) у меня при этих объемах такого роста никак не получается. Другая цифра - 6% всего рынка - это аппаратное обеспечение. Только мы, как один из крупнейших производителей именно аппаратной безопасности, зарабатываем в России вдвое больше. А ведь помимо нас встречаются и другие игроки (нечастно, но встречаются ;-)

Вообще приведенные цифры, кроме как гаданием на кофейной гуще не назовешь. "Белый" рынок, "черный" рынок, "серый" рынок? Как его оценивали? Откуда такие цифры? Что в них входит? Если только то, что четко называется средством защиты, то 912 миллионов - это оценка раза в 2,5-3 превышает реальность. Если речь идет даже о встроенных в инфраструктурные решения механизмах безопасности (ОС, СУБД, маршрутизаторы, коммутаторы), то емкость рынка превышает оценки LETA в разы. Правда про последний вариант LETA даже не упоминает.

Во-вторых, непонятна методика подготовки отчета и источники информации. В преамбуле сказано, что цифры взяты путем опроса участников рынка. Cisco как бы и не последняя на российском рынке (если не сказать первая по данным Cnews) ИБ, но нас не спрашивали. Это конечно не показатель, но сомнение в остальных оценках закрадывается. И вообще, почему в отчете не указаны компании, которых опрашивали? Чего скрывать их имена? Может потому, что никакого опроса и не было?

Главным разочарованием авторы отчеты называют "отсутствие роста широкого применения международного стандарта ISO 27001". А кто его вообще предсказывал, этот рост? "Эксперты" LETA? Ни один здравомыслящий специалист такого предсказать не мог. Да, интерес к стандарту есть. да, есть первые попытки сертификации. Но ни о каком широком применении необязательного стандарта речи и быть не может. Если уж авторы ссылаются на то, что пользовались данными Gartner, то могли бы посмотреть на оценки этой международной компании. А она еще пару лет назад предсказывала, что стандарты ISO 2700x выйдут на "плато продуктивности" не раньше чем через 5-10 лет.

Главной удачей рынка называется активный рост сегмента DLP. Это просто смешно. Активность Infowatch и Perimetrix на данном поприще еще не говорит о том, что рынок развит. Все DLP-вендоры вместе взятые заработали в России от силы миллионов 6-10 (LETA, правда, называет цифру в 24 миллиона). При правдивости данных LETA - это меньше процента. Интересное толкование удачи. И вообще DLP не дает покоя специалистам LETA. Почему-то они считают, что быстрый рост данного сегмента российского рынка связан с выходом документов ФСТЭК по персональным данным и выходом российских компаний на IPO и обязательным соответствии SOX. Однако 4-ка нормативных актов ФСТЭК по защите ПДн вообще ни слова не говорит про DLP-решения (даже косвенно), а IPO необязательно должно осуществляться в Америке, где и действует SOX/

Одной из главных тенденций развития угроз эксперты LETA называют угрозы для мобильных устройств. И я опять задумываюсь о том, что не стоит слепо копировать западные отчеты и надо иногда думать. Я активно езжу и в России и зарубежом и еще ни разу не столкнулся с мобильной угрозой. НИ РАЗУ!!! Мобильный Касперский у меня раз пять на смартфоне "вылез" и то по поводу неизвестного отправителя SMS. Угроза мобильных угроз очень сильно раздута. Да, про нее нельзя забывать и через несколько лет она станет актуальной (может и в России). Но нельзя же ее называть одной из главных. Вывод о росте интереса к мобильным устройствам со сканерами отпечатков пальцев я комментировать не буду.

Интересный вывод сделан о том, что одной из важных тенденций 2007 года стал "экономический" подход при выборе и внедрении решений ИБ. Мол, многие компании научились считать стоимость своей информации и активно используют методы финансовой отдачи в проекты по ИБ. Где, кто?.. Ау?!..

Некоторые моменты отчеты вызывают недоумение и вопросы. Например, авторы почему-то ставят знак равенства между ISO 20000 и ITILv3. А ведь последний был выпущен двумя годами позже ISOшного стандарта. В отчете, датированном 2008-м годом (не ранее марта), упоминается компания Vontu, которую Symantec купил еще в прошлом октябре.

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

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

Пугает меня заключение, данное в конце отчета: "Компания LETA продолжит исследование российского рынка информационной безопасности. В дальнейшем будут выпушены исследования как по отдельным сегментам, так и по рынку в целом (2009 год). LETA IT-company надеется, что эти исследования, которые компания готовит для себя, будут востребованы всеми участниками ИТ и ИБ рынка."

10.4.08

О заблуждениях в безопасности, ставших классикой

Опубликовал тут статью "О заблуждениях в безопасности, ставших классикой" про три священных коровы ИБ, которые давно уже "протухли":
- ISO 27001
- численная оценка рисков
- триада "конфиденциальность, целостность и доступность".

Читать...

7.4.08

О моделях зрелости, ISO 27001, 15408, ROI в безопасности и многом другом...

Интересная дискуссия развернулась на форуме по ИБ на банковском сайте bankir.ru. Если по поводу моделей зрелости действительно есть, о чем говорить, то другие темы достаточно интересны. Например, что такое ОУД в ISO 15408? Это уровень доверия к объекту оценки, т.е. системе защиты, или к оценке оценщика? Оказывается есть специалисты, которые уверяют, что вторая трактовка единственно верная, что российской аутентичный перевод 15408 не соответствует оригиналу, и что нашим разработчикам стандарта надо еще многому учиться.

Аналогичная "битва" развернулась и по поводу трактовок ISO 27001. Например, насколько он зависит от экспертной трактовки? Или какая логика используется при аудите - бинарная (есть мера контроля или нет) или иная?

Также интересная дискуссия началась по поводу термина ROI в безопасности. Может ли ROI не учитывать вообще понятие "прибыль"? И как в методике ROI подменяется термин "прибыль" на "потенциальный ущерб".

Если есть желающие подисскутировать, то приглашаю на форум:
- Зрелость бизнеса и ИБ
- ISO 27001 ISMS Toolkit

27.2.08

Кладезь полезной информации ;-)

20-21 февраля мы проводили Cisco Security Summit, но дело даже не в этом. На конференции были озвучены следующие темы:
  • Как связать безопасность с бизнес-стратегией предприятия?
  • Управление информационной безопасностью с помощью ISO 27001, ISM3, ISF, ISO 13335 и других международных стандартов
  • Архитектура информационной безопасности
  • Обеспечение информационной безопасности в контексте стандартов ITIL и CoBIT
  • Требования стандартов PCI DSS и ISO 17799 и другие

Если вдруг кому-то интересно, то презентации выложены на http://my.cisco.ru/materials/?action=view&id=141

27.12.07

Первый в СНГ банк, получивший сертификат соответствия ISO 27001

В декабре этого года АзияУниверсалБанк успешно прошел сертификацию по международному стандарту Системы Управления Информационной Безопасностью (СУИБ) - ISO/IEC 27001:2005. Он стал первым банком в СНГ, получившим сертификат по информационной безопасности Британского института стандартов.

Детали: http://www.aub.kg/ru/news/?news=1034

2.11.07

Максимизирование бизнес капиталовложений

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

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

Кто это переводил? Сегодня, как мне кажется, даже машинный перевод таких ляпов не делает. Читая такие приглашения, желание участвовать в мероприятии пропадает напрочь.

ЗЫ. Кому интересно, речь идет о конференции "27000 Business Goes Global" (http://www.infosystem.ru/longconf.php?fid=1193842725848334)

28.9.07

ISO 27001 в России: модно и бессмысленно

Ну вот Cnews и опубликовал мое очередное творение на тему ISO 27001. Заранее хочу предупредить, что данная статья писалась не как критика самого стандарта. Он хорош и правилен. Вопрос только в его применимости в России. Причем правильной применимости. Не ставя под сомнение его нужность, просто хочу выделить некоторые "болевые точки", на которые надо обращать внимание при его внедрении или при желании его внедрить. Повторяя заключение к статье: "Несмотря на достаточно длинную историю, стандарт ISO 27001 пока так и не превратился в России из отвлеченной теории в успешную практику. Необходимо время. Для потребителей. Для консультантов. Для регуляторов. А пока… Не хотелось бы столкнуться с ситуацией, когда управление ИБ (и сертификация этого процесса) у нас будет осуществляться формально, как в большинстве случаев с ISO 9001:2000. Это дискредитирует саму идею сертификации безопасности".

Читать: http://www.cnews.ru/reviews/index.shtml?2007/09/28/268177

11.9.07

О западных стандартах и методиках

В последнее время все чаще и чаще слышим восторженные слова и дифирамбы в адрес ISO 27001, ISO 17799, ISO 15408 и т.д. Мы восхищенно вникаем в западные методики, восхищенно внимаем западным «оракулам», усваиваем западный сленг и иностранные словечки (один только «файрвол» чего стоит), стремимся за западными сертификатами, не задумываясь над простым вопросом: «А оно нам надо?»

Мы стали часто смотреть на Запад. Будто бы там все хорошо, все правильно, все ОК. У Запада действительно стоит многому поучиться и многое перенять. Но с умом, адаптируя к нашему менталитету, культуре, уровню зрелости. А мы берем все и, не меняя, пытаемся прививать. Но так нельзя. Обратимся к безопасности. Да, США на несколько корпусов ушли вперед и все, что прогрессивного есть в информационной безопасности (исключая может быть криптографию), взято именно от них. Но взято как-то неумно и неумело. Вспомним наши РД, появившиеся в далеком 1992 году и ставшие Библией для большинства российских специалистов по защите информации. А ведь эти РД были калькой с более ранней «Оранжевой книги», входящей в состав «Радужной серии». Однако, взяв за основу неплохой документ, наши пути разделились. В США «Радужная серия» разрослась до нескольких десятков книг по различным аспектам информационной безопасности, а потом ей на смену и вовсе пришли «Общие критерии», которые сейчас уже известны в своей третьей (пусть и нефинальной) редакции. У нас же РД (их меньше 10-ти) в неизменном виде известны до сих пор. Дальше больше.

Помимо классических РД мы стали применять и «Общие критерии» (ГОСТ Р ИСО/МЭК 15408), хотя в список стран, признающих выданные в других государствах сертификаты, мы так и не вошли. Более того. Несмотря на аутентичный перевод, наша версия «Общих критериев» официально не признана другими странами. Мы все ищем, что же плохого в «Общих критериях». Именно это прозвучало на одной из конференции из уст представителя Совета Безопасности РФ. С этим стандартом вообще ситуация непонятная. По нему уже сертифицируют, а вот что делать со «старыми» РД непонятно. Четкого ответа от ФСТЭК, по какому из двух направлений – РД или «Общие критерии» - нам двигаться вперед, до сих пор нет. Вот и вынуждены производители сертифицировать свои продукты дважды – по обоим документам – по старому, но всем известному, и по новому, но не всем понятному.

А теперь обратимся к международным стандартам ISO 27001 и 17799. Мы их приняли в России достаточно «быстро» – в 2007 году. Только вот принятые версии этих стандартов давно уже устарели. В России принята версия 2000 года, а весь мир работает по версии 2005 года. Опять хотели как лучше, а получилось…

Нельзя забывать, что многие западные методики появились в нужное время и в нужном месте. И если их превозносят в мире, это не значит, что они могут быть легко применимы в России. У нас немного иная история отрасли безопасности, иные специалисты, иные регуляторы, иные законы, иной уровень зрелости. Почти все у нас, за исключением продуктов, иное. Мы же, не оглядываясь на наш опыт, стараемся внедрять западные «best practices» (вот еще одно часто используемое западное словосочетание). И очень редко, когда успешно. А все потому, что мы не готовы к ним. Не зря все эксперты по ITIL признают, что ITIL – это лучшие ЗАПАДНЫЕ практики и их нельзя безоговорочно применять у нас – эффект может быть совершенно противоположным. Да и в предисловии к самому ITIL прямо написано, что эти рекомендации – не догма. Мы же всегда уходим в крайность и начинаем их навязывать… и на законодательном уровне тоже.

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

Интегрироваться в западный мир надо. Но обдуманно. Главное не потерять себя. Брать полезное и отбрасывать наносное, ненужное и вредное. Надо научиться уважать себя и жить своим умом. Не все, конечно, надо начинать с нуля. Надо просто воспользоваться теми граблями, на которые уже наступил Запад и, вовремя их обойдя, сделать шаг вперед. Самостоятельно.