Доброго времени суток, уважаемые хабровчане!
Недавно пришлось столкнуться с одним локальным интегратором в части работ по ФЗ-152 и в общем по защите информации. Целесообразность для нашей небольшой конторы, описывать не буду (я бы сделал это в одиночку, разве что чуть дольше, но на порядок дешевле), так как к времени начала моей работы в нашей организации вопрос о работе с этим интегратором был решен и я мог только наблюдать и пожинать результаты.
О результатах и размышлениях, «почему оно так», под хабракатом.
Инструкция действий в нештатной ситуации
Так назывался их самый интересный документ. Оговорюсь сразу — я не работал в компаниях-интеграторах, я не делал инструкция для заказчика. Мне было сложно понять логику создания этого документа, от человека, писавшего этот документы был комментарий только: мы успешно это внедряли во многих организациях и ни у кого не было проблем!
Теперь перейдем к выдержкам из текста с моими комментариями (опустим 1 раздел — общие положения, так как там описание законов и тп):
2. Общий порядок действий при возникновении нештатных ситуаций
2.1. При возникновении нештатных ситуаций во время работы сотрудник, обнаруживший нештатную ситуацию, немедленно ставит в известность администратора защиты информации.
2.2. Администратор защиты информации проводит предварительный анализ ситуации и, в случае невозможности исправить положение, ставит в известность начальника подразделения.
2.3. По факту возникновения нештатной ситуации составляется акт, с описанием ситуации. К акту прилагаются, если есть, поясняющие материалы (копии экрана, распечатка журнала событий и др.).
2.4. При необходимости, проводится служебное расследование по факту возникновения нештатной ситуации и выяснению её причин.
Первое что вызывает вопросы: а что собственно такое эти нештатные ситуации? Как рядовой сотрудник, к примеру, отдела маркетинга, узнает — это нештатная ситуация, или результат штатных действий?
Для чего отягощать инструкцию для пользователей (по словам того же сотрудника интегратора) описанием действий администратора ЗИ?
Далее идёт раздел 3. Особенности действий при возникновении наиболее распространённых нештатных ситуаций. Он большой и состоит из 14-ти пунктов, все их приводить не имеет смысла, так как там фактически каждый раздел представляет собой нештатную ситуацию и что делать сисадмину и админу ЗИ в этом случае (повторюсь, инструкция создавалась для пользователей).
Как пример:
3.2. Отключение электричества. Администратор защиты информации совместно с сотрудником (указать) отдела проводят анализ на наличие потерь и (или) разрушения данных и ПО, а так же проверяют работоспособность оборудования. В случае необходимости, производится восстановление ПО и данных из последней резервной копии с составлением акта.
3.3. Сбой в локальной вычислительной сети (ЛВС). Администратор защиты информации совместно с сотрудником (указать) отдела проводят анализ на наличие потерь и (или) разрушения данных и ПО. В случае необходимости, производится восстановление ПО и данных из последней резервной копии с составлением акта.
Копипаст просто рулит!
3.7. Обнаружена утечка информации (дырка в системе защиты). При обнаружении утечки информации ставится в известность администратор защиты информации и начальник подразделения. Проводится служебное расследование. Если утечка информации произошла по техническим причинам, проводится анализ защищённости системы и, если необходимо, принимаются меры по устранению уязвимостей и предотвращению их возникновения.
Замечательная формулировка, разъясняющая, что же такое утечка информации. Причём НСД и утечка информации (дырка в защите системы) они разделили на два отдельных пункта:
3.8. Взлом системы (Web-сервера, файл-сервера и др.) или несанкционированный доступ (НСД). При обнаружении взлома сервера ставится в известность администратор защиты информации и начальник подразделения. Проводится, по возможности, временное отключение сервера от сети для проверки на вирусы и троянских закладок. Возможен временный переход на резервный сервер. Учитывая, что программные закладки могут быть не обнаружены антивирусным ПО, следует особенно тщательно проверить целостность исполняемых файлов в соответствии с хэш-функциями эталонного программного обеспечения, а также проанализировать состояние файлов-скриптов и журналы сервера. Необходимо сменить все пароли, которые имели отношение к данному серверу. В случае необходимости производится восстановление ПО и данных из эталонного архива и резервных копий с составлением акта. По результатам анализа ситуации следует проверить вероятность проникновения несанкционированных программ в ИС ООО«Вектор», после чего провести аналогичные работы по проверке и восстановлению ПО и данных на других рабочих станций ИС ООО «Вектор». По факту взлома сервера проводится служебное расследование.
3.9. Попытка несанкционированного доступа (НСД). При попытке НСД проводится анализ ситуации на основе информации журналов регистрации попыток НСД и предыдущих попыток НСД. По результатам анализа, в случае необходимости, принимаются меры по предотвращению НСД, если есть реальная угроза НСД. Так же рекомендуется провести внеплановую смену паролей. В случае появления обновлений ПО, устраняющие уязвимости системы безопасности, следует применить такие обновления.
Ещё один интересный пункт в этом разделе, который просто и легко описывает трудоемкую работу по созданию, тестированию и отладке системы непрерывности бизнеса:
3.13. Стихийное бедствие. При возникновении стихийных бедствий следует руководствоваться документами (указать) для соответствующих подразделений ООО «Вектор». По факту возникновения нештатной ситуации составляется акт, с описанием ситуации. К акту прилагаются, если есть, поясняющие материалы (копии экрана, распечатка журнала событий и др.).
Опять же копипаст, причём из 2-го раздела. Писали люди явно далекие от business continuity. Я бы посмотрел, как в момент возникновения стихийного бедствия составляется по факту акт, прикладываются копии экрана, распечатки логов и тд.
Ну и завершает этот раздел стандартный пункт:
3.14. При необходимости, проводится служебное расследование по факту возникновения нештатной ситуации и выяснению её причин.
Четвёртый раздел этого фолианта (повторюсь, инструкции для пользователей) называется: Профилактика против возникновения нештатных ситуаций
4.1. Не реже (указать период), должен проводиться анализ зарегистрированных нештатных ситуаций для выработки мероприятий по их предотвращению.
4.2. В общем случае, для предотвращения нештатных ситуаций необходимо чёткое соблюдение требований нормативных документов ООО «Вектор» и инструкций по эксплуатации оборудования и ПО.
Первый пункт этого раздела — этакий problem management в миниатюре.
Второй пункт вызывает недоумение. Этим пунктом можно было заменить все предыдущие 3 страницы текста 12-м шрифтом. Ну или это такой намек на этот же документ, то есть рекурсия.
Размышления на тему
Интегратор, создававший нам этот документ, довольно крупный в нашем регионе, работает уже давно и известен.
То есть создается скорее всего такая ситуация: молодой специалист, только что окончивший ВУЗ по престижной специальности «Информационная Безопасность» попадает на работу к этому интегратору. Он пишет подобный документ для заказчика. Заказчик до этого не имел дело с документами по ИБ (у нас ещё пока что совковый взгляд на эту отрасль) и принимает этот документ, знакомит под роспись с ним своих сотрудников и как-то выполняет требования.
Повторюсь, я никогда не работал у интеграторов. Я занимался ИБ для тех организаций в которых работал, я делал инструкции для себя и своих сотрудников.
Для чего создавать такой трудно перевариваемый и безграмотный документ, переполненный слепым копипастом?
Неужели молодые спецы не слышали про best practice и разнообразные зарубежные стандарты по безопасности?
За время работы в сфере ИБ уяснил 2 основные вещи:
1. Информационная безопасность — это прежде всего люди, только потом техника.
2. Инструкции должны выполняться на автомате, для этого они должны быть написаны доступно и с как можно более меньшим количеством пунктов (идеально — расписаны действия юзера по шагам с ответственными и их контактами).
Уважаемые интеграторы! Пожалуйста, следите за качеством выдаваемых вами рекомендаций и рекомендуемых документов. Создавайте их, как для себя, а не на «отвали»!
P.S. Надеюсь сотрудники компаний-интеграторов смогут отметиться в комментариях.
P.P.S. Все связи с реальными ООО «Вектор» — случайны.
UPD: если сливаете топик или карму, отписывайтесь, плиз, в камментах за что. Буду знать и совершенствоваться.
Недавно пришлось столкнуться с одним локальным интегратором в части работ по ФЗ-152 и в общем по защите информации. Целесообразность для нашей небольшой конторы, описывать не буду (я бы сделал это в одиночку, разве что чуть дольше, но на порядок дешевле), так как к времени начала моей работы в нашей организации вопрос о работе с этим интегратором был решен и я мог только наблюдать и пожинать результаты.
О результатах и размышлениях, «почему оно так», под хабракатом.
Инструкция действий в нештатной ситуации
Так назывался их самый интересный документ. Оговорюсь сразу — я не работал в компаниях-интеграторах, я не делал инструкция для заказчика. Мне было сложно понять логику создания этого документа, от человека, писавшего этот документы был комментарий только: мы успешно это внедряли во многих организациях и ни у кого не было проблем!
Теперь перейдем к выдержкам из текста с моими комментариями (опустим 1 раздел — общие положения, так как там описание законов и тп):
2. Общий порядок действий при возникновении нештатных ситуаций
2.1. При возникновении нештатных ситуаций во время работы сотрудник, обнаруживший нештатную ситуацию, немедленно ставит в известность администратора защиты информации.
2.2. Администратор защиты информации проводит предварительный анализ ситуации и, в случае невозможности исправить положение, ставит в известность начальника подразделения.
2.3. По факту возникновения нештатной ситуации составляется акт, с описанием ситуации. К акту прилагаются, если есть, поясняющие материалы (копии экрана, распечатка журнала событий и др.).
2.4. При необходимости, проводится служебное расследование по факту возникновения нештатной ситуации и выяснению её причин.
Первое что вызывает вопросы: а что собственно такое эти нештатные ситуации? Как рядовой сотрудник, к примеру, отдела маркетинга, узнает — это нештатная ситуация, или результат штатных действий?
Для чего отягощать инструкцию для пользователей (по словам того же сотрудника интегратора) описанием действий администратора ЗИ?
Далее идёт раздел 3. Особенности действий при возникновении наиболее распространённых нештатных ситуаций. Он большой и состоит из 14-ти пунктов, все их приводить не имеет смысла, так как там фактически каждый раздел представляет собой нештатную ситуацию и что делать сисадмину и админу ЗИ в этом случае (повторюсь, инструкция создавалась для пользователей).
Как пример:
3.2. Отключение электричества. Администратор защиты информации совместно с сотрудником (указать) отдела проводят анализ на наличие потерь и (или) разрушения данных и ПО, а так же проверяют работоспособность оборудования. В случае необходимости, производится восстановление ПО и данных из последней резервной копии с составлением акта.
3.3. Сбой в локальной вычислительной сети (ЛВС). Администратор защиты информации совместно с сотрудником (указать) отдела проводят анализ на наличие потерь и (или) разрушения данных и ПО. В случае необходимости, производится восстановление ПО и данных из последней резервной копии с составлением акта.
Копипаст просто рулит!
3.7. Обнаружена утечка информации (дырка в системе защиты). При обнаружении утечки информации ставится в известность администратор защиты информации и начальник подразделения. Проводится служебное расследование. Если утечка информации произошла по техническим причинам, проводится анализ защищённости системы и, если необходимо, принимаются меры по устранению уязвимостей и предотвращению их возникновения.
Замечательная формулировка, разъясняющая, что же такое утечка информации. Причём НСД и утечка информации (дырка в защите системы) они разделили на два отдельных пункта:
3.8. Взлом системы (Web-сервера, файл-сервера и др.) или несанкционированный доступ (НСД). При обнаружении взлома сервера ставится в известность администратор защиты информации и начальник подразделения. Проводится, по возможности, временное отключение сервера от сети для проверки на вирусы и троянских закладок. Возможен временный переход на резервный сервер. Учитывая, что программные закладки могут быть не обнаружены антивирусным ПО, следует особенно тщательно проверить целостность исполняемых файлов в соответствии с хэш-функциями эталонного программного обеспечения, а также проанализировать состояние файлов-скриптов и журналы сервера. Необходимо сменить все пароли, которые имели отношение к данному серверу. В случае необходимости производится восстановление ПО и данных из эталонного архива и резервных копий с составлением акта. По результатам анализа ситуации следует проверить вероятность проникновения несанкционированных программ в ИС ООО«Вектор», после чего провести аналогичные работы по проверке и восстановлению ПО и данных на других рабочих станций ИС ООО «Вектор». По факту взлома сервера проводится служебное расследование.
3.9. Попытка несанкционированного доступа (НСД). При попытке НСД проводится анализ ситуации на основе информации журналов регистрации попыток НСД и предыдущих попыток НСД. По результатам анализа, в случае необходимости, принимаются меры по предотвращению НСД, если есть реальная угроза НСД. Так же рекомендуется провести внеплановую смену паролей. В случае появления обновлений ПО, устраняющие уязвимости системы безопасности, следует применить такие обновления.
Ещё один интересный пункт в этом разделе, который просто и легко описывает трудоемкую работу по созданию, тестированию и отладке системы непрерывности бизнеса:
3.13. Стихийное бедствие. При возникновении стихийных бедствий следует руководствоваться документами (указать) для соответствующих подразделений ООО «Вектор». По факту возникновения нештатной ситуации составляется акт, с описанием ситуации. К акту прилагаются, если есть, поясняющие материалы (копии экрана, распечатка журнала событий и др.).
Опять же копипаст, причём из 2-го раздела. Писали люди явно далекие от business continuity. Я бы посмотрел, как в момент возникновения стихийного бедствия составляется по факту акт, прикладываются копии экрана, распечатки логов и тд.
Ну и завершает этот раздел стандартный пункт:
3.14. При необходимости, проводится служебное расследование по факту возникновения нештатной ситуации и выяснению её причин.
Четвёртый раздел этого фолианта (повторюсь, инструкции для пользователей) называется: Профилактика против возникновения нештатных ситуаций
4.1. Не реже (указать период), должен проводиться анализ зарегистрированных нештатных ситуаций для выработки мероприятий по их предотвращению.
4.2. В общем случае, для предотвращения нештатных ситуаций необходимо чёткое соблюдение требований нормативных документов ООО «Вектор» и инструкций по эксплуатации оборудования и ПО.
Первый пункт этого раздела — этакий problem management в миниатюре.
Второй пункт вызывает недоумение. Этим пунктом можно было заменить все предыдущие 3 страницы текста 12-м шрифтом. Ну или это такой намек на этот же документ, то есть рекурсия.
Размышления на тему
Интегратор, создававший нам этот документ, довольно крупный в нашем регионе, работает уже давно и известен.
То есть создается скорее всего такая ситуация: молодой специалист, только что окончивший ВУЗ по престижной специальности «Информационная Безопасность» попадает на работу к этому интегратору. Он пишет подобный документ для заказчика. Заказчик до этого не имел дело с документами по ИБ (у нас ещё пока что совковый взгляд на эту отрасль) и принимает этот документ, знакомит под роспись с ним своих сотрудников и как-то выполняет требования.
Повторюсь, я никогда не работал у интеграторов. Я занимался ИБ для тех организаций в которых работал, я делал инструкции для себя и своих сотрудников.
Для чего создавать такой трудно перевариваемый и безграмотный документ, переполненный слепым копипастом?
Неужели молодые спецы не слышали про best practice и разнообразные зарубежные стандарты по безопасности?
За время работы в сфере ИБ уяснил 2 основные вещи:
1. Информационная безопасность — это прежде всего люди, только потом техника.
2. Инструкции должны выполняться на автомате, для этого они должны быть написаны доступно и с как можно более меньшим количеством пунктов (идеально — расписаны действия юзера по шагам с ответственными и их контактами).
Уважаемые интеграторы! Пожалуйста, следите за качеством выдаваемых вами рекомендаций и рекомендуемых документов. Создавайте их, как для себя, а не на «отвали»!
P.S. Надеюсь сотрудники компаний-интеграторов смогут отметиться в комментариях.
P.P.S. Все связи с реальными ООО «Вектор» — случайны.
UPD: если сливаете топик или карму, отписывайтесь, плиз, в камментах за что. Буду знать и совершенствоваться.
