Актуальные вопросы защиты информации

Конференция “Актуальные вопросы защиты информации” прошла в феврале в рамках форума “Технологии безопасности”. Специалисты ФСТЭК России и представители отрасли выступили с докладами, посвященными безопасности критической информационной инфраструктуры, а также обозначили ряд проблем, связанных с реализацией нормативно-правовых актов, совершенствованием сертификации и повышением доверия к средствам защиты информации.

Безопасность КИИ

Первая часть форума была посвящена безопасности критической информационной инфраструктуры и нормативно-правовым актам в данной области.

На сегодняшний день в перечень объектов критической информационной инфраструктуры включено более 28 тыс. объектов. Около 1100 субъектов КИИ провели категорирование и предоставили сведения о 2 тыс. объектов. Большая часть этих сведений уже рассмотрена.

"Мы делаем успехи в утверждении недостающих нормативно-правовых актов и считаем, что все условия реализации федерального закона с точки зрения нормативно-правового регулирования созданы. Все документы, находящиеся на рассмотрении, в ближайшее время будут приняты", – отметил заместитель директора ФСТЭК России Виталий Лютиков.

Поправки не внесут глобальных изменений в процедуру категорирования, за исключением нескольких показателей. Поэтому в целом концепция правил категорирования останется неизменной. Объекты, которые уже прошли данную процедуру по старым показателям, должны быть пересмотрены.

Что касается приказов ФСТЭК, то основные изменения будут касаться вопросов категорирования, связанных с учетом интегрированных структур дочерних обществ, но кардинальных изменений в данных документах не ожидается.

Исходя из положения 187-го федерального закона, ФСТЭК предложил утвердить постановления об административной ответственности по определенным процедурам. Эта работа завершится в первом полугодии 2019 г.

Постановление правительства № 676 в части согласования модели угроз и технических заданий уже работает, и количество рассматриваемых технических заданий увеличивается. В текущем году завершится работа над типовыми моделями угроз для различной архитектуры государственных информационных систем.

Сертификация

Еще одно направление работы – это совершенствование системы сертификации средств защиты и повышение доверия к сертифицируемым средствам защиты информации. В прошлом году вступило в силу положение о системе СЗИ. Оно регламентировало сроки выполнения процедуры. Кроме того, был увеличен срок действия сертификата, который распространяется на производителя – разработчика средств защиты. Эти изменения призваны избавить потребителя от необходимости продления сертификатов, как это было раньше. Обязанности, связанные с поддержанием сертификата, теперь лягут на плечи разработчика-производителя.

Требование доверия

Также важный документ, который утвержден в этом году и зарегистрирован в Минюсте, – требования доверия. Документ заменит РД НДВ и установит требования к разработке, испытаниям и поддержке системы. С 1 мая прием заявок на соответствие сертификации по РД НДВ прекращен.

В ближайшее время появится Методика выявления уязвимости декларируемых возможностей программного обеспечения. В первую очередь документ увидят лаборатории, которые являются его целевой аудиторией. Объем испытаний увеличится, и хотя методы останутся традиционными, в них будут учтены тенденции в области статического и динамического анализа. В методику также войдут рекомендуемые виды или классы средств, которые можно использовать. Для этого потребуется повышение уровня подготовки специалистов

Категорирование

В последнее время увеличивается объем поступающих во ФСТЭК сведений об объектах, которые провели категорирование. Особенно активно процесс категорирования проходит в сфере здравоохранения, энергетики и топливно-энергетического комплекса. В аутсайдерах оказались сферы науки, ракетно-космической промышленности и горнодобывающей промышленности.

"Сведения о результатах категорирования нам предоставили более 2 тыс. объектов критической информационной инфраструктуры, но около 600 сведений нам пришлось вернуть на доработку из-за ошибок, которые допустили заявители, – рассказывает заместитель начальника управления ФСТЭК России Елена Торбенко, – например, в документах занижают значения показателей критериев значимости. Это одна из причин, по которой мы пересмотрели 127-е постановление правительства ".

ФСТЭК России уже разработал ту часть нормативно-правовой базы, которая необходима для реализации полномочий службы после выхода 188-ФЗ.

Нормативная база помогает субъекту определить, относится ли он к области действия федерального закона, провести категоризацию, а также внедрить меры по обеспечению безопасности значимого объекта в случае, если он является владельцем объекта.

