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

Для кого данный материал

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

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

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

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

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

В чем польза статьи?

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

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

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

Если не хочется читать дальше

Если вы уже знаете как смешать управление рисками, внутренний контроль и безопасную разработку, или уже реализовали такую смесь у себя в компании, то можно не читать дальше...

Но если любопытство берет свое, то далее вас ожидает ОЧЕНЬ много текста и таблиц, так как изначально материал создавался как ВКР :-)

Также, материал принесет вам больше пользы, если вы почитаете об Управлении риском ИТ и Внедрении контроля над ИТ.

Итак, почему могут возникать издержки?

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

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

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

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

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

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

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

SDLC — это аббревиатура от «Жизненный цикл разработки программного обеспечения». Ею обозначают процесс разработки программного обеспечения.

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

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

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

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

Как пишет в своей статье Шарлотта Фриман (https://www.synopsys.com/blogs/software-security/secure-sdlc) SDL, или Secure SDLC, — это процесс, который позволяет поддерживать необходимый уровень безопасности системы на этапе разработки, а затем на протяжении всего срока эксплуатации. Эта концепция фокусируется на обеспечении безопасности разрабатываемого приложения, идентификации рисков и управлении ими.

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

В рамках данной статьи за основу был взят стандарт, предлагаемый и поддерживаемый компанией Microsoft - «Жизненный цикл безопасной разработки Майкрософт».

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

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

Компания Microsoft рекомендует осуществлять управление рисками через моделирование угроз. Угрозы являются ключевым элементом жизненного цикла Microsoft Security Development Lifecycle (https://www.microsoft.com/en-us/securityengineering/sdl). В стандарте выделяется пять основных этапов моделирования угроз:

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

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

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

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

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

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

Как пишет в своей статье Садик Альмуайрфи Аленези (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), анализ угроз позволяет более точно и полно понять потенциальные риски и последствия для компании, включая возможные финансовые издержки при разработке, внедрении и эксплуатации ПО.

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

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

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

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

Как утверждает Исаак Саколик (https://www.infoworld.com/article/3607914/6-security-risks-in-software-development-and-how-to-address-them.html) издержки также могут возникать в следствие реализации различных угроз из области информационной безопасности. В этом случае финансовые потери компаний могут быть существенными.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1)    Обоснованность автоматизации;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Риски на этапах жизненного цикла программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На основании проведенного исследования открытых источников и проведённых интервью с представителями ИТ-подразделений нескольких компаний можно утверждать, что в настоящее время в мировой практике является наиболее востребованной и набирающей все большую популярность разработка программных продуктов с учетом рисков, присущих информационной безопасности. Т.е. программные продукты при их разработке в рамках жизненного цикла учитывают требования информационной безопасности, так называемый принцип «Security by default».

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

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

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

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

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

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

1)    Этап проектирования и разработки;

2)    Этап внедрения;

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

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

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

Таблица 1. Матрица рисков 1

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

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

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

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

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

3)    Критерии качества: заблаговременная формулировка критериев качества (например: производительность, отсутствие ошибок, проведение необходимых тестов и др.), при этом для каждого типа релиза есть своя цель по качеству. Без соблюдения критериев качества релиз не выпускается.

4)    Визуализация: определение визуализации, т.е. представления о том, как конечный пользователь взаимодействует с программным продуктом.

5)    Минимально жизнеспособный продукт (MVP): ПО реализуется порционно, минимально необходимыми блоками, но сразу в соответствии с требованиями и с учетом различных критериев, что позволяет лучше контролировать процесс разработки, внедрения и поддержки, снижая издержки.

6)    Апробация минимально жизнеспособного продукта: тестирование продукта на отдельных функциональных подразделениях либо выпуск продукта под другим брендом от лица аффилированной компании. Это позволяет лучше понять потребности конечного потребителя и возможные связанные с этим проблемы.

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

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

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

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

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

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

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

Подготовка

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

Общие рекомендации по снижению рисков безопасности на этапе разработки и проектирования

Требования

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

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

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

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

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

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

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

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

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

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

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

В ходе таких оценок необходимо получить следующие сведения:

1)    Для каких компонентов проекта перед выпуском потребуется моделирование рисков?

2)    Для каких компонентов проекта перед выпуском потребуется анализ обеспечения безопасности при проектировании?

3)    Для каких компонентов проекта потребуется тестирование на проникновение, выполняемое взаимно согласованной группой (внешней по отношению к группе проекта), если такое тестирование необходимо?

4)    Существуют ли дополнительные требования к тестированию или анализу, которые консультант по безопасности (эксперт, внутренний или внешний, обладающий необходимыми знаниями в области ИБ и безопасной разработки) считает необходимыми для защиты от угроз?

5)    Какова конкретная область требований тестирования?

6)    Какова оценка влияния на конфиденциальность?

Проектирование

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

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

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

Технические условия проектирования рекомендуется сверять с функциональной спецификацией приложения. Функциональная спецификация должна:

1)    точно и полно описывать предполагаемое применение компонента или функции;

2)    описывать способы развертывания компонента или функции с обеспечением безопасности.

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

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

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

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

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

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

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

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

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

Реализация

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

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

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

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

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

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

Внедрение

Таблица 2. Матрица рисков 2

Общие рекомендации по снижению рисков безопасности на этапе внедрения

Проверка

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

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

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

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

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

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

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

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

Консультант по безопасности может потребовать проведения дополнительных fuzz-тестов или увеличения области и длительности fuzz-тестирования.

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

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

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

