25 февраля, четверг 07:49
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Пересечение полномочий ИТ и ИБ

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Пересечение полномочий ИТ и ИБ

    Стоит вопрос об установке сертификатов на процессинг, сервера ИТшные и по регламенту только они имеют права доступа.
    Встал вопрос о передачи части прав на ИБ, связано со сменой сертификатов. Соответственно ИБ будут нужны права локаладмина. До сего момента установку сертификатов проводили ИТ. А генерацию/регистрацию ИБ. Теперь предлагается смену тоже проводить ИБ.
    Лично я сторонник максимального разграничения прав ИТ и ИБ (полное разграничение невозможно впринципе, к сожалению.). В данном случае имею ввиду, что ИБ предоставляет кл. инф. и контроллирует ее введение в бой, а ИТ вводит ее в бой и не нарушает непрерывность функционирования системы, за которую ИТ отвечает.
    Хотелось бы узнать Ваши мнения конкретно по данной ситуации. Спасибо.
    Последний раз редактировалось tsv_and; 02.07.2013, 10:15.

  • #2
    С точки зрения СТО БР, по-идее, ИБ даже генерить ничего не должно, только контролировать.


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

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

    Комментарий


    • #3
      7.8.7. Обязанности по администрированию средств защиты платежной информации рекомендуется возлагать приказом или распоряжением по организации БС РФ на администраторов ИБ с отражением этих обязанностей в их должностных инструкциях.
      здесь под администрированием предполагается в т.ч. установка сертификатов?

      Комментарий


      • #4
        tsv_and, В данном контексте - Администратор ИБ, это не ИБшник, это по сути название роли, ее можно возложить на кого угодно, как на ИБ, так и на ИТ.
        Правильным, на мой взгляд будет такое распределение ролей (если 2 и более ИБ-шника в организации) - один генерит ключи, регистрирует их, передает пользователю, ведет журнал (это администратор ИБ). Второй осуществляет контрольные функции над первым и над ИТ. ИТ-шники устанавливают ПО СКЗИ и подгружают сертификаты ключей.

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

        Комментарий


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

          Комментарий


          • #6
            Сообщение от Sascha Посмотреть сообщение
            Если ИБ-шник один, то при назначении его администратором ИБ, начинается совмещение ролей - он и генерит и контролирует одновременно, а это уже повышает риски.
            Прошу прощения, а где вы в п. 7.2.3 СТО БР ИББС увидели запрет быть Администратором ИБ и контролировать выполнение операций? Там же попарно дано то, что не рекомендуется совмещать.

            Сообщение от tsv_and Посмотреть сообщение
            У нас такая ситуация, что ИТ хочет скинуть свой функционал (установку сертификатов) на ИБ. Дело не в том как организовать, уже все давно организованно и работает. А ИТшники хотят отказаться от существующей и оптимальной на мой взгляд модели.
            Тут спорно. Работа с СКЗИ требует некоторой компетенции (а в некоторых случаях даже образования), тем более в таких тонких вопросах как "процессинг". Не во всяком банке ИТ могут поддерживать необходимую компетенцию на должном уровне. Поэтому, если у вас есть ИТшник/и, который/е в теме и вы понимаете, что он/они сделает/ют всё правильно смело им делегируйте администрирование. Если нет, то придётся тянуть лямку самому.
            Последний раз редактировалось Zuz; 03.07.2013, 00:55.

            Комментарий


            • #7
              Zuz,
              7.2.3.....выполнения операций в системе и контроля их выполнения.
              На мой взгляд это как раз и есть - генерация ключей и пр. операции с ними и контроль этих действий. В таком случае получается, что ИБ будет выполнять все работы с ключами и тут же сам себя контролировать. А это уже совмещение и потенциальная компрометация ключей.
              И опять же, для установки ключей ИБ надо будет наделять правами администратора на тех узлах, куда будут устанавливаться ключи, а это еще больше повысит операционные риски. Я не думаю, что такой расклад понравится ЦБ.

              Комментарий


              • #8
                Сообщение от Sascha Посмотреть сообщение
                Zuz,
                На мой взгляд это как раз и есть - генерация ключей и пр. операции с ними и контроль этих действий. В таком случае получается, что ИБ будет выполнять работы с ключами и тут же сам себя контролировать. А это уже совмещение и потенциальная компрометация ключей.
                Простите, но это выдумка. ) Так можно много чего вычитать в стандарте. )
                В первую очередь 7.2.3 говорит о том, что не рекомендуется совмещать в одной роли.
                Роль администратора ИБ (т.е. в данном случае того, кто администрирует средства защиты) не должна совмещается с ролью администратора (тут может много ролей быть применительно к "процессингу" Администраторы ОС, АБС, СУБД и пр.). А операции, это, обычно, какие-то всё же осмысленные бизнес-операции, типа проводки документа (см. банковский технологический/ платежный / информационный процесс) или операции по управлению, например, доступом. Контролируются опять же именно операции в банковских технологических процессах, где осуществляется взаимодействие персонала со средствами и системами автоматизации (5.12, 7.8.6, 7.8.8).
                Так же рекомендация дана с целью снижения рисков нарушения ИБ. Исходя из этого и распределяйте роли. Кому и как вы назначите роли ИТ или ИБ, я уже пояснял, всё зависит от того, на кого вы можете назначить эти роли (где какая компетенция), если в ИТ есть нормальные специалисты, конечно делегируйте им всё по максимуму. )

                Что касается контроля я не совсем понял о какой "компрометации ключей" речь, поясните? А, так же не совсем понял какой контроль может быть для: "Стоит вопрос об установке сертификатов на процессинг, сервера ИТшные и по регламенту только они имеют права доступа". Было бы, кстати, интересно узнать, что это за сертификаты такие и в чём суть операции. В процессинге обычно ключики, в т.ч. и сертификаты с соответствующими ключами живут в HSM.

                Комментарий


                • #9
                  Установка сертификатов, читай обслуживание системы. Установка сертификатов не требует особых навыков, вопрос в адм. доступе на ресурсы ИТ сотрудниками ИБ, читай пересечение зон ответственности - уже плохо. Настройка процессинга лежит на ИТ по регламенту. Соответственно вопрос о квалификации сотрудников ИБ для работы с системой процессинга открыт. Соответственно корректную установку сертификатов в систему с минимальным риском ее остановить способны обеспечить сотрудники ИТ, а не сотрудники ИБ, т.к. обслуживают систему ИТ. Генерация ключей/регистрация ключей в сервисе/запрос и получение ключей, читай безопасность. ИТ производит установку и настройку среды/ПО. ИБ, путем предоставления ключей ИТ и контроля их установки в систему, обеспечивает организацию защищенной среды/канала связи для функционирования обмена с минимальным риском завалить систему.
                  Такой подход вроде как идеально вписывается в стандарты и законы, при том что риск сведен к минимуму, нет пересечения зон ответственности, есть только адекватное сотрудничество между ИБ и ИТ.

                  Комментарий


                  • #10
                    Сообщение от tsv_and Посмотреть сообщение
                    Установка сертификатов, читай обслуживание системы. Установка сертификатов не требует особых навыков, вопрос в адм. доступе на ресурсы ИТ сотрудниками ИБ, читай пересечение зон ответственности - уже плохо.
                    "Установка сертификата" (так и не пояснили, что именно тут имеется в виду) - это сопровождение системы или администрирование. Установка часто требует особых навыков, нужно понимать что делаешь. Например, в HSM установка может требовать как раз ещё и офицера безопасности, со своим отдельным паролем.

                    Сообщение от tsv_and Посмотреть сообщение
                    Настройка процессинга лежит на ИТ по регламенту. Соответственно вопрос о квалификации сотрудников ИБ для работы с системой процессинга открыт. Соответственно корректную установку сертификатов в систему с минимальным риском ее остановить способны обеспечить сотрудники ИТ, а не сотрудники ИБ, т.к. обслуживают систему ИТ.
                    Как я уже писал всё зависит, что и как устанавливать и настраивать. Если это *.pem файлик положит куда-то и по регламенту настройки в ПО поправить - это одно, если это HSM, то не всегда за него ИТ отвечают, ибо завалить можно всю железку не зная чего делаешь.

                    Сообщение от tsv_and Посмотреть сообщение
                    Генерация ключей/регистрация ключей в сервисе/запрос и получение ключей, читай безопасность. ИТ производит установку и настройку среды/ПО. ИБ, путем предоставления ключей ИТ и контроля их установки в систему, обеспечивает организацию защищенной среды/канала связи для функционирования обмена с минимальным риском завалить систему.
                    Такой подход вроде как идеально вписывается в стандарты и законы, при том что риск сведен к минимуму, нет пересечения зон ответственности, есть только адекватное сотрудничество между ИБ и ИТ.
                    Если действительно ИТ всё делает правильно и понимает, что таскать на флешке копию сертификата с ключами уже после проведения установки, а потом её благополучно потерять - нельзя, то, да - это отличный вариант.

                    Комментарий


                    • #11
                      Имелась в виду именно зона ответственности ИТ. В данном конкретном случае установка сертификатов как раз требует квалификации ИТ а не ИБ, т.к. нужно знать линуксовые команды, этими командами что куда класть, в каком файле настроек чего менять и правильно т.е. безболезненно перезапускать службы.
                      А касательно ключей на флешках, девайс локом рулим мы, следовательно унести их можно только используя в противозаконном ключе свою смекалку и эрудицию. Вдобавок нужно быть по жизни догадливым чтобы угадать за разумное время достаточно длинный пароль к ключу.

                      Комментарий


                      • #12
                        Сообщение от tsv_and Посмотреть сообщение
                        Имелась в виду именно зона ответственности ИТ. В данном конкретном случае установка сертификатов как раз требует квалификации ИТ а не ИБ, т.к. нужно знать линуксовые команды, этими командами что куда класть, в каком файле настроек чего менять и правильно т.е. безболезненно перезапускать службы.
                        Интересно, а ваши специалисты по ИБ специалистам по ИТ на слово верят? А "линуксовые команды" воспринимают как магию? )))
                        Квалификация среднего специалиста по ИБ в большинстве случае гораздо шире, она может быть менее глубокой, но чтобы, что-то контролировать, нужно знать систему и всё окружение очень даже хорошо.

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

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

                        В противном случае лучше, если критически важные операции выполнит безопасник с правильным ходом мыслей. Пусть для этого ему придётся выучить "линуксовые команды" и понять как устроена система (хотя, на мой взгляд, он и так это должен знать).

                        P.S. И, да, если у вас DeviceLock на сервере и там linux, то я, видимо, отстал от жизни. А ещё, когда вы говорите о распределении полномочий и говорите о том, что сами рулите девайслоком, то это означает, что у вас есть, как минимум, полномочия для его установки = локальный администратор. Тогда о каком разделении полномочий тут может идти речь? Раз вы локальный админ на всех машинах, где девайслок. )))

                        P.P.S. Я нисколько не возражаю, против того, что у вас всё хорошо на бумаге, и вы очень правильно распределили полномочия, но я не верю, что это воплощено в практику и работает. Если же это так, то вам жутко повезло.
                        Последний раз редактировалось Zuz; 14.07.2013, 15:28.

                        Комментарий


                        • #13
                          В мои обязанности не входит управление девайс-локом, (это обязанность других сотрудников ИБ). Я отвечаю за криптографию. Но, если интересно, то на тех серверах нету возможности подключать съемные носители впринципе. Работа с сервером, производится удаленно с компьютера с виндой на котором стоит ДЛ. Линуксовые команды мы как магию не воспринимаем и пароль на флешке не передаем (корп. эл. почта в запароленном архиве, пароль от архива по телефону). Пароль к ключу вводит специалист ИБ (в часности я), когда следит удаленно через радмин за ходом установки ключей.
                          Линукс кстати я немного знаю, на предыдущей работе познакомился с ним. Но для общего понимания того, что происходит мне хватает. Контроль осуществляется тем, что при мне ставят ключи и подтверждают что поставили. После этого ответственность за последующие сбои в работе с системой (например если я, слабо знающий линукс, не проследил что они не перезапустили как надо службы) несут специалисты ИТ. Наше дело предоставить а их - корректно установить.
                          Про "на слово верят" я, если честно, не понял о чем речь.
                          По поводу специалистов ИТ. Им не надо быть сознательными (хотя они весьма сознательные, но исходить необходимо из худшего), т.к. определенную информацию (напр. пароли от ключей) им просто никто не предоставляет.
                          На пятый день жизни этой темы подход опробован и себя оправдал, так что выходит, что нам повезло спасибо!

                          Комментарий


                          • #14
                            tsv_and, "на слово верят" - это, про то, что я не предполагал, что вы "свечку держите", т.е. смотрите в радмин. ))) А вообще, достаточно интересно, если вы расскажите про весь процесс в комплексе, т.к. решаю подобную задачу и удовлетворительного решения пока не нашёл ибо суперюзеры могут всё.
                            Так же интересно, что по вашему на том или ином шаге есть контроль. На мой взгляд, гораздо интереснее - где именно лежат ключики, какие права на эти файлы, есть ли там аудит доступа к этим файлам, где хранится пароль, и т.п.

                            Комментарий

                            Обработка...
                            X