Сегодня я хотел бы рассказать о проекте по внедрению системы защиты конфиденциальной информации на 5600 автоматизированных рабочих мест. Этот кейс мы реализовали в прошлом году. Он вобрал в себя множество типовых и уникальных проблем, которые могут возникнуть при внедрении в больших организациях. «Очень больших» — намекает картинка.

Источник

Характеристика объекта внедрения

Крупный военный завод. К сожалению, военные заводы не любят, когда распространяются об их деятельности в области безопасности и на каждом шагу упоминают их названия. Поэтому будем для лаконичности называть объект внедрения просто – военный завод.

На заводе работают порядка 16 000 человек на 5600 автоматизированных рабочих местах (АРМах). Инфраструктура расположена в двух ЦОДах плюс в мобильном ЦОДе. Итого 119 объектов/отделов на 15 площадках.

Состав внедряемых подсистем:

• СЗИ от НСД плюс централизованное управление;
• платы СДЗ плюс централизованное управление;
• межсетевые экраны;
• VPN-шлюзы;
• система обнаружения вторжений;
• анализ защищенности;
• USB-токены;
• SIEM-система;
• антивирусная защита.

Вендоров называть не буду, чтобы не сочли за рекламу. Лучше расскажу про сроки. Начало работ — 15 июля 2019 года, окончание — 27 декабря 2019 года.

Специфика ИБ-внедрений

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

Но сложность ИБ-проектов кроется как раз в той самой нормативной базе. Когда требование есть, но реализовать его невозможно, во всяком случае в рамках текущего времени и бюджета. В противном случае или это требует изменения такого количества процессов в производстве, что вы даже не захотите начинать об этом думать. 

В рамках данного проекта мы должны были выполнить (сокращенный перечень):

• постановление Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»;
• приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»;
• приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»;
• приказ ФСТЭК России от 28.02.2017 № 31 «Об утверждении Требований к обеспечению защиты информации, содержащейся в информационных системах управления производством, используемых организациями оборонно-промышленного комплекса»;
• приказ ФСТЭК России от 29.05.2009 № 191 «Об утверждении Положения по защите информации при использовании оборудования с числовым программным управлением, предназначенного для обработки информации ограниченного доступа, не содержащей сведений, составляющих государственную тайну»;
• приказ ФСБ России от 10.07.2014 № 378 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности».

Не вдаваясь в подробности конкретных положений, те, кто с ними сталкивался, думаю, могут представить конкретные проблемы реализации. Однако хотелось бы заострить внимание на следующих моментах.

• Система защиты должна была быть аттестована, а потом проверена регуляторами, что очевидным образом максимально повышает приоритет задаче: неукоснительное выполнение требований.
• Требования прописаны в государственном контракте, и несмотря на то, что в данном списке есть неприменимые к заводу нормативно-правовые акты (НПА), их требования необходимо выполнять. 
• Некоторые НПА предъявляют разные требования к одним и тем же элементам, а следовательно реализовывать их надо будет все. Т.е., если один НПА предъявляет минимальные требования, а другой – повышенные, реализовывать надо будет по максимуму.
• В информационной безопасности, к сожалению, небольшой перечень решений, которые можно было бы применить. Так что если средство защиты не подходит к конкретной ИТ-архитектуре, то заменить его очень сложно, тем более в рамках четкого ТЗ по 44-ФЗ.
• При отсутствии технической возможности выполнения требований, можно применить организационные мероприятия. Но это потребует огромного количества согласований и может растянуться на годы в такой огромной организации, как военный завод. А срок исполнения проекта ограничен.

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

1. Четкие этапы внедрения новых мер.
2. Сроки данных этапов.
3. Ответственных за выполнение плана.
4. Обязательное обучение сотрудников и ответственных.
5. Быть принятым на уровне организации.

Источник

Чужой проект

