Library
|
Your profile |
Cybernetics and programming
Reference:
Mironov S.V., Kulikov G.V.
Technologies of security control for automated systems on the basis of structural and behavioral software testing
// Cybernetics and programming.
2015. № 5.
P. 158-172.
DOI: 10.7256/2306-4196.2015.5.16934 URL: https://en.nbpublish.com/library_read_article.php?id=16934
Technologies of security control for automated systems on the basis of structural and behavioral software testing
DOI: 10.7256/2306-4196.2015.5.16934Received: 08-11-2015Published: 27-11-2015Abstract: The subjects of the study are the basic methods and principles of testing software systems used in the interest of the safety evaluation and control of automated systems. The study provides recommendations on the methods of software testing for the most common threats to security subsystems such as firewall, audit; access control; integrity monitoring; password and encryption. The authors considered the possibility that the product could contain the following vulnerabilities: buffer overflow, incorrect handling of format means, race problems. The research methods include the methods of the theory of programming, theory of reliability, software engineering, error-correcting coding, information security, system analysis. The main conclusion of the study is that software testing is a powerful tool to detect both errors in the software and security vulnerabilities. Modern methods of behavioral testing allow to identify vulnerabilities without software source code and can be used successfully in the Russian market, where accessing the source code for testing purposes is almost impossible. Keywords: structural testing, software engineering, program testing method, Security Subsystem, software vulnerabilities, behavioral testing, testing programs, information security, safety of the automated system, threat security programsВведение Увеличение сложности корпоративных автоматизированных систем, выявление новых способов реализации уязвимостей и стремительное развитие технологий, используемых нарушителями, определяет на сегодня одну из важнейших задач по защите информации – разработку и внедрение комплексного подхода к оценке и контролю безопасности автоматизированных систем [1-3]. Наиболее распространенными способами оценки и контроля безопасности автоматизированных систем являются: сертификация; аттестация; аудит; тестирование [4-6]. Несмотря на большие потенциальные возможности по выявлению угроз безопасности тестирование не получило широкого распространения в России из-за нескольких предпосылок: 1) Несовершенство нормативной базы:
2) Высокая стоимость и трудоемкость проведения тестирования программного обеспечения; 3) Малое количество отечественных компаний, выполняющих независимое тестирование. В статье рассмотрены основные методы и принципы тестирования программных комплексов. Кроме этого будет приведена информация по способам выявления методами тестирования наиболее распространенных угроз безопасности. Причины использования средств тестирования программного обеспечения Тестирование программ можно рассматривать как в качестве самостоятельного подхода к анализу безопасности, так и использование его методов как в рамках сертификации, аттестации или аудита систем [7, 8]. Существует ряд причин, когда необходимо использовать тестирование программного обеспечения: 1) предоставление разработчикам информации, необходимой для минимизации ошибок; 2) выявление ошибок в разработанном программном обеспечении; 3) оценка безопасности программного обеспечения; 4) предоставление необходимой информации для разработчика, по созданию проекта, который будет легко в дальнейшем тестировать; 5) попытка взлома программного обеспечения или проверка на уязвимости; 6) проверка соответствия программного продукта, заявленной документации. Стратегии тестирования программного обеспечения Существуют две основные стратегии тестирования программного обеспечения: стратегия поведенческого тестирования (которая также называется тестированием черного ящика или функциональным тестированием) и структурное тестирование (тестирование белого ящика). Также применяется гибридная стратегия поведения, которая является комбинацией вышесказанных стратегий. Для проведения структурного тестирования необходимо наличие исходных текстов программ. Структурное тестирование предполагает составление программы тестирования на основании знаний о структуре и конфигурации объекта испытаний. Этот метод описан в стандарте ANSI/IEEE Std 1008-1987. Такой вид тестирования наиболее эффективен для выявления программных ошибок, однако, в тоже время, является самым трудоемким. Он используется в случае анализа модулей небольшого объема или отдельно взятых фрагментов кода, например, связанных с безопасностью изделия [9]. Метод структурного тестирования применяется в ходе проведения сертификационных испытаний программного обеспечения [10, 11]. Существуют инструментальные средства проведения структурного тестирования программного обеспечения, но, они, как правило, заточены на выполнение узких задач, например, выявление утечек памяти, определение участков кода, некорректно обрабатывающих массивы и переменные, а также средства анализа связности фрагментов кода и др. [10, 12] В настоящее время распространена ситуация, когда разработчики не хотят предоставлять исходные тексты своих изделий, но в тоже время, хотят его протестировать. В данной ситуации возможно проведение только поведенческого тестирования. Потому остановимся на этом методе поподробнее. Методы тестирования Все методы тестирования можно разделить на две большие группы: это функциональные тесты и тесты на безопасность, надежность и производительность. Функциональное тестирование имеет важное значение для разработчиков, т.к. это оно непосредственно влияет на качество программной продукции. Данное тестирование заключается в проверке соответствия функций изделия какой-либо документации, представленной разработчиком. В рамках функциональных проверок тестировщик выполняет все заявленные разработчиком возможности изделия. Как правило, этот вид тестирования выполняется с другими видами тестирования, например, нагрузочным или стрессовым тестированием. Названный вид тестирования описан стандартом ISO 09646-1-6:1991, регламентирующим проверку функциональных возможностей и поведения продукции относительно требований и рекомендаций ISO, а также заявлений и документации разработчиков о функциональных возможностей изделия. Этот вид тестирования обычно проводится самим разработчиком [13-16]. Тестирование на надежность и производительность заключается в создании стрессовых ситуаций для изделия и попыток заставить работать изделие в нештатном режиме. Например, для изделия, обрабатывающего поток поступающих транзакций, создать ситуацию, при которой в единицу времени на него будут поступать тысячи транзакций, либо понижать пропускную способность сети и многое другое [17, 18]. Тестирование на безопасность При проведении тестировании на безопасность изделия необходимо выделить все подсистемы безопасности изделия и проверить реализацию существующих уязвимостей. К числу подсистем безопасности, требующих тестирования, как правило, относят следующие подсистемы: межсетевого экранирования; аудита; контроля доступа; контроля целостности; парольную; криптографическую. Считаем, что в изделии могут присутствовать следующие уязвимости: переполнение буфера, некорректная обработка форматных средств, гонки (эти уязвимости являются наиболее распространенными [17-26]). Соответствие указанных подсистем безопасности и методов тестирования представлено в таблице 1. Таблица 1 - Соответствие подсистем безопасности и методов тестирования
Аутсорсинговое тестирование Еще одним распространенным методом тестирования является «аутсорсинг». Этот вид подразумевает тестирование продукта независимыми компаниями: за рубежом созданы специальные тестовые агентства, наиболее часто применяющие тестирование безопасности, надежности и производительности. Использование тестирования для выявления ошибок 1) Переполнение буфера Переполнение буфера возникает из-за того, что данные и информация о потоке выполнения программы перемешаны, а также в низкоуровневых языках программирования разрешен прямой доступ к памяти. Пример возникновения переполнения буфера – запись программой данных в память, не принадлежащую выделенному буферу. Результатами переполнения буфера может быть как крах программы, так получение противником контроля над положением или выполнение других программ с правами пользователя, запустившего программу. Классический пример реализации переполнения буфера на языке С++: #include <stdio.h> void func1() { char buf[256]; gets(buf); …. } Способы структурного тестирования: Обнаружить места переполнения буфера можно как легко, так и очень сложно. Прежде всего, необходимо с использованием метода сигнатурного тестирования выявить все участки программы, где используются функции по работе со строками. Затем проанализировать все возможные параметры, а также размеры используемых строк и их проверку. Кроме этого, необходимо отследить все вводимые пользователями данные как напрямую, так и через конфигурационные файлы и базы данных, начиная с точки ввода в программу и далее по всем функциям. Кроме этого можно использовать средства обнаружения ошибок при работе с памятью Способы поведенческого тестирования: Наиболее эффективным методом является рандомизированное тестирование, которое заключается в передачи анализируемому объекту полуслучайных данных произвольного объема и отслеживания работы программы при обработки этих данных. В ходе исследования во все места запроса от пользователей данные вводятся полуслучайные данные произвольного размера. Это может быть, ввод имени пользователя, либо имени файлов. Файлы настроек приложения, доступные для пользователей, либо записи из баз данных. Кроме этого можно использовать средства обнаружения ошибок при работе с памятью и применять существующие эксплойты. Сравнение эффективности структурного и поведенческого тестирования: Поведенческое тестирование для выявления данной ошибки просто реализуемо и в более короткие сроки уязвимости могут быть выявлены. Однако нет 100% вероятности выявления как в случае структурного тестирования. 2) Ошибки, связанные с форматной строкой Такая ошибка является разновидностью переполнения буфера и заключается в отсутствии контроля вводимых от пользователя параметров. Результатами могут быть: запись по произвольному адресу в памяти, обход защиты стека, исполнение произвольного кода и раскрытие информации. Пример реализации ошибки: Файл test.cpp #include <stdio.h> int main (int argc, char* argv[]) { FILE *in; if(argc > 1) { if ((in = fopen(argv[1], "rt")) == NULL) { printf("Cannot open input file %s.n", argv[1]); return 1; } } } Вызов файла: C:test.exe bad_file%x%x.txt В результате на экране выедено: Cannot open file bad_file234a078eab0. Где, 234a07, 8eab0 – адреса из стека. Способы структурного тестирования: Данная ошибка очень легко выявляется на этапе анализа кода, достаточно отследить все операции с операндами командой строки на предмет выявления процедур проверок. Способы поведенческого тестирования: Наиболее эффективным методом также является рандомизированное тестирование. В ходе исследования при вызове программы в качестве параметров вызова передаются специальным образом сконфигурированные данные. Эти данные включают спецификаторы формата данных, длинные пути, применение существующих эксплойтов. Сравнение эффективности структурного и поведенческого тестирования: Ошибки, связанные с форматной строкой легко выявляются при использовании обоих методов. 3) Переполнение целых чисел Переполнение возникает из-за того, что существуют операции, при выполнении которых компьютер дает не тот же результат, что на бумаге. К данным операциям чаще всего относят операции приведения типов как явных так и неявным приведением. Результат: Переполнение целых чисел чаще всего вызывает переполнение буфера с последующим выполнением кода. Пример реализации: #include <stdio.h> int main (int argc, char* argv[]) { const long MAX_INPUT = 0x7fff; short len; if(argc > 1) { len = strlen(argv[1]); if(len < MAX_INPUT) { //основной функционал } else { return 0; } } } Комментарий: В случае, если в качестве аргумента будет введена строка, длина которой больше 32К, то переменная len станет отрицательной, поэтому будет выполнен «основной функционал» с неверными входными данными.
Способы структурного тестирования: Такая ошибка очень трудно выявляется на этапе анализа кода, необходимо отследить все операции с переменными, арифметические операции и приведения типов. Способы поведенческого тестирования: Такая ошибка также очень трудно выявляется. Можно использовать только рандомизированное тестирование. В ходе исследования при вызове программы в качестве параметров передаются строки символов, чтобы вызвать ошибку. Часто ошибки возникают, если длина строк составляет,: 127,128, 255, 32К, 64К-1, 64К. Применение существующих эксплойтов.
Сравнение эффективности структурного и поведенческого тестирования: Ошибки, связанные с переполнением целых чисел сложно выявляются при использовании обоих методов. 4) Внедрение SQL-команд
Ошибка возникает в случае отсутствия проверки параметров, водимых пользователем, при создании SQL-запросов (их конкатенации). В результате реализации уязвимости может быть скомпрометирована машина и осуществлено раскрытие секретных данных. Пример реализации: … gets(ID); CString sSQL = “SELECT money FROM zarpl WHERE id=” + ID; …. Комментарий: пользователь может ввести любое значение идентификатора, либо вместо идентификатора ввести дополнительные операнды SQL-запроса, которые при конкатенации введенной строки со строкой из программы выведут недоступные ранее для пользователя данные.
Способы структурного тестирования: Для выявления ошибки используются метод сигнатурного анализа поиска операций взаимодействия с базой данных. Определяются места формирования запросов и проверки вводимых данных. Способы поведенческого тестирования: Данная ошибка достаточно трудно выявляется. Можно использовать только рандомизированное тестирование. В ходе исследования при вызове программы в качестве параметров формирования запросов передаются частично некорректные данные.
Сравнение эффективности структурного и поведенческого тестирования: Структурное тестирование эффективней поведенческого тестирования за счет наглядности процедур формирования запросов. 5) Гонки Гонки возникают в случае существования двух и более программ, выполняемые в разных контекстах (процессах или потоках). Эти программы могут блокировать друг друга, а также изменять один и тот же объект. В результате реализации этой уязвимости, может быть осуществлено блокирование программы, аварийный останов программы.
Способы структурного тестирования: Метод поиска не эффективен без использования динамического тестирования. Способы поведенческого тестирования: Такая ошибка достаточно трудно выявляется. Можно использовать только тесты на быстрых многопроцессорных машинах. А также выявление коллизий в ходе выполнения программы на высокоскоростных машинах.
Сравнение эффективности структурного и поведенческого тестирования: Структурное и поведенческое тестирование не очень эффективны при выявлении гонок, однако с некоторой вероятностью их можно выявить только при поведенческом тестировании. Заключение Как видно из приведенного анализа: тестирование программного обеспечения является мощным средством для выявления ошибок в работе программ, так и уязвимостей безопасности. За рубежом тестированию уделяется значительное внимание, эффективно функционирует специальная отрасль «Software Testing & Quality Assurance». Современные методы поведенческого тестирования позволяют выявлять уязвимости без исходных текстов программ и могут успешно применяться на российском рынке, для которого передача исходных текстов на тестирование задача почти невыполнимая. References
1. Markov A.S., Mironov S.V., Tsirlov V.L. Vyyavlenie uyazvimostei programmnogo obespecheniya v protsesse sertifikatsii // Informatsionnoe protivodeistvie ugrozam terrorizma. 2006. № 7. S. 177-186.
2. Kotenko I.V., Saenko I.B., Yusupov R.M. Perspektivnye modeli i metody zashchity komp'yuternykh setei // Vestnik Rossiiskoi akademii nauk. 2013. T. 83. № 5. S. 463. 3. Nepomnyashchikh A.V., Kulikov G.V., Sosnin Yu.V., Nashchekin P.A. Metody otsenivaniya zashchishchennosti informatsii v avtomatizirovannykh sistemakh ot nesanktsionirovannogo dostupa // Voprosy zashchity informatsii. 2014. № 1 (104). S. 3-12. 4. Lakutin A. Autsorsing testirovaniya programmnogo obespecheniya. M.: KIS, 2002. 412 s. 5. Men'shikh V.V., Koval'chuk A.A. Otsenki uyazvimosti i opasnosti rasprostraneniya ugroz informatsionnoi bezopasnosti v telekommunikatsionnykh sistemakh // Informatsionnaya bezopasnost' regionov. 2013. № 2 (13). S. 17-22. 6. Maiers G. Iskusstvo testirovaniya programm. M.: Finansy i statistika, 1982. 176 s. 7. Nashchekin P.A., Nepomnyashchikh A.V., Sosnin Yu.V., Kulikov G.V. Kriterii i metody proverki vypolneniya trebovanii po zashchishchennosti avtomatizirovannoi sistemy pri izmenenii nastroek ili vydelennykh resursov sredstv zashchity informatsii // Voprosy zashchity informatsii. 2013. № 4 (102). S. 50-53. 8. Golosovskii M.S. Informatsionno-logicheskaya model' protsessa razrabotki programmnogo obespecheniya // Programmnye sistemy i vychislitel'nye metody. 2015. № 1. S. 59-68. 9. Bogomolov A.V., Chuikov D.S., Zaporozhskii Yu.A. Sredstva obespecheniya bezopasnosti informatsii v sovremennykh avtomatizirovannykh sistemakh // Informatsionnye tekhnologii. 2003. № 1. S. 2. 10. Beizer B. Testirovanie chernogo yashchika. Tekhnologii funktsional'nogo testirovaniya programmnogo obespecheniya sistem. SPb.: Piter, 2004. 318 s. 11. Sosnin Yu.V., Kulikov G.V., Nepomnyashchikh A.V. Kompleks matematicheskikh modelei optimizatsii konfiguratsii sredstv zashchity informatsii ot nesanktsionirovannogo dostupa // Programmnye sistemy i vychislitel'nye metody. 2015. № 1. S. 32-44. 12. Khovard M., Ledblank D., Viega D. 19 smertnykh grekhov, ugrozhayushchikh bezopasnosti programm: Kak nedopustit' tipichnykh oshibok. M.: Izdatel'skii Dom DMK-press, 2006. 288 s. 13. Markov A.S., Mironov S.V., Tsirlov V.L.. Vyyavlenie uyazvimostei v programmnom kode // Otkrytye sistemy, №12, 2005. S.64-69. 14. Nepomnyashchikh A.V., Nepomnyashchikh E.V., Lavrov D.N. Prioritizatsiya trebovanii k programmnomu obespecheniyu v usloviyakh nepreryvnoi integratsii // Prikladnaya informatika. 2012. № 1 (37). S. 20-27. 15. Borodakii Yu.V., Kulikov G.V., Nepomnyashchikh A.V. Metodika otsenivaniya funktsional'nykh vozmozhnostei sistem obnaruzheniya vtorzhenii na osnove ranzhirovaniya stepeni opasnosti atak // Izvestiya YuFU. Tekhnicheskie nauki. 2006. № 7 (62). S. 124-128. 16. Brunilin A.A., Kuvaev V.O., Saenko I.B. Ontologicheskii podkhod k organizatsii informatsionnogo vzaimodeistviya raznorodnykh avtomatizirovannykh sistem spetsial'nogo naznacheniya // T-Comm: Telekommunikatsii i transport. 2015. T. 9. № 2. S. 69-73. 17. Markov A.S., Mironov S.V., Tsirlov V.L. Opyt testirovaniya setevykh skanerov uyazvimostei // Informatsionnoe protivodeistvie ugrozam terrorizma. 2005. № 5. S. 109-122. 18. Rudakov I.S., Rudakov S.V., Bogomolov A.V. Metodika identifikatsii vida zakona raspredeleniya parametrov pri provedeniya kontrolya sostoyaniya slozhnykh sistem // Informatsionno-izmeritel'nye i upravlyayushchie sistemy. 2007. T. 5. № 1. S. 66-72. 19. Grusho A.A., Grusho N.A., Timonina E.E. Iskusstvennaya nedostovernost' informatsii kak sredstvo ee zashchity // Vestnik RGGU. Seriya: Dokumentovedenie i arkhivovedenie. Informatika. Zashchita informatsii i informatsionnaya bezopasnost'. 2011. № 13 (75). S. 123-127. 20. Fedorov M.V., Kalinin K.M., Bogomolov A.V., Stetsyuk A.N. Matematicheskaya model' avtomatizirovannogo kontrolya vypolneniya meropriyatii v organakh voennogo upravleniya // Informatsionno-izmeritel'nye i upravlyayushchie sistemy. 2011. T. 9. № 5. S. 46-54. 21. Men'shikh V.V., Pastushkova E.A. Generatsiya variantov sinteza upravlyayushchikh vozdeistvii dlya prinyatiya reshenii v sistemakh kriticheskogo primeneniya s ispol'zovaniem funktsional'no izbytochnogo nabora deistvii // Sistemy upravleniya i informatsionnye tekhnologii. 2014. T. 57. № 3. S. 15-19. 22. Golosovskii M.S. Modelirovanie zhiznennogo tsikla spetsial'nogo programmnogo obespecheniya // Sbornik trudov II vserossiiskoi nauchno-prakticheskoi konferentsii «Yuzhno-Ural'skaya molodezhnaya shkola po matematicheskomu modelirovaniyu». Chelyabinsk, 2015. S. 55-62. 23. Kozlov V.E., Bogomolov A.V., Rudakov S.V., Olenchenko V.T. Matematicheskoe obespechenie obrabotki reitingovoi informatsii v zadachakh ekspertnogo otsenivaniya // Mir izmerenii. 2012. № 9. S. 42-49. 24. Kukushkin Yu.A., Bogomolov A.V., Ushakov I.B. Matematicheskoe obespechenie otsenivaniya sostoyaniya material'nykh sistem // Informatsionnye tekhnologii. 2004. № 7 (prilozhenie). 32 s. 25. Ermakov A.D. Testirovanie bezopasnosti programmnogo obespecheniya s ispol'zovaniem verifikatorov // Izvestiya vysshikh uchebnykh zavedenii. Fizika. 2013. T. 56. № 9-2. S. 181-183. 26. Azymshin I.M., Chukanov V.O. Analiz bezopasnosti programmnogo obespecheniya // Bezopasnost' informatsionnykh tekhnologii. 2014. № 1. S. 45-47 |