Корпоративное управление и эффективность ИТ

Эффективное корпоративное управление ИТ позволяет обеспе­чить реальную пользу от информационных систем и контроль рис­ков, связанных с информационными технологиями. Вопросы управ­ления и контроля в сфере ИТ также являются предметом особого внимания в свете постоянно меняющихся потребностей бизнеса и требований нормативных актов, таких, как закон Сарбэйнса—Окс- пи, МСФО и Basel II, а также необходимости обеспечения прозрач­ности для акционеров.

КПМГ предлагает широкий перечень услуг в области корпора­тивного управления и эффективности ИТ, включающий в себя по­мощь руководству компаний в решении следующих вопросов:

• разработка адекватной ИТ-стратегии;

• измерение экономическою эффекта от ИТ;

• определение реальных затрат на ИТ;

• оценка того, что инвестиции в ИТ надлежащим образом уп­равляются, учитываются риски и определены направления развития;

• внедрение таких стандартов, как CobiT и ITIL.

Услуги в области информационной безопасности, конфиденциальности персональных данных и планировании непрерывности бизнеса

В современном мире репутация бизнеса, а также само его существование могут в большой степени зависеть от того, на­сколько хорошо внедрены меры по обеспечению безопасности бизнеса, непрерывности и конфиденциальности персональных данных. Эффективность основополагающих мер контроля, таких, как разделение полномочий, нередко полностью зависит от ре­ализации мер контроля доступа в области информационных тех­нологий. В мире глобальных телекоммуникационных сетей уязви­мости в системе безопасности могут быть легко использованы злоумышленниками. Получившие широкую огласку случаи мошен­ничества подрывают общественное доверие. Наши услуги помо­гают клиентам ставить вопросы безопасности, конфиденциаль­ности и непрерывности бизнеса как перед высшим руководством, так и перед службами ИТ и информационной безопасности. В области информационной безопасности КПМГ, в частности, является аккредитованной компанией на проведение аудита по стандарту ISO 27001; наша компания также принимает участие в разработке стандартов информационной безопасности для российского банковского сектора.

Услуги по аттестации в области ИТ

В современных условиях, когда клиенты организаций, предостав­ляющих услуги, напрямую зависят от информационных систем этих организаций, нередко нужны дополнительные гарантии для удовлет­ворения ожиданий этих клиентов в отношении надежности и безо­пасности обработки их данных.

SAS 70 и подобные аттестационные стандарты направлены на подтверждение того, что организации прошли всеобъемлющую про­верку эффективности мер контроля. Эта проверка предусматрива­ет оценку мер контроля как над совершением транзакций, так и в области ИТ-процессов. По результатам проверки клиентам орга­низации представляется заключение независимого аудитора о ка­честве системы внутреннего контроля организации.

Бизнес-процессы и мониторинг внутренней системы контроля

В то время как многие компании оценили преимущества нали­чия документированной внутренней системы контроля в области процессов подготовки финансовой отчетности, большое количество компаний до сих пор не уверены в отношении эффективности мер контроля за бизнесом в целом. Соответствующий мониторинг эф­фективности мер контроля является серьезной задачей. Внедрение сложных ERP-систем, таких, как SAP R/3 и Oracle Applications, по­зволяет компаниям контролировать эффективность мер контроля бизнес-процессов на различных уровнях. КПМГ помогает своим

клиентам в правильном выборе ключевых мер контроля и опреде­лении оценки их эффективности. Наш успех основан на детальном понимании целей бизнеса, а также ключевых приложений, которые используются в данной отрасли.

кпмг

119019, Москва, Гоголевский бульвар, д. 11 тел.: (495) 937-4477, факс: (495) 937-4400 www.kpmg.rumoscow@kpmg.ru

3.1.2. Национальные стандарты и руководства по основам аудита информационной безопасности

Среди национальных стандартов и руководств по основам аудита ИБ и самооценки соответствия ИБ установленным требованиям выделим для рассмотрения следующие документы ввиду их практической на­правленности:

GA0/AIMD-12.19.6 «Руководство по аудиту средств управления федеральных информационных систем» (Federal information system controls audit manual, FISCAM);

NIST 800-26 «Руководство по самооценке безопасности для систем информационной технологии» (Security Se If-Assessment Guide for Information Technology Systems);

NIST 800-55 «Руководство по метрикам безопасности для систем информационной технологии» (Security Metrics Guide for Information Technology Systems).

Документ GA0/AIMD-12.19.6 «Руковод- 3.1.2.1. GA0/AIMD-12.19.6 ctbo по аудиту средств управления фе- «Руководство по аудиту деральных информационных систем» средств управления

(Federal information system controls audit федеральных

manual, FISCAM) является составной ча- информационных систем» стью схемы формирования и предостав­ления отчетности Контрольно-ревизионным управлением (GA0) Кон­грессу США о состоянии дел в сфере обеспечения ИБ федеральных

агентств. Руководство РБСАМ используется аудиторами ОАО и реви­зорами в качестве методологической основы для проведения аудита средств обеспечения ИБ агентств.

Руководство предназначено для использования при проведении внешних аудитов двух типов:

1) финансового аудита (аудита финансовой отчетности федераль­ных агентств США);

2) аудита безопасности ИС федеральных агентств США.

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

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

Данный документ предназначен как для аудиторов ИС, так и для финансовых аудиторов, подтвердивших, что они обладают необходи­мыми знаниями, навыками и способностями для выполнения проце­дур аудита в компьютерной среде.

Руководство РБСАМ рассматривает цели управления (безопаснос­тью), реализацию которых должны проверять аудиторы при оценке компьютерных средств управления, и предоставляет примеры мето­дов и средств управления (обеспечения ИБ), обычно используемых в федеральных агентствах, а также процедуры их аудита.

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

