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

Спам-сообщения могут к тому же содержать мошенническую рекламу и вредоносные коды, например во вложениях, даже если имена и расширения прикрепленных файлов, равно как и текст сообщения, и картинки создают иллюзию рядового и вполне легитимного почтового отправления. Один из способов определить письмо как вредоносный спам — поочередно навести курсор на со держащиеся в нем гиперссылки и проверить в строке состояния или всплывающей подсказке, куда в действительности ведет ссылка: если не на сайт компании, значащейся в тексте, значит, это точ но вредоносный спам. Другой признак: отсутствие функции (ссылки) «отказаться от подписки» (unsubscribe). В США в рекламных объявлениях, распространяемых по электронной почте, нали чие такой ссылки для прекращения дальнейшего получения писем от отправителя обязательно.

2. ПРОВОДИМЫЕ РАБОТЫ

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

2.1 Выявление требований по безопасности данных

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

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

2.1.1 Бизнес-требования

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

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

2.1.2 Нормативно-правовые требования

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

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

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

США:

Закон Сарбейнса — Оксли (Sarbanes — Oxley Act of 2002);

Закон о применении медицинских информационных технологий в экономической деятельности и клинической практике, являющийся частью Закона о восстановлении американ ской экономики (Health Information Technology for Economic and Clinical Health (HITECH) Act, enacted as part of the American Recovery and Reinvestment Act of 2009);

Закон о преемственности и учете данных в медицинском страховании (Health Insurance Portability and Accountability Act of 1996, HIPAA);

Закон Грэмма — Лича — Блайли (Gramm — Leach — Bliley I and II);

Законы, принятые по инициативе Комиссии по ценным бумагам и биржам (Securities and Exchange Commission, SEC), и Закон о подотчетности в сфере корпоративной ИБ (Corpo rate Information Security Accountability Act);

«Патриотический акт» (Homeland Security Act and USA Patriot Act);

Федеральный закон об управлении информационной безопасностью (Federal Information Security Management Act, FISMA);

Закон штата Калифорния об обязательном информировании о случаях нарушения защиты данных (California: SB 1386, California Security Breach Information Act).

ЕС:

Директива о защите данных (EU DPD 95/46/): раздел AB 1901, хищение электронных фай лов или баз данных (Data Protection Directive (EU DPD 95/46/) AB 1901, Theft of electronic files or databases).

Канада:

Билль 1981

Австралия:

Закон о программе экономической реформы корпоративного права (CLERP Act).

Отраслевые нормативные документы, затрагивающие различные аспекты безопасности данных:

1 Билль 198 (англ. Bill 198) — аналог Закона Сарбейнса — Оксли, принятый в 2003 г. в провинции Онтарио, но вступив ший в силу лишь с 2006/07 финансового года. — Примеч. пер.

Стандарт безопасности данных индустрии платежных карт (Payment Card Industry Data Secu rity Standard, PCI DSS). Предусматривает подписание соглашения по соблюдению стандарта всеми организациями, имеющими отношение к работе с платежными картами.

Европейский союз. Соглашение о достаточности капитала (Базель II) устанавливает правила информационного контроля для всех кредитно-финансовых учреждений стран-участниц.

США. Стандарты защиты данных о потребителях Федеральной торговой комиссии (US Federal Trade Commission, FTC).

Нередко для обеспечения соблюдения корпоративных политик и/или нормативно-правовых тре бований и ограничений приходится вносить коррективы в бизнес-процессы. Пример: необходимость предоставления доступа к информации о состоянии здоровья граждан (регламентируемые данные) множественным уникальным группам пользователей в соответствии с Законом о преем ственности и подотчетности медицинского страхования (HIPAA).

2.2 Определение политики безопасности данных

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

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

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

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

в организации должны быть предусмотрены различные уровни политики. Например:

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

Политика безопасности ИТ. Стандарты структуры каталогов, политики в отношении паро лей, рамочная структура управления идентификацией пользователей и т. п.

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

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

управление данными.

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

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

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