16772

Разработка Профиля Защиты для средства контентного анализа банковской системы

Дипломная

Банковское дело и рынок ценных бумаг

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

Русский

2014-12-13

1.26 MB

15 чел.

РЕФЕРАТ

Пояснительная записка  - 136 с., 3 ч., 8 рис., 36 табл., 34 источников.

АВТОМАТИЗИРОВАННЫЕ БАНКОВСКИЕ СИСТЕМЫ, АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ, ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ, ОЦЕНКА ЗАЩИЩЕННОСТИ, НЕПРЕРЫВНОСТЬ ПРОЦЕССА, МЕТОДЫ ОБЕСПЕЧЕНИЯ ДОВЕРИЯ, МЕЖДУНАРОДНЫЕ СТАНДАРТЫ.

Объектом исследования является автоматизированная банковская система.

Цель работы – Повышение защищенности автоматизированной банковской системы.

Задачи:

1 Анализ угроз ИБ организаций БС РФ;

2 Выбор метода повышения доверия к системе безопасности;

3 Разработка Профиля Защиты для средства контентного анализа.

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

В результате анализа был выбран один метод повышения доверия к системе информационной безопасности. На основе этого метода был разработан Профиль Защиты для средства контентного анализа.

СОДЕРЖАНИЕ

ВВЕДЕНИЕ……………………………………………………………………….............................

6

ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ……………………………………………………………………

7

ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ ……………………………………………………………...

12

1. АВТОМАТИЗИРОВАННЫЕ БАНКОВСКИЕ СИСТЕМЫ……………………………… …..

13

1.1 Требования к современным АБС………………………………………………………………

14

1.1.1 Функциональная полнота………………………………………. …... ………………….......

14

1.1.2 Обеспечение единого информационного пространства……...............................................  

14

1.1.3 Масштабируемость системы…………………………………………………………….......

15

1.1.4 Настраиваемость системы……………………………………………………………...........

15

1.1.5 Централизованное управление системой …………………………………………… .........

15

1.1.6 Единая база данных…………………………………………………………………………..

15

1.1.7 Работа в режиме реального времени……………………………………………………......

16

1.1.8 Защищенность,  безопасность и надежность работы………………………………………

16

1.1.9 Специальные требования………………………………………………................................

18

1.1.10 Поддержка единой учетной политики…………………………………………………….

18

1.2  Структура программного обеспечения АБС…………………………………………………

19

1.3 Архитектура АБС……………………………………………………. ………………………..

20

1.4 Функции АБС ……………………………………………………....... ……………………......

20

1.5 Цели внедрения АБС...................................................................................................................

22

1.6 Цели применения современных АБС………………………………. …………………..........

23

1.7 Потенциальные возможности увеличения прибыли ……………………...............................

23

1.8 Российский опыт по обеспечению информационной безопасности АБС………………......

24

1.9 Международный опыт по обеспечению информационной безопасности АБС………….…

25

Выводы по первому разделу………………………………………………………………………..

27

2 Повышение уровня информационной безопасности ИТ…………………………………….....

29

2.1 Модель угроз ИБ организаций БС РФ…………………………………………………………

29

2.2 Модель нарушителя………………………………………………………………………….....

34

2.2.1 Модель внутреннего нарушителя……………………………………………………………

37

2.2.2 Модель внешнего нарушителя……………………………………....…………………........

45

2.3 Основные уязвимости АБС…………………………………………… …................................

52

2.3.1 Информационные атаки………………………………………………………………….......

55

2.3.2 Последствия информационных атак…………………………………………………….......

56

2.3.3 Существующие методы и средства защиты от информационных атак...............................

57

2.4 Основные правила защиты АБС………………………………………………………….........

60

2.5 Повышение уровня доверия и минимизации рисков…………………………………………

70

2.5.1 Первый способ повышения уровня доверия………………………………………………...

70

2.5.2 Методы обеспечения доверия и сфера применения……………………………..................

71

2.5.3 Второй способ повышения уровня доверия…………………………………………………

75

2.5.4 Аудит информационной безопасности……………………………………………………....

76

Выводы по второму разделу………………………………………………………………………..

83

3 Разработка Профиля Защиты для средства контентного анализа……………………………..

84

3.1 Введение…………………………………………………………………………………………

84

3.1.1 Идентификация ПЗ……………………………………………………………………………

84

3.1.2 Аннотация ПЗ………………………………………………………………………………….

84

3.1.3 Соглашения……………………………………………………………………………………

84

3.1.4 Термины и определения………………………………………………………………………

86

3.2 Описание объекта оценки………………………………………………………………………

86

3.3 Среда безопасности ОО………………………………………………………………………...

87

3.3.1 Предположения безопасности………………………………………………………………..

87

3.3.2 Предотвращаемые угрозы…………………………………………………………………….

87

3.3.2.1 Угрозы, предотвращаемые ОО……………………………………………………………..

87

3.3.2.2 Угрозы, предотвращаемые средой…………………………………………………………

88

3.3.3 Политика безопасности……………………………………………………………………….

89

3.4 Цели безопасности………………………………………………………………………………

90

3.4.1 Цели безопасности для ОО…………………………………………………………………...

90

3.4.2 Цели безопасности для среды………………………………………………………………..

91

3.5 Требования безопасности………………………………………………………………………

91

3.5.1 Функциональные требования………………………………………………………………...

91

3.5.1.1 Защита данных пользователя (FDP)……………………………………………………….

92

3.5.1.2 Идентификация и аутентификация (FIA)………………………………………………….

101

3.5.1.3 Защита ФБО (FPT)…………………………………………………………………………..

104

3.5.1.4 Управление безопасностью (FMT)………………………………………………………...

107

3.5.1.5 Аудит (FAU)…………………………………………………………………………………

108

3.5.1.6 Приватность (FPR)…………………………………………………………………………..

112

3.5.2 Требования доверия к безопасности………………………………………………………....

113

3.5.2.1 Управление конфигурацией (ACM)……………………………………………………......

114

3.5.2.2 Поставка и эксплуатация (ADO)…………………………………………………………...

115

3.5.2.3 Разработка (ADV)…………………………………………………………………………...

116

3.5.2.4 Документация(AGD)………………………………………………………………………..

119

3.5.2.5 Поддержка жизненного цикла (ALC)……………………………………………………..

121

3.5.2.6 Тестирование (ATE)………………………………………………………………………..

122

3.5.2.7 Оценка уязвимостей (AVA)………………………………………………………………...

124

3.6 Обоснование…………………………………………………………………………………….

126

3.6.1 Обоснование целей безопасности…………………………………………………................

126

3.6.1.1 Обоснование целей безопасности для ОО………………………………………………...

126

3.6.1.2 Обоснование целей безопасности для среды……………………………………………...

127

3.6.2 Обоснование требований безопасности……………………………………………………..

127

3.6.2.1 Обоснование функциональных требований……………………………………………….

127

3.6.2.2 Обоснование требований доверия…………………………………………………………

131

ЗАКЛЮЧЕНИЕ ……………………………………………………………………………………..

133

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ……………………………………………….

134

ВВЕДЕНИЕ

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

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

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

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

Многие потребители ИТ из-за недостатка знаний компетентности или ресурсов, не будучи уверены в безопасности применяемых продуктов и систем ИТ, возможно, не хотят полагаться исключительно на заверение разработчиков. Чтобы повысить свою уверенность в мерах безопасности продукта или системы ИТ, потребители могут заказать проведение анализа безопасности этого продукта или системы (то есть оценку безопасности).  [1]

ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

В пояснительной записке применены следующие термины и сокращения с соответствующими определениями:

Банковская система Российской Федерации – Банк России и кредитные организации, а также филиалы и представительства иностранных банков. [2]

Стандарт – Документ, в котором в целях добровольного многократного использования устанавливаются характеристики продукции, правила осуществления и характеристики процессов производства, эксплуатации, хранения, перевозки, реализации и утилизации, выполнения работ или оказания услуг. Стандарт также может содержать требования к терминологии, символике, упаковке, маркировке или этикеткам и правилам их нанесения. [2]

Рекомендации в области стандартизации – Документ, содержащий советы организационно-методического характера, которые касаются проведения работ по стандартизации и способствуют применению основополагающего стандарта. [2]

Комплекс БР ИББС – Взаимоувязанная совокупность документов в области стандартизации Банка России “Обеспечение информационной безопасности организаций банковской системы Российской Федерации”. [2]

Менеджмент – Скоординированная деятельность по руководству и управлению. [2]

Система – Множество (совокупность) материальных объектов (элементов) любой, в том числе различной физической, природы и информационных объектов, взаимодействующих между собой для достижения общей цели, обладающее системным свойством (свойствами) [2].

Системным свойством (свойствами) – является свойство, которое не имеет ни один из элементов и ни одно из подмножеств элементов при любом способе членения. Системное свойство не выводимо непосредственно из свойств элементов и частей. [2]

Информация – Сведения (сообщения, данные) независимо от формы их представления. [2]

Материальный носитель – изделие (материал), на котором записана информация и которое обеспечивает возможность сохранения этой информации и снятие ее копий, например, бумага, магнитная лента или карта, магнитный или лазерный диск, фотопленка и т.п. [2]

Процесс – Совокупность взаимосвязанных ресурсов и деятельности, преобразующая входы в выходы. [2]

Технология – Совокупность взаимосвязанных методов, способов, приемов предметной деятельности. [2]

Технологический процесс – Процесс, реализующий некоторую технологию. [2]  

Автоматизированная система – Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. [3]

Авторизация – Предоставление прав доступа. [2]

Идентификация – Процесс присвоения идентификатора (уникального имени); сравнение предъявляемого идентификатора с перечнем присвоенных идентификаторов. [2]

Аутентификация – Проверка принадлежности субъекту доступа предъявленного им идентификатора (подтверждение подлинности). [2]

Регистрация – Фиксация данных о совершенных действиях (событиях). [2]

Роль – Заранее определенная совокупность правил, устанавливающих допустимое взаимодействие между субъектом и объектом. [2]

Субъект – лицо из числа руководителей организации банковской системы Российской Федерации, ее персонала, клиентов или инициируемые от их имени процессы по выполнению действий над объектами. [2]

Объект – аппаратное средство, программное средство, программно-аппаратное средство, информационный ресурс, услуга, процесс, система, над которыми выполняются действия. [2]

Угроза – Опасность, предполагающая возможность потерь (ущерба). [2]

Риск – Мера, учитывающая вероятность реализации угрозы и величину потерь (ущерба) от реализации этой угрозы. [2]

Актив – Все, что имеет ценность для организации банковской системы Российской Федерации и находится в ее распоряжении. [2]

Актив организации банковской системы Российской Федерации – работники (персонал), финансовые (денежные) средства, средства вычислительной техники, телекоммуникационные средства и пр.; [2]

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

Ресурс – Актив организации банковской системы Российской Федерации, который используется или потребляется в процессе выполнения некоторой деятельности. [2]

Автоматизированная банковская система – Автоматизированная система, реализующая технологию выполнения функций организации банковской системы Российской Федерации. [2]

Безопасность – Состояние защищенности интересов (целей) организации банковской системы Российской Федерации в условиях угроз. [2]

Информационная безопасность; ИБ – Безопасность, связанная с угрозами в информационной сфере. [2]

Система информационной безопасности; СИБ – Совокупность защитных мер, защитных средств и процессов их эксплуатации, включая ресурсное и административное (организационное) обеспечение. [2]

Угроза информационной безопасности; угроза ИБ – Угроза нарушения свойств ИБ — доступности, целостности или конфиденциальности информационных активов организации банковской системы Российской Федерации. [2]

Уязвимость информационной безопасности; уязвимость ИБ – Слабое место в инфраструктуре организации банковской системы Российской Федерации, включая СОИБ, которое может быть использовано для реализации или способствовать реализации угрозы ИБ. [2]

Ущерб – Утрата активов, повреждение (утрата свойств) активов и (или) инфраструктуры организации или другой вред активам и (или) инфраструктуре организации банковской системы Российской Федерации, наступивший в результате реализации угроз ИБ через уязвимости ИБ. [2]

Инцидент информационной безопасности; инцидент ИБ – Событие, указывающее на свершившуюся, предпринимаемую или вероятную реализацию угрозы ИБ. [2]

Реализация угрозы ИБ — реализация нарушения свойств ИБ информационных активов организации банковской системы Российской Федерации. [2]

Нарушение может вызываться источниками угроз ИБ – либо случайными факторами (ошибкой персонала, неправильным функционированием технических средств, природными факторами, например, пожаром или наводнением), либо преднамеренными действиями, приводящими к нарушению доступности, целостности или конфиденциальности информационных активов. [2]

Нарушитель информационной безопасности; нарушитель ИБ – Субъект, реализующий угрозы ИБ организации банковской системы Российской Федерации, нарушая предоставленные ему полномочия по доступу к активам организации банковской системы Российской Федерации или по распоряжению ими. [2]

Модель нарушителя информационной безопасности; модель нарушителя ИБ – Описание и классификация нарушителей ИБ, включая описание их опыта, знаний, доступных ресурсов, необходимых для реализации угрозы, возможной мотивации их действий, а также способы реализации угроз ИБ со стороны указанных нарушителей. [2]

Модель угроз информационной безопасности; модель угроз ИБ – Описание источников угроз ИБ; методов реализации угроз ИБ; объектов, пригодных для реализации угроз ИБ; уязвимостей, используемых источниками угроз ИБ; типов возможных потерь (например, нарушение доступности, целостности или конфиденциальности информационных активов); масштабов потенциального ущерба. [2]

Риск нарушения информационной безопасности; риск нарушения ИБ: Риск, связанный с угрозой ИБ. [2]

Оценка риска нарушения информационной безопасности: Систематический и документированный процесс выявления, сбора, использования и анализа информации, позволяющей провести оценивание рисков нарушения ИБ, связанных с использованием информационных активов организации банковской системы Российской Федерации на всех стадиях их жизненного цикла. [2]

Обработка риска нарушения информационной безопасности – Процесс выбора и осуществления, защитных мер, снижающих риск нарушения ИБ, или мер по переносу, принятию или уходу от риска. [2]

Остаточный риск нарушения информационной безопасности – Риск, остающийся после обработки риска нарушения ИБ. [2]

Допустимый риск нарушения информационной безопасности: Риск нарушения ИБ, предполагаемый ущерб от которого организация банковской системы Российской Федерации в данное время и в данной ситуации готова принять. [2]

Документация – Совокупность взаимосвязанных документов, объединенных общей целевой направленностью. [2]

План работ по обеспечению информационной безопасности – Документ, устанавливающий перечень намеченных к выполнению работ или мероприятий по обеспечению ИБ организации банковской системы Российской Федерации, их последовательность, объем (в той или иной форме), сроки выполнения, ответственных лиц и конкретных исполнителей. [2]

Свидетельства выполнения деятельности по обеспечению информационной безопасности – Документ  или элемент документа, содержащий достигнутые результаты (промежуточные или окончательные), относящиеся к обеспечению ИБ организации банковской системы Российской Федерации. [2]

Политика информационной безопасности; политика ИБ – Документация, определяющая высокоуровневые цели, содержание и основные направления деятельности по обеспечению ИБ, предназначенная для организации банковской системы Российской Федерации в целом. [2]

Частная политика информационной безопасности; частная политика ИБ – Документация,  детализирующая положения политики ИБ применительно к одной или нескольким областям ИБ, видам и технологиям деятельности организации банковской системы Российской Федерации. [2]

Мониторинг – Постоянное наблюдение за объектами и субъектами, влияющими на ИБ организации банковской системы Российской Федерации, а также сбор, анализ и обобщение результатов наблюдений. [2]

Аудит информационной безопасности; аудит ИБ – Систематический, независимый и документируемый процесс получения свидетельств деятельности организации банковской системы Российской Федерации по обеспечению ИБ, установления степени выполнения в организации банковской системы Российской Федерации критериев ИБ, а также допускающий возможность формирования профессионального аудиторского суждения о состоянии ИБ организации банковской системы Российской Федерации. [2]

Критерии оценки (аудита) информационной безопасности; критерии оценки (аудита) ИБ – Совокупность требований в области ИБ, определенных стандартом Банка России СТО БР ИББС_1.0 “Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Общие положения” или его частью. [2]

Свидетельства оценки соответствия (аудита) информационной безопасности установленным критериям; свидетельства оценки соответствия (аудита) ИБ – Записи, изложение фактов или другая информация, которые имеют отношение к критериям оценки соответствия (самооценки соответствия, аудита) ИБ и могут быть проверены. [2]

Выводы аудита информационной безопасности; выводы аудита ИБ – Результат  оценки собранных свидетельств аудита ИБ. [2]

Заключение по результатам аудита информационной безопасности (аудиторское заключение); заключение по результатам аудита ИБ – Качественная или количественная оценка соответствия установленным критериям аудита ИБ, представленная аудиторской группой после рассмотрения всех выводов аудита ИБ в соответствии с целями аудита ИБ. [2]

Область аудита информационной безопасности; область аудита ИБ – Содержание и границы аудита ИБ. [2]

Программа аудита информационной безопасности; программа аудита ИБ – План деятельности по проведению одного или нескольких аудитов ИБ (и других проверок ИБ), запланированных на конкретный период времени и направленных на достижение конкретной цели. [2]

ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

АБС – автоматизированная банковская система;

БС – банковская система;

БИ – безопасность информации

ЖЦ – жизненный цикл;

ИС – информационная система;

ИБ – информационная безопасность;

ИСПДн – информационная система персональных данных;

НСД – несанкционированный доступ;

НРД – нерегламентированные действия в рамках предоставленных полномочий;

РФ – Российская Федерация;

СКЗИ – средство криптографической защиты информации;

СМИБ – система  менеджмента информационной безопасности;

СИБ – система информационной безопасности;

ЭВМ – электронная вычислительная машина;

ЭЦП – электронная цифровая подпись.

1 АВТОМАТИЗИРОВАННЫЕ БАНКОВСКИЕ СИСТЕМЫ

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

  •  комплексный подход в охвате широкого спектра банковских функций с их полной интеграцией;
  •  модульный принцип построения, позволяющий легко конфигурировать системы под конкретный заказ с последующим наращиванием;
  •  открытость технологий, способных взаимодействовать с различными внешними системами (системы телекоммуникации, финансового анализа и др.), обеспечивать выбор программно-технической платформы и переносимость ее на другие аппаратные средства;
  •  гибкость настройки модулей банковской системы и адаптация их к потребностям и условиям конкретного банка;
  •  масштабируемость, предусматривающая расширение и усложнение функциональных модулей системы по мере развития бизнес-процессов (например, поддержка работы филиалов и отделений банка, углубление анализа и т.д.);
  •  многопользовательский доступ к данным в реальном времени и реализация функций в едином информационном пространстве;
  •  моделирование банка и его бизнес-процессов, возможность алгоритмических настроек бизнес-процессов;
  •  непрерывное развитие и совершенствование системы на основе ее реинжиниринга бизнес-процессов. [4]

Создание или выбор АБС связаны с планированием всей системной инфраструктуры информационной технологии банка. Под инфраструктурой АБС понимается совокупность, соотношение и содержательное наполнение отдельных составляющих процесса автоматизации банковских технологий. В инфраструктуре кроме концептуальных подходов выделяются обеспечивающие и функциональные подсистемы. К обеспечивающим подсистемам относят: информационное обеспечение, техническое оснащение, системы связи и коммуникации, программные средства, системы безопасности, защиты и надежности и др. Функциональные подсистемы реализуют банковские услуги, бизнес-процессы и любые комплексы задач, отражающие содержательную или предметную направленность банковской деятельности. Создание автоматизированных банковских технологий помимо общесистемных (системотехнических) принципов требует учета особенностей структуры, специфики и объемов банковской деятельности. Это относится к организационному взаимодействию всех подразделений банка, которое вызывает необходимость создания многоуровневых и многозвенных систем (головной банк, его отделы, филиалы, обменные пункты, внешние структуры), со сложными информационными связями прямого и обратного направления. [4]

1.1 Требования к современным АБС

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

Прежде всего, АБС является инструментом управления банком. Основные требования, предъявляемые к современным АБС можно разделить на три части:

  •  требования к АБС как программному средству – системотехнические требования;
  •  специальные требования, отражающие специфику банковской деятельности, банковских операций и технологий их выполнения;
  •  показатели качества, характеризующие процесс разработки АБС. [5]

1.1.1 Функциональная полнота

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

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

    

1.1.2 Обеспечение единого информационного пространства

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

1.1.3 Масштабируемость системы

Масштабируемость системы – это способность системы адаптироваться к расширению предъявляемых требований и возрастанию объемов решаемых задач: числа обслуживаемых автоматизированных рабочих мест, количества обрабатываемых документов, а также быстроты реакции, общей производительности и пр., при добавлении к ней вычислительных ресурсов. [5]

1.1.4 Настраиваемость системы

Настраиваемость системыэто ее мобильность, динамичность, подвижность. Настраиваемость предполагает, что те или иные значимые параметры не жестко заданы, а могут быть адаптированы к потребностям и условиям конкретного банка. [5] 

1.1.5 Централизованное управление системой.

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

1.1.6 Единая база данных

Единая база данных, обеспечивающая многопользовательскую работу. Рекомендуется использование распределенных баз данных на основе промышленных СУБД (MS SQL Server, Oracle, Informix, DB2). В этих СУБД встроены и являются неотъемлемой частью:

  •  транзакционный механизм;
  •  средства разграничения доступа;
  •  средства поддержания ссылочной целостности и непротиворечивости данных.

Использование распределенных баз данных позволяет обеспечить необходимый уровень безопасности данных, программистам банка дает возможность сосредоточиться на оптимизации содержательной части приложений. [5]

1.1.7 Работа в режиме реального времени

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

1.1.8 Защищенность,  безопасность и надежность работы.

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

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

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

