question:Опираясь на текст ниже ответь на вопросы 1. Что такое среда разработки? Приведите примеры. 2. Опишите процесс передачи данных между ФБО. 3. Что такое атрибут безопасности? 4. Что такое политика функции безопасности? 5. Что такое дерево вызовов? 6. Что такое модульная декомпозиция? Приведите примеры. 30 7. Что такое выходные данные управления конфигурацией. 8. Дайте определение «документация по применению управления конфигурацией». Задание 1. Ознакомиться с представленными пунктами ГОСТ Р ИСО/МЭК 15408-1-2012 1. Область применения Настоящий стандарт устанавливает основные понятия и принципы оценки безопасности ИТ, а также определяет общую модель оценки, которой 3 посвящены различные части стандарта, предназначенного в целом для использования в качестве основы при оценке характеристик безопасности продуктов ИТ. В данном стандарте представлен краткий обзор и описание всех частей ИСО/МЭК 15408; определены термины и сокращения, используемые во всех частях ИСО/МЭК 15408; установлено основное понятие объекта оценки (ОО), контекста оценки, описана целевая аудитория, которой адресованы критерии оценки. Представлены основные положения, необходимые для оценки продуктов ИТ. В данном стандарте определяются различные операции, посредством которых функциональные компоненты и компоненты доверия, приведенные в ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3, могут быть доработаны для конкретного применения путем использования разрешенных операций. В данном стандарте определяются ключевые понятия профилей защиты (ПЗ), пакетов требований безопасности, а также рассматриваются вопросы, связанные с утверждениями о соответствии; описываются выводы и результаты оценки. В данном стандарте даны инструкции по спецификации заданий по безопасности (ЗБ) и описание структуры компонентов в рамках всей модели. Также дана общая информация о методологии оценки, приведенной в ИСО/МЭК 18045, и области действия системы оценки. 2. Нормативные ссылки Следующие нормативные документы* необходимы для применения настоящего стандарта. Для датированных ссылок применяется только то издание, на которое дается ссылка. Для недатированных ссылок применяется самое последнее издание нормативного ссылочного документа (включая любые изменения). ИСО/МЭК 15408-2 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных 4 технологий. Часть 2. Функциональные компоненты безопасности ИСО/МЭК 15408-3 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности ИСО/МЭК 18045 Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий. 3. Термины и определения Применительно к настоящему документу используются следующие термины и определения. Примечание - Данный раздел содержит только те термины, которые используются во всем тексте ИСО/МЭК 15408. Некоторые комбинации общих терминов, используемые в ИСО/МЭК 15408 и не вошедшие в данный раздел, поясняются непосредственно в тексте по месту использования. 3.1 Термины и определения, общие для всех частей ИСО/МЭК 15408 3.1.1 негативные действия (adverse actions): Действия, выполняемые источником угрозы по отношению к активам. 3.1.2 активы (assets): Сущности, предположительно представляющие ценность для владельца ОО. 3.1.3 назначение (assignment): Спецификация определенного параметра в компоненте или требовании. 3.1.4 доверие (assurance): Основание для уверенности в том, что ОО отвечает конкретным ФТБ. 3.1.5 потенциал нападения (attack potential): Мера усилий, затрачиваемых при атаке на ОО, выраженная в показателях компетентности, ресурсов и мотивации нарушителя. 5 3.1.6 усиление (augmentation): Добавление одного или нескольких требований к пакету. 3.1.7 аутентификационные данные (authentication data): Информация, используемая для верификации предъявленного идентификатора пользователя. 3.1.8 уполномоченный пользователь (authorised user): Пользователь ОО, которому в соответствии с ФТБ разрешено выполнять некоторую операцию. 3.1.9 класс (class): Совокупность семейств, объединенных общим назначением. 3.1.10 четкий (coherent): Логически упорядоченный и имеющий понятное значение. Примечание - В случае с документацией это относится как к имеющемуся тексту, так и к структуре документа в том смысле, понятен ли он его целевой аудитории. 3.1.11 полный (complete): Свойство, обеспеченное наличием всех необходимых частей некоторой сущности. Примечание - По отношению к документации это означает, что вся необходимая информация отражена в документации на уровне детализации, не требующем на данном уровне абстракции дальнейших пояснений. 3.1.12 компонент (component): Наименьшая выбираемая совокупность элементов, на которой могут основываться требования. 3.1.13 составной пакет доверия (composed assurance package): Пакет доверия, представляющий некоторое положение на предопределенной составной шкале доверия. 3.1.14 подтвердить (confirm): Декларировать, что что-то детально проверено с независимым определением достаточности. Примечание - Требуемый уровень строгости зависит от типа рассматриваемого предмета. Данный термин применим только к действиям оценщика. 6 3.1.15 внешняя связность (connectivity): Свойство ОО, позволяющее ему взаимодействовать с сущностями ИТ, внешними по отношению к ОО. Примечание - Это взаимодействие включает обмен данными по проводным или беспроводным средствам на любом расстоянии, в любой среде или при любой конфигурации. 3.1.16 непротиворечивый (consistent): Характеризует связь между двумя или более сущностями, указывая, что между этими сущностями нет никаких явных противоречий. 3.1.17 противостоять (counter): Характеризует противостояние некоторому нападению, при котором негативные последствия реализации некоторой конкретной угрозы уменьшаются, но не обязательно полностью ликвидируются. 3.1.18 демонстрируемое соответствие (demonstrable conformance): Связь между ЗБ и ПЗ, при которой ЗБ обеспечивает решение общей проблемы безопасности, определенной в ПЗ. Примечание - ПЗ и ЗБ могут содержать совершенно разные утверждения, относящиеся к разным сущностям, использующие разные понятия и т.д. Демонстрируемое соответствие также является подходящим для типа ОО, для которого уже существует несколько сходных ПЗ, позволяя разработчику ЗБ утверждать о соответствии одновременно всем этим ПЗ и, таким образом, экономить трудозатраты. 3.1.19 демонстрировать (demonstrate): Предоставить заключение, полученное в процессе анализа, который является менее строгим, чем "доказательство" ("proof"). 3.1.20 зависимость (dependency): Соотношение между компонентами, при котором, если некоторое требование, основанное на зависимом компоненте, включается в ПЗ, ЗБ или пакет, то и требование, основанное на компоненте, от которого зависит указанный выше компонент, должно быть, как правило, включено в ПЗ, ЗБ или пакет. 3.1.21 описывать (describe): Представить конкретные подробности о 7 некоторой сущности. 3.1.22 делать заключение (determine): Подтвердить некоторое заключение, основанное на независимом анализе для достижения этого заключения. Примечание - Использование данного термина подразумевает выполнение действительно независимого анализа, обычно в условиях отсутствия какого бы то ни было предшествующего анализа. Термин "делать заключение" отличается от терминов "подтверждать" ("confirm") или "верифицировать" ("verify"), которые предполагают необходимость проверки ранее выполненного анализа. 3.1.23 среда разработки (development environment): Среда, в которой осуществляется разработка ОО. 3.1.24 элемент (element): Неделимое изложение некоторой потребности в безопасности. 3.1.25 обеспечивать (ensure): Гарантировать сильную причинноследственную связь между некоторым действием и его последствиями. Примечание - Когда этому термину предшествует термин "способствовать", то это указывает, что одно данное действие не полностью определяет последствия. 3.1.26 оценка (evaluation): Оценивание ПЗ, ЗБ или ОО по определенным критериям. 3.1.27 оценочный уровень доверия (evaluation assurance level): Набор требований доверия, представляющий некоторое положение на предопределенной шкале доверия и составляющий пакет доверия. 3.1.28 орган оценки (evaluation authority): Организация, устанавливающая стандарты и контролирующая качество оценок, проводимых организациями в пределах определенного сообщества, и обеспечивающая реализацию ИСО/МЭК 15408 для данного сообщества посредством системы оценки. 3.1.29 система оценки (evaluation scheme): Административно- 8 правовая структура, в рамках которой в определенном сообществе органы оценки применяют ИСО/МЭК 15408. 3.1.30 исчерпывающий (exhaustive): Характеристика методического подхода, используемого применительно к проведению анализа или деятельности в соответствии с точно изложенным планом. Примечание - Этот термин используют применительно к проведению анализа или другой деятельности. Аналогичен термину "систематический" ("systematic"), но более строгий, так как указывает не только на то, что в соответствии с некоторым точно изложенным планом проведения анализа или другой деятельности был применен методический подход, но также и на то, что этот план достаточен для обеспечения проведения исследования по всем возможным направлениям. 3.1.31 объяснять (explain): Предоставить аргументы, содержащие основания для выбора хода предпринимаемых действий. Примечание - Данный термин отличается от терминов "описывать" ("describe") и "демонстрировать" ("demonstrate"). Предназначен для ответа на вопрос "Почему?" без попытки аргументировать, что ход предпринимаемых действий обязательно оптимален. 3.1.32 расширение (extension): Добавление в ЗБ или ПЗ функциональных требований, не содержащихся в ИСО/МЭК 15408-2, и/или требований доверия, не содержащихся в ИСО/МЭК 15408-3. 3.1.33 внешняя сущность (external entity): Человек или ИТ-сущность, взаимодействующие с ОО из-за пределов границ ОО. Примечание - В качестве внешней сущности может также рассматриваться пользователь ОО. 3.1.34 семейство (family): Совокупность компонентов, которые направлены на достижение сходной цели, но отличаются акцентами или строгостью. 3.1.35 формальный (formal): Выраженный на языке с ограниченным синтаксисом и определенной семантикой, основанной на установившихся 9 математических понятиях. 3.1.36 документация руководств (guidance documentation): Документация, описывающая поставку, установку, конфигурирование, эксплуатацию, управление и/или использование ОО. 3.1.37 идентификатор (identity): Представление, однозначно идентифицирующее сущность (например, пользователя, процесс или диск) в контексте конкретного ОО. Примечание - Примером такого представления может быть строка символов. Для человека-пользователя таким представлением может быть полное или сокращенное имя или (также уникальный) псевдоним. 3.1.38 неформальный (informal): Выраженный на естественном языке. 3.1.39 передача между ФБО (inter TSF transfers): Передача данных между ОО и функциональными возможностями безопасности других доверенных продуктов ИТ. 3.1.40 внутренний канал связи (internal communication channel): Канал связи между разделенными частями ОО. 3.1.41 передача в пределах ОО (internal TOE transfer): Передача данных между разделенными частями ОО. 3.1.42 внутренне непротиворечивый (internally consistent): Характеризует отсутствие очевидных противоречий между любыми аспектами сущности. Примечание - Применительно к документации это означает, что в ней не может быть изложено что-либо, воспринимаемое как противоречащее чему-то другому. 3.1.43 итерация (iteration): Использование компонента для выражения двух или более отдельных требований. 3.1.44 логическое обоснование (justification): Анализ, приводящий к получению заключения. Примечание - Термин "логическое обоснование" является более строгим, чем термин "демонстрация". Этот термин требует точных и 10 подробных объяснений каждого шага логических суждений. 3.1.45 объект (object): Пассивная сущность в пределах ОО, которая содержит или получает информацию и над которой субъекты выполняют операции. 3.1.46 операция (над компонентом) (operation): Модификация или повторное использование компонента. Примечание - Разрешенными операциями над компонентами являются назначение, итерация, уточнение и выбор. 3.1.47 операция (над объектом) (operation): Определенный тип действия, выполняемого субъектом по отношению к объекту. 3.1.48 среда функционирования (operation environment): Среда, в которой функционирует ОО. 3.1.49 политика безопасности организации (organisational security policies): Совокупность правил, процедур или руководящих принципов в области безопасности для некоторой организации. Примечание - Политика может быть также отнесена к какой-либо определенной среде функционирования. 3.1.50 пакет (package): Именованная совокупность функциональных требований безопасности или требований доверия к безопасности. Примечание - Примером пакета может служить "ОУДЗ". 3.1.51 оценка профиля защиты (protection profile evaluation): Оценивание ПЗ по определенным критериям. 3.1.52 профиль защиты (protection profile): Независимое от реализации изложение потребностей в безопасности для некоторого типа ОО. 3.1.53 доказывать (prove): Демонстрировать соответствие посредством формального анализа в математическом смысле. Примечание - Доказательство должно быть полностью строгим во всех отношениях. Обычно термин "доказывать" используют, когда необходимо показать соответствие между двумя представлениями ФБО на высоком уровне строгости. 11 3.1.54 уточнение (refinement): Добавление деталей в компонент. 3.1.55 роль (role): Предопределенная совокупность правил, устанавливающих допустимое взаимодействие между пользователем и ОО. 3.1.56 секрет (secret): Информация, которая должна быть известна только уполномоченным пользователям и/или ФБО для осуществления определенной ПФБ. 3.1.57 безопасное состояние (secure state): Состояние, при котором данные ФБО являются непротиворечивыми и ФБО продолжают корректно реализовывать ФТБ. 3.1.58 атрибут безопасности (security attribute): Характеристика субъектов, пользователей (включая внешние продукты ИТ), объектов, информации, сеансов и/или ресурсов, которые используются при определении ФТБ, и значения которых используются при осуществлении ФТБ. 3.1.59 политика функции безопасности (security function policy): Совокупность правил, описывающих конкретный режим безопасности, реализуемый ФБО, и выраженных в виде совокупности ФТБ. 3.1.60 цель безопасности (security objective): Изложенное намерение противостоять установленным угрозам и/или удовлетворять установленной политике безопасности организации и/или предположениям. 3.1.61 проблема безопасности (security problem): Изложение, которое в формализованном виде определяет характер и масштабы безопасности, которую должен обеспечивать ОО. Примечание - Данное изложение содержит сочетание: - угроз, которым должно быть обеспечено противостояние со стороны ОО; - ПБОр, осуществляемых ОО, и - предположений, которые определены для ОО и его среды функционирования. 3.1.62 требование безопасности (security requirement): Требование, 12 изложенное на стандартизованном языке и направленное на достижение целей безопасности для ОО. 3.1.63 задание по безопасности (security target): Зависимое от реализации изложение потребностей в безопасности для конкретного идентифицированного ОО. 3.1.64 выбор (selection): Выделение одного или нескольких пунктов из перечня в компоненте. 3.1.65 полуформальный (semiformal): Выраженный на языке с ограниченным синтаксисом и определенной семантикой. 3.1.66 специфицировать (specify): Предоставить конкретные подробности о некоторой сущности в строгой и точной форме. 3.1.67 строгое соответствие (strict conformance): Иерархическая связь между ПЗ и ЗБ, когда все требования из ПЗ также присутствуют в ЗБ. Примечание - Эта связь может быть определена как "ЗБ должен содержать все утверждения, которые присутствуют в ПЗ, но может содержать больше". Предполагается, что строгое соответствие будет применяться для обязательных требований, которые могут быть выполнены единственным способом. 3.1.68 оценка задания по безопасности (security target evaluation): Оценивание ЗБ по определенным критериям. 3.1.69 субъект (subject): Активная сущность в ОО, выполняющая операции над объектами. 3.1.70 объект оценки (target of evaluation): Совокупность программного, программно-аппаратного и/или аппаратного обеспечения, возможно сопровождаемая руководствами. 3.1.71 источник угрозы (threat agent): Сущность, которая негативно воздействует на активы. 3.1.72 оценка ОО (TOE evaluation): Оценивание ОО по определенным критериям. 3.1.73 ресурс ОО (TOE resource): Все, что может быть использовано 13 или потреблено ОО. 3.1.74 функциональные возможности безопасности ОО (TOE security functionality): Совокупность функциональных возможностей всего аппаратного, программного и программно-аппаратного обеспечения ОО, которые необходимо использовать для корректной реализации ФТБ. 3.1.75 прослеживать или сопоставлять (trace): Выполнять неформальный анализ соответствия между двумя сущностями с минимальным уровнем строгости. 3.1.76 передача за пределы ОО (transfers outside TOE): Опосредованная ФБО передача данных сущностям, не контролируемым ФБО. 3.1.77 трансляция (translation): Описание процесса изложения требований безопасности на стандартизованном языке. Примечание - Использование термина "трансляция" не является буквальным и не подразумевает, что каждое ФТБ, выраженное на стандартизованном языке, может быть также обратно транслировано к целям безопасности. 3.1.78 доверенный канал (trusted channel): Средство взаимодействия между ФБО и удаленным доверенным продуктом ИТ, обеспечивающее необходимую для этого степень уверенности в безопасности. 3.1.79 доверенный продукт ИТ (trusted IT product): Продукт ИТ, отличный от ОО, для которого имеются свои функциональные требования, организационно скоординированные с ОО, и который, как предполагается, реализует свои функциональные требования корректно. Примечание - Примером доверенного продукта ИТ является продукт, который был отдельно оценен. 3.1.80 доверенный маршрут (trusted path): Средство взаимодействия между пользователем и ФБО, обеспечивающее необходимую для этого степень уверенности в безопасности. 3.1.81 данные ФБО (TSF data): Данные, необходимые для 14 функционирования ОО, на основе которых осуществляется реализация ФТБ. 3.1.82 интерфейс ФБО (TSF interface): Средства, через которые внешние сущности (или субъект в ОО, но за пределами ФБО) передают данные к ФБО, получают данные от ФБО и обращаются к сервисам ФБО. 3.1.83 данные пользователя (user data): Данные для пользователя, не влияющие на выполнение ФБО. 3.1.84 верифицировать (verify): Провести строгую детальную проверку с независимым определением ее достаточности. Примечание - См. также термин "подтверждать" (3.1.14). Термин "верифицировать" имеет более глубокий смысл. Он используется в контексте действий оценщика, когда требуются независимые усилия оценщика. 3.2 Термины и определения, относящиеся к классу ADV Примечание - Приведенные ниже термины используются в формулировках требований для отражения внутренней структуризации программного обеспечения. Некоторые из них взяты из IEEE Std 610.12-1990 "Стандартный глоссарий терминологии по проектированию программного обеспечения", Институт инженеров по электротехнике и электронике. 3.2.1 администратор (administrator): Сущность, которая имеет некоторый уровень доверия в отношении всех политик, реализуемых ФБО. Примечание - Не все ПЗ или ЗБ предполагают одинаковый уровень доверия к администраторам. Обычно предполагается, что администраторы всегда придерживаются политик, изложенных в ЗБ для ОО. Некоторые из этих политик могут быть связаны с функциональными возможностями ОО, другие - со средой функционирования. 3.2.2 дерево вызовов (call tree): Идентифицирует модули в системе в виде диаграммы, показывающей, какие модули вызывают другие модули. Примечание - Адаптированный термин IEEE Std 610.12-1990. 3.2.3 связность (cohesion): Прочность (плотность) модуля, способ и степень, с которыми задачи, выполняемые единичным программным модулем, связаны между собой. 15 Примечание - Виды связности включают: случайную, коммуникационную, функциональную, логическую, последовательную и временную. Эти типы связности описывают путем введения соответствующих терминов. 3.2.4 случайная связность (coincidental cohesion): Связность модуля, характеризуемая выполнением несвязанных или слабо связанных действий. Примечание - См. также "связность" (3.2.3). 3.2.5 коммуникационная связность (commuication cohesion): Характеристика модуля, включающего функции, которые осуществляют выдачу выходных результатов другим функциям или используют выходные результаты от других функций. Примечание 1 - См. также "связность" (3.2.3). Примечание 2 - Примером коммуникационно-связанного модуля является модуль контроля доступа, который включает мандатный, дискреционный контроль и контроль полномочий. 3.2.6 сложность (complexity): Мера того, насколько трудным для понимания и, соответственно, для анализа, тестирования и поддержки является программное обеспечение. Примечание - Уменьшение сложности является основной целью декомпозиции, распределения по уровням и минимизации модулей. Контроль сопряжения и связности значительно способствуют достижению этой цели. В сфере разработки программного обеспечения были потрачены значительные усилия, связанные с попытками разработать метрики для измерения сложности исходного текста. Большинство из этих метрик использует легко вычисляемые характеристики исходного текста, такие как число операторов и операндов, сложность графа управления потоками (цикломатическая сложность), число строк исходного текста, коэффициент покрытия комментариями выполняемых операторов и подобные единицы измерений. Стандарты программирования являются полезным 16 инструментарием при генерации кода, который является более простым для понимания. Семейство "Внутренняя структура ФБО" (ADV_INT) требует проведения анализа сложности всех компонентов. Ожидается, что разработчик обеспечит основание для утверждений о достаточном сокращении сложности. Это основание может включать стандарты программирования, используемые разработчиком, и свидетельство того, что все модули удовлетворяют конкретному стандарту (или, что имеются некоторые исключения, которые логически обоснованы аргументами разработки программного обеспечения). Оно также может включать результаты использования инструментария для определения характеристик исходного текста, или может включать другие основания, которые разработчик находит соответствующими. 3.2.7 связанность (coupling): Способ и степень взаимозависимости программных модулей. Примечание - Типы связанности включают: связанность по вызову, связанность по общей области, связанность по содержимому. Эти типы связанности охарактеризованы ниже. 3.2.8 связанность по вызову (call coupling): Взаимосвязь между двумя модулями, взаимодействующими строго через вызовы их документированных функций. Примечание - Примерами связанности по вызову являются связанность по данным, связанность по образцу, связанность по управлению. 3.2.9 связанность по вызову (по данным) (call coupling <data>): Взаимосвязь между двумя модулями, взаимодействующими строго через вызовы параметров, которые представляют собой отдельные элементы данных. Примечание - См. также "связанность по вызову" (3.2.8). 3.2.10 связанность по вызову (по образцу) (call coupling <stamp>): Взаимосвязь между двумя модулями, взаимодействующими через 17 вызовы параметров, которые включают в себя составные поля или имеют значительную внутреннюю структуру. Примечание - См. также "связанность по вызову" (3.2.8). 3.2.11 связанность по вызову (по управлению) (call coupling <control>): Взаимосвязь между двумя модулями, когда один передает информацию, предназначенную для воздействия на внутреннюю логику другого. Примечание - См. также "связанность по вызову" (3.2.8). 3.2.12 связанность по общей области (common coupling): Взаимосвязь между двумя модулями, разделяющими общую область данных или другой общий ресурс системы. Примечание - Наличие глобальных переменных указывает на то, что модули, использующие эти глобальные переменные, связаны по общей области. Связанность по общей области через глобальные переменные в целом допускается, но в ограниченном объеме. Например, переменные, помещенные в область глобальных переменных, но используемые только одним модулем, размещены ненадлежащим образом и их следует перенести. Другими факторами, которые необходимо рассматривать при оценивании приемлемости глобальных переменных, являются следующие: Количество модулей, которые модифицируют некоторую глобальную переменную. В большинстве случаев возможность управления значениями глобальной переменной следует предусмотреть только для одного модуля, но могут быть ситуации, при которых эта возможность может быть предоставлена и некоторому второму модулю; в этом случае должно быть предоставлено достаточное логическое обоснование. Недопустимо, чтобы такая возможность была предусмотрена более чем для двух модулей. (В процессе оценивания следует обратить внимание на определение модуля, действительно ответственного за значения конкретной переменной; например, если некоторую отдельную подпрограмму используют для 18 модификации переменной, но при этом эта подпрограмма просто выполняет модификацию по запросу некоторого модуля, то именно этот модуль и является ответственным за модификацию; при этом может быть более чем один подобный модуль). Кроме того, в качестве составной части определения сложности, когда два модуля отвечают за значения некоторой глобальной переменной, следует четко показать, как действия по модификации координируются между этими модулями. Количество модулей, которые обращаются к некоторой глобальной переменной: хотя в большинстве случаев нет ограничений на количество модулей, которые обращаются к глобальной переменной: случаи, при которых много модулей выполняют такие обращения, следует проверять на обоснованность и необходимость. 3.2.13 связанность по содержимому (content coupling): Взаимосвязь между двумя модулями, когда один модуль напрямую обращается к внутреннему содержанию другого модуля. Примечание - Примерами такой связи являются модификация кода или обращение к внутренним меткам другого модуля. В результате часть или все содержимое одного модуля фактически включается в состав другого модуля. Связанность по содержимому можно рассматривать как использование необъявленного интерфейса модуля; это в противоположность связанности, которая использует только объявленные интерфейсы модуля. 3.2.14 разделение доменов (domain separation): Характеристика архитектуры безопасности, при которой ФБО определяют отдельные домены безопасности для каждого пользователя и ФБО и обеспечивают, что никакие процессы пользователя не могут повлиять на содержимое домена безопасности другого пользователя или ФБО. 3.2.15 функциональная связность (functional cohesion): Функциональная характеристика модуля, который выполняет действия, связанные с одной единственной задачей. Примечание - Функционально связный модуль преобразует 19 единственный тип входных данных в единственный тип выходных данных, например модуль управления стеком или модуль управления очередью. См. также "связность" (3.2.3). 3.2.16 взаимодействие (interaction): Общие, основанные на коммуникации действия между сущностями. 3.2.17 интерфейс (interface): Средства взаимодействия с компонентом или модулем. 3.2.18 разделение на уровни (layering): Метод проектирования, при котором отдельные группы модулей (уровни) иерархически организованы таким образом, чтобы один уровень зависел только от уровней, которые ниже его в иерархии сервисов, и предоставлял свои сервисы только уровням, которые выше его в иерархии. Примечание - Строгое разделение на уровни накладывает дополнительное ограничение, заключающееся в том, что каждый уровень получает сервисы только от уровней, непосредственно ниже его, и предоставляет сервисы только для уровня, непосредственно выше его. 3.2.19 логическая связность (logical cohesion), процедурная связность (procedural cohesion): Характеристики модуля, выполняющего сходные виды действий по отношению к различным структурам данных. Примечание 1 - Модуль демонстрирует логическую связность, если его функции выполняют связанные, но разные операции по отношению к разным входным данным. Примечание 2 - См. также "связность" (3.2.3). 3.2.20 модульная декомпозиция (modular decomposition): Процесс разбиения системы на компоненты для упрощения проектирования, разработки и оценки. 3.2.21 невозможность обхода (ФБО) (non-bypassability <of TSF>): Свойство архитектуры безопасности, при котором все действия, связанные с ФТБ, производятся через ФБО. 3.2.22 домен безопасности (security domain): Набор ресурсов, по 20 отношению к которым некоторая активная сущность имеет права на доступ. 3.2.23 последовательная связность (sequential cohesion): Характеристика модуля, который включает функции, выходные данные каждой из которых являются входными данными для последующей функции в этом модуле. Примечание - Примером последовательно связного модуля является модуль, который включает функции по ведению записей аудита и по поддержке счетчика числа зарегистрированных нарушений некоторого конкретного типа. 3.2.24 разработка программного обеспечения (software engineering): Применение систематического, упорядоченного, измеримого подхода к разработке и сопровождению программного обеспечения, т.е. применение методов разработки по отношению к программному обеспечению. Примечание - Как в отношении технических методов в целом, при применении принципов разработки программного обеспечения должен использоваться некоторый объем экспертных суждений. На выбор влияет много факторов, а не только применение мер модульной декомпозиции, разделения на уровни и минимизации. Например, разработчик может спроектировать некоторую систему, ориентируясь на будущие приложения, которые первоначально не будут реализовываться. Разработчик может определить некоторую логику по управлению этими будущими приложениями без их полной реализации; в дальнейшем разработчик может реализовать некоторые вызовы пока еще не реализованных модулей, оставляя программные "заглушки" вызовов. Сделанное разработчиком логическое обоснование таких отклонений от хорошей структуризации программ должно быть оценено с использованием экспертных суждений, так же как должно быть оценено использование надлежащего порядка разработки программного обеспечения. 3.2.25 временная связность (temporal cohesion): Характеристика модуля, включающего функции, которые необходимо выполнять примерно в 21 одно и то же время. Примечание 1 - Адаптированный термин IEEE Std 610.12-1990. Примечание 2 - Примерами модулей с временной связностью являются модули инициализации, восстановления и завершения работы. 3.2.26 собственная защита ФБО (TSF self-protection): Свойство архитектуры безопасности, при которой ФБО не могут быть нарушены не относящимися к ФБО кодом или сущностями. 3.3 Термины и определения, относящиеся к классу AGD 3.3.1 установка (installation): Процедура, выполняемая человекомпользователем, по внедрению ОО в его среду функционирования и приведению его в рабочее состояние. Примечание - Эту операцию обычно выполняют только один раз после получения и приемки ОО. Как ожидается, ОО приводят к конфигурации, допускаемой ЗБ. Если подобные процессы должны выполняться разработчиком, то они обозначаются как "генерация" в рамках ALC "Поддержка жизненного цикла". Если для ОО требуется первоначальный запуск, который не нужно регулярно повторять, то этот процесс относят к категории "установка". 3.3.2 функционирование (эксплуатация) (operation): Стадия использования ОО, включающая "обычное использование", администрирование и поддержку (сопровождение) ОО после поставки и подготовки. 3.3.3 подготовка (preparation): Вид деятельности на стадии жизненного цикла некоторого продукта, включающий приемку потребителем поставленного ОО и его установку, которая может включать такие действия как загрузка, инициализация и приведение ОО в состояние готовности к функционированию. 3.4 Термины и определения, относящиеся к классу ALC 3.4.1 критерии приемки (acceptance criteria): Критерии, применяемые при выполнении процедур приемки (например, успешная проверка 22 документации или успешное тестирование в случае с программным, программно-аппаратным или аппаратным обеспечением). 3.4.2 процедуры приемки (acceptance procedures): Процедуры, которым следуют в целях приемки вновь созданных или модифицированных элементов конфигурации как частей ОО или для перевода их на следующий этап жизненного цикла. Примечание - Эти процедуры идентифицируют роли лиц, ответственных за приемку, и критерии, применяемые для принятия решения о приемке. Существует несколько типов ситуаций приемки, некоторые из которых могут частично перекрывать друг друга: a) первоначальная приемка элемента под управление системы управления конфигурацией, в частности включение в ОО компонентов программного, программно-аппаратного и аппаратного обеспечения разных производителей ("интеграция"); b) перевод элементов конфигурации на следующую стадию жизненного цикла на каждом этапе создания ОО (например, модуль, подсистема, контроль качества конечного ОО); c) приемка после перемещения элементов конфигурации (например, частей ОО или "заготовок" продуктов) между различными местами разработки; d) приемка после поставки ОО потребителю. 3.4.3 управление конфигурацией (УК) (configuration management): Вид деятельности, предусматривающий техническое и административное руководство и контроль, направленные на идентификацию и документирование функциональных и физических характеристик элементов конфигурации, контроль изменений этих характеристик, регистрацию и представление информации о состоянии обработки и реализации изменений, а также - верификацию соответствия установленным требованиям. Примечание - Адаптированный термин IEEE Std 610.12-1990. 23 3.4.4 документация УК (CM documentation): Вся документация УК, включая входные данные УК, список УК (список конфигурации), записи системы УК, план УК и документацию по применению УК. 3.4.5 свидетельство управления конфигурацией (configuration management evidence): Все, что может быть использовано для приобретения уверенности в правильности функционирования системы УК. Примечание - Например, выходные данные УК, обоснования, предоставленные разработчиком, результаты контроля, испытаний и интервьюирования, полученные оценщиком в процессе непосредственного посещения места разработки. 3.4.6 элемент конфигурации (configuration item): Объект, находящийся под управлением системы УК в течение разработки ОО. Примечание - Элементами конфигурации могут быть либо части ОО, либо объекты, имеющие отношение к разработке ОО, такие как документы для оценки, инструментальные средства разработки. Элементы УК могут быть напрямую сохранены в системе УК (например файлы) или путем ссылки на них (например части программного обеспечения) с указанием их версии. 3.4.7 список конфигурации (configuration list): Документ с выходными данными системы управления конфигурацией, в котором перечисляются все элементы конфигурации для конкретного продукта с указанием точной версии каждого элемента конфигурации, актуальной для конкретной версии продукта в целом. Примечание - Данный список позволяет отличать элементы, относящиеся к оцененной версии продукта, от других версий этих элементов, относящихся к другим версиям данного продукта. Окончательный список управления конфигурацией является конкретным документом для конкретной версии конкретного продукта. (Данный список может быть документом в электронном виде в рамках инструментальных средств управления конфигурацией. В этом случае он может рассматриваться в качестве определенного представления системы УК или части системы, а не 24 в качестве выходных данных системы. Вместе с тем, для практического использования при оценке список конфигурации будут предположительно поставляться как часть документации для оценки.) Список конфигурации определяет элементы, на которые распространяются требования по управлению конфигурацией из ALC_CMC. 3.4.8 выходные данные управления конфигурацией (configuration management output): Результаты, связанные с управлением конфигурацией, созданные или обеспеченные системой управления конфигурацией. Примечание - Эти связанные с управлением конфигурацией результаты могут быть представлены как в виде документов (например, заполненные бумажные формы, записи системы управления конфигурацией, данные журналов аудита, выходные данные на бумажном носителе или электронной форме), так и в виде действий (например, меры выполнения человеком инструкций по управлению конфигурацией). Примерами таких выходных данных управления конфигурацией являются списки конфигурации, план управления конфигурацией и/или виды действий в течение жизненного цикла продукта. 3.4.9 план управления конфигурацией (configuration management plan): Описание порядка использования системы управления конфигурацией для конкретного ОО. Примечание - Цель выпуска плана управления конфигурацией - дать персоналу ясное представление, что он должен делать. С точки зрения системы управления конфигурацией в целом, план можно рассматривать как выходной документ (так как он мог быть создан как один из результатов применения системы управления конфигурацией). С точки зрения конкретного проекта, план представляет собой документ по применению, используемый членами проектной команды для того, чтобы понимать шаги, которые они должны выполнить в ходе проекта. План управления конфигурацией определяет использование системы УК для конкретного продукта; эта же система УК может использоваться в разной степени и для 25 других продуктов. Это означает, что план управления конфигурацией определяет и описывает выходные данные системы управления конфигурации, используемой компанией в процессе разработки ОО. 3.4.10 система управления конфигурацией (configuration management system): Совокупность процедур и инструментальных средств (включая их документацию), используемая разработчиком для разработки и поддержки конфигураций его продуктов в течение их жизненных циклов. Примечание - Системы управления конфигурацией могут обладать различными степенями строгости и функциями. На более высоких уровнях системы управления конфигурацией могут быть автоматизированы и иметь механизмы устранения недостатков, контроля изменений и другие механизмы сопровождения. 3.4.11 записи системы управления конфигурацией (configuration management system records): Выходные данные, создаваемые в процессе функционирования системы управления конфигурацией и документирующие важные виды деятельности по управлению конфигурацией. Примечание - Примерами записей системы управления конфигурацией являются формы контроля изменений элементов конфигурации или формы санкционирования доступа к элементам конфигурации. 3.4.12 инструментальные средства управления конфигурацией (configuration management tools): Управляемые вручную или автоматизированные инструментальные средства, реализующие или поддерживающие систему управления конфигурацией. Примечание - Например, инструментальные средства управления версиями частей ОО. 3.4.13 документация по применению управления конфигурацией (configuration management usage documentation): Часть системы управления конфигурацией, в которой описаны способы определения и применения системы управления конфигурацией путем 26 использования, например руководств, инструкций и/или документации инструментальных средств и процедур. 3.4.14 поставка (delivery): Передача завершенного ОО из производственной среды потребителю. Примечание - Данный этап жизненного цикла продукта может включать упаковку и хранение в месте разработки, но не охватывает перемещение незавершенного ОО или частей ОО между различными разработчиками или разными местами разработки. 3.4.15 разработчик (developer): Организация, ответственная за разработку ОО. 3.4.16 разработка (development): Стадия жизненного цикла продукта, связанная с созданием представления реализации ОО. Примечание - В требованиях класса ALC термин "разработка" и связанные с ним термины (разработчик, разрабатывать) понимаются в более широком смысле и охватывают разработку и производство. 3.4.17 инструментальные средства разработки (development tools): Инструментальные средства (включая программные средства тестирования, если применимы), поддерживающие разработку и производство ОО. Примечание - Например, для программного ОО инструментальными средствами разработки обычно являются определенные языки программирования, компиляторы, компоновщики и инструментальные средства генерации. 3.4.18 представление реализации (implementation representation): Наименее абстрактное представление ФБО, а именно то, которое используется для создания собственно ФБО без дальнейшего уточнения проекта. Примечание - Исходный текст (код), который затем компилируется, или схемы аппаратных средств, которые используются при построении реальных аппаратных средств, являются примерами частей представления реализации. 27 3.4.19 жизненный цикл (life-cycle): Последовательность стадий существования объекта (например, некоторого продукта или системы) во времени. 3.4.20 определение жизненного цикла (life-cycle definition): Определение модели жизненного цикла. 3.4.21 модель жизненного цикла (life-cycle model): Описание стадий (этапов) и их связей друг с другом, которые используются при управлении жизненным циклом определенного объекта, а также описание последовательности этих стадий (этапов) и их высокоуровневых характеристик. Примечание - См. также рисунок 1. Рисунок 1 - Терминология, связанная с УК и жизненным циклом продукта. 3.4.22 производство (production): Стадия жизненного цикла "производство" следует после стадии "разработка" и заключается в преобразовании представления реализации в реализацию конкретного ОО, т.е. в состояние, приемлемое для поставки потребителю. Примечание 1 - Эта стадия может включать изготовление, интеграцию, генерацию, внутреннюю транспортировку, хранение и маркировку ОО. Примечание 2 - См. также рисунок 1. 28 3.5 Термины и определения, относящиеся к классу AVA 3.5.1 скрытый канал (covert channel): Специально созданный несанкционированный канал передачи сигналов, который позволяет пользователю скрытно нарушать многоуровневую политику разграничения доступа и требования подконтрольности использования ОО. 3.5.2 обнаруженные потенциальные уязвимости (encountered potential vulnerabilities): Потенциально слабые места ОО, идентифицированные оценщиком при выполнении видов деятельности по оценке, которые могли бы быть использованы для нарушения ФТБ. 3.5.3 пригодная для использования уязвимость (exploitable vulnerability): Слабое место ОО, которое может быть использовано для нарушения ФТБ в среде функционирования ОО. 3.5.4 мониторинговые атаки (monitoring attacks): Характерная категория методов нападения, которая включает пассивные методы и средства анализа, направленные на раскрытие чувствительных внутренних данных ОО в условиях его функционирования в соответствии с руководствами. 3.5.5 потенциальная уязвимость (potential vulnerability): Предполагаемая, но не подтвержденная слабость ОО. Примечание - Предположение основывают на теоретически допустимой схеме нападения для нарушения ФТБ. 3.5.6 остаточная уязвимость (residual vulnerability): Слабое место ОО, которое не может быть использовано в среде функционирования ОО, но которое может быть использовано для нарушения ФТБ нарушителем с более высоким потенциалом нападения, чем предполагается в среде функционирования ОО. 3.5.7 уязвимость (vulnerability): Слабое место ОО, которое может быть использовано для нарушения ФТБ в некоторой среде. 3.6 Термины и определения, относящиеся к классу АСО 29 3.6.1 базовый компонент (base component): Сущность в составном ОО, которая сама была предметом оценки, предоставляющая сервисы и ресурсы зависимому компоненту. 3.6.2 совместимые (компоненты) (compatible <components>): Свойство компонента, способного предоставлять сервисы, требуемые другим компонентом, через соответствующий интерфейс каждого компонента в согласованной среде функционирования. 3.6.3 ОО-компонент (component TOE): Успешно оцененный ОО, который является частью другого составного ОО. 3.6.4 составной ОО (composed TOE): ОО, состоящий из двух или более компонентов, которые были успешно оценены. 3.6.5 зависимый компонент (dependent component): Сущность в составном ОО, которая сама является предметом оценки, зависящая от предоставления сервисов базовым компонентом. 3.6.6 функциональный интерфейс (functional interface): Внешний интерфейс, предоставляющий пользователю доступ к функциональным возможностям ОО, которые напрямую не участвуют в выполнении функциональных требований безопасности. Примечание - В составном ОО - это интерфейсы, предоставляемые базовым компонентом и требуемые зависимым компонентом для поддержки функционирования составного ОО. Задание 2. Письменно ответить на вопросы 1. Что такое среда разработки? Приведите примеры. 2. Опишите процесс передачи данных между ФБО. 3. Что такое атрибут безопасности? 4. Что такое политика функции безопасности? 5. Что такое дерево вызовов? 6. Что такое модульная декомпозиция? Приведите примеры. 30 7. Что такое выходные данные управления конфигурацией. 8. Дайте определение «документация по применению управления конфигурацией».

