Comments 35
так как к времени начала моей работы в нашей организации вопрос о работе с этим интегратором был решен и я мог только наблюдать и пожинать результаты
Предложенная интегратором инструкция — это не результат.
Результат — это окончательно согласованный и принятый заказчиком документ.
Конечно нет, но речь идет так же о качестве выполненой интегратором работы. Именно для того их и нанимали, чтобы получить профессиональную помощь.
Я думаю, что размышления в статье очень верные вот в каком ключе. Часто инструкции пишут черт знает как, такое чувство что просто для отписки. А ведь, действительно, люди — один из самых критичных компонентов в системе. И, помимо грамотной тренировки сотрудников, документы очень важно писать так, чтобы было легко и просто понять, что же черт возьми делать и в каких ситуациях. Это очень похоже на ситуацию с пользовтельскими соглашениями, в которых сам черт ногу сломит. И если есть определенный язык — юристов, административных текстов — то, как минимум, необходмо всю эту красоту переводить на человеческий язык.
Я думаю, что размышления в статье очень верные вот в каком ключе. Часто инструкции пишут черт знает как, такое чувство что просто для отписки. А ведь, действительно, люди — один из самых критичных компонентов в системе. И, помимо грамотной тренировки сотрудников, документы очень важно писать так, чтобы было легко и просто понять, что же черт возьми делать и в каких ситуациях. Это очень похоже на ситуацию с пользовтельскими соглашениями, в которых сам черт ногу сломит. И если есть определенный язык — юристов, административных текстов — то, как минимум, необходмо всю эту красоту переводить на человеческий язык.
Частенько инструкции пишутся не для заказчиков, а для регуляторов, которые могут прийти с проверкой.
Для них чем больше написано — тем труднее придраться.
Лучше начните свою работу в организации не с критики того, что было сделано до вас, а с реализации собственных идеи. Ибо лучший способ показать недостатки чужой работы — сделать самому и сравнить.
Для них чем больше написано — тем труднее придраться.
Лучше начните свою работу в организации не с критики того, что было сделано до вас, а с реализации собственных идеи. Ибо лучший способ показать недостатки чужой работы — сделать самому и сравнить.
Во-первых, как уже сказали, большая часть инструкций нужна для защиты от регуляторов. А во-вторых…
Одной из причин, почему интегратор пишет такие документы, является то, что исполнитель прекрасно понимает, что заказчик в этом, мягко говоря, не заинтересован. Почему? Ну, вопрос того, кто, как и почему компрометирует сферу ИБ — довольно большой, и заслуживает отдельной статьи.
Что касается вашей критики. Если вы хотите по-критиковать документ — приведите его полностью. Со ссылками на все сопутствующие документы. Уверен, что большая часть вопросов отпадет, если рассматривать комплект разработанных документов полностью. Кроме того, что бы разработать грамотный документ самостоятельно, вам потребуется учитывать очень много факторов — от наших обязательных к исполнению стандартов по ИБ, до международных стандартов (если вы заявляетесь/собираетесь заявиться на ISO 27k), и включая особенности бизнеса и отраслевые стандарты, если у вас такие есть.
Помимо этого. Если вам так не нравится документ — почему его утвердили? Никакой интегратор не отдает документы просто так — они всегда проходят процедуру согласования у заказчика. Если вы не глядя подмахнули документ, то все претензии по его качеству можете смело предъявлять себе. Если вы не ЛПР, и сами документы не подписываете, то возникает вопрос, почему вы не поставили руководство в известность о плохом качестве документов?
Одной из причин, почему интегратор пишет такие документы, является то, что исполнитель прекрасно понимает, что заказчик в этом, мягко говоря, не заинтересован. Почему? Ну, вопрос того, кто, как и почему компрометирует сферу ИБ — довольно большой, и заслуживает отдельной статьи.
Что касается вашей критики. Если вы хотите по-критиковать документ — приведите его полностью. Со ссылками на все сопутствующие документы. Уверен, что большая часть вопросов отпадет, если рассматривать комплект разработанных документов полностью. Кроме того, что бы разработать грамотный документ самостоятельно, вам потребуется учитывать очень много факторов — от наших обязательных к исполнению стандартов по ИБ, до международных стандартов (если вы заявляетесь/собираетесь заявиться на ISO 27k), и включая особенности бизнеса и отраслевые стандарты, если у вас такие есть.
Помимо этого. Если вам так не нравится документ — почему его утвердили? Никакой интегратор не отдает документы просто так — они всегда проходят процедуру согласования у заказчика. Если вы не глядя подмахнули документ, то все претензии по его качеству можете смело предъявлять себе. Если вы не ЛПР, и сами документы не подписываете, то возникает вопрос, почему вы не поставили руководство в известность о плохом качестве документов?
Ссылок на другие документы, кроме первой части, нет. вот первая часть:
1. Общие положения
1.1. Инструкция действий в нештатной ситуации (далее – Инструкция) разработана в соответствии с Федеральным законом №152-ФЗ от 27 июля 2006 года «О персональных данных», Федеральным законом «Об информации, информационных технологиях и защите информации» от 27.07.2006г. № 149-Ф3, Постановлением Правительства РФ от 17 ноября 2007г. №781, другими нормативными правовыми актами Российской Федерации, регулирующими отношения в области защиты персональных данных.
1.1. Настоящая инструкция предназначена для организации порядка действий при возникновении нештатных ситуаций.
1.2. Инструкция регламентирует действия персонала подразделений при возникновении нештатных ситуаций.
1.3. Настоящая инструкция доводится под роспись до всех сотрудников ООО «Вектор» (Приложение №1 – Журнал ознакомления с настоящей Инструкцией).
Приведите, пожалуйста, список обязательных российских стандартов по ИБ, для коммерческой организации, не имеющей отношения к кредитным организациям, гос сектору, энергетике и тд!
Документ не утвердили, утверждена написанная лично мной инструкция. Этот документ лежит сейчас у меня в качестве образца — как не надо делать!
1. Общие положения
1.1. Инструкция действий в нештатной ситуации (далее – Инструкция) разработана в соответствии с Федеральным законом №152-ФЗ от 27 июля 2006 года «О персональных данных», Федеральным законом «Об информации, информационных технологиях и защите информации» от 27.07.2006г. № 149-Ф3, Постановлением Правительства РФ от 17 ноября 2007г. №781, другими нормативными правовыми актами Российской Федерации, регулирующими отношения в области защиты персональных данных.
1.1. Настоящая инструкция предназначена для организации порядка действий при возникновении нештатных ситуаций.
1.2. Инструкция регламентирует действия персонала подразделений при возникновении нештатных ситуаций.
1.3. Настоящая инструкция доводится под роспись до всех сотрудников ООО «Вектор» (Приложение №1 – Журнал ознакомления с настоящей Инструкцией).
Приведите, пожалуйста, список обязательных российских стандартов по ИБ, для коммерческой организации, не имеющей отношения к кредитным организациям, гос сектору, энергетике и тд!
Документ не утвердили, утверждена написанная лично мной инструкция. Этот документ лежит сейчас у меня в качестве образца — как не надо делать!
Ну, допускаю, что это может быть просто хреново написанный документ.
Вы работаете в сферической коммерческой компании вакууме, которая не занимается ничем? Или все-таки какая-то сфера деятельности у вас есть? Назовите ее, а то трудно подсказать какой-то стандарт, не зная, чем компания занимается.
Вы работаете в сферической коммерческой компании вакууме, которая не занимается ничем? Или все-таки какая-то сфера деятельности у вас есть? Назовите ее, а то трудно подсказать какой-то стандарт, не зная, чем компания занимается.
Тогда перефразирую так: приведите список обязательных российских стандартов по безопасности, для сферической коммерческой организации в вакууме без учета отраслей, которые я отмёл ранее.
Для сферической коммерческой организации в вакууме в России (да и во всем мире) есть сферические стандарты по безопасности в вакууме.
ИБ — это голая практика, отделять безопасность от бизнеса нельзя.
ИБ — это голая практика, отделять безопасность от бизнеса нельзя.
Ок, повторю в третий раз: какие из этих сферических российских стандартов ОБЯЗАТЕЛЬНЫ?
Так понятнее?
Ну и вопрос: вы какое имеете отношение к ИБ?
Так понятнее?
Ну и вопрос: вы какое имеете отношение к ИБ?
Кхм. Видимо, тэг сарказм надо было ставить.
Сферических стандартов в вакууме не существует, мы все это прекрасно знаем. В лучшем случае можно использовать ISO 27k или COBIT (у нас, увы, даже аналогов нет), но это рекомендательные стандарты, напрямую обязать их использовать нельзя.
Да фактически никакого — жалких три года в органе по аттестации, сейчас DLP-системами занимаюсь.
Если уж мы начинаем разговор на тему «Кто тут дурак», то дайте мне ответ — вы с какой целью позвали интеграторов? Соответствие каким стандартам было необходимо подтвердить? От кого исходила инициатива привлечения интеграторов?
И к слову — разработка документации — это скорее работа аудиторов/консалтеров. Интеграторы больше техникой занимаются.
Сферических стандартов в вакууме не существует, мы все это прекрасно знаем. В лучшем случае можно использовать ISO 27k или COBIT (у нас, увы, даже аналогов нет), но это рекомендательные стандарты, напрямую обязать их использовать нельзя.
Да фактически никакого — жалких три года в органе по аттестации, сейчас DLP-системами занимаюсь.
Если уж мы начинаем разговор на тему «Кто тут дурак», то дайте мне ответ — вы с какой целью позвали интеграторов? Соответствие каким стандартам было необходимо подтвердить? От кого исходила инициатива привлечения интеграторов?
И к слову — разработка документации — это скорее работа аудиторов/консалтеров. Интеграторы больше техникой занимаются.
Да причём тут тэг, сказали про обязательные российские стандарты, попытался узнать есть ли такие — ни одного прямого ответа.
Интеграторов позвали ДО того, как я пришёл в организацию. Фактически я там появился, когда они проводили обследование. Работы были именно консалтинговые, пока никакого ПО или железа они у нас не внедряли, провели только обследование+выдали рекомендации.
Вы занимались построением системы управления безопасностью или просто системы безопасности?
Интеграторов позвали ДО того, как я пришёл в организацию. Фактически я там появился, когда они проводили обследование. Работы были именно консалтинговые, пока никакого ПО или железа они у нас не внедряли, провели только обследование+выдали рекомендации.
Вы занимались построением системы управления безопасностью или просто системы безопасности?
Системы безопасности — слишком расплывчато. Давайте конкретику. Хотите соответствие ISO 27k? Ваши вопросы по системам управления безопасностью говорят в пользу этого.
Сам такие вещи не внедрял, но со стандартами этими знаком. И если хотите разговор непосредственно по этой теме — давайте в личку или Skype, у меня в профиле он есть.
Сам такие вещи не внедрял, но со стандартами этими знаком. И если хотите разговор непосредственно по этой теме — давайте в личку или Skype, у меня в профиле он есть.
Эти инструкции написаны для регулятора, вы реальную безопасность в проекте строили, или выполняли требования? Если требования то и стиль изложения, и сам документ не предназначены для вашего бизнеса.
Особенно мне нравятся заявления, я сделал лучше, (документ покажите что ли) а на простой вопрос почему вы решили что 6 знаков длины пароля для вашей системы достаточно, обосновать в соответствии с требованиями Российских регуляторов (не надо путать со здравым смыслом) не могут.
Так же регулятора интересует основания, почему документ написано именно так, почему вы решили, что он сделал правильно и он требует документарного подтверждения этих знаний?
Особенно мне нравятся заявления, я сделал лучше, (документ покажите что ли) а на простой вопрос почему вы решили что 6 знаков длины пароля для вашей системы достаточно, обосновать в соответствии с требованиями Российских регуляторов (не надо путать со здравым смыслом) не могут.
Так же регулятора интересует основания, почему документ написано именно так, почему вы решили, что он сделал правильно и он требует документарного подтверждения этих знаний?
Я как правило строю реальную безопасность, а не отмахиваюсь бумагами от регуляторов.
Сегодня я опубликовал пост с примерами и рекомендациями по написанию инструкций. habrahabr.ru/post/153973/
Все примеры из документов, написанных мной.
Причём тут про 6 знаков в пароле, я не понял.
Сегодня я опубликовал пост с примерами и рекомендациями по написанию инструкций. habrahabr.ru/post/153973/
Все примеры из документов, написанных мной.
Причём тут про 6 знаков в пароле, я не понял.
Про пароль просто пример из жизни. Когда регулятор спрашивает, почему вы считаете что указанной длинны пароля достаточно, необходимо обосновать почему, большинство толком не может (обоснования он сложный сам по себе недостаточно).
Вы когда строите реальную безопасность, вы руководствуетесь принципом минимизации рисков. Российские стандарты требуют нейтрализации рисков, как говориться « почувствуй разницу». И документы под это готовят. Когда начинают выполнять требования по 152 ФЗ силами собственных инженеров, существующий опыт не подходит, разные принципы в подходах. Поэтому ваша инструкция с точки зрения логики не плоха, но с точки зрения регулятора ее нет.
А инструкции, пользователи не читают их, а в большинстве случаев и не выполняют. Можете сходить к своему генеральному, ведущему менеджеру, главбуху, и тд. и попросить его рассказать, что написано в вашей инструкции, боюсь вероятен ваш посыл в пешие путешествия. А там где есть исключения, там есть и высокие риски.
Так что эта инструкция прикрытие вашей собственный попы как ответственного за ИБ.
Когда реализуется ИБ, стоит уделить очень пристальное внимание создание доказательной базы. Как пример защита от вирусных угроз: простой вопрос, почему вы решили, что антивирус от чего то вас защищает, совсем не защищает, вы лицензионное соглашение прочитайте и там увидите, что вам никто и не говорит, что это должно работать, а остальное маркетинг.
Вы когда строите реальную безопасность, вы руководствуетесь принципом минимизации рисков. Российские стандарты требуют нейтрализации рисков, как говориться « почувствуй разницу». И документы под это готовят. Когда начинают выполнять требования по 152 ФЗ силами собственных инженеров, существующий опыт не подходит, разные принципы в подходах. Поэтому ваша инструкция с точки зрения логики не плоха, но с точки зрения регулятора ее нет.
А инструкции, пользователи не читают их, а в большинстве случаев и не выполняют. Можете сходить к своему генеральному, ведущему менеджеру, главбуху, и тд. и попросить его рассказать, что написано в вашей инструкции, боюсь вероятен ваш посыл в пешие путешествия. А там где есть исключения, там есть и высокие риски.
Так что эта инструкция прикрытие вашей собственный попы как ответственного за ИБ.
Когда реализуется ИБ, стоит уделить очень пристальное внимание создание доказательной базы. Как пример защита от вирусных угроз: простой вопрос, почему вы решили, что антивирус от чего то вас защищает, совсем не защищает, вы лицензионное соглашение прочитайте и там увидите, что вам никто и не говорит, что это должно работать, а остальное маркетинг.
Про обоснованность длинны пароля для ИСПДн, к примеру, из Приказа №58 ФСТЭК, для систем 3 класса:
а) управление доступом:
— идентификация и проверка подлинности пользователя при входе в систему информационной системы по паролю условно-постоянного действия длиной не менее шести буквенно-цифровых символов;
Про читают/выполняют, я писал в следующем посте о необходимости обучения. про работу с юзерами напишу отдельный пост, как и что лучше делать. но попозже.
Про доказательную базу тоже не совсем понял, доказательства для кого? Регуляторов? Топ-менеджмента?
а) управление доступом:
— идентификация и проверка подлинности пользователя при входе в систему информационной системы по паролю условно-постоянного действия длиной не менее шести буквенно-цифровых символов;
Про читают/выполняют, я писал в следующем посте о необходимости обучения. про работу с юзерами напишу отдельный пост, как и что лучше делать. но попозже.
Про доказательную базу тоже не совсем понял, доказательства для кого? Регуляторов? Топ-менеджмента?
Я об этом и говорил, почему вы решили, что вашей системе достаточно именно 6 символов или 7 или 9 (на самом деле есть формула которая и является обоснованием)? Это один из маленьких примеров при прохождении проверки в отношении документов сделанными собственными силами, невозможность обосновать.
Поделитесь мыслями, сотрудникам, хорошо.
У вас произошёл инцидент, к примеру, пользователь слил базу данных сделок (пользователь легитимный, просто не туда отдал). Вам его надо наказать, в рамках хотя бы увольнения, для этого собственно говоря и готовиться доказательная база. Без нее он вас пошлет а потом через суд восстановиться если уволят.
Поделитесь мыслями, сотрудникам, хорошо.
У вас произошёл инцидент, к примеру, пользователь слил базу данных сделок (пользователь легитимный, просто не туда отдал). Вам его надо наказать, в рамках хотя бы увольнения, для этого собственно говоря и готовиться доказательная база. Без нее он вас пошлет а потом через суд восстановиться если уволят.
Если нет вопросов относительно модели угроз и классификации системы, то по факту у регуляторов не должно быть вопросов, почему мы так исполнили пункт нормативного документа. В нём же описан только обязательный нижний предел сложности пароля (6 символов и 2 алфавита). Если мы выполняем это требование, то остальное на наше усмотрение (относительно этого пункта).
Для этого так же необходим документ, юридически и по смыслу верно составленный. В том же ISO 27002-2005 раздел есть: сбор доказательств. Там описаны основополагающие принципы сбора доказательств инцидента.
Грубо говоря, в случае электронных копий необходимо запротоколировать процесс расследования с указанием того откуда, кем, когда и какие данные брались, при этом так же под протокол зафиксировать зеркалирование этих данных для возможной передачи в суд или МВД.
Если на бумаге, то также снимаются копии, для предоставления в органы. Оригиналы хранятся у ответственного сотрудника (офицера безопасности) в сейфе.
Ну и соответственно в таких документах, как должностная инструкция, коллективный договор и/или трудовой договор должны быть прописаны пункты об ответственности за защиту информации и должно быть подписано соглашение о неразглашении.
Для этого так же необходим документ, юридически и по смыслу верно составленный. В том же ISO 27002-2005 раздел есть: сбор доказательств. Там описаны основополагающие принципы сбора доказательств инцидента.
Грубо говоря, в случае электронных копий необходимо запротоколировать процесс расследования с указанием того откуда, кем, когда и какие данные брались, при этом так же под протокол зафиксировать зеркалирование этих данных для возможной передачи в суд или МВД.
Если на бумаге, то также снимаются копии, для предоставления в органы. Оригиналы хранятся у ответственного сотрудника (офицера безопасности) в сейфе.
Ну и соответственно в таких документах, как должностная инструкция, коллективный договор и/или трудовой договор должны быть прописаны пункты об ответственности за защиту информации и должно быть подписано соглашение о неразглашении.
Сразу видно, когда и кто делал модель угроз. И какие документы кто делал, если компания сама делала, то ей и задают вопросы.
Конечно на свое усмотрение, только не просто так а на основании.
У регулятора не идиоты сидят. Они просто ограниченны в своих действиях, чиновники однако, да же если захотят нормально сделать, то фик кто даст.
Конечно на свое усмотрение, только не просто так а на основании.
У регулятора не идиоты сидят. Они просто ограниченны в своих действиях, чиновники однако, да же если захотят нормально сделать, то фик кто даст.
Можно тогда ваш взгляд на то, как объяснить регулятору, что пароля в 6 символов и 2-мя алфавитами достаточно?
Не с целью поехидствовать, а опыта для.
Не с целью поехидствовать, а опыта для.
Я выше писал, обоснованием достаточности является формула из нормативной документации. Саму правильность расчета роскомнадзор не проверяет.
По поводу формулы я привел пример, что оператор может строить систему защиты как хочет, но должен обосновать. В большинство компаний проводивших работы самостоятельно, как раз с обоснованием очень тяжко, так как разная методика защиты: минимизация и предотвращение рисков.
Обоснование на основе экспертной оценки рисков. Такой-то риск незначителен, поэтому не рассматривается и приводится обоснование почему. И тд.
Так и есть, вопрос что является доказательством что исполнитель в компании операторе является экспертом и обладает всей необходимой документацией и знаниями.
И только написал каммент, как увидел habrahabr.ru/company/group-ib/blog/154005/?
Тут про ДБО, но как пример сбора доказательств вполне хороший док
Тут про ДБО, но как пример сбора доказательств вполне хороший док
Sign up to leave a comment.
Безопасность, инструкции и интеграторы