Методология, которая должна использоваться для оценки компью­терных средств управления, включает оценку:

общих средств управления на уровне организации или системы;

общих средств управления, относящихся к изучаемому приложе­нию (приложениям), такому, как система платежных ведомостей или система учета кредитов;

прикладных средств управления, являющихся средствами управле­ния ввода, обработки и вывода данных, связанных с индивидуальны­ми приложениями.

Общие средства управления представляют собой политики и про­цедуры, относящиеся ко всем или к большей части ИС организации и помогающие обеспечивать их надлежащую деятельность. Целями об­щих средств управления являются:

— обеспечение защиты данных;

— защита прикладного программного обеспечения;

— предупреждение несанкционированного доступа к системному программному обеспечению;

— обеспечение бесперебойности работы ИС в случае неожидан­ных нарушений.

Эффективность общих средств управления является важным фак­тором в определении эффективности прикладных средств управления.

В данном документе рассматриваются процедуры оценки и тести­рования именно общих средств управления.

При проверке компьютерных средств управления для аудита фи­нансовой отчетности требуют решения и являются составными частя­ми методологии следующие задачи:

определение характера и объема процедур аудита. Характер и объем процедур аудита, необходимых для оценки компьютерных средств управления, меняется в зависимости от целей аудита и ряда других факторов. К таким факторам относятся характер и слож­ность ИС организации, среда средств управления организации и конкретные расчеты и приложения, которые важны для финансо­вой отчетности. Аудитор ИС и финансовый аудитор должны дей­ствовать согласованно для определения того, какая проверка не­обходима;

проверка компьютерных средств управления в аудитах финансо­вой отчетности. Компьютерные средства управления должны рас­сматриваться на каждой из четырех стадий аудита: планирование, внут­ренний контроль, тестирование и составление отчета. На каждой стадии аудита финансовой отчетности проводятся следующие мероп­риятия:

— стадия планирования. На стадии планирования аудитор дос­тигает понимания компьютерных операций и средств управле­ния организации, и соответствующих рисков;

— стадия внутреннего контроля. На стадии внутреннего конт­роля аудиторы получают подробную информацию о политике, процедурах и целях управления и осуществляют тестирование мероприятий по управлению с целью определения эффектив­ности действия средств управления.

Вначале аудитор тестирует общие средства управления в масштабе организации или системы путем наблюдения, наведения справок и обследования. Если данные средства управления действуют эффек­тивно, аудитор должен протестировать и оценить эффективность об­щих средств управления для приложений, которые важны для аудита;

— стадия тестирования. На стадии тестирования аудиторы сосредоточиваются в основном на тестировании по существу. Тесты обычно включают изучение исходной документации, поддерживающей транзакции, чтобы определить, были ли их фиксирование, обработка и сообщение надлежащими и пол­ными. Аудитор ИС может помогать финансовым аудиторам в идентификации и выборе компьютерных транзакций для тес­тирования, возможно, используя аудиторское программное обеспечение;

— стадия составления отчета. На стадии составления отчета аудитор делает заключения и составляет отчет в соответствии с предписаниями и законами.

Планирование является основой качественного аудита, а связан­ная с ИС часть — важной частью общего процесса.

Планирование позволяет аудитору и руководству аудиторской груп­пы определять эффективные и продуктивные методы получения дан­ных, необходимых для оценки компьютерных средств управления орга­низации. Хотя планирование относится к началу аудита, оно представляет собой итеративный процесс, выполняемый фактически на всем протяжении аудита. Это обусловлено тем, что результаты пред­варительных оценок являются основанием для определения объема и вида последующего тестирования.

Например, если аудиторы получают данные о том, что конкретные процедуры управления неэффективны, они могут заново оценить свои предыдущие выводы и плановые решения, принятые на основе этих выводов.

На стадии планирования аудитор:

достигает понимания операций организации и идентифицирует компьютерные операции, являющиеся важными для аудита;

оценивает свойственный риск и риск контроля;

выполняет предварительную оценку возможной эффективности общих средств управления;

идентифицирует подлежащие тестированию общие средства контроля.

На рисунках 9 и 10 изложены этапы оценки средств управления ИС при выполнении аудита финансовой отчетности агентств.

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

Далее аудитор оценивает свойственный риск и риск контроля, ко­торые имеют решающее значение при определении риска аудита. Риск аудита ИС можно представить в терминах трех компонентов риска:

1) свойственный риск — это риск того, что информационные ре­сурсы или ресурсы, контролируемые ИС, могут подвергаться хищению, разрушению, раскрытию, несанкционированной мо­дификации или другим повреждениям, предполагая, что свя­занные с ними средства внутреннего контроля отсутствуют;

2) риск контроля — это риск того, что некая существенная не­правильная запись в данных организации не будет предотвра­щена или обнаружена и своевременно исправлена внутренним контролем организации;

Рис. 9. Этапы оценки средств управления ИС при выполнении аудита финансовой отчетности

Рис. 10. Этапы оценки средств управления ИС при выполнении аудита финансовой отчетности (продолжение)

3) риск необнаружения — риск того, что аудитор не обнару­жит существенную неправильную запись в финансовой от­четности.

На основе уровня риска аудита и оценки свойственных рисков и рисков контроля организации аудитор определяет характер, сроки и объем основных процедур аудита, необходимых для достижения ре­зультирующего риска необнаружения. Например, в ответ на высокий уровень свойственных рисков и рисков контроля аудитор должен вы­полнить дополнительные процедуры аудита или более обширное тес­тирование по существу. Аудитор должен: (1) идентифицировать усло­вия, которые существенно увеличивают свойственные риски и риски контроля; (2) сделать выводы о том, не мешают ли они эффективнос­ти конкретных методов и средств управления в важных приложениях. В связи с тем что оценка риска требует принятия важного аудитор­ского решения, она должна выполняться квалифицированным персо­налом аудиторской группы.

