Quis custodiet ipsos custodes?

Disclaimer

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

среда, 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.

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


2 комментария:

  1. Володя, хороший пост. Спасибо.

    А в чем принципиальная разница между "аутсорсером" и "сотрудником"? :-)

    Знание и умение сотрудника так же декларативно в начале вашего с ним сотрудничества. Кодекс о труде меньше всего защищает Бизнес, а в договоре с "аутсорсером" такооое можно прописать ;-)

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

    ОтветитьУдалить
  2. Володя, пост не о том. :)
    Тут мы предполагаем, что внутри компании все хорошо, а риски у третьей стороны.
    Про сотрудников - как-нибудь отдельно. Это все-таки блог, а не книга :)

    ОтветитьУдалить