Обеспечение безопасности в автоматизированных системах требует комплексного подхода, при этом должны рассматриваться все составляющие таких систем. [5]

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

  •  конфиденциальность — защита от несанкционированного получения информации;
  •  целостность   — защита от несанкционированного изменения информации;
  •  доступность    — защита от несанкционированного удержания информации и ресурсов.

Удовлетворяющая этим критериям АБС включает в себя определенный набор функций защиты (сервис безопасности):

  •  идентификация и аутентификация;
  •  управление доступом;
  •  подотчетность;
  •  аудит;
  •  повторное использование объектов;
  •  точность информации;
  •  надежность обслуживания;
  •  обмен данными. [5]

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

  1.  Идентификация и аутентификация обеспечивают проверку подлинности текущих пользователей, регистрацию новых и удаление покинувших систему пользователей, проверку аутентификационной информации, контроль целостности и проверку соблюдения ограничений на число повторных попыток аутентификации.
  2.  Средства управления доступом ограничивают доступ к базе данных путем распределения прав доступа пользователей и контроля получения информации косвенным путем.
  3.  Очевидны и функции подотчетности действий пользователей в информационной системе, и функция аудита — контроля на основе проверки правомерности и корректности совершаемых действий. Проведение служебного расследования без этих функций просто невозможно.
  4.  Точность информации — необходимое требование к любой информационной системе. Специальные функции системы должны поддерживать согласованность ее различных частей, точность связей между процессами и неизменяемость данных при передаче.
  5.  Надежность обслуживания означает, что пользователи должны получать информацию в срок, и именно ту, которую запрашивали, а в системе всегда должны быть доступны ресурсы, необходимые для своевременного выполнения требуемых процедур.
  6.  Обмен данными предполагает, что функции системы должны обеспечивать безопасность при взаимодействии с внешней информационной средой по каналам связи. Это предъявляет свои требования к обеспечению аутентификации, управлению доступом, соблюдению конфиденциальности и целостности данных, а также невозвратности совершенных действий. [5]

Единого подхода к автоматизации банков не может быть. Мелкие, средние и крупные банки ставят перед собой разные задачи, также рознятся их подходы к автоматизации. Для мелких банков (до 100 человек) работающих на грани выживаемости, главная задача автоматизации будет сводиться к тому, чтобы обеспечить бесперебойное функционирование и надежное сопровождение комплексной АБС (мультивалютный операционный день, кредиты, депозиты, отчетность). Целью становится стремление удержаться на уровне современных компьютерных технологий. [5]

Для средних банков (100-1000 человек) главная задача автоматизации заключается в том, чтобы навести порядок в «разросшемся» хозяйстве — и здесь они делают ставку на внедрение интегрированной АБС, покрывающей все сферы деятельности банка и обеспечивающей единую сквозную технологию работы. [5]

Для крупных банков (свыше 1000 человек) главная задача автоматизации состоит в создании единой корпоративной среды, объединяющей данные многочисленных филиалов, отделений и дочерних структур. [5]

1.1.9 Специальные требования

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

1.1.10 Поддержка единой учетной политики

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

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

Показателем поддержки единой учетной политики является степень централизации функций управления, где для каждой пары смежных уровней степень централизации  — это отношение объема задач управления, решаемых на  уровне М, к объему задач управления, решаемых на  уровне М. [5]

1.2  Структура программного обеспечения АБС

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

 

Рисунок 1 – Архитектура банковских приложений

Верхний уровень (Front-office) образуют модули, обеспечивающие быстрый и удобный ввод информации, ее первичную обработку и любое внешнее взаимодействие банка с клиентами, другими банками, ЦБ, информационными и торговыми агентствами и т.д.

Средний уровень (Back-office) представляет собой приложения по разным направлениям внутрибанковской деятельности и внутренним расчетам (работу с кредитами, депозитами, ценными бумагами, пластиковыми карточками и т.д.).

Нижний уровень (Accounting) это базовые функции бухгалтерского учета, или бухгалтерское ядро. Именно здесь сосредоточены модули, обеспечивающие ведение бухгалтерского учета по всем пяти главам нового плана счетов. Разделение банка на Front-office и Back-office основывается не столько на функциональной специфике обработки банковских операций (сделок) и принятия решений (обобщения и анализа), сколько на самой природе банка как системы, с одной стороны, фиксирующей, а с другой - активно влияющей на экономическое взаимодействие в финансово-кредитной сфере.

В самостоятельную группу – Analysis – выделены операции реализующие анализ текущего состояния банка, планирование и внутренний аудит банка. [5]

1.3 Архитектура АБС

На сегодняшний день выделяют пять поколений АБС:  первые были предназначены для решения задач автоматизации бухгалтерских операций, АБС второго и третьего поколений дополнительно реализовывали элементы автоматизированного документооборота. АБС четвертого поколения строились по классической схеме трехзвенной клиент-серверной архитектуры и имели модульную структуру, реализующую концепции docflow. АБС пятого поколения являются информационными системы реализующими полнофункциональную модель workflow - автоматизации бизнес – процессов. [5]  

 

Рисунок 2 – Схема функциональных бизнес – потоков типовой АБС четвертого поколения

1.4 Функции АБС

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

Каждая фирма – разработчик АБС самостоятельно решает проблему выделения модулей, но и здесь можно проследить некоторые закономерности. Анализ проектных решений ряда АБС показал, что эти модули группируются примерно в одинаковые комплексы. Типовой состав этих комплексов показан на рисунке 3. [5]

Рисунок 3 - Типовой состав комплекса АБС

Функции, решаемых АБС, можно разделить на три большие группы:

  •  учетные функции,
  •  аналитические функции,
  •  технологические функции.

Функции автоматизированных банковских систем (АБС):

  •  операционный день;
  •  операции на фондовом рынке, работа банка с ценными бумагами;
  •  внутрихозяйственная деятельность;
  •  розничные банковские услуги;
  •  дистанционное банковское обслуживание;
  •  электронные банковские услуги;
  •  расчетный центр и платежная система (карточные продукты);
  •  интеграция Back – офиса банка с его внешними операциями;
  •  управление деятельностью банка, реализация бизнес – логики, контроль, учет, в том числе налоговый, и отчетность;
  •  управление рисками и стратегическое планирование;
  •  программы лояльности клиентов, маркетинговая, рекламная и PR-службы. [5]

1.5 Цели внедрения АБС

Внедрение АБС имеет целью повысить уровень автоматизации операционной деятельности и создать единое информационное пространство банка.

Это позволяет:

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

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

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

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

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

"Современная интегрированная АБС может помочь банку выстроить эффективные бизнес-процессы, уменьшить расходы и риски, связанные с операциями на рынке и обслуживанием клиентов. Кроме того, система помогает объективно оценивать риски, анализировать и управлять ими. Таким образом, современная АБС не только может позволить банку контролировать риски в соответствии с требованиями регулирующих органов, но и способна дать ощутимые преимущества перед конкурентами" (EGAR Technology Inc. ).

1.6 Цели применения современных АБС

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

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

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

1.7 Потенциальные возможности увеличения прибыли

Средствами повышения экономической эффективности автоматизации банковской деятельности являются:

  •  Активное их использование в бизнес-процессах, способствующих быстрому увеличению прибыли банка.
  •  Снижение себестоимости услуг за счет оптимизации бизнес – процессов банка и внедрения стратегий управления отношениями с клиентами.
  •  Увеличение объемов бизнеса за счет значительного ускорения обслуживания каждого конкретного клиента.
  •  Сокращение расходов за счет значительного снижения общего числа рутинных операций, выполняемых сотрудниками банка.
  •  Оптимизация управления финансовыми и информационными потоками банка. [5]

1.8 Российский опыт по обеспечению информационной безопасности

автоматизированных банковских систем

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

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

В настоящий момент приняты и введены в действие распоряжением Банка России следующие стандарты (совокупность указанных документов принято называть Комплексом БР ИББС):

  •  СТО БР ИББС-1.0-2010. Общие положения (4 редакция);
  •  СТО БР ИББС-1.1-2007. Аудит информационной безопасности;
  •  СТО БР ИББС-1.2-2010. Методика оценки соответствия информационной безопасности организаций банковской системы Российской Федерации требованиям СТО БР ИББС-1.0-20хх (3 редакция).

Кроме того, Банком России разработаны и введены следующие рекомендации в области стандартизации:

  •  РС БР ИББС-2.0-2007. Методические рекомендации по документации в области обеспечения информационной безопасности в соответствие с требованиями СТО БР ИББС-1.0;
  •  РС БР ИББС-2.1-2007. Руководство по самооценке соответствия информационной безопасности организаций банковской системы Российской Федерации требованиям СТО БР ИББС-1.0;
  •  РС БР ИББС-2.2-2009. Методика оценки рисков нарушения информационной безопасности;
  •  РС БР ИББС-2.3-2010. Требования по обеспечению безопасности персональных данных в информационных системах персональных данных организаций банковской системы Российской Федерации;
  •  РС БР ИББС-2.4-2010. Отраслевая частная модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных организаций банковской системы Российской Федерации.

Одной из целей функционирования АБС является обработка персональных данных сотрудников и клиентов банка. В таком случае, АБС классифицируется как информационная система персональных данных (ИСПДн) и должна быть защищена в соответствии с требованиями Федерального закона 152-ФЗ «О персональных данных».

В случае принятия в кредитной организации Стандарта Банка России СТО БР ИББС, АБС, реализующие банковские платежные процессы, не рассматриваются как ИСПДн.

1.9 Международный опыт по обеспечению информационной безопасности

автоматизированных банковских систем

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

  •  PCI DSS. Обязательный стандарт для операторов данных платежных карт систем VISA, MasterCard, American Express, JCB, Discover. Во-первых, в стандарте регламентируется необходимость шифрования носителей информации, содержащих данные платежных карт, и надежной защиты ключей шифрования. Также в PCI DSS определена необходимость генерации стойкого ключа и разделение криптографического ключа между несколькими лицами. Во-вторых, согласно стандарту операторы платежных карт должны защищать информацию от утечек по различным каналам, жестко регламентировав использование внешних устройств и перемещение конфиденциальных данных. В-третьих, в PCI DSS определена необходимость использования двухфакторной аутентификации для доступа к данным.
  •  Basel II. Довольно давно и успешно применяющийся в Евросоюзе, Северной Америке и Японии нормативный акт, регламентирующий банковскую деятельность. В частности в стандарте описана необходимость ведения архива конфиденциальной информации и создания системы управления операционными рисками.
  •  SOX. Sarbanes-Oxley Act of 2002 является обязательным для всех публичных компаний, акции которых котируются на фондовых биржах США. За несоблюдение закона топ-менеджеры компании несут персональную финансовую (штраф до 25 млн долларов) и уголовную ответственность (до 20 лет лишения свободы). Секция 404 закона регламентирует необходимость внедрения системы внутреннего контроля для предотвращения и защиты информационных активов компании от утечек и несанкционированного использования.
  •  SEC Rule 17a-4 и NASD 3010/3110. Своды правил для компаний, акции которых котируются на биржах США. В правилах регламентируется создание архива электронной корреспонденции и переписки через службы мгновенных сообщений. Требования NASD 3010/3110 еще более жесткие — требуется архивировать не только корреспонденцию участников системы, но и все транзакции брокеров, трейдеров и лиц, действующих от их имени.
  •  Combined code on corporate governance. Кодекс корпоративного управления Великобритании пока не является обязательным для всех организаций, однако уже давно де-факто является стандартом для корпораций, чьи акции представлены на Лондонской фондовой бирже. Combined code регламентирует создание и поддержку системы внутреннего контроля и необходимость как минимум один раз в год проводить независимый аудит такой системы. Также в Кодексе говорится о необходимости постоянного мониторинга самой системы внутреннего контроля, а в случае возникновения какого-либо инцидента ИБ, высшее руководство компании должно быть немедленно информировано.
  •  HIPAA. Американский закон HIPAA затрагивает учреждения здравоохранения, страховые компании и посредников, хранящих, обрабатывающих и передающих конфиденциальные данные. Закон конкретизируют правила HIPAA, The Security Rule, в которых в частности регламентируется необходимость создания системы внутреннего контроля, написания правил использования рабочих компьютеров и внешних устройств и организации системы контроля доступа к информации.
  •  GBLA & FACTA. Защита непубличной информации клиентов финансовых корпораций регламентируется законами Gramm-Leach-Bliley Act of 1999 и Fair and Accurate Credit Transactions Act of 2003. Стандарт «Interagency Guidelines Establishing Information Security Standards» вносит дополнительные уточнения в приведенные законы и требует от финансовых институтов США защищать непубличные данные граждан в процессе хранения, использования, пересылки и утилизации от всех прогнозируемых рисков информационной безопасности, а также обеспечить надежный контроль доступа к этой информации.

О защите персональных данных в международном праве задумались уже довольно давно, а первым законом стала европейская Конвенция «Convention for the Protection of Individuals with regard to Automatic Processing of Personal Data» («О защите личности в связи с автоматической обработкой персональных данных»), принятая 28 января 1981 года. На текущий момент подавляющее большинство развитых стран уже внедрили соответствующие законы. Ниже приведены некоторые законы о персональных данных других стан:

  •  EU Data Protection Directive (Directive 95/46/EC), Евросоюз, 1995.
  •  EU Internet Privacy Law of 2002 (Directive 2002/58/EC) , Евросоюз, 2002.
  •  Data Protection Code of 2003, Италия, 2003.
  •  ORGANIC LAW on the Protection of Personal Data, Испания, 1999.
  •  Federal Data Protection Act of 2001, Германия, 2001.
  •  Data Protection Act, Великобритания, 1998.
  •  Personal Information Protection Law, Япония, 2003.
  •  Personal Information Protection and Electronic Data Act, Канада, 2000.
  •  Privacy Act of 1988, Австралия, 1988.

Выводы по первому разделу.

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

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

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

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

2 Повышение уровня информационной безопасности ИТ.

2.1 Модель угроз ИБ организаций БС РФ

В последнее время высокую актуальность приобретают проблемы надежности и устойчивости функционирования АБС и особенно проблема обеспечения безопасности циркулирующей в ней информации. Основными причинами нарушения ИБ, утраты, хищения или искажения данных, представляющих ценность для их владельца, являются воздействия в результате случайного или преднамеренного НСД нарушителя или воздействие на нее различного рода угроз. [8]

Модели угроз и нарушителей (прогноз ИБ) должны быть основным инструментом менеджмента организации при развертывании, поддержании и совершенствовании системы обеспечения ИБ организации.  [8]

Угрозы информационной безопасности для организаций БС РФ – это:

  1.  нарушение доступности информации и предоставляемых сервисов;
  2.   нарушение целостности информации (данных) и программного обеспечения, в том числе несанкционированное изменение состояние счета при совершении расчетных, учетных и кассовых операций;
  3.   нарушение конфиденциальности (неправомерное использование) информации, в том числе за счет хищения отчуждаемых машинных носителей с несанкционированно копированной информацией. Нарушение конфиденциальности информации за счет нарушения работы криптографических средств не рассматривается, так как неразрушающее воздействие на такие средства требует профессионального образования (специализированных знаний) в области криптографии, которых нарушитель информационно-телекоммуникационной системы организаций БС РФ, не имеет, что обеспечивается кадровой политикой Банковских систем;
  4.  нарушение регламентов технологических процессов совершения банковских операций.

Объектами защиты являются:

1 бизнес-процессы;

2 платежные и информационные технологические процессы;

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

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

Уровни информационной инфраструктуры, на которых возможна реализация угроз информационной безопасности в соответствии со стандартом Банка России [1] представлены в следующей иерархической последовательности:

1 физический (линии связи, аппаратные средства и пр.);

2 сетевой (сетевые аппаратные средства: маршрутизаторы, коммутаторы, концентраторы и пр.);

3 сетевые приложения и сервисы;

4 операционные системы;

5 системы управления базами данных, хранилищ данных и т.п.;

6 банковские технологические процессы и приложения;

7 бизнес-процессы.

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

1 неблагоприятные события природного и техногенного характера;

2 террористы, криминальные элементы;

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

4 поставщики программно-технических средств, расходных материалов, услуг и т.п.;

5 подрядчики, осуществляющие монтаж, пуско-наладочные работы оборудования и его ремонт;

6 сотрудники БС РФ, являющиеся легальными участниками процессов в ИТС и действующие вне рамок предоставленных полномочий;

7 сотрудники БС РФ, являющиеся легальными участниками процессов в ИТС и действующие в рамках предоставленных полномочий.

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

1 потенциальная подверженность района размещения объекта БС РФ воздействию природных и техногенных катаклизмов;

2 недостаточная отказоустойчивость и катастрофоустойчивость аппаратно-

программных и технических комплексов;

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

4 недостатки в организации охраны и технической укрепленности объектов Банка России;

5 восприимчивость программного обеспечения к вредоносным программным кодам (компьютерным вирусам и т.п.) и другим атакам;

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

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

8 некачественная (неполная) регламентация в договорах вопросов взаимодействия с поставщиками и подрядчиками (обязанности, ответственность);

9 ориентация на монопольных поставщиков и подрядчиков;

10 наличие уязвимостей (слабостей) в системе защиты информации;

11 несоответствие регламентов деятельности текущему состоянию объекта защиты и неконтролируемость исполнения сотрудниками БС РФ регламентов своей деятельности.

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

Таблица 1 – Модель  угроз [8]

Основные источники угроз

Угроза

Уровень

реализации

угрозы

Уязвимость

Основные последствия для Банка России и его клиентов и корреспондентов

1

2

3

4

5

6

1

Неблагоприятные события природного и техногенного характера

Нарушение

доступности,

целостности

Физический

уровень

Потенциальная

подверженность

района размещения объектов БС РФ воздействию природных и техногенных катаклизмов

Выход из строя информационно-

телекоммуникационной

системы, потеря управления, прекращение (отказ)

обслуживания, утеря

(уничтожение) данных вследствие физического

разрушения (порчи) носителей информации

Продолжение таблицы 1

Основные источники угроз

Угроза

Уровень

реализации

угрозы

Уязвимость

Основные последствия для Банка России и его клиентов и корреспондентов

1

2

3

4

5

6

2

террористы, криминальные элементы

Нарушение

доступности,

целостности,

конфиденциа-льности

Физический

уровень

Физические,

моральные, психологические

особенности сотрудников, их

незащищенность, создающие предпосылки террористического

или криминального воздействия

Выход из строя информационно-

телекоммуникационной

системы, потеря управления, прекращение (отказ)

обслуживания, утеря

(уничтожение) данных в

следствии физического

разрушения (порчи) носителей информации.

Нарушение

доступности,

целостности,

Недостатки в организации

охраны и технической укрепленности объектов БС РФ

Нарушение

доступности,

целостности,

конфиденци-

альности

Сетевой

уровень

Физические,

моральные, психологические

особенности сотрудников, их

незащищенность, создающие предпосылки террористического

или криминального воздействия

Реализация атак (нерегламентированное использование инструментов

позволяющих реализовать

атаки) на информационно-

телекоммуникационные

системы Банка России

приводящие к прекращению (отказу) обслуживания, модификации настроек сетевого оборудования,

неправомерному доступу к оборудованию (сегментам сети)

Нарушение

доступности,

целостности,

конфиденци-

альности

Уровень се-

тевых при-

ложений и

сервисов

Физические,

моральные, психологические

особенности сотрудников, их

незащищенность, создающие предпосылки террористического

или криминального воздействия

Реализация атак (нерегламентированное использование инструментов

позволяющих реализовать атаки) на информационно-

телекоммуникационные

системы Банка России

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

изменение (модификация)

сетевого трафика, перехват информации

Продолжение таблицы 1

Основные источники угроз

Угроза

Уровень

реализации

угрозы

Уязвимость

Основные последствия для Банка России и его клиентов и корреспондентов

1

2

3

4

5

6

Нарушение

доступности,

целостности,

конфиденци-

альности

Уровень

операцион-

ных систем

Физические,

моральные, психологические

особенности сотрудников, их

незащищенность, создающие предпосылки террористического

или криминального воздействия

Внедрение вредоносного

программного кода позволяющего захватить управление операционными

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

(групп хостов), изменение (модификация) программного окружения, перехват

конфиденциальной информации

Нарушение

доступности,

целостности,

конфиденци-

альности

Уровень

систем

управления

базами

данных

Физические,

моральные, психологические

особенности сотрудников, их

незащищенность, создающие предпосылки террористического

или криминального воздействия

Реализация атак (нерегламентированное использование инструментов

позволяющих реализовать

атаки), внедрение вредоносного программного

кода позволяющего захватить управление СУБД с целью прекращения (отказа) обслуживания, модификации информации

Нарушение

доступности,

целостности,

конфиденци-

альности

Уровень

банковских

технологи-

ческих

процессов и приложений

Физические,

моральные, психологические

особенности сотрудников, их

незащищенность, создающие предпосылки террористического

или криминального воздействия

Нарушение непрерывности и правильности функционирования бизнес- процессов.  Угроза деловой репутации

Нарушение

доступности,

целостности,

конфиденци-

альности

Уровень

бизнес-

процессов

Физические,

моральные, психологические

особенности сотрудников, их

незащищенность, создающие предпосылки террористического

или криминального воздействия

Нарушение непрерывности и правильности функционирования бизнес-процессов .Угроза деловой репутации

2.2 Модель нарушителя

Идея разработки модели нарушителя информационной безопасности родилась во второй половине 80-х годов прошлого века в Министерстве обороны США и получила путевку в жизнь в так называемой Оранжевой книге, а в начале 90-х годов плавно перекочевала в руководящие документы Гостехкомиссии России.

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

  •  категории лиц, в числе которых может оказаться нарушитель;
  •  возможные цели нарушителя и их градацию по степени важности;
  •  предположения о квалификации нарушителя;
  •  степень его технической вооруженности;
  •  ограничения и предположения о характере возможных действий нарушителя. [9]

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

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