Аудитор должен сделать предварительную оценку вероятной эф­фективности компьютерных средств управления. Эта оценка рассмат­ривается как часть оценки риска контроля и основывается главным образом на опросах персонала организации, включая руководителей программных менеджеров, системных администраторов, менеджеров информационных ресурсов и руководителей, отвечающих за безопас­ность ИС, а также на наблюдении за компьютерными операциями и на проверках документированных политик и процедур.

На основе оценок свойственных рисков и рисков контроля, вклю­чая предварительную оценку компьютерных средств управления, ауди­тор идентифицирует методы и средства общего управления, которые должны быть протестированы для определения их действительной эффективности.

Таким образом, планирование аудита позволяет выстроить эффек­тивную стратегию аудита, помогает аудиторам заранее определить сильные и слабые стороны общих средств управления организации, определить объем аудита и сроки его проведения и сконцентриро­вать свою деятельность на важных для организации средствах уп­равления.

Руководство FISCAM определяет шесть основных категорий общих средств управления, которые аудитор должен оценить и протестиро­вать. К ним относятся:

планирование и менеджмент программы обеспечения безопасно­сти в масштабах организации. Эти средства управления обеспечи­вают структуру и постоянный цикл мероприятий для менеджмента риска, разработки политик безопасности, назначения обязанностей и мониторинга адекватности компьютерных средств управления орга­низации;

управление доступом. Эти средства управления ограничивают до­ступ к компьютерным ресурсам, например данным, программам, обо­рудованию и аппаратуре, или обнаруживают доступ к ним, защищая таким образом эти ресурсы от несанкционированной модификации, потери или раскрытия;

средства управления разработкой и изменением прикладного про­граммного обеспечения. Данные средства предотвращают использо­вание неразрешенного ПО или несанкционированное внесение изме­нений в существующее ПО;

системное программное обеспечение. Эти средства ограничивают доступ и осуществляют мониторинг доступа к мощным программам и чувствительным файлам, которые, во-первых, управляют аппаратными средствами компьютеров и, во-вторых, обеспечивают защиту прило­жений, поддерживаемых системой;

разделение обязанностей. К числу таких средств относятся полити­ки, процедуры и организационная структура, которые обеспечивают невозможность контроля ключевых аспектов компьютерных операций одним специалистом. Следовательно, обеспечивается невозможность проведения несанкционированной деятельности или получения несан­кционированного доступа к активам или записям;

непрерывность обслуживания. Данные средства предназначены для обеспечения непрерывного выполнения или быстрого возобновления критических операций в случае непредвиденных событий и для за­щиты критичных и чувствительных данных в экстренных ситуациях.

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

Для каждого критического элемента аудитор должен сделать сум­марное определение в отношении эффективности соответствующих средств управления организации. Если средства управления для од­ного или более критических элементов каждой категории неэффек­тивны, то средства управления для всей категории вряд ли будут эф­фективными. Аудитор должен использовать профессиональное суждение, принимая такие решения.

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

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

После окончания процедуры аудита финансовый аудитор делает заключение и составляет отчет относительно финансового отчета про­веряемой организации, относительно заявлений руководства органи­зации по внутренним средствам управления и относительно соответ­ствия организации действующим законам и регламентам. Что касается внутренних средств управления, аудитор делает заключение о соот­ветствующих заявлениях руководства организации, в котором он оп­ределяет степень достаточности реализованных средств управления в организации в контексте достижения следующих целей управления (безопасности):

активы должны быть защищены от потерь, которые могут возник­нуть из-за их несанкционированного владения, использования или размещения;

транзакции должны выполняться в соответствии с предписаниями бюджетного органа, а также законами и регламентами, проверенными аудитором;

транзакции должны надлежащим образом регистрироваться, об­рабатываться и суммироваться с целью обеспечения возможности подготовки финансовой отчетности и поддержки ответственности за активы.

На основе оценок внутренних средств управления аудитор форми­рует заключение об эффективности средств управления организации в отношении ИБ. Следует обратить внимание на то, что финансовые аудиторы должны тесно работать с аудиторами ИС при оценке резуль­татов аудита и выработке заключения относительно заявлений руко­водства организации. Это позволит адекватно интерпретировать и от­разить в отчете результаты оценки средств управления вычислительных систем организации.

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

По результатам рассмотрения данного документа можно сделать вывод, что методология, методы и средства управления, а также про­цедуры их аудита, предлагаемые в FISCAM, могут быть полезными ис­точниками при разработке нормативных и методических документов, касающихся проведения аудита ИБ в организациях банковской систе­мы Российской Федерации.

Документ «Руководство по самооценке 3.1.2.2. NIST 800-26

безопасности для систем информацион- «Руководство

ной технологии» (NIST Special Publication по самооценке

800-26 Security Self-Assessment Guide for безопасности для систем Information Technology Systems) опреде- информационной

ляет метод для проведения самооценки технологии»

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

Результаты получаются в той форме, которую легко использовать для определения того, какого из пяти уровней, установленных в докумен­те «Федеральная структура оценки безопасности информационных тех­нологий» (Fédérai Information Technology Security Assessment Framework), организация достигает для каждой тематической области средств управления, охватываемой в анкете.

Данный документ служит дополнением к «Федеральной структуре оценки безопасности информационных технологий», разработанной Национальным институтом стандартов и технологий (National Institute of Standards and Technology, NIST) для Федерального совета директо­ров по информационным технологиям (Fédéral Chief Information Officer Council). Он обеспечивает руководство по применению «Федеральной структуры оценки безопасности информационных технологий» путем идентификации семнадцати областей средств управления. Кроме того, данное Руководство определяет цели и методы управления, которые могут быть измерены для каждой области.