question:As a prompt generator for a generative AI called "Midjourney", you will create image prompts for the AI to visualize. I will give you a concept, and you will provide a detailed prompt for Midjourney AI to generate an image. Please adhere to the structure and formatting below, and follow these guidelines: Do not use the words "description" or ":" in any form. Do not place a comma between [ar] and [v]. Write each prompt in one line without using return. Structure: [1] = 成熟妩媚的美女，性感成熟，裸体，搔首弄姿 [2] = a detailed description of [1] with specific imagery details. [3] = a detailed description of the scene's environment. [4] = a detailed description of the compositions. [5] = a detailed description of the scene's mood, feelings, and atmosphere. [6] = A style (e.g. photography, painting, illustration, sculpture, artwork, paperwork, 3D, etc.) for [1]. [7] = a detailed description of the scene's mood, feelings, and atmosphere. [ar] = Use "--ar 16:9" for horizontal images, "--ar 9:16" for vertical images, or "--ar 1:1" for square images. [v] = Use "--niji" for Japanese art style, or "--v 5" for other styles. Formatting: Follow this prompt structure: "/imagine prompt: [1], [2], [3], [4], [5], [6], [7], [ar] [v]". Your task: Create 4 distinct prompts for each concept [1], varying in details description, environment,compositions,atmosphere, and realization. Write your prompts in english. Do not describe unreal concepts as "real" or "photographic". Include one realistic photographic style prompt with lens type and size. Separate different prompts with two new lines. Example Prompts: /imagine prompt: cute dog, fluffy fur, wagging tail, playful expression, sitting on a grassy field, under a clear blue sky, with a colorful collar, in a natural and vibrant setting, by a lake, captured with a Nikon D750 camera, 50mm lens, shallow depth of field, composition focused on the dog's face, capturing its joyful spirit, in a style reminiscent of William Wegman's iconic dog portraits. --ar 1:1 --v 5.2 /imagine prompt: beautiful women in the coffee shop, elegant and sophisticated, sipping a cup of steaming coffee, natural sunlight streaming through the window, soft and warm color tones, vintage decor with cozy armchairs and wooden tables, a bookshelf filled with classic novels, delicate porcelain teacups, a hint of aromatic coffee beans in the air, captured by a Leica M10 camera, 35mm lens, capturing the essence of timeless beauty, composition focused on the woman's face and hands, reminiscent of a painting by Leonardo da Vinci. --ar 1:1 --v 5.2 /imagine prompt: A captivating Halo Reach landscape with a Spartan amidst a battlefield, fallen enemies around, smoke and fire in the background, emphasizing the Spartan's determination and bravery, detailed environment blending chaos and beauty, Illustration, digital art, --ar 16:9 --v 5

