Какие недостатки бывают в ПО

Классификация программного обеспечения

Классификация недостатков программного обеспечения

На поиск каких недостатков стоит тратить время и деньги

Поиск недостатков стандартного ПО

Поиск недостатков заказного и собственного ПО

Инструментальный анализ нестандартного ПО

Логические недостатки

Резюме

Классификация программного обеспечения

  1. По уровню, на котором оно работает:
    • сетевое ПО – обеспечивает работу сети и сетевых устройств (стеки протоколов, операционные системы на маршрутизаторах);
    • системное ПО - предназначено для управления работой вычислительной системы (операционные системы, сервисы уровня операционной системы, СУБД);
    • прикладное ПО -  это комплекс программ для решения специфичных задач, т.е. задач определённого класса конкретной предметной области (web-приложения, десктопные приложения).
  2. По источнику (по производителю):
    • стандартное ПО – характеризуется массовым производством и внедрением, автоматизирует общие для всех потребности в IT-технологиях (операционные системы, web-сервера, прикладные утилиты);
    • заказное ПО – производство под заказ, автоматизация процессов конкретной организации, для которых пока еще нет стандартного ПО (различного рода приложения, т.е. прикладное программное обеспечение);
    • собственное ПО – производится собственными силами, автоматизация собственных процессов для которых пока еще нет стандартного ПО.

При этом возможно, что и заказное и собственное программное обеспечение будет написано не с нуля, от начала и до конца, а на основе какого-то фреймворка или платформы. Например, на базе платформы 1С или на базе платформы SAP, которая уже решает большое количество задач в какой-то предметной области, но не все или не так как этого бы хотел Заказчик.

Совместив две классификации (по уровню и по источнику), можно увидеть тенденцию (см. Рис.1.):

  • стандартное ПО обычно коррелирует с системным и сетевым,
  • собственное и заказное программное обеспечение обычно коррелирует с прикладным программным обеспечением, именно по той причине, по которой было рассказано выше.

Рисунок 1. Тенденция корреляции ПО.

Причина: Стандартные процессы (работа сети и вычислительных систем) автоматизируют стандартным ПО, а специфические процессы конкретной организации  стандартным программным обеспечением не могут быть автоматизированы (разрабатываются под заказ или собственными силами) и по определению являются прикладными.

Классификация недостатков программного обеспечения

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

  • на уровне проектирования;
  • на уровне непосредственной разработки и кодирования;
  • на уровне внедрения и конфигурирования;
  • на уровне эксплуатации этого программного обеспечения.

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

На поиск каких недостатков стоит тратить время и деньги

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

При этом необходимо помнить, что:

  • стандартное программным обеспечением чаще всего является системным, сетевым (исключение - стандартное прикладное программное обеспечение, выполняющее типовые прикладные задачи, например, пакет MS Office);
  • заказное и собственное программное обеспечение будет являться практически всегда прикладным.

Поиск недостатков стандартного ПО

Вначале рассмотрим, почему для типовой организации в рамках проекта по анализу защищенности для стандартного ПО не рационально заказывать поиск уязвимостей проектирования и кодирования. Мы не рассматриваем различного рода огромные компании (например, Google или Microsoft), а также службы безопасности государства (например, ФСБ).

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

Представим, что такая уязвимость найдена. Какую пользу с точки зрения защищенности даёт знание уязвимости проектирования или кодирования стандартного программного обеспечения? Самостоятельно нельзя исправить эту уязвимость, можно только сообщить её вендору и ждать выпуска, соответствующего патча. Это так называемые «уязвимости нулевого дня». До момента выхода патчей, для защиты стандартного программного обеспечения от известных уязвимостей, нет никакого надежного способа. Есть только некоторые наложенные способы, которые связаны с конфигурированием средств защиты. Например, системы обнаружения атак. Кроме того, непонятно, почему организация должна платить за поиск уязвимостей в чужих продуктах (речь идет о коммерческих продуктах), если на продаже этих продуктов их производитель зарабатывает деньги. Иначе получается, что организация-заказчик помогает чужому бизнесу.

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

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

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

Т.е. на этапе эксплуатации отсутствие установленных патчей – это уязвимость уровня эксплуатации.

Поиск недостатков заказного и собственного ПО

Совершенно по-другому обстоят дела с заказным и собственным программным обеспечением. Так как такое ПО разработано «штучно» (для конкретной организации) – вендор не выпустит для него патчей, так как не узнает о наличии ошибки или уязвимости в этом продукте, если сам Заказчик разработки об этом не расскажет о ней вендору или своим собственным программистам, например, заказав услугу по анализу защищенности. Именно поэтому для того, чтобы обеспечить защищенность прикладного программного обеспечения, разработанного на заказ или своими силами, необходимо искать недостатки и уязвимости не только этапа конфигурирования и эксплуатации, но и этапа проектирования, а также разработки и кодирования.

Инструментальный анализ нестандартного ПО

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

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

Для стандартного программного обеспечения такие проверки для сканера можно написать. Например, можно взять web-сервер, Apache, провести анализ его параметров конфигурации и сформулировать правила корректных (т.е. безопасных) параметров конфигурации, а также небезопасных параметров конфигурации. После чего можно создать соответствующую сигнатуру для сканера. Аналогично можно вести базу выхода всех патчей и, устанавливая уровень обновлений в целевом сервисе, делать заключение, установлен последний патч или нет. Таким образом инструментальный анализ уязвимостей конфигурации уязвимостей эксплуатации возможен для стандартного ПО – для ПО, о котором знают производители соответствующих сканеров.

Однако аналогичные инструментальные проверки невозможно сделать для собственного или заказного программного обеспечения. Так как производители сканеров наверняка не знают о Вашем собственном или заказном программном обеспечении.

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

Логические недостатки

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

Резюме

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

Рисунок 2. Рациональный подход к поиску недостатков.

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