Документ может использоваться руководителями любого уровня и теми лицами, которые несут ответственность за безопасность ИТ на системном и организационном уровнях. Кроме того, внутренние и вне­шние аудиторы могут использовать анкету как руководство при про­ведении анализа безопасности ИТ систем.

Данный документ содержит обширную анкету, определяющую спе­цифические цели и методы управления, использование которых по­зволяет тестировать и измерять безопасность системы или группы взаимосвязанных систем.

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

Система идентифицируется посредством определения границ вок­руг совокупности процессов, коммуникаций, памяти и связанных ре­сурсов. Элементы внутри данных границ составляют единую систему, каждый элемент которой должен:

находиться под одним и тем же административным средством уп­равления;

иметь одну и ту же функцию или цель выполнения;

иметь одни и те же операционные характеристики и требования безопасности;

находиться в одной и той же общей операционной среде.

Важный элемент оценки — определение эффективности гранич­ных средств управления безопасностью, если система является час­тью взаимосвязанных систем. Граничные средства управления дол­жны защищать систему или группу систем от несанкционированных воздействий. Если такие граничные средства управления неэффек­тивны, тогда безопасность анализируемых систем зависит от безо­пасности других систем, связанных с ними. Если отсутствуют эффек­тивные граничные средства управления, то руководством указывается необходимость определять и документировать адекватность средств управления каждой системы, которая связана с рассматриваемой системой.

Эффективное использование анкеты предполагает понимание зна­чимости оцениваемых систем и информации. Оценка может выражать­ся в уровне чувствительности или критичности систем и информации относительно каждой из пяти категорий защиты: целостности, конфи­денциальности, доступности, аутентичности и неотказуемости. Причем аутентичность и неотказуемость рассматриваются как свойства целост­ности.

Руководство предлагает три степени чувствительности: высокую, среднюю и низкую. Например, система и ее информация могут требо­вать высокую степень целостности и доступности, но низкую степень конфиденциальности.

Оценочная анкета содержит три раздела: титульный лист, вопросы и примечания. Анкета начинается с титульного листа, требующего опи­сательную информацию о главном приложении, системе общей под­держки или группе оцениваемых взаимосвязанных систем. Анкета обеспечивает иерархический подход к оценке системы посредством включения критических элементов и второстепенных вопросов. Уро­вень критических элементов следует определять на основе ответов на второстепенные вопросы. Второстепенные вопросы отражают цели и методы управления, которые могут реализовываться для соответствия критическим элементам. Допускается, что не все цели и методы уп­равления требуются для достижения критического элемента.

В качестве примера на рисунке 11 представлена часть анкеты из рассматриваемого Руководства.

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

Цели управления	Уровень 1 Политика	Уровень 2 Процедуры	Уровень 3 Реализо­вано	Уровень 4 Протести­ровано	Уровень 5 Интегри­ровано	Принято решение, основанное на риске	Коммен­тарии	Отметка о неприме­нимости
Персонал и безопасность ОМ В Циркуляр А-130, III
6.1. Критический элемент: Разделены ли обязанности для обеспечения минимума привилегий и индивидуальной ответственности?
6.1.1. Проводится ли анализ всех должностей с целью определения уровня их чувствительности? теС4М 50-1.2 ЫШ БР 800-18
6.1.2. Существуют ли в организации документирован­ные должностные инструкции, точно отражающие служебные обязанности и ответственности и которые также разделяют служебные обязанности? Я5 САМ 50-1.2

Рис. 11. Пример анкеты из N1^ БР 800-26

Организация может дополнять вопросы, но из анкеты не разреша­ется удалять вопросы или модифицировать их.

После каждого вопроса следует поле комментария и начальное поле. Поле комментария может использоваться для того, чтобы де­лать ссылку на поддерживающую документацию, которая прилагается к анкете. Начальное поле может использоваться, если принимается решение (на основе результатов оценки риска) не реализовывать сред­ство управления или если средство управления является непримени­мым для системы.

Вопросы делятся на три основные области управления: 1) адми­нистративные средства управления; 2) операционные средства управ­ления и 3) технические средства управления. В каждой из трех обла­стей управления имеется несколько тем: например, безопасность персонала, планирование чрезвычайных ситуаций и реагирование на инциденты представляют собой темы, находящиеся в операционной области управления. В анкете в общей сложности семнадцать тем; каждая тема содержит критические элементы и поддерживающие цели и методы управления безопасностью (вопросы) относительно систе­мы. Если некоторые цели и методы управления не реализовываются, это не удовлетворяет требованиям критических элементов.

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

Области управления безопасностью, предлагаемые данным Руко­водством для оценивания, представлены на рисунке 12.

Для того чтобы измерять реализацию необходимого средства уп­равления безопасностью, предлагается пять уровней эффективности для каждого ответа на вопрос о средстве управления безопасностью: уровень 1 — цель средства управления задокументирована в по­литике безопасности;

уровень 2 — средства управления безопасностью задокументи­рованы в качестве процедур;

уровень 3 — процедуры реализованы;

уровень 4 — процедуры и средства управления безопасностью тестируются и анализируются;

уровень 5 — процедуры и средства управления безопасностью полностью интегрируются во всеобъемлющую программу.

Административные средства управления

1. Менеджмент риска.

2. Проверка (анализ)средств

управления безопасностью.

3. Жизненный цикл.

4. Санкционирование обработки

9. Планирование чрезвычайных ситуаций.

10. Техническое обслуживание

аппаратных и программных средств системы.

11. Целостность данных.

12. Документация.

данных (сертификация

и аккредитация). 5. План безопасности системы.

13. Осведомленность, обучение и образование по вопросам безопасности.

Операционные средства управления

6. Персонал и безопасность.

7. Физическая защита.

8. Производственные средства

14. Способность реагировать на инциденты.

Технические средства управления

15. Идентификация и аутентификация.

