НЕГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ ЧАСТНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «МОСКОВСКИЙ ФИНАНСОВО-ПРОМЫШЛЕННЫЙ УНИВЕРСИТЕТ «СИНЕРГИЯ» Институт Информационных технологий (наименование факультета/ института) Направление подготовки /специальность: 09.03.02 Информационные системы и технологии (код и наименование направления подготовки /специальности) Профиль/специализация Разработка, сопровождение и обеспечение безопасности__________ (наименование профиля/специализации) информационных систем_____________________________________________________________ Форма обучения: заочная. ОТЧЕТ ПО УЧЕБНОЙ ПРАКТИКЕ (вид практики) Технологическая (проектно-технологическая) практика (тип практики) 4 семестр Обучающийся Ответственное лицо от Профильной организации М.П. (при наличии) (ФИО) (подпись) (ФИО) (подпись) Москва 20 г. Контрольные задания-вопросы, необходимые для оценки знаний, умений, навыков и (или) опыта деятельности по итогам практики № п/п Подробные ответы обучающегося на практические кейсы-задачи Задание- Каковы основные методы сбора и анализа данных ИТ-проектов с учетом основных вопрос требований информационной безопасности? №1 Что такое угроза ИБ? Угроза информационной безопасности — это любая подозрительная активность, потенциально направленная на нарушение конфиденциальности, доступности, целостности ключевых информационных ресурсов. Последствиями успешной атаки могут быть: • • • прекращение работы организации; сбой систем управления; уничтожение данных. Источником опасности могут быть как искусственные, так и естественные угрозы. Искусственные угрозы представляют собой умышленное причинение вреда, а естественные возникают в результате обстоятельств непреодолимой силы, при отсутствии умышленного мотива человека. К искусственным источникам опасности традиционно относят две группы. К первой относятся: • • • • хакерские группировки; конкуренты; криминальные организации; инсайдеры (внутренние пользователи с преступным мотивом). Ко второй группе относят: • • • • ошибки в процессе обработки информации; ошибки пользователей; нелицензированное ПО; отключение системы защиты данных. Естественные источники опасности классифицировать намного проще. К ним можно отнести любые действия, на которые не может повлиять человек. Например, стихийные природные явления. № п/п Подробные ответы обучающегося на практические кейсы-задачи Анализ информационной безопасности организации. Анализ состояния информационной безопасности (или оценка защищенности информационных систем) представляет собой структурированный повторяемый процесс, который помогает компаниям вовремя находить и устранять возникающие опасности. По результатам анализа формируются рекомендации, направленные на изменение внутренних процессов компании. Также анализ необходим для определения вероятности возникновения опасности и масштаба возможного ущерба. Анализ информационной безопасности помогает понять, какой должна быть система защиты для дальнейшего ее проектирования, модернизации, внедрения необходимых средств защиты, что, в свою очередь, позволит обеспечить требуемый уровень защиты данных предприятия от неправомерного доступа. Существует несколько различных методологий, которые можно использовать при анализе защищенности. Давайте рассмотрим их подробнее. 1. Экспертная оценка. Экспертная комиссия определяет те объекты, которые будут включены в исследование, а также их параметры и характеристики. Для полноценной оценки эффективности информационной безопасности предприятия специалисты собирают следующие данные: • • • • • общие сведения об объекте автоматизации; описание процессов обработки конфиденциальной информации; описание корпоративной информационной системы; описание информационной инфраструктуры; описание системы обеспечения безопасности информации (документация, организационные и технические меры, средства защиты). На основе собранной информации специалисты оценивают потенциальные источники риска. Для каждого выявленного источника определяется вероятность возникновения угрозы и коэффициент важности. 2. Статистический анализ рисков. 3 № п/п Подробные ответы обучающегося на практические кейсы-задачи Этот метод позволяет определить, в каких местах система наиболее уязвима. Однако для такого анализа необходимо иметь достаточно большой объем данных о ранее совершенных атаках. 3. Факторный анализ. ИТ-специалисты выделяют основные факторы, которые качественно влияют на возникновение той или иной угрозы. Задача эксперта заключается в том, чтобы проанализировать системы предприятия и определить, какие уязвимости будут устранены, а какие можно будет пренебречь. В рамках анализа состояния информационной безопасности специалист также определяет векторы атак или средства, с помощью которых потенциальный злоумышленник может нанести вред системе. Примеры некоторых угроз: • • • • неготовность пользователей к фишинговым атакам; использование незащищенных беспроводных сетей; открытые USB-порты и возможность бесконтрольного использования съемных носителей; наличие устаревших версий компонентов. Важно понимать, что оценка информационной безопасности предприятия должна стать постоянным, периодически проводимым мероприятием. С каждым днем хакеры придумывают новые способы и методы кражи информации, появляются новые уязвимости. Анализ безопасности систем будет особенно актуален при: • • • • • критических ситуациях; слиянии, поглощении, присоединении, расширении компании; смене курса или концепции бизнеса; изменении в законодательстве; крупных изменениях в информационной структуре. Оценка информационной безопасности. Процесс оценки системы обеспечения информационной безопасности может отличаться в зависимости от предприятия. Однако, ключевые этапы оценки должны быть воспроизводимыми, основанными на передовых отраслевых практиках и структурированными, чтобы обеспечить оценку всего масштаба систем и ее потенциальных уязвимостей. Ниже приведены несколько существующих методов, используемые для оценки возможных угроз. Моделирование информационных потоков Процесс оценивания информационной безопасности с помощью моделирования информационных потоков позволит выявить: • • • • тенденции в поведении системы; возникновение потенциальных ошибок; масштаб уязвимостей; масштабы последствий от вероятной угрозы. 4 № п/п Подробные ответы обучающегося на практические кейсы-задачи Предварительная оценка всей системы и выявление потенциальных рисков дает возможность эффективно принимать решения о мерах безопасности. Моделирование угроз. При моделировании угроз обычно используют сочетание экспертного и факторного анализа. Специалисты тестируют все жизненно важные системы предприятия на наличие уязвимости. Такой анализ позволяет оценить вероятность возникновение угрозы и масштабы последствий. Кроме этого, моделирование угроз включает в себя поиск потенциальных источников опасности и способы их устранения. Поиск уязвимых зон. Для успешного анализа и оценки информационной безопасности, компании необходимо не только знать о потенциальных угрозах, но и оценивать степень их влияния на работу предприятия. Существует множество методов и способов поиска уязвимых зон. Ниже представлены две популярные методики, которые позволяют классифицировать атаки на всех этапах их возникновения. Матрица угроз. Матрица угроз представляет собой сводную таблицу вероятности возникновения угроз и степени их влияния. Такая характеристика позволяет специалистам описывать все уязвимые места системы, типы угроз и возможные последствия, уменьшая при этом субъективный фактор. Другими словами, матрица угроз наглядно показывает количество потенциальных угроз. По результатам работ с матрицей организация сможет эффективно распределить свои ресурсы для защиты информационной безопасности от наиболее вероятных атак. Деревья атак. Деревья атак или деревья ошибок — это структурированный и иерархический способ сбора возможных угроз. Дерево описывает возможную атаку и ее цель, связывая с целью атаки задачи злоумышленников, а также возможные способы реализации. Деревья атак могут использоваться либо в совокупности с другими инструментами анализа, либо как самостоятельный инструмент исследования. Особенность деревьев атак заключается в том, что под каждый программный продукт компании эксперт выстраивает отдельное дерево атак. Таким образом, получается целая цепочка угроз, по которой хакеры могут “подниматься” для достижения свой цели. Вероятность реализации угроз и масштаб ущерба. После анализа и оценки информационной безопасности компании специалисты смогут предвидеть вероятность реализации угрозы и масштаб возможного ущерба. Как правило, эксперты ссылаются на следующие данные: • • • проведенные исследования; результаты анализа ИБ; данные по ранее проведенным атакам. Специалисты определяют два основных вектора работы: • • Устранение последствий атаки, если она будет успешной. Принятие и проработка рисков. 5 № п/п Подробные ответы обучающегося на практические кейсы-задачи Опираясь на статистические данные компаний, эксперты определяют уровень затрат производства на устранение последствий. Как правило, статистика собирается за несколько отчетных периодов. В них отражена реальные инциденты по утечкам данных, репутационные риски, эффективность систем защиты. С помощью собранной информации компания принимает решение по тем действиям, которые необходимо предпринять, чтобы обеспечить надлежащий уровень защиты. При просчете рисков эксперты также обращают внимание на стоимость их устранения. В случае, если устранение риска превосходит предполагаемые потери, то некоторые компании предпочитают минимизировать возможные потери, а не полностью исключить подобный риск. Такой анализ помогает грамотно распределить бюджеты компании на защиту своих данных и избежать незапланированных расходов Анализ и оценка информационной безопасности способствуют повышению осведомленности о степени защиты в компании. Работа по изучению потенциальных рисков и уязвимостей, а также действия по их минимизации позволяют повысить безопасность данных организации, ее сетей и серверов. Задание- Процесс разработки технической документации по информационной безопасности. вопрос Жизненный цикл системы информационной безопасности (далее — СИБ) в общем виде состоит №2 из следующих этапов: • анализ требований к СИБ; • проектирование; • реализация; • внедрение; • эксплуатация. Необходимость разработки технической документации. Для владельца информационных ресурсов важно получить результат в виде функционирующей системы информационной безопасности, снижающей риски компрометации информации ограниченного доступа в организации. Технический проект в данном случае служит для разработки фундаментальных основ будущей системы, а именно включает описание того, каким образом СИБ будет строиться и функционировать, какими мерами и средствами будет обеспечиваться защита информации, каковы возможности развития и совершенствования системы. По завершении разработки технического проекта на систему информационной безопасности Заказчик получает исчерпывающий комплект документации на СИБ, описывающий все технические нюансы будущей системы. Для непосредственного исполнителя на этапе технического проекта необходимо заложить наиболее подходящую архитектуру СИБ, а также сделать правильный выбор мер и средств защиты информации в организации. Также важно обеспечить соответствие характеристик и свойств системы техническому заданию, либо обосновать при участии и согласии Заказчика корректировку требований, указанных в ТЗ, для повышения эффективности создаваемой системы. Таким образом, в результате разработки документации технического проекта у Заказчика появятся ответы на следующие вопросы: • какова общая архитектура СИБ; 6 № п/п Подробные ответы обучающегося на практические кейсы-задачи • какие меры и средства будут использоваться для реализации требований по защите информации; • каким образом СИБ будет функционировать; • какие изменения в организации, необходимые для повышения уровня защищенности информации, последуют в результате внедрения СИБ; • будут ли учтены требования заказчика (бизнес-требования) и требования нормативноправовых актов в сфере информационной безопасности при разработке и внедрении СИБ и, если да, то каким образом. Исполнитель в процессе разработки документации технического проекта получит следующие результаты: базу для перехода к следующим этапам построения СИБ, а именно стадиям рабочей документации и внедрения; • понимание архитектуры, используемых технологий и средств, порядка построения системы; • каким образом реализуются требования Заказчика (бизнес-требования) и нормативных документов в сфере информационной безопасности к системе. Разработка технического проекта для системы информационной безопасности чаще всего осуществляется на основе соответствующих стандартов и руководящих документов. Причем для государственных учреждений их применение обязательно, а для коммерческих рекомендуется. На практике коммерческие организации также используют государственные стандарты при разработке документации технического проекта по следующим причинам: • многократно апробированный подход к созданию информационных систем; продуманные структура и наполнение документов; состав документов, достаточный для разработки и описания практически любой системы. Для разработки документации стадии технического проекта (ТП) на СИБ используются государственные стандарты и руководящие документы серии 34: • • • 1. ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем». В данном стандарте указаны: • виды и наименование документов стадии ТП; • комплектность документации; • принятые обозначения документов; • правила обозначения СИБ и их частей. 2. ГОСТ 34.003-90 «Термины и определения»; 3. ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания». В стандарте указаны: • перечень этапов работ, проводимых на стадии ТП; • подробное описание работ, проводимых на стадии ТП; • перечень организаций, участвующих в создании СИБ. 4. РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов». В данном руководящем документе указаны требования к содержанию документов стадии ТП. Однако стоит отметить, что вышеуказанные стандарты являются слишком общими и в основном реализуют оформительскую и обще структурную функцию. Для разработки 7 № п/п Подробные ответы обучающегося на практические кейсы-задачи сетевой части документов стадии технического проекта проектировщиками используются сведения из следующих источников: - действующие нормативные документы (НПА), регламентирующие требования к защите той или иной информации ограниченного доступа. В данных НПА представлены требования к мерам по защите информации в информационных системах, описаны нюансы реализации этих мер и дополнительные меры усиления. Среди актуальных НПА можно выделить следующие: приказ ФСТЭК России от 18 февраля 2013 г. № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; • приказ ФСТЭК России от 11 февраля 2013 г. № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» • приказ ФСТЭК России от 14 марта 2014 г. № 31 «Об утверждении требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды; • методический документ «Меры защиты информации в государственных информационных системах», утвержден ФСТЭК России 11 февраля 2014 г. Требования к защите информации ограниченного доступа и перечни защитных мер разнятся для ИС разных уровней/классов защищенности. В случае, если информация в организации не относится к защищаемой в соответствии с федеральными законами РФ (например, служебная тайна), то владелец данной информации может воспользоваться подходами, предлагаемыми в данных НПА для построения корпоративной СИБ. • - российские и зарубежные стандарты, описывающие различные подходы к способам реализации стадий жизненного цикла построения СИБ, в том числе стадии технического проекта: серия государственных стандартов ГОСТ Р ИСО/МЭК 2700X, идентичные международным стандартам ISO/IEC 2700X. Данные стандарты описывают процессный подход PDCA (Plan, Do, Check, Act) к реализации жизненного цикла системы менеджмента информационной безопасности, которая является неотъемлемой частью СИБ; • NIST SP 800-64 – стандарт Национального Института Стандартов и Технологий США, описывающий жизненный цикл разработки информационных систем; • NIST SP 800-37 – стандарт Национального Института Стандартов и Технологий США, являющийся руководством по интеграции управления рисками в жизненный цикл разработки информационных систем. - эксплуатационная документация производителя на средства защиты информации и вспомогательные средства. В данных документах содержится исчерпывающая техническая информация о применяемых при построении СИБ средствах, в том числе напрямую к реализации мер ИБ не относящихся, например, серверах, системах хранения данных, средствах виртуализации и прочих. Общий набор таких документов у разных производителей различен и зависит в том числе от исполнения того или иного средства • 8 № п/п Подробные ответы обучающегося на практические кейсы-задачи (аппаратное/программное). Ниже представлен стандартный набор эксплуатационной документации на средства защиты информации, используемый для разработки документов стадии технического проекта: общее описание (datasheet); руководство администратора (может входить руководство по локальному и централизованному управлению); • руководство пользователя; • руководство по быстрой установке и развертыванию (для аппаратного СЗИ); • руководство оператора; • руководство по развертыванию в виртуальной инфраструктуре (для программного СЗИ); - общая информация об имеющихся архитектурах СИБ, лучшие практики в части построения СИБ, руководства по безопасности и интеграции СЗИ друг с другом, сведения о проблемах при взаимодействии тех или иных СЗИ. Примерами таких сведений могут являться следующие документы: • • • руководства по архитектурам систем информационной безопасности; • лучшие практики в области информационной безопасности; • руководства по безопасности для СЗИ и сред функционирования. Разработка технического проекта на СИБ в соответствии с ГОСТ 34. Разработка документов стадии технического проекта на СИБ осуществляется чаще всего интеграторами данных услуг и реализуется преимущественно в соответствии со следующим планом: определение перечня разрабатываемых документов – данные сведения указываются в техническом задании на СИБ. В некоторых случаях разработчик документов по согласованию с Заказчиком может расширить или сократить данный перечень, если возможность этого предусмотрена в ТЗ; • разработка шаблонов документов стадии ТП – используется структура в соответствии с РД 50-34.698-90 и ГОСТ 2.106 (для некоторых документов), оформление в соответствии с ГОСТ 2.105-95; • разработка сетевой части документов. Требования к системе устанавливаются в техническом задании на СИБ. В соответствии с данными требованиями определяется перечень защитных технических и организационных мер, необходимых к реализации в системе; • согласование разработанной документации и представленных в ней решений с Заказчиком системы. При разработке документации технического проекта чаще всего не требуется разрабатывать полный перечень документов, указанный в ГОСТ 34.201-89, так как данный стандарт морально устарел и часть документов не учитывают тенденции разработки и технологии современных информационных систем. Минимальный комплект документов, необходимый для описания системы информационной безопасности, следующий: • • • • • ведомость технического проекта; пояснительная записка к техническому проекту; схема функциональной структуры; схема структурная комплекса технических средств; 9 № п/п Подробные ответы обучающегося на практические кейсы-задачи • схема организационной структуры; • ведомость покупных изделий. По требованию заказчика или в том случае, если СИБ является сложной многокомпонентной системой, дополнительно могут разрабатываться также следующие документы: • схема автоматизации; • описание автоматизируемых функций; • описание информационного обеспечения системы; • описание комплекса технических средств; • описание программного обеспечения; • описание организационной структуры. Необходимо отметить, что ГОСТ 34.201-89 допускает расширение номенклатуры документов стадии ТП, однако на практике означенных документов хватает с избытком. Правила разработки документации. При разработке документации рекомендуется придерживаться определенных правил, основные представлены ниже: структурное соответствие государственным стандартам; четкое соответствие требованиям технического задания на систему; применение шаблонов документов (применение единых стилей, разметки, полей и прочего); • индивидуальный подход и одновременное использование существующих разработок при наполнении разделов документов. Также существуют практические рекомендации применительно к конкретным документам: • • • Пояснительная записка к техническому проекту: • • • • • • • • • • • • • разработка документа осуществляется в среде Microsoft Word, после окончания разработки рекомендуется для удобства конвертировать документ в формат PDF; термины и сокращения должны быть едиными в пределах всех разделов документа; рекомендуется избегать явных повторений и ненужного увеличения объема документа; технические решения необходимо описывать как можно более подробно с указанием: архитектуры и используемых технологий; мест размещения программных и технических средств в инфраструктуре организации; используемых средств защиты информации с описанием их характеристик, реализуемых функций, сведений о сертификации; основных настроек средств защиты информации в части механизмов защиты, адресации, маршрутизации, взаимодействия со смежными системами и средствами и прочего; средств управления, методов доступа к ним и местах их установки; схемы (структурная, функциональная, организационная): разрабатывать схемы в среде Microsoft Visio; после разработки вставлять схемы в документ при помощи диалога «Специальная вставка» в формате EMF (метафайл Windows); разрабатывать отдельные схемы на систему, подсистемы и компоненты подсистем. 10 № п/п Подробные ответы обучающегося на практические кейсы-задачи Задание- Основные элементы спроектированной программной и технической архитектуры. вопрос Архитектура безопасности информационных систем (ИС) зависит от модели рисков и от №3 организационной структуры предприятия. Задача построения оптимальной системы решается на основе достижения поставленных целей и отказа от избыточности. Понятие архитектуры безопасности ИС и ее задачи. Организация решает задачи построения идеальной архитектуры сети исходя из ключевых задач бизнеса. Одно решение будет приемлемо для торговой фирмы, второе – для корпораций ТЭК, решающих задачу глобальной цифровизации: от использования нейронных сетей до построения цифровых моделей буровых вышек и скважин. В обоих случаях ключевыми факторами становятся задачи бизнеса и объем выделенных ресурсов. В обычной ситуации, при отсутствии разработанной стратегии цифровизации бизнеса, проблема построения оптимальной архитектуры информационных систем встает, когда: задачи различных подразделений в области ИС не согласованы, что порождает конфликты программного обеспечения из-за отсутствия единой системы мониторинга рисков и управления ИС; • пользователи и руководство не считают систему ИС оптимальной; • необходимо рассчитать себестоимость внедрения средств защиты данных и финансовый результат от их использования; • отсутствует идеология развития информационной системы, нет понимания целей и направлений ее развития, видов требуемого ПО или его обновления. Если единой стратегии построения архитектуры безопасности информационных систем не разработано, возникает ряд проблем: • ИТ-подразделение недофинансируется, что снижает общую эффективность решения задач в компании; • пользователи и руководители недовольны тем, что ключевые задачи не решаются, данные не охраняются должным образом, из-за отсутствия систем мониторинга постоянно происходят сбои в работе, из-за нарушения функционирования ключевых модулей теряется важная информация, системы фильтрации почты не настроены; • система не соответствует требованиям регуляторов, например, ФСТЭК РФ, в области защиты персональных данных, что вызывает проблемы при проверках; • система не соответствует задачам бизнеса, например, не решается задача удаленного контроля датчиков работы промышленного оборудования или систем ЖКХ; • несогласованность в работе различных подразделений приводит к заминкам и проволочкам в решении задач информационной безопасности. Дополнительным риском становится неэффективность инвестиций, вложенных в создание отдельных элементов архитектуры сети. • Методы построения идеальной архитектуры. Архитектура безопасности информационных систем опирается на две составляющие: архитектуру ИБ в целом и организационную структуру предприятия. Но она имеет специфические особенности, связанные с разработанной для организации моделью угроз. В ней учитываются риски: • вирусных угроз и хакерских атак; 11 № п/п Подробные ответы обучающегося на практические кейсы-задачи • утечки персональных данных; • утечки конфиденциальной информации; • сохранности государственной тайны; • нарушения работы всей системы или ее элементов из-за технологических или программных сбоев. Защите подлежит информация в электронном виде и на бумажных носителях. Важные сведения содержатся в видеоконференциях и видеосессиях, голосовых приложениях и IP-телефонии. Система должна учитывать эти риски и предполагать охрану от: • действий инсайдеров; • ненамеренных ошибок пользователей или системных администраторов; • внешних рисков. Эксперты считают, что разработка системы защиты от рисков информационной безопасности должна происходить независимо от разработки общей ИТ-архитектуры бизнеса, что позволит решать важные задачи отдельно, концентрируясь на конкретных целях. Несогласование целей безопасности и бизнеса возникает в случаях: заинтересованности бизнеса в использовании облачных технологий, увеличивающих риски утраты или утечек важных данных; • использования проектных и групповых способов работы над важными решениями, что не позволяет выявить ответственного пользователя; • применения единых каналов коммуникаций для нескольких пользователей и групп; • активного взаимодействия с клиентами без учета ИБ-рисков. Все это исключает возможность создания единственного общего периметра безопасности, а внедряемые решения противоречат общему направлению развития бизнеса. Но служба информационной безопасности часто забывает о том, что она существует для бизнеса, а не вопреки ему. Недоговоренности приводят к: • • перекрыванию протоколов на сетевом экране; • затруднению доступа в Интернет для отдельных сотрудников; • блокировке доступа к сайтам, важным для бизнеса. Итогом становится то, что подразделения информационной безопасности начинают называть business prevention department, то есть препятствующими бизнесу, а не способствующими ему. Невозможно изменить организационную структуру предприятия или бизнес-процессы под внедряемую систему информационной защиты, напротив, им она должна соответствовать ИБсистема. Стратегия. Первым шагом для формирования архитектуры безопасности становится разработка стратегии, представляющей собой последовательность этапов достижения целей и используемые ресурсы. Три группы ресурсов – человеческие, финансовые и временные – должны быть скоординированы. Поэтому разработку стратегии нельзя поручать отдельным департаментам, она должна контролироваться на уровне руководства компании. Именно оно определяет, что является максимальным приоритетом – краткое время создания системы или минимизация затрачиваемых ресурсов. Стратегия описывает желаемые элементы архитектуры, которые должны обеспечить ее функционирование: 12 № п/п Подробные ответы обучающегося на практические кейсы-задачи 1. Информация. Указываются информационные массивы и виды предоставления данных, среди них – текстовые, видео- и аудиофайлы, устная информация, данные на бумажных носителях. В этом разделе определяются степени важности данных, уровень их защиты. 2. Инфраструктура. Этот подраздел документа описывает материальные объекты, где присутствуют данные, подлежащие защите. Это компьютеры, материальные носители, периферийные устройства, места нахождения документированной информации, например, регистратура в поликлинике, где находятся медицинские карточки пациентов, содержащие персональные данные. 3. Информационные системы, в которых содержатся конфиденциальные данные: ERP-, CRM-, SCM-, SCADA-системы, биллинговые программы, бизнес-приложения, программы бухгалтерского учета. 4. Информационная безопасность. В разделе описывается, какие задачи безопасности решаются и какие средства, программные решения, например, DLP-системы, будут использованы, предполагается инсталляция готового программного продукта или разработка собственного решения. 5. Служба информационной безопасности. Здесь описывается структура подразделения, отвечающего за поддержание элементов архитектуры безопасности информационных систем, его задачи и функциональные обязанности, методы оценки ключевых показателей эффективности. Необходимо учитывать направления развития бизнеса и рынка программного обеспечения в целом, предполагаемые действия регуляторов. Требуется проводить мониторинг изменения угроз. С точки зрения затрат нужно учитывать, что рынок ПО меняется, и все большую популярность приобретает направление «ПО как услуга» (Software-as-a-Service, SaaS). Требуется учитывать отраслевую специфику, предполагаемые изменения нормативных актов в рамках государственной Доктрины информационной безопасности. Решение этих вопросов позволит выстроить оптимальную систему защиты и архитектуру ИС и снизить общие расходы предприятия. Задание- Руководство пользователя. вопрос В настоящее время часто используют еще один эксплуатационный документ, в который отчасти №4 входит руководство системного программиста, программиста и оператора. Этот документ называют Руководством пользователя. Появление такого документа явилось следствием широкого распространения персональных компьютеров, работая на которых пользователи совмещают в своем лице трех указанных специалистов. Составление документации для пользователей имеет свои особенности, связанные с тем, что пользователь, как правило, не является профессионалом в области разработки программного обеспечения. Рекомендации по написанию подобной программной документации: • • • • учитывайте интересы пользователей - руководство должно содержать все инструкции, необходимые пользователю; излагайте ясно, используйте короткие предложения; избегайте технического жаргона и узко специальной терминологии, если все же необходимо использовать некоторые термины, то их следует пояснить; будьте точны и рациональны - длинные и запутанные руководства обычно никто не читает, например, лучше привести рисунок формы, чем долго ее описывать. 13 № п/п Подробные ответы обучающегося на практические кейсы-задачи Руководство пользователя, как правило, содержит следующие разделы: • • • • • общие сведения о программном продукте; описание установки; описание запуска; инструкции по работе (или описание пользовательского интерфейса); сообщения пользователю. Раздел «Общие сведения о программе» обычно содержит наименование программного продукта, краткое описание его функций, реализованных методов и возможных областей применения. Раздел «Установка» обычно содержит подробное описание действий по установке программного продукта и сообщений, которые при этом могут быть получены. В разделе «Запуск» как правило, описаны действия по запуску программного продукта и сообщений, которые при этом могут быть получены. Раздел «Инструкции по работе» обычно содержит описание режимов работы, форматок ввода/вывода информации и возможных настроек. Раздел «Сообщения пользователю» должен содержать перечень возможных сообщений, описание их содержания и действий, которые необходимо предпринять по этим сообщениям. Лучше всего следовать 3 простым советам: 1. Понятность. Помните, что руководство будут читать люди, которые не сильно знакомы с вашим продуктом. Пишите простым языком, избегайте профессиональных терминов. Руководство пользователя должно быть написано на языке этого самого пользователя, а не на языке писателя. 2. Наглядность. Добавляйте в руководство побольше графики и скриншотов с аннотациями. Читателю будет проще и приятнее решать проблему, если будет наглядно показано как это делать. 3. Видео. Лучше один раз увидеть, чем сто раз услышать. Продемонстрируйте пользователю последовательность действий для достижения конкретной цели. Документация, содержащая видео вставки будет пользоваться большей популярностью, чем обычный текстовый документ. Задание- Основные принципы и правила урегулирования конфликтов в организации. вопрос 1. Переговоры – это совместное обсуждение конфликтующими сторонами с возможным №5 привлечением посредника спорных вопросов с целью достижения согласия. Они выступают некоторым продолжением конфликта и в то же время служат средством его преодоления. В том случае, когда делается акцент на переговоры как часть конфликта, их стремятся вести с позиции силы, с целью достигнуть односторонней победы. Такой характер переговоров, обычно, приводит к временному, частичному разрешению конфликта, и переговоры служат лишь дополнением к борьбе за победу над противником. Если же переговоры понимаются имущественно как метод урегулирования конфликта, то они приобретают форму честных, открытых дебатов, рассчитанных на взаимные уступки и взаимное удовлетворение определенной части интересов сторон. 14 № п/п Подробные ответы обучающегося на практические кейсы-задачи 2. Компромисс – означает соглашение на основе взаимных уступок. 3. Консенсус – форма выражения согласия с аргументами противника в споре. Схемы технического расположения инфраструктуры ООО «Инновационная форма» Firewall WiFi Network Router Server Switch ПК сотрудников 15 № п/п Подробные ответы обучающегося на практические кейсы-задачи Программное обеспечение ООО «Инновационная форма» Программная архитектура включает в себя пакет MS Office,браузер Google Chrome, в качестве решения безопасности Checkpoint Sandblast Agent. Дополнительно у сотрудников технической поддержки установлен Microsoft Visual Studio, у специалистов ИС 1С Предприятие. 16
