Текст книги "Управление риском ИТ. Основы"

Глава 3.
Управление рисками, внутренний контроль и безопасная разработка

За безопасность необходимо платить,

а за ее отсутствие расплачиваться.

Уинстон Черчилль

Для кого и зачем написана эта глава?

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

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

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

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

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

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

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

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

3.1. ПОЧЕМУ МОГУТ ВОЗНИКАТЬ ИЗДЕРЖКИ?

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

Почему случаются галлюцинации? Все достаточно просто – любая процедура или процесс в целом при подобном исполнении лишь создают чувство эффективности и надежности, тем самым порождая различные иллюзии и неоправданные ожидания. Это относится как к управлению ИТ, так и к управлению ИБ-процессами и процедурами.

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

Издержки и наиболее частые варианты

их возникновения

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

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

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

Например, в индустрии программного обеспечения различают два основных подхода: SDLC и SDL.

SDLC – это аббревиатура от «Жизненный цикл разработки программного обеспечения». Ею обозначают процесс разработки программного обеспечения, это структура, определяющая задачи, выполняемые на каждом этапе процесса разработки, внедрения и последующей эксплуатации ПО. SDLC – это классический процесс, используемый индустрией программного обеспечения для его проектирования, разработки и тестирования.

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

SDL – аббревиатура от «Жизненный цикл безопасной разработки», – более современный процесс, в настоящее время наиболее востребованный и становящийся в индустрии разработки программного обеспечения фактически обязательным стандартом.

Как пишет в своей статье Шарлотта Фриман1818
  https://www.synopsys.com


[Закрыть], SDL, или Secure SDLC, – это процесс, который позволяет поддерживать необходимый уровень безопасности системы на этапе разработки, а затем на протяжении всего срока эксплуатации. Эта концепция фокусируется на обеспечении безопасности разрабатываемого приложения, идентификации рисков и управлении ими.

В концепции разработки SDL управление рисками заключается в формировании требований к приложению, безопасному программированию, тестированию, сертификации, эксплуатации и развитию ПО.

За основу данной главы был взят стандарт, предлагаемый и поддерживаемый компанией Microsoft, – «Жизненный цикл безопасной разработки Майкрософт»1919
  https://www.microsoft.com/en-us/securityengineering/sdl


[Закрыть].

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

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

Компания Microsoft рекомендует осуществлять управление рисками через моделирование угроз. Угрозы являются ключевым элементом жизненного цикла Microsoft Security Development Lifecycle. В стандарте выделяется пять основных этапов моделирования угроз:

• определение требований безопасности к приложению;

• создание схемы приложения;

• выявление угроз;

• снижение угроз;

• подтверждение того, что угрозы были снижены до приемлемого уровня.

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

Как пишет в своей статье Садик Альмуайрфи Аленези2020
  Alenezi, Sadiq Almuairfi, «Security Risks in the Software Development Lifecycle» International Journal of Recent Technology and Engineering (IJRTE) ISSN: 2277—3878, Volume-8 Issue-3, September 2019.


[Закрыть], анализ угроз позволяет более точно и полно понять потенциальные риски и последствия для компании, включая возможные финансовые издержки при разработке, внедрении и эксплуатации ПО.

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

Для индустрии разработки программных продуктов характерным является качественный подход к управлению рисками жизненного цикла ПО. Единицами измерения служат инциденты.

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

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

Как утверждает Исаак Саколик2121
  https://www.infoworld.com


[Закрыть], издержки также могут возникать вследствие реализации различных угроз из области информационной безопасности. В этом случае финансовые потери компании могут быть существенными.

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

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

В ходе анализа также учитываются драйверы разработки или развития программного продукта. Драйверами могут быть как автоматизация процесса, так и, например, решение некой проблемы пользователей. Проводятся A/B2222
  A/B тестирование, также называемое сплит-тестированием или тестированием в группах, позволяет сравнить производительность двух версий контента, чтобы увидеть, какая из них больше привлекает посетителей/зрителей. Вы тестируете контрольную версию (A) против варианта (B), чтобы определить, какой из них более результативен с точки зрения метрик, которые важны для вас. https://en.wikipedia.org/wiki/A/B_testing


[Закрыть] эксперименты, готовятся MVP2323
  Минимально жизнеспособный продукт (MVP) – это концепция, которая подчеркивает влияние обучения на разработку нового продукта. https://www.agilealliance.org/glossary/mvp/


[Закрыть] с целью получения понимания, правильности вектора движения команды разработки и заказчика.

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

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

В ходе цифровой трансформации бизнеса и/или автоматизации отдельных процессов при существенном изменении, приобретенного ранее стандартного функционала ПО финансовые издержки могут быть обусловлены расходами компании на поддержку такого ПО, значительно трансформированного и доработанного под собственные нужды компании или нужды заказчика на всех последующих этапах жизненного цикла2424
  HOW MUCH DOES DIGITAL TRANSFORMATION COST?
  https://resources.hypeanddexter.com


[Закрыть].

В данном случае программное обеспечение уже является отдельной версией изначально созданного стандартного («out of the box») программного решения и либо потребует в дальнейшем нестандартного подхода в рамках поддержки, либо его полной замены.

Этапы жизненного цикла разработки

программного обеспечения

Обобщая изложенную выше информацию, рассмотрим варианты возникновения издержек.

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

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

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

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

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