16. Средства управления логическим

управления, средства управления

вводом/выводом.

Рис. 12. Области управления безопасностью

Метод для ответов на вопросы может основываться прежде всего на рассмотрении имеющих отношение к вопросам документов и тща­тельном исследовании и тестировании средств управления. Анализ, например, должен состоять из:

— тестирования имеющихся методов управления доступом путем выполнения испытания на проникновение;

— рассмотрения системной документации, такой, как формы зап­росов на изменение программного обеспечения, планы тести­рования и приемки;

— просмотра журналов безопасности и записей аудита.

доступом. 17. Записи аудита.

Эксперт должен по каждому вопросу определить совместно с вла­дельцем системы и с теми, кто несет ответственность за администриро­вание системы, подтверждает ли уровень чувствительности системы реализацию средства управления, определенного в вопросе. Если сред­ство управления применяется, то следует проверить, имеются ли доку­ментированные политики (уровень 1), процедуры для реализации сред­ства управления (уровень 2), реализовывается ли средство управления (уровень 3), тестируется ли средство управления, и, если оно оказыва­ется неэффективным, исправляется ли (уровень 4) и является ли сред­ство управления частью культуры организации (уровень 5).

На основе ответов на вопросы, касающиеся целей и методов уп­равления, совместно с владельцем системы и с теми, кто несет ответ­ственность за администрирование системы, эксперту следует сделать вывод об уровне критического элемента. Вывод должен учитывать относительную важность каждой цели/метода для достижения крити­ческого элемента и точность, с которой метод реализовывается, экс­плуатируется и тестируется.

Анкета может использоваться в двух целях. Во-первых, руководителя­ми организации, которые знают системы своей организации и средства управления безопасностью, для того чтобы определить, где для системы, группы систем или всей организации требуется повышение безопаснос­ти. Во-вторых, ее можно использовать в качестве руководства для все­сторонней оценки уровня безопасности системы. Результаты таких ана­лизов могут служить для: 1) отчета о выполнении требований; 2) подготовки к аудитам; 3) идентификации потребностей в ресурсах.

Заполненные анкеты самооценки могут являться источником для составления отчетов по безопасности, требуемых от организации. В от­чете необходимо рассматривать следующие темы по безопасности в масштабах организации:

— менеджмент безопасности;

— административные средства управления;

— операционные средства управления;

— технические средства управления;

— планируемые действия.

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

Целью документа «Руководство по метри- 3.1.2.3. NIST 800-55

кам безопасности для систем информаци- «Руководство по метрикам онной технологии» (NIST Special безопасности для систем Publication 800-55 Security Metrics Guide информационной

for Information Technology Systems) явля- технологии»

ется обеспечение стандартизированного

подхода к разработке, выбору и реализации метрик безопасности ИТ, подлежащих использованию для измерения эффективности применя­емых в организации средств управления ИБ.

В Руководстве представлена методология, рекомендованная для количественного измерения семнадцати тематических областей средств управления безопасностью, определенных в N151 800-26 «Руководство по самооценке безопасности для систем информационной техноло­гии». Методология измерения может использоваться для подтвержде­ния выполнения системных задач безопасности и подтверждения эф­фективности средств управления ИБ.

Руководство описывает, как организация через использование мет­рик может оценить адекватность соответствующих средств управле­ния ИБ, политик и процедур. Данный документ помогает менеджмен­ту решать, финансировать ли дополнительные ресурсы обеспечения безопасности или идентифицировать и оценивать непродуктивные средства управления. Документ объясняет процесс разработки и реа­лизации метрик, определяет роли и обязанности персонала организа­ции, ответственного за разработку и реализацию метрик безопаснос­ти ИТ, и показывает, как метрики можно использовать для адекватного обоснования инвестиций в управление ИБ.

Целевой аудиторией Руководства являются менеджеры по ИТ и профессиональные работники в сфере безопасности всех уровней.

Структура программы метрик безопасности ИТ в организации пред­ставлена на рисунке 13.

Рис. 13. Структура программы метрик безопасности ИТ

Программа метрик безопасности ИТ в организации состоит из че­тырех взаимосвязанных частей:

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

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

третий компонент программы — разработка и внедрение коли­чественных метрик, которые спроектированы для сбора и предостав­ления значащей информации об эффективности безопасности систем ИТ организации. Чтобы количественные метрики безопасности могли обеспечивать значащую информацию, они должны строиться на осно­ве целей и задач эффективного обеспечения безопасности ИТ, вместе с этим они должны легко формироваться и должны позволять прове­сти измерение. Метрики также должны быть повторяемыми, показы­вать соответствующие тренды эффективности на заданном временном интервале и быть полезными для слежения за эффективностью и для управления ресурсами;

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

Метрики являются средствами, которые упрощают принятие реше­ний и в то же время позволяют улучшить качество работы и отчет­ность организации. Такой эффект достигается посредством сбора и анализа необходимых данных о качестве работы и подготовкой соот­ветствующих отчетов. Основу метрик составляют цели и задачи эф­фективного обеспечения безопасности ИТ. Цели эффективного обес­печения безопасности ИТ задают необходимые результаты, которые ожидаются от выполнения программы информационной безопаснос­ти в организации. Реализацию целей помогают осуществлять задачи эффективного обеспечения безопасности ИТ. Задачи определяют прак­тики (согласно положениям политик и процедур безопасности), при помощи которых предполагается реализовать защитные меры во всей организации. Мониторинг процесса выполнения задач и достижения целей осуществляется при помощи метрик безопасности ИТ. При вы­полнении мониторинга измеряются уровень реализации, результатив­ность и эффективность защитных мер, проводится анализ адекватнос­ти деятельности по обеспечению безопасности и определяются возможные действия по улучшению.

При разработке и выполнении программы по реализации метрик безопасности ИТ необходимо соблюдать следующие условия:

