Взгляд на ИБ со стороны не ИБ-разработчиков
Всем привет!
Меня зовут Елена Галата. Хочу сегодня немного поговорить об информационной безопасности и о том, как она выглядит со стороны тех, кто имеет отношение к созданию ПО. Не только программистов, но и специалистов QA, аналитиков, продуктовиков и других. Я уже много лет в разработке и в последние годы занимаюсь промышленными приложениями, в основном связанными со сбором данных с различных приборов, АСУТП, других информационных систем предприятий. Многие наши компоненты работают в зоне критической инфраструктуры, поэтому безопасность часто выходит на первый план. Так что тема взята неслучайно.
Давайте начистоту: у всех, кто занимается разработкой, все, что связано с безопасностью, вызывает скорее негативную реакцию. Программисты стремятся написать красивый код, желательно производительный, а это совсем не равно безопасному. Специалисты QA — проверить и написать тест-кейсы, исходя из функциональных требований. В этих требованиях аналитики обычно детально расписывают поведение компонента, но ничего не упоминают о том, какие требования безопасности должны выполняться. Продуктовые менеджеры сосредоточены на создании конкурентоспособных продуктов, сокращении издержек и time to market. А тут вдруг возникают какие-то дополнительные ограничения, связанные с портами, аудитом и всем прочим. Зачем мы должны опять пересобирать наши сервисы из-за в очередной раз устаревших базовых образов?!
А действительно, зачем? В этой статье я и хочу обсудить три важных вопроса: почему нам так важна безопасность, как она выглядит со стороны разработки, и куда двигаться дальше.
Вопрос 1. Зачем уделять внимание вопросам ИБ при разработке?
Ответ на этот вопрос достаточно прост и наглядно показан на этом старом, но весьма актуальном и известном графике — см. Рис. 1.
Рисунок 1. Цена исправления дефекта в зависимости от этапа создания ПО
Он демонстрирует, когда (в зависимости от этапа разработки) появляются и когда находятся дефекты в приложениях (синий и оранжевый линии). А резко улетающая вверх красная кривая — стоимость исправления ошибки. Тут видно, что по сравнению с найденным на этапе кодирования дефектом стоимость обнаруженной на этапе релиза ошибки возрастает в 640 раз. И это цена исправления обычного дефекта ПО. Проблемы в области безопасности могут обойтись гораздо дороже, особенно если их первыми найдут злоумышленники.
В последние годы в новостях периодически появляется информация о громких взломах корпоративных систем и суммах, которые вымогатели требуют с пострадавших компаний. Далеко ходить не будем. Вот примеры из промышленности:
— С Saudi Aramco (это национальная нефтегазовая компания Саудовской Аравии) взломщики требовали 50 млн долларов.
— JBS, одному из крупнейших в мире переработчиков мяса, пришлось остановить на какое-то время свои заводы и заплатить 11 млн долларов вымогателям.
— Colonial Pipeline была вынуждена заплатить вымогателям 5 млн долларов. А это крупнейшая трубопроводная система в США, поставляющая газ и нефтепродукты с заводов Мексиканского залива. Из-за взлома пришлось перекрыть трубопровод, который обеспечивает поступление примерно 45% топлива, потребляемого на восточном побережье Америки.
Реальную стоимость ошибки в области ИБ оценить крайне сложно. Кроме платы взломщикам, что бывает не всегда, это еще затраты на восстановление работоспособности предприятия, убытки от вынужденного простоя, штрафы регуляторов, репутационные потери и т. д. Подробности с цифрами можно найти в недавнем отчете IBM Cost of a Data Breach Report 2023.
Кстати, ИТ-отрасль тоже входят в число излюбленных мишеней киберпреступников. Компания Positive Technologies в своем отчете Актуальные киберугрозы: итоги 2022 года рапортовала, что количество успешных атак на ИТ-компании постоянно растет: в 4 квартале прошлого года их число в два раза превысило показатели 1-го квартала. В 63% случаев страдала конфиденциальная информация (в частности, имела место кража исходного кода ИТ-продуктов), в 35% была нарушена основная деятельность предприятия, а еще наблюдалось использование ресурсов компаний для проведения последующих атак, прямые финансовые потери и так далее.
Рисунок 2. Последствия атак на ИТ-компании
Последствия атак на ИТ-поставщиков во многих случаях носят межотраслевой характер: страдают клиенты, в числе которых могут быть и социально значимые учреждения. Следом страдают клиенты клиентов и далее по цепочке. Эксперты ожидают, что атаки на цепочки поставок ПО и вредоносные активности, направленные на компрометацию клиентов ИТ-компаний, будут увеличиваться. Так что, ответ на вопрос о том, почему нам — разработчикам — так важна безопасность, является очевидным. Последствия ИБ-уязвимостей обходятся слишком дорого, и нам нужно всеми возможными способами стараться таких рисков избежать.
Вопрос 2. Как безопасность выглядит со стороны разработки?
Борьба за безопасность со стороны разработки — это прежде всего борьба с уязвимостями.
Проникнуться проблемой нам поможет вот такой график из последнего отчета IBM Security X-Force — см. Рис. 3.
Рисунок 3. Динамика уязвимостей
Начиная с 90-х годов прошлого века, когда начал бурно развиваться Интернет, количество найденных уязвимостей постоянно растет, а в последнее время — просто огромными темпами.
В качестве примеров громких уязвимостей можно привести Log4Shell, от которой пострадали минобороны Бельгии, научное сообщество США, сервера «Майнкрафта» и многие другие. Она набрала максимальный балл по шкале оценки уязвимостей CVSS v3.1. (мы о ней еще чуть позже поговорим), что бывает нечасто. Этот дефект относится к типу уязвимостей RCE (Remote Code Execution), то есть допускает удаленное выполнение произвольного кода. Попасть в систему вредоносный код может какими угодно способами — всего то и надо, чтобы в логах появилась определенная запись.
Другой похожий пример — Spring4Shell. Это уязвимость также относится к классу RCE и имеет рейтинг 9.8 по десятибалльной системе CVSS v3.1.
Из текущего года можно упомянуть две критические уязвимости в популярной JavaScript-библиотеке VM2 (рейтинг 9.8), найденные в апреле. Они тоже связаны с запуском произвольного кода в контексте хоста. Несмотря на наличие патча в последних версиях, автор проекта прекратил его развитие, настоятельно рекомендовал не использовать в продакшене и перейти на альтернативные варианты.
Теперь давайте обратимся к другому ежегодный отчету — Annual Report on the State of Application Security от компании Veracode, который сфокусирован на безопасности приложений. В нем говорится, что за последний год в более чем 74% приложений обнаружена хотя бы одна уязвимость. Причем почти 20% этих уязвимостей имеют высокий уровень опасности. Смотрите Рис. 4.
Рисунок 4. Процент найденных уязвимостей в приложениях
А на Рис. 5 показано распределение уязвимостей в разрезе языков программирования. Интересный факт — это распространение неоднородно. Так приложения на JavaScript имеют дефекты безопасности приблизительно в половине случаев, а на .Net и Java — в четырех случаях из пяти.
Рисунок 5. Процент найденных уязвимостей в приложениях в размере языков программирования
CVE, CWE, CVSS или Структуризация хаоса для организованной борьбы с ним
Еще в 90-х, когда развитие Интернета привело к бурному росту количества уязвимостей, человечеству пришло понимание, что этой лавиной надо как-то управлять. Уже к середине первого десятилетия нового тысячелетия в обиход вошли такие аббревиатуры, как CVE, CWE и CVSS, непосредственно связанные с темой управления уязвимостями. Что они из себя представляют и каким образом помогают в борьбе за безопасность?
Идея создания базы данных известных уязвимостей CVE (Common Vulnerabilities and Exposures) возникла в 1999 году. В нее попадают все известные уязвимости с присвоением им уникального идентификатора и указывается год их обнаружения, порядковый номер в рамках этого года, тип, продукт, версия, воздействие, обязательно способы устранения и другое. Это позволило упростить и стандартизировать процесс работы с уязвимостями.
Вот несколько примеров открытых баз уязвимостей, которыми можно пользоваться: nvd.nist.gov, bdu.fstec.ru, vulners.com, security.snyk.io.
Далее появилась необходимость в объективной и согласованной оценке уязвимостей. Для этого в 2005 году была разработана система CVSS (Common Vulnerability Scoring System). Сейчас CVSS — широко признанный международный стандарт. Вот его текущая версия 3.1, на подходе уже версия 4.0. CVSS, позволяет по определенным формулам рассчитывать и оценивать опасность уязвимостей по десятибалльной шкале, результат потом может быть соотнесен с уровнями опасности (низким, средним, высоким или критическим).
В том же 2005 году вышла первая версия еще одной системы категоризации уязвимостей — CWE (The Common Weakness Enumeration). В отличие от CVE, которая регистрирует реальные случаи уязвимостей и риски в конкретных цифровых продуктах, CWE перечисляет и определяет слабые места, обычно встречающиеся в ПО. CWE не ссылается на какой-то конкретный пример, а дает определения для широко распространенных дефектов безопасности.
Еще есть многочисленные рейтинги уязвимостей, позволяющие увидеть текущую картину. Например, CWE Top 25 от некоммерческой организации MITRE, или OWASP TOP 10 от проекта OWASP. Они публикуют достаточно подробную информацию о рисках, сценариях их развития и предотвращения.
Ежегодный список наиболее опасных уязвимостей публикует также известный американский институт SANS, но нам он, к сожалению, доступен только через VPN.
Вопрос 3. Куда двигаться дальше?
Что же нам может помочь спокойнее работать и минимизировать риски уязвимостей в нашем коде? Ответ очевиден — необходимо двигаться в сторону безопасной разработки. Проблема лишь в том, что дорога туда не проложена, так что строить ее придется самим. Помощь могут оказать соответствующие фреймворки, например, известный OWASP SAMM — см. Рис. 6.
Рисунок 6. Фреймворк безопасной разработки OWASP SAMM v2
Если выразить принципы безопасной разработки просто и коротко, то это:
— всестороннее сотрудничество команд разработки с командой ИБ;
— система управления уязвимостями;
— максимальная автоматизация;
— внедрение практик DevSecOps;
— повышение грамотности в области кибербезопасности и уровня ответственности каждого сотрудника, имеющего отношение к созданию ПО;
— привлечение Security Сhampions.
Заинтересовать работников компании вопросом кибербезопасности помогут соответствующие новостные рассылки, дополнительное обучение, единый портал с собранными в одном месте материалами по безопасности, возможно даже CTF-турниры.
Путь к безопасной разработке — сложный и долгий, но пройти его крайне важно для минимизации рисков появления уязвимостей в программных продуктах. Выше мы убедились, что эти уязвимости могут обойтись неимоверно дорого и для ИТ-компаний, и для их клиентов. Как идет этот процесс в нашей компании — пожалуй, тема для целой серии статей. Как будем готовы, отдельными аспектами нашего опыта будем здесь делиться.
