Требуется специалист по информационной безопасности.

Сергей Гринкевич

В качестве вступления.

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

С истечением текущего года подходил к концу и третий месяц активных, но пока безрезультатных поисков. Именно это обстоятельство вызывало раздражение и беспокойство. Неужели так трудно найти специалистов на вакантные должности? И надо то всего лишь двоих. За что агентство по подбору персонала берет деньги? Обычно они работаю оперативно. Не успеешь сделать заявку, как уже нужно проводить собеседование. Но в этот раз все выглядело по-другому.

После получения от нас заявки на поиск специалистов в области безопасности программ, агентство стало направлять к нам охранников и телохранителей. Они действовали по принципу «нужна безопасность - получите армию». Хорошо, что не успела дойти очередь до спецназа и ФСБшников. Но и после разъяснительной беседы ситуация не улучшилась. За охранниками пошли системные администраторы, отвечающие за вопросы сетевой безопасности. Очередная разъяснительная беседа с работниками агентства и ... провал. Прямо как в детском стихотворении: «...ищут пожарные, ищет милиция ...ищут давно, но не могут найти...».

Грустно, но приходиться констатировать факт. У нас считанные единицы специалистов, имеющих опыт в проектировании «безопасного» программного обеспечения  и его тестировании. На вопрос о том, как большинство компаний-разработчиков обеспечивают безопасность своих программ,  вывод напрашивается сам собой: «Как получиться.».

Все хуже, и хуже, и хуже.... (на мотив извествной песни о самолетах)

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

«Утечка 20% коммерческой информации в 60% приводит к банкротству фирмы.»

«Gartner: простои систем из-за проблем с безопасностью могут за четыре года увеличиться в три раза.»

«Согласно очередному исследованию, половина компаний не имеют стратегии обеспечения информационной безопасности.»

«Оставлять личные данные в Сети стало совсем опасно.»

«90% сайтов финансовых компаний беззащитны перед киберпреступниками.»

«Вымогатели все чаще шантажируют интернет-компании.»

«IDC: 67% компьютеров заражены шпионскими программами.»

