Методы безопасной разработки программного обеспечения
Рассматриваются методы безопасной разработки программного обеспечения. Описываются цели и границы применения методов, достоинства и недостатки. В настоящее время существует достаточно большое количество методов безопасной разработки про граммного обеспечения (ПО).
Рассматриваются применяемые при разработке ПО методы, целью которых является повышение качества и безопасности конечного программного продукта. Методы безопасной разработки могут быть выделены в следующие группы, относительно этапов и процессов разработки ПО, в которых они применяются: методы, применяемые в процессе управления разработкой ПО; методы, применяемые при анализе и формировании требований и составлении спецификаций, а так же в процессе проектирования; методы, применяемые в процессе реализации; методы, применяемые в процессе тестирования, вводе в эксплуатацию и поддержке разработанного ПО. Методы безопасной разработки ПО различаются по следующим критериям: границы применения, цели использования в процессе разработки ПО. Решение об использовании при создании ПО того или иного метода безопасной разработки зачастую принимаются на основе указанных критериев. Поэтому целью данной работы является так же анализ различных методов с точки зрения их эффективности и границ применения. К числу методов, применяемых в процессе управления разработкой ПО относятся: метод “команды безопасности”, проведение обзорных анализов безопасности, метод “стерильной комнаты”, модель улучшения процессов CMMI, метод структурной корректности. Метод “команды безопасности” заключается в выделении в структуре организации группы либо отдела, называемых командой безопасности, которая отвечает за развитие и совершенствование процессов разработки с точки зрения информационной безопасности, выступает в роли эксперта по вопросам информационной безопасности для всей организации в целом и для каждого из проектов в частности.
Отдел безопасности организации назначает соответствующего работника либо группу работников на роль инженера по безопасности для конкретной разработки. Инженер по безопасности помогает команде разработчиков продукта, производя анализ всех действий разработчиков, документов, составленных в процессе разработки, таких как перечень требований безопасности и проектной документации и делает рекомендации на основе произведенного анализа. Таким образом, инженер по безопасности отвечает за контроль методологии разработки и за безопасность всего разрабатываемого продукта в целом. Относительно данного метода следует отметить, что применение подобного подхода не является гарантией безопасности разрабатываемого ПО, отсутствия в нем уязвимостей. Однако применение подобного подхода способно снизить общее количество уязвимостей в созданных программных системах, в том числе критичных с точки зрения ИБ и в целом повысить его безопасность. Метод проведения обзорных анализов безопасности заключается в систематической проверке и анализе самими разработчиками программного кода (либо проектной документации), разработанных на предыдущих стадиях жизненного цикла проекта. Такие обзорные анализы помогают найти и устранить ошибки в разрабатываемом ПО, кроме того, при этом самими разработчиками данным проблемам уделяется особое внимание, что зачастую означает, что на следующих стадиях разработки подобные ошибки не будут допущены. В ходе подобных анализов пополняется база известных ошибок.
Существует две категории обзорных анализов: формальный анализ, в ходе которого систематически и в высшей степени подробно изучается все проектная документация либо программный код. При этом достаточно часто происходят общие собрания разработчиков, на которых обсуждаются те или иные решения, примененные при разработке проекта. В отличие от формального анализа, другие методики предполагают применение парной разработки, использование автоматизированных средств анализа, а также выделение среди разработчиков роли инженера по безопасности, ответственного за анализ всего проекта.
Существуют так же итоговые обзорные анализы безопасности, проводимые экспертами по информационной безопасности (внешними либо внутренними). Сведения, полученные в результате проведения подобного обзорного анализа могут применяться для повышения эффективности применения методик обеспечения безопасности, а так же являться основанием для пересмотра отдельных этапов или всего процесса разработки ПО, практикуемого в организации. Разработка программного обеспечения методом «стерильной комнаты» представляет собой теоретически обоснованный, ориентированный на командную разработку процесс создания, верификации и сертификации корректных программных систем со статистическим контролем качества. Метод “стерильной комнаты” охватывает весь жизненный цикл разработки, включая управление проектом, определение спецификаций функций и архитектуры, проверку правильности функционала, а также статистическое тестирование при сертификации программ. Основная идея данного метода – предотвращение ошибок и дефектов в программных средствах предпочтительней, нежели их устранение. Основные принципы метода таковы: инкрементная разработка на основе статистического контроля качества; использование принципа структурной разработки представлений; тестирование на основе методов статистики; итеративная разработка; перераспределение времени между этапами жизненного цикла; разработка ПО должна базироваться на формальных методах. К преимуществам метода “стерильной комнаты” можно отнести: широкие возможности для верификации программных систем за счет использования формальных спецификаций, метод подразумевает подробное формальное описание всех возможных сценариев выполнения разрабатываемых программ, что значительно снижает вероятность некорректной работы программ, а также значительно уменьшает вероятность возникновения ошибок в спецификации и требованиях к ПО. Метод обеспечивает прозрачность, а значит и более полные возможности контроля и верификации формальных спецификаций, сформированных на основе требований к ПО. Метод позволяет обнаруживать и устранять ошибки и уязвимости на ранних стадиях разработки (начиная со стадии формирования спецификаций) и, таким образом предотвращает появление подобных критических ошибок на стадии проектирования и реализации. Из недостатков следует выделить, что метод фокусирует основное внимание на корректной разработке отдельных компонентов системы (что является очень эффективно при разработке отдельных компонентов), но в то же время не предоставляет достаточно эффективных инструментов для анализа и верификации системы в целом. Метод “стерильной комнаты” не предоставляет средств для анализа поведения системы в динамике (в процессе работы системы), требует достаточно сложных вспомогательных автоматизированных средств для верификации различных, представлений системы и их соответствия, а так же соответствия спецификаций, проектной документации и программного кода. Метод структурной корректности, включает в себя определение формальных нотаций для спецификаций систем и компонентов архитектуры с учетом их согласованности и корректности. Он позволяет с помощью формальных методов проверять программное обеспечение и своевременно устранять в нем дефекты на протяжении его жизненного цикла.
Данный способ включает в себя определение формальных нотаций для спецификаций систем и компонентов архитектуры с учетом их согласованности и корректности. Для безопасных систем выделяются категории состояний системы и операций, которые определяются с учетом их влияния на общую безопасность. Конечной целью является создание архитектуры, которая позволяет свести к минимуму число функций, критически важных для обеспечения защиты, и изолировать их. Это способствует дальнейшему снижению стоимости и сокращению объема работы (возможно, значительно более трудоемкой), связанной с проверкой правильности данных элементов. Модель улучшения процессов CMMI используется для общей оценки эффективности работы организации (в зависимости от определенных в модели критериев) и поиска путей ее повышения. Модель CMMI содержит основные направления развития процессов разработки в организации, наборы практик и методов разработки, адаптация и оптимизации которых с учетом специфики конкретной организации является достаточно эффективным инструментом для совершенствования всего процесса разработки. Методами применяемыми при анализе и формировании требований и составлении спецификаций, а так же в процессе проектирования являются Z-нотация, В-метод (нотация), UMLSec, оценка рисков и моделирование угроз. Z-нотация представляет собой язык формального описания, используемый для проектирования и моделирования вычислительных систем.
Язык Z является стандартом, утвержденным ISO (ISO/IEC 13568:2002). Z-нотация основана на стандартной математической нотации, используемой в аксиоматической теории множеств, лямбда-исчислении, и логике предикатов первого порядка. За счет сочетания двух видов математических нотаций позволяет составлять формальные описания требований и спецификаций, а также для составления проектов ПО различного уровня детализации и абстракции. В настоящее время язык Z является базисным для ряда других формальных нотаций, включая адаптированные варианты Z для объектно-ориентированных языков программирования. Однако большую роль в эффективности применения Z-нотации играет практический опыт разработчиков. Применение данной нотации значительно повышает время и трудоемкость разработки. B-нотация это формальная нотация, являющийся подвидом Z-нотации. В-метод позволяет создавать четкие, непротиворечивые, логически связанные спецификации, верифицируемые и математически корректные. Формальные спецификации и проектные, полученные в результате применения данного метода, близки к неформальным спецификациям разрабатываемого ПО по уровню детализации и модели представления, что позволяет минимизировать ошибки при переходе от неформальных спецификаций к формальным и далее к проектной документации. По сравнению с Z-нотацией, B-метод является более низкоуровневым методом. Он предназначен для применения на этапе программной реализации и учитывает многие нюансы данного процесса. Преимуществами данного метода является создание формализованных спецификаций и моделей, ориентированных на особенности программной реализации. UMLSec является стандартным расширением языка UML, предназначенным для проектирования и разработки безопасных ИС. Он включает в себя средства для представления функциональных требований и требований безопасности, спецификаций, проектирования. UMLSec представляет возможность визуального моделирования и проектирования различных уровней детализации представлений. UMLSec содержит достаточно большое количество шаблонов моделей и диаграмм, которые позволяют решать типовые задачи обеспечения информационной безопасности в короткие сроки и с высоким уровнем надежности.
В настоящее время имеется большое число программных средств, предназначенных для составления и описания диаграмм UMLSec, а также средства автоматического анализа их корректности. Кроме того, существует программное обеспечение, позволяющее на основе данных диаграмм формировать описания последовательности тестов для разрабатываемого ПО, верификации разрабатываемого ПО, генерации начального программного кода. Разработка ПО с использованием UMLSec менее ресурсоемкая со сравнению с большинством других формальных методов. Однако математические методы формализации не являются основными в UMLSec, что не позволяет полностью исключить непротиворечивость и неточности в спецификациях и проектной документации. Кроме того, следует отметить сложность верификации корректности реализации функциональности программ, проектированных с помощью UMLSec. К методам, применяемым в процессе реализации, относятся метод использования руководств разработчиков и контрольных ведомостей, метод безопасных и формальных языков программирования. Руководства разработчиков и контрольные ведомости являются набором основных принципов, практических советов и рекомендаций, как избежать появления наиболее типичных и распространенных уязвимостей в ПО в процессе написания программного кода. К подобным правилам следует отнести стандарты написания программного кода, действующие в организации, списки запрещенных либо рекомендованных к использованию функций языка программирования, используемого при разработке. Так же в процессе разработки возможно применение контрольных ведомостей (checklist), которые представляют собой списки значимых с точки зрения ИБ при разработке ПО моментов, выполнение которых разработчик в обязательном порядке должен проконтролировать и проверить. Обычно для каждого из этапов разработки существует своя контрольная ведомость.
В ходе разработки ведомости и руководства могут пересматриваться и обновляться для повышения эффективности их использования. Хотя подобные средства не способны гарантировать отсутствие ошибок и предотвратить появление ошибок и уязвимостей, не схожих с уже известными, они способны уменьшить общее количество уязвимостей в разрабатываемом ПО. Метод применения безопасных языков программирования учитывает, что многие часто используемые языки программирования имеют ряд свойств, которые могут оказаться источниками появления уязвимостей. Выбор языка программирования также может оказать существенное влияние на безопасность конечного продукта. Лучшими языками являются те, в которых все действия определены и обоснованы, поддерживаются функции, уменьшающие число ошибок (например, требуется строгое определение типов), осуществляется контроль за распределением памяти и использованием указателей. Одним из возможных вариантов для разработки безопасного ПО является язык программирования Ada95. За счет возможности выполнения проверок корректности реализованных модулей и функций непосредственно в процессе компиляции, расширенной обработки исключений, возможности спецификации типов, а так же общей формализации, повышающей эффективность верификации программного кода, написанного на данном языке, Ada 95 обеспечивает более высокий уровень надежности и безопасности по сравнению с другими языками программирования. К недостаткам данного языка следует отнести общую сложность реализации, сложность в изучении и использовании, значительное увеличение трудоемкости разработки, отсутствие поддержки объектно-ориентированного программирования.
Применение языков, разработанных с учетом различных вопросов безопасности (C#, Java, Ada95) может позволить избежать ряда типичных ошибок и уязвимостей ПО, повысить эффективность верификации программного кода. Методами, применяемыми в процессе тестирования, вводе в эксплуатацию и поддержке разработанного ПО являются применение различных способов тестирования и организация поддержки ПО. Использование в процессе тестирования анализаторов кода, а так же таких методов тестирования как тестирование на устойчивость, тестирование методом Баллиста, модульного тестирования программного кода позволяет эффективно выявлять дефекты системы безопасности, что не только не только сказывается на эффективности исправления ошибок, но и позволяет предотвращать их появление в будущих системах и проектах. Кроме того, аналогичные дефекты можно исключить из других уже разработанных программных продуктов. Знания о ошибках и уязвимостях, полученные в ходе поддержки выпущенного ПО могут быть использованы при применении некоторых методик безопасной разработки ПО для недопущения повторения подобных ошибок. Кроме того, анализ сведений об уязвимостях, выявленных после выпуска программного продукта является эффективным инструментом для оценки эффективности применяемых методик безопасной разработки и всего процесс разработки в организации в частности. Тестирование не дает гарантий, что ПО не содержит ошибок и уязвимостей и даже не гарантирует корректное поведение ПО и соответствие его функциональности требованиям. Однако использование эффективных методик тестирования в течении всего процесса разработки программного кода, корректное построение процесса тестирования способно обнаружить большинство из ошибок, уязвимостей и случаев неправильного функционирования, тем самым повышая безопасность ПО. В целом можно отметить что, корректное применение методов разработки безопасного ПО способно значительно повысить качество и безопасность разрабатываемого продукта при относительно умеренном уровне затрат. При этом, с учетом различной эффективности методов и различий в области их применения наиболее целесообразным представляется применение совокупности некоторых из рассмотренных методов для безопасной разработки на различных этапах создания ПО, например применение UMLSec на этапах формирования требований и проектирования, применение руководств разработчика, контрольных ведомостей и безопасных языков программирования на этапе разработки, а также применение таких методов тестирования как модульное тестирование, тестирование методом Баллиста, тестирование на устойчивость.
Список литературы:
1.Сайт xakep.ru. Режим доступа: (https://xakep.ru/2011/08/03/56389/) (дата обращения 25.08.2016). - 13 УТИЛИТ ДЛЯ БЕЗОПАСНОЙ РАЗРАБОТКИ: ИНСТРУМЕНТЫ ОТ MICROSOFT ДЛЯ НАПИСАНИЯ НАДЕЖНОГО КОДА
2. Официальный сайт компании ИнфоТеКС .Режим доступа: (https://www.infotecs.ru/press/publications/detail.php?ID=15041) (дата обращения 25.08.2016). - Безопасная разработка программного обеспечения – основа доверия к ИКТ в условиях современных киберугроз
3. Зефиров С. Л., Колобанов А. Ю. Методы безопасной разработки программного обеспечения. – 2009. – С. 1-3.
4.Сайт Хабрахабр. Режим доступа: (https://habrahabr.ru/company/microsoft/blog/134464/) (дата обращения 25.08.2016). - Разное → Как создавать безопасные системы. Краткое введение в SDL
Приложение А
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace WindowsFormsApplication5
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
Color cl = new Color(); // цвет для рисования
Color cl2 = new Color(); // цвет для рисования
Color cl3 = new Color(); // цвет для рисования
Pen pen; // перо рисования
SolidBrush brush,brush1;
int Rk,Rs,k; // радиус круга анимации
// Graphics g; // холст
void Work()
{
// Pen pen;
Bitmap bmp = new Bitmap(400, 200); // битовая карта для закрепления к pictureBox
pictureBox1.Image = bmp; // закрепление к pictureBox
Graphics g = Graphics.FromImage(bmp); // холст для рисования
bmp = new Bitmap("E:\\Снимок.PNG"); // инициализация файл с фото
Rectangle r = new Rectangle();
double p;
int w, h;
w = bmp.Width; // ширина иображения
h = bmp.Height; // высота изображения
r.X = 0;
r.Y = 0;
p = h;
r.Width = 400;
r.Height = (int)Math.Floor(p / w * r.Width); // пропорциональная высота
g.DrawImage(bmp, r);
// Color cl, cl3, cl2;
if (colorDialog1.ShowDialog() == System.Windows.Forms.DialogResult.OK) // цвет выбран?
{
cl = colorDialog1.Color; // цвет RGB
if (colorDialog1.ShowDialog() == System.Windows.Forms.DialogResult.OK) // цвет выбран?
{
cl2 = colorDialog1.Color; // цвет RGB
if (colorDialog1.ShowDialog() == System.Windows.Forms.DialogResult.OK) // цвет выбран?
{
// g.FillRectangle(brush, 100, 100, 150, 150); // белый сплошной прямоугольник
cl3 = colorDialog1.Color; // цвет RGB
}
}
}
pen = new Pen(cl); // перо
brush1 = new SolidBrush(cl2);
brush = new SolidBrush(cl3);
g.DrawLine(pen, 50, 40, 29, 10);
g.DrawLine(pen, 10, 40, 29, 10);
g.DrawLine(pen, 10, 40, 50, 40);
g.DrawLine(pen, 20, 40, 20, 140); // отрезок прямой
g.DrawLine(pen, 40, 40, 40, 140); // отрезок прямой
g.DrawLine(pen, 10, 140, 50, 140); // отрезок прямой
g.DrawLine(pen, 10, 150, 50, 150); // отрезок прямой
g.DrawLine(pen, 10, 140, 10, 150); // отрезок прямой
g.DrawLine(pen, 50, 140, 50, 150); // отрезок прямой
g.DrawEllipse(pen, 25, 120, 10, 10);
g.DrawEllipse(pen, 25, 100, 10, 10);
g.DrawEllipse(pen, 25, 80, 10, 10);
g.DrawEllipse(pen, 25, 60, 10, 10);
g.DrawEllipse(pen, 25, 40, 10, 10);
}
private void Form1_Load(object sender, EventArgs e)
{
timer1.Interval = 500; // интервал срабатывания таймера (0,5 сек)
Work();
}
private void timer1_Tick(object sender, EventArgs e) // отклик на событие Tick таймера
{
Animate(); // вызов каждый Interval (0,5 сек)
}
void Animate()
{
Bitmap bmp = new Bitmap(400, 200); // битовая карта для закрепления к pictureBox
pictureBox1.Image = bmp; // закрепление к pictureBox
Graphics g = Graphics.FromImage(bmp); // холст для рисования
bmp = new Bitmap("E:\\Снимок.PNG"); // инициализация файл с фото
Rectangle r = new Rectangle();
double p;
int w, h;
w = bmp.Width; // ширина иображения
h = bmp.Height; // высота изображения
r.X = 0;
r.Y = 0;
p = h;
r.Width = 400;
r.Height = (int)Math.Floor(p / w * r.Width); // пропорциональная высота
g.DrawImage(bmp, r);
pen = new Pen(cl); // перо
brush1 = new SolidBrush(cl2);
brush = new SolidBrush(cl3);
g.DrawLine(pen, 50, 40, 29, 10);
g.DrawLine(pen, 10, 40, 29, 10);
g.DrawLine(pen, 10, 40, 50, 40);
g.DrawLine(pen, 20, 40, 20, 140); // отрезок прямой
g.DrawLine(pen, 40, 40, 40, 140); // отрезок прямой
g.DrawLine(pen, 10, 140, 50, 140); // отрезок прямой
g.DrawLine(pen, 10, 150, 50, 150); // отрезок прямой
g.DrawLine(pen, 10, 140, 10, 150); // отрезок прямой
g.DrawLine(pen, 50, 140, 50, 150); // отрезок прямой
g.DrawEllipse(pen, 25, 120, 10, 10);
g.DrawEllipse(pen, 25, 100, 10, 10);
g.DrawEllipse(pen, 25, 80, 10, 10);
g.DrawEllipse(pen, 25, 60, 10, 10);
g.DrawEllipse(pen, 25, 40, 10, 10);
if (Rk > 60)
timer1.Enabled = false; // останов таймера
else
{
if (Rs == 0)
{
g.FillEllipse(brush, 25, 120, 10, 10);
Rs = 20;
}
else
{
if (k-Rs>= 40)
{
g.FillEllipse(brush, 25, k - Rs, 10, 10);
Rs += 20;
pictureBox1.Refresh();
}
}
}
}
private void pictureBox1_Click(object sender, EventArgs e)
{
}
private void button1_Click(object sender, EventArgs e)
{
string s;
s = textBox1.Text;
Rk = Convert.ToInt32(s);
Rs = 0;
k = 120;
timer1.Start(); // запуск таймера
}
}
}