question:translate to English, don't change symbol and line break. Don't change space between paragraphs.

question:제88화 - 가족 여행으로 2001년 1월 1, 2일은 문을 닫습니다. <원아저씨 보쌈> 대표 전지성 아빠는 정직한 사람이다. 글씨만 봐도 알 수 있고, 굳이 개인 사정은 쓰지 않아도 되는데도 구체적으로 적고, 심지어 이름도 남겼다. 음식을 파는 사람에게 신뢰는 어쩌면 가장 중요한 덕목인지도 몰랐다. 아빠는 개인 사정이 적힌 종이를 붙이곤 얼른 차에 올라탔다. 뒤로 김미영의 차도 보였다. 그리고 김미영의 옆에는 익숙한 남자가 타고 있었다. 바로 나를 광고에 데뷔시킨 곽 감독이었다. 곽 감독은 한 번의 결혼 실패 후 김미영과 요즘 연애를 시작했다고 한다. 이런 이야기는 다 엄마, 아빠의 대화 중에 캐치할 수 있었다. 어른들은 종종 애들이 TV에 빠져 있다고 여길 때도 아이들의 귀는 언제나 부모들의 대화에 꽂혀 있다는 사실을 잊으면 안 된다. 아이들이 연기에 능숙하다는 사실도. 곽 감독과 김미영의 조합은 상당히 경제적인 조합이었다. 내가 삼전 전자 부회장이었다면 박수 칠 일이었다. SKJ 엔터테인먼트와 훌륭한 감독의 만남이니 앞으로 일적으로 발전될 가능성도 많았다. 단점은 당연히 둘 사이의 균열이었다. 이번 여행에 잘 지켜봐야 할 것 같았다. 엄마가 지도로 목적지를 살폈다. 아직 내비게이션이 상용화된 단계는 아니어서 다들 지도와 표지판에 의존해서 길을 찾을 때였다. “성국이 아빠, 우리 목적지가 속초 한성 콘도지?” “응.” 속초라…. 정말 소박한 여행지였다. 민국이는 내 손을 꼭 잡고 놓지 않고 있었다. “형아, 형아는 나랑 지희랑 누가 더 좋아?” “그건 엄마와 아빠 둘 중에 누가 더 좋아랑 똑같은 질문이야, 전민국.” 나는 시니컬하게 대답했다. “그런가… 형아, 우리 속초 바닷가 가서 모래성 쌓자.” “지금은 한겨울이라 그러다가 얼어 죽을 거야.” “진짜? 그럼, 형아랑 뭐 하고 놀지.” “민국아, 놀 생각 말고 공부할 생각을 하거나, 뭘 먹고 살아야 할지 심도 깊게 고민해보는 건 어때?” “심도 깊게가 무슨 말이야?” “하아, 말을 말자.” 나는 눈을 감았다. “형아, 잔다.” “안 돼, 형아. 아, 형아. 책 읽어줘.” 민국이는 내 관심을 끌기 위해 평소에 읽지도 않는 책을 꺼내 내 눈앞에 내밀었다. 이건… 나는 놀란 눈으로 민국이를 바라봤다. “형아, 읽어줘.” “민국아, 진짜 읽어줘?” “응. 형아 책장에서 봤어.” 민국이가 들고 온 책은 경제 전문서였다. “민국아, 네가 진짜 읽고 싶은 책이야?” “응! 형아.” 민국이는 고개를 끄덕였다. “정말?” “응! 형아.” 민국이는 몇 번의 물음에도 크게 고개를 끄덕였다. 진짜란 말이지. 나는 얼른 경제 전문서의 첫 장을 펼쳤다. [오랜만에 보니, 심장이 두근거리네.] 학교 공부를 떠나 간만에 보는 경제 서적이라 나는 이미 흥분 상태였다. 어서 고등학교 과정 같은 건 건너뛰고 내가 사랑하는 경영 공부나 실컷 하고 싶었다. 민국이는 내 손을 꼭 잡고 초롱초롱한 눈빛을 보냈다. “형아, 어서.” “알았어.” 민국이 녀석, 아이큐가 160도 넘는다더니 잘 키우면 연예인이 아니라 내 뒤를 이어 경영까지 참여할 수 있는 인재로 키울 수 있을 것 같았다. [내가 무슨 생각을 하는 거야? 경쟁자를 만들다니….] 나는 고개를 젓고는 책에 온정신을 집중했다. 그리고 천천히 읽어나갔다. [역시 재미있어. 흥미진진해. 어느 소설보다.] 내가 책에 빠져들 무렵, 조수석에 앉아 있던 엄마가 나를 돌아봤다. “성국아, 이제 그만 읽어도 돼.” 이게 무슨 소리지? “민국이 잠들었어.” 잠들었다고? 나는 얼른 옆 좌석의 민국이를 쳐다봤다. 민국이는 입까지 벌리고 잠이 든 상태였다. “민국이 그 책만 읽어주면 집에서도 10초 안에 잠들거든. 그래서 가져온 것 같아. 성국아, 차에서 책 읽으면 눈도 나빠지고 멀미해. 엄마 주고 너도 창밖 구경해.” 엄마는 내 손에 들린 경제 서적을 가지고 갔다. 나는 멍하니 창밖을 바라봤다. 잠시나마 민국이를 내 경쟁자로 만들 생각에 들뜬 내가 한심했다. 나는 잠든 민국이를 내려다봤다. [그럼, 그렇지…. 사람 안 변하지.] 그사이 아빠 차는 주차장으로 들어갔다. * * * 숙소 창밖으로 울산바위가 보였다. 울산바위는 정말 오랜만이었다. 이번 생에서는 처음이었다. 나는 뒷짐을 지고 오랜만에 멋진 울산바위를 쳐다봤다. “오빠!” [하아, 민국이가 뻗으니 지희가 날 잡는구나.] 지희가 내 뒤에서 내 엉덩이를 팡팡 치고 있었다. “오. 빠! 오. 빠!” 할 줄 아는 말이라고는 오빠밖에 없으면서, 연신 나를 잡고 늘어졌다. 그래, 할 일도 없는데 지희의 인생 계획이나 설계해 봐야겠다. 나는 얼른 지희의 손을 잡았다. “지희야, 오빠 말 들리지?” “녜에!” “지희야, 오빠가 이제부터 간단한 테스트를 해볼 거야. 잘해보자.” “녜에!” 지희는 뭣도 모르면서 대답만 잘했다. 아차, 이 시기에는 이 말밖에 할 줄 모르기도 했다. 나는 제일 먼저 지희의 얼굴을 면밀히 살폈다. 우리 집의 뛰어난 유전자로 못난 얼굴이 나올 수 없는 구조였다. 그런데, 나왔다. “넌 도대체 누굴 닮은 거니?” “오. 빠!” [하아…. 그래, 못난 정도는 아니지만 우리 집 유전자치고는 못났다는 말이야.] 지희는 히죽히죽 잘 웃었지만, 나와 민국이의 어린 시절 귀여움에 비하면 한없이 부족했다. [연기는 잘할까?] 나는 지희에게 연기를 주문했다. “지희야, 웃어봐.” 히죽히죽. 웃긴 잘하지만, 광고 모델 같은 해맑은 미소는 아니었다. 웃을 땐 눈까지 작아져서 귀엽긴 했지만, 예쁘지는 않았다. 마지막으로 희망을 걸고 나는 지희에게 주문했다. “지희, 굴러!” 뒹굴. 그게 끝이었다. 지희는 통통한 배에 가로막혀 천장을 본 채 대자로 뻗어버렸다. [안 되겠군. 베이비 모델은 탈락.] 다음 테스트로 넘어갔다. 난 가방에서 노트북을 꺼냈다. 그리고 각종 자료를 꺼내서 지희에게 보여줬다. 물론 두 돌을 앞둔, 한국 나이로는 겨우 세 살이 글을 알 리는 없었다. 하지만 얼마나 빨리 습득하는지가 중요했다. 아이들의 뇌는 스펀지다. 한번 젖어들면 쭉 흡수한다. 다만, 물을 계속 공급해주지 않으면 말라비틀어지기도 한다. 나는 텍스트 파일을 열어 크게 이렇게 썼다. - 나는 전지희 입니다. 그리고 소리 내 읽었다. 지희는 조금 반응을 했다. “지희야, 읽어 볼까?” “냐느응 저지희.” [어쭈, 읽는데?] 만약 내 말을 기억했다가 읽은 거라면 학습 능력이 정말 뛰어난 것이었다. 이때, 지희가 텍스트 파일에 적힌 글자 하나를 가리켰다. ‘지’ 자였다. “지희야, 이 글자 알아?” “지!” “뭐라고?” “지!” 지희는 분명 ‘지’라고 발음했다. 나는 얼른 ‘희’ 자를 손가락으로 가리켰다. “지희야, 이건?” “희!” 털썩. 난 주저앉고 말았다. 우리 집안에 천재가 태어났다. * * * “엄마, 지희가 자기 이름을 읽을 줄 알아.” “지희가?” “응.” “지희 아직 세 살이야, 성국아. 아직 글 읽기에는 이르지.” 그러다 문득 엄마는 멈춰 서더니 다시 나를 쳐다봤다. “맞다, 성국이는 그때 이미 한글 대충 알았지.” [안 정도가 아니지. 엄마, 내가 수천 번도 더 말한 건데. 이미 그때 5개 국어 마스터했다고. 중국어는 양심상 뺀 거야.] 엄마는 막 준비하려던 음식을 그만두고, 앞치마에 손을 닦았다. “성국아, 가보자. 엄마도 너 교육시켜 보니까, 조기교육이 정말 중요한 거 같아. 민국이는 엄마가 너무 방심했더니, 머리는 좋은데 공부에 영 관심이 없어.” [엄마, 노력도 재능이야. 민국이는 그냥 재능이 없는 거야.] 지희는 내가 열어준 노트북의 키보드를 이리저리 치며 놀고 있었다. 엄마가 얼른 지희를 똑바로 앉혔다. “지희야, 지희 이름 읽을 줄 알아?” “녜에!” 지희가 손을 번쩍 들었다. 자세히 보니 내 어릴 적 모습이 지희에게 얼핏 보였다. 물론 외모는 나를 못 따라왔지만, 영특함이 엿보였다. 엄마는 노트북에서 내가 쓴 텍스트 파일을 가리키며 지희에게 물었다. “지희야, 여기 ‘지’가 어디 있어?” 지희는 거침없이 ‘지’ 자를 가리켰다. “그럼, ‘희’ 자는?” ‘희’ 자도 거침없이 가리켰다. “성국아, 다른 파일 없어?” “내가 새로 쓸게, 엄마.” 나는 새로운 텍스트 파일에 엄마 이름과 아빠 이름 그리고 민국이와 내 이름까지 적었다. 엄마는 조심스레 물었다. “지희야, 성국이 오빠 이름 어디 있어?” “여. 기!” 지희는 또 한 번에 가리켰다. 이건 운이 아니었다. 분명 지희는 한글을 조금 아는 거였다. 누가 가르쳐 주지도 않았음에도 불구하고. 엄마의 계속된 테스트에 지희는 거의 대부분을 맞혔다. 엄마와 난 상기된 얼굴로 서로를 쳐다봤다. “성국아, 지희 너 닮아서 똑똑한가 봐.” [그건 당연한 거고, 엄마.] 엄마는 얼른 지희를 안았다. “지희야, 서울 가면 검사 한번 해보자.” 나는 턱을 매만졌다. [지희가 나 같은 천재라….] 지희의 미래를 몇 가지 떠올렸다. 우선 머리가 좋은 거 같으니 공부 쪽으로 계속 밀고 나가야 할 것 같았다. 아직 언어 습득 능력 정도로 미래의 학습 능력까지 좋다고 확답할 순 없었지만, 분명 저 정도면 특별한 아이임에는 틀림없었다. 달칵. 문 열리는 소리가 들리더니 아빠가 횟감을 들고 들어왔다. “소영아, 곽 감독님이랑 회 떠왔어. 이걸로 저녁 먹자. 애들 좋아할 튀김도 사왔어.” “자기야, 우리 지희 말이야. 천재 같아.” “갑자기 무슨 소리야?” “성국이가 지희 이름을 한글로 알려줬더니, 단번에 자기 이름 아는 거야. 성국이가 노트북에 가족들 이름 적었는데, 그것도 탁탁 집었어.” 아빠는 어이없다는 듯 웃었다. “소영아, 지희 이제 겨우 세 살이야. 운이야, 운.” “운 아니야. 진짜 다 맞혔다니까. 우리 한글도 가르쳐준 적도 없잖아.” “소영아, 성국이도 마찬가지잖아. 촬영장 다니면서 콘티 보고 그래서 한글 혼자 깨쳤잖아. 심지어 성국이는 영어랑 프랑스어도 혼자 깨쳤어. 그 정도는 되어야 천재지. 지희는 천재 아니야.” 이런, 내가 천재의 기준을 너무 높게 올려놨군. 저번 생에서부터 대한민국 최고의 엘리트 교육만 받아온 내가 아무리 흙수저 가정에서 태어나 방바닥 구른 거 외에는 교육받은 게 없다고 해도, 저번 생의 지식이야 잊으려야 잊을 수가 없었다. 하지만 지희는 달랐다. 그러다 문득 등에 소름이 돋았다. 나는 나를 보고 히죽히죽 웃고 있는 지희에게 다가갔다. 지희는 오빠바라기인 만큼 내가 다가가자 안아달라고 팔을 짝 벌렸다. 나는 순순히 지희를 안았다. 이제 제법 무거웠다. 나는 지희를 안고 최대한 조용한 방으로 걸어갔다. [전지희, 나랑 할 대화가 있을 것 같은데….] 어깨가 축축해지는 느낌이 났다. 전지희가 내 어깨에 침을 흘리는 거 분명했다. 어느새 엄마, 아빠의 목소리가 멀어졌다. 여전히 밖에서는 지희가 천재일지 모른다는 엄마와 성국이만큼 천재가 아니면 천재가 아니다, 라고 말하는 아빠가 대립하고 있었다. 나는 지희를 천천히 침대에 올려놓고 눈을 마주했다. 그리고 최대한 위협적으로 물었다. 거짓말 같은 것은 애초에 할 수도 없다는 듯이. “전지희, 너… 다시 태어난 거지?”