Третий вариант: масс-маркет, компания-производитель несет издержки в процессе понимания потребностей не только собственных, но и в первую очередь своих потенциальных клиентов, при формировании «портрета» клиента, причин, по которым различным клиентам мог бы понадобиться тот или иной функционал, «фича» и/или автоматизация.

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

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

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

Анализ практики создания, внедрения и развития ПО

в компаниях малого или среднего бизнеса

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

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

Проведенное автором исследование в первую очередь ориентировано на компании, не являющиеся представителями финансового, страхового либо иной категории бизнеса, у которых отсутствует потребность строго соответствовать требованиям Центрального Банка РФ, нет обязанности соблюдать четко определенные стандарты и требования к управлению рисками.

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

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

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

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

Финансовые издержки на этапах жизненного цикла

программного обеспечения

Пример 1. Данный случай описал руководитель одной из компаний в ходе интервью. Его фирма закупила у компании HP программный продукт (HP Product Management). В процессе внедрения система существенно дорабатывалась, адаптировалась и изменялась с учетом требований и специфики бизнес-процессов заказчика. В результате сама компания-заказчик несла существенные расходы, превышающие стоимость стандартных услуг разработчика данного программного продукта.

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

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

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

• обоснованность автоматизации;

• возможность использования максимально стандартного функционала;

• возможные издержки на эксплуатацию стандартной версии ПО в противовес существенно измененной версии ПО.

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

Пример 2. Недостаточный контроль качества при выпуске программного продукта на рынок компанией-разработчиком. Данная проблема может также относиться и к компании, внедряющей у себя программный продукт.

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

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

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

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

При этом в подобном случае практически невозможно подсчитать будущие потери от снижения уровня доверия к бренду компании со стороны поставщиков и клиентов.

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

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

Компании могут тратить до 70%, от совокупных расходов на ИТ, на разработку нового ПО и до 30% – на поддержку старого. Нередки случаи, когда при старой архитектуре стоимость поддержки может достигать 50% от общего бюджета на доработку и поддержку ПО. При этом исправление ошибок в одном месте может формировать ошибки в других местах программного продукта.

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

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

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

Риски на этапах жизненного цикла

программного обеспечения

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

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

На базе проанализированных стандартов по управлению рисками, присущими программному обеспечению, и с учетом задачи сокращения издержек при разработке, внедрении и последующей эксплуатации ПО за основу перечня рисков, используемых в данной работе, был взят международный стандарт по финансовому аудиту ISA 315/МСА 315 [ISA 315].

Стандарт ISA 315/Пункт А174 утверждает следующее: степень и характер применимых рисков, связанных с использованием ИТ, варьируются в зависимости от характера и характеристик идентифицированных ИТ-приложений и других аспектов ИТ-среды. Применимые риски, связанные с использованием ИТ, также могут быть определены в связи с кибербезопасностью.

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

Таким образом, можно утверждать, что чем сложнее архитектура и функционал программного обеспечения, тем сложнее управлять рисками, присущими такому ПО (например SAP ERP).

Стандарт ISA 315/МСА 315/Пункт 18 определяет типовые группы рисков, присущих ИТ-системам, которые включают риски:

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

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

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

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

• несанкционированного изменения мастер-данных (справочных данных компании);

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

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

• неправомерного вмешательства в автоматизированные процессы и финансово значимые данные;

• возможной потери данных или невозможности доступа к данным в случае необходимости.

Стандарт ISA 315/МСА 315/Пункт 19 рассматривает также риски, связанные с несанкционированным доступом со стороны внутренних или внешних сторон. Их часто называют рисками кибербезопасности.

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

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

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

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

Опираясь на собственный многолетний опыт в управлении рисками, внутреннем контроле и аудите, а также открытые источники и результаты интервью с представителями ИТ-подразделений компаний, можно утверждать, что в настоящее время в мировой практике является наиболее востребованной и набирающей все большую популярность разработка программных продуктов с учетом рисков, присущих информационной безопасности. То есть программные продукты при их разработке в рамках жизненного цикла учитывают требования информационной безопасности, так называемый принцип «Security by default»2525
  https://en.wikipedia.org/wiki/Secure_by_default


[Закрыть].

Вместе с тем безопасная разработка создает дополнительные затраты, обосновать которые позволяют риски потерь для компании:

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

• риски остановки сервисов, как внутренних, так и внешних, которые также могут принести немалый ущерб компании и привести к рискам, обозначенным в пункте выше.

Таким образом, «безопасную разработку» можно считать элементом управления рисками компании, при котором вырабатываются предупреждающие меры, позволяющие снизить либо не допустить событий, способных причинить ущерб компании.

В рамках безопасной разработки риски информационной безопасности рассматриваются на всех этапах жизненного цикла программного обеспечения.

Можно выделить три основных этапа жизненного цикла ПО, на которых возможна реализация различных рисков информационной безопасности и, как следствие, возникновение непредвиденных финансовых издержек для компании:

• этап проектирования и разработки;

• этап внедрения;

• этап последующей эксплуатации и развития.

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

Разработка и проектирование

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

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

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

1. Итерационный подход и ограничение объема: ограничение объема, входящего в каждую выпускаемую версию программного продукта (релиза), с разделением минимум на две итерации: первую и последующую, в которых четко обозначены цель релиза, объем разработки и сроки. Данный подход позволяет выпускать программные продукты или различного рода и объема изменения в ПО регулярно с приемлемым качеством, а также сокращает «отвлекающие» запросы на доработки, при которых расходуются человеческие ресурсы и время.