метрики должны давать результат в количественно измеримой фор­ме (в процентах, в усредненных и абсолютных значениях). Например: «процент систем, для которых имеется план работы в чрезвычайной ситуации», «процент уникальных идентификаторов пользователей», «процент систем, в которых применяются запрещенные к использова­нию протоколы», «процент систем, для которых существуют докумен­тированные отчеты об оценке рисков» и т.п.;

данные для поддержки метрик должны быть легкодоступными; измерению подлежат только повторяемые процессы; метрики должны быть полезны для отслеживания эффективности защитных мер и распоряжения ресурсами.

Данный документ представляет примеры метрик, основывающихся на критических элементах управления безопасностью и методах, со­держащихся в NIST 800-26. Представленные примеры метрик могут использоваться либо непосредственно без изменений, либо могут быть скорректированы или дополнены согласно существующим целям и задачам эффективного обеспечения безопасности ИТ в организации.

Документ определяет три типа метрик безопасности ИТ:

1) метрики реализации — для измерения реализации принятых политик, стандартов и процедур ИБ в организации;

2) метрики эффективности/результативности — для измерения результатов, которые зависят от предоставляемых сервисов бе­зопасности;

3) метрики влияний — для измерения влияния событий, связан­ных с безопасностью, на бизнес или миссию организации.

Типы метрик, которые реально можно получить и которые могут оказаться полезными для повышения эффективности, зависят от зре­лости программы безопасности организации и от зрелости реализа­ции системных средств управления безопасностью.

Разные типы метрик могут использоваться одновременно, однако исходная направленность метрик меняется по мере развития зрелос­ти реализации средств управления безопасностью (т. е. происходит постепенный переход от использования метрик первого типа к исполь­зованию метрик третьего типа).

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

Процесс разработки метрик представлен на рисунке 14.

Процесс разработки метрик безопасности ИТ состоит из двух ос­новных деятельностей:

идентификация и определение действующей программы безопас­ности ИТ (элементы 1-4 на рис. б);

разработка и выбор конкретных метрик для измерения реализа­ции, результативности, эффективности и влияния на бизнес организа­ции средств управления безопасностью (элементы 5-7 на рис. 13, которые соответствуют трем указанным выше типам метрик).

	Влияние на бизнес:
	— прирост или
	потеря стоимости
	бизнеса (business
	value);
	— оценка допустимых
	потерь

Работоспособность/ эффективность:

— своевременность предоставления сервиса безопасности;

— результаты работы, полученные вследствие реализации программы безопасности

Реализация процесса: — уровень реализации установленных стандартов, политик и процедур безопас­ности

Рис. 14. Процесс разработки метрик безопасности ИТ

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

Вторая деятельность в процессе разработки метрик (элементы 5- 7 на рисунке 14) предполагает разработку метрик для измерения процесса реализации стандартов, политик и процедур обеспечения безопасности систем ИТ организации, их эффективности и результа­тивности и влияния на миссию организации. Конкретный аспект бе­зопасности ИТ, на котором сосредоточены метрики в заданный мо­мент времени, зависит от уровня эффективности безопасности, как определено в руководстве ЩБТ БР 800-26 (т.е. от уровня зрелости программы ИБ организации). Метрики могут быть разработаны на ос­нове примеров метрик безопасности ИТ из приложения А данного до­кумента (или использованы непосредственно без доработки).

Подробная форма метрик

Руководство предлагает формировать метрики в виде, представлен­ном в таблице 1.

Таблица 1 Цель эффективности Формулируются желаемые результаты, которые должна обеспечить реализация одной или нескольких целей безопасности или методов и средств управления безопасностью системы, которые измеряются метрикой. При использовании N151 БР 800-26 в данный элемент описания метрики следует внести критический (контролируемый) элемент, заданный в N151 БР 800-26 Задача эффективности Формулируются действия, которые следует выполнить для достижения цели эффективности. При использовании N151 БР 800-26 в данном элементе должен быть представлен один или несколько дополнительных вопросов, определенных для критичного (контролируемого) элемента в N151 БР 800-26. Для одной цели эффективности могут существовать несколько задач эффективности

Метрика	Задается количественная мера, обеспечиваемая метрикой. Используется численное выражение, которое начинается словами «процентное отношение», «число», «частота», «среднее значение» или другие аналогичные термины
Назначение	Описывается общая функциональность, для осуществления которой проводится сбор метрик. Описывается, будет ли метрика использоваться для измерения качества работы внутри организации или для отчетности во внешние контролирующие органы. Также здесь описываются: понимание каких вопросов планируется получить, используя метрики; причины сбора конкретных метрик (регулятивные и законодательные требования), если таковые существуют, и другие аналогичные аспекты
Свидетельство реализации	Перечисляются доказательства существования средств управления безопасностью, которые подтверждают правильность их реализации. Свидетельство реализации используется для вычисления метрики. Свидетельство выступает в качестве косвенного показателя, который подтверждает выполнение деятельности, и в качестве причинных факторов, которые могут указывать на причины неудовлетворительных результатов для конкретной метрики
частота	Задаются периоды времени для сбора данных, который осуществляется для измерения происходящих изменений. Периоды времени задаются на основе вероятных ожидаемых обновлений, которые могут возникнуть при реализации средств управления
Формула	Описывается способ расчета численного значения метрики. В качестве входных данных для формулы используется информация из перечисленных свидетельств реализации
Источник данных	Перечисляется местонахождение данных, используемых для расчета метрики. Указываются базы данных, средства слежения, подразделения или конкретные роли в организации, которые могут предоставить необходимую информацию

Пример метрик безопасности ИТ, представленных в приложении А N151 800-55

Окончание табл. 1

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

В таблице 2 представлен пример метрик безопасности ИТ, содер­жащихся в приложении А ЬПБТ 800-55.