Вопрос о принадлежности к субъекту – один из самых популярных. Чтобы ответить на него, необходимо проанализировать, чем занимается субъект и какие полномочия он реализует. Если его полномочия совпадают с тринадцатью сферами, определенными федеральным законом, и у него есть объекты, которые реализуют полномочия ИС, АСУ или ИТКС, то субъект попадает в сферу деятельности федерального закона.

Субъект попадает под действие закона, если у него есть критические процессы. Согласно постановлению № 127, это управленческие, технологические, производственные, финансово-экономические или иные процессы, при нарушения которых в результате действия компьютерной атаки будет нанесен ущерб одной из пяти групп, определенных законом, и пяти группам категорий значений показателей, которые определены в приложении к 127-му постановлению.

Чтобы определить перечень объектов, подлежащих категорированию, прежде всего необходимо оценить последствия от нарушения производственных процессов, и если такие нарушения будут, то нужно включать объект в перечень КИИ.

В соответствии с 127-м постановлением согласование категорирования с вышестоящими инстанциями обязательно только для подведомственных организаций либо в том случае, если регулятор области определил необходимость такого согласования.

Возможный ущерб оценивается не по всем показателям критериев значимости. При оценке по пяти группам показателей должны быть оценены все критерии либо сделан вывод о том, что критерий не применяется. Можно также указать конкретное значение критерия, войдет ли он в три категории или будет меньше нижнего значения третьей категории. Тем не менее оценка должна быть проведена по всем показателям критериев значимости. Зачастую в обосновании того, что критерий неприменим, указывают применение технических мер защиты информации. Однако это не может являться обоснованием для того, что критерий неприменим. Прочерков в форме также не должно быть.

В 127-е постановление правительства в ближайшее время будут внесены изменения. Прежде всего, если объект относится к первой категории по экономическим или экологическим показателям, то остальные категории оценивать не придется. Более подробно будет описана процедура категорирования вновь создаваемых объектов, когда задается категория и когда она может применяться.

Появится подробное описание вопросов функционирования и создания комиссий по категорированию. Данные комиссии по субъектам, владеющим значимыми объектами, должны быть постоянно действующими. В документах появятся четкие указания, когда комиссии будут сформированы и какие особенности есть в их работе.

В постановлениях, а именно в правилах категорирования, будет указано, что при оценке показателя значимости должен рассматриваться наихудший сценарий, т.е. максимально возможное воздействие на систему субъекта. Будет описано, каким образом производить категорирование взаимосвязанных объектов. Например, если от нарушений объекта может пострадать другой, зависимый объект, то это также нужно учитывать при категорировании.

ФСТЭК России планирует предложить правительству установить срок утверждения перечней объектов, подлежащих категорированию, июнем 2019 г. Если проект будет одобрен, то с июня 2019 г. у субъектов останется один год на категорирование существующих объектов. На все объекты может быть создан, написан и утвержден только один акт категорирования.

Сведения о категорировании будут отправляться в ФСТЭК и в печатном, и в электронном виде, т.к. поступает очень большой объем сведений от некоторых субъектов.

Ряд показателей критериев значимости также пересмотрят. Но прежде всего в показателях 2 и 3 будет четко прописана нижняя граница территориального образования. Муниципальные будут рассматриваться с численностью от 2 тыс. человек.

Показатель 4, связанный с субъектами, оказывающими услуги связи, теперь привязан к количеству абонентов. Эти изменения ФСТЭК обсудил с субъектами, работающими в данной области, и учел их пожелания к данному показателю.

Изменение формулировок коснулось и показателя 8. В нем была изменена нижняя граница оценки экономического показателя исходя из практики категорирования.

Экономический показатель 9, который вызывал много вопросов, также был переформулирован. Он остался без разделения по субъектам, потому что для крупных субъектов Российской Федерации достаточно сложно посчитать, в какой из бюджетов и в каком объеме производятся отчисления.

Показатель 13 – это государственный оборонный заказ, очень чувствительный для страны показатель. Поэтому нижняя граница будет считаться от минимального ущерба, т.е. показатели выше нуля также будут рассматриваться. Кроме того, в показателе исправлены некоторые технические ошибки, которые произошли на момент издания документа. Перечень будет дополнен сносками, поясняющими, что такое экологические последствия, прекращение или нарушение функционирования значимого объекта. Это исключит неоднозначные трактовки терминов.

