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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как пишет в своей статье Шарлотта Фриман: SDL, или Secure SDLC, — это процесс, который позволяет поддерживать необходимый уровень безопасности системы на этапе разработки, а затем на протяжении всего срока эксплуатации. Эта концепция фокусируется на обеспечении безопасности разрабатываемого приложения, идентификации рисков и управлении ими.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В ходе анализа также учитываются драйверы разработки или развития программного продукта. Драйверами могут быть как автоматизация процесса, так и, например, решение некой проблемы пользователей. Проводятся 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. Для каждой идентифицированной угрозы Xn каждого жизненного цикла ПО руководство экспертным методом определяет «важность угрозы», т.е. уровень ее влияния на деятельности компании в целом по шкале от 1 до 3, где 1 – высокая критичность, 2 – средняя критичность, и 3 – низкая критичность. Важность угрозы обозначается как yn.

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

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

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

Формула (1)
Формула (1)

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

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

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

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

Угрозы

 

yn

Zn

K

1

 

 

 

 

 

 

 

 

 

 

 

 

Количество участников

m

 

 

 

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

Угрозы

Минимизирующие риск мероприятия

1

Не определены направления развития ПО

Определена стратегия развития внедряемого ПО

2

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

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

 

 

 

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

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

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

Угрозы

Важность

Участник 1

Участник 2

Участник 3

Совокупная сумма баллов

1

Нечетко определены цель и функции ПО

1

2

1

5

2,7

2

Нереалистичность требований к разрабатываемому ПО

1

3

4

3

3,3

3

Не определены критерии успешности реализации каждого требования

1

2

3

1

2

4

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

1

2

4

1

2,3

5

Не осуществляется регулярный контроль хода реализации разработки ПО

1

4

3

5

4

6

Не определена визуальная составляющая ПО

1

2

2

5

3

7

Потребности заказчика непоняты, либо не поняты в полном объеме

1

3

4

2

3

8

Отсутствует регулярный мониторинг соответствия ПО ожиданиям заказчика

1

1

3

5

3

9

Отвлечение команды разработки на другие задачи

1

3

3

1

2,3

10

Недостаточная экспертиза команды разработки в вопросах ИБ

1

5

2

4

3,7

11

Не определены требования ИБ к разрабатываемому ПО

1

4

4

5

4,3

12

В разрабатываемом ПО не учтены механизмы защиты конфиденциальности

1

1

3

5

3

 

Количество участников

3

 

 

 

 

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

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

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

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

Угрозы

Минимизирующие риск мероприятия

1

Нечетко определены цель и функции ПО

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

2

Нереалистичность требований к разрабатываемому ПО

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

3

Не определены критерии успешности реализации каждого требования

Определить и согласовать со всеми заинтересованными сторонами критерии успешности реализации требований к ПО

4

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

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

5

Не осуществляется регулярный контроль хода реализации разработки ПО

Внедрить регулярную процедура контроля статуса реализации разработки ПО

6

Не определена визуальная составляющая ПО

Определить требования к визуальному интерфейсу ПО

7

Потребности заказчика непоняты, либо не поняты в полном объеме

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

8

Отсутствует регулярный мониторинг соответствия ПО ожиданиям заказчика

Внедрить регулярную процедуру мониторинга соответствия свойств ПО и/или его нового функционала ожиданиям заказчика

9

Отвлечение команды разработки на другие задачи

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

10

Недостаточная экспертиза команды разработки в вопросах ИБ

Разработать необходимую документацию и провести необходимые тренинги в области безопасности ПО

11

Не определены требования ИБ к разрабатываемому ПО

Определить и согласовать со всеми заинтересованными сторонами требования ИБ к ПО

12

В разрабатываемом ПО не учтены механизмы защиты конфиденциальности

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

Внедрение

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

Угрозы

Важность

Участник 1

Участник 2

Участник 3

Совокупная сумма баллов

1

Функционал внедряемого ПО не соответствует первоначально запланированному

1

3

1

3

2,3

2

В работе разработанного программного продукта присутствуют ошибки

1

3

1

1

1,7

3

Не согласованы достаточные условия по исправлению ошибок во внедряемом ПО

1

4

4

1

3

4

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

1

5

5

3

4,3

5

Несовместимость разработанного ПО с уже существующим и эксплуатируемым в компании

1

1

5

2

2,7

6

Некорректная интеграция разработанного ПО с уже внедренным ПО в компании

1

4

1

2

2,3

7

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

1

