Давайте попробуем поразмышлять. Как можно бороться с угрозами недекларированных возможностей на уровне прикладного и системного ПО? Я вижу несколько вариантов:
- внедрение приемов «защищенного» программирования (SDLC)
- проверка исходных кодов на предмет НДВ с помощью автоматизированных инструментов (Appercut, Fortify или отечественные сканеры исходных кодов)
- проверка исходных кодов на предмет НДВ с помощью специализированных компаний (Positive Technologies, Digital Security и т.п.) или в рамках сертификационных испытаний ФСТЭК/ФСБ/МО
- услуги по анализу защищенности приложений и операционных систем
- доверенная аппаратная платформа с функциями защиты от НДВ на системном и прикладном уровне
- страхование соответствующих информационных рисков.
Какие еще варианты могут быть?
Договором с разработчиком включающим его ответственность.
Регулярным обновлением ПО.
А вообще — обязательно ли бороться с НДВ?
Мы можем другими средствами (FW, IPS, WAF, DBF) понизить риск до приемлемого уровня.
Я сейчас не рассматриваю вариант "не бороться" 😉 Исходим из нынешней редакции ПП-1119 и того, что регуляторам придется что-то включать в свои нормативные документы для нейтрализации этих угроз
Я думаю нужно начать с того, какие угрозы ИС/АС несут в себе недекларированные функциональные возможности Системного и Прикладного ПО. Это даст нам возможность рассматривать контрмеры не на уровне абстрактных понятий а на уровне конкретных АС/ИС — что и требуется на практике.
Угрозы для АС/ИС, происходящие от НДВ в системном ПО (BIOS, ОС, Драйвера и т.п.) — имеют значительный потенциал нанесения вреда. В прикладном ПО на порядок меньше. Если рассматривать по крупному, по противодействие может быть по двум направлениям: выполнение и контроль требований по безопасной разработке и контроль готового ПО. Оба направления тяжелые.
Женя, не демагогируй, а предложи конкретные вещи, которые можно вставить в документы 😉
Если рассматривать первое направление то попробуем хотя бы источники угроз рассмотреть для ППО на каскадной модели ЖЦ ПО:
1. Источники угроз на этапе формирования требований к прикладному программному обеспечению
1) формирование требований направленных на создание условий для по-следующего небезопасного применения программного обеспечения;
2) просчеты при формировании требований к программному обеспечению.
2. Источники угроз на этапе проектирования прикладного программного обеспечения
1) целенаправленное внедрение уязвимости или закладки на уровне архитектуры и/или алгоритма функционирования программного обеспече-ния;
2) целенаправленное проектирование таких методов тестирования, которые направлены на сокрытие уязвимостей/закладок;
3) внесение уязвимостей/закладок используемыми средствами автомати-зированного проектирования;
4) применение архитектурных решений, которые приводят к необходимости применения ресурсоемких методов тестирования и отладки программного обеспечения.
3. Источники угроз на этапе реализации (кодирования/компиляции/сборки) прикладного программного обеспечения
1) целенаправленное внедрение закладки;
2) целенаправленное внедрение уязвимости;
3) использование сторонних недоверенных компонентов;
4) скрытая реализация специальных настроек, позволяющих включить/инициировать закладки или уязвимости программного обеспечения;
5) избыточная компиляция и сборка ПО из «грязных» исходных текстов содержащих различный «мусор»;
6) внесение уязвимостей используемыми средствами компиляции и сборки программного обеспечения;
7) реализация тестов, которые позволяют скрыть уязвимости и недостатки в программном обеспечении.
4. Источники угроз на этапе тестирования прикладного программного обеспечения
4.1. Проведение тестирования разработчиком или заказчиком прикладного программного обеспечения
1) целенаправленное использование методов тестирования, которые направлены на сокрытие уязвимостей;
2) тестирование не проводится или проводится не в полном объеме;
3) целенаправленное сокрытие результатов тестирования.
4.2. Проведение тестирования прикладного программного обеспечения независимой испытательной лабораторией в процессе сертификационных или иных испытаний
1) целенаправленное использование методов тестирования, которые направлены на сокрытие уязвимостей;
2) тестирование не проводится или проводится не в полном объеме;
3) целенаправленное сокрытие результатов тестирования.
5. Источники угроз на этапе внедрения прикладного программного обеспечения
1) подмена компонентов прикладного программного обеспечения;
2) внедрение прикладного программного обеспечения без учета ограничений и условий эксплуатации как самого ППО так и среды его функционирования;
3) использование скрытых настроек прикладного программного обеспечения для включения/инициации закладок или уязвимостей.
6. Источники угроз на этапе эксплуатации и сопровождения прикладного программного обеспечения
1) использование скрытых настроек прикладного программного обеспечения для включения/инициации закладок или уязвимостей;
2) срабатывание/использование уязвимостей и закладок недоверенного программного обеспечения.
Понятно, что за месяц проблему стратегически не решить, но коль скоро регуляторы загнали себя в угол этой формулировкой, а требовать сертификации системного и прикладного ПО на отсутствие НДВ у них нет права, то остается предлагать какие-то промежуточные варианты.
К базовым методам обеспечения безопасного применения программного обеспечения относятся:
1) формирование требований по безопасному проектированию, реализации программного обеспечения и контролю этих требований на всех этапах жизненного цикла ПО;
2) анализ среды функционирования ПО, направленный на выявление характеристик, которые считаются опасными или потенциально опасными;
3) анализ прикладного программного обеспечения, направленный на выявление функциональных возможностей и характеристик, которые считаются опасными или потенциально опасными;
4) контроль среды функционирования ПО (динамический контроль поведения, изменения характеристик и т.п.) в процессе функционирования АС КВО;
5) контроль прикладного программного обеспечения в процессе его функционирования.
Необходимо отметить, что применение указанных методов неоднородно. Это связано с наличием специальных средств, сложности и стоимости их применения.
Женя, этот текст можно использовать?
Твой вопрос звучит примерно так: Вот что то написали… теперь давайте придумаем пару фраз чтобы в документ вставить…)))) Мельчаешь 😉
Я скажу как одной фразой!
"Мерой, направленной на нейтрализацию угроз НДВ в ИС является использование системного и прикладного ПО прошедшего контроль на отсутствие в нем НДВ и/или средств ЗИ обеспечивающих контроль и нейтрализацию нежелательных последствий от наличия или использования НДВ в ПО"
Женя, даже по 199-му приказу нельзя требовать сертификации на отсутствие НДВ системного и прикладного ПО для всех кроме госорганов
"Женя, этот текст можно использовать?"
Я уже док почти дописал в гордом одиночестве "ОЦЕНКА И ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ ПРИМЕНЕНИЯ
НЕДОВЕРЕННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
В АВТОМАТИЗИРОВАННЫХ СИСТЕМАХ
КРИТИЧЕСКИ ВАЖНЫХ ОБЪЕКТОВ (АС КВО)
"
Тебе часть или все ?
Я так понимаю в требования исследование пихать уже поздно… нужны гладкие формулировки…
Мне все не надо 😉 Нужны формулировки. Как вариант. А пройдет/не пройдет — никаких гарантий, как ты понимаешь
А где ты видишь слово сертификация 😉 ? а… ? а… ? :))
Да, тоже верно. И этот контроль может быть реализован с помощью описанных в замой заметке вариантов 😉 Логично
Алексей: бизнес-приложения (а именно там находятся ПДн) сертифицировать невозможно — срок изменения функционала меньше времени сертификации в разы, то есть сертификат будет на позапрошлую и уже не актуальную версию.
Использовать инструменты контроля качества кода для поиска НДВ нельзя — можно найти потенциально опасные конструкции, но не более. В том числе и потому, что НДВ = В — ДВ, а низкоуровневые (на уровне кода) ДВ тебе никто не знает.
Евгений: "Угрозы для АС/ИС, происходящие от НДВ в системном ПО (BIOS, ОС, Драйвера и т.п.) — имеют значительный потенциал нанесения вреда. В прикладном ПО на порядок меньше." — в этом вы не совсем правы, все активы и критические процессы компании обычно находятся именно в прикладных системах, например в АБС.
Руст, ты РД по НДВ смотрел?
2 Рустэм:
бизнес-приложения сертифицировать можно — половину федерального казначейства отсертифицировал… Есть методы… к тому же ПДн скорее в БД.
Можно использовать инструменты контроля безопасности кода для поиска НДВ. Как разработчик таких средств говорю. В том числе и на уровне машинного кода.
"в этом вы не совсем правы, все активы и критические процессы компании обычно находятся именно в прикладных системах, например в АБС."
Тут позвольте не согласиться. Системное ПО это как канальный уровень модели OSI для прикладного. Любой нижний уровень абстракции неконтролируем на более высоком. Ну и так далее…
Итого:
Для НДВ в системном ПО — беда. Анализировать его безперспективно без доступа к архитекторам и процессу проектирования. Для части Прикладного примерно тоже. Но можно иногда исходники ковырять. Выход вижу один:
1 — использовать архитектуру ИС таким образом, чтобы минимизировать риски.
2 — использовать средства позволяющие минимизировать ущерб. Например ограничив распространение ПДн и т.п.
Коллеги, а Вам не кажется, что Вы немного не там ковыряете? Я конечно не особый спец в разработке СПО и ППО, но законодатель-то и не предполагает бороться с НДВ. Он говорит буквально следующее: "актуальны угрозы, связанные с наличием недокументированных (недекларированных) возможностей".
Ключевое слово — НАЛИЧИЕ. Давайте подумаем, какие угрозы могут быть связаны с наличием, и будем бороться с ними, а не с НДВ?
Иными словами , к чему может наличие привести, и как минимизирвать последствия иными средствами, а не борьбой с НДВ, которые не победить?
Ну как бороться с наличием…)))
Прописать примерно так:
Данные прикладные программные средства функционируют только в момент непосредственной обработки Пдн. Все остальное время находятся в неактивном состоянии, что ЗНАЧИТЕЛЬНО сокращает риск срабатывания в нем НДВ :)))
Непосредственная обработка занимает 5 минут в течении суток что явно показывает что угроза появления НДВ незначительная…
А вообще запасаемся попкорном.. таких фраз будет МОРЕ….
Хотел предложить подход аналогичный тому, который предложил Евгений Родыгин ))) (конечно не так полно и красиво:))
Но раз опередил, предложу идею развития мысли Алексея Волкова.
!!!Все что пишу — только направление мысли, с учетом принципа "наличия или простоты реализации" при отсутствии альтернативы.
Определение из РД:
Недекларированные возможности — функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации.
Разбираем на части (условия):
1. функциональные возможности не описанные в документации
2. функциональные возможности не соответствующие описанию в документации
3. при использовании которых возможно нарушение конфиденциальности обрабатываемой информации
4. при использовании которых возможно нарушение доступности обрабатываемой информации
5. при использовании которых возможно нарушение целостности обрабатываемой информации
Теперь по порядку:
1. функциональные возможности не описанные в документации
ничего мы сделать с этим не можем не прибегая к "Принципам Родыгина" (я не придумал как иначе)
2.функциональные возможности не соответствующие описанию в документации
ничего мы сделать с этим не можем не прибегая к "Принципам Родыгина" (я не придумал как иначе)
3. при использовании которых возможно нарушение конфиденциальности обрабатываемой информации
Тут конечно надо перебирать все угрозы и подбирать путь их нейтрализации, но для примера:
3а. СПО
обвес СЗИ на уровне выше (на уровне ОС), например работа в "песочнице", в виртуальной машине, которая контролируется "по выходам"
3б. ОС
надо идти по "Принципам Родыгина", но как вариант 3а от некоторых угроз, например, утечек по сети/каналам — применение DLP, "железных" СЗИ на проходе.
4. при использовании которых возможно нарушение доступности обрабатываемой информации
резервирование оборудования на иных ОС и СПО (например 2 сервера на Windows и на Linux)
5. при использовании которых возможно нарушение целостности обрабатываемой информации
резервирование баз данных на ином СПО
Получается, что СрЗИ — тоже ПО… к нему применять те же принципы по актуальности угроз ?…
Но если так, то чем больше СрЗИ тем лучше! Вероятность НДВ (как то посчитали) = 0,5. Вероятность утечки через два разных СрЗИ уже меньше. ))) бред…
Конечно, чем больше в системе элементов, тем ниже ее надежность. Аналогично, чем больше ПО, тем больше НДВ, соответственно выше уязвимость, больше угроз.
Но, в настоящей ситуации, СЗИ почти всегда проходят сертификацию по НДВ, так что можно принять, что вероятность НДВ в СЗИ ниже, чем в обычном ПО. Возможно СЗИ даже разрабатывают по описанной Вами парадигме.
При таком допущении, можно ПРЕДПОЛОЖИТЬ, что вероятность НДВ у двух разных СЗИ окажется ниже, чем у "простого" ПО. Тогда не бред )))))
Вообще стандартная задача надежности сложных электронных устройств. И резервирование в общем случае самое распространенное решение ее повышения, наряду, естественно, с повышением надежности отдельных элементов.
Вообще я о том, что особенность угрозы НДВ в том, что чем больше разных СрЗИ наставишь тем угроза меньше именно НДВшная. При условии что они определяют защиту периметров
1. Антивирусное средство (проверка наличия вредоносных механизмов в ПО + динамический контроль + эвристика)
2. Фаерволл/МЭ/маршрутизатор (ограничение распространения и ограничение информационных потоков на случай сбоя в ПО)
3. Средство контроля целостности ПО (в составе антивируса или отдельно)
4. Средства оперативного восстановления после сбоев в ПО (быкап, восстановление)
5. Любое средство делающее предположения о функционале ПО (любая поделка которая определяет функционал хотя бы на основе импортируемых функций + рассмотрение багов в Интернет + небольшая методика)
6. Архитектура (локализация возможного сбоя ПО и ограниченность свободного распространения)
7. Оргмеры… надрать из ISO 27xxx
все…
Женя и ZZubra — вы уловили мысль! Как сделать угрозу, СВЯЗАННУЮ С НАЛИЧИЕМ НДВ, неактуальной и условии, что НДВ есть всегда? Верно — отвязать ее от НДВ! И поэтому чем больше СЗИ будет перекрывать лазеек, способных привязать угрозу к НДВ — тем выше отвязка. Другое дело, как выстроить защиту вида СПО — ППО — все остальное…
Не… Это я предполагаю как будет… Как правильно я знаю, но кому нужно как правильно ?..
А будет примерно так:
Нам нужно тонну угля!
Вот вам пол тонны песка и пол тонны навоза. Если перемешать и смотреть издалека то на тонну угля вполне похоже…
Правильно знаешь как бороться с НДВ, но это никому не надо. Борются с угрозами, связанными с ними — то есть вместо дыры нейтрализуют тех, кто хочет ей воспользоваться. Потому что дыра и самим пригодится 🙂
Да уж…. исключить угрозы ндв можно только одним способом-привязав к ущербу. Все остальное это словоблудие к ИБ не имеющее отношение. Иди туда, не знаю куда…. Вы думаете во ФСТЭК написать документ не могут? Могут!!!!! Но исходные данные таковы, что чистыми из этой ситуации уже не выйти….
Да уж…. исключить угрозы ндв можно только одним способом-привязав к ущербу. Все остальное это словоблудие к ИБ не имеющее отношение. Иди туда, не знаю куда…. Вы думаете во ФСТЭК написать документ не могут? Могут!!!!! Но исходные данные таковы, что чистыми из этой ситуации уже не выйти….
Алексей, повторю, НДВ никто не собирается исключать. Правительство говорит о том, что нужно сделать неактуальными угрозы связанные с их наличием. То есть наличие — это аксиома. Они есть и точка. И это само по себе не угроза. А вот все что за этим следует, с этим связано — это угроза. И здесь получаем гипертрофированную классику ИБ, где вместо ущерба — СПО, ППО и остальное все.
Алексей, да все понятно, что хотели и что получили… Получается, что сроки выхода документов ФСТЭК зависят от того, найдут ли решение по исключению угроз, связанных с НДВ. Пессимизм экспертов начинается сбываться. Полдня сегодня думал, никаких "красивых" вариантов не нашел.
ИМХО самый безболезненный вариант — привязать к каким-нибудь исходным данным комплексной системы защиты, а именно наличие адекватных орг мер, политик обновления ПО, централизованного управления, достаточного количества администраторов и т.д…Если все плохо — применяйте дополнительные сертифицированные на НДВ СЗИ, а если хорошо — то вы и сами справитесь. При этом конечно оставить требования к МЭ, СКЗИ, АЗ и т.д.
Прежде всего они должны придумать, как смоделировать угрозы исходя из априорного и неустранимого наличия НДВ, затем — как отвязать их от НДВ выбором СЗИ, то есть сделать их неактуальными. Алексей Лукацкий предлагает бороться с НДВ, что методологически неверно, и если он не донесет эту мысль до тех, чье задание выполняет — будет куда большая неразбериха. Если, конечно, этот бардак кому-то не выгоден.
А вы не исключаете вариант, что банально совершили ошибку при формулировке, имея ввиду именно угрозы НДВ? И теперь регулятор просто проигнорит все сложности, связанные с интерпретацией получившегося термина. Я к тому, что сложности в решении этой задачи могут видеться специалистам, но не регулятору…и будем в итоге в небе солнце досками заколачивать
Это было сделано не случайно. Этот вариант полностью исключен.
1. Я не выполняю ничей заказ. Пора это уяснить.
2. Ты не прав в отличие от Михаила.
1. Я не сказал заказ — я сказал задание. Как внештатный консультант на добровольных началах. Что за агрессия?
2. Поясни тогда, почему, когда все (в том числе и я — на Инфобезе) в лицо им говорили об ошибочной формулировке , и они обещали прикинуть и подумать, так ничего и не исправили?
Почему проект СТРК обсуждается публично, а проекты по ПДн — кулуарно, кружком посвященных? Мне вот наплевать на СТРК, я и старого недостатки не знал, знаю только, что все ГОСы обязаны и сертификаты на СЗИ иметь, и аттестаты на АС. И это незыблемо. А вот проекты по ПДн пообсуждал бы. Конструктивно, подробно и по делу. Ночами бы не спал. Ан нет — не дают?
А проекты ПДн еще никто и не обсуждает 😉
Может быть потому, что на Инфобезе текст ПП уже был всеми согласован и ушел в Правительство? А изменение согласованного текста — это начало процедуры заново. Это я не утверждаю, а предполагаю. Всякое может быть. Может быть ты общался не с разработчиками ПП?..
И задание я ничье не выполняю. У меня доков по ПДн нет
Но ты же зачем-то собираешь мнения. Я и подумал что ты уже щасливый обладатель 😉 А ты с разработчиками общался, и некоторые другие люди, и говорили то же самое. Результат 0.
О результате можно говорить только после выхода доков ФСТЭК и ФСБ. На их уровне можно нивелировать некоторые недочеты ПП-1119
О результате нельзя говорить, если ети доки перед выходом не будут выложены дляиэкспертного обсуждения.
Поддерживаю Алексея Волкова — надо описывать меры защиты для уменьшения риска угроз (чтобы они стали неактуальными). Только список в посте Евгения от 21.17 надо расширять 😉
И американцы сейчас двигаются в том же направлении.
Если посмотреть на SANS TOP20 Critical Security Controls (http://www.sans.org/critical-security-controls/) и DSD TOP35 (http://www.dsd.gov.au/infosec/top35mitigationstrategies.htm), то в них как раз много мер для того чтобы угрозы НДВ стали менее актуальными 😉
Хочу добавить — особенно это видно в TOP35 потому что он как раз предназанчен для защиты от целевых атак с применением малвари и т.д., которые как раз используются уязвимости переполнения буфера и т.д. (то есть те самые недекларированные возможности)
Хотя оба этих документа несистемно описывают меры ;-(
Кстати сертификация ни фига не спасет — вон Windows сертифицировали (и даже обновления типа сертфицируют), но каждый месяц находят все новые и новые недекларированные возможности, позволяющие drive-by downloading и т.д 😉
Плюс не забудьте, что до фига ПДн в БД Oracle, от которого нельзя отказаться и для которого НДВ — просто фантастика, и даже сам Oracle был вынужден сделать Database Vault (отдельное управление доступом за админами)
Так что в его случае можно защищаться только тем, что Сергей Борисов написал
Этот комментарий был удален автором.
Кроме упомянутого анализа исходных кодов, необходимо напомнить о возможности формального анализа (динамический, статический, комбинированный) бинарных кодов для поиска НДВ (как автоматического, так и ручного). Имеются соответствующие методики (ну и реверс инжинринг никто не отменял). Юридические вопросы лицензионных соглашений здесь не затрагиваю.
Однозначно основной упор борьбы с НДВ должен быть на первых этапах создания ПО.
2Родыгин
"Мерой, направленной на нейтрализацию угроз НДВ в ИС является использование системного и прикладного ПО прошедшего контроль на отсутствие в нем НДВ и/или средств ЗИ обеспечивающих контроль и нейтрализацию нежелательных последствий от наличия или использования НДВ в ПО"
Кто-нибудь задумывался, сколько будет стоить полная нейтрализация угроз? Разработчик всегда имеет возможность оставить себе для дальнейшего сопровождения ПО некоторые возможности. Выявить все такие возможности в ПО лаборатории не представляется возможным. Если только подкупить разработчика с целью раскрытия этих возможностей…
2Родыгин
Женя, уважаю 🙂
" половину федерального казначейства отсертифицировал…"
Ну только не бизнес-приложения, как ты пишешь… Или я чего-то не знаю?
У меня такое впечатление, что авторы 1119-го перепутали буквы — не НДВ, а НСД. Если в постановлении заменить НДВ на НСД картинка то получается достаточно гладкая.
2 Олег
"… нейтрализацию нежелательных последствий от наличия или использования"
"Кто-нибудь задумывался, сколько будет стоить полная нейтрализация угроз?"
где тут речь про полную? и да, все задумываются…
НДВ могут быть непреднамеренными — естественно для больших систем, угроза неактуальна, закрывается применением ПО от "авторитетных" производителей, закрывающих свои косяки, и преднамеренными закладками, выявить которые крайне сложно, а уж закрыть тем более.
Угрозы НДВ надо делить на сознательно заложенные и ошибки при разработке (грубые такие названия для классификации, но все же). Понимаю, что грань между ними тонкая, если вообще есть, но для адекватной борьбы с этими угрозами (а не создание идеальной безопасности) очевидно меры по защите будут несколько разные. Причем для большинства организаций угрозы сознательно заложенных НДВ будут маловероятны (как минимум в системном ПО!). Исходя из этого для сознательных НДВ — анализ исходного кода, анализ поведения времени исполнения, системные ограничения по доступу к ненужному функционалу. Для случайных ошибок — прежде всего налаженная система своевременных обновлений, различные защитные механизмы (от переполнения буфера, случайное расположение в памяти и т.п.).
Еще один важный аргумент за такое деление — как только сделают требование о сертификации на НДВ для системного и прикладного ПО -> следует запрет на частые обновления (пока сертификационная лаборатория не проверит) -> окно доступности 0-day уязвимостей становится больше и уровень безопасности за счет этого снизится гораздо больше, чем повышение из-за сертификации.
>> Кстати сертификация ни фига не спасет — вон Windows сертифицировали (и даже обновления типа сертфицируют), но каждый месяц находят все новые и новые недекларированные возможности, позволяющие drive-by downloading и т.д 😉
Винда по НДВ не сертифицирована. проверка, как я понял, была на то, что ОПИСАННЫЕ механизмы защиты работают, и при определенных условиях и настройках обеспечивают требования по ЗИ.
Несколько замечаний по дискуссии:
ни НДВ, ни НСД не являются угрозами.
НДВ — средство реализации угроз;
НСД — метод реализации.
Средство, как известно, может приносить как пользу, так и вред. Лопатой можно убить человека, а можно вскопать грядку, вырастить на ней морковку и спасти человека от голодной смерти. При помощи НДВ можно, например, выявлять "брейвиков", а можно качать у конкурента ноу-хау. Другими словами, источник угроз не НДВ (или НСД), а тот, кто использует их для причинения вреда объекту защиты.
Если объект защиты — информация, то ей могут угрожать:
1) уничтожением;
2) искажением;
3) изменением статуса;
4) изменением условий доступа.
Ещё раз: НДВ только повышают вероятность реализации угроз, но сами таковыми не являются. Более того, бороться нужно не с угрозами, а с их источником (противником), защищаться от атак (а не от угроз) и ликвидировать последствия деструктивных воздействий (а, опять же, не угроз).
НДВ (но не "угрозы НДВ") целесообразно делить на "преднамеренные" и "непреднамеренные". "Непреднамеренные", в свою очередь, можно разделить на "ошибки" (по Евгению) и "обусловленные сложностью" (по Сергею) (термины "не очень", но для прояснения сути пойдут). "Ошибки" возникают вследствие того, что кто-то где-то недосмотрел, недоработал, схалявничал и т.п., а "обусловленные сложностью" нельзя предусмотреть в принципе. Они возникают в результате усложнения системы: спонтанно формируются связи или бреши, появляются новые возможности, о которых даже разработчики не догадывались.
Прав Сергей Борисов, что бороться с НДВ следует "договором с разработчиком включающим его ответственность". (Об этом же говорил и Расторгуев С.П. в "Философии информационной войны".) Обнаружилась НДВ — разработчику штрафные санкции. Желательно немалые. Даже за непреднамеренные. При таком подходе даже будет выгодно иметь ПО с НДВ. Чем больше НДВ, тем выгоднее. И сертификация никому будет не нужна. Все будут гоняться за ПО с НДВ, пока оно не исчезнет как класс.
У Расторгуева есть ещё одна дельная мысль — "контроль контролёра". Можно пойти и по этому пути. Если ФСТЭК будет сертифицировать ПО на НДВ, то оно же должно нести и ответственность (финансовую и уголовную) за их наличие в сертифицированных ими продуктах. Не лицензиаты, а орган гос. власти. Тогда они и к выбору лицензиата будут подходить соответственно.
> Обнаружилась НДВ — разработчику штрафные санкции. Желательно немалые. Даже за непреднамеренные.
Ага! А еще сажать депутатов, если закон, за который они голосовали, не привел к мгновенному и всеобщему счастью! 🙂
НДВ = характеристика ПО которая может являться причиной угрозы.
К таким характеристикам так же относятся:
Для ИС:
1) функции и характеристики ИС не задокументированы;
2) в составе ИС отсутствуют и/или не функционируют механизмы, выполняющие выявление сбоев и недостатков в аппаратном и в программном обеспечении и не реагируют на них;
3) ИС эксплуатируется на неохраняемом объекте, доступ к ней не ограничен;
4) информационные процессы ИС не изолированы друг от друга;
5) ИС не обеспечивает доступ к ресурсам ИС (доступность ресурсов) в соответствии с установленными правилами;
6) аппаратные средства, используемые в составе ИС, содержат закладные устройства;
7) в ИС присутсутствуют компьютерные вирусы и другие вредоносные программы;
8) ИС подвергается компьютерным атакам;
9) все ПО ИС не обладает полной совместимостью, в том числе с аппаратными средствами ИС;
10) ПО ИС содержит ошибки;
11) ПО ИС не корректно выполняет заявленные функции;
12) ИС подвержена негативным действиям пользователей.
ДЛЯ ПО:
1) функции и характеристики ПО не задокументированы;
2) ПО содержит ошибки;
3) ПО не контролирует на корректность входные данные (на уровне среды функционирования и на уровне внутренних функциональных объектов);
4) ПО не контролирует на корректность выходные данные (на уровне среды функционирования и на уровне внутренних функциональных объектов);
5) ПО не контролирует на корректность управляющие воздействия в том числе пользователя (в том числе «внутренние» воздействия, связанные с функционалом ПО);
6) ПО не корректно реагирует на управляющие воздействия управляющих механизмов среды функционирования («внешние» воздействия, не связанные с функционалом ПО);
7) ПО содержит программные закладки;
8) ПО использует не только те ресурсы ИС и не в том объеме, которые необходимы и достаточны для выполнения возложенных на него задач;
9) ПО содержит вредоносные функции;
10) ПО вне ыполняет корректный запуск и завершение своих компонент;
11) ПО не выполняет правила информационного взаимодействия в ИС (среде функционирования);
12) ПО не выполняет правила использования ресурсов ИС;
13) ПО содержит не законченные (тупиковые) ветви алгоритма (ответвления не имеют “заглушки”);
14) ПО не предоставляет функции (не обеспечивает доступность) в соответствии с заявленными правилами.
2LAY
Атаманов абсолютно верно применяет прием перевода нематериальных величин в материальные с целью их количественного измерения и соответственно контроля, а так же перевода в экономическую плоскость, что в существующей временнОй реальности единственный правильный метод регулирования (что почти все столпы экономики давно научно подоказывали в своих теориях).
Но конечно реализация этого — утопия, в связи с мировым трендом на парадигму "авторских прав". Никто гражданский кодекс РФ переписывать не будет, если такое переписывание в мире никто никогда не делал. Наверняка, тот же ВТО запретит нам такое действо.
Так что такой путь ни ФСТЭК ни ФСБ не выберут — уровень законодательной инициативы не тот, действовать они должны только в рамках существующих ФЗ.
А в языках программирования и компиляторах НДВ есть? Типа того, что разработчик все делал "как надо", а на более высоком уровне его продукт имеет такую гадость.
2 ZZubra:
1 — есть. И было пару раз отловлено. Один раз даже мной 😉
2 — в современных условиях программист-бедолага сам не знает что у него написано. Любые компоненты языка высокого уровня несут в себе значительную избыточность которую программер не видит. Специально проводил такой анализ… но с этим ничего не поделаешь…
А если ОС пишется с помощью языков высокого уровня, то… 🙁
Как я неоднократно говорил ранее КАРАМБА (с) Барт Симпсон…
Без доступа к архитектуре и проектированию ОС — в ней ковыряться малопродуктивно…
LAYю: Уточняю: задача закона — упорядочивать отношения, а не делать всех счастливыми. Не надо путать! А ответственность у всех, в т.ч. и депутатов, за результаты своей деятельности должна быть. Иначе всё превращается в абсурд. Как сейчас: куча дебильных законов и ещё больше — дебильных инициатив. И никакой ответственности! Важно только, чтобы наказание было адекватно нарушению. Равно, как и штрафные санкции за НДВ. Я ведь вел речь не о размерах штрафов, а о подходах к решению проблемы. А это — "две большие разницы", как говорят в Одессе.
> LAYю: Уточняю: задача закона — упорядочивать отношения, а не делать всех счастливыми. Не надо путать! А ответственность у всех, в т.ч. и депутатов, за результаты своей деятельности должна быть
Я не путаю и даже про ответственность согласен (почти). Просто уж очень утопично это.
Кроме того, подобный договор с разработчиком применим (и то в теории) в мизерной доле ситуаций, т.к. ПО в основном создается либо своими силами либо приобретается на условиях "AS IS"
Для ZZubra: Вы правы: все вокруг понимают и делают. Но то, что очевидно для других, недоступно и неочевидно у нас. Я понимаю, что никто не будет сейчас менять законодательство. Это и не возможно, и, главное, не нужно. Менять будут вынуждены те, кто его создавал. В результате получим(как в том анекдоте) всё равно автомат Калашникова . Нужно, для начала, хотя бы продекларировать изменение подходов.
Авторские права при этом как раз и не затрагиваются. Ведь Майксофт пошёл на то, что предоставил исходники на некоторые версии Винда. Помнится об этом с гордостью нам объявили на Инфофоруме-2007. А здесь — не хочешь открывать, не открывай, но сделал ошибку — плати. Если, конечно, ошибку (закладку) удастся выявить. Нормальная конкуренция. А для выявления нужны высококлассные специалисты, а не сочинители разного рода никому не нужных бумаг, как сейчас, когда главный критерий — соответствие закону, а не эффективность.
Летом был в Белоруси. Там наши коллеги осознают, что НДВ есть данность, от которой избавиться невозможно, и тихо, без особого шума, решают эту проблему следующим образом: окружают "пиндосовское" ядро своими программулями. Такой подход можно назвать "интеллектуальным противодействием". Сравните с нашим ….
Белорусский софт контролирует винду. Кто-нибудь слышал? Звучит угрожающе…
Интересная дискуссия. Попробую свои 5 коп. добавить.
Сейчас у нас есть "наличие актуальных угроз НДВ" СПО/ППО. Уже говорилось ранее, что отталкиваемся все-таки от актуальности. Как её определить — вопрос к ожидаемым документам. Далее, актуальность угроз — это не только факт их наличия и того к чему может привести их реализация, но и возможность их реализации, а также актуальность соответствующего нарушителя. Для возможности реализации угроз необходимо: чтобы нарушитель знал о соответсвующих возможностях/уязвимостях или мог их обнаружить экспериментальным метотодом (например), а также, чтобы у нарушителей были реальные каналы для реализации угроз, то есть нужны, как минимум каналы доступа к защищаемым компонентам.
С физическими каналами все просто и уже обговаривалось, да и многие требования есть даже в документах регуляторов. Логические каналы — сетевые или локальные (консоль). Локальные — это физика + аутентификация + средства доверенной загрузки или иные ограничения. Сетевые каналы — также сетевое ограничение доступа к компонентам, хорошо всем известные МЭ, IPS и VPN.
Пример из жизни: есть ИСПДн, в ней есть компоненты, например, СУБД, сервер приложений и клиентское ПО на АРМ. На всех этих компонентах ОС и ППО могут содержать потенциальные угрозы наличия НДВ — у нас зарубежные разработчики, ничего не проверялось, сорцов нет, не сертифицировано. Ставится режим физической безопасности — доступ имеют только доверенные сотрудники в рамках контролируемой зоны. На АРМ дополнительно ставятся средства доверенной загрузки (мало ли кто зайдет в кабинет или open-space у нас) + аутентификация с токенами. ИСПДн сегментируем МЭ, если распределенная, то VPN, добавляем те же стандартные антивирусы, IPS, сканер уязвимостей + реализуем процессы мониторинга инцидентов ИБ, обновений и контроля конфигурации. В общем все — ничего не изменилось по сравнению со старыми требованиями. При этом мы реально снизили угрозы использования НДВ (если берем в расчет, что легитимные пользователи и так имеют доступ к ПДн и подписали кучу соглашений и правил). Даже при наличии НДВ злоумышленики не будут иметь каналов для реализации соответствующих угроз. В идеале. Возможны варианты с общедоступными сервисами и разделением прав, типа порталов с личными кабинетами, использования ПО, в котором пользователи имеют разные права доступа к ПДн или какие-то групы имеют права доступа, а какие-то нет. Но с этими моментами проблема была и ранее.
Также, как мне кажется, угрозы НДВ скорее всего стоит рассматривать с точки зрения получения несанкционированного доступа к ПДн. А если контроль и разграничение выполняется сертифицированными средствами защиты от НДВ, то и угроза получается опять же не актуальной.
Спору нет, что это не самый умный и красивый подход к проблематике НДВ, но в текущей сложившейся ситуации мне видится только такое решение, если есть хоть какое-то желание отделаться малой кровью.
Алексей, с Вами всё в порядке? Вы где угрозу увидели? Не стоит ёрничать, не тот случай. Перефразируя известную шутку скажу: "Проблема не в софте, проблема в головах". Даже американский софт можно заставить контролировать американскую винду. Нужно только мозги "включить" и совесть. И контролировать не обязательно. Чтобы защитить свой ресурс, нет нужды всё и вся контролировать. Думать надо, думать. Там, где люди думают раньше о деле, а потом о деньгах, там будет результат. Если наоборот, будет по Булгакову — разруха в клозетах.
>>Винда по НДВ не сертифицирована
Еще хуже. Пытаюсь представить, что Винду попытаются заставить сертифицироваться на НДВ, как хочет Евгений 😎
Что не верится 😉
>>естественно для больших систем, >>угроза неактуальна, закрывается >>применением ПО от "авторитетных" >>производителей, закрывающих свои >>косяки,
Угу. Свежо предание 😉
Достаточно посмотреть на Oracle или Adobe 8-(
А если почитать отчеты за последние годы о безопасности тех же веб-приложений (или пообщаться немного с разработчиками бизнес-приложений) или хотя бы почитать книгу про SDLC от майкрософтовца, то складывается впечатление, что о безопасности прикладные разработчики даже в крупных конторах думают далеко не всегда 😉
2Ronin: "Также, как мне кажется, угрозы НДВ скорее всего стоит рассматривать с точки зрения получения несанкционированного доступа к ПДн. А если контроль и разграничение выполняется сертифицированными средствами защиты от НДВ, то и угроза получается опять же не актуальной.
"
Увы, это серт. средство будет реализовывать только требования из ТУ или класса СВТ, в которых нет защиты хотя бы от SQLInjection 😉 и прекрасно ее пропустит (в отличие от несертифицированного WAF, потому что РД ФСТЭК для IDS как-то не ложатся на функционал WAF)
ну положим винда сертифицирована по НДВ…
и проблем сертифицировать поделку хоть по ТУ в которое все необходимое можно вписать хоть по общим критериям не проблема.
но при отсутствии требований по безопасному проектированию и разработке — косяк старый к тому же поднимется вой о том что Грамотные разработчики лучше всех знают как разрабатывать и им указания не нужны… 😉
>>Угу. Свежо предание 😉
Достаточно посмотреть на Oracle или Adobe 8-(
А зачем смотреть на "авторитетных дедушек". Есть молодой и перспективный законодатель моды, трехкратный автор Андройда и браузера, не уступающего ОСтальным, и много еще титулов. Короче, Google.
У них до сих пор идет акция по спонисрованию тюменского студента-тестера "Платим за баги"? У меня сложилось впечатление, что сия организация всерьез занимается укреплением своей репутацией. Смею напомнить, что это безвозмездно распространяемый продукт.
> У них до сих пор идет акция по спонисрованию тюменского студента-тестера "Платим за баги"?
А кстати, чем не вариант? Нанять штатного искателя НДВ по друдовому договору и обязать его оперативно закрывать угрозы, связанные с ними.
2 VKamensky
Спору нет, вариант и предлагался просто как некоторый уход, а не решение всех реальных проблем. Ну как бы так просто было и ранее с предыдущими документами и подходами. Просто мы пока что говорим об общих требованиях и решениях, которые должны быть реализованы повсеместно, включая муниципальные учреждения типа дет. садов, поликлиник и т.д. По понятным причинам те правильные вещи, которые обсуждаются в комментариях (типа процессов SDLC, менеджмента обновлений и сотрудничества с производителем и т.д.) там реализованы быть не могут. Так что я предложил решение в духе предыдущего подхода регуляторов, которое может помочь всем. А уж те организации, в которых есть реально высокие риски и соответствующая необходимость должны сами знать и понимать где им WAF поставить, где пентесты проводить ежеквартально, а где ПО самостоятельно разрабатывать и тестировать по всем правилам.
Просто тут есть 2 варианта: бороться с этими самыми НДВ, которые теоретически могут быть везде — путь сложный и не для всех; и бороться с актуальностью этих угроз — пытаясь снизить риски эксплуатации уязвимостей, связанных с наличием НДВ. Ну и уже тут определить необходимый минимум, а далее каждый думат для себя и оценивает свои риски. Это более адекватный путь на мой взгляд и он вполне коррелирует с предыдущим подходом регуляторов, поэтому и не вызовет паники тех, кто уже потратил миллионы на приведение в соответствие.
"ну положим винда сертифицирована по НДВ…"
если так, то ежемесячное обнаружение в ней все новых и новых уязвимостей говорит о качестве такой сертификации ;-(
"Есть молодой и перспективный законодатель моды…"
если бы все использовали софт только от гугла, я бы согласился.
Но ведь крупных производетелей ПО много ;-(
2Ronin: "…и бороться с актуальностью этих угроз — пытаясь снизить риски эксплуатации уязвимостей, связанных с наличием НДВ"
Полностью согласен — и многие комментарии здесь говорят об этом же, так как это единственно реальный путь для большинства.
Но как говорится, в России умеют скрывать под видом глупости определенный умысел. И судя по ряду комментов это и имеет место сейчас. так что "ежики плакали…" ;-(
"ежемесячное обнаружение в ней все новых и новых уязвимостей говорит о качестве такой сертификации"
А покажите мне требования РД НДВ по поиску уязвимостей… 😉
>>"А покажите мне требования РД НДВ по поиску уязвимостей… ;)"
вот-вот — какие РД, такая и сертификация ;-(
Вот поэтому Алексей Лукацкий как-то и сказал (не дословно, но смысл был такой), что чем дальше, тем больше выполнение требований РД ФСТЭК не имеет отношения к реальной безопасности…
Вот почему никто не хочет понимать, что сертификация это всего лишь подтверждение заявленного !? Сертификация ничего не требует кроме заявленного самим заявителем! А Лешик уже давно понял что нормативка такая в большой степени из-за позиции отрасли! Мне ситуация вообще кажется идиотской когда Регулятор не может, отрасль не хочет а сертификатор должен нормативку писать ?!
А еще расскажите, кто участвовал в сертификации по НДВ, что вы делаете со сторонними библиотеками :). Исходного кода нет, никто его не даст, а в серьезной прикладной программе такого библиотечного кода может быть ой-ой-ей сколько…
Евгений 2 Евгений (шизофрения…)
Делаем разное.
1 — оптимизируем механизмы защиты.
2 — уточняем границы СрЗИ. В большом ПО за защиту может отвечать маленькая плюшечка и библиотеки не причем. Сертифицируются только средства защиты.
3 — уточняем роль библиотек и относим их к среде функционирования
4 — находим исходники
5 — переписываем библиотеки
6 — ну и т.п.