Добрый день!
Я хотел бы осветить вопрос соблюдения требований к управлению ИТ отдела в рамках внешнего финансового аудита компании. Цель статьи заключается не в описании сопутствующих законов, а в их конкретном влиянии на управление ИТ отдела.
Вероятно, многие из вас уже сталкивались с этими требованиями в виде либо каждодневной рутины, либо авралов в конце календарного года (больше склоняюсь ко-второму), но лично я, кроме упоминаний таких понятий как SOX, HIPAA, SAS 70 (заменен на SSAE 16) и ITGC, не встречал сколько-нибудь исчерпывающего описания этого вопроса.
Не так давно, в рамках своей работы я подготовил презентацию для новых сотрудников, которая дает минимальное представление об этом виде деятельности нашей фирмы. Собственно говоря, сама презентация и сподвигла меня на написание данной статьи. Здесь я хочу заметить, что мой опыт работы на территории стран СНГ весьма ограничен – я больше работаю с международными компаниями.
Если вас интересует данный вопрос, добро пожаловать.
Вступление
Проведу краткий экскурс в историю возникновения этих требований: вследствие финансовых махинаций в нескольких крупных компаниях в начале 2000-ых, президентом США был утвержден закон SOX, касающийся прямой ответственности высшего звена менеджеров за достоверность финансовой отчетности. Поскольку финансовая отчетность в наше время ведется не в амбарных книгах, а в специализированных информационных системах, возникла необходимость удостовериться в том, что на хранящиеся в этих системах финансовые данные можно положиться.
У каждого из вас может возникнуть вопрос, каким образом это касается компании, где вы работаете? В случае если компания котируется на фондовом рынке в США, либо является дочерней для одной из таких компаний, необходимо создать внутренний механизм контроля за работой ИТ отдела. Разумеется, что необходимо создание подобного механизма и в других отделах, но здесь я повторюсь, что целью данной статьи является ИТ отдел.
Итак, каким образом создается такой механизм контроля? Как правило, компания обращается к консалтинговой фирме, которая выступает представителем этой компании в переговорах с аудиторской фирмой, причем в роли консультанта может выступить и другая аудиторская фирма. Консалтинговая компания использует свои наработки, подгоняя их в той или иной степени под каждую конкретную компанию.
Что же это за наработки? По сути, это обычная таблица в Excel, содержащая риски и контроли, скомпонованные по темам, которые я опишу в дальнейшем. Откуда взялись эти риски и контроли? В зависимости от степени самоотверженности сотрудников консалтинговых фирм, начиная с тщательного изучения различных стандартов (COBIT, ITIL, COSO), их последующего анализа и построения своей собственной «библиотеки» рисков и контролей, и заканчивая простым плагиатом, как правило, бывшими сотрудниками крупных фирм, отправившимися в свободное плавание.
Процесс аудита ИТ отдела можно разделить на два отрезка времени. Первый, как правило, протекает поздней весной либо в начале лета, он включает в себя описание ИТ процессов и контролей (заполнение матриц) и требует предоставить минимум один документированный пример для каждого ключевого контроля. По своему опыту могу заявить, что этот этап чрезвычайно важен для самого ИТ отдела – при отсутствии тщательной проверки описанных ИТ процессов и контролей, возможные неточности могут дорого обойтись в будущем. Вторая часть аудита выпадает на осень, и включает в себя тестирование всех ключевых контролей посредством сбора документации по этим контролям.
Здесь требуется небольшое объяснение разницы между обычным и ключевым контролем: обычный контроль вносится в матрицу в виде описания, ключевой же, помимо описания, необходимо протестировать. Как узнать, где необходимо предоставить документацию по контролю, а где можно ограничиться всего лишь упоминанием? Никак. Это обговаривается между посредником и аудитором, на основании размера компании, результатов первой части аудита и т.д. Вместе с тем, по большинству из приведенных ниже контролей, необходимо предоставить документацию.
Перед началом описания процесса аудита я хотел бы упомянуть тему приказов и процедур – необходимо задокументировать все ключевые рабочие процессы ИТ отдела. Эти документы должны быть утверждены руководством компании, периодически пересматриваться и обновляться в случае существенных изменений в процессах либо технологиях.
И еще одно замечание: по возможности предоставляйте списки в формате Excel – этим вы облегчите жизнь и аудиторам, и себе (повторные требования с просьбами предоставить то же самое, но в другом виде могут заставить вас понервничать).
Перейдем к описанию контролей. Таблица рисков и контролей подразделяется на три части:
1. Логический и физический доступ
2. Эксплуатация информационных систем
3. Управление изменениями в информационных системах
Четвертая часть, «Разработка информационных систем», как правило, проверяется в рамках управления изменениями, поскольку фокусируется на документировании изменений.
Логический и физический доступ
Первый раздел — Логический и физический доступ ко всем информационным системам, на которых фокусируется аудит.
1. Администраторы систем – здесь требуется предоставить список администраторов в каждой системе, включая сеть компании (Administrators, Domain, Enterprise и Scheme Admins) и базы данных. Список должен быть либо экспортирован из системы, либо предоставлен в виде скриншотов, причем первое предпочтительнее.
Для каждого сотрудника с правами администратора системы должен существовать приказ по утверждению. Также необходимо знать каждую сервисную учетную запись с аналогичными правами.
2. Права доступа сотрудников – проводится тестирование нескольких подпунктов:
a. Сотрудники, начавшие работу в тестируемом году – требуется предоставить список таких сотрудников, проще всего из бухгалтерской программы (исходя из факта, что нет сотрудника, который не получает зарплату).
b. Сотрудники, закончившие работу в тестируемом году – аналогично, список таких сотрудников.
c. Сотрудники, сменившие должность – список сотрудников.
d. Дополнительно следует предоставить полные списки пользователей во всех системах, включая сеть компании и базы данных
По запросу аудиторов (полный список либо выборка), следует предоставить заполненные и заверенные бланки найма и увольнения сотрудников.
Будет проведена перекрестная проверка данных: есть ли сотрудники, получившие права доступа к каким-либо системам без соответствующего разрешения, есть ли уволенные/уволившиеся сотрудники с открытыми правами доступа, есть ли неиспользуемые открытые учетные записи (вход в систему больше 90-180 дней назад).
Так же проверяется выполнение ежегодной процедуры ревизии прав пользователей – необходимо предоставить заверенный список пользователей и их прав в каждой системе. Кстати, с помощью этой проверки можно обнаружить не закрытые вовремя учетные записи уволенных/уволившихся сотрудников.
3. Права удаленного доступа – необходимо предоставить список всех сотрудников с удаленными правами доступа. Так же может проверяться выполнение процедуры ревизии списка сотрудников в рамках ежегодной процедуры ревизии прав пользователей. В случае если в AD существует отдельная группа с данными правами – готовьтесь к дополнительной перекрестной проверке.
4. Права для локальной установки программ – желательно, чтобы ни один сотрудник не был локальным администратором на своем компьютере.
5. Внешние подключения – желательно заблокировать CD-ROM, USB-порты, LAN-розетки и Wi-Fi-точки. Плюс использовать систему слежения и оповещения за подключениями.
6. Политика паролей – необходимо предоставить скриншот экрана настроек пароля для всех систем, а также AD. Минимальные требования к паролю:
a. длина минимум 6 символов
b. использование различных символов
c. смена пароля максимум через 90 дней, минимум через день
d. сохранение истории паролей минимум 5 поколений, либо год
e. отсутствие возможности восстановить пароль
f. блокирование учетной записи максимум после 5 неправильных попыток
g. разблокирование учетной записи администратором сети (желательно не использовать автоматический сброс блокировки)
Также будет проведена проверка даты последней смены пароля в AD у всех учетных записей.
7. Межсетевой экран – скриншот версии FW, списка администраторов FW, списка рассылки предупреждений. Также могут потребовать заверенную периодическую проверку правил в FW. В особо тяжелых случаях просмотрят лог или потребуют документ, удостоверяющий (!), что такая проверка выполняется.
8. Антивирус – скриншот версии AV, списка рассылки предупреждений, экрана настроек обновлений сервера AV и клиентов.
9. Безопасность ноутбуков – довольно редко (пока еще) требуют предоставить список сотрудников с ноутбуками. Шифруются ли жесткие диски, если да, то каким образом.
10. Управление чрезвычайными происшествиями – каждая компания должна вести список таких происшествий (попытки взлома сети и т.д.). Желательно передавать ежеквартальные отчеты вышестоящему руководству.
Эксплуатация информационных систем
Ну что же, с безопасностью информационных систем вроде разобрались. Перейдем непосредственно к их эксплуатации.
1. Резервное копирование данных – одна из основных проверок в этом разделе.
Следует предоставить скриншот версии программы бэкапа, списка рассылки статуса выполнения заданий, а также экрана настроек бэкапа. Поскольку, как правило, каждая финансовая система устанавливается на свой виртуальный сервер, да и требования к бэкапу могут быть разными (полный, дифференциальный, инкрементальный), потребуется соответствующее количество скриншотов. Непрерывность процесса резервного копирования проверяется просмотром логов, поэтому необходимо хранить логи бэкапа за три предыдущих месяца, а еще лучше — за весь тестируемый год. Здесь ищутся проблемы с бэкапом систем, длящиеся больше 2-3 дней. В таком случае следует хранить отчет вышестоящему руководству, хотя бы в виде сообщения по электронной почте.
2. Проверка восстановления данных – необходимо предоставить логи восстановления данных с кассет. Опытный аудитор не ограничится несколькими документами с файлового сервера, поэтому желательно выполнять восстановления баз данных и финансовых систем.
3. Кассеты для резервного копирования – политика круговорота и перезаписи кассет должна отвечать следующим правилам:
a. ежедневные кассеты должны храниться минимум две недели
b. недельные кассеты – минимум месяц
c. месячные кассеты – минимум год
d. годичные кассеты – минимум семь лет
Кассеты необходимо хранить в огнеупорном сейфе, как минимум не в серверной комнате, а лучше в другом здании. Соответственно, необходимо иметь список всех сотрудников с доступом к сейфу.
4. Доступ в серверную комнату – следует предоставить заверенный список сотрудников с доступом в серверную комнату. Необходимо вести журнал посещений, а сделать это посредством установки специализированной системы контроля доступа. На мой взгляд, достаточно обычной системы доступа по личным удостоверениям (ID tag). Я бы посоветовал периодически просматривать журнал посещений – в некоторых случаях, вам может открыться интересная картина.
5. Контроль окружающей среды в серверной комнате – наличие датчиков дыма, огня, затопления, независимая система кондиционирования (от близлежащих помещений), наличие UPS и генератора, список сотрудников, получающих уведомления в экстренных случаях.
6. Резервный ДЦ – расстояние от головного офиса, способ передачи данных, наличие плана BCM/DRP (ИТ отделу следует обратить внимание на вторую часть плана), осуществление ежегодных (как минимум) учений по плану.
7. Пакетная обработка данных – здесь подразумевается автоматическая обработка данных (как правило, выполняющаяся в ночное время), не требующая вмешательства операторов. Необходим список всех сотрудников с правами изменения настроек, список рассылки статуса выполнения обработки данных. Также могут потребовать предоставить лог и исследовать его на предмет ошибок, как в случае с бэкапами.
8. Интерфейсы – в принципе взаимосвязано с предыдущим пунктом, но все же упомяну этот контроль. Желательно иметь схему интерфейсов всех финансовых систем (не только между ними, а к ним и от них).
9. Решение проблем инфраструктуры – здесь подразумевается внутренний колл-центр для регистрации и последующего решения всех возникающих в компании проблем, в той или иной степени связанных с информационными системами и инфраструктурой (упал сервер, отключили электричество, не работает мышь, две кнопки «Пуск» и т.д.). Управление чрезвычайными происшествиями из предыдущего раздела может осуществляться в рамках этого контроля.
Управление изменениями в информационных системах
Два раздела позади, остался один, требующий пристального внимания, поскольку для успешного прохождения аудита, как правило, необходимы изменения в самих рабочих процессах. Итак, управление изменениями в информационных системах.
Начну с нескольких замечаний. Первое – необходимо иметь задокументированные и утвержденные процедуры разработки. Второе – очень и очень желательно иметь специализированную систему для управления разработкой, в которой будет задокументировано каждое изменение. Третье – при условии ведения разработки в аутсорсинге, либо использования коробочных версии продуктов, аудит будет несколько отличаться.
1. Рабочие среды – очень просто: для каждой финансовой системы предоставить скриншоты как минимум трех рабочих сред – разработки, тестирования и боевой. Для вышеупомянутых случаев, достаточно двух последних скриншотов (да-да, даже для коробочной версии должна быть среда тестирования).
2. Доступ к рабочим средам – списки учетных записей для каждой среды, список имен разработчиков и тестировщиков. Выполняется уже известная нам перекрестная проверка, смысл которой заключается в следующем: разработчикам и тестировщикам запрещен доступ в боевую среду, обычным пользователям запрещен доступ ко всему, кроме боевой среды. Если версия коробочная, достаточно списков к тестируемой и боевой средам. Это весьма проблематично сделать в компаниях малых и средних размеров, поэтому аудиторы идут на некоторые компромиссы.
3. Процесс переноса изменений – в идеале, сотрудник, отвечающий за перенос изменений из тестируемой среды в боевую, не имеет отношения ни к разработке, ни к бизнес-процессам. Опять-таки, в этом случае аудиторы тоже могут пойти на компромисс.
4. Изменения – необходимо предоставить список всех изменений в финансовых системах, внедренных в тестируемом году. Не было таких? Значит скриншот папки с установленной системой, с файлами, упорядоченными по дате изменений. Ну, а если были, то будет вам выборка с просьбой предоставить следующую документацию:
a. Запрос на изменения от пользователя – специальные бланки, либо письмо по электронной почте.
b. Техническое задание для изменения – в зависимости от типа изменения (добавить поле в бланке либо разработать модуль с нуля) будет требоваться документация — от обычного письма с описанием изменения до полноценного многостраничного документа, заверенного подписями всевозможных начальников и руководителей.
c. Тестирование изменения – тест-кейсы с чек-листами и разрешение пользователя, что данное изменение удовлетворяет его запросу.
d. Разрешение на перенос изменения в боевую среду – за подписью руководителя, ответственного за разработку в данном направлении.
5. Управление критическими изменениями – по большому счету не отличается от предыдущего пункта. Единственное отличие – критические изменения обычно происходят без документации, поэтому важно получить все документы ретроактивно, и сохранить на будущее.
Вот вы и закончили сбор всей необходимой документации, что же делать дальше? Аудитор запросит у вас собранные документы и проведет их анализ. По некоторым контролям будут запрошены дополнительные документы, поскольку аудитору необходимо сохранять независимость от внутренних проверок (вдруг у вас есть только 10 запросов на открытие учетных записей для новых сотрудников, хотя самих сотрудников больше 50-ти; или вы стерли со скриншота группы администраторов домена учетную запись генерального директора). А дальше таблица рисков и контролей будет заполнена результатами тестов и представлена на обсуждение руководителю ИТ отдела и финансовому директору компании (поскольку он несет ответственность за финансовую отчетность).
Заключение
Работа аудитора заключается в том, чтобы находить дефекты и недостатки в процессах и контролях. Даже если все работает идеально, аудитор может зацепиться за незначительную мелочь и раскрутить ее до серьезного недостатка. Небольшое отступление: недостатки делятся на три категории – недостаток (дефект), серьезный недостаток и существенный недостаток, причем последний вносится в годовую финансовую отчетность и может повлиять на стоимость компании. Опытный руководитель ИТ отдела может использовать этот нюанс в целях запроса на выделение дополнительного бюджета под нужды отдела. Факт отсутствия огнеупорного сейфа или системы контроля доступа в серверную комнату второй год подряд, поднимается до уровня комитета по аудиту, состоящего из членов совета директоров, что при правильном подходе позволяет получить необходимый бюджет для устранения недостатка.
На мой взгляд, это описание в достаточной мере дает представление о процессе внешнего аудита ИТ отдела, но я думаю, что главный вопрос заключается в следующем: можно ли самостоятельно подготовиться к внешнему аудиту ИТ отдела, не прибегая к помощи посредников? На основании своего опыта, я заявляю, что можно, хотя это и требует приложить определенные усилия, но в конечном итоге позволит ежегодно сэкономить приличную сумму. Вместе с тем, если вы готовитесь к аудиту впервые и не уверены в своих силах и знаниях, я все же порекомендовал бы нанять хорошую консалтинговую фирму. Правда, желательно выделить одного сотрудника для помощи в подготовке к аудиту, чтобы в дальнейшем он взял на себя эту обязанность.
Надеюсь, представленная информация будет полезна как непосредственно принимающим участие в аудите, так и более широкой публике.
С радостью отвечу на все возникшие вопросы.
Автор: freebornman
