Поделиться
Очевидно, что необходимость перехода на отечественное программное обеспечение стало главным выводом, которое сделало большинство отраслевых специалистов. Однако при любом ПО без сбоев не бывает, поэтому нужно относится к ним не как катастрофе, а как внештатной ситуации, научится использовать средства резервирования и восстановления, уверен Дмитрий Стефановский, завкафедрой информационных систем ГУУ.
Есть и другая важная особенность - разработка отечественного ПО идет в условиях ограниченного доступа к технологиям и инновациям, используемым в западных продуктах. А это значит, что информационное пространство будет все больше распадаться на отдельные острова, считает Олег Чумаков, директор по развитию "Арбайт". Следствием островного развития станет как минимум несовместимость программных продуктов, как максимум - их неравномерное развитие.
В такой ситуации важна внутренняя кооперация, например создание единой экосистемы для синхронизации разработок отдельных компаний, способствующей массовому производству и внедрению российского оборудования, уверен Григорий Урьев, гендиректор "Синтерра Медиа". Однако для эффективной работы такой экосистемы нужно предпринять ряд мер. Прежде всего - разработать "правила игры" и стандарты качества ПО, предусматривающие обязательное тестирование безопасности, функциональности и совместимости, а также регулярные аудиты. Должна быть установлена ответственность производителей за уязвимости в продуктах, а также простимулирована заинтересованность пользователей в их поиске. Кроме того, правильным будет финансовое стимулирование разработчиков и пользователей, повышение образовательного уровня, прозрачность и открытость процессов, а также расширение господдержки, уверен Максим Рогов, независимый исследователь систем безопасности.
- В идеальной ситуации государства и государственные объединения должны обеспечить законодательную базу для определения ответственности поставщика ИТ-решения за подобные сбои и компенсации потерь за время простоя для бизнеса и невозможности воспользоваться услугой для клиентов пострадавшего бизнеса, особенно если сбой затронул критически важные отрасли. Причем последствия для вендора должны быть изначально известны и озвучены, а не в случае происшествия по результатам расследования, которое может идти долгие годы и с течением времени терять инерцию, - резюмирует Денис Ходасков, гендиректор HD Tech.
Что касается практических уроков для пользователей и бизнеса "на каждый день", то для них также справедливо более внимательное отношение к тестированию. Если от какого-либо продукта зависит работоспособность критических систем компании, то все обновления необходимо проверять на тестовых стендах, своего рода "песочницах", которые по функционалу и структуре имитируют основную информационную систему.
Для этого можно использовать цифровых двойников, чтобы сначала апробировать какой-либо продукт на виртуальной системе и только потом внедрить его в работу, комментирует Константин Горбунов, web-разработчик компании "Код Безопасности".
Антон Мартьянов, директор департамента в проектном офисе "Павелецкая" компании "Первый Бит":
- Штатные сотрудники обычно не несут ответственности за убытки. Исключением является случай, когда внутренняя ИТ-служба на самом деле является выделенной дочерней компанией, официально выступающей подрядчиком по договору. В таком случае генеральный директор и учредитель несут хоть какую-то ответственность за принятие управленческих решений по договору подряда. При этом учредитель или владелец у обоих сторон в таких случаях часто совпадает, поэтому и ответственность ляжет только на должностное лицо - генерального директора "ИТ-дочки". Поэтому я советую диверсифицировать риски, разделяя ответственность между внутренней ИТ-службой и внешним подрядчиком - ИТ-интегратором.
Кроме того, проработайте вопрос резервных договоров по SLA (service level agreement, соглашение об уровне сервиса), которые должны будут вступать в действие при возникновении подобных сбоев. Доверяй, но проверяй и контролируй - приобретайте и используйте собственные средства мониторинга угроз и рисков. Они помогут поддерживать безопасность компании хотя бы на "гигиеническом минимуме". Также в рамках управления рисками нужно проработать план B (переход на резервное ПО) и даже план С (переход на ручные процессы без применения ПО).
Александр Михайлов, директор по развитию бизнеса ИТ-компании TeamIdea:
- Я выделю пять важных действий, которые нужно предпринять.
1. При выборе, установке и обновлении ПО проверять их работоспособность. Возможно, выполнять тестовую установку на независимую систему.
2. Проводить дополнительные проверки (аудит) на кибербезопасность. При необходимости выносить критически важные системы в закрытый IT-контур.
3. Вводить и соблюдать процедуры по архивации и резервному копированию данных (бэкап). Это позволит в случае непредвиденного сбоя восстановить данные.
4. Прорабатывать варианты выполнения критически важных операций и функций предприятия в офлайн-режиме. Например, предусмотреть возможность ручного заполнения каких-либо документов, требуемых для обеспечения логистики или приема клиентов. Это актуально, например, для медицинских учреждений.
5. Проводить регулярное информирование и обучение сотрудников о возможных последствиях установки нелицензионного ПО или "прохода" по непроверенным ссылкам. Особенно это касается ситуаций, когда сотрудники подключаются с личного ПК.