Для уточнения понятия субъекта планируется введение дополнительных граф. Например, отдельная графа будет утверждена для указания типа объекта. Приказы 235 и 239 ФСТЭК России пересмотрят, соответственно, и в 235-м и в 239-м приказе уточнят процедуры, связанные с вновь создаваемыми объектами. В документах появятся уточнения требований к уровню подготовки и образования специалистов, которые будут работать с документами и обеспечивать безопасность значимых объектов. Естественно, меры доверия также должны быть внедрены в данные требования.

Методические документы

Помимо нормативно-правовых актов, будет разработан ряд методических документов. Они помогут субъектам реализовывать те требования, которые предписывает законодательство.

Прежде всего это методика категорирования объектов КИИ. Данный документ даст рекомендации по форме акта категорирования, опишет порядок проведения категорирования, формирование работы комиссии, методы выявления значимых объектов, подлежащих категорированию, и порядок взаимодействия с регуляторами в области безопасности значимых объектов.

Вторым важным документом станет методика оценки показателей в различных областях, таких как экономическая, социальная и экологическая значимость.

Моделирование угроз

В области моделирования угроз появятся два типа документов. Прежде всего это описания типовых моделей угроз безопасности информации, привязанных к архитектуре систем, в первую очередь к распределенной системе, SKADA-системе.

Вторая группа документов будет посвящена описанию базовых моделей угроз, которые характерны для объектов, функционирующих в определенной сфере деятельности, например здравоохранении и ТЭК. Документы этих групп облегчат выбор рассматриваемых угроз.

Порядок сертификации и требования к средствам защиты информации

За последний год произошли изменения в сертификации СЗИ и вышли новые нормативные документы. Прежде всего это Положение о системе сертификации, Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий средств защиты информации, а также Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении.

Положение о системе сертификации средств защиты информации устанавливало порядок сертификации СЗИ с 1995 г., но с 1 августа 2018 г. этот документ не применяется при проведении сертификации средств защиты информации в системе сертификации ФСТЭК России. Документ, известный как РД НДВ, с мая 2019 г. при проведении сертификации новых СЗИ не используется.

Процедуры сертификации фактически не изменились, но вместе с тем в документе были уточнены процедуры и установлены конкретные сроки их осуществления. Это сделано для упрощения работы с заявителем, лабораторией и органом по сертификации. Теперь процесс сертификации можно контролировать, а лаборатории органов по сертификации не будут затягивать сроки исполнения работы.

В документе четко установлены критерии, связанные с отказом принятии решения по проведения сертификации, критерии для принятия решения о приостановлении и прекращении сроков действия сертификатов соответствия.

В Положении также установлено, кто может являться заявителем на сертификацию. Это прежде всего изготовитель средств защиты информации, который разрабатывает и производит это средство. Данный тип заявителя для ФСТЭК России является преимущественным. Однако заявку может подать и организация, которая планирует эксплуатировать средство защиты информации.

"Желательно, чтобы перед заказом средства защиты организация запросила у поставщика этого средства действующий сертификат соответствия ФСТЭК России, – подчеркнул начальник управления ФСТЭК России Дмитрий Шевцов, – но зачастую организации задумываются об этом гораздо позже и попадают в безвыходную ситуацию. Тем не менее решение этой проблемы должно быть. Организации, которые эксплуатируют средства, могут выступать в качестве заявителя на проведение сертификации средств защиты информации, а затем будут поддерживать безопасность этого средства: обновлять его, взаимодействовать с разработчиком. Правда, зачастую у этого типа заявителей таких возможностей нет. Необходимо иметь в виду, что в процессе сертификации данные будут проверяться и в случае невелизации процедур по поддержке и невозможности их реализации положительного решения о выдаче сертификатов соответствия не будет. Кроме того, организации, эксплуатирующие СЗИ, могут подать заявку на сертификацию такого средства защиты только в том случае, если на рынке сертифицированных средств защиты информации отсутствуют идентичные СЗИ серийного производства. Мы это учли при рассмотрении заявок на получение сертификации".

В документе четко установлены требования к изготовителю средств защиты информации в части наличия у него лицензии ФСТЭК России на деятельность по технической защите информации, содержащей и оставляющей государственную тайну, а также на проведение работ по СЗИ, содержащей сведения, составляющие государственную тайну, если планируется применение средств для защиты данной информации, или на деятельность по разработке производств средств защиты конфиденциальной информации. Если при подаче заявки на сертификацию у разработчика нет лицензии ФСТЭК России на соответствующий вид деятельности, решение о проведении сертификации не может быть принято.

