Построение СУИБ: С чего начать?

    Доброго времени суток, уважаемые!
    Давно не писал на Хабр, не было времени, много работы было. Но теперь разгрузился и сформировались мысли для нового поста.

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

    Анализ рисков


    Практически всё в ИБ начинается с анализа рисков, это основа и начало всех процессов в безопасности. Проведу краткий ликбез в этой области, так многие понятия не очевидны и чаще всего путаются.
    Итак есть 3 основных понятия:
    • Риск
    • Вероятность реализации
    • Уязвимость


    Риск — это возможность понести какие-либо потери (денежные, репутационные и тд), в связи с реализацией уязвимости.
    Вероятность реализации — это насколько вероятно, что данная уязвимость будет эксплуатирована для реализации риска.
    Уязвимость — непосредственно брешь в вашей системе безопасности, которая с некоей долей вероятности может нанести вред, то есть реализовать риск.

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

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

    Масштабы


    В первую очередь, конечно же, необходимо оценить масштабы бедствия. Я не буду касаться моментов по защите персданных, по этому поводу уже куча статей, есть описанные не раз практические рекомендации и алгоритмы действий.
    Напомню также, что информационная безопасность — это в первую очередь люди, так что нужна нормативная документация. Что бы написать её, для начала нужно понять что туда вписывать.
    Основных документов для ИБ в этом плане 3:
    • Политика информационной безопасности
    • Концепция информационной безопасности
    • Положение о коммерческой тайне (конфиденциальной информации)


    Политика информационной безопасности

    Ваш основной документ, настольная книга, Библия и другие громкие названия. Именно в ней описаны все процедуры по ИБ, описан уровень безопасности, которому вы следуете в своей организации. Так сказать — идеальный срез безопасности, задокументированный и принятый по всем правилам.
    Политика не должна быть мертвым грузом, документ должен жить, должен изменяться под влиянием новых угроз, веяний в ИБ или пожеланий. В связи с этим политика (как, в принципе, и любой процессный документ) должна регулярно пересматриваться на предмет актуальности. Лучше делать это не реже 1 раза в год.

    Концепция информационной безопасности

    Небольшая выжимка из политики, где описаны основы безопасности вашей организации, нет никаких конкретных процессов, но есть принципы построения СУИБ и принципы формирования безопасности.
    Этот документ скорее имиджевый, он не должен содержать никакой «чувствительной» информации и должен быть открытым и доступным для всех. Разместите его на своём сайте, вложите в лоток на информационном стенде, что бы ваши клиенты и посетители могли с ним ознакомиться или просто видели, что вы заботитесь о безопасности готовы это продемонстрировать.

    Положение о коммерческой тайне (конфиденциальной информации)

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

    Аудит


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

    Политика доступа

    Тут 2 ветки — это физический доступ в помещения и доступ в информационные системы.

    Физический доступ

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

    Доступ в информационные системы

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

    Построение сети

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

    Удаленный доступ

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

    Инциденты

    Как они обрабатываются, кто ответственный и как построен процесс инцидент менеджмента и проблем менеджмента (если есть, конечно). По работе с инцидентами у меня уже был пост: habrahabr.ru/post/154405 можете ознакомиться подробнее.
    Так же необходимо определиться с трендами в вашей организации. То есть какие инциденты возникают чаще, какие несут больший вред (простой, прямые потери имущества или денег, репутационный вред). Это поможет в контроле рисков и проведении анализа рисков.

    Активы

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

    Обучение


    Момент, о котором многие забывают. Сотрудникам нужно рассказать о мерах безопасности. Не достаточно ознакомления с инструкциями и политиками под роспись, 90% их не прочитают, а просто распишутся, дабы отвязались. Про обучение я тоже делал публикацию: habrahabr.ru/post/154031 Там приведены основные моменты, важные при обучении и про которые не стоит забывать. Помимо непосредственно самого обучения, такие мероприятия полезны в плане общения между сотрудниками и офицером безопасности (красивое название, мне очень оно нравится :-). Можно узнать о каких-то мелких происшествиях, пожеланиях, да даже проблемах, про которые в обычном рабочем ритме вы вряд ли бы узнали.

    Заключение


    Вот, наверное, и всё, о чём хотелось поведать начинающим на поприще ИБ. Я понимаю, что подобным постом я, возможно, лишу какого-то своего коллегу работы, так как потенциальный работодатель просто возложит на админа эти обязанности, но я и огорожу многие организации от интеграторов-бракоделов, любящих выкачивать деньги за аудиты и пишущие многостраничные памфлеты ни о чём, выдавая их за нормативку (http://habrahabr.ru/post/153581/).
    В следующий раз постараюсь рассказать об организации службы информационной безопасности как таковой.

    P.S. если ставите минус, прокомментируйте, пожалуйста, дабы в будущем мне не допускать подобных ошибок.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 35

      0
      Начать следует с определения понятия «СУИБ» и целей и задач ее создания.
        +1
        Я указал, что статья рассчитана на неспециалиста в области ИБ, на которого руководство взвалило задачи по безопасности. Определение целей и задач СУИБ — дело третье в текущем разрезе. С одной стороны эта статья как помощь, что бы отвязаться от начальства, с другой стороны, что бы всё было сделано +- правильно, и не выглядело смешно и нелепо.
          0
          Вот как раз неспециалисту, если на него взвалили задачу по созданию СУИБ, тем более надо начинать с вопросов «что вы хотите в результате».
            0
            Минимизация рисков — вот основная цель СУИБ как таковой.
              0
              Каких? В отношении чего?
                0
                А это выясняется на основании анализа рисков.
                  0
                  То есть вы предлагаете строить систему, цели которой выясняются в ходе ее же постройки?
                    0
                    Цель — минимизация рисков, как таковых. Любая организация имеет такие, по факту. От каких конкретно рисков и как защищать — выясняется на подготовительном этапе анализа рисков.
                    И повторюсь еще раз, статья рассчитана на тех, кому сверху упало указание — сделать безопасно!
                      0
                      «сделать безопасно» и «создать СУИБ» — это две немного разные вещи, как мне кажется. Меня, собственно, слово «система» больше всего смущает.
                        0
                        Ок, в вашем понимании СУИБ — что такое?
                          0
                          У меня нет этого понимания, и после вашей статьи тоже не появилось. Это меня и фрустрирует.
                            0
                            У меня не было цели рассказать, что такое СУИБ и для чего. Я рассказал, что делать, если руководство сказало «сделать безопасно». Собственно то, что представлено в этой статье, это рекомендации по построению системы управления безопасностью. То есть фактически безопасность в некоем роде есть, но о ней не знают (точнее не знают, что это относится к ИБ), работа эта не структурирована и не описана. А по логике процессного подхода, если процесс не описан, то его нет!
                            У меня не было задачи описывать, начиная с дебрей — с понятий, назначений и тд. Я сказал как можно сделать, максимально красиво с минимумом затрат.
                            Это один из подходов и не претендует на абсолютную истину.
                              0
                              Собственно, именно поэтому ваш пост следует назвать «что делать, если руководство сказало „сделать безопасно“».
                                0
                                Собственно в статье и рассказано, как создать СУИБ, то есть сделать безопасно.
                                  0
                                  Для того, чтобы приравнять «сделать СУИБ» к «сделать безопасно», нужно объяснить, что такое СУИБ.
                                    0
                                    Мы пошли по второму кругу, так что я просто посоветую, еще раз перечитать мои комментарии и саму статью!
              • UFO just landed and posted this here
          0
          Начать следует, как по мне, с выяснения, какие есть активы, их категоризировать — то есть присвоить грифы, и потом согласно категориям и выяснять, какие риски для каких активов имеются в наличие.
            +1
            В статье совершенно не встречаются термины «злоумышленник» или «нарушитель» или их аналоги, «угроза» упоминается всего один раз и без комментариев, а уязвимость, оказывается, сама по себе "… может нанести вред, то есть реализовать риск"!
            Это настолько печально, что всё вместе начинающему скорее повредит, чем поможет.

            Вот только несколько моментов:
            1) Сначала всегда строится модель системы (в первую очередь, защищаемых активов) и модель нарушителя (и угроз), потом все остальное. Иначе о безопасности говорить бессмысленно. Совершенно естественная цепочка вопросов "ЧТО ЕСТЬ (у нас)? --> КТО ЕСТЬ (не у нас)? + ЗАЧЕМ (они нас будут атаковать)? --> КАК (это может произойти и через какие дыры у нас)? --> ЧТО ДЕЛАТЬ (чтобы меньше страдать)?" отлично описывает одну итерацию управления ИБ.
            2) Вред наносит только злоумышленник или иная активная сущность/явление (да хоть бы и потоп). Уязвимость вреда не наносит (пример: пятка у Ахилла как изъян в его защите). Потенциально вредоносное воздействие — это угроза. Не путать с атакой (см. далее).
            3) Риск — вероятность совмещения угрозы и уязвимости
            4) Атака — реализация угрозы через уязвимость, т.е. факт осуществления риска в реальности.
              0
              Чем же в данном примере может навредить терминология?
              Для общего понимания этого вполне достаточно!
              • UFO just landed and posted this here
                0
                Ещё есть такая штука, как бездействие. Бездействием можно иногда тоже навредить не меньше, чем действием. Вспоминаем некоторые статьи законодательства, не помню какие кодексы уже.
                +1
                Все давно придумано. Дайте другу iso27003 и пусть по пунктам проходит и внедряет. Все четко разложено и без путаницы.
                Единственное дам совет, если топ-менеджмент далек от ИТ, на первых этапах внедрения, не нужно сочинять толстые талмуты с заумными словами типа эксплоит, проникновение. Лучше сделать красивую презентацию и на пальцах, на пальцах.)
                  0
                  передать актив, подверженный риску (к примеру перенести сервера в дата-центр, таким образом за бесперебойное питание и физическую сохранность серверов будет ответственнен дата-центр).


                  Мне кажется, что перемещение серверов в дата-центр это передача риска — неудачный пример. На мой взгляд, передачей риска это будет, если дата-центр будет вам платить деньги, в случае отказа оборудования
                    0
                    Почему неудачный пример? Как раз-таки самый распространенный. Ведь проще заплатить кому-то, кто обязуется 24/7 поддерживать физически ваши сервера, чем самому городить отказоустойчивость.
                      0
                      То, что он распространненый, не делает его автоматически удачным:) Не претендую на истину в последний инстанции, но если у вас есть риск «Отказ сервера (поломка, отсутствие питания, др.).», то каким образом Вы передаете этот риск другой компании? Если у них, что-то сломается, то Ваш сервер выключится, то есть риск произойдет и Вы понесете потери от простоя сервера.
                        0
                        Это уже вопрос SLA с датацентром. Фактически датацентр дает гарантию, что сервер будет доступен 99,9% времени, указывают максимальное время восстановления питания и связи. И данный пример самый удачный как раз, потому как именно для передачи риска отказа связи и питания многие компании передают сервера датацентрам. Советую почитать про управление рисками и непрерывностью
                          0
                          В первом комментарии я как раз и написал
                          На мой взгляд, передачей риска это будет, если дата-центр будет вам платить деньги, в случае отказа оборудования


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

                              Смотрите, простой сервера стоит нам 100 000 долларов в час, вероятность этого, допустим, 10%, то есть стоимость риска 10 000$. Закупив упсы, дизели и вторую линию электричества, мы можем снизить этот риск до 5%, отдав все на аутсорс дата-центру мы снижаем риск до 1%.

                              Но при этом, если дата-центр не несет никаких платежей, в случае отказа питания — это снижение риска. Если, за каждый час простоя они нам платят 1 000 долларов — это передача риска.

                              Не ИТ-шный пример: нужна машина, чтобы возить команду проекта к клиенту. Мы можем купить машину и взять водителя, но есть риск что машина сломается. Мы можем отдать нашу машину и водителя, какой-то субподрядной организации, которая будет каждый вечер проверять машину и мерять давления водителю (это меры по снижению риска, так как машина может все равно сломаться). А можем заключить договор с таксопарком, что они приезжают и возят нас (это передача риска, так как у них сто машин и даже если одна сломается, то они пришлю другую).
                                –1
                                У вас ужасная каша в голове, от этого идёт подмена понятий. Почитайте, что такое SLA, Business Continuity, Risk Management и тд.

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

                                Хорошо, такой пример: вы страхуете своё здание, с таким расчётом, что в случае пожара/наводнения/обрушения, получите компенсацию, покрывающую расходы на поиск/аренду нового и упущенную прибыль за вынужденный простой. Это более правильно?
                                  0
                                  А как Вы оцениваете, что у меня каша в голове?

                                  Со страхованием — это передача риска, без сомнения. С дата-центром — зависит от SLA, как я уже три раза и написал.
                                    0
                                    Про SLA писал я :-)
                                  • UFO just landed and posted this here
                      +1
                      1) Понять бизнес задачу.
                      2) Проработать релевантное решение

                      Инструментов решения много. Основной — стандарт ISO 27001 и другие дочки из серии 27000.
                      Можно использовать его как чеклист, выбирая необходимые блоки.
                      А вот конкретный пример процесса внедрения СУИБ по 27001.
                      Dejan Kosutic весьма грамотен в советах.

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

                      Only users with full accounts can post comments. Log in, please.