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

Немного вступления
Меня зовут Альбина Аскерова, я работаю в команде Swordfish Security руководителем направления по взаимодействию с регуляторами, и искренне верю - как красота в глазах смотрящего, так и в российской регуляторике много полезного, нужно только перевести с эльфийского нормативной лексики на понятный обывателю язык.
В нашей практике консалтинга по разработке безопасного программного обеспечения (РБПО) мы часто получаем от клиентов запрос на создание стратегии процессов РБПО, подбор и внедрение нужных инструментов с обязательным учетом всех действующих требований законодательства. Один нюанс – клиенты сами не всегда знают конечный список обязательных требований, но всегда очень переживают, если в рамках проверок выявляются нарушения.
На просторах интернета мы не нашли полного описания действующей регуляторики, в которой прямо или косвенно указаны требования к практикам безопасной разработки, и сделали такой обзор сами. Провели целое исследование (выжали более 30 документов) и с радостью готовы поделиться им с вами. Материала набралось много, поэтому мы поделим наш путь на 5 частей и опубликуем их в виде цикла статей:
Часть 1. РБПО: общие требования - ГОСТы, Указы Президента, Федеральные законы, Приказы (сейчас вы ее читаете);
Часть 2. РБПО: требования в финансовой отрасли;
Часть 3. РБПО: требования к КИИ;
Часть 4. РБПО: требования к ГИС, ИСПДн, отраслевые требования;
Часть 5. РБПО: ответственность, взгляд в будущее, инфографика всего обзора.
Важно! Еще раз подсветим, что мы будем говорить только про регулирование РБПО. Другие направления информационной безопасности тоже важны, но им мы посвятим отдельные материалы.
Важно № 2! РБПО в современном понимании это давно уже не только классический DevSecOps в виде разного вида анализов безопасности приложений. Сейчас наша классическая восьмерка разрастается и становится как бы ядром всех практик безопасности, которые влияют на безопасность приложения. Теперь это и инфраструктура (защищенность контейнерных сред, секретов), и цепочка поставок ПО, и вообще Secure by Design с подходом к безопасности еще на этапе появления первой мысли о создании приложения и многое другое.

Или еще такой вариант неких «кругов по воде» при замысле разработки продукта:

Разминка
Так как элементов творчества и креатива в регуляторике мало, попробуем на протяжении пяти частей помочь вам держать фокус внимания небольшими, но понятными обзорами, добавим немного юмора и разыграем мерч.
Начнем с синхронизации. Если это регуляторное бинго вызовет у вас улыбку сквозь слезы, то знайте – вы не один.
Перечитывал одно и то же 3 раза и каждый раз понимал по-разному | Только выполнил требование, а регулятор внес изменения | Добрый день! Завтра проверка, вот чек-лист на 100+ требований | Прочитал три дня назад, но понял только сейчас | Искренне веришь, что "инновации в регуляторике" — это не оксюморон |
Читал и думал - кто это написал? | Прочитал и понял нормативный документ с первого раза, не отвлекаясь на слёзы | Пришел за консультацией к юристам, но тебе пояснили, что они не безопасники | Провел вечер, изучая новый закон, и теперь можешь цитировать его наизусть (но никто не хочет тебя слушать) | Участвовал во встрече, где все согласны с тем, что правила — это хорошо, но соблюдение их — это уже перебор |
Понял, что самый сложный документ — это тот, который ты написал сам | Пытался объяснить коллеге, что "проверка соответствия" — это не то же самое, что "проверка на совместимость" | Участвовал в обсуждении новых правил и вспомнил о старых добрых временах, когда все было проще | Получил звонок от проверяющего и на мгновение поймал паническую атаку | Убедил начальство, что новые требования — это не конец света, а просто новое утро |
Получил от начальства задание "сделать так, чтобы нас не оштрафовали", и задумался о карьере в магии | Пытался объяснить, почему важна документация, и чувствовал себя проповедником | Прочитал новую регуляторику и почувствовал себя в научной фантастике | Составлял отчет и думал, что это похоже на написание романа | Пытался найти баланс между инновациями и соблюдением норм |
Слышал, как кто-то говорит: "Мы всегда соблюдаем правила", и не смог сдержать улыбку | Чувствовал себя Шерлоком, расследуя несоответствия в документации | Проводил встречу с коллегами, чтобы обсудить изменения в требованиях, и все пришли с разными мнениями, и все похожи на правду | Получил положительный отзыв от регулятора и почувствовал гордость за свою работу | Пытался объяснить родителям, чем ты занимаешься на работе, и они все равно не поняли |
Погнали!

Какие есть регуляторы и что они регулируют в РБПО?
Регуляторов у нас в стране много, и, по сути, все они говорят об одном и том же, только каждый со своей стороны. Также много отраслей экономики, среди которых можно выделить укрупненные виды требований. И типов документов тоже много, но глобально – обязательные и рекомендательные. В этих трех плоскостях будем двигаться.
Итак, чем дальше в Консультант, тем удивительней мир.
Источники нормативного регулирования РБПО
Президент;
Регуляторы – ФСТЭК России, Минцифры России, Банк России, Минэнерго России (сами не ожидали);
Росстандарт.
(Если кого-то упустила, обязательно напишите об этом в комментариях).
Для кого требования
Для себя мы выделяем глобально 5 типов систем/приложений по их целевому назначению:
Финансовая отрасль;
КИИ (если вы КИИ в финтех, то смотрите и требования к финансовой отрасли);
Системы обработки персональных данных (если обработка ПДн в финтех и/или КИИ, то смотрите еще и требования к ним);
Государственные системы, созданные для выполнения гос.полномочий, а также в иных установленных федеральными законами целях (если ГИС в финтех и/или КИИ, и/или обрабатываете ПДн, то смотрите еще и требования к ним);
Иное (тут общие требования типа ГОСТов, законов, указов, требования при сертификации ПО в системе ФСТЭК и сертификации процесса РБПО, тут Минэнерго с требованиями к энергетике. Предчувствуем, что список будет расширяться).
Про типы документов уже писала выше:
Обязательные к исполнению (Указы Президента, Федеральные законы, нормативные правовые акты регуляторов – приказы, положения);
Рекомендательные (ГОСТы, методические рекомендации). Важно, что они такие до тех пор, пока в обязательном документе не укажут, что рекомендательные являются обязательными