В новом Положении увеличен срок действия сертификата до пяти лет, в зависимости от того, какой срок указан в заявке на проведение сертификации. С 1 августа 2018 г. все сертификаты выдаются на пять лет. Средства защиты информации могут измениться по окончании срока действия сертификата соответствия при условии выполнения требований по безопасности информации и осуществление технической поддержки данного средства заявителем.

Срок действия сертификата необходим для заявителя. В рамках этого срока заявитель осуществляет производство и поставку сертифицированных СЗИ. Если срок закончился, заявитель может подать заявку на его продление. Потребитель, который эксплуатирует СЗИ, должен следить за тем, чтобы применение средств соответствовало требованиям к безопасности информации. Например, если приказом предусмотрено применение того или иного класса защищенности СЗИ, то применять средства более низкого класса, не соответствующего этим требованиям, нельзя. Чтобы потребитель СЗИ мог планировать процедуры по его замене и модернизации, заявители на сертификацию должны будут представить информацию о предполагаемых сроках поддержки. Эта процедура поможет планировать применение средства защиты информации и установить срок эксплуатации.

В соответствии с Положением в заявке на сертификацию указывается назначение СЗИ.

"К сожалению, мы отклонили огромное количество заявок только потому, что в графе "назначение" были указаны сферы, которые не относятся к компетенции нашей структуры. Это защита коммерческой тайны, программное обеспечение игровых автоматов и другие сферы. В этом разделе заявки необходимо привести категорию объекта информатизации, класса защищенности государственных систем, автоматизированных систем управления производственными технологическими процессами, категории значимости объектов критической информационной инфраструктуры, уровень защищенности персональных данных. Вопросы применения сертифицированных решений регламентированы законодательством РФ. Если в графе будет указана иная информация, то решение о проведении сертификации не будет принято", – отметил Дмитрий Шевцов.

Положение предусматривает, что заявитель определяет тип и указывает его в заявке на сертификацию. То есть он относит свое средство к тому или иному типу средств защиты информации. Во-первых, это позволит сделать правильный вывод о тех требованиях безопасности, которые должны предъявляться к данному СЗИ. Во-вторых, позволит заявителю на стадии подачи заявки на сертификацию правильно выбрать требования по безопасности информации. В-третьих, поможет проанализировать данные, приведенные в государственном реестре сертифицированных средств защиты информации.

В связи с созданием требований доверия ФСТЭК России ставит перед собой задачу доработать требования к средствам защиты информации, которые были утверждены в 2011 г.

Требования к новым типам СЗИ

Следующее направление – разработка требований к новым типам средств защиты информации. Это требования к средствам управлению потоками информации, к средствам виртуализации, а также иным типам средств защиты информации.

В июле 2018 г. приказом ФСТЭК России утверждены требования доверия, а в ноябре было принято решение о том, что в течение шести месяцев требования доводятся до испытательных лабораторий заявителей на осуществление сертификации. Сейчас данный документ подготовлен к изданию и его можно заказывать в установленном порядке. Документ имеет пометку "Для служебного пользования", порядок получения приведен на сайте ФСТЭК России.

В мае 2019 г. будет опубликовано информационное сообщение о применении требований доверия и методики по выявлению уязвимости НДВ. Все заявки во ФСТЭК после 1 мая должны подаваться на соответствие требованиям данного документа. Также с 1 мая 2019 г. заявки с указанием РД НДВ не принимаются. Информационное сообщение поможет определиться с требованиями к тем типам средств, которые утверждены с 2011 г. Это средства антивирусной защиты, системы обнаружения вторжений.

С 1 мая 2019 г. должны применяться новые требования доверия. Данные требования не устанавливают уровень, который характеризует безопасность применения средств для обработки и защиты информации ограниченного доступа. Кроме того, требования доверия являются обязательными при проведении сертификации средств защиты информации в системе сертификации ФСТЭК России.

Документом устанавливается шесть уровней доверия, из которых низкий уровень – шестой, а самый высокий – первый.

"Мы не изобретали новые классификации, новые категорирования. У нас классы средств защиты информации четко соответствуют уровням доверия – их у нас шесть, как и шесть уровней доверия", – отметил Дмитрий Шевцов.

