Февральский номер журнала Computer посвящен сетевой безопасности. В отличие от обычной структуры журнала, в которой все статьи тематической подборки подаются под рубрикой «Cover Features», в этом номере статьи, относящиеся к теме безопасности, разбросаны по нескольким разделам журнала. Фактически, только одна (последняя) статья совсем не относится к теме номера. Поэтому я буду приводить обзоры статей в порядке их расположения в журнале.

Первая статья номера называется «Проблемы обеспечения безопасности сетевых приложений J2ME» («Challenges in Securing Networked J2ME Applications») и представлена Андре Клингсхеймом, Вебьерном Моемом и Кьелом Холе (André N. Klingsheim, Vebjørn Moen, Kjell J. Hole, University of Bergen, Norway).

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

Рынок смартфонов быстро растет, стимулируя разработку нового мобильного программного обеспечения. В частности, на мировом рынке мобильных игр ожидается рост прибыли от 2.6 млрд. долларов в 2005 г. до 11.2 млрд. в 2010 г., причем 20.5% рынка занимают онлайновые игры с несколькими участниками.

Имеется много различных инструментальных платформ для разработки программного обеспечения смартфонов. Эти платформы ориентированы на разных производителей, разные мобильные операционные системы и специфические особенности устройств. Однако наиболее распространенной платформой является Java 2 Micro Edition (J2ME), которая использовалась при разработке программного обеспечения 80% смартфонов, представленных на сегодняшнем рынке.

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

Авторами следующей статьи являются Дэвид Шафф, Оцгур Туреткен, Джон Д'Арси и Дэвид Кросон (David Schuff, Temple University, Ozgur Turetken, Ryerson University, John D'Arcy, Towson University, David Croson, Southern Methodist University). Статья называется «Управление перегрузкой электронной почты: решения и будущие проблемы» («Managing E-Mail Overload: Solutions and Future Challenges»).

Частью повседневной жизни стало затопление человека сообщениями электронной почты. По оценкам компании IDC, в 2006 г. ежедневно по e-mail пересылалось 84 миллиарда сообщений. Возрастает число не только сообщений со спамом, но и сообщений, несущих потенциально полезную информацию.

По утверждению авторов статьи, в этом затоплении сообщениями людям следует винить самих себя, поскольку электронная почта используется не так, как это предполагалось при создании этого приложения. Во-первых, e-mail часто используется в качестве инструмента архивации; многие пользователи никогда не удаляют сообщения, поскольку содержащаяся в них информация может пригодиться позже, например, в качестве напоминания о будущих событиях.

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

Только недавно появились признаки изменения такого способа использования e-mail. Например, в отчете проекта Pew Internet and American Life отмечается, что тинэйджеры теперь предпочитают использовать для оперативного общения службы мгновенной доставки сообщений, а не электронную почту. E-mail теперь больше используется для посылки длинных сообщений с более подробной информацией.

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

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

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

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

Авторами статьи «Криптография в пылинке» («Cryptography on a Speck of Dust») являются Йенс-Петер Капс, Гуннар Гаубац и Берк Сунар (Jens-Peter Kaps, George Mason University, Gunnar Gaubatz, Berk Sunar, Worcester Polytechnic Institute).

Беспроводные сенсорные сети (wireless sensor networks, WSN) и устройства радиоидентификации (radio frequency identification, RFID), применяемые в различных областях, от управления цепочками поставок до здравоохранения и автоматизации домов, быстро становятся жизненной частью человеческой инфраструктуры. Критическим фактором этих приложений является безопасность. Однако эти крошечные устройства обладают исключительно ограниченными ресурсами электропитания и небольшими вычислительными возможностями. Поэтому разработчики средств безопасности сталкиваются с противоречивой проблемой обеспечения облегченных алгоритмов строгой аутентификации, шифрования и других криптографических служб, которые могут функционировать внутри пылинки.

В современных беспроводных сенсорных узлах используются простые 4-х или 8-битовые процессоры общего назначения с питанием от батарей. Безопасные коммуникации обеспечиваются на основе программно реализованных криптографических протоколов, таких как Security Protocols for Sensor Networks (Spins). Авторы статьи предвидят, что сенсорные узлы следующего поколения будут работать без батарей, черпая вместо этого энергию из внешних источников своей среды. Появление вычислительных устройств с собственным обеспечением питания открывает дверь множеству новых приложений, не только в области сенсорных сетей, но и во всей области «всепроникающего» компьютинга.