Таблица 2 Критический элемент 1.1. Оцениваются ли периодически риски? Дополнительный (вспомогательный) вопрос 1.1.2. Выполняются ли оценки рисков на регулярной основе или всякий раз, когда изменяются системы, средства или другие условия? Метрика Процентное отношение систем, для которых выполнены и задокументированы оценки рисков Назначение Оценивать количество оценок рисков, выполняемых в соответствии с требованиями организации Свидетельство реализации 1. Проводит ли ваша организация текущую опись систем ИТ? ДА НЕТ 2. Если ДА, то сколько систем в вашей организации (или организационном компоненте, если применимо)?

Свидетельство реализации	3. Из систем в вашей текущей описи, для скольких систем выполнены и задокументированы оценки рисков в следующие временные интервалы? (выбирайте для каждой системы; не учитывайте одну и ту же систему более чем в одном временном интервале) За прошедшие 12 месяцев. За прошедшие 2 года. За прошедшие 3 года 4. Для систем, которые подвергались оценке рисков, внесите количество систем согласно причине (причинам) оценки. Плановая оиенка рисков Значительное изменение в системной среде Значительное изменение в средствах (возможностях)________. Изменение в других условиях (спеиифииир^йте) 5. Для систем, которые не подвергались оценке рисков за последние 3 года, перечислите количество систем согласно причинам. Нет политики. Нет ресурсов Уровень системы не требует Система ранее не определялась Новая система Другое (специфицируйте)
Частота	Раз в полгода, ежегодно
Формула	На уровне организации: сумма оценок рисков за каждый временной интервал (вопрос 3)/количество систем ИТ в описи (вопрос 2)
Источник данных	Опись систем ИТ, которая включает все главные приложения и системы общей поддержки; хранилище оценок рисков
Индикаторы	Данная метрика вычисляет процентное отношение систем, по которым проводились оценки рисков за последние три года (что составляет обычно требуемый максимальный временной интервал для проведения оценок рисков). Для установления количества оценок рисков вычисляется количество систем, оцененных за каждый временной интервал. Сумма за три года должна равняться 100% всех требуемых систем. Системы, которые не подвергаются регулярным оценкам рисков, вероятно, подвергаются угрозам. Вопрос 4 используется для подтверждения правильности причин для проведения оценок рисков и обеспечения того,

Окончание табл. 2

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

Процесс реализации программы метрик безопасности ИТ, опреде­ленный в данном документе, иллюстрируется на рисунке 15.

Фаза 1 «Подготовка к сбору данных» включает функции, ко­торые являются основой для создания и реализации программы метрик безопасности ИТ, в том числе определение, разработку и выбор метрик и разработку плана реализации программы метрик. В фазе 1 определяются шаги по сбору, анализу метрик и составле­нию по ним отчета. Данные шаги следует документировать в плане реализации программы метрик. В план могут включаться следую­щие вопросы:

— роли и обязанности метрик, в том числе обязанности по сбору данных, анализу и отчету;

Индикаторы

— аудитория для плана;

Рис. 15. Процесс реализации программы метрик безопасности ИТ

— процесс сбора, анализа и отчета о метриках, адаптированный к организационной структуре, процессам, политикам и про­цедурам;

— создание, выбор и модификации инструментальных средств сбо­ра и контроля данных;

— форматы итоговых отчетов о метриках.

Фаза 2 «Сбор данных и анализ результатов» включает следую­щие функции:

— сбор данных метрик в соответствии с процессами, определяе­мыми в плане реализации программы метрик;

— объединение собираемых данных и сохранение в формате, спо­собствующем анализу данных и отчета о данных, например в базе данных, в электронных таблицах;

— проведение анализа недостатков — сравнение собираемых из­мерений с задачами и идентификация пробелов между факти­ческим и желаемым функционированием;

— идентификация причин плохого функционирования;

— идентификация областей, требующих улучшения (усовершен­ствования).

Фаза 3 «Идентификация корректирующих действий» включает следующие действия:

— определение диапазона корректирующих действий. Корректи­рующие действия могут включать: изменение конфигураций системы; обучение штатных сотрудников, системных админист­раторов или обычных пользователей; поставку инструменталь­ных средств безопасности; изменение системной архитектуры; учреждение новых процессов и процедур и модернизацию по­литик безопасности;

— присвоение приоритета корректирующим действиям. При­меняемым корректирующим действиям следует присваивать приоритет для каждого вопроса функциональности. Если ве­совые коэффициенты назначались метрикам в фазе подготов­ки к сбору данных, такие весовые коэффициенты следует ис­пользовать для присвоения приоритета корректирующим действиям. И наоборот, весовые коэффициенты могут назна­чаться корректирующим действиям в фазе идентификации этих действий, основанных на критичности реализации спе­цифичных корректирующих действий, стоимости корректиру­ющих действий и величины воздействия корректирующих дей­ствий на состояние безопасности организации;

— выбор наиболее соответствующих корректирующих действий. Корректирующие действия следует выбирать по критерию «зат­раты-выгоды».

Фаза 4 «Разработка бизнес-портфеля» и фаза 5 «Получение ресурсов» обеспечивают финансирование цикла, необходимого для реализации корректирующих действий.

Фаза 6 «Применение корректирующих действий» включает ре­ализацию корректирующих действий в технических, административ­ных и операционных областях средств управления безопасностью. После применения корректирующих действий цикл завершается и повторно запускается с помощью последующего сбора и анализа дан­ных. Сбор итеративных данных, анализ и отчет будут отслеживать раз­витие корректирующих действий, измерять улучшение и идентифици­ровать области для дальнейшего усовершенствования.