5

5

4

4,7

8

Неполное или несвоевременное тестирование ПО при внедрении

1

4

2

1

2,3

9

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

1

4

1

2

2,3

10

Разработчики имеют доступ к промышленной среде разработки

1

3

2

1

2

11

Функционал ПО позволят вносить изменения в промышленной среде

1

1

1

1

1

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

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

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

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

Угрозы

Минимизирующие риск мероприятия

1

Функционал внедряемого ПО не соответствует первоначально запланированному

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

2

В работе разработанного программного продукта присутствуют ошибки

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

3

Не согласованы достаточные условия по исправлению ошибок во внедряемом ПО

Определены требования к протоколу устранения замечаний заказчика

4

При приемке разработанного ПО тестирование не проведено должным образом и в необходимом объеме

Определены требования к процедурам тестирования ПО и его отдельных элементов

5

Несовместимость разработанного ПО с уже существующим и эксплуатируемым в компании

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

6

Некорректная интеграция разработанного ПО с уже внедренным ПО в компании

Разрабатываемое ПО проходит регулярное тестирование на совместимость с уже существующим ПО

7

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

Угрозы ИБ регулярно анализируются и пересматриваются

8

Неполное или несвоевременное тестирование ПО при внедрении

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

9

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

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

10

Разработчики имеют доступ к промышленной среде разработки

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

11

Функционал ПО позволят вносить изменения в промышленной среде

Функционал ПО позволяет ограничить внесение изменений

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

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

Угрозы

Важность

Участник 1

Участник 2

Участник 3

Совокупная сумма баллов

1

Не определены направления развития ПО

1

3

1

5

3

2

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

1

4

5

1

3,3

3

Недостаточное финансирование развития ПО

1

1

2

4

2,3

4

Отказ в поддержке или доработке ПО производителем

1

1

1

4

2

5

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

1

5

1

2

2,7

6

Ошибки при внесении изменений в программный код и настройки ПО

1

4

2

3

3

7

Отсутствие процедур тестирования вносимых изменений в ПО

1

5

3

1

3

8

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

1

2

1

4

2,3

9

Доступ разработчиков в промышленную среду эксплуатации

1

3

1

1

1,7

10

Недостаточные настройки безопасности ПО

1

4

3

1

2,7

11

Некорректное управление доступом к программному обеспечению либо нарушение принципа разграничений полномочий

1

5

2

2

3

12

Отсутствие либо нарушение процедур резервного копирования

1

4

4

5

4,3

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

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

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

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

Угрозы

Минимизирующие риск мероприятия

1

Не определены направления развития ПО

Определена стратегия развития внедряемого ПО

2

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

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

3

Недостаточное финансирование развития ПО

Определена стратегия финансирования внедряемого ПО. Запланировано и согласовано бюджетирование для всех этапов жизненного цикла ПО

4

Отказ в поддержке или доработке ПО производителем

Предусмотрены варианты сопровождения ПО своими ресурсами, либо иными подрядчиками

5

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

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

6

Ошибки при внесении изменений в программный код и настройки ПО

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

7

Отсутствие процедур тестирования вносимых изменений в ПО

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

8

Неправомерное вмешательство в автоматизированные процессы и финансово значимые данные компании.

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

9

Доступ разработчиков в продуктивную среду эксплуатации

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

10

Недостаточные настройки безопасности ПО

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

11

Некорректное управление доступом к программному обеспечению либо нарушение принципа разграничений полномочий

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

12

Отсутствие либо нарушение процедур резервного копирования

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

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

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

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

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

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

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

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

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

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

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

Блок

Вопрос/Тема для анализа экспертной группой компании

Ответ

ППП

1

Определены ли цель и требуемые функции ПО?

Да/Нет

2

Сможет ли быть обеспечена совместимость разрабатываемого/покупаемого ПО с уже существующим и эксплуатируемым ПО в компании?

Да/Нет

3

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

Да/Нет

4

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

Да/Нет

5

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

Да/Нет

ОР

 

6

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

Да/Нет

7

Определены ли источники и сроки финансирования на разработку и последующее развитие ПО?

Да/Нет

8

Определены ли направления и этапы развития ПО, включая корректирующее, адаптивное и улучшающее обслуживание?

Да/Нет

9

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

Да/Нет

10

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

Да/Нет

11

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

Да/Нет

12

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

Да/Нет

13

Согласована ли модель лицензирования ПО (в случае его покупки [20]) со всеми сторонами, влияющими на финансирование эксплуатации и развития ПО в будущем?

