Безопасность: общая ответственность (часть 5)

• Безопасность: общая ответственность (часть 2)
• Безопасность: общая ответственность (часть 3)
• Безопасность: общая ответственность (часть 4)
• Безопасность: общая ответственность (часть 6)

Введение

В этой серии статей, состоящей из нескольких частей, мы рассмотрим общую картину сфер ответственности в области безопасности и то, как каждый компонент (внутренняя должность или внешнее лицо) вписывается в головоломку, а также обсудим важность определенных зон ответственности.. В первой статье серии мы подробно рассмотрели роль CSO или CISO на вершине структуры ИТ-безопасности. Во второй части мы продолжили обсуждение, изучив роль (роли) безопасности ИТ-администраторов, а затем обсудили обязанности внешних подрядчиков, консультантов и партнеров, которым вы предоставляете доступ к некоторым или всем вашим ИТ-ресурсам. В части 3 мы начали рассматривать обязанности конечных пользователей по обеспечению безопасности и то, как вы можете превратить их в ответственных членов группы безопасности, а в части 4 мы продолжили обсуждение ответственности конечных пользователей.

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

Обязанности поставщиков программного обеспечения в области безопасности

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

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

Эволюция безопасности программного обеспечения

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

Давайте вернемся в прошлое, чтобы понять, почему поставщикам программного обеспечения потребовалось так много времени, чтобы присоединиться к побеждающей стороне на выборах в области безопасности. Когда почти все компьютеры работали под управлением Windows, Microsoft вряд ли потеряла много клиентов из-за пренебрежения безопасностью — худшее, что могло случиться, — это несколько недовольных клиентов и плохая пресса. Когда практически все смартфоны были iPhone, Apple не нужно было беспокоиться о том, что клиенты уйдут куда-то еще, если они не встроили в телефоны высокий уровень безопасности. Когда Flash был единственной игрой в городе для анимации и видео, Adobe не нуждалась в безопасности как в аргументе.

Произошло несколько событий, которые изменили это. Во-первых, по мере диверсификации рынка конкуренция меняет приоритеты. Клиенты (и делают) отказаться от поставщика и перейти на другую платформу, если они недовольны продуктом. Даже Apple, которая когда-то, казалось, почти гипнотизировала своих пользователей, начала сталкиваться с этим, когда iPhone и iPad уступили позиции продуктам Android за последние пару лет, хотя их выпуск iPhone 6 помог обратить это вспять. до некоторой степени (статистика за октябрь 2014 года показала, что iOS занимает 41 процент рынка США по сравнению с 53,8 процентами Android).

Дело в том, что клиенты больше не привязаны к одной программной платформе. У них есть выбор. Поставщики программного обеспечения осознают это и принимают во внимание (о чем свидетельствует капитуляция Apple перед рыночным спросом, когда они выпустили iPad Mini — несмотря на заявление бывшего лидера Стива Джобса о том, что компания никогда не будет производить планшеты с малым форм-фактором — и снова с введением iPhone 6 Plus после многих лет противостояния тренду «фаблет».

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

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

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

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

Юридическая ответственность за уязвимости: плюсы и минусы

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

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

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

Так родилось Лицензионное соглашение с конечным пользователем (EULA), оно же тот документ, который почти никто не читает. Вместо этого 99% тех, кто устанавливает программное обеспечение (или подписывается на программное обеспечение как услугу), быстро пролистывают длинную путаницу непостижимых юридических терминов, чтобы в конце нажать «Я согласен». Лицензионные соглашения с конечным пользователем различаются, но у них есть одна общая черта: соглашение о неприкосновенности поставщика программного обеспечения за любой ущерб, который может возникнуть в результате использования продукта.

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

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

Поставщики программного обеспечения окажутся в положении, похожем на положение врачей в США, где судебные иски о злоупотреблениях служебным положением привели к тому, что: а) многие хорошие врачи просто полностью уходят из профессии и б) те, кто остается, вынуждены иметь огромные страховые полисы ответственности за злоупотребление служебным положением, которые могут стоит десятки тысяч долларов в год. Это, в свою очередь, увеличивает стоимость здравоохранения, поскольку врачи и другие поставщики медицинских услуг должны взимать более высокую плату за свои услуги, чтобы оплачивать страховку. Разрешение судебных исков о «злоупотреблении служебным положением» программного обеспечения может привести к взлету цен на программное обеспечение и программные услуги в стратосферу.

Резюме

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

• Безопасность: общая ответственность (часть 2)
• Безопасность: общая ответственность (часть 3)
• Безопасность: общая ответственность (часть 4)
• Безопасность: общая ответственность (часть 6)