Так случилось, что данный проект изначально вел другой интегратор. В течение трёх лет по всем правилам был проведен аудит и техническое проектирование. В начале 2019 года завод готов был заключить договор с единственным поставщиком на работы по внедрению, но… интегратор ушел, что называется, «в несознанку». Он перестал отвечать на письма и звонки, а когда все же удалось с ним связаться, ответил, что данный проект его не интересует.

Это породило две проблемы – в проекте была чужая спецификация, и сроки уже начали поджимать.

Чужая спецификация

Чужая спецификация в информационной безопасности — не такая уж и большая проблема. Как уже упоминалось, на рынке средств защиты информации круг решений скромный, и от большинства знаешь, чего ожидать.

Проблема крылась в другом: за строчкой в спецификации – 5600 СДЗ —  может скрываться внедрение на одной площадке, а может и по всей области (в итоге площадок оказалось 15). В данной строке не виден парк конечных станций, их распределение и готовность к внедрению.

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

В этот момент стало понятно, что, если и ввязываться в данный проект, то необходимо провести минимум рекогносцировку на местности. Так как изначальный проект можно изучить только на месте, мы сформировали команду из четырёх человек, усилились представителями вендоров и выехали на объект.

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

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

Время внедрения

В связи с отказом от выполнения работ предыдущего поставщика сильно сократился срок внедрения. Первоначально планировалось все реализовать за 12 месяцев, но т.к. пришлось организовывать конкурс, его отыгрывать, проводить пресейльные мероприятия, согласовать и организовать подписание договора по 44-ФЗ с казначейским сопровождением, в чистом остатке на внедрение у нас оставалось менее 6 месяцев.

В принципе, этот срок был уже на грани возможностей. Камнем преткновения стала установка 5600 плат СДЗ (средство доверенной загрузки, которое защищает рабочую станцию на этапе загрузки BIOS). Каждая плата должна быть установлена в компьютер путем нехитрых манипуляций: прийти на место, выгнать пользователя, снять крышку корпуса, вставить плату, загрузиться, протестировать плату, провести настройку, завинтить крышку, отдать компьютер пользователю.

В идеале, это занимает 15 минут. При планировании же мы ориентировались на час работы. Итого 5600 трудо-часов. Применив нехитрые статистические методы, стало ясно, что на эту работу потребуется минимум 10 человек. Собственно, на этом работу можно было бы и закончить. Ни один интегратор в здравом уме не отправил бы 10 инженеров в командировку из Москвы на 3 месяца крутить компьютеры. Во-первых, это очень дорого и накладно, а, во-вторых, это верный способ этих инженеров потерять.

Выручило нас то, что у ЛАНИТ в данном регионе есть ресурсный центр (у нас их несколько по России), который плотно взаимодействует с региональными вузами. В этот момент у них начался очередной раунд стажировки студентов. Договорившись с коллегами, обеспечив транспорт, питание и контроль над молодыми специалистами, мы получили 15 стажеров на внедрение плат.

15 июля 2019 года ГИП, руководитель проекта, три аналитика и три инженера из Москвы, 15 студентов-стажеров, руководитель ресурсного центра, его заместитель, бригадир стажеров и два представителя вендоров зашли на завод, чтобы начать работу.

Сложности согласования

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

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

Бывают сложности и внутри проекта. Это уже второй пример. Когда мы подписали договор и начали работы, все резко осознали, что в спецификацию надо внести изменения из-за того, что требуемые серверы не успеют прийти вовремя. Сразу же эти изменения обговорили и потом четыре месяца согласовывали их в спецификации внутри команды проекта со стороны заказчика, так как любые решения у нас должны пройти стадию тестирования. Этот процесс мы не можем завершить, так как нет серверов. Серверы не можем заказать, так как заложенные не успеют прийти, а планируемые никто не будет заказывать без изменения спецификации. Круг замкнулся.

В таких случаях надо переходить сразу к пятой стадии – принятие. И, конечно, хорошо бы знать особенности своих заказчиков, чтобы быть готовыми к подобным поворотам и играть на опережение. Заранее официальными письмами все согласовывать.