Да/Нет

ИБ

 

14

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

Да/Нет

15

Готова ли ролевая модель, которая будет применяться в ПО?

Да/Нет

16

Учитывает ли ролевая модель принципы разграничения полномочий SoD?

Да/Нет

17

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

Да/Нет

18

Позволяет ли ПО соблюдать принцип разграничения полномочий?

Да/Нет

19

Будет ли производитель и/или разработчик ПО иметь доступ к алгоритмам, данным и информации, обрабатываемого ПО?

Да/Нет

20

Есть ли в компании сотрудник либо команда, отвечающая за вопросы информационной безопасности?

Да/Нет

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

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

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

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

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

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

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

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

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

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

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

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

Блок

Вопрос/Тема для анализа экспертной группой компании

Ответ

ИБ

1

Внедрены ли процессы и инструменты безопасной разработки в компании-разработчике/поставщике ПО?

Да/Нет

2

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

Да/Нет

3

Обеспечивают ли инструменты, используемые в разработке разработчиком/поставщиком ПО, безопасность кода и функционала ПО?

Да/Нет

4

Существуют ли политики и процедуры у разработчика/поставщика ПО, направленные на контроль безопасности при использовании свободно распространяемого кода и библиотек?

Да/Нет

5

Обладает ли инструментами и осуществляет ли разработчик/поставщик ПО статический и динамический анализ кода и функционала ПО на предмет рисков информационной безопасности?

Да/Нет

6

Соответствует ли функционал поставляемого ПО в контексте информационной безопасности требованиям служб информационной безопасности и внутреннего контроля компании-заказчика?

Да/Нет

7

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

Да/Нет

8

Имеют ли доступ разработчики ПО в промышленную среду эксплуатации разрабатываемого ПО?

Да/Нет

9

Позволяют ли процессы разработчика/поставщика ПО обеспечить внесение только протестированных и согласованных со стороны заказчика изменений в ПО?

Да/Нет

НСП

10

Готов ли разработчик/поставщик ПО осуществлять регулярный контроль хода реализации разработки ПО с представителями компании-заказчика?

Да/Нет

НСП

11

Есть ли подтверждение понимания разработчиком/поставщиком ПО потребностей заказчика в полном объеме?

Да/Нет

НСП

12

Готов ли разработчик/поставщик ПО осуществлять регулярный мониторинг и контроль соответствия ПО требованиям и ожиданиям заказчика совместно с представителями заказчика?

Да/Нет

НСП

13

Как быстро и при каких условиях разработчик/поставщик ПО готов реагировать на устранение ошибок в работе ПО?

Да/Нет

НСП

14

Обеспечивает ли разработчик/поставщик ПО сохранность и доступность разрабатываемого ПО на случай аварийной ситуации?

Да/Нет

НСП

15

Готов ли разработчик/поставщик ПО в согласованные с компанией-заказчиком сроки предоставить/заменить недоступный ключевой при разработке ПО персонал?

Да/Нет

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

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

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

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

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

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

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

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

Вопрос/Тема для анализа экспертной группой компании

Ответ

7

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

Да/Нет

3

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

Да/Нет

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

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

Вопрос/Тема для анализа экспертной группой компании

Ответ

1

Внедрены ли процессы [12], [21] и инструменты безопасной разработки [22] в компании-разработчике/поставщике ПО?

Да/Нет

2

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

Да/Нет

3

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

Да/Нет

6

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

Да/Нет

7

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

Да/Нет

11

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

Да/Нет

Заключение

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

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

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

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

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

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

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

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

Комментарии (4)


  1. Noctisik
    02.11.2023 20:06

    Статью читать не просто, но она получилась информативной по учёту рисков при внедрении ПО. Эта часть мне понравилась, поскольку я могу её понять на собственном опыте и соотнести правильность написанного с тем, что увидел я. Некоторые вещи я не встречал, но готов поверить, что они могут быть.

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

    Статья понравилась.


    1. MTorn Автор
      02.11.2023 20:06

      Привет! Спасибо, хорошая идея:) нужно подумать


  1. arTk_ev
    02.11.2023 20:06
    +1

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

    Мера критичности зависит от вероятности регрессии багов и времени исправления.

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

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

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


    1. MTorn Автор
      02.11.2023 20:06

      Хорошая мысль. Стоит отдельной проработки. Однако, возможно, уже реализована в инструментах анализа кода. Спасибо, что поделились!