Требования доверия содержат три блока информации

Во-первых, это требования к разработке и производству средств защиты информации. В них указаны требования по разработке безопасного ПО, которые повышаются в зависимости от уровня доверия.

Во-вторых, требования к проведению испытаний СЗИ, которые включают в себя требования к испытаниям по выявлению уязвимостей и недекларируемых возможностей средств защиты информации. В этом разделе приведено соответствие требований методическим документам – методике выявления уязвимостей и недекларируемых возможностей.

В-третьих, это требования к поддержке безопасности средств. От шестого уровня доверия к первому требования повышаются. Например, если на шестом требуется достаточное информирование обеспечения целостности, то на более высоких уровнях уже необходимо, чтобы данное обновление осуществлялось исключительно с ресурсов заявителя на классификацию. Кроме того, уже на четвертом уровне требуется, чтобы заявитель на осуществление сертификации имел информацию о том, кто эксплуатирует средства защиты, и мог его своевременно информировать о вышедших обновлениях и появлениях уязвимости средств защиты информации.

"Требования доверия неразрывно связаны с новым методическим документом, который 11 февраля был утвержден ФСТЭК России. Естественно, методика применяется при проведении сертификации СЗИ в системе сертификации на соответствие требованиям доверия. Кроме того, любой документ позволяет пользоваться им и для иных целей, например для проведения приемки, испытаний средств защиты информации. Вы можете брать положения этого документа и использовать их для того, чтобы обеспечить безопасность коммерческой тайны или провести испытания тех средств, которые у вас для этого применяются. Но прежде чем принять решение, мы всегда советуем связаться с нами и обсудить вашу проблему", – поясняет Дмитрий Шевцов.

Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении

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

Методика разрабатывалась как на основе существующих практик в области выявления уязвимостей и недекларированных возможностей в программном обеспечении, так и на основе имеющихся нормативных документов, регулирующих данную область. Документ предназначен в первую очередь для испытательных лабораторий, которые занимаются сертификацией, но будет полезен и разработчикам других программных средств.

Основу методики составляют требования к работам, которые необходимо проводить в ходе исследования по выявлению уязвимости. Этому посвящены 3, 4 и 5-й разделы. Кроме того, в документе представлены справочные приложения, где описаны методы и средства выявления уязвимостей, указана методика расчета потенциала нападения, а также даны классификации как уязвимостей, так и НДВ.

Документ содержит перечень исходных данных, которые требуются для выполнения той или иной работы, требования к содержанию, методы и средства, используемые при выполнении работы. Каждая работа предполагает наличие усиления, т.е. ряда качественных усовершенствований, которые могут быть выполнены в рамках той или иной задачи. Это сделано для ранжирования работы по уровню контроля, их в документе предусмотрено шесть.

Соответственно, при ранжировании требований к работам учитывался потенциал нарушителя. Рассматривались три потенциала: нарушители с низким потенциалом, средним и высоким. Возможности нарушителя с низким потенциалом сводились к возможности эксплуатации известных уязвимостей и известных средств, которые были опубликованы ранее. При этом под "высоким" нарушителем понимался тот, который обладает группой высококвалифицированных экспертов, занимающихся выявлением уязвимостей и имеющих богатый опыт применения и использования средств выявления уязвимостей. Таким экспертам доступен исходный код. Это стало одной из причин, почему уже с 4-го уровня требуется обязательное наличие исходного кода.

Важную роль в документе играют методы и средства выявления уязвимостей. С этого года может быть сопоставлено несколько методов выявления уязвимостей. При этом один метод может использоваться сразу в нескольких работах. Средства – это то, при помощи чего проводится исследование. Необходимо отметить, что в методике представлены лишь общие описания методов и средств.

Применение того или иного метода или средства зависит как от функциональных возможностей объекта, оценка которого исследуется, так и от технологий, которые заложены в само средство выявления.

Методы выявления уязвимостей делятся на целевые и вспомогательные. К целевым методам относятся те, которые непосредственно позволяют выявить уязвимость или недекларированную возможность. Вспомогательные –улучшают эффективность целевого метода или предоставляют ему некие исходные данные. Каждый метод хорош в определенной области, но нет метода, который решает все задачи.

Все типы средств, которые отмечаются в методике, представлены на рынке. Но необходимо учитывать, что для ряда технологий таких средств может не оказаться, например статических анализаторов для каких-либо языков программирования. В методике есть рекомендации и для таких случаев.

