Материал: Математические методы системного анализа и управления информационно-вычислительными, управляющими и сетевыми системами. Проскурин Д.К., Сысоев Д.В
ВЫПУСК № 3-4 (17-18), 2019 ISSN 2618-7167
|
|
|
|
Таблица 2 |
|
|
|
Пример оценки рисков |
|||
|
Оценка |
|
Оценка |
|
|
|
|
послед- |
|
|
|
Угроза |
вероят- |
Комментарии к оценке |
|
Риск |
|
ствий |
|
||||
|
ности |
|
|
|
|
|
|
ущерба |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Внесение логиче- |
С |
Средняя квалификация. Автора закладки |
В |
|
В |
ской закладки |
|
можно вычислить из-за ограниченного кру- |
|
|
|
|
|
га программистов. |
|
|
|
Ошибки в про- |
Н |
Опытная команда программистов, повтор- |
В |
|
С |
граммировании |
|
ные инциденты с данной командой проис- |
|
|
|
(коде). |
|
ходят не чаще одного раза в год |
|
|
|
|
|
|
|
|
|
Анализ и перехват |
В |
Доступны свободно-распространяемые |
В |
|
В |
трафика сервера c |
|
средства перехвата трафика. Выявить |
|
|
|
целью подсчета ре- |
|
наличие перехвата трафика непросто |
|
|
|
гистраций и пере- |
|
|
|
|
|
хвата в нужный |
|
|
|
|
|
момент |
|
|
|
|
|
Внесение в таблицу |
В |
Средняя квалификация. Источник действия |
В |
|
В |
базы данных ис- |
|
может быть и не вычислен. |
|
|
|
пользуемых сайтом. |
|
|
|
|
|
|
|
|
|
|
|
Взлом сайта. |
С |
Средняя квалификация. Вычисление зло- |
В |
|
В |
Например, получе- |
|
умышленника затруднительно. |
|
|
|
ние прав админи- |
|
|
|
|
|
стратора. |
|
|
|
|
|
|
|
|
|
|
|
Проведение DDoS. |
В |
Низкая квалификация. Финансовые затраты |
С |
|
В |
|
|
минимальны (300 USD за 24 часа атаки по |
|
|
|
|
|
данным из открытых источников |
|
|
|
|
|
информации). |
|
|
|
|
|
|
|
|
|
|
Каждый актив можно отнести к одному |
деляется его стоимостью. А в связи с тем, |
|||||||||
из 8 типов: А1 - информация/данные цирку- |
что зачастую невозможно определить точ- |
||||||||||
лирующие в ERP-систем; |
А2 |
- аппаратное |
ную стоимость актива и предприятия в це- |
||||||||
обеспечение ERP-системы; А3 - приложения |
лом, то предлагается ценность актива C(Aji) |
||||||||||
уровня |
представления |
в |
ERP-системе |
оценивать нормированной величиной в диа- |
|||||||
(например, GUI, мобильные клиенты ERP); |
пазоне от 0 до 1, которая будет показывать |
||||||||||
А4 - оборудование для обеспечения связи; |
отношение цены актива Cost(Aji) к величине |
||||||||||
А5 - система управления базами данных; А6 - |
капитала всего предприятия Cost: |
|
|||||||||
программное обеспечение и процессы серве- |
|
Сost(Aij ) |
|
|
|||||||
ра; |
А7 - |
8 пользователи |
и клиенты ERP- |
С(Aij ) |
|
(3) |
|||||
|
|||||||||||
системы; А - |
репутация и уровень доверия к |
|
Cost |
|
|||||||
ERP-системе. |
|
|
|
|
Каждая угроза ИБ |
|
|||||
|
Таким образом, множество A представ- |
|
|||||||||
|
|
|
|
|
|||||||
ляет собой объединение всех подмножеств, |
TRk TR|k {1,2,..,n} |
(4) |
|||||||||
описывающих |
различные |
типы |
активов. |
где n – количество рассматриваемых |
при |
||||||
Универсальной методики |
оценки |
активов |
|||||||||
оценке риска угроз, из множества угроз без- |
|||||||||||
нет, поэтому в данном случае будем прово- |
|||||||||||
опасности ERP-систем TR, описывается сле- |
|||||||||||
дить |
оценку |
ценности актива |
экспертным |
||||||||
дующим параметром |
|
||||||||||
путем. Как правило, ценность актива опре- |
|
||||||||||
|
|
|
|
||||||||
55
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В СТРОИТЕЛЬНЫХ, СОЦИАЛЬНЫХ И ЭКОНОМИЧЕСКИХ СИСТЕМАХ
TRk (v, p, d ) |
(5) |
где v – частота возникновения данной угрозы за фиксированный промежуток времени, p – вероятность успешной реализации угрозы, d
– коэффициент разрушительности угрозы. Каждый из перечисленных выше параметров предлагается нормировать и оценивать в диапазоне значений
v, p, d 0,1 |
(6) |
Значение вероятности успешной реали-
зации угрозы в ERP-системе тесно связано с наличием в ERP-системе различных механизмов и функций безопасности, которые в соответствии с моделью безопасности с полным перекрытием должны в идеальном случае перекрывать все возможные угрозы активам и объектам исследуемой системы. В этом случае связь между угрозами и механизмами защиты ERP-системы будет описываться матрицей отношений RM:TR×MP:
|
0, если механизм MP не перекрывает угрозу TR |
RM (rmTR,M P) |
(7) |
PM P,если механизм MP перекрываает угрозу TR с вероятностью PM P
А так как для противодействия одной угрозе может быть использовано несколько механизмов защиты, имеющих различную вероятность отражения одного и того же типа угроз, то с учетом формулы 7, предлагается вероятность успешной реализации угрозы - p в ERP-системе рассчитывать по следующей формуле:
p 1 max( PMP1, PMP2 ,....PMPl ) . |
(8) |
В свою очередь каждая угроза может воздействовать не на всю ERP-систему, а на один или несколько определенных активов, следовательно, при оценке рисков от каждой конкретной угрозы, необходимо составить матрицу бинарных отношений между угрозами и активами ERP-системы RMA:TR×А:
|
1, если для актива А существует угроза TR |
|
RMА (rmaTR, A ) |
|
(9) |
0, если для актива А не существует угроза TR |
|
|
В этом случае, ущерб u(TRk ) от каждой угрозы
TRk | k 1,...,| TR |
будет рассчитываться по следующей формуле:
m |
|
u(TRk ) (С(Aij )rmaTRk,Ai ) . |
(10) |
i 1
Таким образом, риск Rk от каждой угрозы будет зависеть от характеристик самой угрозы и ценности активов, на которые данная угроза направлена, и будет рассчитываться по формуле:
|
( |
, ) = |
|
|
|
( ), |
(11) |
|
|
|
|
|
|
|
A, уровень B, уровень C, уровень D} [5]. Общий риск рассчитывается по форму-
ле 12 и классифицируется по аналогии с частным риском по каждой угрозе в соответствии с правилами таблицы:
TR |
|
R R k |
(12) |
k 1
Данная модель и методика и ее этапы могут применяться при оценке рисков информационной безопасности ERP-систем. Они могут быть применены для любых организаций, независимо от сферы их деятельности, масштабов, уровня организационной зрелости.
Каждый рассчитанный риск от реализации угрозы классифицируется в соответствии с качественной шкалой DR={уровень
Библиографический список
1. Аткина В.С. Применение карты рисков для оценки деструктивного воздействия
56
ВЫПУСК № 3-4 (17-18), 2019 |
|
ISSN 2618-7167 |
|||
существенной |
среды |
на |
информационную |
сти // Вопросы кибербезопасности. 2014. №4 |
|
систему |
// Безопасность |
информационных |
(7). С.49-54. |
||
технологий. 2013. №4. С.21 – 26. |
4. Mikova S.Y., Oladko V.S. The risk as- |
||||
2. СТО БР ИББС -1.0-2014. Обеспече- |
sessment of the Implementation of network at- |
||||
ние информационной безопасности органи- |
tacks on information infrastructure on the ex- |
||||
заций банковской системы Российской Фе- |
ample of tourism enterprises//Sochi Journal of |
||||
дерации. Общие положения [электронный |
Economy.2016. Vol. 39 , Issue 1, pp.42-51/. |
||||
ресурс].: |
URL: |
http://www.cbr.ru/credit/ |
5. Плетнев П.В., Белов В.М. Сравни- |
||
Gubzi_docs/st-10-10.pdf. |
|
тельный анализ существующих методов |
|||
3. Миков |
Д.А. |
Анализ методов и |
оценки рисков информационной безопасно- |
||
средств, используемых на различных этапах |
сти // Ползуновский вестник.2018. №3/1. С. |
||||
оценки рисков информационной безопасно- |
221 – 223. |
||||
УДК 004.415.2 |
|
|
|
|
|
Воронежский государственный технический университет |
Voronezh state technical university |
||||
Начальник отдела АИС Е.В. Колыхалова, тел.: 7(473)207-22-20 |
Head of the Department AIS E.V. Kolyhalova, Ph.:7(473)207-22-20 |
||||
Студентка К.А. Андреева бИС-171, |
|
Student K. A. Andreeva bIS-171, |
|||
E-mail: kandreeva952@gmail.com |
|
E-mail: kandreeva952@gmail.com |
|||
Россия, г. Воронеж |
|
|
|
Russia, Voronezh |
|
|
|
|
|
Е.В. Колыхалова, |
К.А. Андреева |
АНАЛИЗ ЖИЗНЕННОГО ЦИКЛА ПРОДУКТА С УЧЕТОМ БУДУЩИХ ИЗМЕНЕНИЙ
Аннотация: Проводится общий анализ жизненного цикла программного продукта, при котором определяется важность будущих изменений, а также возможные причины перепроектирования
Ключевые слова: жизненный цикл, программный продукт, международный стандарт, анализ, проектирование, паттерны, система, программное обеспечение, объекты, классы, перепроектирование, кодирование, тестирование, документирование, эксплуатация, сопровождение
E.V. Kolyhalova, K.A. Andreeva
PRODUCT LIFE CYCLE ANALYSIS FOR FUTURE CHANGES
Abstract: A General analysis of the life cycle of the software product, which determines the importance of future changes, as well as possible causes of redesign
Keywords: Life cycle, software product, international standard, analysis, design, patterns, system, software, objects, classes, redesign, coding, testing, documentation, operation, maintenance
При2 проектировании любой информа- |
ISO/IEC 12207, который разработан на осно- |
||
ционной системы необходимо учитывать ее |
ве предыдущих мировых стандартов и опи- |
||
дальнейшее развитие, если же этого не де- |
сывает стадии жизненного цикла программ- |
||
лать, то написанный в результате программ- |
ного продукта. Основными его характери- |
||
ный продукт, может быть не рентабелен и |
стиками являются единая терминология по |
||
вытеснен с рынка более оптимизированной |
разработке и внедрению программного про- |
||
системой. Введем такое понятие как жизнен- |
дукта, четкое разграничение между жизнен- |
||
ный цикл программного продукта. Он отра- |
ным циклом и моделью жизненного цикла. |
||
жает различные состояния, начиная с момен- |
[1] |
||
та возникновения необходимости в про- |
Единый стандарт включает в себя не |
||
граммном продукте и до его полного вывода |
только набор программных продуктов, но и |
||
из эксплуатации. Понятие жизненного цикла |
соответствующую документацию для всех |
||
определено в международном стандарте |
программ и непрерывного процесса сопро- |
||
|
|
вождения. Введение единого стандарта |
|
© Колыхалова Е.В., Андреева К.А., 2019 |
|||
необходимо для того, чтобы сформировать |
|||
57
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В СТРОИТЕЛЬНЫХ, СОЦИАЛЬНЫХ И ЭКОНОМИЧЕСКИХ СИСТЕМАХ
конкретное понимание жизненного цикла всеми участникам процесса его разработки. Общий вид жизненного цикла программного продукта представлен на рисунке 1.
Определение проекта
Анализ
Разработка
Детальное проектирование, кодирование
Реализация проекта
Тестирование, документирование
Эксплуатация
Сопровождение, поддержка
Рис. 1. Общий вид жизненного цикла программного продукта
Анализ информационной системы играет большую роль, позволяет выбрать оптимальный вариант реализации проекта. Этот этап в полной мере характеризует потребности аудитории и описывает требования заказчика, а впоследствии дает возмож-
ность сравнить с ресурсами предприятия. При проектировании следует построить модель сущность - связь для наглядного отображения системы.
Разработка проекта - период времени, когда был произведен анализ предметной области и на его основе ведутся переговоры с заказчиком и подписываются проектные контракты.
Детальное проектирование и кодирование – этап, на котором происходит непосредственное создание информационной системы. Объектно-ориентированное проектирование – парадигма объектно - ориентированного программирования, которая позволяет разложить систему на объекты и классы, это и является ее основной задачей. Причем стоит учитывать зависимость объектов, развитие системы, ее гибкость и производительность в будущем. [2]
Наиболее распространенным подходом к проектированию является использование паттернов. Паттерн проектирования - это наглядное описание взаимодействия объектов и классов, предназначенных для решения поставленной задачи. Паттерн не привязан ни к какому языку программирования, он лишь помогает спроектировать систему. Благодаря применению паттернов проектирования возможна разработка системы таким образом, чтобы ее последующие модификации требовали значительного сокращения финансовых и временных затрат, а значит наиболее быстрое удовлетворение изменившихся потребностей заказчика.
В частности, бывают случаи, когда проведенный анализ системы некорректен, следовательно, система спроектирована не точно и не отвечает заявленным требованиям заказчика. В таких случаях приходится перепроектировать систему, поэтому необходимо обращать внимание на следующие аспекты:
1. Программная платформа. Совре-
менные программы должны быть ориентированы и обладать таким свойством как кроссплатформенность. Это необходимо, чтобы программный продукт мог без труда работать с разными операционными системами. Если же программа ориентирована для
58
ВЫПУСК № 3-4 (17-18), 2019 |
|
|
|
|
ISSN 2618-7167 |
||
конкретной платформы, то велика вероят- |
нию. |
|
|
|
|||
ность, что ее понадобится изменять, дораба- |
Руководство пользователя – детальное |
||||||
тывать для возможности использования с |
описание технологии работы разработанного |
||||||
другой операционной системой. |
|
программного обеспечения конечным поль- |
|||||
2. Создаваемые классы. Часто требу- |
зователем. |
|
|
|
|||
ется изменить класс, но этот класс тесно свя- |
Описание применения - это общая ха- |
||||||
зан с другими классами. С такой системой |
рактеристика |
программного продукта для |
|||||
сложно работать, изменение одного класса |
сфер его применения. |
|
|||||
приведет к изменению в других. Такая зави- |
Руководство программиста - техниче- |
||||||
симость в системе называется монолитной. |
ская документация для разработчиков и спе- |
||||||
Заданное имя класса должно быть привязано |
циалистов, которые будут сопровождать |
||||||
к конкретной реализации. |
|
программный продукт. [4] |
|
||||
3. Алгоритм. При создании алгоритма |
После завершения стадий документи- |
||||||
будущего программного продукта важно по- |
рования и тестирования программное обес- |
||||||
нимать, что он будет модернизироваться, а, |
печение переходит на этап эксплуатации. С |
||||||
следовательно, и будет меняться, поэтому |
течением времени может возникнуть по- |
||||||
такие алгоритмы следует изолировать. [2] |
требность в обновлении программных ком- |
||||||
Чаще паттернов используются такое |
понентов или добавлении новых функций, |
||||||
понятие как каркас приложения. Каркас при- |
тогда этот этап будет называться сопровож- |
||||||
ложения - это набор классов, взаимодей- |
дение и поддержка продукта. |
|
|||||
ствующих друг с другом. Он определяет об- |
Таким образом, любая система в про- |
||||||
щую архитектурную структуру, где разгра- |
цессе работы претерпевает изменения. |
||||||
ничивает на методы и объекты. Основное |
Большинство из них следует учитывать на |
||||||
назначение каркаса в повторном использова- |
этапе проектирования, это необходимо для |
||||||
нии дизайна, а не кода. Они разрабатывают- |
того, чтобы она могла быстро развиваться, |
||||||
ся под конкретную предметную область, по- |
работать без «ошибок и сбоев». |
|
|||||
этому они должны легко модифицироваться. |
Библиографический список: |
||||||
На этапе |
кодирования |
программист |
|||||
|
|
|
|
||||
«переводит» алгоритм, разработанный для |
1. ГОСТ |
Р |
ИСО/МЭК |
12207-2010. |
|||
конкретного программного модуля, на опре- |
Информационная технология. Системная и |
||||||
деленный язык программирования. |
программная инженерия. Процессы жиз- |
||||||
Созданный программный продукт под- |
ненного цикла программных средств. |
||||||
лежит обязательному этапу – тестированию. |
2. Э. Гамма. Приемы объектно - ориен- |
||||||
На этом шаге производиться проверка про- |
тированного проектирования. Паттерны про- |
||||||
граммного продукта, с заранее подготовлен- |
ектирования / Гамма Э., Хэлм Р., Джонс Р., |
||||||
ными исходными данными, для которых из- |
Влиссидес Дж. / СПБ : Питер, 2004.-366 с.:ил |
||||||
вестен результат. Тестирование подразделя- |
3. Инюшкина О.Г., Кормышев В.М. |
||||||
ется на автономное и комплексное. При про- |
Исследование систем управления при проек- |
||||||
ведении первого вида тестирования - прохо- |
тировании информационных систем: учеб- |
||||||
дят проверку только определенные про- |
ное пособие. / О.Г. Инюшкина, В.М. Кор- |
||||||
граммные модули. Комплексное тестирова- |
мышев. Екатеринбург: «Форт-Диалог Ис- |
||||||
ние представляет из себя проверку всего |
еть», 2013. 370 с. |
|
|
||||
программного продукта. [3] |
|
4. ГОСТ Р ИСО/МЭК ТО 9294-93. |
|||||
Любое написанное приложение должно |
Информационная |
технология. |
Руководство |
||||
сопровождаться |
технической документаци- |
по управлению документированием про- |
|||||
ей. В соответствии со стандартом ISO-9294, |
граммного обеспечения |
|
|||||
она обычно классифицируется |
по назначе- |
|
|
|
|
||
59