Приветствую всех! Я работаю в Департаменте информационной безопасности ЛАНИТ, руковожу отделом проектирования и внедрения. В этой статье я хочу поделиться опытом, как на старте карьеры совсем в другой компании подготовил стандарт для организации защиты персональных данных в медучреждениях. Это история о том, как написать 500 страниц с нуля за 10 дней, сделанных ошибках и сложностях, которые не были преодолены. Надеюсь, мой опыт поможет всем, на кого свалилась задача написать руководящий документ, стандарт или закон.
Месяц до дня Х
2009 год в сфере безопасности персональных данных был годом предвкушения. Ходили упорные слухи, что 152-ФЗ «О персональных данных», принятый в 2006 году вот-вот станет обязательным для исполнения. Рынку и операторам отвели время на подготовку к обязательному исполнению закона, и оно истекало. О том, что закон вступит в действие лишь в 2011, никто не знал, и бизнес, и госструктуры предполагали, что в ближайшее время придется работать долго и упорно, чтобы успеть.
Одним из первых, кто стал готовиться, было ведомство, которое курировало огромный пласт операторов персональных данных повышенного внимания — медицинские учреждения, которые оперируют данными о здоровье пациентов, поэтому и внимание к таким важным сведениям повышенное. Для краткости буду называть их ЛПУ – лечебно-профилактические учреждения.
Поскольку в ЛПУ слабо развиты ИТ, не говоря уже об информационной безопасности, решили для всех медучреждений создать стандарт по защите персональных данных, которым могли бы пользоваться люди, далекие от безопасности и ИТ.
Большинство руководящих документов по защите персональных данных были недоступны широкому кругу лиц (действовало так называемое «четверокнижие» с грифом «Для служебного пользования», которое могли запросить только лицензиаты), поэтому вариант с созданием подробных методических рекомендаций был оптимальным.
В 2009 году я занимался информационной безопасностью всего три года и был на уровне опытного джуниора. Мог похвастаться парой проектов по персональным данным (что в то время было большим опытом, т.к. очень сложно убедить заказчика выполнять необязательные требования) и находился в жесткой схватке с одним крупным НИИ. Конечно, работа по созданию стандарта досталась мне.
Неделя до дня X
За неделю до начала работ я обсуждал с руководством предстоящую задачу и планировалось, что ее будет делать другой специалист, но в итоге бороться с ней пришлось мне. Будучи молодым, я действовал по принципу «слабоумие и отвага», и именно этот принцип сыграл ключевую роль во всей работе. Впрочем, это свойственно всем специалистам на определенном этапе карьеры.
Как проявилась в проекте моя отвага? Такую масштабную задачу мне пришлось решать исключительно своими силами – это напоминало атаку «с шашками на танки».
Уже значительно позже я участвовал в пяти схожих проектах, возглавляя группы от 2 до 6 человек. Теперь с уверенностью могу сказать: оптимальное количество людей для аналогичной задачи – 2 человека, не считая привлекаемых специалистов, вроде технических писателей. А всего в команде должно работать человек пять (2 аналитика, технический писатель, консультант и менеджер проекта). На моей памяти есть случай, когда команда из пяти человек делала подобную работу 9 месяцев.
Слабоумие же заключалось в указанных мною сроках работы – 10 дней, которые вместо рабочих стали календарными. Недооценка сложности чуть не стала роковой. В этот раз отвага победила, но путь был труден.
1-3 день работы
Поскольку ничего подобного я раньше не делал, решил воспользоваться имеющимися методиками создания документов. Вспомнив самый масштабный документ, который я написал к тому моменту – мой диплом, я решил начать с начала и закончить в конце.
Первым документом были «Методические рекомендации по составлению Частной модели угроз безопасности персональных данных». (Кстати, все документы можно найти в Интернете). С моделями угроз я работал больше всего, и эта задача была самой понятной. Это было первой ошибкой.
Если не вдаваться в подробности, мне необходимо было описать три последовательные стадии защиты персональных данных:
- проведение обследования,
- составление модели угроз,
- создание комплекта организационно-регламентирующих документов.
Разумеется, я начал описывать с середины, что вылилось в большие проблемы на 7-10 дней.
Второй ошибкой было использование последовательного принципа написания документов. Это когда сначала титульный лист, потом оглавление, список сокращений, вводная часть и т.п. Это не работает, в определенный момент вы обязательно встанете в «креативный тупик», чаще всего он наступает на 3-5 разделе, когда вам понятно, откуда вы вышли и куда хотите прийти, но не понятно как.
Забавно получилось с сокращениями, которые сразу же были сделаны. Чтобы была хоть какая-то преемственность с текущей нормативной базой, я скопировал сокращения из документов регулятора, и там осталось сокращение «ТКУИ – технические каналы утечки информации», которое в тексте нигде не встречается.
Лайфхак: чтобы сделать список сокращений актуальным, во время написания применяйте три простых действия:
- Как только вам потребуется сделать сокращение, пишите в формате «(далее – )». Например, обязательное сокращение в тексте (далее – ОСТ).
- Держите открытым отдельный файл Exсel, куда заносите все сокращения (можно без расшифровки).
- Когда текст будет написан, ранжируете в экселе перечень от А до Я и смотрите количество, а в тексте поиском ищете вхождение «(далее – )». Если числа совпали, поздравляю – у вас актуальный перечень сокращений.
Работая с сокращениями, не используйте больше трёх букв. Все отличное от этого выглядит ужасно и плохо запоминается. По крайней мере, в безопасности, где, как и в армии, верховодит всем ТБС.
Результат: 1 файл объемом 20 страниц и несколько табличек в Exсel.
4-6 день работы
После первых дней спокойного режима пришлось окунуться в бассейн кофеина и никотина (сейчас то я, конечно, за ЗОЖ). Во-первых, была сделана здравая работа – прочитано техническое задание. В принципе и раньше было понятно, что необходимо делать, но важны были детали.
Ключевыми словами были «методические рекомендации», т.е. последовательность действий для людей, слабо знакомых с предметом. Это будет либо главный врач ЛПУ, либо секретарь. Поэтому я решил, что нужно описывать все возможные варианты, чтобы пользователь не имел права на неопределенность: либо красное, либо зеленое, либо теплое, либо мягкое.
В этот момент я работал над моделью угроз и сразу сделал таблицы для всех возможных типов информационных систем (их у меня было 10), написал угрозы и делал другие непонятные вещи, интересные лишь в контексте защиты персональных данных.
После указания названий угроз в табличке стало понятно, что где-то должно быть общее описание самих угроз, затем – что наши 10 видов информационных систем тоже неплохо где-то описать. Так, двигаясь шаг за шагом, наполнял документ.
В процессе работы пришел к принципу «обратного движения», когда в начале пишется результат, являющийся сутью и целью документа, а потом итеративно все, что должно к нему привести.
В общем случае:
- результат;
- методика достижения результата;
- описание.
Принцип оказался довольно живуч. С помощью него можно писать отчеты, начав с выводов, или политики информационной безопасности, начав с основных мероприятий.
Уже гораздо позже я дополнил этот метод концепцией «улучшенного JPEG», которая говорит, что работа в зависимости от срока всегда должна быть готова на 100%, разница лишь в степени детализации. Если кто застал времена небыстрого интернета, то обычный JPG отображался по мере загрузки (тот самый последовательный способ написания документов) сверху вниз, а картинку JPEG загружал всю целиком и улучшал ее четкость.
Одна беда – применение концепции «улучшенного JPEG» в лоб не работает для сложных документов (по крайне мере у меня). При прямом применении вы в новом документе создаете разделы и пишите, о чем они, расширяя описание по мере проработки. В стандартах и хитрых методиках это не работает, с чем я столкнулся на следующем этапе.
Дело в том, что нельзя все предусмотреть заранее. Концепция изложения может несколько раз меняться в процессе, причем меняться кардинально. Поэтому, если наполнять документ чем-то большим, чем заголовки (например, давать пояснения и т.п.), то в итоге вы придете к тому, что надо не просто переставить несколько предложений местами (те самые заголовки), а править, расчленять и дополнять те самые пояснения. Поверьте, это очень муторно.
Поскольку методические рекомендации, описывающие все возможные исходы однотипны, они должны совпадать по структуре и логике описания. Странно же будет выглядеть, если в одном типе будет структура системы, а в другом – нет. И вообще, если у пользователя будет два типа информационных систем, у него меньше возможности запутаться в одинаковых по структуре описаниях.
Сказано – сделано. Я взял самое подробное описание, которое у меня было, для системы, которая включала всё (в моём случае распределенная информационная система II типа), и копипастнул на другие типы. Я рассудил, что удалить лишние (а другие типы систем были подмножеством распределенной ИС II типа) проще, чем дописывать. Разумеется, это оказалось не так. Пришлось не только удалять лишнее, но и дописывать особенности конкретного типа. В итоге на проверку, перепроверку и отлов противоречий ушла уйма времени. В последующих работах я стал действовать ровно наоборот – описывать минимально необходимое, добавляя специфику.
На создание модели угроз ушло 5 дней, и я приступил ко второму документу.
Наученный горьким опытом, в первую очередь создал приложения, которые пользователи должны будут под себя заполнять, а потом приступил к описанию, как это заполнение организовать.
Результат – готовая методика по моделям угроз плюс половина приложений.
7-9 день работы
Это было время эйфории, план в голове сложился, осталась чисто механическая работа – только и делай, что добавляй приложения и описывай грамотно. Беда пришла откуда не ждали, даже две.
На оформление и переоформление кучи документов я убил значительную часть времени. Хотелось все сделать красиво, поэтому я сразу проставлял еще и внутренние ссылки на разделы и внешние файлы. Разумеется, как только возникала необходимость в корректировках (приложение новое вставить, документ переписать и т.п.), все это влекло за собой переделку всего оформления.
Не помню, о чем я тогда думал, но мне казалось это таким важным, что после каждого структурного изменения я занимался оформлением и перестановкой ссылок. Наверно, мне казалось, что вот это-то изменение точно будет последним, сейчас быстро переделаю и пойду другим заниматься.
С приобретением опыта я стал делать цветные заглушки. Ссылка на раздел 4, приложение 5 (отследить номер) и т.д.
Второй бедой стала терминология. Согласование терминов и определений по всем документам отняло много времени. Постоянно приходилось рыскать по страницам для уточнения той или иной формулировки (я делал все на одном мониторе, и, поверьте, это было нелегко). Это неизбежное зло, постепенно ваш словарный запас пополнит соответствующей тяжести канцелярит, и большинство определений у вас будут согласованными.
На девятый день работы все было готово – два файла рекомендаций с приложениями. Оставалось доделать мелочи.
10 день работы
Доделав мелочи, я решил перечитать все еще раз – поправить ошибки, отловить мелкие косяки и т.п. И тут мне захотелось сделать свою работу еще лучше, чтобы было понятнее. Решил отразить в описании угроз информацию из итоговых таблиц (все эти «реализация угрозы является маловероятной»). Зачем? Почему? Вот, захотелось.
Я начал добавлять, одно стало цеплять за собой другое, а тут результирующие таблицы неплохо бы поправить… Казалось, стало более красиво, но задача вычитки была полностью провалена. Поэтому не стремитесь к совершенству, что-то улучшать можно бесконечно, но вряд ли это кто-нибудь оценит.
А на вычитку время и силы надо обязательно оставить. Именно поэтому оптимальное количество человек в команде – два. Больше не стоит. Когда через полгода аналогичную задачу для образования решали пять человек, мы убили кучу времени на согласования, притирку частей, написанных разными людьми, общую терминологию, вычитку и т.п.
Если вы — титан мысли, то можете попробовать работать в одиночку. Но учтите, что когда напишите 500 000 знаков, у вас замылится глаз и будет казаться, что вы читаете одно, а по факту написано совершенно другое. Смешно и грустно.
Работу я сдал в срок и пошел спать. Уже потом надо было согласовывать документы с регулятором и править ошибки. В итоге данные рекомендации разошлись широко и отдельные части присутствуют в подавляющем большинстве комплектов документов по персональным данным. После я делал аналогичную работу для образования и атомной энергетики. Но это уже совсем другая история.
P.S. Краткая памятка для отважных
- Читай техническое задание.
- Не нарушай последовательность стадий работы.
- Внутри стадии двигайся от результата к методологии, а потом к определениям.
- Дополнять малое проще, чем сокращать большое.
- Занимайся оформлением в последнюю очередь.
- Ссылки внутри документа проставь на предпоследнем шаге.
- Удели время перепроверке.
Автор: DDudko