Работы, к которым предъявляются требования в методическом документе, сгруппированы по видам, а виды работ разбиты на этапы. Этапы предварительного анализа позволяют создать представление об объекте оценки и включают в себя методы анализа документации и других доступных источников, а также развертывание исследовательского стенда. Выявление уязвимостей и НДВ осуществляется в ходе применения ручного, статического, динамического и экспертного анализов. При этом эффективность экспертного и ручного анализов оценивается квалификацией эксперта, который применяет и выполняет тот или иной вид работ. Статический и динамический анализы основаны на применении средств автоматизации. Для этих работ важно, насколько разработчик средств выявления уязвимости вложился в технологию выявления уязвимостей и НДВ.

Немаловажным является этап оформления документации, в которой специалист разрабатывает частные методики с учетом специфики объекта оценки и оформляет протокол исследования. Первый этап этого процесса – подготовка к исследованию. На этом этапе исследователи проводят анализ конструкторской, эксплуатационной или другой документации, которую они получили от заявителя. На основе этих сведений или других источников исследователь формирует представление об объекте оценки: какие функции в объекте оценки существуют, модули, их назначение, какой порядок действий требуется для установки объекта оценки, в каких средах он функционирует. На основе этой информации исследователи приступают к развертыванию исследовательского стенда, где настраивают все те среды, которые заявлены в документации, и в которых может функционировать объект оценки. В ходе установки объекта оценки исследователю нужно снимать все взаимодействия объекта оценки со средой функционирования. Это делается для того, чтобы в дальнейшем установить факт отсутствия возможности установки объекта оценки в состоянии, отличном от заявленного.

В ходе развертывания исследовательского стенда проводится также антивирусный контроль сертифицированными антивирусными средствами с актуальными на момент исследования базами данных. Таких средств должно быть несколько, и обязательно от различных разработчиков, чтобы результаты анализа были объективными. Первая группа работ, связанных непосредственно с самим исследованием объекта оценки, – это экспертный анализ.

Экспертный анализ включает анализ архитектуры объекта оценки, выявление потенциальных уязвимостей объекта оценки и тестирование проникновения. Данный вид работы направлен на выявление архитектурных уязвимостей, которые вызваны неправильным выбором или взаимодействием компонентов и блоков, из которых состоит объект, а не тем, как именно реализован и написан код того или иного блока. Важная задача на этом этапе – это выявление известных уязвимостей в данном продукте и, связанных с известными уязвимостями заимствованных компонентов, которые используются в объекте исследования, объекте оценки.

"Есть предположение, что необходимо ограничить область поиска уязвимостей по существующим базам данных, но мое мнение другое, – отметил начальник лаборатории ФАУ "ГНИИИ ПТЗИ ФСТЭК России" Алексей Сердечный. – Наоборот, нельзя ни в коем случае ограничивать и сужать область как источников, так и элементов внутри одного источника в области поиска известных уязвимостей. Приведу характерный пример.

Совсем недавно была выявлена уязвимость в СУБД SQLight. Это встраиваемая СУБД, которая поставляется в виде исходного кода и используется многими разработчиками средств, где нужна обработка данных. Не полноценная СУБД, а объект с неким ограниченным функционалом средств. Данная СУБД предоставлялась и встраивалась в виде исходного кода в ряд других продуктов. При этом зачастую невозможно определить, использует ли тот или иной продукт эту СУБД или не использует.

Осенью прошлого года разработчики устранили уязвимость, которая позволяет выполнить произвольный код на машине. Это один из самых опасных типов последствий, к которым может привести уязвимость. Исследователи быстро сообщили разработчикам SQLight об этой уязвимости. Разработчики в течение трех дней устранили ее и на своем информационном ресурсе опубликовали этот патч, код, в каком месте была исправлена ошибка, и перенесенный тест, по которому специалистам можно было достаточно быстро сформировать тот код, который приводит к эксплуатации уязвимости. Но при этом сама уязвимость не была подана как уязвимость и, соответственно, ей не был присвоен никакой идентификатор, и она не была занесена ни в какие базы данных. Тот разработчик, в частности браузер Google Chrome, который использовал этот компонент, узнал об этой уязвимости только через 40 дней – уже после общедоступной публикации данной информации. Если не рассматривать подобные источники и не оценивать уязвимости заимствованных компонентов, как динамических, так и тех, которые интегрированы в исходный код, то можно допустить большую брешь в системе".

