Мы часто слышим упоминания о том, что большинство проблем в безопасности тех или иных программных продуктов так или иначе связаны с недочетами, допущенными при разработке. Действительно, многочисленные уязвимости, закрываемые бесконечными заплатками, по сути своей являются в большинстве случаев попросту ошибками программистов. Не стоит забывать и об архитектурных просчетах, которые уже простым патчем не поправить и, как следствие, такого рода ошибки исправляются новыми релизами ПО.
Вроде как всем понятна проблема и, если верить словам, все хотят поправить ситуацию: лучше продумывать архитектуру, более тщательно подходить к разработке, лучше тестироваться и т.п. НО, не является секретом тот факт, что для того, чтобы какое-либо изменение произошло, как минимум важна заинтересованность кого-либо в этом изменении. Так кто же заинтересован в разработке качественного ПО?
Разработчик? - Нет. Предположим гипотетически, что кто-то разработал ПО, которое не нуждается в постоянных обновлениях (исправлении ошибок), выпуске новых релизов (добавление новых возможностей и исправление архитектурных просчетов). Такой разработчик сможет заработать только однажды, продав право пользования своим ПО. Целый пласт доходов, связанных необходимостью поддержки, будет недоступен.
Еще один момент, который стоит учесть - это то, что есть некая зависимость количества программых ошибок от объема кода. В двух словах: чем больше кода, тем больше в нем ошибок. Как мне кажется, без ущерба для смысла, можно сказать и так: чем меньше ошибок, тем меньше кода. Наш разрабочик написал код с примерно нулевым количеством ошибок, значит его код невелик, а, следовательно, не велика и функциональность его кода. Поскольку, как правило, потребитель хочет "таблетку от всех болезней", не функциональный продукт будет плохо продаваться, дешево стоить, - в общем, доход от его продаж будет невелик, что не выгодно разработчику. Итого, как это не прискорбно, разработчик будет писать большой многофункциональный код, с большим количеством багов, которые потом будет исправлять во время всего жизненного цикла своего детища. При этом, безусловно, зарабатывая на этом.
Отрасль информационной безопасности? - Нет. Целый ряд уязвимостей будет искоренен как класс. Не будут нужны куча административных и технических контрмер, предпринимаемых в настоящее время для снижения ущерба от использования уязвимого ПО. Будут не нужны люди, задействованные в реализации этих контрмер: не нужны исследовательские институты, занимающиеся поиском уязвимостей, не будут нужны различные сканеры безопасности и те, кто ими пользуются, не будут нужны сложные процессы по управлению обновлениями ПО, их тестированию, пр.
В общем, к сожалению, только потребитель в проигрыше. Что, как это не цинично звучит, в общем-то нормально. Ведь кто-то должен оплачивать всех перечисленных выше....
Я писал применительно к программногому обеспечению, но, в целом, как это не прискорбно, принцип работает практически везде: АвтоВАЗ делает плохие машины и при этом еще зарабатывает на сервисе и запчастях, ресурс которых значительно ниже чем у кого бы то ни было, как, собственно, и самого автомобиля; средняя выслуга современной стиральной машины, из собственного опыта, не более 5 лет, тогда как у меня есть знакомые, которые покупали стиральную машину 15 лет назад (!) и она до сих пор исправно работет - действительно, производителю выгодно, чтобы я покупал его продукт каждые 5 лет, а не раз на всю жизнь.
Можно подумать о каких-либо мероприятиях по противодействию. Наверно, здесь поможет сертификация, но опять же сложность современных продуктов не позволяет обеспечить должную глубину проверки, а грубая поверхностная проверка не гарантирует желаемого качества.
Thursday, May 14, 2009
Бизнес для Бизнеса
Labels: Architecture, Operating Systems, Security, Software
Subscribe to:
Post Comments (Atom)
6 comments:
Аналогичные рассуждения можно распространить на другие виды деятельности.
Например.
Автомобили с выдающимися эксплуатационными характеристиками и сроком службы подорвут продажи и автопромышленность.
Новые лекарства позволяющие лечить болезни быстрее и с привлечением менее дорогостоящих специалистов и процедур заставят искать работу какое-то количество врачей и т.д.
Но всего этого не происходит, причем не благодаря злому умыслу.
Во всем этом, безусловно, есть доля правды. Но по сути ты рассматриваешь максималистский вопрос "кому выгодно чтобы ПО было 100% безопасно". На деле же надо рассматривать вопрос "кому выгодно чтобы ПО было безопаснее". А это выгодно, например, тому же производителю. При наличии двух вендоров ПО с примерно одинаковой функциональностью, вендор, ПО которого более безопасно будет в плюсе. Конечно, на практике все немного сложнее и преимущество будет у вендора, который более красочно опишет что его ПО безопаснее :), но в общем идея, думаю, ясна.
И совсем другая ситуация с "cloud computing". На данном этапе я бы принял за данное что теоретически у любого онлайнового сервиса есть (ненулевая) вероятность быть взломанным. Для конечного пользователя мерой защищенности сервиса будет скорее то, как вендор реагирует на инциденты - оперативность, эффективность, коммуникация с клиентами, и т.д. Безопасность это процесс...
Сертификация породит новый пласт нахлебников.
Если не ошибаюсь, в Европе есть желание обязать отвечать разработчиков ПО за ущерб нанесенный своими продуктами.
На деле же надо рассматривать вопрос "кому выгодно чтобы ПО было безопаснее".
Амиран, ты немного не уловил суть, но в этом, вероятно, виноват я.
Мой вопрос самому себе :) звучал так: "Так кто же заинтересован в разработке качественного ПО?". Я имел в виду не только безопасность, безопасность здесь выступает как одно из свойств "хорошего" ПО, как один из параметров качества.
Я не вижу причин, что может заставлять разработчика писать качественное ПО. Экономически писать брак более выгодно: во-первых, это банально дешевле, можно использовать низко квалифицированных разработчиков и архитекторов, как следствие - более дешевых, к тому-же можно потом, в рамках "поддержки" дорабатывать этот брак до качественного состояни, да и еще и зарабатывать на этом! Ты можешь возразить сказав, что тогда покупатель пойдет к тому, у кого качество в среднем выше. Мой ответ тебе - не пойдут, так как не к кому. Другие разработчики тоже не глупые люди, тоже считают деньги, зачем им делать качественный продукт "на века" и терять такой пласт дохода?? Они также будут держать своих разработчиков в индийских деревнях, китайских провициях и российских регионах, также будут брать архитекторов из тех же деревень за копейки и также потом за счет покупателя исправлять свой брак на протяжении всего жизненного цикла своего продукта. Задача коммерческой компании - зарабатывать деньги, а не делать хорошо покупателю. Цели и методы бизнеса циничны.
На мой взгляд, у компании-разработчика все таки может появиться желание писать качественное ПО в том случае, если она на рынке столкнется с конкурирующим open-source проектом.
Александр, согласен с вами, но только отчасти, поскольку open source практически не вариант для коммерческой компании.
Post a Comment