Для обеспечения криптографических функций для этого класса устройств разработчикам, прежде всего, требуется учитывать фактор энергопотребления. До сих пор исследования концентрировались на аспектах WSN и программной реализации криптографических алгоритмов. Лишь недавно появились работы, посвященные исследованиям аппаратных реализаций (см., например, здесь).

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

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

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

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

Авторы из Индии Ваарун Виджаирагаван, Даршак Шах, Паллави Галгали, Амит Шах, Нихил Шах, Венкатеш Сривасан и Локеш Бхатия (Vaarun Vijairaghavan, IBM India Software Labs, Darshak Shah, Pallavi Galgali, IBM India Systems and Technology Labs, Amit Shah, Nikhil Shah, Synygy India, Venkatesh Srinivasan, Zensar Technologies, Lokesh Bhatia) представили статью «Создание метода для изоляции граничного маршрутизатора от нарушителя защиты» («Marking Technique to Isolate Boundary Router and Attacker»).

От враждебных воздействий, приводящих к отказу в обслуживании (Denial-of-Service, DoS), страдают как правительственные организации, так и коммерческие компании. DoS-злоумышленники обычно «затопляют» целевую сеть и входящие в ее состав компьютеры интенсивным трафиком, который исходит из одного или нескольких компьютеров, находящихся под контролем злоумышленника. При этом расходуются ресурсы удаленного хоста и сети, что приводит к отказу в обслуживании законных пользователей или к ухудшению качества обслуживания. DoS-атаки просто организуются и трудно предотвращаются, и поэтому они относятся к числу враждебных воздействий, с которыми сложнее всего бороться.

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

Идеальным методом прекращения атаки в месте ее зарождения является обратное прослеживание атаки до ее исходной точки. Существенным шагом к опознаванию злоумышленников и пресечению их враждебной деятельности является введение методов обратной трассировки протоколов Internet (Internet Protocol traceback), позволяющих надежно установить происхождение пакета в Internet.

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

Существующие методы борьбы с DoS-атаками направлены на нахождение всех маршрутизаторов, через которые прошел пакет злоумышленника. Однако знание реального маршрута пакета в действительности не помогает найти злоумышленника. В подходе авторов статьи к борьбе с DoS-атаками, называемом быстрой обратной трассировкой IP (Speedy IP Traceback, SIPT), предпринимается попытка точно определить граничный маршрутизатор (подключенный непосредственно к клиенту). Если известны граничный маршрутизатор и MAC-адрес злоумышленника, то можно определить злоумышленника и найти маршрут атаки.

При использовании SIPT каждый маршрутизатор определяет, происходит ли входящий пакет из непосредственно подключенного к нему клиенту или же из другого маршрутизатора. Если пакет поступает из клиента, то маршрутизатор вставляет в него идентификатор виртуального канала клиента и IP-адрес своего собственного входного интерфейса. Затем пакет посылается дальше обычным образом. Если пакет поступает из маршрутизатора, то он отправляется дальше безо всякой модификации.

Статья «Адаптивное качество обслуживания для мобильных Web-сервисов на основе межуровневой коммуникации» («Adaptive QoS for Mobile Web Services through Cross-Layer Communication») написана Мин Тианом, Андеасом Граммом, Хартмутом Риттером, Йохеном Шиллером и Тимо Войтом (Min Tian, MJN Technologies, China, Andreas Gramm, Hartmut Ritter, Jochen H. Schiller, Freie Universität Berlin, Thiemo Voigt, Swedish Institute of Computer Science).

По мере возрастания популярности Web-сервисов все больше компаний основывает свои будущие решения на этой технологии. Для поставщиков услуг ключевым аспектом технологии Web-сервисов является качество обслуживания (Quality of Service, QoS). Хотя в некоторых простых случаях приемлемыми оказываются сервисы без гарантированного качества обслуживания, QoS является критическим фактором при выборе Web-сервисов в качестве строительных блоков более сложных бизнес-приложений.

По этой причине аспекты безопасности, надежности, доступности и другие аспекты QoS фиксируются в стандартах, в частности, в стандарте Business Process Execution Language for Web Services (BPEL4WS). В спецификациях www.ws-i.org также затрагивается высокоуровневая поддержка QoS.

Потребность в спецификациях QoS для Web-сервисов диктуется двумя обстоятельствами. С одной стороны, клиентам нужно надежное обслуживание. С другой стороны, поставщики услуг стремятся к достижению оптимального баланса между уровнем удовлетворенности пользователей и уровнем загрузки системы. Например, наиболее важные транзакции, такие как обработка платежа, должны выполняться с высоким приоритетом.