Проиллюстрируем этот тезис на примере. Предположим, что в вашем банке создана автоматизированная информационная система, реализованная в рамках локальной вычислительной сети, которая расположена в контролируемом помещении. Система обрабатывает конфиденциальную информацию, требующую защиты. На ней работают сотрудники, которые прошли кадровую проверку и контроль за работой которых достаточно осуществлять силами либо руководителя, либо системного администратора. Доступ в помещение посторонним лицам ограничен. Ведется физическая охрана технических средств и носителей информации. В этом случае достаточно использовать аутентификацию пользователей и обычный доступ к информации по паролю. [9]

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

Какие же информационные ресурсы подлежат защите?

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

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

В-третьих, данные информационных, аналитических и иных неплатежных систем банка. Здесь следует разделить фактографические данные, хранящиеся в структурированном виде в различных базах данных, и документарные - имеющие бесструктурный характер.  [9]

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

В-пятых, аппаратно-программные и технические комплексы, обеспечивающие реализацию функций банка, здания и сооружения, где установлены указанные комплексы.
Следует отметить, что при разработке модели нарушителя информационной безопасности рассматриваются только электронные информационные ресурсы. Если включить в этот ресурс и иную конфиденциальную информацию (сведения, озвученные на совещаниях, заседаниях, переговорах; информацию на бумажных носителях; данные, полученные в ходе приватных встреч, и др.), то в таком случае и рассматриваться должна базовая модель потенциального нарушителя банка. Она формируется на основе модели нарушителя информационной безопасности путем включения в нее дополнительной категории сотрудников банка, работающих с конфиденциальной информацией (работники канцелярии, персонал, работающий с VIP-клиентами в формате "бутик-банкинг" и т.п.).
[9]

Особо хотелось бы отметить сотрудников, которые владеют интегрированными аналитическими сведениями, представляющими для банка стратегический характер. Это в первую очередь топ-менеджеры банка и приближенные к ним лица (секретари и обслуживающий персонал), по роду своей работы, допущенные к эксклюзивным процессам банка. В отношении этой категории сотрудников службой безопасности банка должны быть разработаны дополнительные профилактические организационные меры защиты, желательно согласованные не только с руководителем исполнительного органа банка, но и с советом директоров. [9]

Исходя из ценности электронных информационных ресурсов, можно определить и приоритеты безопасности:

  •  доступность информации и сервисов, предоставляемых информационной системой;
  •  целостность информации (данных) и программного обеспечения;
  •  конфиденциальность информации.

Под нарушением доступности подразумеваются:

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

Под нарушением целостности подразумеваются:

  •  несанкционированное искажение;
  •  уничтожение или ввод ложной информации.

Под нарушением конфиденциальности понимается инсайдерская деятельность, нарушение банковской тайны, несанкционированное чтение/копирование/публикация информации. [9]

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

  •  для открытой информации: целостность → доступность;
  •  Для внутренней банковской информации, предназначенной для использования исключительно сотрудниками банка: доступность → конфиденциальность → целостность.
  •  Для конфиденциальных сведений: конфиденциальность → целостность → доступность.

2.2.1 Модель внутреннего нарушителя

Обеспечение всего комплекса организационных мер и программно-технических средств по обеспечению информационной безопасности требует значительных финансовых и людских ресурсов. Вместе с тем новый Стандарт Банка России СТО БР ИББС-1.0-2010 подсказывает и определяет основное направление этой работы. Учитывая специфику накапливаемой и обрабатываемой в банках информации, основная потенциальная угроза исходит от сотрудников банка, то есть от инсайдера. Поэтому при разработке модели нарушителя необходимо учитывать, что по сложившейся уже практике существующая сложность современных банковских технологий приводит к их меньшей привлекательности для злоумышленника, чем персонал банка. [9]

Внутренние нарушители информационной безопасности в АБС - это сотрудники самого банка, являющиеся легальными участниками процессов управления банка, в том числе обеспечения расчетов его клиентов, а также персонал, обслуживающий банковские аппаратно-программные комплексы или допущенный к ним в соответствии со своими служебными обязанностями. Внутренние нарушители являются наиболее значимыми источниками угроз информационной безопасности. [9]

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

При подготовке модели нарушителя необходимо провести работу по определению грифа конфиденциальной информации. К строго конфиденциальной следует отнести финансовые документы, аналитические отчеты, документы о новых разработках и т.п., к конфиденциальной информации относятся документы, разглашение которых может привести к потерям в настоящее время, например аналитический отчет за месяц. В конце года он уже не будет так актуален для конкурентов, они будут охотиться за более новыми материалами. Эту работу не обязательно проводить силами своей службы безопасности. Можно привлечь специалистов со стороны, которые и проведут аудит безопасности. Конечно, необходимо придерживаться следующего правила: не привлекать к аудиту безопасности фирмы-производители средств защиты. Несложно догадаться, что они предложат для обеспечения защищенности вашей сети. [9]

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

Можно выделить следующие признаки классификации внутреннего нарушителя:

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

При отсутствии мотивации могут совершаться только непреднамеренные действия, ущерб от которых носит, как правило, разовый, несистемный характер. [9]

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

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

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

  •  руководящий и управленческий персонал банка:
  •  пользователи АБС, то есть сотрудники, допущенные к информационным ресурсам в соответствии со своими служебными обязанностями и являющиеся потребителями сервисов автоматизированных информационных систем. [9]

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

Третий уровень - уровень администратора - определяется возможностью управления функционированием АБС, то есть воздействием на базовое программное обеспечение системы, на состав и конфигурацию ее оборудования. К этой категории относятся: персонал, имеющий право доступа к оборудованию, в том числе сетевому; администраторы сетевых приложений и т.п., реализующие угрозы в рамках своих полномочий (легальный доступ) и за их пределами (несанкционированный доступ). [9]

Четвертый уровень - уровень системного программиста или разработчика АБС - определяется всем объемом возможностей лиц, осуществляющих проектирование, реализацию и ремонт технических средств АБС, вплоть до включения в состав автоматизированных систем собственных технических средств с новыми функциями по обработке информации. [9]

Главная цель, которую себе ставит внутренний нарушитель, - получение контроля над электронными информационными ресурсами банка, включая средства их обработки, хранения и предоставления, на самом высоком доступном для него уровне. Для первого уровня нарушителей такими ресурсами являются банковские бизнес-процессы, для остальных - банковские технологические процессы, базы данных и операционные системы. [9]

Естественно желание минимизировать число сотрудников, которые должны быть включены в модель нарушителя. Один из возможных путей - исключить из модели второй, третий и четвертый уровни нарушителей. Возможно это путем использования в банке на особо ответственных участках таких программных средств, которые не требуют участия программистов-разработчиков, а само создание и эксплуатацию базы данных осуществляют сотрудники первого уровня, то есть люди зачастую без базового технического образования. И ошибаются те, кто полагает, что это невозможно. Достаточно вспомнить, что подавляющее большинство "серых" нелегальных баз данных, продающихся на "черном" рынке информационных услуг, представлены в оболочке программных средств CRONOS PLUS, у которой настолько развит интуитивный интерфейс, что работать с ней может любой человек без соответствующего образования. А потратив на самообучение этих программных средств всего несколько часов, человек способен самостоятельно создавать собственные базы данных. Немудрено, что эти программные средства активно используются службами безопасности большого числа банков, так как ценность и важность обрабатываемых с их помощью данных исключают возможность допуска к ним штатных программистов. [9]

Но, к сожалению, это не может являться универсальным выходом, ведь далеко не на всех участках работы можно установить подобные программные средства, взять хотя бы автоматизированные системы по обработке платежной информации. Какой может быть предложен выход из этой ситуации? Универсального выхода нет, но можно дать некоторые рекомендации из практики, которые не устраняют в полном объеме опасность, но минимизируют риски нарушения информационной безопасности. Предлагаемый список далеко не полный, а законченность ему может придать только учет специфики обработки конфиденциальной информации в конкретном банке. Итак, это:

  •  определение, проведение и реализация политики и мер защиты безопасности;
  •  недопущение разработчиков программных средств к участку эксплуатации созданных ими баз данных и соответствующих приложений;
  •  блокировка всех устройств и разъемов соединения с внешними устройствами;
  •  мониторинг, аудит и тестирование АБС и оборудования для обнаружения проблем с обеспечением информационной безопасности и самих программно-аппаратных и технических средств защиты;
  •  обязательное разделение функций администраторов систем и администраторов информационной безопасности;
  •  строгая регламентация работы администраторов систем и работа на наиболее ответственных участках только группой - не менее двух человек одновременно;
  •  контроль за действиями сотрудников эксплуатации АБС с помощью визуальных средств наблюдения;
  •  дополнительная надбавка к жалованию администраторов всех уровней с целью минимизации мотивации неправомочных действий;
  •  ознакомление с новыми технологиями защиты и возможными угрозами информационной безопасности банка;
  •  дополнительные организационные меры контроля, хорошо известные сотрудникам служб безопасности коммерческих банков, и т.д. и т.п. [9]

Остановимся подробнее на первом уровне нарушителей, так как они составляют большую часть лиц, имеющих доступ к АБС, где обрабатывается конфиденциальная информация, тем более что соотношение IT-специалистов к остальным сотрудникам в среднем колеблется в банках от 1:30 до 1:50, поскольку они относятся к обеспечивающим подразделениям. [9]

Этим и определяются отличия потенциальных нарушителей первого и последующих уровней в области нарушения конфиденциальности. Программист слабо разбирается в бизнес-процессах, но прекрасно ориентируется в программных средствах. Такие нарушители будут стараться похитить максимально для них возможный массив конфиденциальной информации и продать его конкурентам целиком. Менеджеру банка в силу его профессиональных способностей и служебных обязанностей намного сложнее сделать то, на что способен программист. Но он прекрасно разбирается в экономических вопросах и способен провести эффективную селекцию доступной для него информации с целью вычленения из нее наиболее значимой для дальнейшего использования конкурентами. [9]

Для иллюстрации сказанного приведем следующий пример. Допустим, в банке в электронном виде хранится информация о его клиентах с характеризующими их финансовое состояние данными. Нарушителю - IT-специалисту сподручнее сконцентрировать свои усилия на том, чтобы постараться похитить весь массив данных и продать его конкурентам коммерческого банка, где он работает. Для этого ему потребуется внешнее устройство накопления большой емкости: флэш-память; внешнее устройство записи на CD- или DVD-диски и, разумеется, доступ к самой базе данных на расширенных правах с возможностью копировать информацию. Поэтому и усилия по защите от такого рода потенциального нарушителя должны быть нацелены в первую очередь на ограничение его доступа к информации. [9]

Легальный пользователь - экономист этой базы данных, скорее всего, опираясь на свои знания и опыт, с помощью запроса вычленит из общего массива наиболее притягательных с точки зрения их финансового состояния клиентов банка. Ему намного труднее скопировать весь массив данных, так как для пользователя, как правило, программными средствами накладываются ограничения на объем копируемой информации, а обойти это ограничение порой крайне затруднительно даже для "продвинутого пользователя". При этом у него нет нужды копировать весь массив, а достаточно визуально (с экрана) снять нужную ему информацию и попытаться сбыть ее конкурентам. К такого рода пользователям запретительные меры бесполезны, поскольку они и так являются авторизованными пользователями. В этом случае эффективны контроль и постоянный аудит действий этих сотрудников с последующим полным или выборочным отчетом о проделанной работе. И такую работу служба безопасности должна проводить совместно с руководством соответствующих структурных подразделений. [9]

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

Достаточно полезен аудит активности бюджетов пользователей, цель которого - обнаружить бездействующие, ошибочные или неправильно используемые бюджеты. Эти действия подразумевают, что бюджеты легальных пользователей должны регулярно проверяться на дату последнего доступа. Любой бюджет, к которому не обращались в течение N дней (например, 30, 60, 90), должен быть соответствующим образом помечен, и по нему нужно составить отчет. Неактивные бюджеты должны стать недоступными, и их следует заархивировать. [9]

Сами руководители тоже не могут выступать в роли "жены Цезаря". В отношении их должен вестись такой же полноценный аудит, как и по отношению к рядовым сотрудникам. Только отчет об их действиях докладывается непосредственно руководству банка. Ему целесообразно также докладывать и о действиях остальных сотрудников банка, если их действия являлись исполнением личных поручений их прямых руководителей. При этом, чтобы не попадать постоянно впросак, руководству службы безопасности желательно хотя бы в общих чертах разбираться в бизнес-процессах банка. [9]

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

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

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

  •  идентификация, проверка подлинности и контроль доступа пользователя к программам, файлам, записям и полям записей;
  •  регистрация и учет входа/выхода пользователя доступа в/из АБС (узла сети), а также выдачи печатных выходных документов и многие другие.  [9]

Полный перечень этих программно-аппаратных средств защиты можно найти в руководящих и нормативных документах Федеральной службы по техническому и экспортному контролю. [9]

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

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

Это могут быть личностные недостатки:

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

Это также могут быть семейные проблемы:

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

На таких лиц служба безопасности должна обращать особое внимание.

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

Сам список этих лиц является строго конфиденциальным. Неверно было бы и проведение с ними профилактических бесед, так как это может незаслуженно обидеть людей. Но в отношении этих лиц необходимо проводить дополнительные организационные меры и программные средства защиты. Что касается автоматизированных рабочих мест таких лиц, то службе безопасности целесообразно проводить так называемый активный аудит, а проще говоря, перлюстрацию информационных массивов, хранящихся на их персональных компьютерах, а также их электронной почты. Средства защиты позволяющие осуществлять активный аудит целесообразно устанавливать на все персональные компьютеры, где обрабатывается конфиденциальная информация. Разумеется, такой тотальный контроль всех работников банка крайне затруднителен для службы безопасности в силу ее ограниченных ресурсов, но выборочный мониторинг действий "проблемных лиц" вполне ей под силу. [9]

Подобные действия ни в коей мере не ущемляют права и свободы работников этого банка, не являются нарушением Федерального закона "О персональных данных" и являются распространенной практикой крупнейших российских и зарубежных компаний. Для снятия всех вопросов внутрикорпоративным документом возможно либо запретить на персональных компьютерах работников хранить и обрабатывать личные данные, либо предупредить их о возможном доступе к этим данным третьих лиц. [9]

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

На основе классификации для конкретной банковской автоматизированной информационной системы (в зависимости от ее особенностей - технологии, программно-аппаратная платформа и т.д.) разрабатывается конкретная модель внутреннего нарушителя. Эта модель наряду с другими параметрами автоматизированной системы (уязвимость, уровень конфиденциальности информации и т.д.) ложится в основу построения ПИБ данной банковской автоматизированной информационной системы. [9]

Разработка и внедрение ПИБ минимизируют операционные риски деятельности кредитной организации, которые в конечном итоге сказываются и на самих бизнес-процессах данной кредитной организации. [9]

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

По оценке экспертов, именно операционные риски сегодня являются серьезным препятствием на пути к созданию эффективной системы управления рисками. Между тем Соглашение Базель II (которое требует использовать управление, ориентированное на операционные риски) в отличие от Базеля I (которое требует использовать управление, ориентированное в первую очередь на рыночные и кредитные риски) предписывает учитывать этот вид угроз и резервировать под него капитал. Такое внимание к управлению рисками в целом и операционными рисками в частности продиктовано тем, что коммерческий банк, который будет в состоянии наиболее точно оценить свои операционные риски и продемонстрировать свою уверенность регулятору, сможет резервировать меньшие объемы капитала под эти риски. Это, в свою очередь, позволит данному банку существенно повысить свою конкурентоспособность относительно менее продвинутых коммерческих банков. [9]

Кроме того, хотя в состав операционных рисков не входят те, что связаны с репутацией, тем не менее реализация многих угроз может привести к отрицательным последствиям в виде ущерба имиджу и потери репутации. Например, если инсайдеры ограбят клиентов банка (самая опасная операционная угроза), то об этом наверняка станет известно широкой общественности. В результате репутация банка может пострадать, что приведет к сокращению клиентской базы и снижению прибыли. Таким образом, риски, связанные с репутацией, могут быть прямым следствием реализации операционных угроз. Опасаясь этого, банки зачастую не оповещают общественность о реализации операционных угроз, благо в настоящее время закон им это и не вменяет в обязанность. Например, если коммерческий банк выявит инсайдера, пытавшегося совершить мошенничество или продававшего приватные данные клиентов, он не станет обращаться в суд и постарается уладить дело без лишнего шума. В результате таких действий инсайдеры часто уходят от ответственности, однако и банки спасают, таким образом, свою репутацию. Тем не менее, развитие российской законодательной базы рано или поздно приведет к тому, что подобные инциденты станут полностью прозрачными как для правоохранительных органов, так и для прессы. [9]

2.2.2 Модель внешнего нарушителя

В общедоступных сетях распространены нападения хакеров. Это высококвалифицированные специалисты, которые направленным воздействием могут выводить из строя на длительное время серверы АБС (DoS-атака) или проникать в их системы безопасности. Практически все упомянутые угрозы способен реализовать хакер-одиночка или объединенная группа. Хакер может выступать как в роли внешнего источника угрозы, так и в роли внутреннего (сотрудник организации). [10]

Хакеры буквально творят произвол во всемирной Сети. Они воруют номера кредитных карточек. Получают доступ к закрытым базам и оперируют со счетами пользователей. Используют информационные и сетевые ресурсы для изощренных атак. Чаще всего доступ к Интернету они также получают за счет кого-то. Они занимаются рассылкой спама и внедрением вредоносных программ на различные компьютеры в сети. Они собирают и взламывают пароли от чужих машин и систем, чтобы получить к ним полный доступ: завладеть секретной информацией, скопировать ее, удалить или модифицировать. Хакеры перехватывают и перенаправляют сетевой трафик. Устраивают настоящую войну с крупными сайтами в сети Интернет. И чаще всего не ради наживы, а ради развлечения или самоутверждения. [10]

В результате хакерских атак может причиняться крупный ущерб, чаще всего они носят организованный характер и нередко среди соучастников могут быть представители собственного персонала. Кроме того, информационным атакам и вторжениям присуща высокая степень латентности (малый процент – меньше 10% выявления преступлений). [10]

Хакеры могут встраивать троянские программы, которые превращают пораженную машину в "компьютер-зомби", который совершает различные действия по указке хакера, выходя из-под контроля. Такие пораженные системы могут использоваться для дальнейшего развития атак на машины в сети и их заражения. [10]

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

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

Наиболее опасными и сильными хакерами могут стать представители военных ведомств и спецслужб различных государств. Эти ведомства обладают мощными компьютерами и высокопроизводительными пропускными каналами связи. Следует учесть, что в ведомствах могут работать недобросовестные сотрудники, которые заинтересованы в подрыве репутации или нанесении ущерба добросовестным банкам. [10]

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

Группу внешних нарушителей могут составлять:

  •  клиенты;
  •  приглашенные посетители;
  •  представители конкурирующих организаций;
  •  сотрудники органов ведомственного надзора и управления;
  •  нарушители пропускного режима;
  •  наблюдатели за пределами охраняемой территории. [10]

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

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

Используемые методы и средства:

  •  сбор информации и данных;
  •  пассивные средства перехвата;
  •  использование средств, входящих в информационную систему или систему ее защиты, и их недостатков;
  •  активное отслеживание модификаций существующих средств обработки информации, подключение новых средств, использование специализированных утилит, внедрение программных закладок и "черных ходов" в систему, подключение к каналам передачи данных. [10]

Уровень знаний нарушителя об организации информационной структуры:

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

Время информационного воздействия:

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

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

Начнем с самого простого варианта.

Это хакер-одиночка, обладающий стандартным персональным компьютером на базе PC, с выходом в Интернет. Данный тип злоумышленников очень сильно ограничен в финансовом плане. Он необязательно обладает глубокими знаниями в области компьютерных технологий, чаще всего использует готовые компьютерные программы, доступные из Интернета, для реализации угроз через давно известные уязвимости. Вряд ли такой тип нарушителя обладает достаточными знаниями о построении информационной системы банка. Его действия больше носят экспериментальный характер, он не стремится получить доступ к определенной информации или модифицировать ее с целью извлечения выгоды. Ему просто интересно провести некоторые действия с информационной системой банка, недоступными и неиспользуемыми простыми пользователями Интернета. Характер действия – скрытый, в меру своих способностей. Чаще всего останавливается после проведения первого успешного воздействия. [10]

Для борьбы с подобными "исследователями" администраторам безопасности необходимо четко выполнять правила, предписанные политикой безопасности организации. Устанавливать самые последние версии используемых программных продуктов и ОС, а также выпускаемые к ним патчи и расширения. Отслеживать публичные списки обнаруживаемых уязвимостей в аппаратных и программных продуктах известных производителей и совершать рекомендуемые действия для предотвращения реализации угроз с использованием обнаруженных уязвимостей. [10]

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

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

Для противостояния действиям подобных групп необходимо использовать последние достижения в области обеспечения информационной безопасности объекта. [10]

Следующий тип – предприятие-конкурент.

Данная модель включает в себя:

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

Возможны попытки подкупа сотрудников службы безопасности или иные действия из области социальной инженерии. Конкуренты могут предпринять серьезные усилия для получения сведений функционирования системы информационной защиты, в том числе внедрить своего представителя в службу безопасности. Среди целей могут быть: блокирование функционирования информационной системы конкурента, нанесение подрыва в имидже, деструктивные действия, направленные на причинение непоправимого ущерба конкуренту, вплоть до его разорения и банкротства. Для этого используются самые изощренные методы проникновения в информационные системы и воздействия на потоки данных в ней. Действия конкурентов могут носить как скрытый, так и открытый, демонстративный характер. При осуществлении своих намерений конкурирующая сторона бьется до победного конца. [10]

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

