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

С новым годом!


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

 





вторник, 13 декабря 2011 г.

Новый подход к оценке зрелости процессов от ISACA

Пару слов о новой инициативе  ISACA - программе по оценке зрелости процессов.
На текущий момент, помимо основного документа, содержащего в себе модель оценки процессов, ISACA предлагает руководства по оценке и самооценке, а также инструментарий. Руководство по самооценке и поддерживающий его инструментарий бесплатны для членов ассоциации, в то время как за руководство по оценке процессов и инструментарий придется потратиться.
Чем же новый подход лучше  и почему нельзя использовать старый добрый CMM? Рассмотрим аргументы ISACA:
  • PAM (process assessment model) соответствует международному стандарту по оценке процессов ISO 15504. Лично для меня аргумент сомнительный, поскольку в наших реалиях стандарт практически не используем. 
  • PAM содержит детальные требования к процессам из CobiT - ... хм. Поскольку информация и так из CobiT - в чем преимущество не понятно
  • PAM позволяет оценить достижение "атрибутов процесса" из ISO 15504 - смотрим пункт первый
  • PAM содержит требования к "доказательствам" работы процесса - первый серьезный аргумент. Вместо общего описание "документирован и доведен до всех", "производит 1,2,3..."
  • PAM содержит требования к квалификации и опыту оценщика - тоже, на мой взгляд, весомый аргумент, поскольку качество результатов оценки критично зависят от оценщика. 
Результат оценки отражается такой же 5-и уровневой шкалой. Процессы оценки очень похожи, но все-таки они разные:
  • PAM использует шкалу из ISO15504, а CobiT -  CMM
  • 3-й уровень зрелости PAM не то же самое, что 3-й уровень зрелости CMM
  • Оценка по PAM выполняется по более детализированным атрибутам
После беглого осмотра новый подход кажется более взвешенным и детальным, а значит и более полезным. Главное, разобраться с отличиями во избежание путаницы.

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

В поиcках корней. Часть 2. Обзор инструментов для выявления причины

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

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

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

В поисках корней. Часть 1 Обзор процесса решения проблем

