Как сделать стандарт за 10 дней

    Приветствую всех! Я работаю в Департаменте информационной безопасности ЛАНИТ, руковожу отделом проектирования и внедрения. В этой статье я хочу поделиться опытом, как на старте карьеры совсем в другой компании подготовил стандарт для организации защиты персональных данных в медучреждениях. Это история о том, как написать 500 страниц с нуля за 10 дней, сделанных ошибках и сложностях, которые не были преодолены. Надеюсь, мой опыт поможет всем, на кого свалилась задача написать руководящий документ, стандарт или закон.

    Источник

    Месяц до дня Х


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

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

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

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

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

    Источник

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


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

    Как проявилась в проекте моя отвага? Такую масштабную задачу мне пришлось решать исключительно своими силами – это напоминало атаку «с шашками на танки».

    Уже значительно позже я участвовал в пяти схожих проектах, возглавляя группы от 2 до 6 человек. Теперь с уверенностью могу сказать: оптимальное количество людей для аналогичной задачи – 2 человека, не считая привлекаемых специалистов, вроде технических писателей. А всего в команде должно работать человек пять (2 аналитика, технический писатель, консультант и менеджер проекта). На моей памяти есть случай, когда команда из пяти человек делала подобную работу 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. Удели время перепроверке.

    Источник

    ГК ЛАНИТ

    288,00

    Ведущая многопрофильная группа ИТ-компаний в РФ

    Поделиться публикацией
    Комментарии 43
      +2

      Проблемы форматирования, стиля, глоссария, списка сокращений и перекрестных ссылок неплохо решаются в latex (правда могут появится совершенно новые и труднопреодолимые проблемы в самых простых местах).

        +2
        Да, инструмент хороший, но в 2009 я о нем не знал. Использую его для диссертации. Для более «простых» текстов он все же сложноват, особенно, когда команда большая. Обычно хватает Google Docs
          +2
          особенно, когда команда большая

          а вот тут на помощь латеху приходит гит.

            +1
            Да, но для большинства команд по написанию доков по ИБ, это избыточный функционал. Ни в одном крупном интеграторе такой связки не встречал. Наверно, когда-нибудь доберемся. В безопасность все приходит чуть медленнее :)
              0

              Кстати когда-то слышал, что для создания документации в авиации (а там сотни томов связанных документов) используют Adobe Framemaker.

        0
        Дубликат
          +1
          Пункты 5 и 6 в памятке для отважных при использовании LaTeX можно минимизировать или вообще сократить
            +2
            Да, но latex на выходе дает — конечный файл, и с ним происходит вся работа. Плюс к этому у него большой порог вхождения. Например, в нем сложно организовать процесс согласования с заказчиком, когда необходимо отослать исходник пользователю, который умеет работать только в Word и теряется без WISIWIG.
              +1

              Поскольку в вашем случае 99% документа — это обычный текст, может помочь конвертация TEX -> HTML -> DOCX.

                +1
                Скорее всего. Но, пока, никто не отважился на постоянную конвертацию tex<->docx. Docx берет своей распространенностью. А при конвертации появляется еще одна область неопределенности, требующая контроля, сам конвертер.
                +1
                Эти задачи довольно просто решаются и в Ворде несколькими кликами мыши и минимальным редактированием интуитивно понятных формул. Причем не возникает необходимости в изучении мануалов по синтаксису очередного уголкового языка.
              +1
              Вы, наверно, с деревом любите работать.)
                +2
                Тогда я и был «дубом» :) Сейчас, в такие-то сроки, не взялся бы.
                +2
                Скажите откуда первая фотка? Для чего он это делает?
                0
                На самом деле ничего особо нового вы не написали, все через это проходят. Просто конкретно в вашем случае относительно большой и сложный проект попал вам в руки ровно в тот момент, когда вы находились в самой верхней точке диаграммы Даннинга-Крюгера :)
                  +1
                  Возможно :) С высоты 2018 года все смотрится несколько проще, сейчас много материалов и треннигов. Но думаю, они больше применимы для «известных» задач. Например, в безопасности сейчас новая тема КИИ, думаю те, кто будут по ней писать, будут проходить все тот же путь.
                  +1

                  Так вот откудово растут ноги со всей этой чехардой вокруг персональных данных. Интересно закон Яровой тоже по этой методе делали?

                    0
                    Вы переоцениваете эти рекомендации :) Хотя с точки зрения безопасности, закон Яровой логичен. Правильный или нет, можно долго спорить, но что логичный это факт.
                      0
                      Я, конечно, тот ещё специалист по безопасности, но хранить 6 месяцев трафик, который, скорее всего никогда не получится расшифровать, и точно не получится в течении 6 месяцев -это так логично. Более логично может быть только вот это.
                      image
                        +1
                        Вопрос не в конкретике, а в принципе. Никого же не смущает СОРМ. Логично, что силовые ведомства стремятся к большему контролю, это и у нас, и на западе.

                        Я думаю, если бы смогли — то и в интернет пускали бы по биометрии пальцев.
                          +1
                          Это так, но что в этом логичного? Как это может повысить безопасность, что-бы вы под этим не понимали? СОРМ-это плохо, но это может быть полезно спецслужбам. Это адекватный объем информации, который поддаётся систематизации и анализу. Запись всего трафика, большая часть из которого шифрованая- стрельба из пушки по комарам. Причём из чужой пушки, по комарам в Африке. Даже если не надо покупать пушку-Вы не потянете цену снарядов.
                            +1
                            Иногда не нужно знать что было в снаряде, достаточно знать откуда эти снаряды выпущены и куда они упали.
                              +1
                              Да, иногда этого достаточно. Тут всегда надо решать дилемму про поезд и стрелку, думаю, тут нет правильных и не правильных решений.
                                0
                                Lbh ner evtug!
                              +1
                              Логично, что они хотят больше контроля. Как я и говорил, о реализации можно много копий сломать. Например, следующим шагом может быть копия всех ssl ключей.

                              Вопрос ведь не в объеме данных, а в том, что они должны быть все. Иначе у них ничего не заработает в будущем. Это не хорошо и не плохо, это так есть. Как безопасник, я их понимаю.
                                0
                                Ок, Вы безопасник, имеете все права в своей компании, Вы копируете и храните весь трафик всех пользователей? Знаете кого-то, кто копирует и хранит. Очень сомневаюсь.
                                Блин, если да, то я ничего не понимаю не только в безопасности, но и в безопасниках.
                                  +1
                                  Если мне позволяет бюджет, я бы это делал. Те кто может себе это позволить, с большой долей вероятности, делают это, если у них такие задачи.

                                  Например, есть такой класс решений, как DLP — так у них по умолчанию теневое копирование всех действий пользователя, а это посерьезней, чем просто трафик.
                                    –1
                                    Про бюджет, я неспроста там приплёл снаряды. Там не только оборудование и лицензии. Если у вас в компании n сотрудников, то требуется отдел безопасности в составе n/3, ну или n/5, если Вы прям такой доверчивый. В противном случае, Вы выбросили деньги, потраченные на оборудование и лицензии. Когда сотрудников 200-ну ок, когда 2000-это «егей», а когда 146 миллионов-это«да п-дц».
                                    И Вам конечно видней, но мне кажется, что у Вас уже наступила IT-безопасность головного мозга. Не хотел вас обидеть, просто констатирую проф. деформацию.
                                      +1
                                      Обычно штат безопасников n/100 или n/1000, сейчас безопасники не просматривают все глазами.

                                      Профдеформация есть во всех профессиях, я не исключение :) у вас она тоже есть, как я понимаю, вы работаете в сфере ИТ, а там сложно относятся к попыткам контроля :)

                                      Давайте остановимся на том, что безопасники хотят все контролировать, это их суть. Плохо этот, или хорошо — сложный вопрос. когда-то это хорошо, когда-то плохо.
                                      –1
                                      Я прочитал про DLP, там один из методов-это анализ трафика, а не его глобальная запись и хранение. А это как раз СОРМ и его продвинутый вариант-«Золотой щит». Даже в теории безопасники не могли себе представить «пакет Яровой», пока какой-то отставной гэбист, не умеющий в интернет, не сказал «да ладно, это-ж Россия, прокатит»
                                        +1
                                        Как вы верно сказали, один из методов. Вы уже дальше пошли в политику, а это неблагодарная тема для обсуждения.
                            0

                            В чем же логика?

                              +1
                              Логично, что силовики хотят больше контроля.
                                0

                                Логично

                          +2
                          Для любого проекта, после его тщательного изучения и выведения сроков, последние нужно умножать на два. Всегда.
                          Так вы и себя подстрахуете, и порадуете заказчика «досрочной сдачей» если всё пойдёт хорошо. )))
                            +1
                            Разумеется, я после этого еще и на 1,1 умножаю :)
                              0
                              последние нужно умножать на два
                              А как же переход к бОльшей единице измерения?
                              0
                              500 страниц?! Не слишком ли «много буков»? Думаете это реально прочесть, усвоить и выполнять сотрудникам в медучреждениях, для которых это не единственная работа, и на которых такие бумаги с буреломом из канцелярита спускают регулярно? Методичкой в 10-20 страниц точно нельзя было ограничиться?
                                +1
                                Нереально. Например, в образовании я потом два года еще занимался обучением. А эти рекомендации 3 года поддерживали по телефону и почте.
                                500 страниц написал не от хорошей жизни. Не было плана написать много, была задача расписать шаги.

                                Если убрать множественные определения и объяснения «почему так», думаю можно было бы уложиться страниц в 300. Но наши люди пытливые, если написано делай так, обязательно спросят почему. В образовании потом регулярно спрашивали.
                                  +1
                                  Ну это же не оглавление 500 страниц. А досконально знать и не нужно, нужно обращаться по мере необходимости. Главное быстро находить по оглавлению.
                                    +2
                                    Это тоже самое как с законодательством разбираться — не нужно знать все законодательство, оно постоянно меняется. Нужно знать где быстро находить. Благо всё структурировано.
                                  0
                                  Спасибо, интересный опыт.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое