1 апреля, среда 21:15
Bankir.Ru

Объявление

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

382-П

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

  • Сообщение от saches Посмотреть сообщение
    А что....-то говорит, если не секрет?
    устранить нарушение, проявляет обеспокоенность, правда в чем и что конкретно надо исправить не уточняет, цитирует 382-П, даже без привязок к ВНД и конкретики нарушения... горестно как то созерцать такое ...

    Комментарий


    • Сообщение от Berckut Посмотреть сообщение

      У меня плохие новости: без толку выяснять, потому что всё будет зависеть от того, как это понимают проверяющие. А у них фантазия богатая
      Как ни печально, но это факт! И даже аудит, предварительно проведенный с актом красивым не указ. Собственно причина для спора пустяковая, внести в ДИ одного ИТ_шника запрет модернизации, вписав "работы по эксплуатации".

      Комментарий


      • Сообщение от IgorL Посмотреть сообщение
        причина для спора пустяковая
        Согласен. Тут даже нет предмета для споров, но к сожалению нечеткость трактовок и субъективизм мнений вызывает нездоровые практики указывать одним, что "надо" делать другим...причем без восприятия возражений и пояснений...

        Комментарий


        • Сообщение от Павлоний Посмотреть сообщение

          ...практики указывать одним, что "надо" делать другим...причем без восприятия возражений и пояснений...
          Работавшие в органах или служившие в армии воспринимает это легче. Сделали замечание - устранил. Если замечание пустяковое даже с радостью! ;-)

          Комментарий


          • Сообщение от IgorL Посмотреть сообщение
            даже с радостью!
            Так и действуем )

            Комментарий


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

              Комментарий


              • Сообщение от UserNick Посмотреть сообщение
                можно привести такие контраргументы:
                А зачем?
                Гораздо выгоднее принять и устранить замечание.
                + проверяющий доволен
                + проверяющий план выполнил и дальше копать не будет
                + доложить руководству, что нашли только одно пустяковое несоответствие и мы его устранили (какие мы молодцы!)

                Комментарий


                • Сообщение от ost Посмотреть сообщение
                  Гораздо выгоднее принять и устранить замечание.
                  Я пытался дать совет на вопрос заданный в контексте исходного поста

                  Сообщение от Павлоний Посмотреть сообщение
                  Обращение к экспертному сообществу... возникли споры в представителями Регулятора...
                  To: ost Ваш совет из области стратегии тоже вполне разумный.
                  Но может быть там замечаний сделанных ради замечаний и так хватает
                  Мой совет можно использовать как для дискуссии с проверяющим так и при устранении замечания.

                  Комментарий


                  • Провели вебинар среди банков о грядущих изменениях в Положение Банка России № 382-П.
                    Презентацию в pdf выложили сюда: https://vk.com/legalbifit
                    Запись вебинара после новогодних праздников опубликуем там же.

                    Комментарий


                    • Сообщение от malotavr Посмотреть сообщение

                      Сертификация на ОУД4 - это, как минимум, год работы. Поэтому случаи, когда АБС пройдет сертификацию, можно считать крайне редким исключением, а само требование - требованием о проведении анализа уязвимостей. И да, ОУД.4 требует анализа исходников.
                      А для начала, - тестирование функционального соответствия. Как ни переименовывай части целого, получается, что изменение функциональности АРМов по вводу/обработке платежей и той половинки АБС, в которой платежи хранятся ("учетного ядра"), в части как минимум относящейся к вводу, хранению и обработке платежной информации, - это обязательная переоценка их соответствия в том же самом объеме.

                      Для простоты, предположим, что разработчики АБС все как один уже отделили "учетное ядро" от "системы сбора отчетности", в смысле данные ядра пушатся в базу отчетности, и АРМы отчетников, финмониторинга и прочего внутреннего контроля к изменению информации о переводах доступа не имеют даже теоретически. Также предположим, что вкладной и кредитный модули тоже выделены отдельно и обмениваются с учетным ядром не прямыми записями в таблицы БД, а форматными сообщениями через шину данных, аналогичными сообщениям банкклиента. Про устойчивость такой конструкции я даже думать не хочу, но, допустим, всё это так и есть.

                      Во-1, довольно много изменений в отчетности должно быть поддержано добавлением/изменением атрибутов и/или справочников допустимых значений учетного ядра.
                      Во-2, изменения в самом по себе УФЭБС, которые тоже минимум 2 раза в году наступают, прибавить сюда регулярные внесистемные изменения в реквизитном составе и порядке заполнения бюджетных, налоговых и коммунальных платежей.

                      Если уж вспоминать PCI-DSS, то заодно надо вспомнить, сколько времени занял например переход с пластика на чиповые карты. Сколько времени заняло внедрение NFC. Сколько времени уже заняло и как проходит внедрение НСЕ.

                      А допустим переход с MT100 на MT103.

                      А тут тыц-бамс, давайте операторы по переводу денежных средств, обеспечьте да не ОУД1, а прямо ОУД4 в выполнении хотелок, которые мы меняем с легкостью по 2 раза в году. Где имение, а где вода. Хотелось бы надеяться, что это не пройдёт антикоррупционной экспертизы, раз уж прочие наши регуляторы в области безопасности насмерть ушиблены военным коммунизмом 100 лет назад. Но скорее всего, - пройдёт
                      /kiv

                      Комментарий


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

                        Комментарий


                        • Сообщение от saches Посмотреть сообщение
                          Т.е., конкретизируя ситуацию при возможных изменениях в прикладном ПО, накатывание любого патча может потребовать проведение очередного контроля или обоснования, почему именно с этим патчем такой контроль не требуется.
                          Любого или не любого зависит от реализации программной архитектуры АБС и ДБО.

                          Господа, а чем собственно рискуем? Минус чуть чуть в итоговом результате оценки по 202 форме? А на второй чаше весов регулярные миллионные затраты. Оценка рисков и тыдымц куда идут такие требования? А для успокоения амбиций великого мегарегулятора можно нарисовать план мероприятий со сроком исполнения в ближайшем столетии.

                          Комментарий


                          • Сообщение от UserNick Посмотреть сообщение
                            Любого или не любого зависит от реализации программной архитектуры АБС и ДБО.......
                            Именно это и имелось в виду.

                            Комментарий


                            • Сообщение от UserNick Посмотреть сообщение
                              А для успокоения амбиций великого мегарегулятора можно нарисовать план мероприятий со сроком исполнения в ближайшем столетии.
                              Пока это работает... )))

                              Комментарий


                              • Сообщение от Zuz Посмотреть сообщение
                                Пока это работает... )))
                                У нас нет.
                                Будут требовать отчитаться от устранении, а т.к. требовать долго они не могут, то и план с такими сроками не согласуют. Максимум - до конца года растянуть дадут.

                                Комментарий


                                • Сообщение от Илюха Посмотреть сообщение

                                  Хотелось бы надеяться, что это не пройдёт антикоррупционной экспертизы...
                                  На заседании ПК1 ТК122 А.М. Сычев сказал, что со ФСТЭК редакция изменений в 382-П уже согласована, сейчас находится на согласовании с ФСБ. После согласования отправят в Минюст на утверждение. Т.ч. шансы не утверждения, действительно, малы

                                  По-моему, с ходу требовать от банков или разработчиков ПО анализ уязвимостей по ОУД4 - слишком жестко. Мало того, многие испытательные лаборатории даже примерную стоимость анализа уязвимостей на данный момент нам затрудняются озвучить.

                                  Комментарий


                                  • Сообщение от Berckut Посмотреть сообщение
                                    Максимум - до конца года растянуть дадут.
                                    Это да, но потом начинается бесконечный перенос сроков, хотя очень сложно, конечно, их обосновывать (чаще всего можно на подрядчика кивать, мол заказали нормативку, а они делали дольше), на 2 года удавалось растянуть.
                                    Затем снижение оценки можно объяснить деградацией процессов и внедрённых решений. )))

                                    У меня сейчас другая проблема: пришло предписание предоставить отчёт в целях подтверждения выполнения требований по 382-П с 15.01.2016 по 15.01.2018.
                                    Причём отчёт нужно предоставить до 15.01.2018 (но отчёт должен включать этот период, что уже коллизия).
                                    Последняя самооценка у меня была в летом 2017. Период с лета по 15.01.2018 не охвачен.
                                    Всё это звучит так, как будто нужно за неохваченный период провести проверку и заново сформировать все свидетельства. Но на всё дано 4 рабочих дня!
                                    Что думаете?

                                    Комментарий


                                    • Сообщение от nos313 Посмотреть сообщение
                                      По-моему, с ходу требовать от банков или разработчиков ПО анализ уязвимостей по ОУД4 - слишком жестко.
                                      Вопрос в том, что будет банку за невыполнение. А стоимость может быть действительно значительная.

                                      Комментарий


                                      • Сообщение от Zuz Посмотреть сообщение
                                        Вопрос в том, что будет банку за невыполнение. А стоимость может быть действительно значительная.
                                        Как я услышал, наличие/отсутствие сертификата/ОУД4 и результаты аудита будет влиять на коэффициенты по страхованию киберрисков. Которое планируется создать по типу страхования вкладов АСВ.

                                        Комментарий


                                        • Сообщение от nos313 Посмотреть сообщение
                                          По-моему, с ходу требовать от банков или разработчиков ПО анализ уязвимостей по ОУД4 - слишком жестко. Мало того, многие испытательные лаборатории даже примерную стоимость анализа уязвимостей на данный момент нам затрудняются озвучить.
                                          Как то сложно представить компромиссный вариант. Тут или требовать или не требовать. Другое дело, что разработчик может честно поделить дополнительные затраты на всех клиентов, при этом частично или полностью оплатить их за счет стоимости техподдержки, а может под видом реализации "эксклюзивных" требований "экзотического" 382-П пытаться отбить затраты с каждого клиента предлагая их оплатить как "индивидуальную хотелку". Разное отношение приходилось наблюдать.

                                          Комментарий


                                          • Сообщение от Zuz Посмотреть сообщение
                                            У меня сейчас другая проблема: пришло предписание предоставить отчёт в целях подтверждения выполнения требований по 382-П с 15.01.2016 по 15.01.2018.
                                            Причём отчёт нужно предоставить до 15.01.2018 (но отчёт должен включать этот период, что уже коллизия).
                                            Последняя самооценка у меня была в летом 2017. Период с лета по 15.01.2018 не охвачен.
                                            Всё это звучит так, как будто нужно за неохваченный период провести проверку и заново сформировать все свидетельства. Но на всё дано 4 рабочих дня!
                                            Что думаете?
                                            Нам тоже пришло, но смысл был иной - предоставить отчёт, сформированный по результатам самооценки, проведённой в период с 15.01.2016 по 15.01.2018. Новую проверку никто проводить не требовал.

                                            Комментарий


                                            • Сообщение от Berckut Посмотреть сообщение
                                              период с 15.01.2016 по 15.01.2018
                                              мб выявляют тех, кто нарушает требование проведения оценки не реже 1 раза в 2 года. хотя для этого есть 202-я отчетность..

                                              Комментарий


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

                                                Комментарий


                                                • Сообщение от UserNick Посмотреть сообщение

                                                  Как то сложно представить компромиссный вариант. Тут или требовать или не требовать. Другое дело, что разработчик может честно поделить дополнительные затраты на всех клиентов, при этом частично или полностью оплатить их за счет стоимости техподдержки, а может под видом реализации "эксклюзивных" требований "экзотического" 382-П пытаться отбить затраты с каждого клиента предлагая их оплатить как "индивидуальную хотелку". Разное отношение приходилось наблюдать.
                                                  Вопрос больше к тому а что за код нужно сертифицировать? АБС без поддержки кастомного кода в реалиях наших постоянно меняющихся требований никому не нужна. И код этот кастомный может как раз основные каки и содержать, начиная от спецкомиссий по прибитых гвоздями счетов/клиентов до уникальных схем отпраок по ним же. Самые что ни на есть НДВ - разработчик вообще и знать то не знает про такие финты. А сколько налеплено сбоку на батниках или прямыми инсёртами/апдейтами баз? Может получиться что каждому банку нужно идти за оценкой уровня доверия в лабу. Да еще и разработчика время покупать, на разъяснения кишочков. Сопровождение по ГОСТ штука тоже сильно дороже, техподдержка вырастет в стоимости и хорошо если на проценты а не на порядки. (((

                                                  Комментарий


                                                  • Кстати, если вдруг кому интересно. Я уже не раз замечал, что наши внезапные иррациональные новации (в частности, на улицах и в метро столицы, но не ограничиваясь) проще всего понять, предположив прямое заимствование из Европы (в духе указов Петра 1: суть выкинуть, оболочку оставить). Вот и 161-ФЗ с 382-П не оказались исключениями, сегодня, разыскивая как бы мне попрямее сделать SSO для клиентов инфосервиса, случайно наткнулся на обзор

                                                    https://medium.facilelogin.com/turni...i-7eefebd7945a

                                                    С интересом начал читать (включая разумеется references therein), там есть нетривиальные вещи, продолжу в выходные.
                                                    Предупреждение. Требуется знание английского.
                                                    /kiv

                                                    Комментарий


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

                                                      Комментарий


                                                      • Сообщение от IgorL Посмотреть сообщение
                                                        Причем в самых первых редакциях (в основном еще до публикации) новации как раз рациональные.
                                                        Да.
                                                        Ещё рекомендую посмотреть статью на РБК https://www.rbc.ru/technology_and_me...79475bf73470c1

                                                        Операторы связи и члены «открытого правительства» намерены кардинально изменить законодательство в сфере ИT и связи. Они приступили к созданию Инфокоммуникационного кодекса, который будет регулировать индустрию
                                                        Может быть создадут внятное законодательство в сфере ИT и связи.

                                                        Комментарий


                                                        • Сообщение от ost Посмотреть сообщение
                                                          Может быть создадут внятное законодательство в сфере ИT и связи.
                                                          Если журналисты ничего не наврали, та же фигня, что и с пресловутыми персданными: вместо сути (человек-субъект (а) знает когда, кому, кем и на каком основании передавались его данные (б) лично решает кому, для какой цели и на какой срок их сообщить, если это не установлено специальным законом (в) при нарушении условий имееет права и преимущества ), какие-то абстрактные сообщения в вакууме, которые сами по себе служат предметом лицензирования с регулированием, материалом для проверок и основанием для штрафов и запрещений.

                                                          /kiv

                                                          Комментарий


                                                          • Краткий обзор прошедшего Уральского форума http://nos313.blogspot.ru/2018/02/2018-ibbank.html
                                                            Обсуждались в том числе и изменения в 382-П, новый ГОСТ 57580.1, закон об Antifraud, КИИ.

                                                            Комментарий


                                                            • Итоги пилотного проекта по аудиту выполнения требований Положения 382-П в одном из московских банков https://nos313.blogspot.com/2018/03/382.html

                                                              Комментарий

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