понедельник, 12 декабря 2016 г.

Что защищать? О инвентаризации объектов защиты

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

Инвентаризация информационных систем.

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

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



Общий характер инвентаризации информационных систем. 

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

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

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

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

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

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

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


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

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

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


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

Кроме того, необходимо определиться с тем, что считать отдельным объектом системы, подлежащим защите? Отдельный компьютер?

Отдельный логический модуль? Если взять в качестве примера систему с трехзвенной архитектурой (клиент-сервер приложений-сервер данных), то в зависимости от особенностей, классификация может быть различной. Можно посчитать всю систему единым объектом, а можно каждое звено рассматривать отдельно (получив три объекта).

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

С чего начать: нормативные документы и круг респондентов.

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

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

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

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

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

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

Принципы и направления.

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

Принципы проведения инвентаризации.

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


Направления проведения инвентаризации.

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


Примерный объем собираемой информации.

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

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

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


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

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


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

По физическому размещению:

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

По аппаратному обеспечению:

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

По программному обеспечению (кроме уже указанных параметров):

  • производитель;
  • номер версии;
  • встроенные механизмы защиты;
  • статистика сбоев, если есть.

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

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

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


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


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


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

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

Контроль инвентаризации.

Данный раздел будет интересен трем категориям специалистов:

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

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

Предложим краткий конспект проведения такой проверки.

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

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

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

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

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

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

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

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

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

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

Место инвентаризации в жизненном цикле предприятия.

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

Классификация информационных систем.

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

Введение в классификацию ИС. Терминология и постановка задачи.

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

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

Субъектом будет выступать любой пользователь системы, ориентированный как на производственные или иные задачи, так и на поддержку самой системы (администратор).

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

Таким образом задача сводится к классификации:

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


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

Правда, реальность в данном вопросе более сложная. Проще всего на первый взгляд классифицировать субъектов, учитывая опыт, накопленный отделами по режиму (так называемыми "первыми отделами") советских предприятий. Однако в современном информационном пространстве необходимо учитывать не только общий уровень благонадежности пользователя, но и такие факторы как:
общая квалификация или способность работать в информационной системе, не внося в нее сбоев из-за человеческого фактора. Известна статистика нарушений информационной безопасности. Мы не будем приводить конкретных цифр - они меняются в зависимости от времени и агентства, производившего опрос. В любом случае, например, цифра, равная 1% нарушений, приемлемая для одной организации, может оказаться катастрофичной для другой;
подготовка пользователя в сфере информационной безопасности или осведомленность его в вопросах установленных процедур безопасности.

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

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

Основные регламенты классификации. 

Тем, кто начинает свое знакомство с информационной безопасностью, уже на первых стадиях ее изучения попадутся названия "Оранжевая книга", "Красная книга", Общие критерии (Common Criteria), ТСРЕС, ITSEC и др.

Все это критерии определения уровня безопасности систем. Наиболее известные из них следующие:
Оранжевая книга (DoD 5200.28-STD - Trusted Computer Systems Evaluation Criteria) - выпущенные Министерством обороны США критерии оценки уровня безопасности компьютерных систем как таковых.
Красная книга (NCSC-TG-005 - Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria) - расширение этих критериев для случаев использования компьютерных систем в информационной сети.

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

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

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

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

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

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

Классификация информационных объектов.

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

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

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

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

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

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

Примерная модель классификации.

Таким образом можно предложить следующую модель для классификации информационных объектов. Для удобства дальнейших ссылок на класс категории рекомендуем сразу ввести буквенно-цифровое обозначение (в приведенном примере литера "Д" означает "доступность", "Ц" - "целостность"* "К" - "конфиденциальность", цифры возрастают с убыванием значимости критерия).

По наличию (доступность)
Критическая - без нее работа субъекта останавливается (ДО).
Очень важная - без нее можно работать, но очень короткое время (Д1).

Важная - без нее можно работать некоторое время, но рано или поздно она понадобится (Д2).
Полезная - без нее можно работать, но ее использование экономит ресурсы (ДЗ).
Несущественная - устаревшая или неиспользуемая, не влияющая на работу субъекта (Д4).
Вредная - ее наличие требует обработки, а обработка ведет к расходу ресурсов, не давая результатов либо принося ущерб (Д5). (В определенных организациях может понадобиться и такой параметр.)

