Содержание
- Аудит безопасности от REG.RU – что это и для чего он необходим?
- Аудит информационной безопасности. Пример отчета. Security Audit Анализ уровня защищенности Вашей ИТ-инфраструктуры. TSsolution.
- Транскрипт
- Отчет аудита информационной безопасности. Часть I. Основы составления отчета аудита
- В первой статье цикла мы начнем с особенностей составления отчета о проведении аудита информационной безопасности.
- Аудит информационной безопасности – основа эффективной защиты предприятия
Аудит безопасности от REG.RU – что это и для чего он необходим?
Введение
Современный мир характеризуется чрезвычайно быстрым ростом объемов информации, глобализацией и компьютеризацией всех слоев общества. Информационные технологии прочно укоренились в нашей жизни – большая часть населения планеты практически постоянно использует доступ в Интернет для работы, обучения, игр, развлечения. Это закономерно влечет за собой монетизацию всех возможных сервисов. Следовательно, линейно возрастает общее количество затрачиваемого времени на совершение операций с использованием пластиковых карт: безналичный расчет при оплате покупок товаров, транзакции в системах онлайн-банкинга, валютный обмен и прочие платежные операции с поставщиками услуг. Соответственно расширяется «веб-пространство», в котором существует информация о владельцах карт и других аутентификационных данных.
Увеличение количества и разнообразия сервисов, доступных конечному пользователю через Интернет, прямо пропорционально расширению поля для мошенничества. В контексте рассматриваемой проблемы основные виды атак злоумышленников можно определить как:
- Атака на поставщика услуг
- Атака на конечного пользователя
В случае атаки на конечного пользователя борьба со злоумышленниками ведется преимущественно установкой клиентского программного обеспечения, соответствующего требованиям безопасности, и информированием пользователя о возможных угрозах. Когда же атака направлена на вендора – необходимы комплексные меры защиты, особым этапом которых является предотвращение вторжений. Столь важную роль предотвращения вторжения можно объяснить тем, что утечка даже части конфиденциальных данных и использования их злоумышленниками ведет к значительным финансовым потерям как поставщика услуг, так и конечного пользователя. Поэтому для уменьшения риска взлома сервиса, перебоев в работе, утечки данных, а также для сохранения репутации ресурса рекомендуется проводить аудит информационной безопасности.
Что такое аудит информационной безопасности?
Понятие «аудит информационной безопасности» появилось сравнительно недавно. Тем не менее, в настоящее время аудит информационной безопасности представляет собой одно из наиболее актуальных и динамично развивающихся направлений стратегического и оперативного менеджмента в области безопасности информационных систем и вызывает постоянный интерес специалистов. Его основная задача – объективно оценить текущее состояние информационной безопасности (ИБ) компании, а также ее адекватность поставленным целям и задачам бизнеса для увеличения эффективности и рентабельности экономической деятельности. Поэтому под аудитом информационной безопасности корпоративной системы обычно понимается системный процесс получения объективных качественных и количественных оценок о текущем состоянии ИБ компании в соответствии с определенными критериями и показателями безопасности. Считается, что результаты квалифицированно выполненного аудита ИБ компании позволяют построить оптимальную по эффективности и затратам корпоративную систему защиты, адекватную текущим задачам и целям бизнеса.
Таким образом, можно дать краткое определение аудиту информационной безопасности (ИБ):
Аудит информационной безопасности – это проверка способности ресурса успешно противостоять угрозам информационной безопасности.
Кому нужен аудит ИБ?
Всем компаниям, нацеленным на успех. Успешный бизнес не построить на сайтах, подверженных взлому. Моментально падают уровень доверия пользователей и снижается посещаемость ресурса. Как следствие – падают продажи, снижается количество клиентов, возникают финансовые потери. Учитывая, что сейчас абсолютно все интернет-ресурсы представляют интерес для злоумышленников (мошенники равно интересуются взломом ресурсов, содержащих информацию о пластиковых карточках, паспортные данные, пароли, счета и т.п., и взломом сайтов, используемых в дальнейшем для сомнительных целей: рассылка спама, использование для черного SEO, создание ботнета и т.д.), аудит ИБ является не пустой тратой денег, а вложением в стабильность.
Почему не популярен?
В большинстве случаев, из-за банального непонимания реальной необходимости услуги. Большинство компаний не готовы отдавать немалые деньги за «всего лишь» проверку на возможность компрометации системы. Все потому, что владельцы не проинформированы о количестве и масштабах хакерских угроз. Зачастую используя принцип «Не во всякой туче гром; а и гром да не грянет; а и грянет, да не по нас; а и по нас – авось не убьет!», компании начинаются задумываться о безопасности лишь, когда система уже скомпрометирована и нанесен серьезный ущерб. Но учиться и делать выводы лучше на чужих ошибках, поэтому ниже приведено несколько реальных примеров, когда аудит ИБ мог бы сохранить нервы и средства.
Сайт одного из министерств некой страны
История случилась 3 года назад при тесте государственного веб-ресурса на проникновение. При первом же осмотре сайта была выявлена уязвимость типа PHP-injection — то есть все ссылки были организованы инклудингом других PHP-страниц, имя которых передавалось GET-запросом. Настройки сервера также нельзя было назвать безопасными – имелся доступ к важным системным файлам mq=off, allow_url_fopen=On, чего уже было достаточно для чтения важной информации, а затем и получения полного доступа к серверу.
Такой запрос позволял без труда читать логи веб-сервера:
Как оказалось позже, виной всему незамысловатый PHP-код:
<?php … $query = $_GET; if(isset($query) && !empty($query)) { require($query.»php»); } ?>
Для устранения уязвимости было рекомендовано проверить переменную на существование файла, использовать функцию strpbrk для выявления спецсимволов — «/.\?», запрета на чтение из под веба /proc/self/, установки в php.ini: magic_quotes_gpc=on, allow_url_fopen=Off.
Казалось бы, защита должна быть одним из первых приоритетов, ведь нетрудно представить, что за собой влечет взлом государственного сайта. Проникновение в локальную сеть, получение доступа к компьютерам, на которых хранится информация, например, о лицензированном тестировании специалистов (ключи ответов на КРОК, внешнее независимое оценивание и т.д.). Тогда, возможно, будет под вопросом подлинность сертификатов, которые требуют все высшие учебные заведения, а значит и компетентность будущих врачей и т.д.
Электронная коммерция
Все больше развлекательных ресурсов используют собственную игровую валюту, которая может быть конвертирована в реальные деньги. При проведении теста на проникновение одного из таких сайтов была обнаружена SQL-инъекция с выводом по типу error based.
Суть сайта заключалась в том, что у вас есть автомобиль, вы устраиваете гонки, усовершенствуете авто и т.д. Некоторые из этих операций требовали вложений в баланс аккаунта. В ходе проверки, через SQL-инъекцию была получена вся структура БД, сканером директорий были выявлены старые или тестовые версии сайта с установленной системой управления контентом Joomla. Для симулирования действий злоумышленников все через ту же уязвимость были получены хэши паролей от Joomla, успешно подобраны грубым брутфорсом, получен доступ к серверу через загрузку «php-shell» в административном центре Joomla. Как следствие, также получены пароли доступа к БД, что обеспечило возможность управлять балансом счетов, без реального перечисления средств. Таблица с балансом была организована очень просто:
Кроме того, пароли сохранялись в открытом виде.
Рекомендации по устранению уязвимости были следующими:
• Обработать входные параметры функцией mysql_real_escape_string;
• Отключить вывод ошибок;
Не оставлять «полезных» директорий, доступных из веба (старых версий, дампов, тестовых скриптов и тому подобное);
• Даже на тестовые версии сайтов не ставить пароли, которые могут быть в словарях;
• Обработать пароли необратимым алгоритмом шифрования.
Невидимая угроза
При анализе одного из взломанных серверов было отмечено внедрение i-frame кода на сайты без определенного источника. Файлы на сервере сохраняли целостность, их содержимое не было изменено, но пользователям сайтов «выбрасывался» вредоносный код. Характерной чертой было случайное появление вредоносного кода абсолютно на всех сайтах сервера:
Виной всему был вредоносной модуль Apache — DarkLeech, который распространял вредоносное ПО, «прозрачно» дописывая пару строк кода в отдаваемые страницы веб-сервера. Физические имена модулей были: mod_spm_headers.so, mod_spm_mem.so, mod_log.so и mod_security.so.
В httpd.conf присутствовала строка:
LoadModule spm_headers_module modules/mod_spm_headers.so
На сервере за логами доступа были обнаружены уязвимые скрипты, через которые происходил взлом, отключены вредоносные модули и обновлено ядро операционной системы, в связи с подозрением на использование local root эксплойтов злоумышленниками.
Это еще раз подтверждает важность функции комплексной защиты веб-ресурса, а не только защиты исходного кода, которую обеспечивает полный аудит ИБ.
Сколько это стоит?
Стоимость аудита ИБ в большинстве случаев невозможно определить сразу – все зависит от характера работ (какие уязвимости определяются – от ошибок программистов до социальной инженерии). Кроме того, некоторые компании рассчитывают стоимость услуги в зависимости от числа найденных проблем, количества строк анализируемого кода и формы представления результатов (отчет, видеоотчет, рекомендации по устранению, дополнительные консультации). Но в среднем, цены начинаются от $100. При этом такая стоимость работ характерна либо для компаний, которые только вышли на рынок и работают без сертифицированных специалистов и стандартов проведения аудита, либо для аматорских команд, которые, в основном, состоят из бывших black-hat или непрофессиональных специалистов по информационной безопасности. Конечно, нельзя утверждать, что при обращении в подобные компании работа будет выполнена некачественно, но, когда речь идет о конфиденциальной информации и безопасности, лучше довериться профессионалам.
В данном случае расценки будут уже сильно отличаться – от $300-500 до $5000, в зависимости от тарифа. Например, в REG.RU цены на эти услуги выглядят следующим образом: 25 000 руб. за «Бюджетный» тариф и от 150 000 руб. за «Корпоративный» (https://www.reg.ru/web-sites/security-audit/#prices). Столь высокая цена объясняется проведением мультианализа всех частей системы с целью выявления критичных мест и введения комплексных мер защиты, а также высокой квалификацией специалистов, имеющих сертификаты Offensive Security Certified Professional (OSCP) и Certified Professional Penetration Tester (eCPPT).
Выводы
Что дает заказ услуги «Аудит безопасности сайта в REG.RU»?
- Описание и оценку текущего уровня защищенности информационной системы;
- Анализ рисков, связанных с возможностью осуществления внутренних и внешних угроз в отношении ресурсов информационной системы;
- Составление модели потенциального злоумышленника;
- Рекомендации по технической, организационной составляющей ИБ (устранение уязвимостей в коде, разработке политики информационной безопасности)
- Получение максимальной отдачи от инвестиций, вкладываемых в системы защиты информации;
- Подтверждение того, что используемые внутренние средства контроля соответствуют задачам организации и позволяют обеспечить эффективность и непрерывность бизнеса.
- Обоснование инвестиций в системы защиты информации.
Большинство владельцев взломанных сайтов не подозревало о вторжении на их ресурс. Часть системных администраторов при выявлении вторжения не предпринимали никаких действий, если не было видимых нарушений работы сайта, ввиду нехватки знаний по данной проблеме. Аудит безопасности способен предоставить объективную информацию о защищенности сайта, что позволит владельцу ресурса не поставить под угрозу свой бизнес и деловую репутацию. Ведь доверяя свои личные данные какой-либо организации, пользователи и партнеры уверены, что она сможет обеспечить их конфиденциальность.
Аудит информационной безопасности. Пример отчета. Security Audit Анализ уровня защищенности Вашей ИТ-инфраструктуры. TSsolution.
Транскрипт
1 фыва Аудит информационной безопасности Пример отчета Security Audit Анализ уровня защищенности Вашей ИТ-инфраструктуры TSsolution.ru
2 Оглавление 1. Цель проекта Подход к выполнению работ Резюме для руководства о результатах проведенного аудита Результаты анализа технической защищенности внешнего периметра Результаты анализа защищенности внутреннего периметра Рекомендуемые шаги
3 1. Цель проекта Целью проекта является проведение независимого технического аудита информационной безопасности. Следующие задачи были обозначены как ключевые в отношении проведения комплексного аудита ИБ: получение оценки текущего уровня защищенности сетевой инфраструктуры; разработка рекомендаций по повышению уровня защищенности и устранению выявленных уязвимостей. 2. Подход к выполнению работ В рамках проекта моделировались действия следующих категорий нарушителей: Внешний нарушитель: нарушитель, не обладающий знаниями об ИТ-инфраструктуре Компании, не имеющий возможности доступа в офис и не имеющий возможности подключения к локальной сети Компании. Внутренний нарушитель: нарушитель, имеющий возможность доступа в офис и физического подключения к ЛВС Компании. В рамках оценки степени выполнения основных положений рассматривались следующие критерии: Текущий уровень ИБ: — распределение ролей; — управление доступом и регистрация; — антивирусная защита; — использование Интернет. Менеджмент ИБ: — функционирование службы ИБ; — оценка и обработка рисков ИБ; — документирование деятельности в области ИБ; — реагирование на инциденты безопасности; 2
4 3. Резюме для руководства о результатах проведенного аудита Внешнее тестирование В рамках работ по тестированию защищенности внешнего периметра была проведена идентификация уязвимостей в отношении внешних адресов Компании. В результате идентификации уязвимостей было обнаружено наличие 1 критичной уязвимости, 2 уязвимостей среднего уровня критичности, 1 уязвимости низкого уровня критичности. Обнаруженные уязвимости связаны с отсутствием своевременного обновления используемого программного обеспечения и некорректной настройкой используемого программного обеспечения. Рекомендации по исправлению выявленных уязвимостей приведены при описании конкретных уязвимостей. Внутреннее тестирование В рамках работ по тестированию защищенности внутреннего периметра была проведена идентификация уязвимостей в отношении узлов, образующих локальную инфраструктуру Банка и узлов демилитаризованной зоны (DMZ). Критичные уязвимости были обнаружены как автоматическими средствами сканирования, так и в ходе экспертного анализа. Обнаруженные уязвимости связаны с отсутствием в Компании политики и правил управления паролями, учетными записями, отсутствием своевременного обновления ПО, некорректной настройкой используемого ПО и сетевого оборудования. Рекомендации по исправлению выявленных уязвимостей приведены в разделе по описанию результатов внутреннего тестирования. Оценка организационного обеспечения безопасности Для оценки организационного обеспечения безопасности информации Исполнителем применялся подход, описанный в СТО БР ИББС В рамках оценки степени выполнения основных положений СТО проводилась оценка текущего уровня ИБ и менеджмента ИБ. Уровень ИБ и Менеджмент ИБ ООО Компания не соответствуют требуемому согласно СТО БР ИББС уровню ни по одному из групповых показателей, по которым осуществлялась оценка. Менеджмент ИБ в настоящий момент находится в критическом состоянии. По результатам проведенных работ можно сделать следующие выводы: Текущее управление информационной безопасностью Компании имеет проблемы системного характера: выявленные технические уязвимости имеют общие причины возникновения и присутствуют во всех рассмотренных системах В Компании отсутствуют базовые элементы управления информационной безопасности: стандарты по ИБ, политики и процедуры, правила, система контроля соблюдения требований по ИБ Организационная и техническая системы ИБ требуют существенного улучшения Как результат, текущий уровень защиты информационных систем находится ниже общепринятого базового уровня Необходимо принять меры организационного и технического характера 3
5 4. Результаты анализа технической защищенности внешнего периметра 4.1 Описание используемых средств Настоящий раздел содержит описание результатов проведения экспертного и инструментального анализа внешней ИТ-инфраструктуры с участием профильных специалистов. Инструментальное исследование внешнего сетевого периметра проводилось с использованием следующих средств по анализу защищенности: MaxPatrol MaxPatrol программное средство контроля защищенности сетевой инфраструктуры. Позволяет получать объективную оценку защищенности информационных систем. Существует возможность использования следующих профилей для проверки сети: тестирование на проникновение (Pentest); системная проверка (Audit); контроль соответствия стандартам (Compliance). Программное средство сертифицировано по требования безопасности информации, сертификат соответствия 2305 действителен до 24 марта 2014 года. Cain&Abel Утилита для восстановления паролей, прослушивания сетевого трафика, декодирования защищенных паролей, восстановления ключей беспроводных сетей и анализа маршрутизации протоколов. Применялась для осуществления проверки уязвимости сетевой инфраструктуры к атаке ARP-poisoning. Intercepter Многофункциональный снифер паролей и переписки. Осуществляет перехват паролей\хешей следующих протоколов: ICQ\IRC\AIM\FTP\IMAP\POP3\SMTP\LDAP\BNC\SOCKS\HTTP \WWW\NNTP\CVS\TELNET\MRA\DC++\VNC\MYSQL\ORACLE Осуществляет перехват переписки следующих протоколов: ICQ\AIM\JABBER\YAHOO\MSN\IRC\MRA Проводит MiTM атаки: ARP\DHCP\DNS over ICMP\SSL\SSLSTRIP 4
6 Nmap В область проведения анализа технической защищенности внешнего периметра по согласованию с представителями Заказчика были включены следующие внешние ресурсы Заказчика: Основная внешняя подсеть 195.хх.yyy.0/ хх.yyy.8/ хх.yyy.32/ хх.yyy.0/27 В отношении вышеперечисленных хостов специалистами были проведены следующие процедуры: Сбор информации о запущенных службах; Обработка и интерпретация собранной информации; Поиск и анализ уязвимостей; Описание выявленных уязвимостей. 4.2 Описание выявленных недостатков/уязвимостей в отношении внешнего периметра 195.хх.yyy.3 (ns-m.company.ru) 143/TCP — IMAP 110/TCP — POP3 Небезопасный метод аутентификации: Удаленный сервер допускает использование незашифрованных учетных данных, передаваемых по незащищенному протоколу. Это позволяет злоумышленникам, при помощи прослушивания, получить информацию об имени и пароле пользователя. POP3 IMAP Методы аутентификации Методы аутентификации LOGIN IMAP LOGIN PLAIN LOGIN USER/PASS PLAIN Решение: Настройка службы на использование пониженного уровня безопасности аутентификации только для шифрованных соединений. CVSS Базовая 2.6 (AV:N/AC:H/Au:N/C:P/I:N/A:N) 5
7 CVSS оценка AV:N AC:H Au:N C:P I:N A:N данная уязвимость может эксплуатироваться удаленно для эксплуатации уязвимости нужны особые условия, или уязвимая конфигурация редко встречается на практике для эксплуатации уязвимости проходить аутентификацию не требуется эксплуатация уязвимости влечет существенное разглашение эксплуатация уязвимости не затрагивает целостность системы эксплуатация уязвимости не влияет на доступность системы Ссылки: хх.yyy.4 (ns1.company.ru) 53/UDP — BIND Server ( Версия: 9.8.2rc1-RedHat rc1.el6.3) Использование памяти после освобождения Уязвимость позволяет атакующему вызвать отказ в обслуживании. Уязвимость в ISC BIND (BIND-форум) позволяет злоумышленникам, действующим удаленно, вызвать отказ в обслуживании (аварийное завершение работы named-демона), что приводит к «разыменованию ранее освобожденной выборки контекста». Решение: Для устранения уязвимости необходимо установить последнюю версию продукта, соответствующую используемой платформе. Необходимую информацию можно получить по адресу: CVSS Базовая 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C) оценка Временная 3.2 (AV:N/AC:L/Au:N/C:N/I:N/A:C/E:U/RL:OF/RC:C) оценка AV:N данная уязвимость может эксплуатироваться удаленно AC:H для эксплуатации уязвимости не требуются особые условия Au:N для эксплуатации уязвимости проходить аутентификацию не требуется C:N эксплуатация уязвимости не затрагивает конфиденциальные данные 6
8 CVSS I:N A:C системы эксплуатация уязвимости не затрагивает целостность системы при успешной эксплуатации злоумышленник может сделать систему полностью недоступной Ссылки: FULLDISC ( BIND remote exploit (low severity) ): January/ html MLIST ( Internet Systems Consortium Security Advisory.): FRSIRT (ADV ): SECUNIA (23904): BUGTRAQ ( BIND remote exploit (low severity) ): хх.yyy.6 (ibank2.company.ru) 195.хх.yyy.8 (plastic.company.ru) 443/TCP — HTTP SSL (ibank2.company.ru) 8080/TCP HTTP (plastic.company.ru) Возможна атака Anti DNS Pinning Сервер уязвим для обхода ограничений политики безопасности Same Origin Policy с помощью атаки Anti DNS Pinning (DNS rebinding). Описание: Атака Anti DNS Pinning (DNS rebinding) позволяет злоумышленнику манипулировать соответствием между IP-адресом и DNS-именем узла (FQDN) с целью запуска активного содержимого в контексте безопасности уязвимого сайта. Используя эту технику, злоумышленник может использовать браузер жертвы для получения доступа к защищенным сайтам (например, находящимся за межсетевыми экранами или требующим аутентификации). В отличие от атаки типа «Подделка межсайтового запроса» (Cross-Site Request Forgery, CSRF), атака Anti DNS Pinning направлена на получение данных (нарушение 7
9 конфиденциальности) а не на выполнение каких-либо действий с приложением (нарушение целостности). Однако совместно с CSRF атака Anti DNS Pinning может использоваться для полнофункционального доступа к веб-приложению через браузер пользователя. Проблема настройки сервера состоит в том, что он не осуществляет достаточную проверку поля Host в HTTP-запросе. При поступлении запросов с произвольным адресом в поле Host сервер должен возвращать ошибку. Решение: Удаление стандартных виртуальных сайтов, отвечающих на HTTP-запросы с произвольным значением заголовка HOST. В IIS для этого необходимо установить непустое значение «Host header value» для всех веб-сайтов. В Apache необходимо установить непустое значение директивы ServerName для всех виртуальных сайтов (даже если сайт на сервере один, он должен быть оформлен в виде Virtual Host) и проверить что сайт по умолчанию ни указывает на другие сайты, а возвращает ошибку. CVSS Базовая 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C) оценка AV:N данная уязвимость может эксплуатироваться удаленно AC:H для эксплуатации уязвимости нужны особые условия, или уязвимая конфигурация редко встречается на практике Au:N для эксплуатации уязвимости проходить аутентификацию не требуется C:С эксплуатация уязвимости влечет полное разглашение конфиденциальных данных I:N эксплуатация уязвимости не затрагивает целостность системы A:N эксплуатация уязвимости не влияет на доступность системы Ссылки:
10 5. Результаты анализа защищенности внутреннего периметра 5.1 Область проведения В область проведения анализа технической защищенности внешнего периметра по согласованию с представителями Заказчика были включены следующие внутренние ресурсы Заказчика: / / /24 Ресурсы демилитаризованной зоны (DMZ): / /24 В отношении вышеперечисленных хостов специалистами были проведены следующие процедуры: Сбор информации о запущенных службах; Обработка и интерпретация собранной информации; Поиск и анализ уязвимостей; Описание выявленных уязвимостей. 5.2 Описание выявленных недостатков/уязвимостей в отношении внутреннего периметра Использование лекгоподбираемых реквизитов доступа или реквизитов доступа «по умолчанию»: Получен доступ к NAS с логином root без пароля, причем доступ возможен как через WEB-интерфейс, так и по ssh. 9
11 Рисунок 1. Доступ к Рисунок 2. Доступ к
13 Получен доступ к серверу : Реквизиты доступа: Login: User Password: (empty) Рисунок 4. Получен доступ к серверу Сервер отдает пароль с помощью специального запроса: Рисунок 5. Пароль в открытом виде на
15 сети (устройства Juniper). Рекомендации: не хранить пароли администраторов устройств в формате Juniper $9$ Password. Не хранить файлы конфигурации на общедоступном для пользователей локальной сети сервере. Получен доступ к (ds1) с помощью следующих реквизитов доступа: Login: test Password: Удалось подключиться к базе MS SQL ( ) с использованием следующих реквизитов доступа: Login: test Password: test Рисунок 6. Подключение к базе данных MS SQL Получен доступ к системе резервного копирования ( , bac1 msk-02- bac1.company.local) с помощью следующих реквизитов доступа: Login: root Password: password Панель администрирования принтеров в открытом доступе. Любой пользователь локальной сети банка может получить доступ к панели администрирования сетевого принтера просто обратившись к нему по адресу его размещения, например :80 14
16 Рисунок 7. Панель управления принтерами Общие рекомендации: Необходимо сменить все подобранные в ходе аудита реквизиты доступа; Не использовать пароли по умолчанию для доступа к NAS, серверам, приложениям и сетевым устройствам; Не использовать одинаковые пароли для доступа к разнородным устройствам; Для генерации паролей использовать специализированное программное обеспечение (keepass, etc), которое позволяет генерировать пароли заданной сложности. Запретить доступ к панели управления принтером без пароля. ARP-poisoning Анализ безопасности протокола ARP показывает, что, перехватив на атакующем хосте внутри данного сегмента сети широковещательный ARP-запрос, можно послать ложный ARPответ, в котором объявить себя искомым хостом (например, маршрутизатором), и в дальнейшем активно контролировать сетевой трафик дезинформированного хоста, воздействуя на него по схеме «ложный объект ЛВС». Атака обычно начинается с прослушивания канала связи и заканчивается тем, что аналитик пытается подменить перехваченное сообщение, извлечь из него полезную информацию, перенаправить его на какой-нибудь внешний ресурс. Применяя данный вид атаки, злоумышленник может получить доступ к учетной записи 15
17 пользователя. В Компании используются текстовые прикладные протоколы передачи данных без наличия средств шифрования, что делает возможным перехват парольной информации в отношении используемых WEB-сервисов для корпоративных приложений, сервисов электронной почты. Существует возможность перехвата LM&NTLM, NTLMv2 хешей, что делает доступным работу из-под сторонних учетных записей пользователей домена. В результате чего возможен доступ злоумышленника к почте легитимных пользователей, и к любой иной информации, передаваемой в локальной сети. Рисунок 8. Доступ к учетной записи Автушковой Оксаны Рисунок 9. Доступ к администрированию почты, создание учетных записей 16
18 Доступ к системе nagios (перехвачены логин и пароль: nagiosadmin-qazsedcft): Рекомендации: Рисунок 10. Дополнительные данные об особенностях локальной сети Использовать статические записи в таблице ARP 5.3 Описание выявленных недостатков/уязвимостей в отношении DMZ (IBANK2_JAVA) 3389/TCP — Microsoft RDP Подмена данных в сертификате Уязвимость позволяет атакующему получить доступ к защищенному трафику. В цепочке сертификатов найден сертификат, который содержит символ \x00 в поле CommonName. Сертификаты, содержащие символ \x00 в поле CommonName, позволяют злоумышленникам эксплуатировать уязвимость в механизме проверки корректности сертификата, который применяется в различных браузерах, а также других продуктах, использующих SSL. В случае успешной эксплуатации злоумышленник может провести атаку типа «человек посередине» и получить доступ к защищенному трафику. Решение: Установите корректный сертификат для данной службы. 17
19 CVSS Базовая оценка AV:A AC:L Au:N C:С I:С A:С 8.3 (AV:A/AC:L/Au:N/C:C/I:C/A:C) для успешной эксплуатации уязвимости злоумышленник должен иметь доступ к соседней сети для эксплуатации уязвимости не требуются особые условия для эксплуатации уязвимости проходить аутентификацию не требуется эксплуатация уязвимости влечет полное разглашение конфиденциальных данных эксплуатация уязвимости влечет полное нарушение целостности системы при успешной эксплуатации злоумышленник может сделать систему полностью недоступной Ссылки: /TCP — Microsoft DS Не требуется подписывание SMB Узел не требует подписывания SMB. Возможно проведение атаки «человек посередине» на SMB-сервер. В настройках SMB-сервера доступны три опции, касающиеся подписывания SMB: подписывание SMB включено и обязательно для всех клиентов; подписывание SMB включено, но не обязательно для всех клиентов; подписывание SMB отключено. Безопасность данных обеспечивает только первый вариант с включенным и обязательным для всех клиентов подписыванием SMB. На данном узле выбран небезопасный вариант настроек. Решение: Включить подписывание SMB в настройках сервера. CVSS Базовая 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N) оценка AV:N данная уязвимость может эксплуатироваться удаленно 18
20 CVSS AC:L для эксплуатации уязвимости не требуются особые условия Au:N для эксплуатации уязвимости проходить аутентификацию не требуется C:N эксплуатация уязвимости не затрагивает конфиденциальные данные системы I:P эксплуатация уязвимости ведет к частичному нарушению целостности системы A:N эксплуатация уязвимости не влияет на доступность системы Ссылки: Windows: Samba: /UDP — Internet Key Exchange Доступен агрессивный режим Включена поддержка агрессивного режима с парольной защитой. Это позволяет злоумышленнику получить хэш пароля, а затем подобрать по нему пароль. Решение: Отключите агрессивный режим. CVSS Базовая 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N) оценка AV:N данная уязвимость может эксплуатироваться удаленно AC:L для эксплуатации уязвимости не требуются особые условия Au:N для эксплуатации уязвимости проходить аутентификацию не требуется C:P эксплуатация уязвимости влечет существенное разглашение конфиденциальных данных I:N эксплуатация уязвимости не затрагивает целостность системы A:N эксплуатация уязвимости не влияет на доступность системы (ns1.company.local) Linux Kernel Не установлено обновление безопасности. 19
22 6. Рекомендуемые шаги Устранение выявленных уязвимостей Провести работу по устранению уязвимостей, выявленных в ходе проекта. Детальная информация по выявленным уязвимостям приведена в Отчете по результатам комплексного аудита информационных систем ИТ-инфраструктуры. Улучшение процессов информационной безопасности и непрерывности бизнеса Обеспечить комплексный подходи к защите информационных активов Компании, включая не только технические аспекты обеспечение информационной безопасности, но и разработку организационно-технической документации, формирующей требования по всем областям и функциям информационной безопасности, включая управление непрерывностью и доступностью информационных систем. Организовать построение целостной системы управления информационной безопасности по требованиям СТО БР ИББС. Организовать реально функционирующее подразделение по информационной безопасности, в ответственность которого будет входить: — разработка организационных и технических требований к функциям ИБ и согласование требований с бизнес-подразделениями; — постановка задач администраторам информационных систем в соответствии с выработанными требованиями к функциям информационной безопасности; — контроль выполнения требований к функциям информационной безопасности и выработка рекомендаций по совершенствованию Мониторинг и поддержка защищенности систем Организовать процесс управления обновлениями для программных активов. Организовать процесс технического мониторинга событий ИБ систем и внедрить процедуру реагирования на события информационной безопасности Провести инвентаризацию всех активов Банка и провести оценку рисков в соответствии с требованиями СТО БР ИББС Проводить регулярную независимую оценку информационной безопасности. Разработать пакет документов по ИБ в соответствии с требованиями СТО БР ИББС 21
Отчет аудита информационной безопасности. Часть I. Основы составления отчета аудита
- Часть 1.Основы составления отчета аудита
- Часть 2.Структура отчета аудита
- Часть 3. Составление плана по устранению уязвимостей
Мы начинаем цикл статей, посвященных составлению отчета о проведении аудита информационной безопасности. В данном цикле мы попытаемся рассказать вам, почему составлению отчета о проведенном аудите безопасности должно быть уделено совсем не меньше внимания, чем проведению самого аудита. Мы приведем приблизительную структуру отчета, а также расскажем вам о таких отраслевых стандартах, как шкала риска CVSSv2, базах уязвимостей MITRECVE и CWE, OSVDB, NIST и WASC. Осильте эти много букв, это точно принесет вам пользу.
В первой статье цикла мы начнем с особенностей составления отчета о проведении аудита информационной безопасности.
Аудит информационной безопасности – важный этап в построении любого комплексного решения для защиты автоматизированных систем предприятий от возможных угроз информационной безопасности. Ведь именно аудит, который вы можете проводить в виде анализа уязвимостей или тестирования на проникновение (пентеста), даст интегратору, проводящему построение системы безопасности информации на предприятии, точку начального отсчета.
Т.о., если вы проводите аудит безопасности информации в любом его виде, в результате вы должны предоставить клиенту исчерпывающую характеристику состояния информационной безопасности активов клиента. Помимо этого, необходимо провести тщательное и детальное исследование всех обнаруженных уязвимостей. И наконец, в разделе по устранению уязвимостей от вас потребуется превратить полученный вами на ранних этапах аудита массив информации об активе клиента в четкий план действий по устранению проблем с безопасностью информации.
Разработка отчета – очень важная фаза аудита информационной безопасности, а хорошее понимание ожиданий клиента – краеугольный камень вашего успеха. Дело в том, что ваш клиент будет не в состоянии оценить, насколько виртуозно вы провели пентест и как технично вы выполнили эксплуатацию уязвимостей. Вне зависимости от того, являетесь ли вы штатным сотрудником службы информационной безопасности, привлечены ли на аутсорсинге или вы фрилансер, вы должны донести результаты аудита информационной безопасности до клиента так, как он ожидает этого от вас.
Независимо от того, как вы провели аудит информационной безопасности сайта, именно отчет – это то, в соответствии с чем вас оценит клиент. Поэтому к этой фазе нельзя относиться спустя рукава.
Прежде чем перейти к содержанию, необходимо несколько слов сказать о форме. Ваш отчет должен выглядеть солидно и профессионально. Освойте навыки презентации своей работы. Это очень важно.
Также необходимо отметить, что подготовка к составлению отчета о проведенном аудите начинается вместе с самим аудитом. Понятно, что ключом к успешному написанию отчета об аудите безопасности информации является грамотная и четкая систематизация данных, полученных в процессе проведения аудита.
Когда вы проводите аудит информационной безопасности сайта, вы обязательно должны сохранять:
- Время и дату начала аудита;
- Объекты, которые подлежат аудиту (IP, домены, области сайтов);
- Обнаруженные уязвимости;
- Тип уязвимости;
- Краткое описание;
- Уязвимые компоненты сайта;
- Используемый эксплойт или подробную схему проникновения (в случае проведения пентеста).
Если в процессе проведения аудита информационной безопасности вы сохраните эти данные, то можете считать, что полдела по составлению отчета вы уже сделали.
Есть еще одна вещь, которая не должна быть лишена вашего внимания. Написанный вами отчет будут изучать на совершенно разных уровнях в компании, заказавшей ваши услуги. Обычно, таких уровней два: руководство компанией и технические специалисты.
Вы должны быть уверены, что смогли донести до каждого уровня иерархии компании результаты вашего исследования, используя правильные доводы и соответствующий язык.
В следующей статье цикла мы расскажем о том, как это (см. абзац выше) сделать, а также приведем приблизительную структуру отчета.
Аудит информационной безопасности – основа эффективной защиты предприятия
Назад к списку статей
Сегодня информационные системы (ИС) играют ключевую роль в обеспечении эффективности работы коммерческих и государственных предприятий. Повсеместное использование ИС для хранения, обработки и передачи информации делает актуальными проблемы их защиты, особенно учитывая глобальную тенденцию к росту числа информационных атак, приводящих к значительным финансовым и материальным потерям. Для эффективной защиты от атак компаниям необходима объективная оценка уровня безопасности ИС — именно для этих целей и применяется аудит безопасности.
Что такое аудит безопасности
Определение аудита безопасности еще не устоялось, но в общем случае его можно описать как процесс сбора и анализа информации об ИС для качественной или количественной оценки уровня ее защищенности от атак злоумышленников. Существует множество случаев, когда целесообразно проводить аудит безопасности. Это делается, в частности, при подготовке технического задания на проектирование и разработку системы защиты информации и после внедрения системы безопасности для оценки уровня ее эффективности. Возможен аудит, направленный на приведение действующей системы безопасности в соответствие требованиям российского или международного законодательства. Аудит может также предназначаться для систематизации и упорядочения существующих мер защиты информации или для расследования произошедшего инцидента, связанного с нарушением информационной безопасности.
Как правило, для проведения аудита привлекаются внешние компании, которые предоставляют консалтинговые услуги в области информационной безопасности. Инициатором процедуры аудита может стать руководство предприятия, служба автоматизации или служба информационной безопасности. В ряде случаев аудит также проводится по требованию страховых компаний или регулирующих органов. Аудит безопасности выполняется группой экспертов, численность и состав которой зависит от целей и задач обследования, а также от сложности объекта оценки.
Виды аудита безопасности
Можно выделить следующие основные виды аудита информационной безопасности:
- экспертный аудит безопасности, в ходе которого выявляются недостатки в системе мер защиты информации на основе опыта экспертов, участвующих в процедуре обследования;
- оценка соответствия рекомендациям международного стандарта ISO 17799, а также требованиям руководящих документов ФСТЭК (Гостехкомиссии);
- инструментальный анализ защищенности ИС, направленный на выявление и устранение уязвимостей программно-аппаратного обеспечения системы;
- комплексный аудит, включающий в себя все вышеперечисленные формы проведения обследования.
Любой из перечисленных видов аудита может проводиться по отдельности или в комплексе, в зависимости от тех задач, которые решает предприятие. В качестве объекта аудита может выступать как ИС компании в целом, так и ее отдельные сегменты, в которых обрабатывается информация, подлежащая защите.
Проведение аудита безопасности
В общем случае аудит безопасности, вне зависимости от формы его проведения, состоит из четырех основных этапов, на каждом из которых выполняется определенный круг работ (см. рисунок).
Основные этапы работ при проведении аудита безопасности.
На первом этапе совместно с заказчиком разрабатывается регламент, устанавливающий состав и порядок проведения работ. Основная задача регламента — определить границы, в рамках которых будет проводиться обследование. Регламент позволяет избежать взаимных претензий по завершении аудита, поскольку четко определяет обязанности сторон. Как правило, регламент содержит следующую основную информацию:
- состав рабочих групп от исполнителя и заказчика для проведения аудита;
- список и местоположение объектов заказчика, подлежащих аудиту;
- перечень информации, которая будет предоставлена исполнителю;
- перечень ресурсов, которые рассматриваются в качестве объектов защиты (информационные, программные, физические ресурсы и т. д.);
- модель угроз информационной безопасности, на основе которой проводится аудит;
- категории пользователей, которые рассматриваются в качестве потенциальных нарушителей;
- порядок и время проведения инструментального обследования ИС заказчика.
На втором этапе, в соответствии с согласованным регламентом, собирается исходная информация. Методы сбора информации включают интервьюирование сотрудников заказчика, заполнение опросных листов, анализ предоставленной организационно-распорядительной и технической документации, использование специализированных инструментальных средств.
Третий этап работ предполагает анализ собранной информации с целью оценки текущего уровня защищенности ИС предприятия. По результатам проведенного анализа на четвертом этапе разрабатываются рекомендации по повышению уровня защищенности ИС от угроз информационной безопасности.
Ниже мы подробнее рассмотрим этапы аудита, связанные со сбором информации, ее анализом и разработкой рекомендаций по повышению уровня защиты ИС.
Сбор исходных данных
Качество аудита безопасности во многом зависит от полноты и точности информации, полученной в процессе сбора исходных данных. Поэтому в нее необходимо включить следующее: организационно-распорядительную документацию, касающуюся вопросов информационной безопасности, сведения о программно-аппаратном обеспечении ИС, информацию о средствах защиты, установленных в ИС, и т. д. Более подробный перечень исходных данных представлен в табл. 1.
Таблица 1. Перечень исходных данных, необходимых для аудита безопасности
| Тип информации | Состав исходных данных |
| Организационно-распорядительная документация по вопросам информационной безопасности |
|
| Информация об аппаратном обеспечении хостов |
|
| Информация об общесистемном ПО |
|
| Информация о прикладном ПО |
|
| Информация о средствах защиты, установленных в ИС |
|
| Информация о топологии ИС |
|
Как уже отмечалось выше, для сбора исходных данных применяются следующие методы.
Интервьюирование сотрудников заказчика, обладающих необходимой информацией. Интервью обычно проводятся как с техническими специалистами, так и с представителями руководящего звена компании. Перечень вопросов, которые планируется обсудить в процессе интервью, согласовывается заранее.
Предоставление опросных листов по определенной тематике, которые сотрудники заказчика заполняют самостоятельно. В тех случаях, когда представленные материалы не полностью отвечают на необходимые вопросы, проводится дополнительное интервьюирование.
Анализ организационно-технической документации, используемой заказчиком.
Использование специализированного ПО, которое позволяет получить необходимую информацию о составе и настройках программно-аппаратного обеспечения ИС предприятия. Например, с помощью систем анализа защищенности (security scanners) можно провести инвентаризацию сетевых ресурсов и выявить уязвимости в них. В качестве примеров таких систем можно назвать Internet Scanner компании ISS и XSpider компании Positive Technologies.
Оценка уровня безопасности ИС
После сбора необходимой информации проводится ее анализ с целью оценки текущего уровня защищенности системы. В процессе такого анализа определяются риски информационной безопасности, которым подвержена компания. Фактически риск представляет собой интегральную оценку того, насколько эффективно существующие средства защиты способны противостоять информационным атакам.
Обычно выделяют две основные группы методов расчета рисков безопасности. Первая группа позволяет установить уровень риска путем оценки степени соответствия определенному набору требований к информационной безопасности. В качестве источников таких требований могут выступать:
- нормативно-правовые документы предприятия, касающиеся вопросов информационной безопасности (политика безопасности, регламенты, приказы, распоряжения);
- требования действующего российского законодательства — руководящие документы ФСТЭК (Гостехкомиссии), СТР-К, требования ФСБ РФ, ГОСТы и т. д.;
- рекомендации международных стандартов — ISO 17799, OCTAVE, CoBIT, BS 7799-2 и т. д.;
- рекомендации компаний-производителей программного и аппаратного обеспечения — Microsoft, Oracle, Cisco и т. д.
Вторая группа методов оценки рисков информационной безопасности базируется на определении вероятности реализации атак, а также уровней их ущерба. Значение риска вычисляется отдельно для каждой атаки и в общем случае представляется как произведение вероятности проведения атаки a на величину возможного ущерба от этой атаки — Риск (a) = P(a) . Ущерб (a). Значение ущерба определяется собственником информационного ресурса, а вероятность атаки вычисляется группой экспертов, проводящих процедуру аудита. Вероятность в данном случае рассматривается как мера того, что в результате проведения атаки нарушители достигли своих целей и нанесли ущерб компании.
Методы обеих групп могут использовать количественные или качественные шкалы для определения величины риска информационной безопасности. В первом случае для риска и всех его параметров берутся численные выражения. Например, при использовании количественных шкал вероятность проведения атаки P(a) может выражаться числом в интервале , а ущерб от атаки — задаваться в виде денежного эквивалента материальных потерь, которые может понести организация в случае успешной атаки. При использовании качественных шкал числовые значения заменяются на эквивалентные им понятийные уровни. Каждому понятийному уровню в этом случае будет соответствовать определенный интервал количественной шкалы оценки. Количество уровней может варьироваться в зависимости от применяемых методик оценки рисков. В табл. 2 и 3 приведены примеры качественных шкал оценки рисков информационной безопасности, в которых для оценки уровней ущерба и вероятности атаки используется пять понятийных уровней.
Таблица 2. Качественная шкала оценки уровня ущерба
| № | Уровень ущерба | Описание |
| 1 | Малый | Незначительные потери материальных активов, которые быстро восстанавливаются, или незначительные последствия для репутации компании |
| 2 | Умеренный | Заметные потери материальных активов или умеренные последствия для репутации компании |
| 3 | Средней тяжести | Существенные потери материальных активов или значительный урон репутации компании |
| 4 | Большой | Большие потери материальных активов и большой урон репутации компании |
| 5 | Критический | Критические потери материальных активов или полная потеря репутации компании на рынке, что делает невозможным ее дальнейшую деятельность |
Таблица 3. Качественная шкала оценки вероятности проведения атаки
| № | Вероятность атаки | Описание |
| 1 | Очень низкая | Атака практически никогда не будет проведена. Соответствует числовому интервалу вероятности |
| 5 | Очень высокая | Атака почти наверняка будет проведена. Соответствует числовому интервалу вероятности (0,75, 1] |
Для вычисления уровня риска по качественным шкалам применяются специальные таблицы, в которых в первом столбце задаются понятийные уровни ущерба, а в первой строке — уровни вероятности атаки. Ячейки же таблицы, расположенные на пересечении соответствующих строк и столбцов, содержат уровень риска безопасности (табл. 4). Размерность таблицы зависит от количества концептуальных уровней вероятности атаки и ущерба.
Таблица 4. Определение уровня риска информационной безопасности по качественной шкале
| Вероятность атаки | |||||
| Ущерб | очень низкая | низкая | средняя | высокая | очень высокая |
| Малый | Низкий риск | Низкий риск | Низкий риск | Средний риск | Средний риск |
| Умеренный | Низкий риск | Низкий риск | Средний риск | Средний риск | Высокий риск |
| Средней тяжести | Низкий риск | Средний риск | Средний риск | Средний риск | Высокий риск |
| Большой | Средний риск | Средний риск | Средний риск | Средний риск | Высокий риск |
| Критический | Средний риск | Высокий риск | Высокий риск | Высокий риск | Высокий риск |
При расчете значений вероятности атаки, а также уровня возможного ущерба используют статистические методы, экспертные оценки или элементы теории принятия решений. Статистические методы предполагают анализ уже накопленных данных о реально случавшихся инцидентах, связанных с нарушением информационной безопасности. На основе результатов такого анализа строятся предположения о вероятности проведения атак и уровнях ущерба от них в других ИС. Однако статистические методы не всегда удается применить из-за недостатка статистических данных о ранее проведенных атаках на ресурсы ИС, аналогичной той, которая выступает в качестве объекта оценки.
При использовании аппарата экспертных оценок анализируются результаты работы группы экспертов, компетентных в области информационной безопасности, которые на основе имеющегося у них опыта определяют количественные или качественные уровни риска. Элементы теории принятия решений позволяют применять для вычисления значения риска безопасности более сложные алгоритмы обработки результатов работы группы экспертов.
Существуют специализированные программные комплексы, позволяющие автоматизировать процесс анализа исходных данных и расчета значений рисков при аудите безопасности. Примеры таких комплексов — «Гриф» и «Кондор» компании Digital Security, а также «АванГард», разработанный в Институте системного анализа РАН.
Результаты аудита безопасности
На последнем этапе аудита информационной безопасности разрабатываются рекомендации по совершенствованию организационно-технического обеспечения защиты на предприятии. Такие рекомендации могут включать в себя различные типы действий, направленных на минимизацию выявленных рисков.
Уменьшение риска за счет дополнительных организационных и технических средств защиты, позволяющих снизить вероятность проведения атаки или уменьшить возможный ущерб от нее. Так, установка межсетевых экранов в точке подключения ИС к Интернету существенно снижает вероятность проведения успешной атаки на общедоступные информационные ресурсы ИС — такие, как Web-серверы, почтовые серверы и т. д.
Уклонение от риска путем изменения архитектуры или схемы информационных потоков ИС, что позволяет исключить проведение той или иной атаки. Например, физическое отключение от Интернета сегмента ИС, в котором обрабатывается конфиденциальная информация, позволяет избежать внешних атак на конфиденциальную информацию.
Изменение характера риска в результате принятия мер по страхованию. В качестве примеров изменения характера риска можно привести страхование оборудования ИС от пожара или страхование информационных ресурсов от возможного нарушения их конфиденциальности, целостности или доступности. В настоящее время ряд российских компаний уже предлагают услуги страхования информационных рисков.
Принятие риска, если он уменьшен до того уровня, на котором уже не представляет опасности для ИС.
Обычно рекомендации направлены не на полное устранение всех выявленных рисков, а лишь на их уменьшение до приемлемого уровня. При выборе мер для повышения уровня защиты ИС учитывается одно принципиальное ограничение — стоимость реализации этих мер не должна превышать стоимости защищаемых информационных ресурсов, а также убытков компании от возможного нарушения конфиденциальности, целостности или доступности информации.
В завершение процедуры аудита его результаты оформляются в виде отчетного документа, который предоставляется заказчику. В общем случае этот документ состоит из следующих основных разделов:
- описание границ, в рамках которых проводился аудит безопасности;
- описание структуры ИС заказчика;
- методы и средства, которые использовались в процессе проведения аудита;
- описание выявленных уязвимостей и недостатков, включая уровень их риска;
- рекомендации по совершенствованию комплексной системы обеспечения информационной безопасности;
- предложения к плану реализации первоочередных мер, направленных на минимизацию выявленных рисков.
Заключение
Аудит информационной безопасности — один из наиболее эффективных сегодня инструментов для получения независимой и объективной оценки текущего уровня защищенности предприятия от угроз информационной безопасности. Кроме того, результаты аудита дают основу для формирования стратегии развития системы обеспечения информационной безопасности организации. Однако необходимо понимать, что аудит безопасности — не разовая процедура, он должен проводиться на регулярной основе. Только в этом случае аудит будет приносить реальную отдачу и способствовать повышению уровня информационной безопасности компании.
Аудит информационной безопасности (ИБ) является основным инструментом контроля состояния защищенности информационных активов компании/организации. Сервис может выполняться как в совокупности с общим ИТ-аудитом, так и в виде самостоятельного проекта. Часто аудит является неотъемлемой частью комплексных проектов по обеспечению безопасности информации и выполняется в качестве стартового этапа проекта.
Аудит ИБ включает в себя технический аудит и организационно-методический аудит. В свою очередь, технический аудит обычно разделяется на общий аудит и инструментальный аудит.
IBS выполняет аудит на соответствие требованиям в одной или нескольких предметных областях:
- законодательство и требования по защите персональных данных (ФЗ-152, 21-й приказ ФСТЭК и др.);
- требования по защите информации в государственных информационных системах (17-й приказ ФСТЭК и др.);
- законодательство и требования в области защиты информации в национальной платежной системе (ФЗ-161 и др.);
- отраслевые требования, стандарты и рекомендации по защите информации в финансовых организациях, фин.процессинге (СТО БР ИББС-1.0, 382-П и др.);
- аудит в области процессов (ISO 27001 и другие).
Результатом аудита является заключение о степени соответствия компании/организации критериям аудита, а также рекомендации по совершенствованию ИТ-инфраструктуры, защиты информации, процессов обеспечения и управления ИБ и документационного обеспечения заказчика.
Инструментальный аудит включает в себя следующие направления:
- аудит защищенности ИТ-инфраструктуры и информационных систем;
- тест на проникновение (pen-тест);
- аудит информационных потоков в компании/организации;
- контроль исходного кода приложений на уязвимости/закладки.
Логическим продолжением аудита является разработка корпоративных документов верхнего уровня по вопросам безопасности информации в компании/организации, среди которых:
- корпоративная политика ИБ;
- концепция обеспечения ИБ;
- корпоративная модель угроз безопасности информации.
Разработанные верхнеуровневые документы обеспечивают базис для выстраивания всего комплекса работ по приведению процессов и технологий обеспечения и управления ИБ в компании/организации в соответствие требованиям законодательства, нормативным документам, лучшим практикам ИБ.
Формирование и выстраивание процессов обеспечения ИБ и управления ИБ является неотъемлемой составляющей процессной модели функционирования компаний на средних и высоких уровнях зрелости ИТ.
Для публичных компаний аудит ИБ является элементом неотъемлемой составляющей независимой внешней оценки рыночной стоимости компании, внося таким образом свой вклад в капитализацию компании.
Ключевые результаты
В результате выполнения проекта в зависимости от его масштаба и границ заказчик получит независимую оценку состояния обеспечения ИБ в его компании/организации, степень его соответствия обязательным законодательным, нормативным и отраслевым требованиям по вопросам защиты информации, степени уязвимости его ИТ- и ИБ-инфраструктуры и информационных систем к современным угрозам, а также могут быть выявлены свидетельства противоправной деятельности в его информационном пространстве различной природы.