Самым серьезным соперником для службы безопасности банка являются коррумпированные представители различных структур ведомственного уровня, а также спецслужбы различных государств. Они обладают практически неограниченными вычислительными и финансовыми возможностями, самостоятельно регулируют и контролируют трафик в сети Интернет. На их службе состоят самые высокопрофессиональные компьютерные специалисты. В некоторых странах известны примеры, когда вместо тюремного заключения или после него известного хакера берут в службу национальной безопасности. Эти специалисты участвуют в разработке стандартов по безопасности информации, сетевых протоколов и досконально знают возможности и недостатки всех компьютерных технологий. В процессе сертификации вычислительной системы представители ведомственных органов могут получать достаточно полную информацию о ее построении. Цели, преследуемые такой группой, весьма разнообразны и их невозможно предугадать заранее. Подобные преступные элементы могут не утруждать себя сокрытием своих действий и, как уже говорилось, практически ничто неспособно их остановить. Они могут пользоваться поддержкой как законодательных, так и иных правовых актов, а также опекой органов исполнительной и судебной власти. [10]

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

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

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

Таблица 2 – Характеристики моделей типового злоумышленника. [10]

Характеристика

Хакер-одиночка

Группа-хакеров

Конкуренты

Сотрудники ведомств

Вычислительная мощность

Персональный компьютер

ЛВС, использование чужих вычислительных сетей

Мощные вычислительные сети

Неограниченные вычислительные мощности

Выход в интернет

Модем или выделенная линия

Использование чужих каналов с высокой пропускной способностью

Собственные каналы с высокой пропускной способностью

Самостоятельный контроль над маршрутизацией трафика в Интернете

Финансовые возможности

Сильно ограничены

Ограничены

Большие возможности

Практически не ограничены

Компьютерные знания

Не высокие

Высокие

Высокие

Высокие, разработчики стандартов

Используемые технологии

Готовые программы, известные уязвимости

Поиск новых уязвимостей, изготовление вредоносных программ

Современные методы проникновения в информационные системы и воздействие на потоки данных в ней

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

Знания о построении системы безопасности объекта

Вряд ли обладает достаточными знаниями о построении информационной системы банка

Могут предпринимать определенные усилия для получения представления о принципах функционировании системы защиты банков

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

В процессе сертификации вычислительной системы представители ведомственных органов могут получить достаточно полную информацию о ее построении

Преследуемые цели

Эксперимент, любопытство

Подделка счетов, внесение искажений в работу системы

Блокировка функционирования системы, подрыв имиджа, разорение

Непредсказуемый разнообразный характер

Характер действий

Скрытый в меру своих способностей

Предпринимает все возможные усилия для сокрытия факта несанкционированного доступа

Могут носить как скрытый, так и открытый, демонстративный характер

Могут не утруждать себя сокрытием своих действий

Продолжение Таблицы 2

Характеристика

Хакер-одиночка

Группа-хакеров

Конкуренты

Сотрудники ведомств

Глубина проникновения

Чаще всего останавливается после проведения первого успешного действия

До момента достижения поставленной цели или наступления непреодолимых препятствий для проведения дальнейшего вторжения

При осуществлении своих намерений конкурирующая сторона будет идти до победного конца

Практически ни чего их не может остановить

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

2.3 Основные уязвимости АБС

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

Практически любая АБС может выступать в качестве объекта информационной атаки, которая может быть определена как совокупность действий злоумышленника, направленная на нарушение одного из трёх свойств информации - конфиденциальности, целостности или доступности. Рассмотрим эти свойства более подробно. Свойство конфиденциальности позволяет не давать права на доступ к информации или не раскрывать ее неполномочным лицам, логическим объектам или процессам. Характерным примером нарушения конфиденциальности информации является кража из системы секретной информации с целью её дальнейшей перепродажи. Целостность информации подразумевает её способность не подвергаться изменению или уничтожению в результате несанкционированного доступа. В качестве примера нарушения этого свойства можно привести ситуацию, при которой злоумышленник преднамеренно искажает содержимое одного из электронных документов, хранящихся в системе. И, наконец, доступность информации определяется как её свойство быть доступной и используемой по запросу со стороны любого уполномоченного пользователя. Так, например, злоумышленник сможет нарушить доступность Интернет-портала если ни один из легальных пользователей не сможет получить доступ к его содержимому. Таким образом, в результате нарушения конфиденциальности, целостности или доступности информации злоумышленник тем самым может нарушить бизнес-процессы компании, которые базируются на информационных ресурсах, которые являлись объектом атаки. [6]

Для реализации информационной атаки нарушителю необходимо активизировать или, другими словами, использовать определённую уязвимость АБС. Под уязвимостью принято понимать слабое место АБС, на основе которого возможна успешная реализация атаки. Примерами уязвимостей АБС могут являться: некорректная конфигурация сетевых служб АБС, наличие ПО без установленных модулей обновления, использование нестойких к угадыванию паролей, отсутствие необходимых средств защиты информации и др. Логическая связь уязвимости, атаки и её возможных последствий показана на рис. 4. [6]

Рисунок 4 – Связь уязвимости, атаки и её возможных последствий

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

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

Уязвимости АБС могут быть внесены как на технологическом, так и на эксплуатационном этапах жизненного цикла АБС. На технологическом этапе нарушителями могут быть инженерно-технические работники, участвующие в процессе проектирования, разработки, установки и настройки программно-аппаратного обеспечения АБС. [6]

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

  •  наличие слабых, не стойких к угадыванию паролей доступа к ресурсам АБС. При активизации этой уязвимости нарушитель может получить несанкционированный доступ к АБС путём взлома пароля при помощи метода полного перебора или подбора по словарю;
  •  наличие в системе незаблокированных встроенных учётных записей пользователей, при помощи которых потенциальный нарушитель может собрать дополнительную информацию, необходимую для проведения атаки. Примерами таких учётных записей являются запись "Guest" в операционных системах или запись "Anonymous" в FTP-серверах;
  •  неправильным образом, установленные права доступа пользователей к информационным ресурсам АБС. В случае, если в результате ошибки администратора пользователи, работающие с системой, имеют больше прав доступа, чем это необходимо для выполнения их функциональных обязанностей, то это может привести к несанкционированному использованию дополнительных полномочий для проведения атак. Например, если пользователи будут иметь права доступа на чтение содержимого исходных текстов серверных сценариев, выполняемых на стороне Web-сервера, то этим может воспользоваться потенциальный нарушитель для изучения алгоритмов работы механизмов защиты Web-приложений и поиска в них уязвимых мест;
  •  наличие в АБС неиспользуемых, но потенциально опасных сетевых служб и программных компонентов. Так, например, большая часть сетевых серверных служб, таких как Web-серверы и серверы СУБД поставляются вместе с примерами программ, которые демонстрируют функциональные возможности этих продуктов. В некоторых случаях эти программы имеют высокий уровень привилегий в системе или содержат уязвимости, использование которых злоумышленником может привести к нарушению информационной безопасности системы. Примерами таких программ являются образцы CGI-модулей, которые поставляются вместе с Web-приложениями, а также примеры хранимых процедур в серверах СУБД;
  •  неправильная конфигурация средств защиты, приводящая к возможности проведения сетевых атак. Так, например, ошибки в настройке межсетевого экрана могут привести к тому, что злоумышленник сможет передавать через него пакеты данных. [6]

2.3.1 Информационные атаки

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

  •  Стадия рекогносцировки. На этом этапе нарушитель осуществляет сбор данных об объекте атаки, на основе которых планируются дальнейшие стадии атаки. Примерами такой информации являются: тип и версия операционной системы (ОС), установленной на узлах АБС, список пользователей, зарегистрированных в системе, сведения об используемом прикладном ПО и др. При этом в качестве объектов атак могут выступать рабочие станции пользователей, серверы, а также коммуникационное оборудование АБС;
  •  Стадия вторжения в АБС. На этом этапе нарушитель получает несанкционированный доступ к ресурсам тех узлов АБС, по отношению к которым совершается атака;
  •  Стадия атакующего воздействия на АБС. Данный этап направлен на достижение нарушителем тех целей, ради которых предпринималась атака. Примерами таких действий могут являться нарушение работоспособности АБС, кража конфиденциальной информации, хранимой в системе, удаление или модификация данных системы и др. При этом атакующий может также осуществлять действия, которые могут быть направлены на удаление следов его присутствия в АБС;
  •  Стадия дальнейшего развития атаки. На этом этапе выполняются действия, которые направлены на продолжение атаки на ресурсы других узлов АБС. [6]

Схематично стадии жизненного цикла информационной атаки изображены на рис. 5.


Рисунок 5 – Жизненный цикл типовой информационной атаки на ресурсы АБС

Информационные атаки могут быть классифицированы как внешние или внутренние. Внешние сетевые атаки проводятся извне АБС, т.е. с тех узлов, которые не входят в состав системы. Примером внешней сетевой атаки являются вторжение нарушителя в ЛВС из сети Интернет. Внутренние атаки проводятся изнутри АБС с одного из её серверов или рабочих станций. В качестве примера такой атаки можно привести действия сотрудника компании, направленные на утечку конфиденциальной информации. [6]

2.3.2 Последствия информационных атак

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

2.3.3 Существующие методы и средства защиты от информационных атак

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

На сегодняшний день можно выделить следующие основные виды технических средств защиты:

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

Средства криптографической защиты информации представляют собой средства вычислительной техники, осуществляющее криптографическое преобразование информации для обеспечения ее конфиденциальности и контроля целостности. Защита информации может осуществляться в процессе её передачи по каналам связи или в процессе хранения и обработки информации на узлах АБС. Для решения этих задач используются различные типы СКЗИ, описание которых приводится ниже. [6]

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

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

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

          Рисунок 6 – Процедура входа пользователя в автоматизированную систему

Межсетевые экраны (МЭ) реализуют методы контроля за информацией, поступающей в АБС и/или выходящей из АБС, и обеспечения защиты АБС посредством фильтрации информации на основе критериев, заданных администратором. Процедура фильтрации включает в себя анализ заголовков каждого пакета, проходящего через МЭ, и передачу его дальше по маршруту следования только в случае, если он удовлетворяет заданным правилам фильтрации. При помощи фильтрования МЭ позволяют обеспечить защиту от сетевых атак путём удаления из информационного потока тех пакетов данных, которые представляют потенциальную опасность для АБС. [6]

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

Средства антивирусной защиты предназначены для обнаружения и удаления вредоносного ПО, присутствующего в АБС. К таким вредоносным программам относятся компьютерные вирусы, а также ПО типа "троянский конь", "spyware" и "adware".

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

  •  нарушение работоспособности почтовой системы вследствие большого потока входящих сообщений. При этом может быть нарушена доступность как всего почтового сервера, так и отдельных почтовых ящиков вследствие их переполнения. В результате пользователи АБС не смогут отправлять или получать сообщения при помощи почтовой системы организации;
  •  реализация "phishing"-атак, в результате которых пользователю присылается почтовое сообщение от чужого имени с просьбой выполнить определённые действия. В таком сообщении пользователя могут попросить запустить определённую программу, ввести своё регистрационное имя и пароль или выполнить какие-либо другие действия, которые могу помочь злоумышленнику успешно провести атаку на информационные ресурсы АБС. Примером атаки этого типа является посылка пользователю сообщения от имени известного банка, в котором содержится запрос о необходимости смены пароля доступа к ресурсам Web-сайта банка. В случае если пользователь обратится по Интернет-адресу, указанному в таком почтовом сообщении, то он будет перенаправлен на ложный Web-сайт злоумышленника, представляющий собой копию реального сайта банка. В результате такой атаки вся парольная информация, введённая пользователем на ложном сайте, будет автоматически передана нарушителю;
  •  снижение производительности труда персонала вследствие необходимости ежедневного просмотра и ручного удаления спамовских сообщений из почтовых ящиков. [6]

Средства контентного анализа предназначены для мониторинга сетевого трафика с целью выявления нарушений политики безопасности. В настоящее время можно выделить два основных вида средств контентного анализа - системы аудита почтовых сообщений и системы мониторинга Интернет-трафика. Системы аудита почтовых сообщений предполагают сбор информации о SMTP-сообщениях, циркулирующих в АБС, и её последующий анализ с целью выявления несанкционированных почтовых сообщений, нарушающих требования безопасности, заданные администратором. Так, например, системы этого типа позволяют выявлять и блокировать возможные каналы утечки конфиденциальной информации через почтовую систему. Системы мониторинга Интернет – трафика предназначены для контроля доступа пользователей к ресурсам сети Интернет. Средства защиты данного типа позволяют заблокировать доступ пользователей к запрещённым Интернет-ресурсам, а также выявить попытку передачи конфиденциальной информации по протоколу HTTP. Системы мониторинга устанавливаются таким образом, чтобы через них проходил весь сетевой трафик, передаваемый в сеть Интернет. [6]

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

  •  модули-датчики, предназначенные для сбора необходимой информации о функционировании АБС. Иногда датчики также называют сенсорами;
  •  модуль выявления атак, выполняющий анализ данных, собранных датчиками, с целью обнаружения информационных атак;
  •  модуль реагирования на обнаруженные атаки;
  •  модуль хранения данных, в котором содержится вся конфигурационная информация, а также результаты работы средств обнаружения атак;
  •  модуль управления компонентами средств обнаружения атак. [6]

2.4 Основные правила защиты АБС

Банки играют огромную роль в экономической жизни общества, их часто называют кровеносной системой экономики. Благодаря своей специфической роли, со времени своего появления они всегда притягивали преступников. К 90-м годам XX века банки перешли к компьютерной обработке информации, что значительно повысило производительность труда, ускорило расчеты и привело к появлению новых услуг. Однако компьютерные системы, без которых в настоящее время не может обойтись ни один банк, являются также источником совершенно новых угроз, неизвестных ранее. Большинство из них обусловлены новыми информационными технологиями и не являются специфическими исключительно для банков. [7]

В условиях финансовых кризисов первоочередное внимание в работе банков уделяется вопросам, влияющим на повышение их конкурентоспособности, одним из важнейших аспектов этой проблемы является повышение уровня безопасности операций, выполняемых банком. При современных технологиях автоматизации увеличивается объем информации, обрабатываемой в электронном виде, что ведет к снижению общего уровня безопасности в работе банка. Решение этой проблемы во многом зависит от технологий, используемых конкретным банком, иными словами – от автоматизированной банковской системы. [7]

Компьютеризация банковской деятельности позволила значительно повысить производительность труда сотрудников банка, внедрить новые финансовые продукты и технологии. Однако прогресс в технике преступлений шел не менее быстрыми темпами, чем развитие банковских технологий. В настоящее время свыше 90% всех преступлений связано с использованием автоматизированных систем обработки информации банка. Следовательно, при создании и модернизации АБС необходимо уделять пристальное внимание обеспечению ее безопасности. [7]

Именно эта проблема является сейчас наиболее актуальной и наименее исследованной. Если в обеспечении физической и классической информационной безопасности давно уже выработаны устоявшиеся подходы (хотя развитие происходит и здесь), то в связи с частыми радикальными изменениями в компьютерных технологиях методы безопасности АБС требуют постоянного обновления. Как показывает практика, не существует сложных компьютерных систем, не содержащих ошибок. А поскольку идеология построения крупных АБС регулярно меняется, то исправления найденных ошибок и «дыр» в системах безопасности хватает ненадолго, так как новая компьютерная система приносит новые проблемы и новые ошибки, заставляет по-новому перестраивать систему безопасности. [7]

Во многие банковские системы заложена идеология и схема бизнес-процессов многофилиального банка, имеющего, в том числе, структурные подразделения в различных регионах. Возможность работы в режиме удаленного доступа предъявляет дополнительные требования к защитным механизмам. А высокая степень интегрированности информации в комбинации с уникальными возможностями адаптации системы к самым разным сетевым операционным системам делает проблему информационной безопасности банка чрезвычайно актуальной. [7]

Безопасность информации напрямую влияет на уровень рентабельности, ибо потери, связанные с ее нарушением, могут свести на нет все достижения эффективного управления. При этом, как правило, чем более совершенна система управления банком, тем опаснее утечки информации. [7]

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

Информационная безопасность банка должна учитывать следующие специфические факторы:

  •  Информация в банковских системах представляет собой «живые деньги», которые можно получить, передать, истратить, вложить и т.д. Вполне понятно, что незаконное манипулирование с такой информацией может привести к серьезным убыткам. Эта особенность резко расширяет круг преступников, покушающихся именно на банки (в отличие от, например, промышленных компаний, внутренняя информация которых мало кому интересна).
  •  Информация в банковских системах затрагивает интересы большого количества физических и юридических лиц – клиентов банка. Как правило, она конфиденциальна, и банк несет ответственность за обеспечение требуемой степени секретности перед своими клиентами. Естественно, клиенты вправе ожидать, что банк должен заботиться об их интересах, в противном случае он рискует своей репутацией со всеми вытекающими отсюда последствиями.
  •  Конкурентоспособность банка зависит от того, насколько клиенту удобно работать с банком, а также насколько широк спектр предоставляемых услуг, включая услуги, связанные с удаленным доступом. Поэтому клиент должен иметь возможность  быстро и без томительных процедур распоряжаться своими деньгами. Но такая легкость доступа к деньгам повышает вероятность преступного проникновения в банковские системы.
  •  Информационная безопасность банка (в отличие от большинства компаний) должна обеспечивать высокую надежность работы компьютерных систем даже в случае нештатных ситуаций, поскольку банк несет ответственность не только за свои средства, но и за деньги клиентов.
  •  Банк хранит важную информацию о своих клиентах, что расширяет круг потенциальных злоумышленников, заинтересованных в краже или порче такой информации. [7]

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

В США, странах Западной Европы и многих других, столкнувшихся с этой проблемой довольно давно, в настоящее время создана целая индустрия защиты экономической информации, включающая разработку и производство безопасного аппаратного и программного обеспечения, периферийных устройств, научные изыскания и др. [7]

Сфера информационной безопасности – наиболее динамичная область развития индустрии безопасности в целом. Если обеспечение физической безопасности имеет давнюю традицию и устоявшиеся подходы, то информационная безопасность постоянно требует новых решений, т.к. компьютерные и телекоммуникационные технологии постоянно обновляются, на компьютерные системы возлагается все большая ответственность. [7]

Под безопасностью АБС будем понимать ее свойство, выражающееся в способности противодействовать попыткам нанесения ущерба владельцам и пользователям системы при различных возмущающих (умышленных и неумышленных) воздействиях на нее. Иными словами под безопасностью системы понимается защищенность от случайного или преднамеренного вмешательства в нормальный процесс ее функционирования, а также от попыток хищения, модификации или разрушения ее компонентов. Следует отметить, что природа воздействия может быть самой различной. Это и попытки проникновения злоумышленника, и ошибки персонала, и стихийные бедствия (ураган, пожар), и выход из строя составных частей АБС. [7]

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

Конфиденциальность информации – это свойство информации быть известной только допущенным и прошедшим проверку (авторизованным) субъектам системы. (пользователям, программам, процессам и т.д.). Для остальных субъектов системы эта информация как бы не существует. [7]

Целостность компонента (ресурса) системы – свойство компонента (ресурса) быть неизменным (в семантическом смысле) при функционировании системы. [7]

Доступность компонента (ресурса) системы – свойство компонента (ресурса) быть доступным для использования авторизованными субъектами системы в любое время.

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

  1.  От чего надо защищать систему?
  2.  Что надо защищать в самой системе?
  3.  Как надо защищать систему (при помощи каких методов и средств)?

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

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

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

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

Обеспечение безопасности АБС в целом предполагает создание препятствия для любого несанкционированного вмешательства в процесс ее функционирования, а также попыток хищения, модификации, выведения из строя или разрушения ее компонентов. То есть защиту всех компонентов системы: оборудования, программного обеспечения, данных и персонала. В этом смысле защита информации от несанкционированного доступа является только частью общей проблемы обеспечения безопасности АБС, а борьбу следует вести не только с «несанкционированным доступом» (к информации), а шире – с «несанкционированными действиями». [7]

Выявление всего множества каналов несанкционированного доступа проводится в ходе проектирования путем анализа технологии хранения, передачи и обработки информации, определенного порядка проведения работ, разработанной системы защиты информации и выбранной модели нарушителя. [7]

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

Центральной в проблеме защиты информации от несанкционированного доступа является задача разграничения функциональных полномочий и доступа к информации, направленная на предотвращение не только возможности потенциального нарушителя «читать» хранящуюся в ПЭВМ информацию, но и возможности нарушителя модифицировать ее штатными и нештатными средствами. [7]

Требования по защите информации от несанкционированного доступа направлены на достижение (в определенном сочетании) трех основных свойств защищаемой информации:

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

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

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

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

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

Система регистрации и учета осуществляет:

  •  регистрацию входа (выхода) субъектов доступа в систему (из системы) либо регистрацию загрузки и инициализации операционной системы и ее программного останова (регистрация выхода из системы или останова не проводится в моменты аппаратного отключения АИТ), причем в параметрах регистрации указываются: время и дата входа (выхода) субъекта доступа в систему (из системы) или загрузки (останова) системы; результат попытки входа – успешный или неуспешный (при попытке несанкционированного доступа), идентификатор (код или фамилия) субъекта, предъявляемый при попытке доступа;
  •  регистрацию и учет выдачи печатных (графических) документов на твердую копию;
  •  регистрацию запуска (завершения) программ и процессов (заданий, задач), предназначенных для обработки защищаемых файлов;
  •  регистрацию попыток доступа программных средств (программ, процессов, задач, заданий) к защищаемым файлам;
  •  учет всех защищаемых носителей информации с помощью их любой маркировки (учет защищаемых носителей должен проводиться в журнале (картотеке) с регистрацией их выдачи / приема, должно проводиться несколько видов учета (дублирующих) защищаемых носителей информации). [7]

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

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

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

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

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

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