По несанкционированной модификации (целостность)

  • Критическая - ее несанкционированное изменение приведет к неправильной работе всего субъекта или значительной его части; последствия модификации необратимы (ЦО).
  • Очень важная - ее несанкционированное изменение приведет к неправильной работе субъекта через некоторое время, если не будут предприняты некоторые действия; последствия модификации необратимы (Ц1).
  • Важная - ее несанкционированное изменение приведет к неправильной работе части субъекта через некоторое время, если не будут предприняты некоторые действия; последствия модификации обратимы (Ц2).
  • Значимая - ее несанкционированное изменение скажется через некоторое время, но не приведет к сбою в работе субъекта; последствия модификации обратимы (ЦЗ).
  • Незначимая - ее несанкционированное изменение не скажется на работе системы (Ц4).


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

По разглашению (конфиденциальность)

  • Критическая - разглашение информации приведет к краху работы субъекта или к очень значительным материальным потерям (КО).
  • Очень важная - разглашение приведет к значительным материальным потерям, если не будут предприняты некоторые действия (К1).
  • Важная - разглашение приведет к некоторым материальным (может быть, косвенным) или моральным потерям, если не будут предприняты некоторые действия (К2).
  • Значимая - приносит скорее моральный ущерб, может быть использована только в определенных ситуациях (КЗ).
  • Малозначимая - может принести моральный ущерб в очень редких случаях (К4).
  • Незначимая - не влияет на работу субъекта (К5).


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

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

Жизненный цикл обычно можно обозначить следующими стадиями.

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

Классификация средств обработки информации: стандарт CCITSE. Краткий обзор стандарта.

Теперь рассмотрим вопросы классификации средств обработки информации. В разделе "Введение в классификацию ИС" этой главы, было упомянуто о множестве существующих классификаторов, в том числе и российских.
Подробно с этими документами читатель может ознакомиться самостоятельно. Из их числа несомненно выделяются:
  • CCITSE (Common Criteria for Information Technology Security Evaluation — Общие критерии оценки безопасности информационных систем);
  • наследник британского стандарта BS7799 — стандарт ISO 17799 (International Security Standard — Международный стандарт по безопасности).
Нам хотелось бы остановиться на первом документе по ряду причин. Во-первых, это качественно разработанный и продолжающий совершенствоваться документ, в создании которого принимают участие высокопрофессиональные специалисты из Великобритании, Германии, Канады, Нидерландов, США и Франции. Во-вторых, по оценкам многих специалистов, этот проект может стать единым стандартом для документов такого характера, заменив собой существующие национальные стандарты. Что касается ISO 17799, то, к сожалению, в настоящее время его нет в свободном доступе в Интернете, поэтому его обсуждение с читателями было бы затруднено.
Мы за основу взяли версию 2.1 документа CCITSE [СС1], которая была доступна в Интернете на момент создания книги. Сравнивая ее с предыдущей версией, можно предположить, что основные характеристики документа сформированы и будут перенесены в более поздние версии.
Документ состоит из трех частей, общим размером более 600 страниц. Первая часть — "Введение и общая модель", вторая — "Требования к функциональности безопасности", третья — "Требования к достоверности безопасности".
Подробно описать весь документ на страницах данной книги невозможно, более того, не каждому специалисту он целиком и понадобится. Отметим основные параметры, по которым выполняется оценка, чтобы читатели имели представление, как такая классификация проводится и, возможно, при необходимости смогли создать свою собственную, выбрать подходящую или хотя бы ориентироваться в документе такого класса.
В первой части документа говорится, что данные критерии являются составной частью общего процесса оценки наряду с такими понятиями, как методика оценки и схема оценки, которые не входят в сферу рассмотрения данного документа. Вводится понятие предмета оценки (англ. Target of Evaluation — TOE), в качестве примера к которому отнесены операционная система, компьютерная сеть, распределенная система или приложение. Также указаны ссылки на понятия конфиденциальности, целостности и доступности. Кроме того здесь представлены принципы формирования целей информационной безопасности для выбора и определения требований и создания спецификаций для продуктов и систем.

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

Требования к функциональности безопасности.


Данный раздел основан на части 2 стандарта CCITSE.

Комментариев нет:

Отправить комментарий