Источник

Сложности коммуникации

В заключение хотелось бы осветить типовую, но не менее болезненную тему – коммуникации. Если внутри своей компании исполнитель может договориться и прийти к единой точке зрения, то проблемы с общением внутри заказчика встают наиболее остро. В нашем случае в команде проекта со стороны завода было три подразделения: айтишники, ИБ-специалисты и отдел технической защиты информации (ТЗИ). 

По всем ключевым вопросам общение делилось на три стадии.

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

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

Способов закрепления договоренностей немного (в порядке убывания).

1. Протокол рабочей группы с подписями участников (за полгода я подписал их десятки).
2. Официальное письмо заказчика. Часто, чтобы что-то двинулось, надо, чтобы заказчик послал соответствующий запрос или требование. Разумеется, это письмо будете писать вы.
3. Официальное письмо исполнителя. Если нет ничего лучше, пишите официальные письма. Проблема данного способа в том, что письмо совершенно спокойно может потеряться в канцелярии или у секретарей. У нас однажды 15 коробок с платами потерялось на проходной, что уж говорить о листе бумаги.
4. Проектная документация. Иногда при понимании всех причастных можно требуемое прописать в утверждаемых документах. Мол, оно всегда там было.
5. Письмо электронной почтой. В крайнем случае фиксируйте все в электронной переписке. В случае чего вы сможете сослаться на то, что информировали заказчика. Хотя шансов немного.

Это лишь малая часть проблем, с которой мы столкнулись. Несмотря ни на что, проект был нами сдан вовремя и уже прошел несколько проверок. Заказчик остался доволен, и мы продолжили с ним сотрудничество.

А на сегодня все, до новых встреч.

P.S. Оригинал статьи.

Управление риском в широком смысле слова, и рисками информационной безопасности в частности, – это то, чем мы с вами занимаемся каждый день. Зачастую это происходит неосознанно, на автомате, однако, тем не менее, дает реальные результаты. Конечный результат управления риском – предотвращение ущерба объекту риска: вам, вашей семье, вашей компании, отдельным процессам, отрасли или государству в целом.

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

Можно украсть информацию о вашей производственной деятельности: закупочные цены, если вы что-то продаете, ноу-хау и секреты, если что-то производите. Даже ваши планы закупок могут представлять интерес.

Можно украсть персональные данные сотрудников и клиентов – их можно продать или оформить множество потребительских кредитов.

Можно получить доступ к банк-клиенту.

Можно воровать вычислительные мощности на ваших серверах, например, чтобы майнить биткоины, разместить там свой сервер или просто рассылать спам.

Можно просто воровать ваш интернет.

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

Заранее посчитанные риски

Классическое определение риска гласит:

Риск (от лат. resecō — «отсекать», «сокращать» или др.-греч. ῥιζικόν — «опасность») — сочетание вероятности и последствий наступления неблагоприятных событий.

А его формулу записывают так: Величина риска = вероятность события * размер ущерба

Вероятность в данном случае – вещь сугубо субъективная. Мы склонны перестраховываться, не понимая, что перед нами лишь иллюзия опасности. Причина этому уходит корнями глубоко в древность, а точнее к тем инстинктам, что принимают камень за льва. Здесь не страшно ошибиться и обознаться, однако эта ошибка дает шанс убежать от реального льва. Поэтому в первом приближении будем рассматривать риски лишь с точки зрения ущерба.

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

Или еще пример: известный расчет риска гибели в процессе авиапутешествия. Вероятность того, что пассажир, севший в самолет, погибнет в авиакатастрофе, составляет примерно 1/8 000 000. Таким образом, если пассажир будет садиться каждый день на случайный рейс, ему понадобится 21 000 лет, чтобы погибнуть.

Далее мы не будем рассматривать заранее известные и просчитанные риски, т.к. это не принесет практической пользы.

Инвентаризация рисков