Повсеместное распространение мобильных устройств, видимо, приведет к тому, что в будущем большая часть запросов всех Web-сервисов будет исходить именно от пользователей этих устройств. Однако мобильные устройства обладают ограниченными ресурсами процессора, памяти и энергии батарей. Это создает проблемы для использования Web-сервисов, поскольку при работе с ними возникают большие накладные расходы, чем при традиционном взаимодействии с Web. SOAP порождает длинные сообщения, дополнительные вычисления требуются при разборе XML и т.д.

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

С точки зрения клиента процесс взаимодействия с Web-сервисом, поддерживающим a QoS, состоит из трех фаз: спецификация требований к качеству обслуживания; обнаружение и выбор сервиса, обеспечивающего QoS; и вызов сервиса с указанием требуемого QoS. Авторы разработали среду QoS Web-сервисов (WS-QoS), которая поддерживает все три фазы.

WS-QoS:

1. дает возможность клиентам и поставщикам услуг специфицировать запросы и предложения с заданными свойствами и классами QoS;
2. обеспечивает эффективное обнаружение и выборку требуемых Web-сервисов;
3. позволяет поставщикам услуг публиковать и обновлять предложения с разными аспектами QoS;
4. поддерживает эффективный вызов Web-сервиса с требуемым QoS.

В предыдущих статьях (здесь и здесь) авторы рассматривали WS-QoS в контексте обнаружения и выбора Web-сервисов. В данной статье авторы обсуждают, как может использоваться их среда поставщиками транспортных и прикладных услуг при определении критериев QoS, а также клиентами при выборе наиболее подходящего поставщика услуг.

Путем применения XML-схемы WS-QoS поставщики могут пополнить свои предложения Web-сервисов различными аспектами QoS, такими как время задержки, пропускная способность, потеря пакетов и т.д., а клиенты могут определить собственные требования к QoS. И клиенты, и поставщики услуг могут определить собственные параметры путем указания специального элемента онтологии WS-QoS.

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

Последняя большая статья февральского номера представлена Лесом Хэттоном (Les Hatton, Kingston University London) и называется «Насколько точно инженеры прогнозируют задачи сопровождения?» («How Accurately Do Engineers Predict Software Maintenance Tasks?»).

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

Как определяется в стандарте IEEE 1219-1993, поддержка программного обеспечения «включает модификацию программного продукта после его выпуска для исправления ошибок, улучшения эффективности или других атрибутов или адаптации продукта к изменившейся среде». Соответственно, сопровождение традиционно подразделяется на три категории: адаптивное (adaptive) сопровождение посвящается добавлению новых функциональных возможностей, требуемых по причине изначальной незавершенности продукта или в ответ на замечания пользователей; при коррекционном (corrective) сопровождении устраняются дефекты программного обеспечения; целью совершенствующего (perfective) сопровождения является улучшение эффективности программного обеспечения без изменения его функциональности. Коммерческие разработчики часто пренебрегают совершенствующим сопровождением, поскольку выгоды от него не столь ощутимы, однако такое сопровождение является существенным фактором проектов с открытыми исходными кодами.

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

Эти исследования, проводившиеся в период 1985-1996 гг., показали, как много времени разработчики программного обеспечения посвящают различным задачам сопровождения, но не слишком прояснили, насколько точно разработчики прогнозируют тип и продолжительность сопровождения.

Формальный статистический анализ современных данных, полученных от небольшой компании по разработке программного обеспечения по поводу прогнозировавшихся и реальных работ в разных категориях сопровождения программного обеспечения, привел к некоторым неожиданным результатам. Данные касались 957 запросов на сопровождение или изменение (change request, CR), обслуживание которых заняло в целом 5,000 часов. Работа выполнялась в период с 14 марта 2001 г. по 14 ноября 2005 г. над 13 программными пакетами, четыре из которых использовались для построения двух коммерческих продуктов. Около 40% всей работы по сопровождению было потрачено на один из этих продуктов, который был формально выпущен в апреле 2002 г., и 20% - на другие 12 продуктов. 10% работы по поддержке ушло на поддержку программного обеспечения с открытыми кодами, а оставшиеся 30% - на разработку Web-сайта и служебных программ.

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

Во-первых, прогнозы затрат времени на обслуживание запросов всех типов для любого продукта со временем становятся более точными. Кроме того, программисты постоянно переоценивают время, требуемое для выполнения коротких CR, и недооценивают время для более сложных CR.

Далее, программистам более свойственны неточные предсказания категории сопровождения для коротких CR. Одним из возможных объяснений этого результата является то, что для коротких CR разработчики менее тщательно обдумывают возможные компоненты сопровождения. Для 77% CR обеспечивалось точное прогнозирование, а для оставшихся - совершенно неточное.

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

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