Статический анализ

Следующая группа работ – это статический анализ, при котором основным объектом является исходный код программы. Статический анализ ранжирован по нескольким видам.

Наиболее простой – это синтаксический анализ, при котором анализируется лишь абстрактное синтаксическое дерево. Данный вид анализа не позволяет выявить много уязвимостей, требующих более сложных процедур. Вероятность наличия уязвимостей, выявленных в его ходе, нужно подтверждать, т.к. происходит много ложных срабатываний при обнаружении уязвимостей. Поэтому более сложное с точки зрения анализа является контекстно-чувствительное, чувствительное и включаемое выполнение анализа, который дает более качественный результат.

Самый сильный среди всех статических анализов – это формальная верификация, но для его выполнения требуется много ресурсов, поэтому он применяется ограниченно для высоких уровней защиты и контроля.

Динамический анализ связан с изучением объекта оценки в ходе его функционирования. В первую очередь это фаззинг-тестирование, при котором на вход в программы подается большое количество данных и фиксируются нарушения штатного функционирования объекта оценки. В частности, это могут быть системы прикладного программного обеспечения, отказы, CRASH, закрытие программы. Для аппаратного обеспечения данный вид работ ограничен, потому что не всегда можно зафиксировать отказ того или иного компонента. В ряде случаев отказ устройства в ходе фаззинг-тестирования может быть зафиксирован только по миганию клавиши или перезагрузке в рабочей недоступности самого устройства, которое исследуется.

Если какие-либо участки кода не были проанализированы в ходе предыдущих работ или фаззинг-тестирования, то используются знания и навыки эксперта, который детально рассматривает тот или иной участок кода программы и на основании своего опыта пытается выявить уязвимость или недекларированную возможность.

На последнем этапе осуществляется оформление документации, протоколов по результатам исследования. К протоколам должны прилагаться все свидетельства и результаты работ средств автоматизации, которые были использованы в ходе исследования объекта оценки. Таким образом, данный документ устанавливает требования для работ, которые исследователь совершает в ходе действия над объектом оценки. Эти работы ранжированы по шести уровням контроля. Кстати, в ходе выполнения этих работ могут быть выявлены только уязвимости в программном обеспечении, а уязвимости, связанные с некими аппаратными компонентами его архитектуры, – это область отдельного документа, который сейчас находится на рассмотрении.

Банк данных угроз безопасности информации

Банк данных угроз был создан для операторов коммуникационных систем, государственных информационных систем и организаций, которые занимаются вопросами построения защищенных информационных систем. Банк данных функционирует уже пять лет. В нем содержатся сведения о 213 угрозах безопасности и более 20 тыс. уязвимостей. Основной целью создания банка данных угроз была разработка некой методической базы данных, содержащей сведения об угрозах и уязвимостях. На текущий момент, помимо этой информации, в банке данных хранится методический инструмент, позволяющий операторам коммуникационных систем проводить работы по выявлению и анализу уязвимостей в таких системах.

"Мы еженедельно наполняем банк новыми сведениями. За 2018 г. в банк данных было включено более 1600 уязвимостей. Сейчас мы включаем за неделю в банк данных угроз более 100 уязвимостей. Это практически в 2,5 раза больше, чем в 2018 г. Мы приобрели достаточные методические инструменты, разработали некие информационные системы, которые позволяют автоматизированно осуществлять сбор данных об уязвимостях и доставлять их в определенном виде, а также провели ряд дополнительных регламентных работ, которые позволили нам увеличить это количество. По данным метрики посещения сайта банка данных угроз в 2018 г., количество пользователей и уникальных посещений увеличилось в 1,5 раза по сравнению с предыдущим годом. Это свидетельствует о том, что ресурс востребован и используется на практике, – подчеркнула заместитель начальника отдела управления ФСТЭК России Ирина Гефнер. – Самым посещаемым является раздел, содержащий сведения об угрозах и уязвимостях. Также пользователи заходят в раздел "Документы", где размещены методические документы ФСТЭК России".

В банк данных ежегодно включаются сведения о новых угрозах. Так, в 2018 г. в банк были добавлены сведения о шести новых угрозах безопасности информации. Для выявления угроз анализируются открытые информационные источники, современные технологии, способы эксплуатации новых уязвимостей и реализации компьютерных атак. На их основе формируется описание уязвимостей. Особое внимание уделяется угрозам безопасности информации, связанной с автоматизированными системами управления производством, с особенностями их эксплуатации и применения в таких системах современных информационных технологий (мобильные устройства, технологии виртуализации).