В методах защиты от вирусов существуют два направления:

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

  1.  Применение специальных программ-анализаторов, осуществляющих постоянный контроль возникновения отклонений в деятельности прикладных программ, периодическую проверку наличия других возможных следов вирусной активности (например, обнаружение нарушений целостности программного обеспечения), а также входной контроль новых программ перед их использованием (по характерным признакам наличия в их теле вирусных образований).
  2.  Защита от несанкционированного копирования и распространения программ и ценной компьютерной информации является самостоятельным видом защиты имущественных прав, ориентированных на проблему охраны интеллектуальной собственности, воплощенной в виде программ ПЭВМ и ценных баз данных. Данная защита обычно осуществляется с помощью специальных программных средств, подвергающих защищаемые программы и базы данных предварительной обработке (вставка парольной защиты, проверок по обращению к устройствам хранения ключа и ключевым дискетам, блокировка отладочных прерываний, проверка рабочей ПЭВМ по ее уникальным характеристикам и т.д.), которая приводит исполняемый код защищаемой программы и базы данных в состояние, препятствующее его выполнению на «чужих» машинах. Для повышения защищенности применяются дополнительные аппаратные блоки (ключи), подключаемые к разъему принтера или к системной шине ПЭВМ, а также шифрование файлов, содержащих исполняемый код программы. Общим свойством средств защиты программ от несанкционированного копирования является ограниченная стойкость такой защиты, так как в конечном случае исполняемый код программы поступает на выполнение в центральный процессор в открытом виде и может быть прослежен с помощью аппаратных отладчиков. Однако это обстоятельство не снимает потребительские свойства средств защиты до нуля, так как основной целью их применения является в максимальной степени затруднить, хотя бы временно, возможность несанкционированного копирования ценной информации. [7]
  3.  Контроль целостности программного обеспечения проводится с помощью:
  •  внешних средств (программ контроля целостности);
  •  внутренних средств (встроенных в саму программу).

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

Контроль целостности программ внутренними средствами выполняется при каждом запуске программы на выполнение и состоит в сравнении контрольных сумм отдельных блоков программ с их эталонными суммами. Такой контроль используется в программах для внутреннего пользования.

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

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

Чем выше уровень защиты, тем она дороже. Сокращение затрат идет в направлении стандартизации технических средств. В ряде случаев, исходя из конкретных целей и условий, рекомендуется применять типовые средства, прошедшие аттестацию, даже если они уступают по некоторым параметрам. [7]

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

Необходимо иметь в виду, что подлежащие защите сведения могут быть получены «противником» не только за счет осуществления «проникновения» к ЭВМ, которые с достаточной степенью надежности могут быть предотвращены (например, все данные хранятся только в зашифрованном виде), но и за счет побочных электромагнитных излучений и наводок на цепи питания и заземления ЭВМ, а также каналы связи. Все без исключения электронные устройства, блоки и узлы ЭВМ излучают подобные сигналы, которые могут быть достаточно мощными и могут распространяться на расстояния от нескольких метров до нескольких километров. При этом наибольшую опасность представляет собой получение «противником» информации о ключах. Восстановив ключ, можно предпринять ряд успешных действий по завладению зашифрованными данными, которые, как правило, охраняются менее тщательно, чем соответствующая открытая информация. С этой точки зрения выгодно отличаются именно аппаратные и программно-аппаратные средства защиты от несанкционированного доступа, для которых побочные сигналы о ключевой информации существенно ниже, чем для чисто программных реализаций. [7]

Основной вывод, который можно сделать из анализа развития банковской отрасли, заключается в том, что компьютеризация банковской деятельности продолжает возрастать. Основные изменения в банковской индустрии за последние десятилетия связаны именно с развитием информационных технологий. Можно прогнозировать дальнейшее снижение оборота наличных денег и постепенный уход на безналичные расчеты с использованием пластиковых карт, сети Internet и удаленных терминалов управления счетом юридических лиц. [7]

В связи с этим следует ожидать дальнейшее динамичное развитие средств информационной безопасности банков, поскольку их значение постоянно возрастает. [7]

2.5 Повышение уровня доверия и минимизации рисков.

Согласно ИСО/МЭК 15408  средства защиты должны удовлетворять требованиям доверия.

При анализе средств защиты от информационных атак, рассмотренных в п. 2.3.3, выяснилось, что средства контентного анализа не имеет описанного профиля защиты. Соответственно средства контентного анализа не может удовлетворять требованиям доверия, которые предъявляют  потребители  к средствам защиты в соответствии с ИСО/МЭК 15408.

Повысить уровень доверия к средству защиты возможно двумя способами.

2.5.1 Первый способ повышения доверия

Согласно ИСО/МЭК 15408, это создание нового профиля защиты. Конструкция «профиль защиты» (ПЗ) предусматривает создание обобщенного, предназначенного для многократного использования набора этих требований безопасности.

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

ИСО/МЭК 15408 предназначен для поддержки разработчиков при подготовке к оценке своих продуктов или систем и ее проведении, а также при установлении требований по безопасности, которыми должны удовлетворять каждый их продукт или система. Использование совместно с ИСО/МЭК 15408 методологии оценки, потенциально сопровождаемой соглашением о взаимном признании результатов оценки, позволит использовать ИСО/МЭК 15408 для поддержки иных лиц, помимо разработчиков ОО, при подготовки этого ОО, к оценке и содействовать его проведению.

ИСО/МЭК 15408 содержит критерии, предназначенные для использования оценщиками ОО при формировании заключения о соответствии объектов оценки предъявляемым к ним требованиям безопасности. В ИСО/МЭК 15408 приведено описание совокупности основных действий, выполняемых оценщиком, и функции безопасности, к которым относятся эти действия. ИСО/МЭК 15408, однако, не определяет процедуры, которых следует придерживаться при выполнении данных действий.

Хотя ИСО/МЭК 15408 ориентирован на определение и оценку характеристик безопасности ИТ для объектов оценки, он также может служить справочным материалом для тех, кто интересуется вопросами безопасности ИТ или несет ответственность за безопасность.  

 

2.5.2 Методы обеспечения доверия и сфера применения.

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

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

Особое внимание должно уделяться оценке результатов доверия. Для достижения более высоких степеней уверенности могут потребоваться формальная оценка или сертификация [11].

В  системах  обеспечения  информационной безопасности ИТ как правило, рассматривают два аспекта – формальный и  практический [12]. Формальный  аспект  заключается  в определении  критериев,  которым  должны соответствовать защищенные ИТ, практический –  в  определении  конкретного  комплекса  мер  по обеспечению  безопасности  применительно  к рассматриваемой информационной технологии.

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

Обычно безошибочное и устойчивое функционирование объекта в рамках приемлемых ограничений на стоимость и время невозможно осуществить в течение жизненного цикла системы ИТ вследствие ошибок или недосмотра оператора, отказа компонента оборудования или несовершенства механизмов обеспечения безопасности. В данной ситуации почти невозможно гарантировать безошибочность, устойчивость и безопасность функционирования системы ИТ [11].

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

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

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

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

Безопасность связана с защитой активов от угроз, где угрозы классифицированы на основе потенциала злоупотребления защищаемыми активами. Во внимание следует принимать все разновидности угроз, но в сфере безопасности наибольшее внимание уделяется тем из них, которые связаны с действиями человека, злонамеренными или иными. Рисунок 7 иллюстрирует высокоуровневые понятия безопасности и их взаимосвязь [1].

Рисунок 7 – Понятия безопасности и их взаимосвязь

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

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

Контрмеры предпринимают для уменьшения уязвимостей и выполнения политики безопасности владельцев активов (прямо или косвенно распределяя между этими составляющими). Но и после введения этих контрмер могут сохраняться остаточные уязвимости. Такие уязвимости могут использоваться нарушителями, представляя уровень остаточного риска для активов. Владельцы будут стремиться минимизировать этот риск, задавая дополнительные ограничения [1].

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

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

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

Рисунок 8 – Понятия, используемые при оценке, и их взаимосвязь

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

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

2.5.3 Второй способ повышения уровня доверия.

Второй способ, согласно ИСО/МЭК 17799, после того, как определены требования к информационной безопасности, следует выбрать и внедрить такие мероприятия по управлению информационной безопасностью, которые обеспечат повышение уровня доверия до приемлемого уровня. Эти мероприятия могут быть выбраны из настоящего стандарта, других источников, а также могут быть разработаны собственные мероприятия по управлению информационной безопасностью, удовлетворяющие специфическим потребностям организации. [13]

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

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

Ключевыми мерами контроля с точки зрения законодательства являются:

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

Мероприятия по управлению информационной безопасностью, рассматриваемые как общепринятая практика в области информационной безопасности, включают:

  •  наличие документа, описывающего политику информационной безопасности;
  •  распределение обязанностей по обеспечению информационной безопасности;
  •  обучение вопросам информационной безопасности;
  •  информирование об инцидентах, связанных с информационной безопасностью;
  •  управление непрерывностью бизнеса. [13]

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

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

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

2.5.4 Аудит информационной безопасности

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

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

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

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

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

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

-  интервьюирование  должностных лиц  организации (программистов,  администраторов базы данных, рядовых пользователей системы);

-  изучение  технической  и  организационно-распорядительной документации;

-  тестирование  информационной системы  с  помощью  специального  программного обеспечения. [14]

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

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

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

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

-  процедуры  анализа  действий, предпринятых  при  обработке  произошедших инцидентов, а также при наступлении аварийных ситуаций;

- процедуры порядка доступа в серверные помещения и других процедур по обеспечению  должного  уровня  безопасности информационных систем. [14]

Для  осуществления  проверки  на практике  может  применяться  так  называемая «модель  нарушителя»,  для  чего специалистам-аудиторам  с  разрешения руководства  предприятия  предоставляется физический доступ внутрь охраняемого периметра и возможность подключаться  к  информационной  системе  проверяемого  субъекта  на  уровне  каналов  связи. Благодаря использованию  такого подхода проверяющие  имеют  возможность  провести  полный  внутренний  тест  на  проникновение  в  любой  из  элементов  информационной  системы  компании.  При обнаружении каких-либо признаков несовершенства  системы  безопасности  поиск выявленных уязвимостей осуществляется на  всех  используемых  серверах,  рабочих станциях  и  сетевом  оборудовании.  Возможность реализации  такого метода проверки  позволяет  получить  реальную  картину  защищенности  информационной системы.  

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

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

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

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

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

Важным  моментом  также  является оценка  соответствия  информационной системы  требованиям  действующего  национального  и международного  законодательства  и  нормативной  базы  в  области информационной  безопасности (различных  руководящих  документов,  международных  общих  и  отраслевых  стандартов). Это  наиболее  важный  этап,  поскольку  на основании  полученных  после  его  проведения  результатов  аудитор  получает  возможность  сделать  целостные  и  обоснованные  выводы  о  степени  защищенности системы.  Для  определения  критериев оценки  защищенности  и  требований, предъявляемых к механизмам защиты, используется  целый  ряд  нормативных  документов.  К  ним  можно  отнести «Общие критерии  оценки  безопасности  информационных  технологий» (The Common Criteria for Information Technology Security Evaluation/ISO 15408)  и  стандарты BS 

7799  и ISO 17799/27001 «Практические правила  управления  информационной безопасностью» (Code of practice for information security management).  В «Общих  критериях»  перечислен  определенный набор требований к механизмам безопасности  организационного  уровня,  а также возможные меры физической защиты. Стандарт BS 7799 описывает механизмы  организационного  уровня,  реализуемых  в  целях  обеспечения  безопасности информационных  систем компаний любого уровня и сложности внутренней структурной  организации.  Большое  внимание уделено  таким  моментам,  как  безопасность  персонала  и  физическая  безопасность,  вопросам  управления  доступом  и контролю  выполнения  требований  политики  безопасности,  администрированию компьютерных  сетей, разработке и  сопровождению  информационных  систем.  Всего  таких  ключевых  средств  контроля,  перечисленных  в  данном  стандарте,  десять. Именно они в мировой практике считаются особо  важными. Эти  средства  актуальны для организации любого размера и любого  вида  деятельности.  Если  проверка проводится на  соответствие  стандарту ИСО/МЭК 17799,  то прежде всего определяется наличие данных средств контроля, а после этого оценивается полнота и правильность их реализации.  

Оценка  уровня  безопасности  системы проводится путем проведения анализа собранных на начальных этапах проверки данных.  Такая  проверка  дает  возможность  выявить,  в  первую  очередь,  перечень угроз и рисков, которым данная система  подвержена  или,  другими  словами, оценить  вероятность  того,  что  существующие  средства  защиты  не  смогут  противостоять вторжению со стороны недоброжелателей.  На  основании  сравнения существующих в конкретной информационной  среде  инструментов  защиты  с минимальным  набором  требований,  включенных  в  соответствующий  стандарт,  аудитор  получает  возможность  оценить уровень  риска  для  информационной  системы  в целом. Причем  следует отметить, что,  помимо  нормативно-правовых  документов конкретной компании или страны, критерии  оценки могут  выдвигаться  также  на  основании  рекомендации  компаний —  производителей  программного  и аппаратного обеспечения [15].

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

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

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

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

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

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

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

иного вида атаки.

Следует также отметить, что, помимо  выявленных  в  результате  проверки рисков, могут существовать также потенциальные  и  наиболее  характерные  для конкретного  вида  бизнеса  или  информационной системы риски и угрозы, так называемые «типовые»  угрозы  и  уязвимости. На  них  тоже  следует  обращать  внимание  при  разработке  рекомендации  по результатам  аудита  информационной безопасности.  Это  особенно  важно,  поскольку  исходными  условиями  создания полноценной  системы  информационной безопасности  должны  быть  четкие  представления  о  ее целях,  структуре,  о  видах угроз  и  их  источниках,  о  возможных мерах противодействия [15].

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

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

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

Выводы по второму разделу

Проблема оценки информационной безопасности автоматизированных систем, несомненно, является крайне важной и актуальной. Современные подходы к оценке безопасности информационных технологий зафиксированы в российских стандартах ИСО/МЭК 15408 и ИСО/МЭК 17799. В силу перечисленных выше причин путь повышения уровня доверия к средствам защиты информации более рациональный, по моему мнению, предлагается в стандарте ИСО/МЭК 15408.

3 Разработка Профиля защиты для средства контентного анализа

Перечень сокращений

Таблица 3

ЗБ

задание по безопасности

ИС

информационная система

КА

Контентный анализ

НСД

несанкционированный доступ

ОДФ

область действия функции безопасности

ОК

Общие критерии

ОО

объект оценки

ОС

операционная система

ОУД

оценочный уровень доверия к безопасности

ПБО

политика безопасности ОО

ПЗ

профиль защиты

ПФБ

политика функции безопасности

РД

руководящий документ

СКА

Средство контентного анализа

УК

управление конфигурацией

ФБО

функции безопасности ОО

3.1. Введение

3.1.1. Идентификация ПЗ

Название: Средства контентного анализа. Профиль защиты.

Обозначение: -2012.

Регистрация:

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

Родственные ПЗ: нет.

3.1.2. Аннотация ПЗ

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

3.1.3. Соглашения

Система обозначений, формат и соглашения, используемые в этом профиле защиты, основаны на версии 2.1 ОК.

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

Операции назначения или выбора - указываются в квадратных скобках ("[]"). Оставшиеся незавершенными операции в профиле защиты должны быть специфицированы разработчиком в задании по безопасности.

Операции уточнения - определяются при помощи слова "Уточнение:", написанного после мнемонического (краткого) имени. Эти операции предоставляют возможность добавить подробности или конкретизировать требования при использовании компонента.

Операции итерации - определяются числом внутри круглых скобок ("(#)"). Такое обозначение следует после краткого имени элемента требований и позволяет использовать компоненты более чем один раз с изменяющимися операциями.

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

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

Таблица 4:Соглашение по использованию выделения шрифтом

Соглашение

Цель

Операция

Полужирный

Выделение текста полужирным шрифтом применяется для предупреждения о том, что этот текст добавлен по отношению к тексту ОК.

Назначение
Уточнение

Курсив

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

Назначение

Подчеркивание

Выделение текста подчеркиванием применяется к результату операции выбора в требованиях ОК.

Назначение
Уточнение

Полужирный

и курсив

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

Выбор

3.1.4. Термины и определения

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

Информационным пространством называется информационная и телекоммуникационная инфраструктура, способная предоставлять и получать информационные сервисы.

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

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

Информационным обменом называется получение и/или предоставление информационных сервисов. Внешним информационным обменом называется информационный обмен с внешним информационным пространством.

Правила фильтрации – перечень условий, по которым с использованием заданных критериев фильтрации осуществляется разрешение или запрещение дальнейшей передачи пакетов (данных), и перечень действий, производимых СКА по регистрации и/или осуществлению дополнительных защитных функций.

3.2 Описание объекта оценки

В данном документе в качестве ОО рассматривается средство контентного анализа(СКА).

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

ОО может быть реализован как в виде программного обеспечения, так и в виде программно-аппаратного комплекса. 

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

3.3 Среда безопасности ОО

3.3.1 Предположения безопасности

A.SINGLEPT (Единая точка входа)- ОО является единственной точкой контроля внешнего информационного обмена.

A.SECURE (Контроль физического доступа) -ОО, связанная с ним консоль, активное сетевое и кроссовое оборудование, а также система электропитания защищены физически и доступны только для обслуживающего персонала.

A.COMMS (Защита передаваемых данных) -Защита передаваемых в процессе внешнего информационного обмена данных обеспечивается дополнительными средствами безопасности, либо было явно принято решение о том, что такая защита не требуется.

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

A. ENV_MANAGE (Среда управления) -Управление настройками ОО, включая безопасность содержащейся в нем информации, а также выделение уровней системных ресурсов осуществляется в соответствии с документацией, поставляемой в комплекте с ОО.

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

3.3.2 Предотвращаемые угрозы

3.3.2.1 Угрозы, предотвращаемые ОО

T.LACCESSЛицо, не имеющее соответствующих полномочий, может получить логический доступ к ОО.

T.AUTHВнешний пользователь может предпринять попытку НСД, выдавая себя за другого пользователя путем активного или пассивного перехвата аутентификационной информации.

T.ISPOOFВнешний пользователь может предпринять попытку НСД, выдавая себя за внутреннего пользователя путем подделки IP-адреса.

T.SSPOOFПользователь может предпринять попытку НСД, используя запрещенный сервис, имитируя при этом использование разрешенного сервиса.

T.NATTACKНарушитель может предпринять попытку НСД к защищаемым ОО сегментам ИС либо отдельным компьютерам, находящимся в указанных сегментах. Целью нападения может быть НСД к информационным ресурсам либо реализация отказа в обслуживании.

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

T.AUDITНарушитель может осуществить повреждение или подмену записей аудита с целью помешать расследованию либо оперативному пресечению попытки НСД.

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

T.CRASHМожет быть предпринята успешная попытка НСД вследствие нарушения работоспособности ОО либо его окружения.

3.3.2.2 Угрозы, предотвращаемые средой

T.INSTALLОО может быть доставлен и установлен таким образом, что появится возможность нарушения безопасности.

T.OPERATEНарушение безопасности может произойти из-за неправильного управления или эксплуатации ОО.

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

T.INALLПользователи могут осуществлять НСД с компьютера, на базе которого функционирует ОО, к ресурсам компьютеров, подключенных к защищенным сегментам внутренней сети.

T.SERVICESМожет быть реализована попытка НСД с использованием уязвимостей логики протоколов высокого уровня. ОО может отказать в доступе к конкретным сервисам либо их отдельным компонентам, однако в случае разрешения появляется возможность атак на соответствующие сервисы.

T.COMMSНарушитель может перехватить конфиденциальную информацию, передаваемую в процессе внешнего информационного обмена.

3.3.3 Политика безопасности

ОО реализует широкий класс режимов политики безопасности, обеспечивающих: 

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

•обеспечение подотчетности пользователей при осуществлении внешнего информационного обмена;

•реализацию принципа минимизации привилегий пользователя и администратора.

Ниже приведены варианты политики безопасности, совместимые с ПЗ ОО.

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

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

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

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

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

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

P.ACCOUNTПользователи должны нести ответственность за безопасность действий, выполняемых ими в процессе работы, путем неукоснительного выполнения утвержденных правил внешнего информационного обмена.

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

P.MAINTENANCEПеред проведением обслуживающих и профилактических работ вся критически важная информация ОО должна быть защищена.

3.4 Цели безопасности

3.4.1 Цели безопасности для ОО

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

O.ADMIN (Доступ администратора)Доступ к ОО предоставляется только уполномоченному администратору, которому предоставляется возможность конфигурирования и администрирования ОО в соответствии с утвержденными регламентами.

O.ACCOUNT (Контроль действий отдельных пользователей)Решение о предоставлении доступа принимается на основе уникального идентификатора пользователя. Аутентификация является механизмом, устанавливающим подлинность пользователя.

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

O.AUDIT (Аудит)Необходимо, чтобы записи аудита внешнего информационного обмена не только собирались в необходимом объеме, но и представлялись в виде, удобном для просмотра администратором, и были защищены от модификации или удаления.

3.4.2 Цели безопасности для среды

O.INSTALLНеобходимо обеспечить установку, инсталляцию и администрирование ОО таким образом, чтобы обеспечить безопасное состояние защищаемой системы.

O.SECUREНеобходимо осуществление контроля физического доступа к ОО.

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

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

3.5 Требования безопасности

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

3.5.1 Функциональные требования

Функциональные требования состоят из компонентов части 2 ОК, приведенных в Таблице 4

Таблица 4:Компоненты функциональных требований ОО

Компонент

Название

FDP_ACC.2

Полное управление доступом

FDP_ACF.1

Управление доступом на основе атрибутов безопасности

FDP_IFC.2

Полное управление информационными потоками

FDP_IFF.1

Простые атрибуты безопасности

FDP_ITC.2

Импорт данных пользователя с атрибутами безопасности

FDP_RIP.2

Полная защита остаточной информации

FDP_SDI.2

Мониторинг целостности хранимых данных и предпринимаемые действия

FIA_AFL.1

Обработка отказов аутентификации

FIA_ATD.1

Определение атрибутов пользователя

FIA_SOS.1

Верификация секретов

FIA_UAU.1

Выбор момента аутентификации

Продолжение таблицы 4

FIA_UAU.3

Аутентификация, защищенная от подделок

FIA_UAU.5

