Comments 35
Начать следует с определения понятия «СУИБ» и целей и задач ее создания.
Я указал, что статья рассчитана на неспециалиста в области ИБ, на которого руководство взвалило задачи по безопасности. Определение целей и задач СУИБ — дело третье в текущем разрезе. С одной стороны эта статья как помощь, что бы отвязаться от начальства, с другой стороны, что бы всё было сделано +- правильно, и не выглядело смешно и нелепо.
Вот как раз неспециалисту, если на него взвалили задачу по созданию СУИБ, тем более надо начинать с вопросов «что вы хотите в результате».
Минимизация рисков — вот основная цель СУИБ как таковой.
Каких? В отношении чего?
А это выясняется на основании анализа рисков.
То есть вы предлагаете строить систему, цели которой выясняются в ходе ее же постройки?
Цель — минимизация рисков, как таковых. Любая организация имеет такие, по факту. От каких конкретно рисков и как защищать — выясняется на подготовительном этапе анализа рисков.
И повторюсь еще раз, статья рассчитана на тех, кому сверху упало указание — сделать безопасно!
И повторюсь еще раз, статья рассчитана на тех, кому сверху упало указание — сделать безопасно!
«сделать безопасно» и «создать СУИБ» — это две немного разные вещи, как мне кажется. Меня, собственно, слово «система» больше всего смущает.
Ок, в вашем понимании СУИБ — что такое?
У меня нет этого понимания, и после вашей статьи тоже не появилось. Это меня и фрустрирует.
У меня не было цели рассказать, что такое СУИБ и для чего. Я рассказал, что делать, если руководство сказало «сделать безопасно». Собственно то, что представлено в этой статье, это рекомендации по построению системы управления безопасностью. То есть фактически безопасность в некоем роде есть, но о ней не знают (точнее не знают, что это относится к ИБ), работа эта не структурирована и не описана. А по логике процессного подхода, если процесс не описан, то его нет!
У меня не было задачи описывать, начиная с дебрей — с понятий, назначений и тд. Я сказал как можно сделать, максимально красиво с минимумом затрат.
Это один из подходов и не претендует на абсолютную истину.
У меня не было задачи описывать, начиная с дебрей — с понятий, назначений и тд. Я сказал как можно сделать, максимально красиво с минимумом затрат.
Это один из подходов и не претендует на абсолютную истину.
UFO just landed and posted this here
Начать следует, как по мне, с выяснения, какие есть активы, их категоризировать — то есть присвоить грифы, и потом согласно категориям и выяснять, какие риски для каких активов имеются в наличие.
В статье совершенно не встречаются термины «злоумышленник» или «нарушитель» или их аналоги, «угроза» упоминается всего один раз и без комментариев, а уязвимость, оказывается, сама по себе "… может нанести вред, то есть реализовать риск"!
Это настолько печально, что всё вместе начинающему скорее повредит, чем поможет.
Вот только несколько моментов:
1) Сначала всегда строится модель системы (в первую очередь, защищаемых активов) и модель нарушителя (и угроз), потом все остальное. Иначе о безопасности говорить бессмысленно. Совершенно естественная цепочка вопросов "ЧТО ЕСТЬ (у нас)? --> КТО ЕСТЬ (не у нас)? + ЗАЧЕМ (они нас будут атаковать)? --> КАК (это может произойти и через какие дыры у нас)? --> ЧТО ДЕЛАТЬ (чтобы меньше страдать)?" отлично описывает одну итерацию управления ИБ.
2) Вред наносит только злоумышленник или иная активная сущность/явление (да хоть бы и потоп). Уязвимость вреда не наносит (пример: пятка у Ахилла как изъян в его защите). Потенциально вредоносное воздействие — это угроза. Не путать с атакой (см. далее).
3) Риск — вероятность совмещения угрозы и уязвимости
4) Атака — реализация угрозы через уязвимость, т.е. факт осуществления риска в реальности.
Это настолько печально, что всё вместе начинающему скорее повредит, чем поможет.
Вот только несколько моментов:
1) Сначала всегда строится модель системы (в первую очередь, защищаемых активов) и модель нарушителя (и угроз), потом все остальное. Иначе о безопасности говорить бессмысленно. Совершенно естественная цепочка вопросов "ЧТО ЕСТЬ (у нас)? --> КТО ЕСТЬ (не у нас)? + ЗАЧЕМ (они нас будут атаковать)? --> КАК (это может произойти и через какие дыры у нас)? --> ЧТО ДЕЛАТЬ (чтобы меньше страдать)?" отлично описывает одну итерацию управления ИБ.
2) Вред наносит только злоумышленник или иная активная сущность/явление (да хоть бы и потоп). Уязвимость вреда не наносит (пример: пятка у Ахилла как изъян в его защите). Потенциально вредоносное воздействие — это угроза. Не путать с атакой (см. далее).
3) Риск — вероятность совмещения угрозы и уязвимости
4) Атака — реализация угрозы через уязвимость, т.е. факт осуществления риска в реальности.
Все давно придумано. Дайте другу iso27003 и пусть по пунктам проходит и внедряет. Все четко разложено и без путаницы.
Единственное дам совет, если топ-менеджмент далек от ИТ, на первых этапах внедрения, не нужно сочинять толстые талмуты с заумными словами типа эксплоит, проникновение. Лучше сделать красивую презентацию и на пальцах, на пальцах.)
Единственное дам совет, если топ-менеджмент далек от ИТ, на первых этапах внедрения, не нужно сочинять толстые талмуты с заумными словами типа эксплоит, проникновение. Лучше сделать красивую презентацию и на пальцах, на пальцах.)
передать актив, подверженный риску (к примеру перенести сервера в дата-центр, таким образом за бесперебойное питание и физическую сохранность серверов будет ответственнен дата-центр).
Мне кажется, что перемещение серверов в дата-центр это передача риска — неудачный пример. На мой взгляд, передачей риска это будет, если дата-центр будет вам платить деньги, в случае отказа оборудования
Почему неудачный пример? Как раз-таки самый распространенный. Ведь проще заплатить кому-то, кто обязуется 24/7 поддерживать физически ваши сервера, чем самому городить отказоустойчивость.
То, что он распространненый, не делает его автоматически удачным:) Не претендую на истину в последний инстанции, но если у вас есть риск «Отказ сервера (поломка, отсутствие питания, др.).», то каким образом Вы передаете этот риск другой компании? Если у них, что-то сломается, то Ваш сервер выключится, то есть риск произойдет и Вы понесете потери от простоя сервера.
Это уже вопрос SLA с датацентром. Фактически датацентр дает гарантию, что сервер будет доступен 99,9% времени, указывают максимальное время восстановления питания и связи. И данный пример самый удачный как раз, потому как именно для передачи риска отказа связи и питания многие компании передают сервера датацентрам. Советую почитать про управление рисками и непрерывностью
В первом комментарии я как раз и написал
Вы часом не путаете передачу риска со снижением риска?
На мой взгляд, передачей риска это будет, если дата-центр будет вам платить деньги, в случае отказа оборудования
Вы часом не путаете передачу риска со снижением риска?
попробую еще раз и на пальцах: при передаче серверов в дата-центр вы, фактически, передаете обязанность по снижению риска отказа питания (к примеру) на датацентр. С момента передачи, датацентр обязуется обеспечить бесперебойное питание с заданным уровнем. Снижение риска, это если бы мы закупали упсы, генераторы и подводили вторую линию электропитания.
Возможно, я оцениваю риски с колокольни управления проектами, но мне кажется, что дата центр это все равно снижение риска, а не его передача.
Смотрите, простой сервера стоит нам 100 000 долларов в час, вероятность этого, допустим, 10%, то есть стоимость риска 10 000$. Закупив упсы, дизели и вторую линию электричества, мы можем снизить этот риск до 5%, отдав все на аутсорс дата-центру мы снижаем риск до 1%.
Но при этом, если дата-центр не несет никаких платежей, в случае отказа питания — это снижение риска. Если, за каждый час простоя они нам платят 1 000 долларов — это передача риска.
Не ИТ-шный пример: нужна машина, чтобы возить команду проекта к клиенту. Мы можем купить машину и взять водителя, но есть риск что машина сломается. Мы можем отдать нашу машину и водителя, какой-то субподрядной организации, которая будет каждый вечер проверять машину и мерять давления водителю (это меры по снижению риска, так как машина может все равно сломаться). А можем заключить договор с таксопарком, что они приезжают и возят нас (это передача риска, так как у них сто машин и даже если одна сломается, то они пришлю другую).
Смотрите, простой сервера стоит нам 100 000 долларов в час, вероятность этого, допустим, 10%, то есть стоимость риска 10 000$. Закупив упсы, дизели и вторую линию электричества, мы можем снизить этот риск до 5%, отдав все на аутсорс дата-центру мы снижаем риск до 1%.
Но при этом, если дата-центр не несет никаких платежей, в случае отказа питания — это снижение риска. Если, за каждый час простоя они нам платят 1 000 долларов — это передача риска.
Не ИТ-шный пример: нужна машина, чтобы возить команду проекта к клиенту. Мы можем купить машину и взять водителя, но есть риск что машина сломается. Мы можем отдать нашу машину и водителя, какой-то субподрядной организации, которая будет каждый вечер проверять машину и мерять давления водителю (это меры по снижению риска, так как машина может все равно сломаться). А можем заключить договор с таксопарком, что они приезжают и возят нас (это передача риска, так как у них сто машин и даже если одна сломается, то они пришлю другую).
У вас ужасная каша в голове, от этого идёт подмена понятий. Почитайте, что такое SLA, Business Continuity, Risk Management и тд.
Как правило в SLA указывается, что датацентр делает, если не может выдержать сроки по каким-либо причинам. И ваш пример с таксопарком еще более некорректен, ведь если вы арендуете сервер у датацентра и он внезапно отрубился, они не включат еще один с вашей информацией, а будут либо бекапы восстанавливать, либо старый поднимать. Тут совершенно разные процессы.
Хорошо, такой пример: вы страхуете своё здание, с таким расчётом, что в случае пожара/наводнения/обрушения, получите компенсацию, покрывающую расходы на поиск/аренду нового и упущенную прибыль за вынужденный простой. Это более правильно?
Как правило в SLA указывается, что датацентр делает, если не может выдержать сроки по каким-либо причинам. И ваш пример с таксопарком еще более некорректен, ведь если вы арендуете сервер у датацентра и он внезапно отрубился, они не включат еще один с вашей информацией, а будут либо бекапы восстанавливать, либо старый поднимать. Тут совершенно разные процессы.
Хорошо, такой пример: вы страхуете своё здание, с таким расчётом, что в случае пожара/наводнения/обрушения, получите компенсацию, покрывающую расходы на поиск/аренду нового и упущенную прибыль за вынужденный простой. Это более правильно?
1) Понять бизнес задачу.
2) Проработать релевантное решение
Инструментов решения много. Основной — стандарт ISO 27001 и другие дочки из серии 27000.
Можно использовать его как чеклист, выбирая необходимые блоки.
А вот конкретный пример процесса внедрения СУИБ по 27001.
Dejan Kosutic весьма грамотен в советах.
В целом, не советовал бы начинающим учиться по этой статье. Тут по каждому пункту можно комментировать.
Вероятно, автор описывает конкретный (свой) опыт для конкретной ситуации, вряд ли ценный для остальных.
2) Проработать релевантное решение
Инструментов решения много. Основной — стандарт ISO 27001 и другие дочки из серии 27000.
Можно использовать его как чеклист, выбирая необходимые блоки.
А вот конкретный пример процесса внедрения СУИБ по 27001.
Dejan Kosutic весьма грамотен в советах.
В целом, не советовал бы начинающим учиться по этой статье. Тут по каждому пункту можно комментировать.
Вероятно, автор описывает конкретный (свой) опыт для конкретной ситуации, вряд ли ценный для остальных.
Sign up to leave a comment.
Построение СУИБ: С чего начать?