Нельзя забывать и о современных технологиях, которые используются в так называемых стандартных информационных автоматизированных системах.

"Мы добавляем угрозы безопасности информации, связанные с применением новых технологий искусственного интеллекта, технологии больших данных и другими технологиями, – рассказывает Ирина Гефнер. – Предусмотрены критерии по контекстному поиску, по поиску уязвимостей и угроз безопасности информации, исходя из последствий нарушения конфиденциальности, целостности и доступности, а также исходя из потенциальных нарушителей".

ФСТЭК России внедрил новые классификационные признаки, чтобы упростить поиск и выбор угроз. Классификация представляет из себя некий классификационный портал, состоящий из четырех основных компонентов: классификации угроз по инцидентам, способам реализации, типам нарушителей и объектам воздействия. На сегодняшний день все 213 угроз, которые содержатся в банке данных, классифицированы по этим признакам. Классификация является серьезным методическим инструментом при моделировании и общей оценке угроз, актуальных для информационных систем.

На сегодняшний день более 50% уязвимостей, добавленных в банк, имеют критичный и высокий уровень опасности. Это говорит о том, что уязвимости обладают высоким потенциалом, причем больше половины их них могут быть реализованы удаленно и представляют большую опасность для информационных систем. Наибольшее количество уязвимостей, содержащихся в банке (более 12 тыс.), приходится на операционные системы, в том числе операционные системы семейства Linux, Windows и российские операционные системы. В банке данных угроз содержится информация о 300 уязвимостях отечественного программного обеспечения. Их них всего 42% связанны с уязвимостями высокого и критичного уровня. Аналогичная ситуация наблюдается с классификацией по типам программного обеспечения.

Наибольшее количество уязвимостей (больше 70%) приходится именно на уязвимости операционных систем. Таким уязвимостям необходимо уделять особое внимание при оценке анализа защищенности информационных систем. С сентября на сайте ФСТЭК России размещено программное обеспечение, которое называется ScanOvaL. Это средство автоматизации, выявляющее уязвимости в программном обеспечении. ScanOvaL выявляет критичные системные параметры программного обеспечения, сравнивает их с описаниями и определяет, являются ли данные уязвимости критичными для информационной системы или нет.

Базовое описание содержит более 300–700 уязвимостей. Любой пользователь может скачать его, установить и проанализировать свою информационную систему на предмет наличия уязвимостей, содержащихся в банке данных угроз.

За 2018 г. поступила информация о 46 уязвимостях, из которых 18 уязвимостей были включены в банк данных, а 22 находятся в обработке. Для совершенствования механизма включения уязвимостей в банк данных ФСТЭК России в июле был утвержден методический документ – Регламент включения уязвимостей в банк данных угроз. Регламент определяет порядок действий между оператором сайта банка данных угроз, исследователями и разработчиками программного обеспечения. По данным работы регламента на текущий момент в банк данных включены сведения о 25 уязвимостях.

Для увеличения количества выявленных уязвимостей ФСТЭК России ведет работу по привлечению заинтересованных организаций, которые в рамках своей основной деятельности проводят мониторинг уязвимостей по результатам анализа открытых источников. В настоящее время соглашения заключены с пятью организациями, предоставляющими сведения об уязвимостях программного обеспечения.

По результатам этой работы ФСТЭК России формирует рейтинг исследователей уязвимостей программного обеспечения, дорабатывает методические инструменты по аналогии со ScanOvaL. В 2019 г. планируется разработка программного обеспечения, которое позволит оптимизировать работу по моделированию угроз. Это автоматизированное программное обеспечение будет включать интерфейс с определением структурно-функциональных характеристик информационных систем, включающих ПО, информационные технологии, потенциал нарушителя. На основании классификационных признаков, которые оператор введет на сайте, в банке данных сформируется отчет вероятных угроз, актуальных для информационной системы, с учетом ее описания. Оператору останется лишь провести определение актуальности таких угроз, и модель будет готова. Планируется также разработка утилиты ScanOvaL для Linux-подобных систем по аналогии с операционными системами Windows, которые существуют сейчас.

Материал подготовила
Анастасия Гаврилова