Сочетание механизмов аутентификации

FIA_UID.2

Идентификация до любых действий пользователя

FPT_AMT.1

Тестирование абстрактной машины

FPT_FLS.1

Сбой с сохранением безопасного состояния

FPT_RCV.1

Ручное восстановление

FPT_RVM.1

Невозможность обхода ПБО

FPT_SEP.1

Отделение домена ФБО

FPT_STM.1

Надежные метки времени

FPT_TDC.1

Взаимная согласованность данных ФБО

FPT_TST.1

Тестирование ФБО

FMT_MSA.1

Управление атрибутами безопасности

FMT_MSA.3

Инициализация статических атрибутов

FMT_MTD.1

Управление данными ФБО

FMT_SMR.1

FAU_ARP.1

Сигналы нарушителя безопасности

FAU_GEN.1

Генерация данных аудита

FAU_SAA.1

Анализ потенциального нарушения

FAU_SAR.1

Просмотр аудита

FAU_SAR.3

Выборочный просмотр аудита

FAU_SEL.1

Избирательный аудит

FAU_STG.1

Защищенное хранение журнала аудита

FAU_STG.4

Предотвращение потери данных аудита

FPR_ANO.1

Анонимность

FPR_PSE.1

Применение псевдонимов

FPR_UNL.1

Невозможность ассоциации

FTP_ITC.1

Доверенный канал передачи между ФБО

3.5.1.1 Защита данных пользователя (FDP) 

Таблица 5

FDP_ACC.2 – Полное управление доступом

FDP_ACC.2.1(1)

ФБО должны осуществлять управление доступом информационного обмена путем фильтрации информационных сервисов для субъектов внешнего и внутреннего информационного пространства и всех операций субъектов на объектах, на которые распространяется ПФБ.

Продолжение таблицы 5

FDP_ACC.2 – Полное управление доступом

FDP_ACC.2.1(2)

Уточнение: ФБО должны осуществлять управление доступом информационного обмена путем фильтрации информационных сервисов при получении информации от субъектов внешнего информационного пространства.

FDP_ACC.2.1(3)

Уточнение: ФБО должны осуществлять управление доступом информационного обмена путем фильтрации информационных сервисов при выдаче информации субъектам внешнего информационного пространства.

FDP_ACC.2.1(4)

Уточнение: ФБО должны осуществлять управление доступом информационного обмена путем фильтрации информационных сервисов при информационном обмене ОО с субъектами внешнего и внутреннего информационного пространства для аутентификации, обеспечения работы служебных сервисов для управления и диагностики работы сетевых устройств.

FDP_ACC.2.2(1)

ФБО должны обеспечить, чтобы на операции любого субъекта из ОДФ на любом объекте из ОДФ распространялась какая-либо ПФБ управления доступом.

FDP_ACC.2.2(2)

Уточнение: ФБО должны обеспечить полный контроль информационных потоков при осуществлении внешнего информационного обмена.

FDP_ACC.2.2(3)

Уточнение: ФБО должны обеспечить проверку соответствия информационных сервисов, запрашиваемых в процессе информационного обмена и определенных политикой безопасности, на уровне примитивов прикладного уровня.

FDP_ACC.2.2(4)

Уточнение: ФБО должны обеспечить осуществление информационного обмена без маршрутизации информационных потоков на сетевом уровне модели ISO/OSI.

Продолжение таблицы 5

FDP_ACF.1 – Управление доступом на основе атрибутов безопасности

FDP_ACF.1.1

ФБО должны осуществлять фильтрацию сервисов внешнего информационного обмена и политику управления доступом к объектам на основе следующих атрибутов:

•сетевых адресов субъектов информационного обмена;

•корректности IP-пакетов и наличию в них дополнительных служебных полей;

•интерфейсов, через которые осуществляется информационный обмен;

• следующих атрибутов транспортного уровня модели OSI/ISO:

  •  Элементы протокола транспортного уровня;
  •  Параметры примитива транспортного уровня;

•следующих атрибутов прикладного уровня модели OSI/ISO:

  •  Идентификатор примитива прикладного уровня;
  •  Параметры примитива прикладного уровня;
  •  Заданной последовательности идентификаторов и/или параметров примитивов прикладного уровня;

•атрибутов субъектов, делающих запрос на получение информационного сервиса (идентификационной и аутентификационной информации);

•времени/даты запроса сервисов внешнего информационного обмена.

 

Продолжение таблицы 5

FDP_ACF.1 – Управление доступом на основе атрибутов безопасности

FDP_ACF.1.2

ФБО должны реализовать следующие правила определения того, разрешена ли операция управляемого субъекта на управляемом объекте:

ОО производит фильтрацию на основе списков правил различных уровней модели ISO/OSI. Должна использоваться следующая последовательность анализа: 

•анализ правил в терминах атрибутов сетевого уровня;

•анализ правил в терминах атрибутов транспортного уровня;

•анализ правил в терминах атрибутов прикладного уровня.

FDP_ACF.1.3

ФБО должны явно разрешать доступ субъектов к объектам, основываясь на следующих дополнительных правилах: отсутствие правила на запрашиваемый сервис приводит к невозможности его предоставления.

FDP_ACF.1.4

ФБО должны явно отказывать в доступе субъектов к объектам, основываясь на следующих дополнительных правилах:

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

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

•должны отклоняться широковещательные (broadcast) запросы;

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

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

•должны отклоняться запросы, содержащие недопустимые последовательности идентификаторов и/или параметров примитивов прикладного уровня.

Продолжение таблицы 5.

FDP_IFC.2 – Полное управление информационными потоками

FDP_IFC.2.1(1)

ФБО должны осуществлять ПФБ управления информационными потоками на сетевом уровне для следующих субъектов:

  •  субъектов из внешнего/внутреннего информационного пространства, осуществляющих информационный обмен с субъектами из внутреннего/внешнего информационного пространства через ОО;

и информации:

  •  информационный поток, осуществляемый с использованием всех протоколов, кроме [назначение: список протоколов, определенных в ЗБ, для которых действуют другие политики безопасности управления информационными потоками, и перечисленных в FDP_IFC.2.1(2) и FDP_IFC.2.1(3)]  

для всех операций перемещения управляемой информации к управляемым субъектам и от них, на которые распространяется ПФБ. 

FDP_IFC.2.1(2)

ФБО должны осуществлять ПФБ управления информационными потоками на прикладном уровне без аутентификации для следующих субъектов:

  •  субъектов из внешнего/внутреннего информационного пространства, осуществляющих информационный обмен с субъектами из внутреннего/внешнего информационного пространства через ОО;

и информации:

  •  информационный поток, осуществляемый с использованием [назначение: список протоколов, определенных в ЗБ для которых осуществляется фильтрация на прикладном уровне, за исключением протоколов, перечисленных в FDP_IFC.2.1(3)]  

для всех операций перемещения управляемой информации к управляемым субъектам и от них, на которые распространяется ПФБ. 

Продолжение таблицы 5

FDP_IFC.2 – Полное управление информационными потоками

FDP_IFC.2.1(3)

ФБО должны осуществлять ПФБ управления информационными потоками на прикладном уровне с аутентификацией для следующих субъектов:

  •  субъектов из внешнего/внутреннего информационного пространства, осуществляющих информационный обмен с субъектами из внутреннего/внешнего информационного пространства через ОО;

и информации:

  •  информационный поток, осуществляемый с использованием [назначение: список протоколов, определенных в ЗБ, для которых осуществляется фильтрация на прикладном уровне с использованием механизмов аутентификации, перечисленных в FIA_UAU.5]  

для всех операций перемещения управляемой информации к управляемым субъектам и от них, на которые распространяется ПФБ. 

FDP_IFC.2.2

ФБО должны обеспечить, чтобы в пределах ОДФ на все операции перемещения управляемой информации управляемым субъектам и от них распространялась какая-либо ПФБ управления информационными потоками.

Замечания по применению: Автор ЗБ должен перечислить все протоколы, для которых реализуются политики управления информационными потоками, приведенные в FDP_IFC.2.2(2) и FDP_IFC.2.2(3).

Таблица 6.

FDP_IFF.1 – Простые атрибуты безопасности1

FDP_IFF.1.1

ФБО должны осуществлять политику безопасности управления информационными потоками, основанную на следующих типах атрибутов безопасности субъектов и информации:

•сетевые адреса субъектов информационного обмена;

•идентификаторы субъектов информационного обмена;

•интерфейсы, через которые осуществляется информационный обмен;

•элементы протокола транспортного уровня;

•запрашиваемые информационные сервисы.

FDP_IFF.1.2

ФБО должны разрешать информационный поток между управляемыми субъектом и информацией посредством управляемой операции, если выполняются следующие правила: 

•сетевой адрес субъекта из внешнего информационного пространства транслируется во внутренний сетевой адрес, а сетевой адрес субъекта из внутреннего информационного пространства транслируется в сетевой адрес для установки соединения с внешней сетью;

•сетевой адрес субъекта из внутреннего информационного пространства транслируется во внешний сетевой адрес, а сетевой адрес субъекта из внешнего информационного пространства транслируется в сетевой адрес для установки соединения с внутренней сетью;

Продолжение таблицы 6

FDP_IFF.1 – Простые атрибуты безопасности2

идентификатор субъекта информационного обмена является допустимым для данной операции;

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

•протокол транспортного уровня корректно настроен и разрешает данную операцию;

•запрашиваемый информационный сервис является разрешенным.

FDP_IFF.1.6

ФБО должны явно запрещать информационный поток, основываясь на следующих правилах:

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

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

•должны отклоняться широковещательные (broadcast) запросы;

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

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

•должны отклоняться запросы, содержащие недопустимые последовательности идентификаторов и/или параметров примитивов прикладного уровня.

 

Продолжение таблицы 6

FDP_ITC.2 – Импорт данных пользователя с атрибутами безопасности

FDP_ITC.2.1

ФБО должны обеспечить возможность импорта пользовательских идентификационных данных и аутентификационной информации при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ.

FDP_ITC.2.2

ФБО должны использовать атрибуты безопасности, ассоциированные с импортируемыми данными пользователя.

FDP_ITC.2.3

ФБО должны обеспечить, чтобы используемый протокол предусматривал однозначную ассоциацию между атрибутами безопасности и полученными данными пользователя.

FDP_ITC.2.4

ФБО должны обеспечить, чтобы интерпретация атрибутов безопасности импортируемых данных пользователя была такой, как предусмотрено источником данных пользователя.

FDP_ITC.2.5

ФБО должны реализовать следующие правила при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ: [назначение: дополнительные правила управления импортом].

Таблица 7

FDP_RIP.2 – Полная защита остаточной информации

FDP_ RIP.2.1

ФБО должны обеспечить недоступность любого предыдущего информационного содержания ресурсов при распределении или освобождении ресурсов для всех объектов.

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

Таблица 8.

FDP_SDI.2 – Мониторинг целостности хранимых данных и предпринимаемые действия

FDP_SDI.2.1

ФБО должны контролировать данные уполномоченного администратора ОО, хранимые в пределах ОДФ, на наличие ошибок целостности для всех объектов, основываясь на следующих атрибутах:

•файлы исполняемых модулей ОО;

•конфигурационных файлов и баз данных;

•файлов, содержащих аутентификационную информацию.

FDP_SDI.2.2

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

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

3.5.1.2 Идентификация и аутентификация (FIA)

Таблица 9

FIA_AFL.1 – Обработка отказов аутентификации

FIA_AFL.1.1

ФБО должны обнаруживать, когда произойдет [назначение: число] неуспешных попыток аутентификации пользователя.

FIA_AFL.1.2

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

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

Таблица 10.

FIA_ATD.1 – Определение атрибутов пользователя

FIA_ATD.1.1

ФБО должны поддерживать для каждого пользователя следующий список атрибутов безопасности:

•идентификаторы субъектов информационного обмена;

•идентифицированные роли безопасности субъектов информационного обмена, предусмотренные компонентом FMT_SMR.1;

•запрашиваемые информационные сервисы.

•[назначение: прочие атрибуты безопасности, используемые в соответствии с принятой политикой безопасности.]

Таблица 11.

FIA_SOS.1 – Верификация секретов

FIA_SOS.1.1

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

Таблица 12.

FIA_UAU.1 – Выбор момента аутентификации

FIA_UAU.1.1

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

FIA_UAU.1.2

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

Замечания по применению: Автор ЗБ должен привести перечень доступных информационных сервисов для пользователей, прошедших или не прошедших процедуру аутентификации, в соответствии с политиками безопасности, определенными в FDP_IFC.2.  

Таблица 13.

FIA_UAU.3 – Аутентификация, защищенная от подделок

FIA_UAU.3.1

ФБО должны предотвращать применение любым пользователем ФБО аутентификационных данных, которые были подделаны.

FIA_UAU.3.2

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

Таблица 14.

FIA_UAU.5 – Сочетание механизмов аутентификации

FIA_UAU.5.1

ФБО должны предоставлять следующий список сочетаемых механизмов аутентификации для поддержки аутентификации пользователя:

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

FIA_UAU.5.2

ФБО должны аутентифицировать любой представленный идентификатор пользователя согласно следующему:

•уполномоченный администратор в соответствии с принятой политикой безопасности вправе осуществлять выбор механизмов аутентификации и их правил из числа подключаемых модулей аутентификации, предоставленных разработчиком ФБО. 

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

Таблица 15.

FIA_UID.2 – Идентификация до любых действий пользователя

FIA_UID.2.1

ФБО должны требовать, чтобы каждый пользователь был успешно идентифицирован до разрешения любого действия, выполняемого при посредничестве ФБО от имени этого пользователя

3.5.1.3 Защита ФБО (FPT)

Таблица 16.

FPT_AMT.1 – Тестирование абстрактной машины

FPT_AMT.1.1

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

Таблица 17.

FPT_FLS.1 – Сбой с сохранением безопасного состояния

FPT_FLS.1.1

Уточнение: ФБО должны обеспечивать невозможность НСД к ресурсам внутреннего информационного пространства при следующих типах сбоев: 

•любые сбои аппаратного обеспечения;

•любые сбои программного обеспечения;

•любые сбои внешнего сервера аутентификации;

•любые сбои ОС;

•любые сбои системы электропитания.

Таблица 18.

FPT_RCV.1 – Ручное восстановление

FPT_RCV.1.1

После сбоя или прерывания обслуживания ФБО должны перейти в режим аварийной поддержки, который предоставляет возможность возврата ОО к безопасному состоянию.

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

Таблица 19.

FPT_RVM.1 – Невозможность обхода ПБО

FPT_RVM.1.1

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

Замечания по применению: ОО должен обеспечить невозможность внешнего информационного обмена до активизации механизмов безопасности.

Таблица 20.

FPT_SEP.1 – Отделение домена ФБО

FPT_SEP.1.1

ФБО должны поддерживать домен безопасности для собственного выполнения, защищающий их от вмешательства и искажения недоверенными субъектами.

FPT_SEP.1.2

ФБО должны реализовать разделение между доменами безопасности субъектов в ОДФ.

Замечания по применению: В ОО должна обеспечиваться защита от доступа пользователей к сервисам администрирования ОО без подтверждения прав на проведение таких действий.

Таблица 21.

FPT_STM.1 – Надежные метки времени

FPT_STM.1.1

ФБО должны быть способны предоставить надежные метки времени для собственного использования.

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

Таблица 22.

FPT_TDC.1 – Взаимная согласованность данных ФБО

FPT_TDC.1.1

ФБО должны обеспечить способность согласованно интерпретировать ниже перечисленный список типов данных ФБО, совместно используемых ФБО и другим доверенным продуктом ИТ:

•атрибуты ПФБ, ассоциированные с данными;

•идентификационная и аутентификационная информация;

•информация аудита.

 

FPT_TDC.1.2

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

Таблица 23.

FPT_TST.1 – Тестирование ФБО

FPT_TST.1.1

ФБО должны выполнять пакет программ самотестирования при запуске, по запросу уполномоченного администратора, при восстановлении после сбоев для демонстрации правильного выполнения ФБО.

FPT_TST.1.2

ФБО должны предоставить уполномоченным администраторам возможность верифицировать целостность данных ФБО.

FPT_TST.1.3

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

Замечания по применению: Под данными ФБО подразумеваются параметры конфигурации ОО. В ОО должна обеспечиваться возможность регламентного тестирования:

•реализации правил фильтрации;

•процесса идентификации и аутентификации;

•процесса регистрации;

•процесса идентификации и аутентификации уполномоченного администратора;

•процесса регистрации действий уполномоченного администратора;

•процесса контроля целостности программной и информационной части;

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

  1.  Управление безопасностью (FMT)

Таблица 24.

FMT_MSA.1 – Управление атрибутами безопасности

FMT_MSA.1.1

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

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

Таблица 25.

FMT_MSA.3 – Инициализация статических атрибутов

FMT_MSA.3.1

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

FMT_MSA.3.2

ФБО должны предоставить возможность уполномоченным администраторам определять альтернативные начальные значения для отмены значений по умолчанию при создании объекта или информации.

Таблица 26.

FMT_MTD.1 – Управление данными ФБО

FMT_MTD.1.1

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

•информация аудита;

•конфигурационная информация

только уполномоченными администраторами. 

Таблица 27.

FMT_SMR.1 – Роли безопасности

FMT_SMR.1.1

ФБО должны поддерживать следующие роли:

•уполномоченный администратор ОО;

•[назначение: прочие пользователи, полномочия которых определены в соответствии с принятой политикой безопасности.]

 

FMT_SMR.1.2

ФБО должны быть способны ассоциировать пользователей с ролями.

3.5.1.5 Аудит (FAU)

Таблица 28.

FAU_ARP.1 – Сигналы нарушения безопасности

FAU_ARP.1.1

При обнаружении возможного нарушения безопасности ФБО должны обеспечить следующие действия:

•локальное оповещение администратора;

•удаленное оповещение администратора;

•программируемую реакцию на события в ОО.

 

Продолжение таблицы 28.

FAU_GEN.1 – Генерация данных аудита

FAU_GEN.1.1

ФБО должны быть способны генерировать запись аудита для следующих событий, потенциально подвергаемых аудиту:

Запуск и завершение выполнения функций аудита;
все попытки получения сервисов прикладного уровня, блокированные ФБО;
все запросы, адресованные непосредственно к ОО, в том числе для получения информации об архитектуре и конфигурации ФБО;
все попытки изменения атрибутов безопасности;
все запросы на получение доступа к аутентификационным данным;
все запросы на использование механизмов аутентификации;
завершение обработки запроса, вызванное рядом неудачных попыток аутентификации;
использование функций, относящихся к администрированию ФБО;

все попытки изменения параметров конфигурации ФБО.  

FAU_GEN.1.2

ФБО должны регистрировать в каждой записи аудита, по меньшей мере, следующую информацию:

Дата и время события, тип события, идентификатор субъекта и результат события (успешный или неуспешный).

FAU_SAA.1 – Анализ потенциального нарушения

FAU_SAA.1.1

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

Продолжение таблицы 28.

FAU_SAA.1 – Анализ потенциального нарушения

FAU_SAA.1.2

ФБО должны реализовать следующие правила при мониторинге событий, подвергающихся аудиту:

а) накопление или объединение следующих событий, указывающих на возможное нарушение безопасности:

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

б) [назначение: другие правила]

Таблица 29.

FAU_SAR.1 – Просмотр аудита

FAU_SAR.1.1

ФБО должны предоставлять уполномоченным администраторам возможность читать всю информацию аудита из записей аудита.

FAU_SAR.1.2

ФБО должны предоставлять записи аудита в виде, позволяющем пользователю воспринимать содержащуюся в них информацию.

Замечания по применению: Возможность просмотра записей аудита предоставляется с помощью соответствующих средств просмотра.

Таблица 30.

FAU_SAR.3 – Выборочный просмотр аудита

FAU_SAR.3.1

ФБО должны предоставить возможность выполнить поиск, сортировку или упорядочение данных аудита, основанные на:

•идентификаторах субъектов информационных сервисов сетевого, транспортного и прикладного уровня;

•дате, времени;

•логических комбинациях параметров, приведенных выше.

Таблица 31.

 FAU_SEL.1 – Избирательный аудит

FAU_SEL.1.1

ФБО должны быть способны к включению событий, потенциально подвергаемых аудиту, в совокупность событий, подвергающихся аудиту, или к их исключению из этой совокупности по следующим атрибутам:

а) •тип события;

  идентификатор пользователя;

  идентификатор объекта;

    •идентификатор субъекта.

б) [назначение: список дополнительных атрибутов, на которых основана избирательность аудита].

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

Таблица 32.

FAU_STG.1 – Защищенное хранение журнала аудита

FAU_STG.1.1

ФБО должны защищать хранимые записи аудита от несанкционированного удаления.

FAU_STG.1.2

ФБО должны быть способны к предотвращению модификации записей аудита.

Замечания по применению: Защищенное хранение записей аудита реализуется средствами ОС.

Таблица 33.

FAU_STG.4 – Предотвращение потери данных аудита

FAU_STG.4.1

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

Замечания по применению: В случае, когда невозможна запись данных аудита поверх самых старых записей аудита, ОО должен перейти в режим аварийной поддержки.

3.5.1.6Приватность (FPR)

Таблица 34.

FPR_ANO.1 – Анонимность

FPR_ANO.1.1

ФБО должны обеспечить, чтобы внешние субъекты информационного обмена были не способны определить подлинное имя пользователя, связанного с ОО.

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

Таблица 35.

FPR_PSE.1 – Применение псевдонимов

FPR_PSE.1.1

ФБО должны обеспечить, чтобы внешние субъекты информационного обмена были не способны определить подлинное имя пользователя, связанного с субъектами, операциями и/или объектами внутреннего информационного пространства.

FPR_PSE.1.2

ФБО должны быть способны предоставить не менее одного псевдонима подлинного имени пользователя для субъектов внешнего информационного пространства.

FPR_PSE.1.3