Документ NIST SP 800-55 является необходимым дополнением к документу NIST SP 800-26 «Руководство по самооценке безопасности для систем ИТ», которое применяется федеральными учреждениями США при планировании собственных годовых бюджетов, в частности затрат на обеспечение ИБ (рис. 16).

В совокупности три данных руководства NIST определяют после­довательность действий федеральных агентств, в результате которых формируются входные данные для составления документа «План дей­ствий и основные этапы» (Plan of Actions & Milestones — POA&M). Вместе с этим определяется приоритетность полученных результатов, на основании которой обеспечивается уверенность в том, что наибо­лее важные потребности безопасности федерального агентства будут удовлетворены в первую очередь.

После этого формируются «подтверждающие документы», кото­рые включают в себя выстроенные в контексте приоритетов кор­ректирующие действия, и представляются через бюджетную заяв­ку в Административное и бюджетное управление США (Office of Management and Budget, 0MB) с целью обеспечения финансирова­ния агентства. Они могут представлять собой либо самостоятельные заявки на инвестирование, либо могут являться составной частью инвестиционного плана ИТ, которая касается расходов на обеспече­ние безопасности.

гтсмл Рис. 16. Федеральное законодательство, регулирование и руководство в сфере безопасности ИТ (N1^ БР 800-26) и планирования капитала (США). Источник: ШТ БР 800-65

3.1.3. Отечественные законы и стандарты

по основам аудита

Следует констатировать, что на момент написания настоящей книги в Российской Федерации не определена правовая база аудита в сфе­ре информационной безопасности. Нет ни одного нормативно-пра­вового акта, который бы не только регулировал отношения в дан­ной сфере, но хотя бы определял базовые понятия в области аудита информационной безопасности, как это сделано для аудита финан­совой отчетности. В то же время в связи с объективно склады­вающимися потребностями и, как следствие, с широким распростра­нением аудита информационной безопасности за рубежом и исполь­зованием аудита информационной безопасности в практической де­ятельности международных аудиторских компаний на территории Российской Федерации подобное положение нельзя признать нор­мальным.

Формируемое национальное законодательство в поддержку вступ­ления и деятельности России в рамках Всемирной торговой организа­ции, включающее в том числе основополагающий Федеральный закон «О техническом регулировании», также не определяет понятия «аудит информационной безопасности». Это можно объяснить тем обстоятель­ством, что информационная безопасность не включена ни в одну из сфер безопасности, которые должны регулироваться обязательными к исполнению требованиями, включаемыми в технические регламенты, имеющие статус федеральных законов (ст. 7). Среди возможных ви­дов оценки соответствия, определяемых Федеральным законом «О тех­ническом регулировании», также не «нашлось места» деятельности и соответственно понятию «аудит безопасности». Так само понятие «оценка соответствия» определено в ст. 2 как «прямое или косвен­ное определение соблюдения требований, предъявляемых к объекту», и далее в п. 3 ст. 7 говорится, что «оценка соответствия проводится в формах государственного контроля (надзора), аккредитации, испыта­ния, регистрации, подтверждения соответствия, приемки и ввода в эксплуатацию объекта, строительство которого закончено, и в иной форме».

Что касается ограничения, связанного с отсутствием в Законе «О техническом регулировании» понятия «информационная безопас­ность», то для смягчения разногласий с данным основополагающим

Законом можно воспользоваться термином «безопасность организа­ции в информационной сфере» и соответственно перейти к термину «аудит безопасности в информационной сфере». Однако его приме­нение в этом случае ограничивалось бы тем обстоятельством, что сфера применения Закона «О техническом регулировании» распространяет­ся лишь на продукцию (входящую в Общероссийский классификатор продукции) и процессы ее производства, эксплуатации, хранения, пе­ремещения, реализации, утилизации. На практике это означает, что для конкретной организации можно было бы говорить лишь об «аудите безопасности информационной (автоматизированной) системы орга­низации в информационной сфере».

С точки зрения применения термина «аудит информационной бе­зопасности» возможны также следующие варианты придания ему ле­гитимности.

Первый из них связан с тем, что в Российской Федерации плани­руется принятие национального стандарта, гармонизированного с меж­дународным стандартом 1Б0/1ЕС 27001 [24], в котором, как и в меж­дународном, существовало бы указание о том, что для проведения внутренних аудитов систем менеджмента информационной безопас­ности (СМИ Б) может быть полезен ГОСТ Р И СО 19011 [33]. В этом слу­чае, однако, сфера применения данного термина на практике свелась бы к использованию его при проведении только внутренних аудитов СМИБ.

Вторым возможным вариантом является внесение изменений в федеральные законы «0 Центральном банке Российской Федерации (Банке России)» и «0 банках и банковской деятельности» в части введения и определения понятия и соответствующей деятельности, составляющей «аудит информационной безопасности». Данный тер­мин должен быть в этом случае определен в указанном выше смысле с учетом необходимости покрытия всей сферы необходимой деятель­ности, уже сложившейся реально. Основным содержанием изменений могли бы стать нормы относительно сферы применения аудита, его назначения, порядка его проведения и правовых последствий для организаций.

Содержательной основой таких изменений могли бы стать нормы Федерального закона от 07.08.2001 № 119-ФЗ «Об аудиторской дея­тельности», который определяет правовые основы регулирования ауди­торской деятельности в Российской Федерации. При этом под ауди­торской деятельностью, аудитом подразумевается предприниматель­ская деятельность по независимой проверке бухгалтерского учета и финансовой (бухгалтерской) отчетности организаций и индивидуаль­ных предпринимателей. Закон устанавливает цель аудита и позицио­нирует его место по отношению к государственному контролю досто­верности финансовой (бухгалтерской) отчетности, а также в системе российского законодательства. Кроме этого, Закон устанавливает тре­бования к аудиторам и аудиторским организациям, их права и обя­занности, права и обязанности аудируемых лиц.

Статья 7 Закона уста