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