ФБО должны быть способны определить псевдоним пользователя и верифицировать его соответствие согласно принятому алгоритму трансляции IP-адресов.

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

Таблица 36.

FPR_UNL.1 – Невозможность ассоциации

FPR_UNL.1.1

ФБО должны обеспечить, чтобы пользователи и субъекты из внешнего информационного пространства были не способны определить однозначное соответствие запросов с тем или иным субъектом внутреннего информационного пространства.

Замечания по применению: При обеспечении анонимности доступа к сервисам внешнего информационного пространства ОО должен обеспечить невозможность ассоциации запросов с тем или иным субъектом внутреннего информационного пространства.

3.5.2 Требования доверия к безопасности

Комбинация выбранных компонентов доверия к безопасности соответствует 4-му оценочному уровню доверия к безопасности (ОУД4), усиленному компонентами ADV_IMP.2 (Реализация ФБО), AVA_CCA.1 (Анализ скрытых каналов) и AVA_VLA.3 (Умеренно стойкий).

3.5.2.1 Управление конфигурацией (ACM)

3.5.2.1.1 ACM_AUT.1 Частичная автоматизация УК

ACM_AUT.1.1D Разработчик должен использовать систему УК.

ACM_AUT.1.2D Разработчик должен представить план УК.

ACM_AUT.1.1C Система УК должна предоставить автоматизированные средства, с использованием которых в представлении реализации ОО производятся только санкционированные изменения.

ACM_AUT.1.2C Система УК должна предоставить автоматизированные средства для поддержки генерации ОО.

ACM_AUT.1.3C План УК должен содержать описание автоматизированных инструментальных средств, используемых в системе УК.

ACM_AUT.1.4C План УК должен содержать описание, как автоматизированные инструментальные средства используются в системе УК.

ACM_AUT.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

3.5.2.1.2 ACM_CAP.4 Поддержка генерации, процедуры приемки

ACM_CAP.4.1D Разработчик должен предоставить маркировку для ОО.

ACM_CAP.4.2D Разработчик должен использовать систему УК.

ACM_CAP.4.3D Разработчик должен представить документацию УК.

ACM_CAP.4.1C Маркировка ОО должна быть уникальна для каждой версии ОО.

ACM_CAP.4.2C ОО должен быть помечен маркировкой.

ACM_CAP.4.3C Документация УК должна включать в себя список конфигурации, план УК и план приемки.

ACM_CAP.4.4C Список конфигурации должен содержать описание элементов конфигурации, входящих в ОО.

ACM_CAP.4.5C Документация УК должна содержать описание метода, используемого для уникальной идентификации элементов конфигурации.

ACM_CAP.4.6C Система УК должна уникально идентифицировать все элементы конфигурации.

ACM_CAP.4.7С План УК должен содержать описание, как используется система УК.

ACM_CAP.4.8С Свидетельство должно демонстрировать, что система УК действует в соответствии с планом УК.

ACM_CAP.4.9С Документация УК должна содержать свидетельство, что система УК действительно сопровождала и продолжает эффективно сопровождать все элементы конфигурации.

ACM_CAP.4.10С Система УК должна предусмотреть такие меры, при которых в элементах конфигурации могут быть сделаны только санкционированные изменения.

ACM_CAP.4.11C Система УК должна поддерживать генерацию ОО.

ACM_CAP.4.12C План приемки должен содержать описание процедур, используемых для приемки модифицированного или вновь созданного элемента конфигурации как части ОО.

ACM_CAP.4.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

3.5.2.1.3 ACM_SCP.2 Охват УК отслеживания проблем

ACM_SCP.2.1D Разработчик должен представить документацию УК.

ACM_SCP.2.1C Документация УК должна показать, что система УК, как минимум, отслеживает: представление реализации ОО, проектную документацию, тестовую документацию, документацию пользователя, документацию администратора, документацию УК и недостатки безопасности.

ACM_SCP.2.2C Документация УК должна содержать описание, как элементы конфигурации отслеживаются системой УК.

ACM_SCP.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

3.5.2.2 Поставка и эксплуатация (ADO)

3.5.2.2.1 ADO_DEL.2 Обнаружение модификации

ADO_DEL.2.1D Разработчик должен задокументировать процедуры поставки ОО или его частей пользователю.

ADO_DEL.2.2D Разработчик должен использовать процедуры поставки.

ADO_DEL.2.1C Документация поставки должна содержать описание всех процедур, необходимых для поддержки безопасности при распространении версий к местам использования.

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

ADO_DEL.2.3C Документация поставки должна содержать описание, как различные процедуры позволяют обнаружить попытку подмены от имени разработчика, даже в тех случаях, когда разработчик ничего не отсылал к месту использования.

ADO_DEL.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

3.5.2.2.2 ADO_IGS.1 Процедуры установки, генерации и запуска

ADO_IGS.1.1D Разработчик должен задокументировать процедуры, необходимые для безопасной установки, генерации и запуска ОО.

ADO_IGS.1.1C Документация должна содержать описание последовательности действий, необходимых для безопасной установки, генерации и запуска ОО.

ADO_IGS.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

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

3.5.2.3 Разработка (ADV)

3.5.2.3.1 ADV_FSP.2 Полностью определенные внешние интерфейсы

ADV_FSP.2.1D Разработчик должен представить функциональную спецификацию.

ADV_FSP.2.1C Функциональная спецификация должна содержать неформальное описание ФБО и их внешних интерфейсов.

ADV_FSP.2.2C Функциональная спецификация должна быть внутренне непротиворечивой.

ADV_FSP.2.3C Функциональная спецификация должна содержать описание назначения и методов использования всех внешних интерфейсов ФБО, обеспечивая полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.

ADV_FSP.2.4C Функциональная спецификация должна полностью представить ФБО.

ADV_FSP.2.5C Функциональная спецификация должна включать в себя логическое обоснование, что ФБО полностью представлены.

ADV_FSP.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_FSP.2.2E Оценщик должен сделать независимое заключение, что функциональная спецификация – точное и полное отображение функциональных требований безопасности ОО.

3.5.2.3.2. ADV_HDL.2 Проект верхнего уровня

ADV_HLD.2.1D Разработчик должен представить проект верхнего уровня ФБО.

ADV_HLD.2.1C Представление проекта верхнего уровня должно быть неформальным.

ADV_HLD.2.2C Проект верхнего уровня должен быть внутренне непротиворечивым.

ADV_HLD.2.3C Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

ADV_HLD.2.4C Проект верхнего уровня должен содержать описание функциональных возможностей безопасности, предоставленных каждой подсистемой ФБО.

ADV_HLD.2.5C Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.

ADV_HLD.2.6C Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.

ADV_HLD.2.7C Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.

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

ADV_HLD.2.9C Проект верхнего уровня должен содержать описание разделения ОО на подсистемы, осуществляющие ПБО, и прочие.

ADV_HLD.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

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

3.5.2.3.3 ADV_IMP.2 Реализация ФБО

ADV_IMP.2.1D Разработчик должен обеспечить представление реализации для всех ФБО.

ADV_IMP.2.1C Представление реализации должно однозначно определить ФБО на таком уровне детализации, что ФБО могут быть созданы без дальнейших проектных решений.

ADV_IMP.2.2C Представление реализации должно быть внутренне непротиворечивым.

ADV_IMP.2.3C Представление реализации должно включать в себя описание взаимосвязей между всеми частями реализации.

ADV_IMP.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_IMP.2.2E Оценщик должен сделать независимое заключение, что представление реализации – точное и полное отображение функциональных требований безопасности ОО.

3.5.2.3.4 ADV_LLD.1 Описательный проект нижнего уровня

ADV_LLD.1.1D Разработчик должен представить проект нижнего уровня ФБО.

ADV_LLD.1.1C Представление проекта нижнего уровня должно быть неформальным.

ADV_LLD.1.2C Проект нижнего уровня должен быть внутренне непротиворечивым.

ADV_LLD.1.3C Проект нижнего уровня должен содержать описание ФБО в терминах модулей.

ADV_LLD.1.4C Проект нижнего уровня должен содержать описание назначения каждого модуля.

ADV_LLD.1.5C Проект нижнего уровня должен определить взаимосвязи между модулями в терминах предоставляемых функциональных возможностей безопасности и зависимостей от других модулей.

ADV_LLD.1.6C Проект нижнего уровня должен содержать описание, как предоставляется каждая из функций, осуществляющих ПБО.

ADV_LLD.1.7C Проект нижнего уровня должен идентифицировать все интерфейсы модулей ФБО.

ADV_LLD.1.8C Проект нижнего уровня должен идентифицировать, какие из интерфейсов модулей ФБО являются видимыми извне.

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

ADV_LLD.1.10C Проект нижнего уровня должен содержать описание разделения ОО на модули, осуществляющие ПБО, и прочие.

ADV_LLD.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

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

3.5.2.3.5 ADV_RCR.1 Неформальная демонстрация соответствия

ADV_RCR.1.1D Разработчик должен представить анализ соответствия между всеми смежными парами имеющихся представлений ФБО.

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

ADV_RCR.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

3.5.2.3.6 ADV_SPM.1 Неформальная модель политики безопасности ОО

ADV_SPM.1.1D Разработчик должен представить модель ПБО.

ADV_SPM.1.2D Разработчик должен демонстрировать соответствие между функциональной спецификацией и моделью ПБО.

ADV_SPM.1.1C Модель ПБО должна быть неформальной.

ADV_SPM.1.2C Модель ПБО должна содержать описание правил и характеристик всех политик ПБО, которые могут быть смоделированы.

ADV_SPM.1.3C Модель ПБО должна включать в себя логическое обоснование, которое демонстрирует, что она согласована и полна относительно всех политик ПБО, которые могут быть смоделированы.

ADV_SPM.1.4C Демонстрация соответствия между моделью ПБО и функциональной спецификацией должна показать, что все функции безопасности в функциональной спецификации являются непротиворечивыми и полными относительно модели ПБО.

ADV_SPM.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

3.5.2.4 Документация (AGD)

3.5.2.4.1 AGD_ADM.1 Руководство администратора

AGD_ADM.1.1D Разработчик должен представить руководство администратора, предназначенное для персонала системного администрирования.

AGD_ADM.1.1C Руководство администратора должно содержать описание функций администрирования и интерфейсов, доступных администратору ОО.

AGD_ADM.1.2C Руководство администратора должно содержать описание того, как управлять ОО безопасным способом.

AGD_ADM.1.3C Руководство администратора должно содержать предупреждения относительно функций и привилегий, которые следует контролировать в безопасной среде обработки информации.

AGD_ADM.1.4C Руководство администратора должно содержать описание всех предположений о поведении пользователя, которые связаны с безопасной эксплуатацией ОО.

AGD_ADM.1.5C Руководство администратора должно содержать описание всех параметров безопасности, контролируемых администратором, указывая, при необходимости, безопасные значения.

AGD_ADM.1.6C Руководство администратора должно содержать описание каждого типа относящихся к безопасности событий, связанных с выполнением обязательных функций администрирования, включая изменение характеристик безопасности сущностей, контролируемых ФБО.

AGD_ADM.1.7C Руководство администратора должно быть согласовано со всей другой документацией, представленной для оценки.

AGD_ADM.1.8C Руководство администратора должно содержать описание всех требований безопасности к среде ИТ, которые относятся к администратору.

AGD_ADM.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

3.5.2.4.2 AGD_USR.1 Руководство пользователя

AGD_USR.1.1D Разработчик должен представить руководство пользователя.

AGD_USR.1.1C Руководство пользователя должно содержать описание функций и интерфейсов, которые доступны пользователям ОО, не связанным с администрированием.

AGD_USR.1.2C Руководство пользователя должно содержать описание применения доступных пользователям функций безопасности, предоставляемых ОО.

AGD_USR.1.3C Руководство пользователя должно содержать предупреждения относительно доступных для пользователей функций и привилегий, которые следует контролировать в безопасной среде обработки информации.

AGD_USR.1.4C Руководство пользователя должно четко представить все обязанности пользователя, необходимые для безопасной эксплуатации ОО, включая обязанности, связанные с предположениями относительно действий пользователя, содержащимися в изложении среды безопасности ОО.

AGD_USR.1.5C Руководство пользователя должно быть согласовано со всей другой документацией, представленной для оценки.

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

AGD_USR.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

3.5.2.5 Поддержка жизненного цикла (ALC)

3.5.2.5.1 ALC_DVS.1 Идентификация мер безопасности

ALC_DVS.1.1D Разработчик должен иметь документацию по безопасности разработки.

ALC_DVS.1.1C Документация по безопасности разработки должна содержать описание всех физических, процедурных, относящихся к персоналу и других мер безопасности, которые необходимы для защиты конфиденциальности и целостности проекта ОО и его реализации в среде разработки.

ALC_DVS.1.2C Документация по безопасности разработки должна предоставить свидетельство, что необходимые меры безопасности соблюдаются во время разработки и сопровождения ОО.

ALC_DVS.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ALC_DVS.1.2E Оценщик должен подтвердить применение мер безопасности.

3.5.2.5.2 ALC_LCD.1 Определение модели жизненного цикла разработчиком

ALC_LCD.1.1D Разработчик должен установить модель жизненного цикла, используемую при разработке и сопровождении ОО.

ALC_LCD.1.2D Разработчик должен представить документацию по определению жизненного цикла.

ALC_LCD.1.1C Документация по определению жизненного цикла должна содержать описание модели, применяемой при разработке и сопровождении ОО.

ALC_LCD.1.2C Модель жизненного цикла должна обеспечить необходимый контроль за разработкой и сопровождением ОО.

ALC_LCD.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

3.5.2.5.3 ALC_TAT.1 Полностью определенные инструментальные средства разработки.

ALC_TAT.1.1D Разработчик должен идентифицировать инструментальные средства разработки ОО.

ALC_TAT.1.2D Разработчик должен задокументировать выбранные опции инструментальных средств разработки, зависящие от реализации.

ALC_TAT.1.1C Все инструментальные средства разработки, используемые для реализации, должны быть полностью определены.

ALC_TAT.1.2C Документация инструментальных средств разработки должна однозначно определить значения всех конструкций языка, используемых в реализации.

ALC_TAT.1.3C Документация инструментальных средств разработки должна однозначно определить значения всех опций, зависящих от реализации.

ALC_TAT.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

3.5.2.6 Тестирование (ATE)

3.5.2.6.1 ATE_COV.2 Анализ покрытия

ATE_COV.2.1D Разработчик должен представить анализ покрытия тестами.

ATE_COV.2.1C Анализ покрытия тестами должен демонстрировать соответствие между тестами, идентифицированными в тестовой документации, и описанием ФБО в функциональной спецификации.

ATE_COV.2.2C Анализ покрытия тестами должен демонстрировать полное соответствие между описанием ФБО в функциональной спецификации и тестами, идентифицированными в тестовой документации.

ATE_COV.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

3.5.2.6.2 ATE_DPT.1 Тестирование: проект верхнего уровня

ATE_DPT.1.1D Разработчик должен представить анализ глубины тестирования.

ATE_DPT.1.1C Анализ глубины должен показать достаточность тестов, идентифицированных в тестовой документации, для демонстрации, что ФБО выполняются в соответствии с проектом верхнего уровня.

ATE_DPT.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

3.5.2.6.3 ATE_FUN.1 Функциональное тестирование

ATE_FUN.1.1D Разработчик должен протестировать ФБО и задокументировать результаты.

ATE_FUN.1.2D Разработчик должен представить тестовую документацию.

ATE_FUN.1.1C Тестовая документация должна состоять из планов и описаний процедур тестирования, а также ожидаемых и фактических результатов тестирования.

ATE_FUN.1.2C Планы тестирования должны идентифицировать проверяемые функции безопасности и содержать изложение целей тестирования.

ATE_FUN.1.3C Описания процедур тестирования должны идентифицировать тесты, которые необходимо выполнить, и включать в себя сценарии для тестирования каждой функции безопасности. Эти сценарии должны учитывать любое влияние последовательности выполнения тестов на результаты других тестов.

ATE_FUN.1.4C Ожидаемые результаты тестирования должны показать прогнозируемые выходные данные успешного выполнения тестов.

ATE_FUN.1.5C Результаты выполнения тестов разработчиком должны демонстрировать, что каждая проверенная функция безопасности выполнялась в соответствии со спецификациями.

ATE_FUN.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

3.5.2.6.4 ATE_IND.2 Выборочное независимое тестирование

ATE_IND.2.1D Разработчик должен представить ОО для тестирования.

ATE_IND.2.1C ОО должен быть пригоден для тестирования.

ATE_IND.2.2C Разработчик должен представить набор ресурсов, эквивалентных использованным им при функциональном тестировании ФБО.

ATE_IND.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ATE_IND.2.2E Оценщик должен протестировать необходимое подмножество ФБО, чтобы подтвердить, что ОО функционирует в соответствии со спецификациями.

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

3.5.2.7 Оценка уязвимостей (AVA)

3.5.2.7.1 AVA_CCA.1 Анализ скрытых каналов

AVA_CCA.1.1D Разработчик должен провести поиск скрытых каналов для каждой политики управления информационными потоками.

AVA_CCA.1.2D Разработчик должен представить документацию анализа скрытых каналов.

AVA_CCA.1.1C Документация анализа должна идентифицировать скрытые каналы и содержать оценку их пропускной способности.

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

AVA_CCA.1.3C Документация анализа должна содержать описание всех предположений, сделанных в процессе анализа скрытых каналов.

AVA_CCA.1.4C Документация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного варианта сценария.

AVA_CCA.1.5C Документация анализа должна содержать описание наиболее опасного варианта сценария использования каждого идентифицированного скрытого канала.

AVA_CCA.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_CCA.1.2E Оценщик должен подтвердить, что результаты анализа скрытых каналов показывают, что ОО удовлетворяет функциональным требованиям.

AVA_CCA.1.3E Оценщик должен выборочно подтвердить правильность результатов анализа скрытых каналов, применяя тестирование.

3.5.2.7.2 AVA_MSU.2 Подтверждение правильности анализа

AVA_MSU.2.1D Разработчик должен представить руководства по применению ОО.

AVA_MSU.2.2D Разработчик должен задокументировать анализ руководств.

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

AVA_MSU.2.2C Руководства должны быть полны, понятны, непротиворечивы и обоснованы.

AVA_MSU.2.3C Руководства должны содержать список всех предположений относительно среды эксплуатации.

AVA_MSU.2.4C Руководства должны содержать список всех требований к внешним мерам безопасности (включая внешний контроль за процедурами, физическими мерами и персоналом).

AVA_MSU.2.5C Документация анализа должна демонстрировать, что руководства полны.

AVA_MSU.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

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

AVA_MSU.2.3E Оценщик должен сделать независимое заключение, что использование руководств позволяет выявить все опасные состояния.

AVA_MSU.2.4E Оценщик должен подтвердить, что документация анализа показывает обеспечение руководствами безопасного функционирования во всех режимах эксплуатации ОО.

3.5.2.7.3 AVA_SOF.1 Оценка стойкости функции безопасности ОО

AVA_SOF.1.1D Разработчик должен выполнить анализ стойкости функции безопасности ОО для каждого механизма, идентифицированного в ЗБ как имеющего утверждение относительно стойкости функции безопасности ОО.

AVA_SOF.1.1C Для каждого механизма, имеющего утверждение относительно стойкости функции безопасности ОО, анализ должен показать, что ее стойкость достигает или превышает минимальный уровень стойкости, определенный в ПЗ/ЗБ.

AVA_SOF.1.2C Для каждого механизма, имеющего утверждение относительно конкретной стойкости функции безопасности ОО, анализ должен показать, что ее стойкость достигает или превышает конкретный показатель, определенный в ПЗ/ЗБ.

AVA_SOF.1.1E  Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_SOF.1.2E  Оценщик должен подтвердить, что утверждения относительно стойкости корректны.

3.5.2.7.4 AVA_VLA.3 Умеренно стойкий

AVA_VLA.3.1D Разработчик должен выполнить и задокументировать анализ поставляемых материалов ОО по поиску путей, которыми пользователь может нарушить ПБО.

AVA_VLA.3.2D Разработчик должен задокументировать местоположение идентифицированных уязвимостей.

AVA_VLA.3.1C Документация должна показать для всех идентифицированных уязвимостей, что ни одна из них не может быть использована в предполагаемой среде ОО.

AVA_VLA.3.2C Документация должна содержать строгое обоснование, что ОО с идентифицированными уязвимостями является стойким к явным нападениям проникновения.

AVA_VLA.3.3C Свидетельство должно показать, что поиск уязвимостей является систематическим.

AVA_VLA.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_VLA.3.2E Оценщик должен провести тестирование проникновения, основанное на анализе уязвимостей, выполненном разработчиком, для обеспечения учета идентифицированных уязвимостей.

AVA_VLA.3.3E Оценщик должен выполнить независимый анализ уязвимостей.

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

AVA_VLA.3.5E Оценщик должен сделать независимое заключение, что ОО является стойким к нападениям проникновения, выполняемым нарушителем, обладающим умеренным потенциалом нападения.

3.6 Обоснование

3.6.1 Обоснование целей безопасности

3.6.1.1 Обоснование целей безопасности для ОО

O.ACCEESS Посредничество в предоставлении доступа. Данная цель безопасности необходима для противодействия угрозам T.ISPOOF, T.SSPOOF, T.NATTACK, T.DCORRUPT и T.EVAL.

O.ADMINДоступ администратора. Данная цель безопасности необходима для противодействия угрозам T.LACCESS, T.ISPOOF, T.SSPOOF и T.DCORRUPT.

O.ACCOUNTКонтроль действий отдельных пользователей. Данная цель безопасности необходима для противодействия угрозе T.LACCESS.

O.PROTECTСамозащита ОО. Данная цель безопасности необходима для противодействия угрозам T.DCORRUPT, T.AUTH и T.CRASH.

O.ACCOUNTАудит. Данная цель безопасности необходима для противодействия угрозам T.NATTACK, T.AUDIT и T.DCORRUPT.

