[RSS-пост] Анализируем новые приказы ФСТЭК России № 17 и № 21
Степаненко Андрей,
директор по маркетингу
компании «Код Безопасности«О приказах ФСТЭК России № 17 и № 21 высказались, наверное, уже все эксперты сообщества, перемыли косточки и разложили по полочкам все новации нашего регулятора. Поэтому планируя вебинар на эту тему, мы рассчитывали на традиционное количество в 150–200 участников. Реальность существенно превзошла наши ожидания. Более 600 зарегистрировавшихся участников — объективный показатель того, что информации по этой теме до сих пор не достаточно, наши партнеры и заказчики нуждаются в дополнительных разъяснениях новых положений. Сама презентация не содержала каких-либо супероткровений; то же самое систематическое «раскладывание по полочкам» и наша позиция по некоторым спорным положениям. А вот сессия вопросов и ответов стала для меня настоящим испытанием, которое длилось дольше самой презентации. Мы получили более 50 вопросов самой разной направленности: от простого толкования тех или иных мер защиты до попытки разобраться в тонкостях лицензирования деятельности по защите информации. Для тех, кто не смог принять участие в вебинаре, презентация и запись вебинара доступны на сайте. Здесь же я хочу дать пояснения по трем наиболее часто поднимаемым вопросам, на которые не успел дать развернутые ответы во время вебинара.Нужна ли оператору ПДн лицензия на ТЗКИ?
Информационное сообщение ФСТЭК России от 30 мая 2012 г. № 240/22/2222 «По вопросу необходимости получения лицензии ФСТЭК России на деятельность по технической защите конфиденциальной информации» допускает возможность работы без лицензии на ТЗКИ, если деятельность организации не направлена на получение прибыли от выполнения работ или оказания услуг по технической защите конфиденциальной информации. Детали и иные условия, при которых эта возможность реализуется, подробно перечислены в сообщении, правда, с весьма неоднозначными формулировками. В соответствии с этой позицией ФСТЭК России лицензия на ТЗКИ для оператора ПДн не является обязательной, если деятельность по защите персональных данных является вспомогательной, выполняемой для собственных нужд. К сожалению, после запуска в январе 2013 г. нового сайта ФСТЭК России найти этот документ там не удалось, поэтому ищите его в информационно-правовых системах (например, http://www.garant.ru/products/ipo/prime/doc/70104166/).Необходимо ли для существующих ИСПДн (для которых выполнены требования приказа № 58) выполнять требования по 21 приказу?
В соответствии с общими правилами нормативный акт применяется к отношениям, имевшим место после его вступления в силу и до утраты им силы. Поэтому действие приказа № 21 будет распространяться на вновь создаваемые системы защиты в информационных системах персональных данных. Отдельной ремарки заслуживает ситуация, когда ранее созданная система защиты ИСПДн модернизируется. В этом случае для легализации нового варианта системы защиты нужно следовать нормам нового приказа. Но глубина модернизации при этом ничем не регламентирована, поэтому каждый оператор, скорее всего, будет толковать эту ситуацию в свою пользу, откладывая переход на новые требования. Хотя провести классификацию существующей ИСПДн по новым критериям может быть полезно и не дожидаясь модернизации, потому что во многих случаях прежний класс К1 может превратиться в УЗ2, УЗ3 или даже УЗ4.Есть ли понимание что такое «методы защищенного программирования» и как понять — какие продукты с использованием этих методов созданы?
Конечно, у всех компаний, занимающихся разработкой программного обеспечения, есть свое видение того, что понимается под «методами защищенного программирования», предназначенными для повышения уровня безопасности продуктов и снижения числа уязвимостей в них.
Одной из самых известных в индустрии моделей является жизненный цикл безопасной разработки Microsoft, базирующийся на нескольких ключевых принципах: безопасность при разработке, безопасность при использовании параметров по умолчанию, безопасность при развертывании и безопасность при обмене данными. Так, «Код Безопасности» осуществляет все свои разработки в соответствии с этой моделью. Другим интересным документов на эту тему является NIST Special Publication 800–64 Security Considerations in the System Development Life Cycle, который охватывает не только программирование, а значительно более широкую область. NIST предлагает пятиэтапную модель, позволяющую обеспечить выполнение требований по безопасности в информационных системах, которые строятся из уже готовых и разрабатываемых по требованию заказчика продуктов. Какого-либо списка продуктов, созданных в соответствии с методами защищенного программирования, не существует. Можно ориентироваться на декларации разработчиков, хотя следование этим методам не означает полного отсутствия ошибок или уязвимостей в их продуктах. Но их гарантированно будет существенно меньше, чем у разработчиков, такими методами не пользующихся.
