Защита интересов бизнеса при внедрении ИТ систем, их разработке и обслуживании
Статья начальника отдела ИБ ООО "IT-TEAM SERVICE" Антона Ракитского вышла в журнале «Управление предприятием», издаваемом Международным центром финансово-экономического развития - Узбекистан. Статья вышла в журнале №11 за ноябрь 2020 г.
Полную версию статьи можно прочитать на сайте издания, в электронной версии журнала. Она доступна на русском и узбекском языках. Ниже приводится авторская редакция статьи.
Для управления информационными технологиями на крупных предприятиях есть отдельные специалисты - ИТ-директора или CIO (англ. Chief Information Officer). Именно они ведут большую часть дел, связанных с информатизацией. Но базовые принципы и проблемы внедрения новых ИТ систем и появляющиеся риски нужно понимать и высшему руководству предприятия.
Жизненный цикл информационных систем.
Всё чаще в управлении информационными технологиями и безопасностью применяется термин «жизненный цикл». Это развитие системы, продукта, услуги, проекта, начиная со стадии разработки и заканчивая прекращением применения. Когда говорят про управление на протяжении всего жизненного цикла, то имеется в виду, что охвачены все его периоды. И безопасность должна обеспечиваться на необходимом уровне на каждом из них. Ведь, согласитесь, если утечка конфиденциальной информации произойдёт из устаревшей и снятой с эксплуатации системы - предприятию от этого будет не легче, а ущерб от этого не станет меньше. Подробнее о жизненном цикле программного обеспечения можно узнать в государственных стандартах Oʻz DSt ISO/IEC/IEEE 12207:2018 «Информационная технология. Процессы жизненного цикла программного обеспечения» и Oʻz DSt ISO/IEC 14764:2008 «Разработка программного обеспечения. Процессы жизненного цикла программного обеспечения. Сопровождение программных средств».
Разработка технического задания.
Планирование создания новой информационной системы желательно начинать с подготовки технического задания. Разрабатывать его от простого - к сложному. Заказчик системы и её будущие пользователи описывают желаемый функционал, что и как система должна делать, входные и выходные данные. Очень важно ещё на этапе планирования подключить к процессу все заинтересованные стороны. Ведь систему в дальнейшем будет эксплуатировать, поддерживать ИТ-служба предприятия, вводить данные кадровая служба, канцелярия, бухгалтерия и т.д. Например, ИТ-службе нужно будет понимать техническую специфику новой системы, заложить её совместимость с уже имеющейся инфраструктурой. Важен и методический аспект - предусмотрено ли обучение новой системе. Ведь, к сожалению, часто всё происходит ровно наоборот - на презентации был показан проект, который понравился руководству. Его волюнтаристски внедряют. Но как работать с новой системой пользователи элементарно не знают, а у ИТ-службы может не хватить для работы системы ни технических средств (элементарно нет свободного сервера), ни знаний. В итоге новая и, возможно, хорошая система саботируется большей частью коллектива.
Другая очень распространённая проблема - отсутствие инструкций по работе с системой. Когда потребитель приобретает любую сложную бытовую технику - от пылесоса до автомобиля, то в комплекте всегда идёт инструкция по эксплуатации. Некоторые даже её читают. А при разработке новых систем этот этап часто пропускается. Поэтому особенно важно именно на стадии составления требований к новой системе, подготовки ТЗ, заложить в него создание подробных инструкций. Причём отдельно для рядовых бизнес-пользователей, для администратора систем, инструкции по технической поддержке. Ведь без инструкции, при возникновении проблемы, пользователю будет просто не к кому обратиться с вопросом. Также на уровне ТЗ оговариваются языки, на которых будет доступен интерфейс системы, при разработке мобильных приложений - поддерживаемые платформы (Android, iOS), форматы данных, формы отчётов. Если этого не сделать то разработчики всё сделают по собственному разумению и будут формально правы, ведь они не могут предугадать всех пожеланий заказчиков. В итоге возникают взаимные претензии между заказчиками и исполнителями, разбирательства, а доработка или переделка требует времени и денег. Поэтому тщательное и подробное техническое задание очень важно. Существует практика, когда техническое задание на систему пишет сам разработчик. Нарушения в этом нет, но, очевидно, что формулировки в этом случае будут скорее выгодны ему для успешной сдачи работ, чем заказчику. В любом случае, лучше всё прописать и, что называется, «договориться на берегу», чем потом спорить - что́ имелось в виду изначально, а что́ появилось по ходу работ.
Кроме чисто функциональных требований к системе, которые предъявляет бизнес, существуют ещё дополнительные специфические требования:
1. Для органов государственного и хозяйственного управления, органов государственной власти на местах при разработке технических заданий необходимо учитывать требования государственного стандарта O'z DSt 1987:2018 «Техническое задание на создание информационной системы». В нём содержатся примеры и даже рекомендуемая структура технического задания. Стандарт будет полезен всем, как минимум в качестве справочника, чтобы случайно не упустить что-то важное.
2. Также для госорганов при разработке и внедрении систем необходимо учитывать специальный документ по информационной безопасности - Требования обеспечения информационной безопасности органов государственного и хозяйственного управления, государственной власти на местах (Приложение № 2 к протоколу Техсовета №7 от 17.11.2017 г.)
3. Если в составе программного комплекса планируется использовать средства криптографической защиты информации (проще - шифрование), то нужно иметь в виду, что обязательной сертификации подлежат средства технической и криптографической защиты информации, если они разрабатываются как часть ПО (см «Перечень производимых в Республике Узбекистан и ввозимых на ее территорию видов продукции, подлежащих обязательной сертификации», приложение № 1 к постановлению Кабинета Министров от 28 апреля 2011 года № 122). При этом сама деятельность по проектированию, разработке, производству, реализации, ремонту и использованию средств криптографической защиты информации является лицензируемым видом деятельности. Лицензирующий орган - Служба государственной безопасности. Будут ли входить в состав разрабатываемого ПО функционал по криптрографической защите? Есть ли у разработчика соответствующие лицензии?
А вот деятельность, связанная с применением средств электронной цифровой подписи (ЭЦП), обеспечивающих её создание в электронном документе и подтверждение подлинности - лицензированию не подлежит (ПКМ № 242 21.11.2007).
4. Для госорганов может существовать необходимость согласовывать разработанное техническое задание в различных службах. Например, ТЗ на информационно-коммуникационные технологии, аппаратные средства и программные продукты, средства защиты и иные технические средства согласовываются в обязательном порядке с Центром кибербезопасности (№ПП-4024 21.11.2018).
Т.е. составление технического задания может потребовать привлечения ещё и юридической службы. Иначе есть риск, что вновь внедрённая система в результате будет нарушать требование каких-то регламентов.
Всё больше систем делаются доступными извне самой организации. Или изначально разрабатываются доступными для неограниченного круга пользователей. Примеры - сайты организации, информационные порталы, службы обратной связи с потребителями и др. Во многом, именно такая информационная система становится «лицом» организации. Особенно для сервисных организаций, служб доставки, интернет-магазинов. Поэтому, внедряя такую систему, нужно предусмотреть отказоустойчивость системы. Также, работа в публичном пространстве автоматически возлагает требования по соблюдению целого ряда нормативов. Самый яркий пример - закон «О персональных данных». Если пользователи системы, регистрируясь в системе, сообщают свои персональные данные, то нужно явным образом получать согласие на их обработку, декларировать сроки и цели такой обработки, обеспечивать должным образом их безопасность (подробнее об этом см. статью в журнале №11 (149) за ноябрь 2019 г.)
Часто возникает необходимость, чтобы действия пользователей в системе были юридически значимыми. А документы и подписи на них приравнивались к собственноручным. Для этого применяются механизмы электронной цифровой подписи (ЭЦП). Применение таких технологий требует особой тщательности, чтобы исключить компрометации данных и поддерживать доверие пользователей к таким системам. В этой связи кроме чисто технических мер, нужно ещё и явно демонстрировать пользователям, какие данные и как накапливаются в системе, какие документы и для чего он подписывает своей ЭЦП. Яркие примеры таких систем - системы дистанционного банковского обслуживания, единый портал интерактивных государственных услуг, система электронных счетов-фактур.
Любая сложная система, особенно после внедрения, это «живой организм», в который постоянно вносятся изменения и исправления. За такой модернизацией нужно следить не менее тщательно чем за первоначальной разработкой. Скорее всего, сопровождением системы будет заниматься та же организация, что и разрабатывала её. На уровне официального соглашения, договора, необходимо оговорить не только обязательства по конфиденциальности, но и правила по модернизации информационной системы (статья об аутсорсине ИТ-услуг вышла в нашем журнале №3 (141) за 2019 г.)
Каждое изменение, вносимое в систему, должно сначала тестироваться, отрабатываться на опытном стенде, и только потом изменение вносится в «боевую» систему. Иначе, устраняя одну проблему, можно «сломать» что-то в другом месте. Каждое такое изменение должно чётко документироваться и одобряться владельцем системы. Т.е. должна быть возможность отследить когда появился тот или иной функционал в системе, по чьей заявке, кто проводил тестирование и кто одобрил ввод в эксплуатацию.
У разработчиков-программистов существует практика создавать копию основной системы - тестовый стенд. И все изменения проверять, тестировать сначала на этом стенде. Для создания максимальной правдоподобности такого тестирования велик соблазн просто взять и скопировать все данные из основной системы в тестовую. Такой подход таит очень большие риски. Ведь доступ к тестовой системе защищается не так тщательно, как к основной. Штатные службы безопасности практически не контролируют деятельность разработчиков. Представьте, что такая тестовая среда создается для автоматизированной банковской системы, заполняется реальными данными, а потом из этой тестовой среды происходит утечка данных. Последствия такой утечки будут такими же, как если бы это случилось с основной системой. Только найти виновных - значительно сложнее. Поэтому хорошей практикой является наполнение тестовых систем фиктивными, вымышленными данными. Если всё-таки необходимо работать с неким подобием реальных данных, то применяется маскирование. Например, все имена и фамилии, адреса обрезаются до первых двух-трёх букв, а остальные заменяются каким-нибудь символом, например звёздочками.
Другая мера - чётко разделить среду разработки и основную промышленную систему. Пользователи и разработчики должны чётко понимать, работают ли они в тестовой или в основной системе. Этой простой мерой часто пренебрегают и возникает ситуация, когда программист, думая, что работает с тестовой системой, вносит глобальные изменения в основную систему, выводит её из строя. У любого опытного разработчика множество историй о таких простых, досадных, но разрушительных ошибках.
Даже такая сугубо технологичная вещь как разработка программного обеспечения требует особого подхода не только со стороны бизнеса, но и юридической, кадровой службы, и особо - со стороны высшего руководства. Любая сложная работа чревата ошибками, разработка современных информационных систем как раз такой случай. Иногда ошибка программиста может привести к утечке данных, хищению средств, полному выходу из строя. Т.е. программист должен не только выполнить техническое задание - создать систему по запросу бизнеса, но и придать ей защитные функции, постараться сделать устойчивой к атаке злоумышленников. На практике, разработчикам ставятся конкретные сроки, в которые они должны уложиться и сдать работающую систему. Вопросы безопасности часто даже не ставятся и не обсуждаются. Но руководство предприятия должно понимать, что сжатые сроки при разработке лишают разработчиков возможности дополнительного тестирования, испытания. Да и спешка сама по себе провоцирует ошибки. Что важнее - запустить систему точно в срок, но с возможными проблемами, или чуть сдвинуть, отложить запуск, но дать больше времени на проверку? Это решение может принять только руководитель предприятия. В некоторых случаях вопросы безопасности и защиты данных имеют очень высокое, а то и определяющее значение. Например, банковские приложения. Финансы, медицина, транспорт, пищевая промышленность - в этих сферах безопасность имеет высший приоритет.
Обеспечение безопасности при разработке ПО это целое направление в технологиях. Но, т.к. заказчики при формировании технического задания никак не обозначают вопросы защиты данных, то программисты и не акцентируют на этом своё внимание. Хорошей практикой является направление сотрудников за счёт предприятия на специальные курсы по обеспечению информационной безопасности при разработке ПО.
Вообще, вопросы безопасности должны озвучиваться на уровне высшего руководства, нужно дать понять всем, особенно разработчикам, что их усилия в этой сфере оцениваются. Ведь если от программиста требуют «быстрее и дешевле», наивно ожидать, что он будет стараться сделать ещё и «безопасно».
Относительно недавно (последние лет 10) появился ещё независимый аудит исходного кода и специальные инструменты по автоматизации поиска ошибок и уязвимостей в разработках. Такой подход позволяет обнаружить многие критические проблемы ещё до выпуска системы в промышленную эксплуатацию. И этот инструментарий будет всё шире применяться. Ведь сейчас сложно представить, что какой-то автомобиль будет запущен в эксплуатацию без краш-теста, когда он на заданной скорости сталкивается с препятствием и определяется, уцелеют ли его пассажиры? Для серьезных информационных систем тоже обязательно должны проводиться подобные испытания - справится ли система с нагрузкой, удастся ли отразить атаки по сети. И после каждого существенного изменения такие тесты нужно проводить снова.
Задача современного руководителя понимать, что кроме несомненных удобств, информатизация несёт ещё и специфические риски. Необходимо определить, задекларировать и придерживаться в работе баланса между безопасностью и скоростью разработки, внедрения новых функций. Сформировать доброжелательную атмосферу, когда допущенные ошибки тщательно анализируются, выявляются истинные причины их возникновения. Ну и всячески поддерживается обратная связь с пользователями систем, которые тоже могут сообщать о проблемах в информационных системах.
Руководителям, которые хотят ещё подробнее узнать об обеспечении безопасности при внедрении и разработке информационных систем рекомендуем раздел «14 Приобретение, разработка и обслуживание информационных систем» государственного стандарта Oʻz DSt ISO/IEC 27002:2016 «Информационная технология. Методы обеспечения безопасности. Практические правила управления информационной безопасностью».