Как сделать стандарт за 10 дней (авторская версия)

Как сделать стандарт за 10 дней (авторская версия)

Всем, привет. Хочу рассказать вам историю о том, как я делал методические рекомендации Минздрава. 500 страниц с нуля за 10 дней, сделанных ошибках и сложностях, которые не были преодолены. Надеюсь, мой опыт поможет всем, на кого свалилась задача написать руководящий документ, стандарт или закон.

Источник

Месяц до дня Х

2009 год в безопасности персональных данных, был годом предвкушения. Ходили упорные слухи, что 152-ФЗ «О персональных данных»., принятый в 2006 году вот-вот станет обязательным для исполнения. С момента принятия, рынку и операторам было дано время подготовиться к обязательному исполнению закона, и время подготовки истекало. 2010 год виделся годом большой работы, но закон вступил в окончательное действие лишь в 2011, но этого еще никто не знал (а потом еще пару лет не верили, что приняли)

Предвидя огромную организационную работу, многие ведомства решили начать готовиться заранее. Одним из первых было Минзравсоцразвитие (сейчас Министерство здравоохранения), которое курировало огромный пласт операторов персональных данных повышенного внимания (информация о здоровье) – медицинские учреждения (для краткости будем называть их ЛПУ – лечебно-профилактическое учреждение).

И т.к. в ЛПУ, ввиду очевидных причин, слабо развито ИТ, не говоря уже об информационной безопасности, то было принято решение создать для всех ЛПУ стандарт по защите персональных данных. Которым могли бы пользоваться люди далекие от безопасности и ИТ.

Т.к. в то время, большинство руководящих документов по защите персональных данных были недоступны широкому кругу лиц (действовало так называемое «четверокнижение» с грифом ДСП, которое могли запросить только лицензиаты), то вариант с созданием подробных методических рекомендаций был оптимальным.

Я же в 2009 году занимался информационной безопасностью 3 года, и был на уровне опытного джуниора. С багажом в пару проектов по персональным данным (что в то время было большим опытом, т.к. очень сложно убедить заказчика выполнять необязательные требования), в жесткой схватке с одним крупным НИИ, работа по созданию стандарта досталась мне.

Источник

Неделя до дня X

За неделю до начала работ, я обсуждал с руководством предстоящую задачу. Планировалось, что ее будет делать другой специалист, но в итоге она досталась мне. Надо упомянуть, что, будучи молодым, в профессиональном отношении, я действовал по принципу «слабоумие и отвага». Думаю, это свойственно всем специалистам на определенном этапе карьеры. И именно этот принцип сыграл ключевую роль во всей работе.

Забегая немного вперед, отвага заключалась в атаке «с шашками на танки» силами одного специалиста на такую масштабную работу. Уже значительно позже, я делал похожие работы возглавляя различные по численности группы (от 2 до 6 человек). И если уж говорить об оптимальной численности команды, то оптимальное количество людей 1-2 человека, не считая привлекаемых специалистов, вроде технических писателей. Из 5 подобных работы, 1-2 человека – это лучшее соотношение по производительности и достигаемому эффекту. Например, команда из 5 человек, подобную работу делала 9 месяцев.

Слабоумие же заключалось в указанных мною сроках работы (10 дней, которые вместо рабочих стали календарными), и не понимания всей широты проблем, которые могут возникнуть. Именно недооценка сложности, чуть не стала роковой. Но в этот раз отвага победила, но путь ее был труден.

Источник

1-3 день работы

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

Первым документом были « Методические рекомендации по составлению Частной модели угроз безопасности персональных данных при их обработке в информационных системах персональных данных учреждений здравоохранения, социальной сферы, труда и занятости ». (Кстати, все документы можно найти в Интернете ). С моделями угроз я работал больше всего, и эта задача была самой понятной. Это было первой ошибкой.

Если не вдаваться в подробности, мне необходимо было описать три последовательные стадии защиты персональных данных:

  1. проведение обследования,
  2. составление модели угроз,
  3. создание комплекта организационно-регламентирующих документов.

Разумеется, я начал описывать с середины, что вылилось в большие проблемы на 7-10 дней.

Второй ошибкой было использование последовательного принципа написания документов. Это когда сначала титульный лист, потом оглавление, список сокращений, вводная часть и т.п. Это не работает, в определенный момент вы обязательно встанете в «креативный тупик», чаще всего он наступает на 3-5 разделе, когда вам понятно, откуда вы вышли и куда хотите прийти, но не понятно как.

Забавно получилось с сокращениями, которые сразу же были сделаны. Чтобы была хоть какая-то преемственность с текущей нормативной базой, я скопировал сокращения из документов регулятора, и там осталось сокращение «ТКУИ – технические каналы утечки информации», которое в тексте нигде не встречается.

Лайфхак: чтобы сделать список сокращений актуальным, во время написания применяйте три простых действия:

  1. Как только вам потребуется сделать сокращение, пишите в формате «(далее – )». Например, обязательное сокращение в тексте (далее – ОСТ).
  2. Держите открытым отдельный файл Exсel, куда заносите все сокращения (можно без расшифровки).
  3. Когда текст будет написан, ранжируете в экселе перечень от А до Я и смотрите количество, а в тексте поиском ищете вхождение «(далее – )». Если числа совпали, поздравляю – у вас актуальный перечень сокращений.

 

Работая с сокращениями, не используйте больше трёх букв. Все отличное от этого выглядит ужасно и плохо запоминается. По крайней мере, в безопасности, где, как и в армии, верховодит всем ТБС.

Результат: 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. Краткая памятка для отважных

  1. Читай техническое задание.
  2. Не нарушай последовательность стадий работы.
  3. Внутри стадии двигайся от результата к методологии, а потом к определениям.
  4. Дополнять малое проще, чем сокращать большое.
  5. Занимайся оформлением в последнюю очередь.
  6. Ссылки внутри документа проставь на предпоследнем шаге.
  7. Удели время перепроверке.

Источник

P.S.S.

Вы прочитали неполиткорректную (авторскую) версию. Политкорректная версия размещена на Хабре .

Alt text

Если вам нравится играть в опасную игру, присоединитесь к нам - мы научим вас правилам!

Подписаться

Дмитрий Дудко

Смотреть глазами