Одно из сообщений сервера «Беспека» позволю себе привести в полном объеме (адрес статьи: http://www.bezpeka.com/news/2004/10/2205.html).

«В 2004 году "цифровые риски" съели 411 млрд. долларов

Компания mi2g, специализирующаяся на оценке цифровых рисков, приводит в своем отчете суммы экономического ущерба от компьютерных атак различных типов в 2004-м году.
1. Экономический ущерб от DDoS-атак в 2004 году составит 34 млрд. долларов во всем мире против 1 млрд. долларов в прошлом году.
2. В 2004 году фишингу подверглись 117 компаний. В 2003 году их число составило 54 штуки, в 2002 году этот феномен был практически неизвестен. Экономический ущерб от фишинга в 2004 - 44 млрд. долларов, в 2003 - 14 млрд. долл.
3. 3,3 трилиона спамерских сообщений было разослано в течение 2004 года. В 2003 году их количество составило 1,6 трлн. Ущерб от спама в 2004 году - 119 млрд. долл. В 2003 году - 58 млрд. долл.
4. Ущерб от вирусов в 2004 году - 165 млрд. долл. по всему миру. В 2003 - 83 млрд. долл.
5. Экономический ущерб от всех видов виртуальных напастей (включая все вышеперечисленное) составил в 2004 году 411 млрд. долл. В 2003 году - 215 млрд. долл.»

Цифры говорят сами за себя. Прогнозы на 2005 год столь же не утешительны. Если верить некоторым аналитикам, то официальные данные не отражают действительной картины преступлений, совершаемых в ИТ сфере. Это всего лишь вершина айсберга.

Проблема сетевой безопасности и безопасного ПО  усугубляется тем, что военные министерства разных стран устанавливают на своем вооружении операционные системы массового производства. Так, например, британское военное ведомство оснастило свой эскадренный миноносец класса 45 и несколько подводных лодок Trafalgar операционной системой Windows 2000. Возможно, эта же операционная система будет установлена на их ядерных подводных лодках Vanguard. А на американских штурмовых вертолетах до сих пор установлена операционная система Windows NT 4.0.

По данным прессы, на сеть Форта Кэмпбелл, где такие вертолеты стоят на вооружении,  была совершена массированная хакерская атака. Для обеспечения более высокого уровня защищенности  командование вооруженных сил США приняло решение выделить 30 млн. долларов для перехода на ПО со службой каталогов Active Directory. Не трудно представить, что может произойти, если злоумышленники получат доступ к системам управления вооружением.

Здесь уместны два основных вопроса русской интеллигенции: «Кто виноват?» и «Что делать?».

Не возьмусь отвечать на вопрос «Кто виноват?». Зачастую это удел правоохранительных органов. Но, вопрос «Что делать?» для меня очень интересен и актуален. Попробуем с ним разобраться.

Процессы – ключ к успеху.

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

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

Давно известен факт, что причиной неудач в реальзации проектов по разработке программного обеспечения являются проблемы с управлением проектами. По данным отчета аналитической группы Standish Group International Inc. за 1994 год успешными были только 26% проектов. Для 31% проектов был превышен срок реализации более чем в два раза. Почти треть проектов (29%) вообще были прекращены по различным причинам.

Согласно данным Computer Emergency Readiness Team Coordination Center (CERT/CC) 75% уязвимостей программ порождены 10 типовыми причинами.  90% уязвимостей специалистам уже известны, они выявлены, описаны и имеются методики их нейтрализации. Следовательно, чаще всего, вопрос создания безопасного ПО - это вопрос правильной организации производственых процессов на предприятии.

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

Согласно другому распространенному мнению, внедрение процессов в повседневную практику фирм-разработчиков значительно увеличивает срок выпуска продукта. Однако, это убеждение также ошибочно. По данным отчета участников форума National Cybersecurity Summit, прошедшего в декабре 2003, применение процесса коллективного проектирования программного обеспечения (Team Software Process), разработанного Software Engineer Institute (SEI), увеличивает срок разработки не более чем на 6%. При этом достигаются отличные результаты качества кода. В выпускаемых программах на 1000 строк кода приходится 0,06 дефектов.

Но сами по себе процессные модели не гарантируют разработку безопасного программного обеспечения, так как перед ними не ставилась такая цель. Более того, в своем докладе на вторых днях качества в Москве один из соавторов стандарта CMM и автор эволюционной медели разработки Том Гилб убидительно продемонстрировал, что процессные модели даже не обеспечивают в полной мере производство качественного программного обеспечения. Основной задачей моделей производства, таких как RUP, MSF и им подобных, было уменьшение хаоса, снижение степени неопределенности и повышение предсказуемости результата в процессе разработки. Значительно позже эти модели были дополнены механизмами, позволяющими управлять качеством выпускаемых программ. По всей видимости, такой же сценарий развития ждет процессные модели разработки в вопросах создания безопасного программного обеспечения. Отчасти это уже происходит. Так, институтом SEI процесс коллективного проектирования ПО (TSP) был дополнен специальными процедурами, обеспечивающими контроль требований безопасности на протяжении всего жизненного цикла разработки. Новое название процесса – TSP-security.

Кто не с нами, тот против нас.

Реализация процессов с низким уровнем программных ошибок (менее 0,1 деффект на 1000 строк кода) может стать базисом организации разработки безопасного программного обеспечения. Но реальные результаты возможны только после специальных мероприятий. Понимание этого факта руководством компании – ключевой момент. Невозможно добиться ощутимых результатов без достаточных ресурсов и надлежащего финансирования.

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

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

Разработка безопасного программного обеспечения.

Как же добиться того, что бы разрабатываемое приложение имело минимальное количество уязвимостей и было надежно защищено от атак? Не стоит изобретать велосипед. Невозможно свести эту проблему к одному «золотому» правилу или приему. Для достижения  цели необходим комплексный подход, который включает в себя применение стандартов, осуществление мероприятий и реализацию сервисов безопасности.

Сервис безопасности это определенная функциональность или компонента, главной целью которой являеться предотвратить нарушения информационной безопасности, обнаружить атаку, локализовать действия злоумышленика или восстановить систему, после сбоя. К основным сервисам безопасности можно отнести следующие:

- аутентификация;

- авторизация;

- протоколирование и аудит;

- шифрование конфиденциальных данных;

- обеспечение отказоустойчивости;

- обеспечение безопасного восстановления после сбоя.

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

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

Помимо сервисов безопасности при разработке приложения необходимо использовать стандарты безопасности. К ним, наряду с большим количеством правил кодирования, можно отнести следующие:

- конфиденциальность – категория разграничения данных по степени секретности (секретно, для служебного пользования, для общего пользования);

- целостность – категория степени контроля данных (высокая, средняя, низкая). К примеру, данные со степенью целостности «высокая» должны публиковаться только на сайтах, управляемых администраторами компании;

- доступность – категория частоты контроля данных (высокая критичность, средная и низкая);

- устойчивость - разработка устойчивых состояний системы, в том числе настроек программы «по умолчанию»; в случае некорректного завершения программы должен быть обеспечен нормальный выход с блокированием кода сессии и уничтожением всех конфиденциальных данных, используемых в сессии;

- обработка критических ошибок, в том числе исключение разглашения данных о приложении и структуре сети через текст описания ошибок;

- проверка всех входящих данных на корректность;

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

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

- применение одной из зарекомендовавших себя процессных моделей разработки ПО;

- управление рисками безопасности по проекту;

- формулирование требований безопасности к разрабатываемому приложению;

- применение статического анализа кода на соответствие правилам кодирования;

- проведение юнит тестирования функциональности;

- проведение функционального и нагрузочного тестирования аспектов безопасности приложения;

- повышение квалификации сотрудников в вопросах реализации безопасных программ.

Стоит более подробно остановиться на мероприятиях по управлению рисками безопасности. Нет возможности избежать рисков, но всегда ли нужно с ними бороться? В зависимости от опасности угроз риски могут быть нейтрализованы, уменьшены, переадресованы или оставлены без внимания. Но, чтобы принять какое-нибудь решение по операциям с рисками, необходимо идентифицировать соответствующие угрозы. Как правило, архитектура разрабатываемого приложения не является чем-то абсолютно новым, поэтому работа по моделированию угроз начинается с анализа архитектуры приложения на наличие известных уязвимостей. Выявленные уязвимости располагаются по степени убывания риска. На основании этих данных принимается решение об управлении рисками. Такой подход позволяет оптимизировать материальные затраты на решение вопросов безопасности, выработать методику разработки и тестирования приложения, а так же критерии оценки остаточных рисков.

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

Фаза разработки	Исполнитель	Мероприятие	Артефакты
Разработка концепции приложения	Группа обеспечения безопасности	Разработка документации	Критерии конфиденциальности Критерии целостности Критерии доступности
Разработка архитектуры приложения	Проектная группа	Разработка документации	Точки устойчивости приложения Структура тестовых данных, используемых для разработки и тестирования
	Группа обеспечения безопасности	Управление рисками	Перечень выявленных уязвимостей и рекомендации по работе с ними
		Разработка документации	Требования безопасности к приложению
	Группа контроля качества	Разработка документации	Методика тестирования приложения на наличие выявленных уязвимостей Точки контроля (check lists) Выбор программ для проведения тестирования
Разработка приложения	Проектная группа	Генерация тестовых данных	Набор тестовых данных для разработки и тестирования приложения
		Статический анализ кода
		Юнит тестирование
	Группа контроля качества	Функциональное и нагрузочное тестирование	Выявленные дефекты Отчеты
Развертывание приложения	Группа обеспечения безопасности	Аудит остаточных рисков	Рекомендации на доработку
Стабилизация приложения	Группа сетевой безопасности	Сканирование приложения на предмет наличия известных уязвимостей	Рекомендации на доработку

В качестве послесловия.

После праздников руководство компании потеряло надежду найти архитектора безопасности в России и перенесло эту позицию в ирландское отделение. Но вакансия тестировщика безопасности пока открыта. Найдем ли?

Список литературы.

1. Заголовки новостей взяты с сайта www.bezpeka.com.

2. Курс лекций "Основы информационной безопасности"

Интернет университет информационных технологий

http://www.intuit.ru/department/security/secbasics/

3. "Processes to produce secure software"

National Cyber Security Pertnership

http://www.cyberpartnership.org/

4. "A guide to build secure web application"

The open web application security project

http://www.owasp.org/index.jsp

5. Нупур Дэвис, Уоттс Хамфри, Сэмюэл Редвайн, Герлинда Цибульски, Рэри Макгро

«Процессы разработки безопасного программного обеспечения»

Журнал «Открытые системы», #8, 2004

http://www.osp.ru/os/2004/08/045.htm

6. В.Мамыкин «Организация безопасного функционирования бизнес-приложений»

Журнал «Открытые системы», #10, 2004

http://www.osp.ru/os/2004/10/030.htm

7. Материалы выступления Тома Гилба (Tom Gilb) на вторых днях качества в Москве в сентябре 2004 года.

Несколько слов об авторе статьи.

Гринкевич Сергей Владимирович - руководитель группы автоматизации компании Dell Inc., отвечает за проведение нагрузочного, функционального, юнит тестирования и релиз менеджмент. Является координатором программы по разработке безопасного ПО в российском отделении компании.

E-mail: segrin@tut.by