Примеры и рекомендации удобных инструкций

    Снова здравствуй, уважаемый хабралюд!

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

    Всем, кому интересно, прошу под хабракат.


    KISS

    Принцип Keep It Simple Stupid хорошо известен в программировании, но почему-то его редко используют для написания инструкций и руководящих документов, предпочитая растекаться мыслею по древу. В 70% ситуаций эта документация необходима только для того, что бы отмахаться от наших бодрых регуляторов, но при этом забывают, что с этой документацией придётся работать, причём не всегда технически подкованным и грамотным в области информационной безопасности людям.

    Для начала напишу несколько правил, которые помогут создать рабочий и удобный документ:

    1. Старайтесь разделять инструкцию для пользователей от инструкции для администраторов и офицеров безопасности. причём первые не должны содержать ссылок на вторые (они могут содержать отсылки друг к другу).
    2. Делайте пошаговые инструкции, вида «взял и сделал». То есть инструкции должны описывать алгоритм действий того, на кого она направлена.
    3. Каждый пункт описывайте, как отдельное действие с обязательным указанием ответственного и контактами, если они необходимы.
    4. Для большей наглядности можете дополнительно нарисовать в инструкцию блок-схему действий. Это поможет пользователю наглядно понять и оценить действия, так же и вам доступно объяснить алгоритм при обучении.
    5. Психологический момент — инструкция будет плохо выполняться и работать, если пользователям понятно и доступно не объяснят алгоритм на пальцах и примерах. Поэтому — НЕ ЗАБЫВАЙТЕ ПРО ОБУЧЕНИЕ!

    Пример инструкции для пользователей

    Ниже приведен пример инструкции по заведению аккаунта пользователя в корпоративной сети.
    image

    Clear screen/clear desk

    Специфика российских организаций, работающих с советских времен и таких же умудренных опытом сотрудников такова, что у них, как правило, стол завален бумагами. Компьютер порой не выключается и не блокируется, даже когда уходят домой. Недавно лично видел, проходя поздно вечером мимо одного муниципального предприятия, как за открытыми жалюзи в закрытом на замок здании горел монитор с открытым на нём вордовским документом.
    Пользователи порой не догадываются о возможных непреднамеренных утечках информации. Пускай она не конфиденциальна, возможно она только для внутреннего пользования. Но это даёт понимание, что в этой организации не заботятся о своей безопасности и могут так поступить с конфиденциалкой. А так же возможно там будет информация, ещё не отнесенная к закрытой, но уже существующая во внутреннем обороте организации.

    Хорошим примером из лучших практик здесь является политики чистого стола и чистого экрана. Их можно описать так же, как я приводил пример ранее, но это будет выглядеть немного глупо, так как действия там простейшие. Лучше просто сделать набором правил:
    image

    На этом завершаю примеры и рекомендации. Серию подобных постов я продолжу, если будет интерес.

    P.S. В посте приведены скрины реально внедренных и работающих инструкции и политик. Все совпадения с существующими организациями случайны. Все названия отделов и бюро изменены.
    • +6
    • 44,5k
    • 4
    Поделиться публикацией

    Комментарии 4

      0
      У меня наконец-то дошли руки отписаться.
      Так вот. Я думаю, что писать статью про написание инструкций стоило с того, что бы представить общую структуру документации. То есть — головным документом, который пишется самым первым, и изменяется реже всего, является политика информационной безопасности. Дальше пишутся стандарты предприятия по информационной безопасности, регламенты, процедуры. Конкретный перечень зависит от того, какими стандартами руководствуется CISO. Инструкции, тем более — инструкции такого вида, являются документами нижнего уровня, которые пишутся в последнюю очередь.
      Кроме того, начать стоило с описания структуры самих инструкций — примеры текста — это хорошо, но не способствует пониманию того, что это вообще за документ. На пример, общая структура будет такой:
      1) Заинтересованный субъект (для кого написана инструкция);
      2) Основания для разработки (для исполнения каких стандартов (как государственных, так и стандартов компании) разработана данная инструкция);
      3) Область применения (в каких ситуация субъект будет руководствоваться данной инструкцией);
      4) Само тело инструкции (делай раз, делай два);
      5) Штрафные санкции за нарушение пунктов инструкции (с обоснованием применения той или иной санкции);
      6) Связанные документы (прочие инструкции для этого субъекта);
      7) Лист ознакомления.

      Эта структура приведена исключительно для примера, но, в принципе, она разумна и может применяться в реальной жизни.

      Вы взвалили на себя нелегкий труд — не хочу отбивать у вас охоту продолжать это дело, но к нему нужно подходить основательно, что бы не навредить. Многие используют статьи на хабре как руководство к действию — а плохо написанная инструкция может быть опасней ее отсутствия.
        0
        Ок, спасибо за коммент.
        Я пока начал, так сказать, с низко висящих яблок.
        Рекомендуемую структуру документации, дерево документов, работу с инцидентами я думал раскрыть попозже.
        Пока недостаточно времени, так как темы довольно объёмные.
        К тому же я начал именно с этой статьи, что бы донести понимание того, как вообще лучше всего описывать процесс в инструкции.
        Но спасибо за замечание, принял к сведению :-)
        0
        А продолжение?
          0
          Запара с работой жуткая была. Пока на больничном, постараюсь продолжить

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

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