CC BY
105
HHSSZ
УДК 004.41/.42
БЕЗОПАСНОСТЬ ПРИ РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
SECURITY IN SOFTWARE DEVELOPMENT
Волошин Игорь Петрович
Voloshin Igor Petrovich
кандидат технических наук, доцент, заведующий кафедрой информационных систем в экономике, Саратовский социально-экономический институт (филиал) РЭУ им. Г.В. Плеханова, Саратов
Cand. Sc. (Engineering), associate professor, head of the department of information systems in economics, Saratov socio-economic institute (branch) of Plekhanov Russian University of Economics, Saratov
e-mail: voloshin.i.p@gmail.com
Рассмотрена роль корпоративной архитектуры в работе с безопасностью в среде управления информацией предприятия, за которой следует более конкретная методология. Представлены современные достижения в области разработки программного обеспечения и предоставления информационных услуг для устранения разрыва между сотрудниками службы безопасности и другими заинтересованными сторонами.
Ключевые слова: архитектура предприятия, разработка программного обеспечения, информационная безопасность.
The article considers the role of corporate architecture in managing the security of the enterprise in the framework of information management followed by a more specific methodology. The author discusses latest solutions in software development and provision of information services for bridging the gap between security service employees and other interested parties.
Keywords: corporate architecture, software development, information security.
В современных условиях коммерческий успех любого предприятия в большой степени зависит от оперативности и мобильности бизнеса, от своевременности и быстроты принятия эффективных управленческих решений. А это невозможно без надежного и качественного информационного взаимодействия между различными участниками бизнес-процессов.
Крайне важно также удовлетворить потребности предприятия в обеспечении информационной безопасности. Это означает, что должны быть приняты соответствующие меры для защиты важнейших активов.
Трудно спроектировать, построить или управлять системой безопасности если неизвестно, что защищать, от кого и в какой степени.
Поэтому для построения эффективной системы безопасности должны быть определены наиболее важные активы, угрозы этим активам и насколько активы уязвимы для этих угроз.
Специалисты по вопросам безопасности, как правило, сосредоточены главным образом на защите конфиденциальности, целостности и доступности критически важной информации, а также на обеспечении подотчетности. Однако следует рассмотреть вопрос о многих других требованиях для обеспечения того, чтобы конечные пользователи во всей организации могли полагаться на своевременный и безопасный доступ к информации, в которой они нуждаются.
Сегодняшняя информационная среда является беспрецедентной с точки зрения богатства угроз, появляющихся в новых формах. Поэтому крайне важно иметь возможность быстро и регулярно разрабатывать, а также осуществлять изменения в информационной инфраструктуре.
Архитектура предприятия моделирует бизнес, технологии, а также процессы и управление для того, чтобы обеспечить общую точку
BÖ
ШшшяШ
зрения организации, которая поддерживает принятие решений.
Большинство существующих методов обеспечения безопасности сосредоточены на угрозах в отношении активов с особым вниманием к техническим уязвимостям в ИТ-инфраструктуре, и последующем внедрении средств контроля снижения рисков, вызванных этими угрозами. Однако такой подход, основанный на угрозе, не обязательно обеспечивает наилучшую информационную защиту.
Подход, основанный на угрозах, как правило, приводит к созданию сложной информационной системы и сетевых архитектур для управления и защиты информации о предприятии, обеспечении доступности логистической информации, сохранении конфиденциальности используемой информации и т. д. В нем могут также игнорироваться возможности того, что обмен информацией с другими предприятиями в контексте коалиционной целевой группы будет сопряжен с тем, что негативные последствия «не совместного использования» информации не рассматриваются.
Проектирование архитектуры предприятия начинается с понимания бизнеса и определения конкретных бизнес-процессов. Эти факторы определяются стратегиями предприятия и ключевыми бизнес-процессами, имеющими решающее значение для успеха.
Таким образом, необходимо вести инвентаризацию косвенных активов, которая затем может использоваться для оценки оперативной угрозы и риска. Когда оценка риска показывает конкурирующие конфиденциальность, целостность, требования доступности, эти конфликты теперь могут быть согласованы на основе операционного воздействия благодаря связи через прокси-активы с операционными приоритетами.
Мало того, что подход, основанный на угрозах, приводит к более сложным решениям, сопряженным с затратами, которых можно было бы избежать, он не учитывает потенциальные выгоды, которые могут быть реализованы при охвате некоторых дополнительных рисков. Начиная с бизнес-целей, действительно можно сосредоточиться на принятии рисков, а не на их избежании.
Таким образом, риск рассматривается с точки зрения риска для бизнеса, и архитектор безопасности вместе с архитектором бизнеса могут разработать архитектуру предприятия, которая решает эти риски. Существуют и другие
Научно-практический журнал. ISSN 2618-6780
модели, которые необходимы для охвата полного спектра бизнес-рисков. Один из дополнительных атрибутов, который необходимо смоделировать, - это «доверие», которое должно рассматриваться как бизнес-характеристика. Таким образом, архитектор по вопросам безопасности определяет все обмены информацией внутри организации или с внешними организациями, в которых должен быть обеспечен определенный уровень доверия. Необходимый уровень гарантий зависит от критичности отношений и чувствительности передаваемой информации. Затем архитектор безопасности может определить логические связи и спроецировать их на физическую ИТ-среду.
Другая модель, необходимая архитектору безопасности, - модель угроз [1]. Она представляет все известные события или элементы, которые могут нанести вред организации. Это может быть преднамеренное действие, например, вызванное враждебным государственным учреждением, или случайное непреднамеренное осознание, например, естественной опасности. Знание об угрозах, их вероятности возникновения и о том, какое воздействие они окажут на активы-посредники, имеет важное значение для определения приоритетности возможных смягчающих гарантий.
Точная информация о гарантиях является последней моделью, которую необходимо разработать. Существующие гарантии должны быть смоделированы равно как и любые известные пробелы в отношении известных угроз. Относительная зрелость мер контроля и гарантий безопасности определяется с использованием отраслевых рамок или наилучшей практики. На основе инвентаризации активов, доверительных отношений и выявленных угроз определяются неотъемлемые риски.
В контексте разработки программного обеспечения уязвимости, которые должны быть устранены, состоят из программного обеспечения низкого качества. Например, анализ сервисов дистанционного управления счетом показал, что далеко не все банки обеспечивают необходимый уровень защиты данных на стороне клиента [3].
В классическом подходе к разработке программного обеспечения разработчик взаимодействует с конечным пользователем на ранней стадии разработки, когда пользователь еще не сталкивается с какой-либо из проблем, которые будут присутствовать в окончательном операционном решении, и поэтому их
взаимоотношения нейтральны. Разработчики затем проектируют и строят систему, не обязательно принимая во внимание операционное воздействие и сложность, которые предполагают их выбор дизайна, что приводит к трудностям, когда система должна быть введена в эксплуатацию.
Особенно это касается разрабатываемого программного обеспечения, взаимодействующего с программным обеспечением других организаций. В результате информационные ресурсы учреждений плохо согласованы, т. е. различаются логикой данных и нормативно-справочной базой, используют различные форматы даных [2], что приведет к увеличению ручного труда при передаче информации.
Как только система будет полностью работоспособна, отношения между разработчиками и операционным персоналом, обслуживающим систему, становятся еще более конфрон-тационными, так как разработчики хотят регулярно обновлять программное обеспечение, чтобы исправить ошибки и добавить новые функции, тогда как операционный персонал неохотно осуществляет обновления для того, чтобы сохранить стабильность. И требования по безопасности на использование сертифицированного программного обеспечения тоже создают определенные проблемы с обновлениями. Кроме того, операционный персонал сталкивается с разочарованием пользователей, когда новые обновления, созданные командой разработчиков, нарушают систему или вызывают проблемы с производительностью и т. д.
Под влиянием современных эволюций в области разработки программного обеспечения и управления услугами во взаимоотношениях между заинтересованными сторонами происходят изменения. Действительно, внедрение библиотеки инфраструктуры информационных технологий, таких как ITIL, уменьшило конфликты между пользователями и операционным персоналом, в то время как поэтапные методологии разработки, такие как Agile, объединили пользователей и разработчиков, работающих в тесном взаимодействии, с активным участием заинтересованных сторон, приоритетными требованиями и т. д. Но связь между разработчиками и операционным персоналом по-прежнему остается конфронтационной.
Для решения данной проблемы, организации, которым необходимы частые выпуски программного обеспечения, используют набор практик DevOps (акроним от Development и
Operations), нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга. Операторы теперь могут вносить вклад в разработку новых приложений, а также их реализацию с самого начала и могут поддерживать весь процесс с помощью средств виртуализации, управления конфигурацией и непрерывной интеграции.
Подход DevOps представляет собой как проблемы, так и возможности в отношении безопасности. Ручные аудиты и официальные обзоры приведут к серьезному препятствию для работы DevOps, и поэтому чаще всего опускаются или ограничиваются важными вехами. Кроме того, поскольку один разработчик может полностью вносить изменения в операционную среду, у него есть сквозной контроль. Это нарушает сегрегацию обязанностей, которые могут потребоваться в качестве контроля безопасности в определенных приложениях или среде, и в этом случае необходимо добавить дополнительные контрольные точки.
Однако DevOps предоставляет целый ряд возможностей для сотрудника службы безопасности. Действительно, когда команды безопасности участвуют в процессе проектирования с самых ранних этапов, быстрое развитие и развертывание изменений, культура непрерывного совершенствования и в значительной степени автоматизация операций тестирования и валидации могут быть использованы для обеспечения безопасности. Небольшие изменения легче протестировать полностью, в том числе и для обеспечения безопасности. Патчи безопасности или улучшения могут постепенно развиваться и продвигаться в производство намного быстрее. Систематическое использование инструментов управления конфигурацией позволяет более легко стандартизировать безопасные конфигурации системы, а также использовать необходимые инструменты и конфигурации для ведения журнала, предупреждения и создания показателей безопасности.
Поэтому для удовлетворения потребностей пользователя наилучшим образом разработчики, операционный персонал и сотрудники службы безопасности должны работать вместе с пользователем в соответствии подходом SecDevOps (акроним от Security, Development и Operations), как показано ниже.
Отношения SecDevOps между заинтересованными сторонами
Для реализации стратегии информационной безопасности ключевым ресурсом являются люди. Крайне важно эффективно использовать имеющиеся ноу-хау в нужных местах, распределяя людей по наиболее полезным для них задачам. Но следует помнить, что навыки, связанные с информационной безопасностью, являются дефицитным ресурсом. Поскольку эксперты с этими скудными навыками, как правило, получают завышенные запросы, проекты занимают больше времени, чем планировалось, и оказывают влияние на последующие
проекты. Из-за отсутствия наиболее подходящего персонала на последующие проекты будет выделяться менее подходящий персонал, что еще больше увеличит вероятность возникновения проблем и еще более увеличит перерасход средств на эти проекты. Поэтому для новых групп важно иметь специалиста по безопасности, но по мере продвижения команды, один или несколько членов команды могут увеличить свои знания по безопасности, и таким образом специалист по безопасности сможет курировать сразу несколько разработок.
Библиографический список (References)
1. «Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных (Выписка)» (утверждена ФСТЭК РФ 15.02.2008).
2. Волошин И.П., Сорокина Е.В. Проблемы обеспечения информационной безопасности при организации информационного взаимодействия муниципальных учреждений // Информационная безопасность регионов. 2015. № 3 (20). С. 38-42.
3. Соколова Т.Н., Васильев В. С. Оценка информационной безопасности систем дистанционного банковского обслуживания // Информационная безопасность регионов. 2017. № 2 (27). С. 34-39.
1. «Bazovaya model' ugroz bezopasnosti personal'nykh dannykh pri ikh obrabotke v informatsionnykh sistemakh personal'nykh dannykh (Vypiska)» (utverzhdena FSTEK RF 15.02.2008) ["Basic model of threats to the security of personal data during processing in the information systems of personal data (Statement)" (approved by FSTEC RF on 15.02.2008)].
2. Voloshin I.P., Sorokina Ye.V. (2015) Problemy obe-specheniya informatsionnoy bezopasnosti pri organizatsii informatsionnogo vzaimodeystviya munitsipal'nykh uchrezh-deniy [Problems of ensuring information security in organizing information interaction of municipal institutions] // Infor-matsionnaya bezopasnost' regionov. № 3 (20). P. 38-42.
3. Sokolova T.N., Vasil'yev V.S. (2017) Otsenka infor-matsionnoy bezopasnosti sistem distantsionnogo bankovsk-ogo obsluzhivaniya [Evaluation of the information security of the system of remote banking services] // Informatsion-naya bezopasnost' regionov. № 2 (27). P. 34-39.
