Какие бывают недостатки в ПО
Классификация программного обеспечения
-
По уровню, на котором оно работает:
-
сетевое ПО – обеспечивает работу сети и сетевых устройств (стеки протоколов, операционные системы на маршрутизаторах);
-
системное ПО - предназначено для управления работой вычислительной системы (операционные системы, сервисы уровня операционной системы, СУБД);
-
прикладное ПО - это комплекс программ для решения специфичных задач, т.е. задач определённого класса конкретной предметной области (web-приложения, десктопные приложения).
-
По источнику (по производителю):
-
стандартное ПО – характеризуется массовым производством и внедрением, автоматизирует общие для всех потребности в IT-технологиях (операционные системы, web-сервера, прикладные утилиты);
-
заказное ПО – производство под заказ, автоматизация процессов конкретной организации, для которых пока еще нет стандартного ПО (различного рода приложения, т.е. прикладное программное обеспечение);
-
собственное ПО – производится собственными силами, автоматизация собственных процессов для которых пока еще нет стандартного ПО.
При этом возможно, что и заказное и собственное программное обеспечение будет написано не с нуля, от начала и до конца, а на основе какого-то фреймворка или платформы. Например, на базе платформы 1С или на базе платформы SAP, которая уже решает большое количество задач в какой-то предметной области, но не все или не так как этого бы хотел Заказчик.
Совместив две классификации (по уровню и по источнику), можно увидеть тенденцию (см. Рис.1.):
-
стандартное ПО обычно коррелирует с системным и сетевым,
-
собственное и заказное программное обеспечение обычно коррелирует с прикладным программным обеспечением, именно по той причине, по которой было рассказано выше.
Рисунок 1. Тенденция корреляции ПО.
Причина: Стандартные процессы (работа сети и вычислительных систем) автоматизируют стандартным ПО, а специфические процессы конкретной организации стандартным программным обеспечением не могут быть автоматизированы (разрабатываются под заказ или собственными силами) и по определению являются прикладными.
Классификация недостатков программного обеспечения
Недостатки, влияющие, в том числе на безопасность информационной системы, могут быть привнесены в нее на различных уровнях жизненного цикла:
-
на уровне проектирования;
-
на уровне непосредственной разработки и кодирования;
-
на уровне внедрения и конфигурирования;
-
на уровне эксплуатации этого программного обеспечения.
Соответственно, в системном, сетевом и прикладном программном обеспечении могут встречаться недостатки этих четырех классов.
На поиск каких недостатков стоит тратить время и деньги
Рассмотрим, какие же недостатки имеет смысл искать для типовой организации и почему.
При этом необходимо помнить, что:
-
стандартное программным обеспечением чаще всего является системным, сетевым (исключение - стандартное прикладное программное обеспечение, выполняющее типовые прикладные задачи, например, пакет MS Office);
-
заказное и собственное программное обеспечение будет являться практически всегда прикладным.
Поиск недостатков стандартного ПО
Вначале рассмотрим, почему для типовой организации в рамках проекта по анализу защищенности для стандартного ПО не рационально заказывать поиск уязвимостей проектирования и кодирования. Мы не рассматриваем различного рода огромные компании (например, Google или Microsoft), а также службы безопасности государства (например, ФСБ).
Что такое уязвимости кодирования и проектирования стандартного программного обеспечения? Это те самые недостатки, при нахождении которых производитель стандартного программного обеспечения, выпускает патчи.
Представим, что такая уязвимость найдена. Какую пользу с точки зрения защищенности даёт знание уязвимости проектирования или кодирования стандартного программного обеспечения? Самостоятельно нельзя исправить эту уязвимость, можно только сообщить её вендору и ждать выпуска, соответствующего патча. Это так называемые «уязвимости нулевого дня». До момента выхода патчей, для защиты стандартного программного обеспечения от известных уязвимостей, нет никакого надежного способа. Есть только некоторые наложенные способы, которые связаны с конфигурированием средств защиты. Например, системы обнаружения атак. Кроме того, непонятно, почему организация должна платить за поиск уязвимостей в чужих продуктах (речь идет о коммерческих продуктах), если на продаже этих продуктов их производитель зарабатывает деньги. Иначе получается, что организация-заказчик помогает чужому бизнесу.
Таким образом, для стандартного программного обеспечения необходимо искать уязвимости конфигурирования и эксплуатации – именно их имеет смысл проверять, в случае, если организация владеет таким стандартным программным обеспечением. Действительно, правильная и безопасная настройка операционной системы, web-сервера, системы управления базами данных – это задача администратора, с которой он может справиться хорошо или плохо. И от этого напрямую зависит защищенность системы.
Под уязвимостями эксплуатации понимается корректность выполнения требований по эксплуатации. Обычно каждый вендор для своего программного обеспечения разрабатывает инструкцию по эксплуатации и администрированию. В таких инструкциях чаще всего содержатся советы по безопасному администрированию. Например, рекомендации:
-
по выполнению принципа наименьших привилегий при создании учетных записей новых пользователей;
-
о необходимости удаления учетной запись пользователя при увольнении соответствующего сотрудника;
-
о необходимости постоянного отслеживания выхода обновлений и их установки.
Т.е. на этапе эксплуатации отсутствие установленных патчей – это уязвимость уровня эксплуатации.
Поиск недостатков заказного и собственного ПО
Совершенно по-другому обстоят дела с заказным и собственным программным обеспечением. Так как такое ПО разработано «штучно» (для конкретной организации) – вендор не выпустит для него патчей, так как не узнает о наличии ошибки или уязвимости в этом продукте, если сам Заказчик разработки об этом не расскажет о ней вендору или своим собственным программистам, например, заказав услугу по анализу защищенности. Именно поэтому для того, чтобы обеспечить защищенность прикладного программного обеспечения, разработанного на заказ или своими силами, необходимо искать недостатки и уязвимости не только этапа конфигурирования и эксплуатации, но и этапа проектирования, а также разработки и кодирования.
Инструментальный анализ нестандартного ПО
Необходимо отметить то, что вне зависимости, имеющееся у Вас прикладное программное обеспечение заказное или собственное, оно решает специфические задачи. Для поиска недостатков в нем не так хорошо подходят сканеры общего назначения.
Большинство сканеров предназначено для поиска уязвимостей в стандартном программном обеспечении. Они ищут типичные уязвимости конфигурации и типичные уязвимости эксплуатации, а именно отсутствие обновлений.
Для стандартного программного обеспечения такие проверки для сканера можно написать. Например, можно взять web-сервер, Apache, провести анализ его параметров конфигурации и сформулировать правила корректных (т.е. безопасных) параметров конфигурации, а также небезопасных параметров конфигурации. После чего можно создать соответствующую сигнатуру для сканера. Аналогично можно вести базу выхода всех патчей и, устанавливая уровень обновлений в целевом сервисе, делать заключение, установлен последний патч или нет. Таким образом инструментальный анализ уязвимостей конфигурации уязвимостей эксплуатации возможен для стандартного ПО – для ПО, о котором знают производители соответствующих сканеров.
Однако аналогичные инструментальные проверки невозможно сделать для собственного или заказного программного обеспечения. Так как производители сканеров наверняка не знают о Вашем собственном или заказном программном обеспечении.
Таким образом, проблема инструментального анализа собственных прикладных приложений занимает особое место.
Логические недостатки
В силу уникальности процессов каждой конкретной организации, которые автоматизируются заказным или собственным ПО, и о которых другие организации (или даже свои собственные разработчики) имеют весьма смутное представление, необходимо вести речь не только о технических типичных недостатках, которые возникают при разработке приложений, а также о логических недостатках, которые позволяют вывести данное приложение из стандартного русла.
Резюме
Резюмируя вышесказанное, отметим, что для стандартного программного обеспечения необходимо искать, устранять и обеспечивать защищенность от недостатков этапов внедрения, конфигурирования и этапа эксплуатации.
Рисунок 2. Рациональный подход к поиску недостатков.
А для собственного или заказного программного обеспечения имеет смысл искать и устранять уязвимости проектирования, кодирования, внедрения, конфигурирования и эксплуатации.
Как искать уязвимости
Поиск уязвимостей в стандартном ПО
Для стандартного программного обеспечения проблема поиска уязвимостей конфигурирования и эксплуатации решена, имеется множество решений. Они называются сканерами безопасности. В том числе эта же проблема решена методически, для каждого стандартного программного обеспечения имеется множество разнообразных документов, которые описывают, как необходимо конфигурировать и эксплуатировать данное стандартное программное обеспечение, и как его эксплуатировать нельзя.
Т.е. имея в штате администратора, которому можно поставить задачу по безопасной конфигурации стандартного программного обеспечения, и проверяя его работу используя сканер безопасности (неважно как он работает в режиме черного ящика или в режиме белого ящика), можно решить задачу наличия уязвимостей в стандартном программном обеспечении.
Поиск уязвимостей в прикладном ПО
Перейдем к прикладному программному обеспечению (т.е. к заказному и собственному ПО). Выше мы говорили о том, почему для поиска недостатков в прикладном программном обеспечение, как разработанном на заказ, так и собственном, не так хорошо подходят сканеры общего назначения. В первую очередь потому, что производители программного обеспечения, производители стандартных сканеров, ничего не знают о Вашем программном обеспечении, не знают версионности, не знают, как правильно конфигурировать Ваше программное обеспечение. Один из основных моментов – они также не умеют искать эти уязвимости этапа кодирования.
Для поиска уязвимостей этапа кодирования в собственном программном обеспечении, а чаще всего это собственное программное обеспечение представляет из себя web-приложения, придуманы статические анализаторы кода и анализаторы кода, которые работают в режиме черного ящика (по-английски – web application scanner). Тем не менее, в отличие от своих собратьев, которые устанавливают уязвимости конфигурирования и эксплуатации для стандартного программного обеспечения и делают это достаточно хорошо, сканеры собственного кода прикладного программного обеспечения работают не так хорошо. В силу, во-первых, большого многообразия технологий, которые используются при реализации собственного прикладного программного обеспечения, а во-вторых, в силу того, что большинство собственного прикладного программного обеспечения решает конкретные задачи (т.е. business specific), для которых общие проверки заранее предусмотреть очень тяжело.
Таким образом, давайте сформулируем и рассмотрим задачу поиска уязвимостей этапов проектирования, а также разработки и кодирования для прикладного ПО (заказного и собственного).
Для собственного ПО
Рассмотрим вначале задачу борьбы с уязвимостями этапов проектирования, а также разработки и кодирования для собственного ПО.
В целом, эта задача неплохо решена уже с методической точки зрения. Компанией Microsoft был придуман особый цикл разработки, который называется Secure Software Development Lifecycle (SDLC), в котором описаны необходимые шаги и мероприятия, позволяющие управляемо контролировать защищенность конечных программных продуктов. Такая разработка становится более дорогой, нежели обычная разработка, которая в основном учитывает только функциональные требования. Тем не менее, на выходе во втором случае получается более качественный продукт и считается, что итоговая стоимость владения программным продуктом в случае применения SDLC меньше за счет снижения средств на поддержку и исправление ошибок в дальнейшем по сравнению со стандартной разработкой, в которой упор делается только на функциональные программные возможности.
Кроме того компания сама обладает экспертизой по разработке и тестированию кода, это значит, что в целом разработчикам достаточно объяснить, как правильно делать, и как неправильно делать. Можно ожидать, что процесс будет в дальнейшем сходиться к нужному результату с точки зрения снижения недостатков этапов проектирования, а также разработки и кодирования.
Для заказного ПО
Намного больше проблем возникает в задаче борьбы с уязвимостями этапов проектирования и кодирования при заказе программного обеспечения. Источник всех проблем – это отсутствие экспертизы у Заказчика. Действительно, если бы у Заказчика была достаточная экспертиза в целом по программированию, по разработке, тестированию и приемке программного обеспечения, можно было бы либо своими силами разработать соответствующий программный продукт, либо же предъявить на этапе разработки достаточно серьезные требования к опасности итогового продукта. В силу того, что такой экспертизы нет, программное обеспечение заказывается так, что в техническом задании присутствуют в основном функциональные требования и принимается программное обеспечение методом проверки этих же самых функциональных требований. То есть если программное обеспечение выполняет все функции, которые от него ожидаются, значит такое программное обеспечение устраивает Заказчика.
Можно представить такой вариант, что Заказчик программного обеспечения при заказе берет классические требования к информационной безопасности и прописывает их в техническом задании. Это может быть сформулировано на достаточно высоком уровне. Например, отсутствие уязвимостей авторизации, отсутствие уязвимостей аутентификации, отсутствие уязвимостей, связанных с некорректной обработкой входных данных и т.д. На первый взгляд, это может решить проблему, но только на первый взгляд. Дело в том, что проверить выполнимость этих требований при отсутствии экспертизы на этапе сдачи программного обеспечения не реально. Именно поэтому задача борьбы с уязвимостями этапов проектирования и кодирования в заказном программном обеспечении по факту обычно возникает намного позже приемки. Другими словами, владелец заказного программного обеспечения, которое не было разработано с применением тактики защитного кодирования чаще всего подвергается какой-то атаке, и уже по факту возникновения инцидента появляется задача проверки.
Таким образом, из-за отсутствия экспертизы у Заказчика в отношении правильного цикла разработки программного обеспечения, единственно возможным выходом является привлечение внешней экспертизы. Либо постфактум, либо для новых приложений после того, как какие-то ошибки уже были совершены на этапе заказа и на этапе приемки программного обеспечения.
Резюме
Как же методически правильно бороться с различными классами недостатков в программном обеспечении различного рода?
В стандартном программном обеспечении имеет смысл бороться с уязвимостями внедрения и конфигурирования, а также эксплуатации. С этим успешно справляются стандартные сканеры стандартного же программного обеспечения.
В собственном прикладном программном обеспечении в случае, если программное обеспечение разрабатывается самостоятельно, имеет смысл бороться с этими уязвимостями на этапе разработки и кодирования, внедряя так называемые SDLC. Если же это не целесообразно делать, то, как минимум, необходимо добавлять требования на этапе заказа программного обеспечения, постановки задачи программистам и проверять эти требования на этапе тестирования безопасности продукта.
Как бы то ни было, обучение собственных разработчиков антипаторному программированию, то есть тому, что не нужно делать – это задача достаточно понятно решаемая.
В случае приобретения заказного программного обеспечения без внешней экспертизы никак не обойтись. Другими словами, единственным вариантом у владельца заказного программного обеспечения является привлечение внешних экспертов для проверки безопасности их программных продуктов. После случая, если это внимание у Заказчика заказных программных продуктов появляется на этапе заказа программного продукта, то имеет смысл привлекать некоторую третью стороннюю организацию, которая обладает экспертизой, и на этапе формирования требований, на этапе утверждения технического проекта заказного программного обеспечения, и на этапе приемки этого программного обеспечения. Так чтобы анализ защищенности программного обеспечения не отстоял от этапа разработки во времени на какой-то длительный срок.
Какие услуги когда заказывать?
Все заказчики и потребители сервиса информационной безопасности характеризуются различным уровнем зрелости в вопросах информационной безопасности.
Рассмотрим уровни зрелости ИБ – будем двигаться от менее зрелого уровня к более зрелому. Какие же услуги и на каком этапе имеет смысл и экономически эффективно заказывать? А какие не целесообразно потому что они будут слишком дороги или не дадут положительного эффекта, который они могли бы дать в случае, если бы в самой компании процессы обеспечения ИБ уже были бы выстроены на должном уровне.
Начальный уровень зрелости ИБ
Вначале рассмотрим вариант, когда некоторая организация понимает, что недостаточно времени уделяет вопросам обеспечения ИБ. Есть осознание, что существует ряд угроз, относительно которых неизвестно защищена организация или нет. Т.е. появляется необходимость выяснить, что же у неё в информационной безопасности есть, и какие базовые рекомендации ей необходимо выполнить в рамках следующей стратегии:
За минимальные деньги максимально повысить начальный уровень защищенности.
При этом, как и в любой новой области очевидно желание решать задачу не сразу целиком, а поступательно. Так, чтобы можно было управлять каждым этапом. И в зависимости от результатов каждого предыдущего этапа, планировать последующий.
Учитывая то, что самый дешевый способ из существующих проверить недостатки информационных систем организации – это проведение сканирования инструментальными средствами, то именно это и является для всех организаций рекомендуемым первым этапом.
Наше решение: Проведение инструментального сканирования
Автоматизированные средства позволяют, используя минимальное количество ресурсов, выявить самые серьезные недостатки. Также на основе результатов сканирования можно оценить насколько плотно эти недостатки содержатся в информационной системе. В дальнейшем необходимо планировать сроки и объем инвестирования в область информационной безопасности.
Например, если в большинстве веб приложениях сканер нашел несколько критичных уязвимостей, которые позволяют полностью захватить веб сервер, это показатель того, что надо срочно что-то делать. В случае, если сканеры не нашли критичных уязвимостей или нашли только в небольшом проценте тестируемых систем – это значит, что срочных оперативных мер принимать не надо, а можно планировать тактические меры.
Однако необходимо помнить про ограничения инструментального сканирования. Ссылка на Инструментальный анализ нестандартного ПО
Средний уровень зрелости ИБ
После проведения сканирования и выявления самых серьезных недостатков, а также их плотности нахождения в информационной системе, перед организацией появляется задача выявить очевидные проблемы, собрать "low hanging fruits", которые с наибольшей вероятностью найдёт потенциальный злоумышленник в первые дни своей работы.
Т.е. необходимо выяснить какие основные процессы ИБ не выполнялись или выполнялись недостаточно качественно – так что организация и её ресурсы пришли в текущее состояние.
Наше решение: оценка уровня защищенности
Оценка уровня защищенности выполняется на основе инструментального сканирования всех ресурсов и ручной проверки только части ресурсов на предмет наличия критичных уязвимостей, которые не могут установить инструментальные средства в силу своих ограничений. Перечень ресурсов, необходимых для обеспечения репрезентативности выборки, определяется нами на основе нашего опыта.
На основе найденных недостатков на выборке ресурсов Заказчика дается оценка и прогноз общему уровню защищенности всей IT-инфраструктуры Заказчика. Проводится своего уровня экстраполяция на защищенность в том числе от внутренних угроз, от инсайдеров и делаются замечания и рекомендации по поводу корректировки процессов обеспечения ИБ.
Например, одним из вариантов рекомендаций в таком аналитическом отчете может быть что, в организации не достаточно эффективно реализован патч менеджмент. Или, например, системы не безопасно администрируются потому, что у администратора один и тот же пароль на различных критичных сервисах, что позволило взломав один, получить контроль и над всеми остальными.
Исходя из стратегии (за минимальные деньги максимально повысить начальный уровень защищенности), при проведении проекта по оценке уровня защищенности даются не все возможные рекомендации по обеспечению информационной безопасности, которые реализовать было бы слишком дорого для клиента, а только базовые, которые позволят эффективно и быстро повысить уровень защищенности.
Основные отличия инструментального сканирования от оценки помимо того, что в случае оценки ищутся недостатки, которые не могут быть обнаружены сканерами – это аналитика, которая предоставляется заказчику по результатам работы.
В случае сканирования аналитики нет – это отчет сканера. В случае оценки на основе проведенных проверок делается оценка итогового уровня ИБ.
Высокий уровень зрелости ИБ
После того как организация получает рекомендации по повышению уровня ИБ и реализует их, у нее возникает ряд вопросов. А что же теперь? Были ли основные рекомендации, данные на предыдущем этапе, выполнены в полном объеме? И какие есть дополнительные рекомендации, которые еще больше повысят уровень защищенности организации.
Таким образом, следующий этап – проверить, что рекомендации были реализованы в полном объеме и получить следующую порцию рекомендаций, которые позволят опять же за минимальные средства еще больше повысить уровень обеспечения ИБ.
Далее имеет смысл обращаться к услуге «анализ защищенности».
Наше решение: анализ защищенности
В отличие от оценки защищенности, анализ защищенности ориентирован на полноту обследования всех ресурсов и помимо инструментального исследования в нем проводится полноценное, а не выборочное ручное исследование всех ресурсов. По итогам проводится полный анализ угроз и возможных последствий от их реализации. Делается заключение о том, насколько эффективно были реализованы предыдущие рекомендации и предлагается ряд дополнительных мер, которые позволят еще больше повысить защищенность.
Все процессы построены. Что дальше?
Далее организация реализует полученные рекомендации. Внутренняя служба обеспечения ИБ представляет карту рисков своей организации, регулярно производит мониторинг угроз и реагирует на возможные инциденты. В целом все рекомендованные процессы реализованы. У организации возникает вопрос: а не деградируют ли выстроенные процессы со временем?
Например, через месяц после проведения предыдущих консультационных работ по анализу защищённости все рекомендации были реализованы. Возникает вопрос: что будет через 3 месяца, через 4, через 6? Не вернется ли организация в предыдущее незащищенное состояние? Не деградирует ли состояние защищенности, качество и эффективность процессов обеспечения ИБ?
Для ответа на эти вопросы этого требуется внешняя проверка. Внешняя – чтобы исключить конфликт интересов, потому что внутренняя безопасность не может рапортовать о снижении защищенности, т.к. она за нее же и отвечает.
В таком случае заказчики прибегают к услуге по тестированию на проникновение.
Наше решение: тестирование на проникновение
Тестирования на проникновение проводится для того, чтобы проанализировать эффективность защитных мер организации (как процессов, так и конкретных технических решений, которые интегрированы в информационную систему организации).
Цель тестирования на проникновение – достижение поставленной Заказчиком задачи. К таким целям относятся: проникновение во внутреннюю сеть, получение доступа к корпоративной переписке, захват сервера, реализующего какой-либо сервис, например, по проведению платежей и т.д. Проект заканчивается как только поставленная задача будет достигнута.
В случае если тестирование на проникновение увенчается успехом (т.е. достижением поставленной задачи), это означает, что какие-то процессы, которые позволили этому тесту быть успешным, не реализованы или реализованы недостаточно эффективно. Таким образом, тест на проникновение – это критерий эффективности работы службы обеспечения информационной безопасности и рассматривается именно так.
В отличие от анализа защищенности, в ходе тестирования на проникновение вопрос полноты обнаруженных уязвимостей не стоит.