3.6.1.2 Обоснование целей безопасности для среды

O.INSTALL Средства контроля инсталляции и эксплуатации. Данная цель безопасности необходима для противодействия угрозам T.INSTALL и T.OPERATE.

O.SECURE Контроль физического доступа к ОО. Данная цель безопасности необходима для противодействия угрозам T.INSHARE и T.INALL.

O.TRAIN Обучение. Данная цель безопасности необходима для противодействия угрозам T.SERVICES, T.COMMS и T.INSHARE.

O.SUPPORT Сопровождение. Данная цель безопасности необходима для противодействия угрозе T.OPERATE.

3.6.2 Обоснование требований безопасности

3.6.2.1 Обоснование функциональных требований 

FDP_ACC.2Полное управление доступом Данный компонент выбран для обеспечения базовых определений функций управления доступом ОО. Он непосредственно поддерживает цель безопасности O.ACCESS– посредничество в предоставлении доступа.

FDP_ACF.1Управление доступом на основе атрибутов безопасности. Данный компонент выбран для обеспечения функций управления доступом ОО. Он непосредственно поддерживает цель безопасности O.ACCESS– посредничество в предоставлении доступа.

FDP_IFC.2Полное управление информационными потоками. Данный компонент выбран для обеспечения постоянной доступности всех сервисов внешнего информационного обмена, предоставляемых ОО, посредством управления информационными потоками. Он поддерживает цель безопасности O.ACCESS.

FDP_IFF.1Простые атрибуты безопасности. Информация и субъекты информационного обмена должны иметь атрибуты безопасности, с учетом которых ОО осуществляет функцию управления информационными потоками. Данный компонент специфицирует также основные реализуемые правила и описывает, как вводятся атрибуты безопасности. Он поддерживает цель безопасности O.ACCESS

FDP_ITC.2Импорт данных пользователей с атрибутами безопасности. Данный компонент выбран для обеспечения возможности импорта пользовательских данных и однозначной ассоциации их с атрибутами безопасности пользователя. Он поддерживает цель безопасности O.ACCOUNT.

FDP_RIP.2Полная защита остаточной информации. Данный компонент выбран для того, чтобы избежать получения пользователем данных, обрабатываемых ОО, доступ к которым не санкционирован явно. Данный компонент поддерживает цель безопасности O.ACCESS.

FDP_SDI.2Мониторинг целостности хранимых данных и предпринимаемые действия. Данный компонент выбран для обеспечения контроля целостности программной и информационной частей ОО. Он поддерживает цели безопасности O.PROTECT и O.AUDIT.

FIA_AFL.1Обработка отказов аутентификации. Данный компонент выбран для реагирования на повторные попытки нападения на ОО, особенно на попытки угадать идентификаторы и аутентификационные данные. Он непосредственно поддерживает цели безопасности O.PROTECT, а также O.ADMIN и O.ACCOUNT.

FDP_ATD.1Определение атрибутов пользователя. Данный компонент выбран для того, чтобы установить поддерживаемые ОО для каждого пользователя атрибуты безопасности. Поддерживает цели безопасности O.ACCESS и O.ACCOUNT.

FIA_SOS.1Верификация секретов. Данный компонент выбран для того, чтобы установить требования к стойкости паролей, используемых для аутентификации пользователя. Поддерживает цели безопасности O.ACCESS, O.ADMIN и O.ACCOUNT.

FIA_UAU.1Выбор момента аутентификации. Данный компонент выбран для определения необходимости и момента времени аутентификации пользователя в соответствии с политикой безопасности. Поддерживает непосредственно цель безопасности O.ACCOUNT, а также O.ACCESS.

FIA_UAU.3Аутентификация, защищенная от подделок. Данный компонент выбран для того, чтобы ОО мог обнаружить и предотвратить использование фальсифицированных или несанкционированно скопированных аутентификационных данных пользователем. Поддерживает цели безопасности O.ACCOUNT и O.ACCESS.

FIA_UAU.5Сочетание механизмов аутентификации. Данный компонент выбран для обеспечения применения пользователями различных механизмов аутентификации в особых случаях. Непосредственно поддерживает цель безопасности O.ACCOUNT, а также O.ADMIN и O.ACCESS.

FIA_UID.2Идентификация до любых действий пользователя. Данный компонент выбран для определения условий, при которых от пользователей должна требоваться собственная аутентификация до выполнения при посредничестве ОО каких-либо других действий от имени пользователя. Компонент поддерживает цели безопасности O.ACCOUNT, O.ADMIN и O.ACCESS.

FPT_AMT.1Тестирование абстрактной машины. Данный компонент выбран для поддержки тестирования предположений безопасности базовой абстрактной машины, от которых зависит нормальное функционирование ОО. Тестирование осуществляется посредством периодического запуска тестирующих функций. Компонент поддерживает цели безопасности O.PROTECT и O.AUDIT.

FPT_FLS.1Сбой с сохранением безопасного состояния. Данный компонент выбран для того, чтобы ОО обеспечивал невозможность доступа к защищаемым ресурсам в случае его сбоя. Он непосредственно поддерживает цель безопасности O.PROTECT.

FPT_RCV.1Ручное восстановление. Данный компонент выбран для обеспечения автоматического возвращения ОО в штатное состояние в случае определенного сбоя, в соответствии с определенным набором сбоев. Он поддерживает цели безопасности O.ACCESS и O.ADMIN.

FPT_RVM.1Невозможность обхода ПБО. Данный компонент включен для обеспечения недоступности информационного обмена с внешним информационным пространством в обход ФБО до введения ФБО в действие. Поддерживает цель безопасности O.ACCESS.

FPT_SEP.1Отделение домена ФБО. Данный компонент включен для обеспечения защиты самого ОО от нападений со стороны субъектов, не являющихся доверенными. Кроме этого данный компонент необходим для ограничения доступа администратора только к средствам конфигурирования ФБО. Компонент поддерживает цель безопасности O.PROTECT– самозащита ОО и O.ADMIN– доступ администратора.

FPT_STM.1Надежные метки времени. Данный компонент включен для обеспечения требований по предоставлению надежных меток времени в процессе функционирования ОО. Поддерживает цели безопасности O.ACCESS и O.AUDIT

FPT_TDC.1 Взаимная согласованность данных ФБО. Данный компонент выбран для обеспечения непротиворечивости данных ФБО, реализованных в ОО, для возможного использования и интерпретации этих данных между ФБО и другими доверенными продуктами. Поддерживает цели безопасности O.ACCESS и O.AUDIT.

FPT_TST.1 Тестирование ФБО. Данный компонент выбран для того, чтобы обеспечить проверку правильности функционирования ФБО, включая верификацию целостности данных ФБО и выполняемого кода ФБО ОО. Поддерживает цели безопасности O.PROTECT и O.AUDIT.

FMT_MSA.1Управление атрибутами безопасности. Данный компонент включен для того, чтобы допустить ролевое участие пользователей для управления идентифицированными атрибутами безопасности. Принятие роли осуществляется в компоненте FMT_SMR.1. Поддерживает цели безопасности O.ACCESS и O.ADMIN.

FMT_MSA.3Инициализация статических атрибутов. Данный компонент содержит требования, чтобы ОО предоставлял возможность присвоения атрибутам безопасности значений по умолчанию, а также их замены начальными значениями. Поддерживает цели безопасности O.ACCESS и O.ADMIN.

FMT_MTD.1Управление данными ФБО. Данный компонент допускает уполномоченных пользователей в соответствии с их ролями к управлению данными ОО. Поддерживает цели безопасности O.ACCESS, O.ADMIN и O.AUDIT.

FMT_SMR.1Роли безопасности. Данный компонент предназначен для управления назначением различных ролей пользователям. Поддерживает цели безопасности O.ACCESS и O.ADMIN.

FAU_ARP.1Сигналы нарушения безопасности. Данный компонент включен для того, чтобы определить действия, предпринимаемые ФБО при обнаружении нарушения безопасности. Поддерживает цель безопасности O.ACCESS.

FAU_GEN.1 Генерация данных аудита. Данный компонент выбран для обеспечения конкретных типов регистрируемых событий, а также минимального содержания контрольных записей для ОО. Он непосредственно поддерживает цель безопасности O.AUDIT– аудит.

FAU_SAA.1 Анализ потенциального нарушения. Данный компонент требует наличия в ОО возможности обнаружения проникновения на основе установленного набора правил управления доступом ОО. Он непосредственно поддерживает цель безопасности O.AUDIT– аудит.

FAU_SAR.1 Просмотр аудита. Данный компонент требует наличия средств просмотра журнала аудита и указывает на использование данных аудита только уполномоченным администратором. Он непосредственно поддерживает цель безопасности O.AUDIT– аудит, а также O.ADMIN– доступ администратора.

FAU_SAR.3 Выборочный просмотр аудита. Данный компонент указывает на необходимость наличия ограниченного поиска и сортировки контрольных записей. Это требование имеет большое значение из-за большого объема контрольных данных. Компонент непосредственно поддерживает цель безопасности O.AUDIT– аудит.

FAU_SEL.1 Избирательный аудита. Данный компонент указывает на необходимость наличия в ОО необходимой избирательности событий аудита безопасности. Данное требование  предотвращает разрастание журнала аудита до таких размеров, когда он становится бесполезен. Он непосредственно поддерживает цель безопасности O.AUDIT– аудит.

FAU_STG.1 Защищенное хранение журнала аудита. Данный компонент включен для того, чтобы ОО обеспечивал защиту записей журнала аудита от несанкционированного удаления. Поддерживает цель безопасности O.AUDIT– аудит.

FAU_STG.4 Предотвращение потери данных аудита. Данный компонент определяет действия, обеспечиваемые ОО, в случае переполнения журнала аудита, с целью предотвращения потери данных аудита. Он важен для поддержки цели безопасности O.AUDIT – аудит, в отношении обеспечения относительной полноты контрольных записей.

FPR_ANO.1 Анонимность. Данный компонент необходим для обеспечения того, что пользователь может использовать внешние информационные ресурсы или услуги без раскрытия своих идентификаторов. Поддерживает цель безопасности O.ACCOUNT.

FPR_PSE.1 Применение псевдонимов. Данный компонент необходим для обеспечения того, что внутренний пользователь может использовать внешние ресурсы без раскрытия своего идентификатора, оставаясь, однако, ответственным за свои действия. Поддерживает цель безопасности O.ACCOUNT.

FPR_UNL.1 Невозможность ассоциации. Данный компонент необходим для обеспечения невозможности ассоциации запросов к ресурсам внешнего информационного пространства с тем или иным пользователем внутреннего информационного пространства. Поддерживает цель безопасности O.ACCOUNT.

FTP_ITC.1Доверенный канал передачи между ФБО. Данный компонент определяет правила создания доверенного канала между ОО и другими доверенными продуктами ИТ для выполнения операций, критичных по безопасности. Примером такой операции может служить процесс информационного обмена между удаленной консолью администратора и ОО. Поддерживает цель безопасности O.ACCESS, O.ADMIN и O.AUDIT.

3.6.2.2 Обоснование требований доверия

ОУД4, усиленный компонентами ADV_IMP.2 (Реализация ФБО), AVA_CCA.1 (Анализ скрытых каналов) и AVA_VLA.3 (Умеренно стойкий)3, выбран для обеспечения независимо подтверждаемого уровня доверия к безопасности выше среднего на основе всестороннего исследования продукта и процесса его разработки без существенного изменения технологии разработки. В данном случае конечному пользователю доступны все отчетные материалы о разработке. Оценивание продукта может проводиться совместно с поставщиком.

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

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

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

Выбранный ОУД удовлетворяет всем функциональным зависимостям и не противоречит предполагаемой среде угроз.

ЗАКЛЮЧЕНИЕ

Целью дипломного проекта является Разработка профиля защиты для средства контентного анализа.

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

В результате этого был разработан новый профиль защиты в соответствии с требованиями ИСО/МЭК 15408 и РД Безопасность информационных технологий. Положение по разработке профилей защиты и заданий по безопасности. Гостехкомиссия России, 2003 год.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

  1.  ИСО/МЭК 15408 (все части) Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий.
  2.  Стандарт Банка России СТО БР ИББС-1.0-2010
  3.  ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения.;
  4.  Титоренко Г.А. Автоматизированные информационные технологии в экономике. – М.: ЮНИТИ, 2003 г.;
  5.  Титоренко Г.А. Информационные системы в экономике. – М.: ЮНИТИ-ДАНА, 2007 г.;
  6.  В.Сердюк.  Ахиллесова пята банков. - "Бухгалтерия и банки", 2007, N 3;
  7.  Ясенев В.Н. информационная безопасность в экономических системах: Учебное пособие – Н. Новгород: Изд-во ННГУ, 2006, 253 с.
  8.  Ю.Б. Борисов. Разработка модели угроз ИБ системы электронных расчетов организаций банковской системы РФ.- УКД 004.056;
  9.  В.В.Бабкин. Модель нарушителя информационной безопасности - превенция появления самого нарушителя. "Управление в кредитной организации", 2006, N 5;
  10.  Мельников Ю., Теренин А. Возможности нападения на информационные системы банка из Интернета и некоторые способы отражения этих атак // Банковские технологии, 2003. - N1-2.
  11.  ИСО/МЭК 15443 (все части) Информационная технология. Методы и средства обеспечения безопасности. Основы доверия к безопасности информационных технологий.
  12.  Симонов С. Анализ рисков, управление рисками // Jet Info. № 1. 1999.
  13.  ИСО/МЭК 17799  Информационная технология. Свод правил по управлению безопасностью информации.
  14.  Фабричная А.С. Учет и статистика. 2008. № 11. С. 178-183.
  15.  Сердюк В.А. T-Comm: Телекоммуникации и транспорт. 2009. № S. С. 24-26.
  16.  Гайкович Ю.В., Першин А.С. Безопасность электронных банковских систем. - М.: Менатеп - Информ, 2006.
  17.  Шаваев А. Концептуальные основы обеспечения безопасности негосударственных объектов экономики. - М.: Академия экономической безопасности, 2009.
  18.  Губин С.В., Гожанский В. В., Актуальные вопросы эффективности и безопасности функционирования систем розничных платежей// Расчеты и операционная работа в коммерческом банке: материалы Межрегиональной банковской конференции - Саратов., № 7-8(61)/2008
  19.  Алавердов А.Р. Организация и управление безопасностью в кредитно-финансовых организациях / Московская финансовопромышленная академия. М., 2004 - 66 с.
  20.  Богданов А., Операционный риск и его влияние на устойчивую работу финансовой организации. // Банковские технологии, №1, 2010, с.39-43.
  21.  Введение в информационную безопасность: Учебное пособие для вузов / А.А. Малюк, В.С. Горбатов, В.И. Королев и др.; Под ред. В.С. Горбатова. – М.: Горячая линия – Телеком, 2011. – 288 с.: ил.
  22.  Стандарты информационной безопасности: курс лекций: учебное пособие / Второе издание / В.А. Галатенко. Под редакцией академика РАН В.Б Бетелина / - М.: ИНТУИТ.РУ «Интернет – университет Информационных технологий», 2010. – 264с.
  23.  Введение в защиту информации в автоматизированных системах: Учебное пособие для вузов. – 2–е  издание. – М.: Горячая линия – Телеком, 2004. – 147с.; ил.
  24.  Аграновский А.В., Мамай В.И., Назаров И.Г., Язов Ю.К. Основы технологий проектирования систем защиты информации в информационно – телекоммуникационных системах: Монография. Ростов – на – Дону. Изд – во СКНЦ ВШ, 2006. 260 с.: ил.
  25.  Теоретические основы компьютерной безопасности: учеб. пособие для студентов высш. учеб. заведений / А.А. Грушо, Э.А. Применко, Е.Е. Тимонина. – М. : Издательский центр «Академия», 2009. – 272 с.
  26.  Комплексная система защиты информации на предприятии : учеб. пособие для студентов высш. учеб. заведений / В.Г. Грибунин, В.В.Чудовский. – М. : Издательский центр «Академия», 2009. – 416 с.
  27.  Основы защиты информации : В.А. Герасименко, А.А. Малюк : Москва 1997г.
  28.  Информационная безопасность открытых систем: Учебник для вузов. В 2-х томах. Том 1 – Угрозы, уязвимости и подходы к защите / С.В. Запечников, Н.Г. Милославская, А.И. Толстой, Д.В. Ушаков. - М.: Горячая линия – Телеком, 2006. – 536с.; ил.
  29.  Информационная безопасность открытых систем: Учебник для вузов. В 2-х томах. Том 2 – Средства защиты в сетях / С.В. Запечников, Н.Г. Милославская, А.И. Толстой, Д.В. Ушаков. - М.: Горячая линия – Телеком, 2008. – 558с.; ил.
  30.  Основы информационной безопасности автоматизированных банковских систем. Учебное пособие. А.П. Курило, Н.Г. Милославская, С.Ф. Михайлов, А.И. Толстой.- М. МИФИ, 2001.
  31.  Теоретические основы банковской безопасности (российский и международный опыт). Алексеева Д.Г. Монография. – М., 2010.
  32.  «Банковские технологии». Журнал. 05/2012. Как снизить банковские риски: IT и информационная безопасность.
  33.   «Банковские технологии». Журнал. 05/2012. Практическое использование DLP – системы Devicelock в корпоративной среде банка. Работа с журналами аудита и теневого копирования.
  34.  Аудит информационной безопасности. М. «БДЦ - пресс». 2006.

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


FDP_IFF.1.3


FDP_IFF.1.4


FDP_IFF.1.5

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


FDP_IFF.1.3


FDP_IFF.1.4


FDP_IFF.1.5

3 Если ОО предполагается использовать для обработки информации с грифом «совершенно секретно», то вместо компонента AVA_VLA.3 (Умеренно стойкий) автор ЗБ должен использовать компонент AVA_VLA.4 (Высокостойкий).

4 Если автор ЗБ усилил требования ОУД включением компонента AVA_VLA.4, то независимый анализ уязвимостей должен продемонстрировать противодействие ОО попыткам проникновения нарушителей с высоким потенциалом нападения.


 

А также другие работы, которые могут Вас заинтересовать

80889. Статус, полномочия Главы Муниципального Образовния и основания прекращения его полномочий 41.75 KB
  выборах либо входит в состав ПО МО с правом решающего голоса и исполняет полномочия его председателя либо возглавляет местную администрацию; 3 в случае избрания ПО МО исполняет полномочия его председателя; 4 не может одновременно исполнять полномочия председателя ПО МО и полномочия главы местной администрации; Глава МО в пределах полномочий: 1 представляет МО в отношениях с ОМС других МО ОГВ гражданами и организациями без доверенности действует от имени МО; 2 подписывает и обнародует в порядке установленном уставом МО нормативные...
80890. Процесс управления муниципальными услугами 44.09 KB
  К муниципальным услугам относится весь комплекс жилищнокоммунальных транспортных в пределах территории поселения бытовых торговых образовательных медицинских культурных досуговых и других услуг. К муниципальным услугам следует относить и такие как обеспечение общественного порядка обустройство и содержание территории обеспечение ее экологического и санитарного благополучия и т. Даже то что мы называем комплексным социальноэкономическим развитием МО означает не что иное как целенаправленное изменение ситуации в сторону...
80891. Организация и планирование работы местной администрации 43.83 KB
  Основным документом определяющим организацию деятельности местной администрации является ее регламент утверждаемый главой администрации. Наряду с регламентом работы администрации важную роль в организации ее деятельности играют нормативные документы регламентирующие деятельность отдельных структурных подразделений и исполнителей. В соответствии с положениями и профилем своей работы структурные подразделения администрации: курируют работу подведомственных предприятий организаций и учреждений; осуществляют сбор информации анализ...
80893. Муниципальное управление охраной здоровья населения 43.99 KB
  Муниципальная система здравоохранения МСЗ включает в себя располагающиеся на территории МО лечебнопрофилактические и иные учреждения системы здравоохранения находящиеся в муниципальной государственной или частной собственности а также органы муниципального управления охраной здоровья населения. Главная цель муниципальная система здравоохранения удовлетворение потребностей населения в услугах сферы здравоохранения отнесенных к предметам ведения местного самоуправления на уровне не ниже государственных минимальных социальных...
80894. Разработка прогноза социально-экономического развития муниципального образования 43.62 KB
  Система планирования комплексного социальноэкономического развития муниципального образования включает в себя прогнозирование текущее и стратегическое планирование. Бюджетный кодекс РФ 2004 года предусматривает обязательную разработку перспективного финансового плана развития муниципального образования на трехлетний среднесрочный период. Этот план разрабатывается на основе прогноза социальноэкономического развития территории на тот же период.
80895. Стратегическое планирование в Муниципальном Образовании 44.44 KB
  Недостаток опыта стратегического планирования комплексного подхода к определению целей и приоритетов перспективного развития муниципальных образований приводит к тому что разработанные концепции и стратегические планы иногда носят декларативный характер отсутствуют механизмы их реализации. В зависимости от стоящих задач концепции и стратегические планы бывают среднесрочные 3 5 лет и долгосрочные до 10 15 лет. Основные этапы разработки концепции комплексного социальноэкономического развития муниципального образования...
80896. Основные направления по противодействию коррупции государственных и муниципальных органах власти 45.12 KB
  Коррупция - злоупотребление служебным положением, дача взятки, получение взятки, злоупотребление полномочиями, коммерческий подкуп либо иное незаконное использование физическим лицом своего должностного положения вопреки законным интересам общества и государства в целях получения выгоды в виде денег, ценностей, иного имущества или услуг имущественного характера, иных имущественных прав для себя или для третьих лиц либо незаконное предоставление такой выгоды указанному лицу другими физическими лицами;
80897. Информационное обеспечение муниципального управления 45.52 KB
  Распоряжения главы администрации и его заместителей протоколы заседаний коллегии ведомости учета изданных мун. Население выражает свое отношение к дти мун. Общественные объединения граждан выражают отношение к деятельности мун.