| Сегодня 9 июня, воскресенье |
      |
  
|
  
Какой рейтинг вас больше интересует?
|
Главная /
Каталог блоговCтраница блогера Информационная безопасность/Записи в блоге |
 |
Информационная безопасность
Голосов: 1 Адрес блога: http://adorofeev.blogspot.com/ Добавлен: 2009-05-19 15:05:09 блограйдером adorofeev |
Защита персональных данных: извлекаем максимум пользы для компании
2009-06-21 18:36:00 (читать в оригинале)Сейчас многие компании активно приводят свои системы обработки персональных данных в соответствие российскому законодательству и часто можно услышать мнение о том, что федеральный закон и “четверокнижие” не продуманные, и что вся эта активность - всего лишь хорошая возможность заработать деньги, предоставленная компаниям-лицензиарам. Многие отмечают то, что формальное соответствие требованиям закона не означает реальную защищенность персональных данных, например, из-за того, что сертифицированные средства защиты уступают несертифицированным аналогам по качеству и функциональности.
Лично я убежден в том, что если компания осознает необходимость построения эффективной системы управления информационной безопасностью, то реализация проекта по приведению системы защиты в соответствие требованиям законодательства будет использована для повышения эффективности СУИБ.
Так, в ходе предпроектного исследования можно провести инвентаризацию всех информационных ресурсов, а не только тех, которые задействованы в процессах обработки персональных данных. Можно провести полноценную классификацию корпоративной информации и сформировать внутренние требования по защите данных разной степени критичности (относительно персональных данных будем считать, что государство нам помогло, сделав это за нас).
В ходе разработки частной модели угроз мы можем концепцию расширить и внедрить в своей компании процесс управления рисками информационной безопасности. Базовая модель угроз от ФСТЭК и международный стандарт ISO 27005 могут послужить хорошей отправной точкой для этого.
Наше законодательство не предъявляет четких требований к внутренним нормативным документам, но их все равно необходимо разрабатывать, так как понятно, что без работающего процесса ничего не получится. Также наличие регламентирующих документов проверяется контролирующими органами. Почему бы в ходе проекта не разработать политики и процедуры, вписывающиеся в систему управления информационной безопасностью и соответствующие лучшим мировым практикам, закрепленным в таких стандартах, как ISO 27001 и ISO 27002?
Акт Сарбейнса-Оксли и информационные технологии
2009-06-17 14:14:00 (читать в оригинале)Компаниям, чьи акции продаются на Нью-Йоркской фондовой бирже (NYSE), необходимо соответствовать требованиям акта Сарбейнса-Оксли. Сегодня многие вендоры программного и аппаратного обеспечения говорят о том, что их решения соответствуют требованиям данного акта. Предлагаю разобраться в том, что за требования предъявляет акт Сарбейнса-Оксли к ИТ, и как им можно соответствовать.
История вопроса
Акт Сарбейнса-Оксли был принят в 2002 году после нашумевших скандалов с компаниями Enron, Worldcom и некоторыми другими. Напомню, что в случае с Enron, компания готовила мошенническую отчетность, которую смело подписывали аудиторы из компании “Артур Андерсен”. Для аудиторов история закончилась плохо – компании “Артур Андерсен” больше нет, а ее практики в разных странах разбежались по другим компаниям теперь уже "большой четверки". Акт определяет требования как к аудиторам, так и к компаниям, чьи акции продаются на американской фондовой бирже. Так, например, компания из "большой четверки" не может оказывать определенные консалтинговые услуги своим клиентам по финансовому аудиту, так как потом не сможе независимо оценивать результаты своей же работы.
Параграф 404
Когда речь заходит о требованиях акта к ИТ все вспоминают 404-й параграф документа. Давайте посмотрим на текст оригинала повнимательнее:
"SEC. 404. MANAGEMENT ASSESSMENT OF INTERNAL CONTROLS.
(a) RULES REQUIRED.—The Commission shall prescribe rules requiring each annual report required by section 13(a) or 15(d) of the Securities Exchange Act of 1934 (15 U.S.C. 78m or 78o(d)) to contain an internal control report, which shall—
(1) state the responsibility of management for establishing
and maintaining an adequate internal control structure and
procedures for financial reporting; and
(2) contain an assessment, as of the end of the most recent
fiscal year of the issuer, of the effectiveness of the internal
control structure and procedures of the issuer for financial
reporting.
(b) INTERNAL CONTROL EVALUATION AND REPORTING.—With
respect to the internal control assessment required by subsection
(a), each registered public accounting firm that prepares or issues
the audit report for the issuer shall attest to, and report on, the
assessment made by the management of the issuer. An attestation
made under this subsection shall be made in accordance with standards
for attestation engagements issued or adopted by the Board.
Any such attestation shall not be the subject of a separate engagement."
Не буду переводить полностью, скажу лишь, что аббревиатура “ИТ” в тексте параграфа даже не встречается. Фактически акт требует от компании создать систему внутреннего контроля за процессами формирования финансовой отчетности и регулярно тестировать ее эффективность и готовить соответствующие отчеты с результатами тестирования. И все.
Откуда же берутся требования к ИТ?
Разбираемся дальше. Фактически акт требует создать контроли (контрмеры) в процессах формирования финансовой отчетности, минимизирующие риски ее искажения. Такие контроли могут быть как ручными (например, подпись руководителя на приказе перед тем как чем-то будет дан ход), так и прикладными в информационных системах (например, замена подписи в виде галочки в соответствующей форме). К прикладным контролям также часто относят функционал систем расчета каких-либо цифр, попадающих, в конечном счете, в финансовую отчетность.
Для того, чтобы этим прикладным контролям можно было доверять нужны эффективные общие ИТ-контроли.
Общие ИТ-контроли для SOX
Фактически, когда мы говорим о соответствии ИТ-контролей требованиям акта Сарбейнса-Оксли, мы подразумеваем, что контроли соответствуют пониманию аудиторов из "большой четверки" о том, какие общие ИТ-контроли должны функционировать в компании. Благодаря такой организации, как ISACA понимание аудиторов из "большой четверки" было формально закреплено в документе IT Control Objectives for Sarbanes-Oxley 2nd Edition (для скачивания потребуется регистрация на сайте ассоциации). В документе есть матрица с иллюстративными контролями, которая по сути представляет собой сильно усеченную версию Cobit. Основными ИТ-процессами, которые должны быть на достойном уровне, являются: процесс внесения изменений в информационные системы, процессы управления информационной безопасностью, процесс управления конфигурациями и т.д. В этом же документе есть иллюстративные прикладные контроли, которые также могут быть полезными.
Как выполнить требования SOX (аудиторов из BIG4) к ИТ?
Алгоритм следующий:
- Определить какие информационные системы и поддерживающая их ИТ-инфраструктура задействованы в процессах формирования финансовой отчетности. На этом этапе также очень важно пообщаться со своими аудиторами и добиться одинакового понимания этого вопроса.
- Провести оценку ИТ-рисков для выбранных систем и определиться с контролями по их минимизации. Очень рекомендую использовать перечень контролей из обсуждавшегося выше документа “IT Control Objectives for Sarbanes-Oxley 2nd Edition.”. Особое внимание должно быть уделено контролям, связанным с внесением изменений и управлением доступом.
- Формализовать выбранные контроли в виде политик и процедур. Воплотить их в жизнь.
- Определить подход к тестированию контролей. Проводить периодическое тестирование контролей с формальным отчетом на выходе.
Вместо заключения
Таким образом, привести ИТ в соответствие требованиям акта Сарбейнса-Оксли не сложно: алгоритмы понятны, доступно хорошее руководство от ISACA. Заявления же вендоров о том, что их продукты, соответствуют требованиям SOX 404 являются всего лишь рекламным трюком.
Обеспечение непрерывности бизнеса и восстановление после сбоев
2009-06-10 17:05:00 (читать в оригинале)Сегодня многие компании начинают задумываться о планировании непрерывности бизнеса (Business Continuity Planning) и восстановлении после сбоев (Disaster Recovery Planning). Эффективная система управления непрерывностью бизнеса позволит минимизировать денежные потери в случае реализации угрозы прерывания бизнеса. Банковским же организациям необходимо выполнять требования Положения 242-П "Об организации внутреннего контроля". В настоящей заметке я рассмотрю основные этапы создания эффективной системы управления непрерывностью бизнеса и ее организационную структуру.
Как создается система управления непрерывностью бизнеса?
У каждой компании свой путь к эффективной системы управления непрерывностью бизнеса, который зависит от вида деятельности, размера организации, корпоративной культуры и многих других факторов. Рассмотрим основные шаги проекта по внедрению
полноценной системы управления непрерывностью бизнеса.
Шаг 1. Оценка рисков
Первым шагом на пути к обеспечению непрерывности бизнеса является создание в компании процесса по идентификации угроз, которые могут оказать столь негативное влияние на бизнес компании.
Перечень угроз для каждой компании будет индивидуальным, но некоторые угрозы будут актуальны для многих компаний.
Приведу примеры некоторых угроз:
- недоступность офиса;
- недоступность датацентра;
- массовое отравление персонала;
- и т.д.
После идентификации угроз, проводится оценка рисков (как правило, с помощью наиболее понятного и удобного способа и в результате мы получаем ТОП N рисков, с которыми нужно бороться в первую очередь.
Шаг 2. Оценка влияния прерываний на бизнес и определение требований
На этом шаге решается несколько задач, но разбивать его на отдельные шаги, как правило, нецелесообразно.
Задачами данного этапа являются:
- определение последствий прерывания процессов;
- выявление критичных бизнес-процессов;
- выявление взаимозависимости процессов;
- определение информационных систем, поддерживающих критичные бизнес-процессы;
- определение требований бизнеса к целевому времени восстановления системы (RTO – Recovery Time Objective) и целевой точки восстановления (RPO – Recovery Point Objective);
- определение требований к ресурсам, необходимым для минимального поддержания функционирования процессов (персонал, рабочие станции).
Замечание из практики
Очень часто руководители бизнес-подразделений пытаются завысить критичность процессов своего подразделения. Для того чтобы получить адекватную оценку критичности бизнес-процессов необходимо получить подтверждения оценок от руководителей более высокого уровня.
Также в ходе данного этапа формируются списки критичных сотрудников (20% тех, кто делает 80% работы), что также сталкивается с сопротивлением со стороны руководителей подразделений по понятным причинам.
Шаг 3. Оценка текущего состояния
После того, как мы поняли, какие бизнес-процессы для нас являются критичными и определили требования к информационным системам, необходимо определить, насколько эти требования выполнимы в текущих условиях.
На данном шаге мы получаем информацию о существующих проблемах, что позволит нам в ходе непосредственного планирования определить, какие решения нужно принять для выполнения требований бизнеса.
Шаг 4. Разработка нормативной документации системы управления непрерыностью бизнеса
Для того чтобы наша система управления непрерывностью бизнеса заработала, необходима разработка ряда нормативных документов. На мой взгляд, набор документации по BCP для крупной компании должен содержать:
- Политику обеспечения непрерывности бизнеса;
- План действий антикризисного комитета;
- План PR-отдела по реагированию на кризис;
- План HR-отдела по реагированию на кризис;
- Планы обеспечения непрерывности деятельности бизнес-подразделений;
- План восстановления ИТ после сбоев;
- Инструкции по восстановлению информационных систем;
- Общий план обеспечения непрерывности бизнеса и восстановления после сбоев;
- Схемы рассадки персонала
Детально содержание данных документов я рассмотрю в одной из следующих своих заметок.
Шаг 5. Внедрение контрмер
Для повышения устойчивости компании принимают различные решения:
- договариваются с соседями по бизнес-центру о предоставлении площадей в случае кризисной ситуации;
- территориально разносят подразделения;
- выбирают один из офисов в качестве резервной площадки;
- строят или арендуют резервные датацентры;
- и т.д и т.д.
В зависимости от требований к целевому времени восстановления может появиться необходимость внедрения различных технических решений, либо настройки существующих в соответствии с требованиями бизнеса.
Обеспечить необходимый уровень устойчивости к сбоям и скорейшее восстановление нам помогут:
- кластерные решения;
- виртуализация;
- системы резервного копирования;
- сети хранения данных;
- территориальное разнесение серверов;
- резервные каналы связи.
Сотрудники должны изучить разработанные планы и знать, что им делать в случае кризисной ситуации.
Шаг 6. Тестирование
После того, как мы определились с угрозами прерывания нашего бизнеса и приняли и внедрили в жизнь соответствующие контрмеры, нам необходимо проверить, насколько все то что мы создали, позволит нам противостоять угрозам в действительности. Для этого необходимо тестирование эффективности принятых мер.
Бывают различные виды тестирования. Можно тестировать только планы, тогда сотрудники собираются в одном помещении и имитируют выполнение действий, которые они бы предприняли в соответствии с планами, а можно устроить боевое тестирование – отозвать партию продукции, остановить работу “боевого” сервера и т.п. Объем и вид тестирования выбираются, исходя из необходимости проверить работоспособность решения/плана и не нанести ущерб бизнесу.
Организационная структура
Для того, чтобы непрерывность бизнеса обеспечивалась, необходимо иметь соответствующую организационную структуру.
В ходе обычного функционирования компании, как правило, выделяется человек (очень редко отдел), который отвечает за поддержание работоспособности системы управления непрерывностью бизнеса (обновление документации, результатов анализа рисков и т.п.). Такого человека часто называют менеджером по обеспечению непрерывности бизнеса. В каждом критичном бизнес-подразделении также назначается координатор, ответственный за поддержание актуальными планов подразделений.
В случае возникновения кризисной ситуации созывается антикризисный комитет, который берет управление компанией на себя для сокращения времени реакции. Для восстановления деятельности создаются специальные команды восстановления, которые и подчиняются антикризисному комитету.
Замечание из практики
Цель создания антикризисного комитета понятна: в случае кризисной ситуации очень важна малая скорость реакции, и поэтому необходимо сосредоточивание власти у довольно малой группы руководителей. Таким образом, если обычно компания управляется десятью директорами, то в случае кризисной ситуации, управление может осуществляться 2-3-мя топ-менеджерами. Понятно, что здесь появляются политические вопросы, в которые консультанты не любят вмешиваться, и иногда антикризисный комитет просто полностью дублирует исполнительный орган управления компании, что, на мой взгляд, не оправдано.
Продолжение следует.
Александр Дорофеев (c)
Документы по информационной безопасности
2009-05-28 19:17:00 (читать в оригинале)Одной из важнейших составляющих эффективной системы управления информационной безопасностью является набор работающих политик и процедур. Зачем они нужны? Как отличить хороший документ от плохого? Как шутят консультанты и интеграторы? Об этом в данной заметке
Зачем нужны документы?
В основном, для того чтобы у всех было одинаковое понимание о том, что, когда, как и кто должен делать для защиты информации (дополнительно см. Политики и процедуры по информационной безопасности).
Есть ли универсальные документы?
Универсальных документов нет. В маленькой компании хватит инструкции для конечного пользователя, а в транснациональном холдинге потребуется целая структура взаимосвязанных документов.
Как оценить качество политики/процедуры?
Перечислю признаки плохих документов:
- Большой объем (для политики > 3 страниц, а для процедуры > 15);
- Плохая ориентированность на аудиторию. Например, в документе, ориентированном на ИТ-специалистов, рассказывается о том, что такое “конфиденциальность”, “целостность” и “доступность”, а в документе, ориентированном на всех сотрудников компании, авторы смело оперируют такими понятиями, как “правила межсетевого экранирования” и “система обнаружения вторжений”;
- Мутность документа. Если из документа не понятно, как распределяются обязанности, в чем заключается процедура, какие результаты на выходе, как осуществляется контроль, какая периодичность выполнения процедуры и т.п., то единственная польза такого документа заключается в его наличии. Такие документы могут доставаться с пыльной полки раз год для аудиторов.
Таким образом, хороший документ – ясный, краткий и ориентирован на конкретную группу пользователей.
Курьезы из практики
За свою практику я просмотрел достаточно много политик информационной безопасности и две политики мне запомнились своей оригинальностью.
Один документ входил в состав комплекта, поставляемого на компакт-диске одним из игроков российского рынка информационной безопасности. Не знаю почему, но высокоуровневая политика информационной безопасности включала в себя схему сети. Другая политика представляла собой документ объемом в 50 страниц и тянула на хорошее вузовское пособие по информационной безопасности – она содержала описание математических моделей злоумышленника.
Разработка документов по информационной безопасности как бизнес
Практически любая компания, работающая на рынке информационной безопасности, предлагает услуги по разработке политик и процедур информационной безопасности. Вещь полезная для клиента, но необходимо помнить, что в ходе такого проекта нужно быть постоянно в контакте с консультантами, чтобы на выходе не получить неработающие “лучшие практики”. Только вовлечение сотрудников клиента и предоставление необходимой информации о существующих в компании процессах позволят создать комплект документов, подходящих компании.
Полезный проект: SecurityPolicy.ru
В своей заметке Информационная безопасность за бесплатно я упоминал о проекте института SANs по разработке политик информационной безопасности. Недавно узнал о российском проекте SecurityPolicy.ru. Портал уже содержит серьезный набор документов, и надеюсь, что благодаря общим усилиям специалистов по информационной безопасности, он станет хорошим источником шаблонов документов для построения эффективных систем управления информационной безопасностью в российских компаниях.
Наш вклад
Наша компания также поддерживает публикацию полезных шаблонов документов и сегодня на нашем сайте появился шаблон Положения о применимости контрмер ISO 27001 (Statement of applicability). Данное положение необходимо для прохождения сертификации по ISO 27001, так как именно оно (в заполненном, конечно, виде) определяет границы системы управления информационной безопасности в терминах контрмер ISO 27001.
Дополнительно по теме
- Управление документацией системы управления информационной безопасностью: требования ISO 27001:2005
- Политики и процедуры по информационной безопасности
- Политика информационной безопасности
Александр Дорофеев (c)
Опять privacy
2009-05-24 00:43:00 (читать в оригинале)Две интересные ссылки в тему "privacy":
- Сайт, демонстрирующий возможность получения информации о посещаемых интернет-ресурсах: ru.startpanic.com
- ЖЖ-сообщество, обсуждающее интересные фотографии из социальных сетей: http://community.livejournal.com/shkola_urodov/
Категория «Блогосфера»
Взлеты Топ 5
 | ||
|
+1241 |
1261 |
Robin_Bad |
|
+1175 |
1263 |
Futurolog |
|
+1090 |
1094 |
MySQL Performance Blog |
|
+1028 |
1098 |
Ksanexx |
|
+1023 |
1097 |
Refinado |
Падения Топ 5
 | ||
|
-2 |
511 |
партнерки |
|
-3 |
605 |
Блог о раскрутке и монетизации сайта. |
|
-3 |
86 |
Mandalaй.ru |
|
-4 |
39 |
БЛОГика |
|
-4 |
589 |
Блог Демона |
Популярные за сутки
Загрузка...
BlogRider.ru не имеет отношения к публикуемым в записях блогов материалам. Все записи
взяты из открытых общедоступных источников и являются собственностью их авторов.
взяты из открытых общедоступных источников и являются собственностью их авторов.