Pull to refresh

Comments 8

Как-то очень кратко. А если по существу, то:

1) Что значит «выбираем стандарт ИБ»? Отраслевые и государственные стандарты являются, по большей части, обязательными к исполнению, и их не выбирают. Международные стандарты — да, тут можно и посмотреть, что нам подходит. Но вы не описали критерии отбора рекомендательных стандартов, соответствие которым будет выгодно для нашего бизнеса.

2) По поводу построения дерева отказов. Вы пишите:
2. Построение деревьев отказов

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


Не совсем понятна ваша мысль. То есть, у нас есть требования стандарта ИБ, нарушение которых не приводит к нарушению информационной безопасности? Было бы интересно получить пример такого требования. И кроме того, даже есть и принять, что так оно и есть (зная государственные требования ИБ -верю), но исключать их из аудита будет не правильно, так как это приведет к проблемам при проведении аудита на соответствие стандартам. Особенно это касается государственных стандартов ИБ.
1) Эта методика не имеет отношения и не может использоваться в качестве инструмента для оценки соответствия обязательным стандартам.
Я здесь говорю не о соответствии обязательным требованиям, а о реальной защищенности.
Под выбором стандарта я имею ввиду некий документ, который, по мнению аудитора, наилучшим образом подходит к нашей системе. Это отправная точка, которая должна в наиболее полной форме учитывать специфику нашей системы.

2) Да, конечно, есть требования, нарушение которых не приводит к нарушению ИБ. Про международные стандарты так прямо, без конкретики, не скажу, но что касается российских, то примеров тут много. Самый простой пример — обязательное требование сертификации средств защиты. Отсутствие сертификата не приведет к нарушению свойств ИБ информации. Требование излишне.
По поводу проблем при проведении аудита на соответствие стандартам — это другая песня, см. пункт 1 (описывается аудит защищенности де-факто, не более того).
1) И тем не менее? Чем должен руководствоваться аудитор, выбирая конкретный стандарт? Своим здравым смыслом? Если мы говорим о аудите защищенности де-факто, то почему не упоминается тестирование на проникновение?

2) А блокирование работы организации регулятором, за нарушение стандарта? Тоже вполне себе риск ИБ :)

Получается, вы написали что-то вроде гайда по внутреннему аудиту. Только очень неполный.
1) Чем должен руководствоваться аудитор, выбирая конкретный стандарт? Не смогу ответь Вам подробнее, чем ранее. Наверно, как Вы и предположили, своим здравым смыслом.
Пентесты сначала с грехом пополам здесь использовались, но потом пришлось их убрать, поскольку меня утянуло в другое русло. Задачей сейчас стало именно определение перечня требований, абсолютное выполнение которых скажет о защищенности системы. Пентесты же — это методы проверок (а я пытаюсь определить не как проверять, а что).
П.с. кстати, если Вы обратили внимание, то я не описываю этап проверки выполнения требований. Потому как считаю, что это уже другой вопрос.

2) Блокирование работы организации регулятором — это уже операционные риски, а не риски нарущения ИБ ;)

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

Блокирование работы регулятором — это организационно-правовая DoS-атака, нарушение доступности информации. Вполне себе нарушения требований по доступности. Так что — это риск ИБ :)
Если регулятор инициирует приостановку деятельности организации, то организация просто будет не иметь права работать (но это не приведет к нарушению доступности информации: информация так же будет находиться на доступных носителях, открывай да смотри, просто делать этого никто не будет, т.к. работать нельзя).
У нас же все так и происходит: есть защита информации, а есть защита от регулятора. Я предлагаю не мешать: котлеты отдельно, мухи отдельно.
Регулятор не может приостановить деятельность организации. Если говорить о ПДн — то только приостановка деятельности, связанной с обработкой персональных данных. Чем не DoS? :)

Таки вы рассказываете про защиту от регуляторов человеку, который 3 года отдал органу по аттестации?))
Хорошо, соглашусь. Действительно, регулятор может повлиять на доступность информации. Однако, как мне представляется, если капнуть в эту сторону, то подобных рисков окажется много (регуляторы есть не только в сфере ИБ, но и др. сферах деятельности организации).
Sign up to leave a comment.

Articles