Все основополагающие понятия в управлении риском мы повторили. Теперь же приступим к определению первого этапа – инвентаризации, или, если вы впервые выявляете риски, идентификации рисков. Чтобы не запутаться: выявляете риски первый раз для любого объекта – производите идентификацию рисков, все последующие работы по выявлению и пересмотру – инвентаризация рисков.

Идентификация рисков – это процесс (бесконечный процесс) определения факторов, событий, ситуаций, которые могут нанести ущерб.

Для успешной идентификации риска достаточно ответить на три простых вопроса:

1. Какой будет ущерб?
2. Какое событие/действие должно произойти, чтобы мы понесли ущерб?
3. В отношении какого объекта должно произойти событие, чтобы мы понесли ущерб?

Вы могли заметить, что вопросы выражают обратную последовательность действий: ущерб <- действие <- объект. Этот способ используется для простоты. Когда вы станете опытнее, сможете использовать прямую схему: объект -> действие -> ущерб.

Объект риска

Объектом ущерба может выступать:

• компания или ее часть;
• бизнес-процесс;
• информационная система;
• банк данных или информация;
• инфраструктура;
• человек и т. д.

Объектом может быть вообще любой предмет, материальный или нематериальный актив, негативные действия по отношению к которому принесут ущерб.

Действие риска

Действия над объектом – перечень негативных операций над объектом, которые приводят к ущербу. К общим негативным операциям можно отнести кражу объекта или его части, повреждение или уничтожение, разглашение, несанкционированное использование и так далее.

В информационной безопасности выделяют следующие действия.

1. Нарушение конфиденциальности – мы получаем ущерб от того, что что-то стало известно. Например, наша секретная формула стала известна конкурентам.
2. Нарушение целостности – мы получаем ущерб от того, что наши данные неполны и/или изменены. Например, компьютерный вирус поменял все 0 на 9 в бухгалтерском отчете, что на один порядок увеличило налоговые выплаты.
3. Нарушение доступности – мы получаем ущерб от того, что в определенный момент не получили доступ к нужной информации или услуге. Например, у нас не было доступа в интернет, чтобы выиграть очень важный аукцион, или мы вовремя не ответили на запрос контролирующих органов, потому что у нас свет отключили.

Источник действия – нарушитель

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

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

• финансовый интерес;
• межличностные интересы;
• доминантность.

К первой категории относится 95% потенциальных нарушений. Мир преступлений (а особенно киберпреступлений) изменился в прагматическую сторону, если из определенного действия нельзя извлечь материальную выгоду, то найдется очень мало желающих этим заниматься.

Ко второй категории относятся все случаи слежки, например, чтобы добиться внимания женщины или отомстить обидчику.

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

Теперь вы можете записать каждый риск примерно в таком виде:

Ущерб от риска

В завершение мы должны оценить ущерб. Оценку нужно производить в деньгах. В третьей строке таблицы мы описали риск увольнения директора по ИТ и ИБ. Это будет не только личной трагедией для топ-менеджеров, но и принесет ущерб компании, которой, как минимум, придется искать новых сотрудников.

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

Методы инвентаризации рисков

Существует два больших множества методов инвентаризации рисков. Первое множество –отраслевые, или стандартизированные, методы.

Во многих отраслях и направлениях уже сформированы базы рисков, которые могут быть отнесены к тем или иным объектам. Например, в информационной безопасности можно воспользоваться Банком данных угроз безопасности информации ФСТЭК России. Каждый риск (угроза) имеет описание: объект, источник угрозы (нарушитель), описание (действие), последствия реализации угрозы (ущерб).

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

Методик и стандартов определения рисков информационной безопасности достаточно. Если вы захотите лучше разбираться в рисках, то можно рекомендовать серию стандартов ISO 2700x, полностью посвященных рискам и риск-менеджменту.

Второе множество методов идентификации рисков я называю «рабоче-крестьянскими» – они являются родственными методам «что если?» (самым ярким представителем которых является методология SWIFT). Данные методы требуют больше времени для определения рисков, но лишены недостатков стандартизированных методов, т.к. учитывают особенности конкретного объекта.