Внедрение

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

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

2)    Контактные данные лиц, имеющих право принимать решения и доступных 24 часа в сутки, семь дней в неделю.

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

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

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

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

Существует три возможных результата окончательной проверки безопасности:

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

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

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

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

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

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

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

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

Эксплуатация и развитие

Таблица 3. Матрица рисков 3

Общие рекомендации по снижению рисков безопасности на этапе эксплуатации и развития

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

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

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

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

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

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

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

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

В индустрии разработки ПО различают четыре типа обслуживания программного обеспечения:

1)    Корректирующее обслуживание;

2)    Адаптивное обслуживание;

3)    Улучшающее обслуживание;

4)    Профилактическое обслуживание.

Корректирующее обслуживание.

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

Адаптивное обслуживание.

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

Улучшающее обслуживание.

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

Профилактическое обслуживание.

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

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

Рекомендации менеджменту компаний при создании, внедрении, эксплуатации и развитии ПО

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

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

«Метод взвешенных коэффициентов»

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

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

«Метод взвешенных коэффициентов» для определения наиболее критичных угроз для компании состоит из следующих этапов:

1)    Для каждой идентифицированной угрозы X_n каждого жизненного цикла ПО руководство экспертным методом определяет «важность угрозы», т.е. уровень ее влияния на деятельности компании в целом по шкале от 1 до 3, где 1 – высокая критичность, 2 – средняя критичность, и 3 – низкая критичность. Важность угрозы обозначается как y_n.

2)    Для более углубленной оценки угрозы руководство формирует команду экспертов – представителей всех участвующих в принятии решения подразделений компании, от одного эксперта и более. Число экспертов, участвующих в оценке угрозы, обозначается как m.

3)    Для каждой угрозы каждый эксперт из сформированной команды (возможна анонимная оценка) проставляет свою оценку критичности угрозы от 1 до 5, где 1 – очень критично по мнению эксперта и 5 – незначительная угроза. Оценка эксперта i обозначается как Z_i.

4)    После проставления всех необходимых значений для угрозы X_n рассчитывается значение взвешенного коэффициента:

где y_i = y_n, если руководство компании считает важность угрозы равной для всех подразделений, представители которых участвуют в оценке критичности Z_i. Либо руководство выставляет разные веса y_i в диапазоне от 1 до 3, чтобы учесть различия в критичности угрозы для деятельности разных подразделений и степень влияния нарушений их деятельности на деятельность компании в целом в случае реализации угрозы.

Получив с помощью формулы (1) значения взвешенных коэффициентов K_n для каждой угрозы, руководство компании ранжирует угрозы по возрастанию K_n и самостоятельно устанавливает порог критичности K_с, далее отбирает как приоритетные те угрозы, для которых K_n ≥ K_c

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

Таблица 4. Пример шаблона оценки

Таблица 5. Пример шаблона разработки минимизирующих риски процедур

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

Опросный лист 1

Таблица 6 Анализ угроз на этапе разработки и проектирования (Пример)

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

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

Меры минимизации рисков

Таблица 7 Разработка минимизирующих риск мероприятий

Внедрение

Таблица 8. Анализ угроз на этапе внедрения ПО (Пример)

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

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

Меры минимизации рисков

Таблица 9. Разработка минимизирующих риск мероприятий

Эксплуатация и развитие

Таблица 10. Анализ угроз на этапе эксплуатации и развития ПО (Пример)

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

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

Меры минимизации рисков

Таблица 11. Разработка минимизирующих риск мероприятий

Перечень вопросов для руководства компании

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

Этап самодиагностики

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

Пример 1. Лист анализа готовности компании к новому ПО

Для более наглядной демонстрации проблемных областей, вопросы разделены на блоки:

1.     Полнота проработки проекта (ППП)

2.     Обеспечение ресурсами (ОР)

3.     Информационная безопасность (ИБ)

Таблица 12. Лист анализа готовности компании к новому ПО

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

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

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

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

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

Этап оценки поставщиков программного обеспечения

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

Пример 2. Лист анализа разработчика/поставщика и самого ПО

Для более наглядной демонстрации проблемных областей, вопросы разделены на блоки:

1.     Непрерывность сервиса и поддержки (НСП)

2.     Информационная безопасность (ИБ)

Таблица 13. Лист анализа разработчика/поставщика и самого ПО

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

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

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

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

Результаты апробации описанного подхода

Разработанные в данном исследовании опросные листы «Лист анализа готовности компании к новому ПО» и «Лист анализа разработчика/поставщика и самого ПО» были отправлены экспертам трех компаний и прошли экспертизу и апробацию. На основании собранных мнений экспертов были внесены корректировки.

«Лист анализа готовности компании к новому ПО» - новая редакция ряда вопросов опросного листа:

Таблица 14. Лист анализа готовности компании к новому ПО, с корректировками

 «Лист анализа разработчика/поставщика и самого ПО» - новая редакция вопросов опросного листа:

Таблица 15. Лист анализа разработчика/поставщика и самого ПО, с корректировками

Заключение

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

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

1.     Самодиагностика и диагностика поставщика и ПО;

2.     Идентификация угроз и рисков;

3.     Оценка и ранжирование угроз и рисков;

4.     Выработка минимизирующих и снижающих издержки мероприятий.

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

Также немаловажным аспектом помимо операционной эффективности выступает и повышение конкурентоспособности компании в следствие лучшего понимания и более эффективного управления рисками.