• Статья

Документы о рабочей средеБезопасность и соответствие требованиям

Уэс Миллер (Wes Miller)

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

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

Безопасность — не флаг

Материалы по SDL

Соответствие требованиям обычно включает требования (люди, процесс, инфраструктуру, технологию и так далее), налагаемые извне на организацию, индустрию, компанию или продукт. Иногда соответствие требованиям означает соответствие принятым в индустрии стандартам (например, Payment Card Industry Data Security Standards или PCI-DSS). В идеале это такие начинания, которые хотя бы до некоторой степени совпадают с тем, как работает ваша организация. С распространением стандарта становится невозможным его игнорировать; и если деятельность предприятия предполагается продолжить, нужно присоединиться к стандарту и наилучшим образом использовать его.

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

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

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

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

Таким образом, некоторые требования соответствия становятся «флаговыми» требованиями. Тогда процессы на предприятии приходится разрабатывать или менять, пытаясь достигнуть единственной цели: соответствия нормативному требованию. «А хорошо ли это?» – как я частенько спрашиваю моего трехлетнего ребенка.

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

Если вы, как и большинство программистов, имеете дело с унаследованным приложением или архитектурой, то тем более необходимо проводить детальную проверку системы безопасности, что я часто отмечал в своих статьях. Если вы не понимаете, как что-то работает, как вы можете судить, безопасно оно или нет? Дальнейшая информация по Microsoft® Security Development Lifecycle (SDL) находится в боковом примечании "ресурсы SDL".

Общее осмысление

Я помню, как меня учили, что безопасность не сводится к простому внедрению шифрования, спискам управления доступом (ACLs, TLS) или инфраструктуре открытого ключа. Настоящая безопасность начинается с общего осмысления: понимание, почему данная версия данного протокола никем не используется или никогда не поддерживалась; почему новый фрагмент взаимодействия между процессами предотвращает атаку «злоумышленник в середине»; почему реализация программы в версии v2 намного безопаснее, чем в версии v1, хотя v1 гораздо быстрее. Также необходимо знать, как взаимодействуют друг с другом все части инфраструктуры.

Соответствие требованиям, с другой стороны, предполагает взять вашу технологию и добиться того, чтобы построенная инфраструктура соответствовала некоторым критериям. Некоторые требования, такие как Payment Card Industry Data Security Standards (PCI-DSS) или North American Electric Reliability Council (NERC), хорошо продуманы и могут привести в итоге к повышению самой безопасности. Однако, получив, в конце концов, «шведский стол» требований соответствия, которые нужно как-то вплести в существующий проект, и имея только ограниченные ресурсы, требования безопасности отходят на второй план.

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

Достаточно хорошо

Недавно я поменял работу. Теперь я работаю в новой компании в Остине, Техас, которая разрабатывает технологию внесения приложений в список разрешенных, чем-то похожую на ту, что мы разрабатывали в Winternals для продукта Protection Manager. Оказывается, что очень интересно разговаривать с заказчиками о том, насколько безопасными кажутся им используемые технологии — или, конкретнее, насколько безопасным, по их представлениям, делает их инфраструктуру используемый ими технологический набор. Хотя большинство из них почти наверняка работают в надежно защищенной среде и не открыты настежь различным уязвимостям, я часто слегка отшатывался в страже от их оценки безопасности системы как «достаточно безопасной».

Нормативные требования — веселая штука: вы им либо соответствуете, либо нет. Ответственность лежит на вас. Ценой несоответствия может быть штраф, наказание по закону или удаление из организации. Часто этого недостаточно, чтобы что-нибудь действительно изменилось.

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

Безопасность часто налетает на тот же дорожный блок, но, по-моему, он хотя бы более конкретен. Если в качестве разработчика вы активно указываете менеджеру на то, что удаление раздела «foo» из спецификации оставит продукт заметно более уязвимым к атакам извне, вы по крайней мере можете сказать после того, как работа вашего участка над продуктом завершена: "А я вам говорил". С нормативными требованиями мой опыт говорит о том, что выполнение их обычно определено нечетко, а бюджет на их внедрение максимально урезан.. Менеджеров стремятся привести все в соответствие с наименьшим уровнем требований — таким образом соответствуя букве требования, но точно не его духу.

Определение текущего уровня

Ресурсы по безопасности и соответствию требованиям.

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

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

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

Что можно потерять?

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

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

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

Гоняясь за хвостом

В прошлогодней статье, посвященной безопасности, я обсуждал тему «Как не потерять ваши данные» (technet.microsoft.com/magazine/cc162325). Год прошел, и появились новые скомпрометированные системы, потерялись очередные незашифрованные переносные компьютеры и новый объем личных данных попали в чьи-то подозрительные руки. Трудно сказать, есть ли в этом хоть какой-то прогресс. Почему мы все время топчемся на одном месте? Проекты опаздывают, работают на крохотных бюджетах, с нелепо растянутыми ресурсами, пытаясь поставить слишком много функций за слишком короткое время.

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

Я твердо верю, что:

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

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

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

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

Примите мой вызов

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

Итого, запомните: соответствие требованиям очень часто не совпадает с построением безопасной системы. Однако правильно реализованная безопасность довольно часто ведет и к выполнению нормативных требований.

Уэс Миллер (Wes Miller) –– старший технический руководитель продуктов в CoreTrace (www.CoreTrace.com) в г. Остин, штат Техас. Ранее Уэс работал в компании Winternals Software, а также в корпорации Майкрософт в должности руководителя программы. Связаться с Уэсом Миллером можно по адресу technet@getwired.com.

© 2008 Корпорация Майкрософт и CMP Media, LLC. Все права защищены. Запрещается воспроизведение статьи или ее части без разрешения.