Заключение

После проведения инвентаризации рисков, вам потребуется оценить последствия (ущерб) и выработать защитные меры от рисков. По отношению к выявленным рискам возможны следующие защитные действия:

• ликвидация риска (например, за счет устранения причины);
• уменьшение риска (например, за счет использования дополнительных защитных средств);
• принятие риска (и выработка плана действия в соответствующих условиях);
• переадресация риска (например, путем заключения страхового соглашения).

Этап инвентаризации рисков является ключевым для любого вида деятельности, чем больше рисков вы предусмотрите, тем менее разрушительными будут последствия от свершившихся рисков. Желаю вам, что бы вас не касались риски с катастрофическими последствиями.

3 декабря 2018 года, для журнала Connect WIT 2018 № 11-12

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

Слишком долгое вступление в тему

Любой живой язык прекрасен в своих нюансах. А русский язык прекрасен вдвойне. Имея такой мощный базис, русский канцелярит (так я называю язык, на котором пишутся законы, постановления правительства и другие официальные бумаги) пленит своими возможностями. Разумеется, если вы не пытаетесь его читать.  Если нет возможности этого избежать, то читать канцелярит надо вдумчиво и размеренно, несколько раз перечитывая, вникая в каждое слово.

Шел 2008 год – лето, пятница. Я отпросился пораньше с работы, чтобы не стоять в пробках, и ехал на дачу по Дмитровскому шоссе в районе Яхромы. Было довольно плотненько, но терпимо. Меня останавливает инспектор ГИБДД, просит документы и заявляет, что я не пропустил пешехода. Я с ним не соглашаюсь.

Тогда инспектор предлагает подписать мне постановление и говорит, что у меня будет 10 дней на обжалование. Ну, уже неплохо. Я подписываю бумагу и еду дальше по своим делам. Оказалось, что инспектор воспользовался моим незнанием.
 

Протокол? Какой протокол?

На суде выяснилось, что я подписал не протокол, а постановление.

В случае, если представитель власти увидел признаки административного правонарушения (например, правил дорожного движения), он должен составить протокол. В протоколе вы можете написать, что не согласны с замечаниями, а вот в постановлении такой графы нет. Т.е. подписывая постановление, я фактически признал свою вину. Да, у вас есть 10 дней, чтобы обжаловать постановление. Но шансов практически нет. Таким образом, протокол – лишь фиксация нарушения, а постановление – уже назначенное наказание.

Казалось бы, две какие-то бумажки, а какие разные последствия.

Документы для информационной безопасности

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

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

Западная школа

Западная школа довольно свободно относится к названиям и содержанию документов. Самым ярким доказательством является серия стандартов – ISO 2700x, которую знает каждый безопасник.

В общем случае вся документация делится на четыре уровня.

• Политики первого уровня – наиболее «водянистые» и «стратегические». Например, «Политика информационной безопасности ООО «Ромашка».
• Политики второго уровня – конкретизируют определённые аспекты глобальной политики или конкретные процедуры. Например, «Политика антивирусной защиты».
• Инструкции (третий уровень) – описывают конкретные обязанности сотрудников в рамках политики 2 уровня, например, «Инструкция системного администратора по антивирусной защите сегмента КСПД».
• Записи (четвертый уровень) – все то, что не вошло в предыдущие три уровня. От настроек на конкретном сегменте до разбора инцидентов SIEM-системы.

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

Обратимся же к отечественному опыту.

Отечественная школа

Имея такую впечатляющую историю и опыт поколений в разработке конструкторской документации (ЕСКД), было бы удивительно, если бы у нас не сложились свои традиции и понимание оформления документов. Если внимательно посмотреть тот же ГОСТ 34 серии, то можно с удивлением узнать, что он вполне логичен и даже удобен. Разве перед внедрением любой системы вы не разрабатываете верхнеуровневую структуру (эскизный проект), уточняя его все детальнее и детальнее (технический проект и рабочая документация)?

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