Сегодня начинаю серию постов посвященных анализу корневых причин.
Штука, популярная в процессе управления ИТ, известном как "управление проблемами", прекрасно подходит как для нужд информационной безопасности, так и для аудита.
В любом случае она нам понадобится в ситуации, когда мы имеем ряд негативных проявлений, будь то инциденты информационной безопасности или признаки неэффективно работающего процесса. Главное, что что-то подсказывает нам, что у этих проявлений есть потенциально что-то общее - класс инцидентов, общий регион/подразделение/временной период или это просто сигнал от спинного мозга, и мы почувствовали, что за этим стоит всемирный масонский заговор какая-то общая причина. И если понять ее суть и избавиться от нее, в будущем это потенциально избавит нас от повторения всей этой кучи инцидентов. Что положительно повлияет на премию статистику для показа руководству общую защищенность, эффективность процесса, или что мы там пытаемся улучшать.
Для решения проблемы нужно выявить корневую причину (причины) и найти пути ее (их) устранения и предотвращения повтора в будущем. Звучит очень просто, но на практике это может оказаться не такой тривиальной задачей.
Далеко не всегда можно сразу назвать причину происходящего.
Например, большое количество инцидентов безопасности, регистрируемых SIEM, могут возникать в результате неправильного конфигурирования сети. Вроде все просто? Поправили и забыли. На небольшой период времени. А потом опять инциденты и та же причина. Копаем глубже, и видим, что вроде бы проблема в постановке процесса администрирования. Недосмотр администратора? Копнув еще глубже, понимаем, что проблема не в знаниях и навыках администратора, а в его мотивации. И знает, что можно внедрить контроль  в процессе согласования изменения, который позволит избежать таких ситуаций, но не хочет это делать. Обидели его во время одного из проектов, вот он и доказывает всем, что он д`Артаньян был прав.
Часто бывает, что причин несколько, и они имеют разный уровень вложенности, т.е. одна причина порождает, вторая - третью, а та уже является источником проблемы.

Классифицируем причины:
  • Симптомы. Они являются не настоящими причинами, а скорее признаками существования проблемы.
  • Причины первого уровня. Это причины, которые напрямую являются источником проблемы.
  • Причины более низкого уровня. Это причины, которые порождают причины первого уровня. Хотя они и не являются непосредственным источником проблемы, причины более низкого уровня являются связующим звеном в цепочке причинно-следственных  связей, которая приводит к возникновению проблемы.
  • Корневая причина - причина, запускающая всю цепочку причинно-следственных связей, порождающую проблему.





Итак, рассмотрим подход по выявлению ключевой причины.

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


На сегодня все. В следующий раз об инструментах выявления основной причины.

часть 2 ->

среда, 7 декабря 2011 г.

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

Использование аутсорсинга - замечательная вещь. Не нужно содержать штат, обеспечивать его рабочими местами, помещениями и т.д. Достаточно лишь подписать договор и SLA и получать удовольствие. По крайней мере, так подают себя компании, оказывающие аутсорсинговые услуги.
В реальности, конечно, и стоимость может существенно превышать содержание собственных сотрудников, и с SLA могут быть проблемы... Но речь сегодня не об этом.
Как бы надежно мы не  защищали свои данные в компании, как только они  покидают ее пределы, попадая в руки аутсорсеров, уверенность в надежности защиты данных существенно падает.
Да, мы подписали NDA (договор о неразглашении). Да, в договоре написано "холить и лелеять".
Но уверенности нет. Чем же ее можно укрепить? Прописать требования к безопасности в SLA?
Откровенно говоря, прописать их грамотно на практике крайне не просто. Хотя и нужно. Составление SLA само по себе дело не простое, а включение туда грамотных требований по безопасности - задача и вовсе из разряда ракетостроения. Но это - только начало. Нужно еще определить механизмы оценки качества сервиса в разрезе выполнения требований по безопасности.
Если у компании есть сертификат соответствия международным стандартам по безопасности, вроде ISO 27001, можно попробовать полагаться на него. Если нет (что вполне логично - ведь в природе таких компаний практически нет) - можно попробовать заставить компанию проходить внешнюю оценку и предоставлять нам отчет.
На какие грабли можно наступить при использовании подобных вариантов?
Начнем с ISO, поскольку многие аутсорсеры  заявляют о скорой сертификации "во благо клиентов". Что же, рассмотрим этот фантастический сценарий.

Темные стороны ISO 27001
  1. Прелесть стандарта состоит в том, что для получения сертификата абсолютно не нужно, чтобы СУИБ охватывала все процессы и географические объекты компании. Т.е. сертифицированная СУИБ может не иметь никакого отношения (!) к процессам по обработки ваших данных.
  2. Стандарт не требует внедрения всех 133 контролей из приложения А (annex A), как многие думают. По большому счету, для успешной сертификации достаточно выполнить требования разделов с 4 по 8 и на этом ограничиться. Поэтому нужно внимательно почитать SoA (положение о применимости, обязательный документ по требованию стандарта) - какие именно контроли внедрены и почему. И, разумеется, убедиться в том, что интересующие нас контроли внедрены.
  3. На что еще нужно обратить внимание, так это на результаты оценки рисков и решение по их обработке. Если в компании определен высокий риск-аппетит, большинство оцененных рисков может быть попросту принято руководством компании (т.е. оставлено как есть). В результате мы имеем официально утвержденный перечень принятых рисков и ни одного контроля (крайний случай, конечно, но теоретически возможен). При этом, компания все еще соответствует требованиям стандарта.
  4. Снова оценка рисков. Методика, используемая для оценки рисков, может быть любая, удовлетворяющая скудным требованиям стандарта (читаем "почти все существующие методики"). Поэтому качественная оценка (например, риск высокий, средний или низкий) - вполне приемлемый вариант.  Для аутсорсинговой компании разумеется, но не для вас. Субъективное понятие "средний уровень риска" может означать все, что угодно и оценить адекватность выбранных мер - просто не реально.
  5. Если мы прошли все предыдущие пункты и остались удовлетворены, неплохо бы убедиться, что компания не только построила СУИБ для сертификации, но и поддерживает сертификат (т.е. проходит соответствующий ежегодный аудит) 
Итак, фантастический сценарий с сертифицированным поставщиком услуг рассмотрели, возвращаемся на землю. Если у компании нет волшебной цветной бумажки сертификата, можно попробовать обязать компанию проходить регулярные внешние аудиты.


Проблемы внешнего аудита 
Поскольку сервисная компания включит затраты на проведение аудита в наш счет, сразу зададимся вопросом - все ли еще стоимость услуг + стоимость аудита меньше стоимости собственного выполнения активности, отданной на аутсорс? Допустим, да - идем дальше.

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


Стоимость консультантов не забыли добавить? Все еще выгодно?  Тогда идем в проблемы привлечения консультантов.

Аудит по SAS 70

Как красиво подают стандарт консультанты, SAS 70 предназначен для оценки эффективности управления рисками и эффективности системы внутреннего контроля, обеспечивающей информационную безопасность и надежность услуг. Так вот же оно! То, что нужно!
Да и внешних компаний, готовых проводить оценку - хоть пруд пруди. Но, как говорил персонаж анекдота, есть один нюанс. Стандарт не предлагает типового набора целей аудита, поэтому результат в большей части зависит от качества постановки целей аудита. Т.е. мы должны четко понимать, что именно необходимо проверить и на предмет чего.
Кроме того, отчет второго типа содержит мнение аудитора о достоверности системы и пригодности дизайна контролей на  данный момент времени и не распространяется на весь период. Т.е. контроли хорошо работали на момент аудита, а что было в течении, например, года - кто знает?
К счастью, этот недостаток восполнен в требованиях SSAE 16, который в этом году пришел на смену SAS 70.
Если не нравится  SSAE 16 (вы - америкофоб?) - можно взять ISAE 3402 - международный стандарт, на основе которого SSAE 16 и создавался. Может это и есть то самое волшебное решение?

Проблемы внешнего аудита - ISAE 3402
Стандарт учел все недостатки своих предшественников и предстал перед нами во всей красе. В чем же подвох? А дело в том, что поголовное число консультантов на текущий момент обладает большим количеством буклетов о преимуществах данного стандарта, а вот опыта - увы и ах. Первые аудиты по PCI-DSS послужили замечательным примером того, как консультанты за счет заказчиков обучались работать по стандарту, предоставляя печально низкий уровень услуг. Такая же судбьа уготовлена и ISAE. Это не значит, что направление тупикове. Наоборот - в перспективе, как говорят консультанты, данный стандарт позволит вывести надежность аутсорсинговых услуг на новый уровень,  но пока следует очень избирательно подходить к выбору консультантов, обращая внимание на наличие практического опыта использования стандарта. Да и в будущем это не помешает. Я бы остановился на тех, у кого богатый опыт SAS70 и точное понимание отличий его от нового стандарта, будь то ISAE или SSAE.

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