ЖУРНАЛ «СТА» 4/2016

101 СТА 4/2016 www.cta.ru В ЗАПИСНУЮ КНИЖК У ИНЖЕ Н Е РА мую к разработчикам приказа № 31. Разъяснения представи- телей ФСТЭК представлены в таблице 1. Получается, что требования подсистемыОБР предъявляют- ся к ПО, разрабатываемому в том числе представителями опе- ратора АСУ ТП 1 , таким образом, необходима реализация определённого для конкретной АСУ ТП набора мер данной подсистемы. Плюс в том, что положениями приказа№31 раз- решено применять механизмы адаптации и уточнения требо- ваний, которые позволяют обосновать, например, использо- вание ручного анализа кода вместо статистического или дина- мического, то есть возможность использования компенси- рующих мер даёт возможность для каждого специфичного слу- чая обеспечить требуемый уровень защищённости АСУ ТП. К ЛАСС ЗАЩИЩЁННОСТИ АСУ ТП Следующая особенность заключается в распределении обя- занностей участников процесса защиты АСУ ТП (заказ- чик/оператор/разработчик) при определении класса защи- щённости АСУ ТП, от которого, в том числе, зависит набор мер защиты информации в АСУ ТП, а также применяемые средства защиты информации. При проектировании новой системы заказчик или опера- тор согласно приказу № 31 должен определить степень ущер- ба от нарушения целостности/доступности/конфиденциаль- ности информации. Полученная степень ущерба необходима разработчику системы информационной безопасности для определения класса защищённости АСУ ТП и зависит от ха- рактера чрезвычайной ситуации. Однако заказчик или оператор не могут предоставить тре- буемые данные, ведь объект по факту ещё не существует. Вы- ход: определить характер чрезвычайной ситуации можно, ли- бо исходя из паспортов аналогичных, уже введённых в экс- плуатацию систем, либо методом экспертной оценки. Таким образом, АСУ ТП присваивается предварительный класс за- щищённости. Критерии, на основании которых определяется предвари- тельный класс защищённости АСУ ТП, представлены в таб- лицах 2 и 3. С ЕРТИФИКАЦИЯ С Р ЗИ Третья особенность – применение средств защиты инфор- мации (СрЗИ). Согласно информационному сообщению ФСТЭК России (№ 240/22/2748 от 25 июля 2014 г.) в АСУ ТП применяются СрЗИ, прошедшие оценку соответствия в фор- ме, установленной заказчиком в техническом задании (ТЗ) в соответствии с ФЗ «О техническом регулировании». Однако на практике в ТЗ заказчик указывает всё ту же пресловутую фразу про оценку соответствия СрЗИ без уточнения формы. Остаётся проектировать систему защиты АСУ ТП с примене- нием СрЗИ, прошедших оценку соответствия в форме обяза- тельной и/или добровольной сертификации (если, например, Таблица 2 Критерии определения класса защищённости АСУ ТП Вопрос, касающийся подсистемы ОБР приказа № 31 Выдержка из ответа представителей ФСТЭК Являются ли инженеры-программисты (представители оператора АСУ), раз- рабатывающие/дорабатывающие прикладное ПО для функционирования АСУ ТП (мнемосхемы, алгоритмы ПЛК и т.д.), разработчиками согласно тер- минологии приказа № 31? К разработчикам системы защиты информации АСУ относятся в том числе инженеры-программисты, привлекаемые к разработке/доработке приклад- ного ПО для обеспечения безопасности информации в АСУ. В случае самостоятельной разработки прикладного ПО операторами АСУ и необходимости выполнения ими требований к ОБР, какие из анализаторов кода можно использовать? На данный момент известные анализаторы кода не ориентированы на SCADA-пакеты и АСУ в целом (не поддерживают языки программирования ПЛК, к примеру). Выбор автоматизированных средств, применяемых для реализации мер за- щиты информации по обеспечению безопасной разработки ПО, осуществ- ляется оператором самостоятельно. В случае отсутствия автоматизированных средств анализа кода он может быть проведён методом ручного анализа. Может ли оператор АСУ использовать ПО стороннего разработчика, кото- рый не выполняет требования ОБР.0–ОБР.6 при разработке ПО? Если да, то при каких условиях? В процессе проектирования АСУ разработчиком должно быть выбрано ПО, соответствующее требованиям в части разработки ПО. В случае отсутствия возможности использования указанного ПО разработ- чиком системы защиты АСУ должны быть реализованы компенсирующие меры, связанные с применением недоверенного ПО, в соответствии с пунк- том 22 требований. Согласно п. 18.14 приказа № 31 контроль принимаемых мер по выявлению, анализу и устранению уязвимостей ПО осуществляется заказчиком и (или) оператором АСУ. Каким образом выполняется данное требование в случае, когда заказчиком или оператором АСУ не осуществляется разработка при- кладного ПО, а используется прикладное ПО (SCADA-пакеты, СУБД, испол- нительные системы ПЛК и т.д.) сторонних разработчиков? Контроль принимаемых мер защиты информации по выявлению, анализу и устранению уязвимостей, в том числе прикладного ПО сторонних разработ- чиков, может проводиться на этапе внедрения системы защиты АСУ при анализе уязвимостей АСУ в соответствии с пунктом 15.7 требований. Кроме того, при приобретении стороннего ПО необходимо предусмотреть процедуру запроса документов, подтверждающих тестирование ПО на уязвимости при разработке. Таблица 1 Комментарии ФСТЭК к подсистеме ОБР приказа № 31 Вид информации (измерительная, управляющая и т.д.) Нарушаемое свойство безопасности Характер чрезвычайной ситуации Степень ущерба Уровень значимости Итоговый уровень значимости Класс защищённости АСУ ТП Наименование 1 Целостность Согласно таблице 3 Согласно таблице 3 = максимальной степени ущерба данного вида информации (УЗ1/УЗ2/УЗ3) = максимальному уровню значимости (УЗ1/УЗ2/УЗ3) К1 = УЗ1 (высокий) К2 = УЗ2 (средний) К3 =УЗ3 (низкий) Доступность Согласно таблице 3 Согласно таблице 3 Конфиденциальность Согласно таблице 3 Согласно таблице 3 Наименование N Целостность Согласно таблице 3 Согласно таблице 3 = максимальной степени ущерба данного вида информации (УЗ1/УЗ2/УЗ3) Доступность Согласно таблице 3 Согласно таблице 3 Конфиденциальность Согласно таблице 3 Согласно таблице 3 1 Оператор АСУ ТП – лицо, обеспечивающее эксплуатацию автома- тизированных систем управления [4].