27 октября, вторник 00:51
Bankir.Ru

Объявление

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

Аудит IT-систем и подразделенийV

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

  • #31
    А не подскажет ли мне кто-нибудь каких-нибудь курсов или семинаров по аудиту ИС или хотя бы безопасности... Желательно в Москве...
    Хочется съездить, пока есть возможность..
    Спасибо!!

    ------------------
    Удача любит подготовленный разум...
    Удача любит подготовленный разум...

    Комментарий


    • #32
      Внимание!

      Сайт ISACA Russia chapter переехал на постоянный адрес
      http://www.isaca-russia.ru

      Константин

      Комментарий


      • #33
        Здравствуйте!
        Хотелось бы узнать, делаете ли Вы какие-либо периодические, систематические проверки инфосистем в Вашем банке. Если да, то какие?
        Спасибо!
        Удача любит подготовленный разум...

        Комментарий


        • #34
          Вопрос немного странный. Все должны делать эти проверки (ЭТО ПО МНЕНИЮ Банка России).
          В годовом отчете о состоянии внутреннего контроля есть два пункта посвященные этому.

          +------+---------------------------------------------------------+------+
          |2.2 | Осуществляется ли контроль за состоянием информационной | |
          | | системы банка и ее безопасностью (да, нет). | |
          +------+---------------------------------------------------------+------+
          |2.3 | С какой периодичностью оценивается уровень безопасности | |
          | | информационной системы банка (да, нет): | |
          | | - один раз в месяц; | |
          | | - один раз в квартал; | |
          | | - один раз в год. | |

          Never take anything for granted

          Комментарий


          • #35
            Ну например:
            1. Проверка процедуры создания резервных копий на серверах банка - раз в месяц
            2. проверка учётных записей базы пользователей основных систем - раз в две недели.
            и т.д.
            Удача любит подготовленный разум...

            Комментарий


            • #36
              Утвердите у руководства Банка методику проверки системы.
              Постарайтесь прописать там все, что Вы можите проверить и хотите проверять.
              Периодичность проверок зависит от запущенности. Мы проверяем один раз в квартал.
              Never take anything for granted

              Комментарий


              • #37
                Чтобы избежать ненужных трат денег и времени (для непрошедших всякие разные курсы )

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

                Риски, присущие компьютерным системам

                Основные виды рисков, которые руководители банка/ департамента должны распознать и которыми должны управлять с помощью внутренних процедур и средств бухгалтерского контроля:
                - Риски, связанные с защитой и безопасностью данных, - риск случайного или намеренного раскрытия или уничтожения данных в системе;
                - Риск, связанный с обеспечением конфиденциальности информации - риск того, что данные об операциях клиентов или банка будут переданы третьим лицам;
                - Риск, связанный с достоверностью данных, - риск того, что в систему введены недостоверные данные;
                - Риск, связанный с полнотой данных, - риск того, что данные введены в систему в неполном объеме или вовремя не обновлены;
                - Риск низкой производительности - риск того, что система неспособна вовремя выдавать ожидаемые результаты или выдает информацию в неудобном для пользования формате;
                - Риск неэффективности работы - результаты работы компьютерной системы не отвечают потребностями руководства банка или клиентов.

                Процесс обработки операции в компьютерной системе проходит в шесть этапов, поэтому необходимы шесть видов контроля:
                1. Контроль на этапе инициации операции.
                2. Контроль на этапе ввода операции в систему.
                3. Контроль передачи данных.
                4. Контроль на этапе обработки операции.
                5. Контроль на этапе сохранения и поиска данных.
                6. Контроль данных на выходе из системы.

                Средства контроля на этапе инициации операции
                - Письменные инструкции для пользователей по эксплуатации системы;
                - Специальный формат экрана ввода данных;
                - Система уникальных кодов для идентификации операции;
                - Ссылка на первоисточник;
                - Модификация средств контроля операций;
                - Двойная система защиты в особенности ценных документов, которые вводятся в систему;
                - Наличие письменного разрешения в тех случаях, когда это необходимо;
                - Система серийных номеров для пакетов документов;
                - Подведение суммы по пакету документов, которые вводятся, в пункте происхождения;
                - Наличие и применение письменных процедур по исправлению ошибок;
                - Незамедлительное уведомление системой пользователя об источнике ошибки в документе;
                - Данные, которые вводятся повторно после исправления ошибки, проходят проверку на правильность в таком же объеме, что и данные, которые вводятся впервые;
                - Хранение файла документа - первоисточника;
                - Определение срока хранения в системе файлов документов - первоисточников.


                Средства контроля на этапе ввода операции в систему:
                - Использование специального готового формата экрана ввода данных в систему;
                - Распределение пользователей по группам на основе их функциональных обязанностей;
                - Периодический пересмотр уровня полномочий отдельных групп пользователей;
                - Редактирование данных на экране и проверка правильности введенных данных осуществляются до утверждения операции;
                - Операции, введенные после даты закрытия отчетного периода, содержатся системой в статусе ⌠до выяснения■ и заносятся в специальный список;
                - Система поддерживает график и очередь обработки операций, что гарантирует обработку всех операций без исключения;
                - Файлы документов первоисточников хранятся на вводе в систему к моменту, когда операция будет утверждена системой;
                - Аннулирование системой файлов документов первоисточников для предотвращения упреждения двойного ввода;
                - Пакетный ввод операций;
                - Контроль по общей сумме пакета;
                - Система немедленно выдает на экран уведомление об обнаруженной ошибке;
                - Четкое формулировка сообщений об ошибке;
                - Повторный ввод исправленных данных осуществляется полностью в соответствии с процедурой, утвержденной для первичного ввода данных;
                - Контроль по общей сумме осуществляется для всех отклоненных системой операций.

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

                Обработка данных в компьютерной системе
                - Операции, инициированные компьютерной системой, распечатываются для информации пользователей;
                - При передаче данных с одного модуля системы в другой проводится контроль по остаткам;
                - Система осуществляет контроль по общей сумме при введении задания и этапов задания;
                - Использование средств проверки правильности математических подсчетов;
                - В случае обхода или уничтожения систем контроля программа выдает отчет об исключениях;
                - Система управления файлами с учетом общих сумм и контролем сбалансированности сумм по отдельным полям на этапе проверки правильности;
                - Контроль завершения процесса обработки операции;
                - Сверка сумм, полученных в процессе расчетов во время обработки операции;
                - Система выдает отчеты об обнаруженных ошибках - с указанием поля и типа ошибки;
                - Подготовка отчетов обо всех отклоненных операциях с целью контроля за исправлением ошибок и повторным вводом операций;
                - Департамент ИТ должен вести и сохранять все файлы отслеживания операций, отклоненных системой;
                - Все файлы отслеживания должны иметь уникальный серийный номер.

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

                Средства контроля данных на выходе из системы
                - Контроль общих сумм на выходе и сверка с общими суммами на вводе;
                - Отчет системы по дополнительной информации, например, количество страниц в отчете;
                - Отчеты, которые готовятся системой автоматически, присылаются только на уполномоченные терминалы;
                - Отчеты получают функциональные пользователи;
                - Пользователи могут контролировать правильность подсчета общих сумм вручную с автоматическим подсчетом, сделанным системой;
                - Конфиденциальная исходящая информация уничтожается в системе через определенный срок;
                - Статьи, которые вошли в отчеты об ошибки, регулярно расследуются с внесением необходимых изменений;
                - Процедура исправления ошибки определена в Инструкции по эксплуатации системы;

                Реестры ошибок ведутся на терминалах пользователей для обеспечения своевременного их расследования, исправления и повторного ввода в систему.


                К сожалению, остальной информацией поделиться не могу.
                Жалко ))))

                Методика целиком используется - и успешно.

                Комментарий


                • #38
                  Уважаемые банкиры!

                  Очень нужен стандарт BS 7799 или ISO/IEC 17799 на русском языке.
                  ГДЕ ЭТО МОЖНО НАЙТИ.
                  Never take anything for granted

                  Комментарий


                  • #39
                    Здравствуйте коллеги!

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

                    То Вадим могу Вам посоветовать ACL - назвать ее рабочим местов ИТ аудитора достаточно сложно. Но как АРМ внутреннего аудитора я бы ее Вам порекомендовал. http://cisco.simtel.ru/cc/td/doc/pro..._gds/ac1js.htm
                    В свое время нам ACL порекомендовали в KPMG.

                    Жозеф.

                    Комментарий


                    • #40
                      Добрый день!

                      То Жозеф: Вероятно, когда вы советовали ACL, имелось в виду http://www.acl.com. Потому как, ваша ссылка совсем "из другой оперы"...

                      Комментарий


                      • #41
                        Здравствуйте, уважаемые!
                        Опять я, информационный аудитор.
                        В чём вопрос?
                        Вопрос в АДМИНАХ!
                        Не знаю как в России, а у нас видимо не совсем ещё понимаю роль админа во всём ЭТОМ.
                        Единственным сдерживающим фактором для админа в настоящий момент является дублирование транзакций на бумажных носителях и контроль со тороны исполнителей на местах.
                        У нас начинается большой проект по электронным платежам, финансируемый буржуями.
                        Посидел я, подумал... и закручинился. Что же будет?
                        Приехали внешние аудиторы, озадачил я их этим вопросом: "Как можно контролировать админа?" Пытались они мне что-то сказать про логи и принцип разделения полномочий... Долго я бился с ними, доказывая, что все эти попытки несостоятельны. Кажется, убедил их. Однако вопрос остаётся открытым! Что же делать?
                        Как контролировать админа? Даже не так.... Как контролировать грамотного админа? Предложите хотя бы одну меру контроля, которую админ не мог бы изничтожить на корню, при чём Вы об этом так и не узнаете!
                        У меня есть кое-какие соображения по этому поводу. Хотелось бы узнать Ваше мнение.
                        Да и вообще, накопилось МНОЖЕСТВО тупиковых вопросов. Я, наверное, прозрел. А может быть у меня просто информационный голод...
                        Удача любит подготовленный разум...

                        Комментарий


                        • #42
                          Хеванс До
                          Не обязательно делать копию на бумажных носителях. Можно копировать всю базу в электронном виде (делать периодитческий backup). Еще можно держать другого системного администратора, который никак не связан с 1-м. А также использовать не собственное, кустарно изготовленное, программное обеспечение, а какое-нибудь всемирно известное. Поверьте, очень немногие люди могут найти дырки в СУБД Oracle. Они, как правило, в Oracle и работают. Даже очень грамотный админ не сможет сломать систему безопасности Unix-а и расширить свои полномочия. Устойчивость этих систем ежедневно проверяется сотнями тысяч людей. Если возможно дайте побольше конкретики.

                          Комментарий


                          • #43
                            Здравствуйте!
                            Да я не про бэкап говорю, это ясно, как день.
                            Я вообще-то про контроль.
                            Вы видимо не совсем меня поняли.
                            Давайте поговорим об АБС.
                            "Еще можно держать другого системного администратора, который никак не связан с 1-м." Это уже интересно! Вы видимо имеете ввиду тип распределённого администрирования. Т.е. два админа одной и той же системы? Это бесполезно, ещё и риск возникает, что один админ может подставить другого. Или один администрит *nix, второй Oracle?
                            Чтож, вариант хорошоий, но! Как ни крути, а схема администрирования всегда будет иерархической и при любом раскладе будет существовать ключевой администратор. Этот администратор может всё, начиная от блокирования логов (грохнул процесс, да и все дела) и заканчивая... да чем угодно.
                            Да, что-то я не понял про дырки. Зачем их искать и ломать чего-то? Он же админ и ничего ломать не надо... )) И в юниксе не надо расширять свои полномочия, коли он root.
                            Т.е. мысль тут одна! ВСЕГДА есть человек, который может делать с системой всё, что ему взбредёт в голову. На то он и админ!
                            Как бы я ни конкретизировал, всё сводится к вышесказанному. Я просто хотел узнать мнение народа обо всём этом, может быть есть опыт какой-нибудь.
                            Просто наблюдая с высоты своего админского прошлого и учитывая текущую обстановку, всё обстоит именно так.
                            Удача любит подготовленный разум...

                            Комментарий


                            • #44
                              Собираюсь заняться решением такой же проблемы, т.е. попытаться усовершенствовать систему внутреннего контроля внутри АБС, в т.ч. организовать контроль за действиями админа. Эффективного и надежного решения я пока не вижу. Причем все усугубляется тем, что в вопросах информационных технологий я дилетант, а информационного аудитора у нас нет.
                              Одним из наиболее эффективных путей контроля является мониторинг процессов независимым контролером, который не может влиять на контролируемые процессы.
                              В связи с этим, дилетантский вопрос
                              насколько реализуема и способна ли надежно (с принципиальной и практической точек зрения) обеспечить контроль за действиями админов такая структура:
                              в системе 2 админа;
                              один - администратор сетевой операционной системы, другой - СУБД;
                              логин админа СУБД жестко привязан к конкретной машине;
                              сетевой траффик между машиной админа СУБД и сервером СУБД шифруется (к примеру "железно" - специальными сетевыми платами);
                              в сети присутствует контролер, который видит процессы в сети, логи с машин админов;
                              контролер видит мониторы обоих админов (видит мониторы, железно подключенные к машинам админов в зеркальном режиме; картинку можно и записать - хотя бы чтобы глянуть повторно в случае сомнений);
                              контролер не должен видеть паролей (насколько это возможно?, хотя бы СУБДшных);
                              контролер не может влиять на процессы и информацию в сети (насколько это возможно?);
                              если просто приказом запретить сетевому админу входить в сеть с любых других машин, кроме специально отведенной (с зеркалированным монитором) - сможет ли увидеть контролер вход админа с другой машины?

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

                              Комментарий


                              • #45
                                Здравствуйте!!!
                                2 MA-Nxx
                                Так, уже "ближе к телу". Давайте по-порядку.
                                //в системе 2 админа;
                                Мне всё же кажется, что 2-й админ может быть только резервным. Если же оба админа действующих, то получится ещё хуже, т.к. они теоретически могут "подставить" друг друга. (это если оба человека являются админами одной системы)
                                //один - администратор сетевой операционной системы, другой - СУБД;
                                Это уже лучше, но! Оба критичны. Один полностью владеет системой, другой - теоретически может делать транзакции прямо в базе.
                                //сетевой траффик между машиной админа СУБД и сервером СУБД шифруется (к примеру "железно" - специальными сетевыми платами);
                                Это правильно, но защищает только от внешних воздействий. Сейчас речь идёт о возможностях админов.
                                //в сети присутствует контролер, который видит процессы в сети, логи с машин админов;
                                Это одна из моих идей, на мой взгляд очень правильная но! Представьте себе, что такое процесс в сети:
                                упрощенно это пакеты, которые направлены от одной машины к другой. Что мы можем узнать из этих пакетов? Практически, только то, что админ обратился к серверу и установил соединение. Всё! Остальное будет происходить на терминале, т.е. внутри процесса сервера. Да и ещё, Вы же сами сказали, что "сетевой траффик между машиной админа СУБД и сервером СУБД шифруется (к примеру "железно" - специальными сетевыми платами" ОПС! Вам придётся всю эту информацию расшифровывать или же хранить ключи ещё и на машине контролёра... не лучшее решение. Дальше - логи. Тут вообще плохо. Админ может снести на сервере любой процесс, в том числе и логирование. Потом он его конечно включит, но что он делал в промежутке между этими двумя событиями?!?!?
                                //контролер видит мониторы обоих админов (видит мониторы, железно подключенные к машинам админов в зеркальном режиме; картинку можно и записать - хотя бы чтобы глянуть повторно в случае сомнений);
                                Это хорошая мера контроля, но! Выполнимо ли это? Контролёр должен неотступно пялиться в монитор. Это хорошо, если система одна, а если их несколько? Сколько нужно контролёров?
                                //контролер не должен видеть паролей (насколько это возможно?, хотя бы СУБДшных);
                                контролер не может влиять на процессы и информацию в сети (насколько это возможно?);
                                Ну, это я согласен, а то ещё один админ получается.
                                //если просто приказом запретить сетевому админу входить в сеть с любых других машин, кроме специально отведенной (с зеркалированным монитором) - сможет ли увидеть контролер вход админа с другой машины?
                                Приказ это дело такое, можно выполнять, а можно и нет. Увидеть вход админа это дело конечно нужное, но главное знать, что он потом будет в системе делать.
                                //Так что, думаю, основные факторы - совесть, личные принципы и боязнь преследования
                                Я тоже так думаю, но всё же там где опираются на доверие, контроля быть не может.
                                И не надо говорить, что Вы дилетант, идеи очень здравые, я с удовольствием прочёл Ваш пост. Давайте ещё подумаем!
                                НАРОД!!! Аудиторы, банкиры! Ну вступайте в обсуждение, или вы не до конца поняли всю глубину проблемы? Ваш админ может за несколько часов сделать Ваш банк - БАНКРОТОМ!
                                Админы, здесь есть и Ваша заинтересованность, чтобы в случае чего Вы смогли отбрыкаться и доказать, что вы невиновны!
                                Удача любит подготовленный разум...

                                Комментарий


                                • #46
                                  Существует еще один вариант. Админ не владеет всеми полномочиями. Большими, но не всеми. Ими владеет только заинтересованное лицо, который физически доступ к серверу не имеет. У нас был такой вариант. Нужно загрузить/выгрузить процесс. Приходишь к человеку, который за этот сервер отвечает, и просишь его ввести пароль админинистратора. Пока ты запускаешь нужные тебе процессы тот сидит и смотрит как ты это делаешь. Подключить монитор при помощи железа, вероятно, невозможно, так как там, по-моему, есть ограничение по длине шнура от видеокарты. Придеться, либо все равно шифровать и отправлять по сети, а туда можно запустить все, что угодно, либо сидеть в одной комнате с администратором, либо вешать камеру у него за спиной.
                                  В принципе, если заняться этой идеей, то можно переписать ядро Linuxa так, что при попытки грохнуть процесс писания логов происходило падение всей системы, либо что-то вроде этого. Логи пишуться на другую машину, носитель, которые админ править не может.

                                  Комментарий


                                  • #47
                                    Здравствуйте ещё раз!

                                    Как будем контролировать "заинтересованное лицо"? Тем более, которое понимает что-то в процессах?
                                    Да и что это за админ, у которого есть не все полномочия? Это уже не админ, а непонятно кто.
                                    Идея с kernel мне не совсем нравится. Исходя из моего опыта администрирования линуха, знай я каким образом перестроено ядро, я бы нашел способ как обойти kernel panic
                                    Появляются уязвимости в безопасности.
                                    Да, кроме того, серьёзные конторы используют линух разве что для коммуникаций, да веба. У нас, например, солярка с ораклом, и идея о перестройке ядра таким образом я думаю, что не очень понравится SUN. А об оракле и говорить нечего.
                                    Удача любит подготовленный разум...

                                    Комментарий


                                    • #48
                                      Здраствуйте!!
                                      Здесь вступает в силу принцип борьбы брони и снаряда. При огромном желании, можно любую систему взломать разложив ее на ассемблерные команды к процессору. Сколько это займет времени? Будет ли это совсем незаметно,
                                      В идеальном случае решения проблема не имеет. Разве только держать админа под страхом смертной казни или платить ему огромные деньги. Это опять основывается на доверии.

                                      Комментарий


                                      • #49
                                        Здравствуйте, с интересом прочла Ваше обсуждение.
                                        Я не админ, я бухгалтер (ну, может не самый простой). Мое мнение - исхода нет. Админ может все!
                                        С уважением,
                                        Philippa

                                        Комментарий


                                        • #50
                                          Проблема защиты от Админа очень сложная и должна строиться из большого числа компонент.
                                          Одно из звеньев решения проблемы - регистрация событий на всех серверах и машинах и их последующий аудит.
                                          Изменение политики аудита Админом расценивается как серьезное нарушение и карается. Поэтому, в первую очередь, необходимо отслеживать эти события.
                                          Желательно обеспечить центразизованное хранение всех журналов, в месте недоступном для Админа, ему дается только доступ для чтения отдельных журналов. Желательно, собирать журналы как можно чаще.
                                          Для Windows систем могу рекомендовать Elwiz от Frank Heyne.

                                          С уважением Foxmann

                                          Комментарий


                                          • #51
                                            Здравствуйте!
                                            To s50 :
                                            В общем-то Вы правы на счёт asma и это ещё более печально. Но даже не забираясь так далеко в технические дебри, можно констатировать факт того, что нынешняя ситуация в банках плачевна.

                                            To Philippa:
                                            Моё Вам почтение!
                                            Нууу, не всё так плохо! Выход всё же есть я думаю.
                                            Надеюсь в процессе обсуждения вы его увидите.
                                            To Foxmann:
                                            Так, уже совсем близко!
                                            Раз мы так близко подобрались к решению проблемы, то попробую высказать своё мнение!
                                            1. Чисто технического решения проблемы контроля изменения информации админом быть не может.
                                            2. Необходим гибрид из организационных и технических мер, типа:
                                            - установка нередактируемого устройства записи и хранения информации, что-то типа древних самописцев (не смешно ) который будет писать каждый "key press" админа, относящийся к серверу.
                                            - также сигнализирующее устройство, подсоединённое к серверу что-то типа фаерволины с определёнными правилами, например:
                                            signal IP console text="kill -9 процесс>"
                                            signal IP on stop,start демон>, процесс>
                                            signal IP on write file>
                                            и т.д. (как Вам идейка?)
                                            Замечу, что всё это будет работать при условии того, что системный админ не является одновременно и сетевым.
                                            В случае выполнения условия правила делается уведомление подразделения отвечающего за информ. безопасность.
                                            Набор правил будет постоянно пополняться.
                                            - ну а потом организационные меры, типа в случае обнаружения на устройстве сигнала или записи об уничтожении процесса или ещё чего-то, снести админу голову.
                                            Ещё раз повторюсь! Контроль за админом должен производиться только в режиме реального времени, т.е. каждый введённый символ должен быть зафиксирован. Первоначальный пуск этой системы контроля должен быть обязательно проконтролирован.
                                            Вот, что Вы думаете?
                                            Да, тем, кто ещё не до конца понял проблему?
                                            Ещё вариантик вредительства:
                                            Админа увольняют, он недоволен. Что он делает?! Он пишет прогу с кроном, который запускается через месяц и грохает всю вашу систему с данными.
                                            Предвидя Ваши контр-аргументы по поводу бэкапа и возможности восстановления данных, задумайтесь о том, что админ кроме проги написал ещё и демон, который умышленно бы вносил ошибки в процессе бэкапа во все поколения резервных копий. Вот и всё, все Ваши данные по всему банку потеряны....
                                            Ужас! Я вот всё это пишу и у самого волосы дыбом.
                                            Как Вам идея на счёт проблемы по типу W2K, только которая будет называться
                                            "Проблема грамотного админа"
                                            Удача любит подготовленный разум...

                                            Комментарий


                                            • #52
                                              Здравствуйте.
                                              To: Хэванс_До

                                              Что касается бомбы, заложенной уволенным Админом, то УК классифицирует это как преступление. Главное - доказать. А вот здесь регистрация событий может помочь.
                                              Но гораздо более важно - не ссориться с Админом при его увольнении, и зачитать его права и обязанности.

                                              Что касается real-time, существует ряд програм (в т.ч. и Elwiz), позволяющих на определенные события посылать alarm.

                                              По поводу двух админов. Существуют системы (например SWIFT Alliance) в которых наряду с Админом присутствуют офицеры безопасности, которые авторизуют изменения, сделанные Админом - это одно из звеньев решения проблемы.

                                              Строить различные препятсвия Админу в установившихся системах - по-моему, бесполезно. А вот разделять функции Админа между несколькими сотрудниками - необходимо.

                                              С уважением FOXMANN

                                              Комментарий


                                              • #53
                                                Здраствуйте!!
                                                То Хеванс_До
                                                По поводу проги с кроном.
                                                Получается, что как только админа взяли на работу, он знал, что его собираются уволить и начал учитывать это в своей работе? Проги с кроном можно просто обойти. Нужно делать простой экспорт, а не backup. Что-то вроде большого ASCII - шного файла, где все значения разделены точкой с запятой.
                                                В такой файл невозможно вложить вирус из-за его простоты. Чтобы проверить ошибки при экспорте, надо его периодически сравнивать с текущей базой.[/B]

                                                Комментарий


                                                • #54
                                                  To Foxmann
                                                  Ну что же, можно использо вать и Elwiz. Но он кажется работает только под НТ. Если что-то подобное для солярки? Я что-то не нашел.
                                                  Понимаете, с *nixами будет сложнее.
                                                  Если даже такая фунчёза онлайнового контроля и есть, то перед её установкой нужно будет учесть несколько вещей, как-то:
                                                  - необходимо начисто снести всякого рода ИКСы
                                                  - запретить удалённый вход на машину админа
                                                  - запрет загрузки машины админа в определённых режимах, когда не работают сетевые протоколы.
                                                  - нужна 100% уверенность в том, что сервис или демон который будет вести контроль, загружается до начала загрузки ОС. (очень важное замечание, так как в случае, если это условие не выполняется, то админ может временно выключать протоколирование) Т.е. это всё же должно быть не softwarное решение, а hardwarное, которое фиксирует все события системы, начиная с момента включения компьютера.
                                                  и т.д.
                                                  В общем, если сказать честно, то и Elwiz можно с лёгкостью обойти. Просто загрузив свою машину с дискеты и поюзав тривиальный ntcp. Elwiz это скорее средство для админа, но не ОТ него.
                                                  По поводу SWIFTа тоже у меня большие сомнения. Я всё же считаю, что комплексы, которые стоят в банках не что иное, как терминалы основного сервера SWIFT. Вы ведь не видите и не можете управлять всей системой в целом. В общем-то достаточно безопасная система для самого банка, но ведь у центральных серверов SWIFT тоже есть админ. Возможно они как-то и контролируют его работу. Хотелось бы знать, как.
                                                  To s50
                                                  ?????? Ничего он не учитывал, всю последовательность действий он сделал за пол-часа до ухода. Я не про вирусы говорю, зачем так напрягаться? Всё проще.
                                                  Экспорт или бэкап - разницы большой нет, я всё равно могу внести коррестивы куда угодно, хоть и без моего дальнейшего участия, потому, как я админ и создал процесс с админскими правами.
                                                  Сравнение с текущей базой - хорошая мера, не недостаточная.
                                                  А знаете, как сделали в Финляндии? Они ведь тоже ничего путнего не придумали. Они просто сразу после выхода приказа об увольнении выводят служащего из здания. Вот так-то.
                                                  Кстати, те же горрячие финнские парни с пеной у рта до сих пор доказывают мне, что контролировать админа - НЕВОЗМОЖНО! И с ним просто нужно проводить разъяснительные беседы, всячески поощрять и т.д., чтоб у него и мыслей всяких гадских не возникало.
                                                  Удача любит подготовленный разум...

                                                  Комментарий


                                                  • #55
                                                    To Хэванс_До
                                                    На самом деле рекомендуется при увольнении отлучать от компьютера не только Админа, но и других сотрудников, имеющих сколь-нибудь важный доступ (в т.ч. и к финансовым операциям). Только вот можно подготовить какую нибудь гадость до подачи заявления.

                                                    С уважением Foxmann

                                                    Комментарий


                                                    • #56
                                                      To Foxmann
                                                      Согласен.
                                                      Удача любит подготовленный разум...

                                                      Комментарий


                                                      • #57
                                                        Когда начал читать возникло желание присоединиться. Когда дочитал - пропало.
                                                        Во-первых, основные идеи уже высказаны.
                                                        Во-вторых НЕТ ТЕМЫ ДЛЯ ОБСУЖДЕНИЯ.
                                                        Совершенно не понятно ради чего уважаемый Хэванс_До хочет обложить админов флажками. Как обычно предлагаются конкретные решения неконкретной задачи.
                                                        Если с субъектом безопасности определились - Админ, то теперь надо определиться с объектом. Что и ради чего мы хотим защитить от "всемогущего" админа. После ответа на этот вопрос можно определять способы и методы защиты.
                                                        Последний раз редактировалось A.Bur; 16.04.2003, 15:42.

                                                        Комментарий


                                                        • #58
                                                          Здравствуйте!
                                                          2 A.Bur
                                                          Уважаемый коллега!
                                                          Вы вот там написали, что Вы НЕ программист! Вы, наверное, сисадмин?!?!? Я делаю такой вывод только потому, что именно со стороны админов я слышал подобные высказывания о "заключении админов в рамки". Чтож, я и не скрываю, я действительно этого хочу. Этого требует политика контроля. Все должны быть заключены в рамки, хотите Вы этого или нет. Это же Вам не театральная студия, а банковское учреждение, вы согласны?!
                                                          Далее, на счёт отсутствия темы для обсуждения и неконкретной задачи... Ну почему же? Тема есть и очень конкретная. Или Вы хотели чтобы я ставил вопрос о конкретном админе или конкретной информационной системе?
                                                          По-моему процесс обсуждения прошел успешно и тема действительно практически закрыта. Я так понимаю, что Вы появились здесь после моего поста в разделе "автоматизация" с сылкой на данные посты. Не удивительно, что у Вас не возникло желания обсуждать данную тему... всё уже обсУждено.

                                                          Да, открою Вам причину создания данного threadа. Просто возникла необходимость написания научной статьи в одно местное научное издание. Ну чтож, скажу честно, что с данной задачей я справился. Она одобрена местными светилами и скоро выйдет, я надеюсь.
                                                          Кроме того, данная тема очень горячо обсуждалась у нас на местных форумах.
                                                          Мнения полярно разделились. Админская часть целиком повторила Ваше мнение, остальная - впала в раздумья.
                                                          Думаю, что и здесь на банкир.ру многие задумались.
                                                          Чего я собственно и добивался.
                                                          Ну вот, всё, что хотел сказать.
                                                          Спасибо!
                                                          Удача любит подготовленный разум...

                                                          Комментарий


                                                          • #59
                                                            Незнаю как в остальной России...

                                                            И так проблема разделения полномочий.
                                                            Я буду говорить о реальной(существующей) схеме, работоспасобность которой можно и нужно ставить под сомнение, но она есть.

                                                            Задействованы на самом деле 3 человека:
                                                            Админ АБС, Админ Сервера(операционки) и Офицер безопасности.

                                                            Сответственно Админы ограничивают доступ друг-другу, Безопасность - конторолирует логи.

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

                                                            Сразу скажу я не видил ни одной АБС содержащей достаточную систему контроля. Но это вопрос времини и требований. На любой АБС можно сделать доступ и права регулируемые и отвечающие требованиям.

                                                            Нет вру! Видел одну... правда тока часть АБС... но зато по полной... АС-Филиал(СБ-РФ). Возможно их новая система полностью реализует этот алгоритм.
                                                            Подавая сигналы в рог будь всегда справедлив, но строг. ©

                                                            Комментарий


                                                            • #60
                                                              Здравствуйте!
                                                              2 Romsan
                                                              Вы знаете, у нас в банке всё именно так, как Вы описали, админ ОС, админ оракла, офицер безопасности. При этом офицер безопасности подчиняется напрямую Председателю. Есть положение о категорировании ресурсов и распределении полномочий. И я думаю, что это нужно делать. Но всё же действительно, это нужно ставить под сомнение. Я лично, чётко представляю себе несколько схем мошенничества со стороны админов.
                                                              Сейчас разбираю стандарт ISO 17799... пока ответов не нашел. У меня такое ощущение, что они эту проблему и не пытались затронуть.
                                                              По всей видимости, всё же нужно совмещать организационные и технические меры контроля для максимального снижения этого риска.
                                                              Спасибо.
                                                              Удача любит подготовленный разум...

                                                              Комментарий

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