Но здесь вас может поджидать проблема. Как вы думаете, чем отличаются:

1. Политика информационной безопасности,
2. Регламент информационной безопасности,
3. Положение об информационной безопасности?

Именно этот вопрос поставил меня в тупик, когда я перешел к этапу составления комплекта организационно-распорядительной документации (ОРД). Давайте же разберемся.
 

Как вы лодку назовете, так она и поплывет

Остановимся на основных документах (если будем рассматривать все – это будет совсем нудно и неинтересно). Описанный ниже подход является основным в работе Департамента информационной безопасности в одном из подразделений ЛАНИТ.
 

Приказ

Альфа и омега любого процесса, который вы захотите перенести на бумагу. В отличие от западного подхода, где достаточно просто утверждения уполномоченными лицами, у нас все документы вводятся приказом. Вы можете использовать в работе какие угодно инструкции и формы, но если они не введены приказом, считайте, что их у вас нет.

Это, кстати, особенно актуально для защиты персональных данных. Любая проверка регуляторов начинается с установления факта правоприменимости принятых мер. Если вы занимаетесь каким-нибудь документом, то вам, скорее всего, и готовить проект приказа.

Основными отличительными чертами Приказа являются следующие:

1. Вводится в действие генеральным директором, именно он имеет право распространять те или иные требования на всю организацию.
2. Наличие команды. Например, внедрить политику информационной безопасности.
3. Назначение ответственного. В приказе должен быть указан ответственный за выполнение сути приказа, например, в случае политики – директор по ИБ.
4. Наличие сроков. Тут все очевидно. Например, доведение до сведения всех сотрудников Политики ИБ в течение 2-х дней.
5. Наличие контролирующего. Эту часть часто забывают, но крайне желательно указать, за кем закрепляется контроль над исполнением сути приказа. Обычно он либо остается у генерального директора, либо передается ответственному.

Приказом вводится все – от режима защиты персональных данных до утверждения форм отчетности. Делать ли разные приказы на каждый чих или единым пулом – зачастую дело вкуса. Если все вводить отдельными приказами, то внедренные документы проще будет менять. Если единым пулом, то проще согласовать и подписывать.

Политика

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

Политика может и должна выдвигать требования к функционированию процесса, может описывать требуемое обеспечение и исключения.

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

Положение

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

Т.е. фактически Положение очень редко применяется к процессам, но будет весьма уместно в виде «Положение о Департаменте информационной безопасности».

Регламент

Регламент – самый противоречивый документ. Я встречал компании, в которой были только разнообразные Регламенты. Надо понимать, что в своей сути регламент – временный документ, во всяком случае в информационной безопасности. Это то, что сейчас модно называть «дорожной картой». Регламент, в отличие от Политики и Положения, определяет конкретные шаги и сроки их исполнения.

А раз есть сроки, Регламент мало применим к непрерывным процессам, например, обеспечению безопасности всей компании или обеспечению контроля качества. Т.е. может быть «Регламент внедрения политики безопасности», но лучше не делать «Регламент информационной безопасности».

Инструкция

Инструкция – самый последний в иерархии, но не по значимости документ. Инструкция описывает конкретные шаги, что надо делать в той или иной ситуации, или наоборот, то, что делать не надо никогда. Самый знаменитый пример инструкций обоих типов – Устав внутренней службы Вооруженных Сил.

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

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

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

Источник

Месяц до дня Х

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

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

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

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

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

Источник

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

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

Забегая немного вперед, отвага заключалась в атаке «с шашками на танки» силами одного специалиста на такую масштабную работу. Уже значительно позже я делал похожие работы, возглавляя различные по численности группы (от 2 до 6 человек). И если уж говорить об оптимальной численности команды, то оптимальное количество людей 1-2 человека, не считая привлекаемых специалистов, вроде технических писателей. 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.

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

P.S.S.S.

Вторая часть