Слово "комплаенс" (от англ. compliance - соблюдение) говорит о соответствии\соблюдении неких внутренних\внешних норм, и вот у нас, в ИБ, к нему никак не могут отнестись равнодушно, т.е. профессионально и обьективно (ну этот холивар "бумажников"\"реальников" все знают).
Попробуем все таки разобрать данную область ИБ и посмотреть, так ли уж она важна (как нам рассказывают консультанты в галстуках) и бесполезна (тут уже появляются разномастые исследователи и инженеры).
Итак, комплаенс... т.е. внешний и внутренний. И, с внешним то все понятно - ГД не хочет в суд\административку, так что как минимум убедительно для регулятора изображать какие-то телодвижения придется. Тут важно А) понимать критерии убедительности для регулятора Б) регулярно рапортовать о прогрессе, ведь именно тут наши проблемы с загрузкой найдут понимание - никто ведь не хочет стать причиной административной ответственности ГД?..
Но, приведенный аспект на самом деле только часть внешнего комплаенса, не стоит забывать о т.н. внешнем комплаенсе развития.. например, мы ИТ-компаний и не будем допущены к тендеру без ISO 27001. Причем, далеко не факт что наш клиент в суматохе разберется на какие процессы и локации наш сертификат, сертификат то есть, заказ мы получили, а там как в анекдоте - Вам шашечки или ехать?... Тут тоже нужно делать А и Б, только не забывать дополнительно делать В) отслеживать\напоминать что без нас вот тех трех заказов (и +30 сотрудников в штате, например) просто бы не было (т.е. мы business enabler и не меньше)
Остался внутренний, а что, собственно, такое внутренний комплаенс, если с регуляторами мы разобрались, и даже с требованиями заказчиков тоже? Возьмем, к примеру, PCI DSS. Читаем - нужны антивирусы, межсетевые экраны, парольная политика такая-то... эээ, а разве мы так же не считаем и этого же не хотим у себя в компании? Чем будет отличаться наш аудит безопасности дочернего предприятия\дивизиона\ЦОДа от PCI DSS если у нас требования такие же? Или пойдем дальше - а как мы вообще можем быть уверены что наша политика безопасности будет реализована, если она не будет документирована, и проверена (т.е. не будет измерена степень соответствия?..), т.к. не будет точки отсчета и все наши проверки будут похожи на "тыканье иголкой в стоге сена", т.е. плохо, но плохо то везде и мы и так об этом знаем..
В общем, получается так - нигде от этого комплаенса не деться, без него у нас ГД административку дадут, заказчики новые не придут, да и бардак у нас в хозяйстве будет отменный..
С другой стороны - пока мы "правильно" напишем все политики, процедуры, инструкции и регламенты, да стандартов безопасности для каждого основного типа устройств - нас уже или поломают, или заразят, или вся эта махина потеряет актуальность (это же годы работы на самом деле). Соответственно, развитие всей этой нормативной базы должно идти параллельно (как ни странно), с безопасной настройкой наших ключевых элементов инфраструктуры и модулей ПО (благо, соответствующих руководств - полно, лично мне больше всего нравятся напрямую от вендоров либо от Center for Internet Security). Конечно, потом придется переделывать, но переделывать и так придется рано или поздно - ПО все обновляется, требования к соблюдению - меняются, да и переезды в новые ЦОДы - случаются.
В идеальном мире, конечно, нужно было бы сперва поставить цели, написать политики и т.п., но в идеальном мире мы были бы не нужны. Просто все злоумышленники сидели бы за решеткой, а все пользователи и продукты вендоров бы ли бы идеальны....
Попробуем все таки разобрать данную область ИБ и посмотреть, так ли уж она важна (как нам рассказывают консультанты в галстуках) и бесполезна (тут уже появляются разномастые исследователи и инженеры).
Итак, комплаенс... т.е. внешний и внутренний. И, с внешним то все понятно - ГД не хочет в суд\административку, так что как минимум убедительно для регулятора изображать какие-то телодвижения придется. Тут важно А) понимать критерии убедительности для регулятора Б) регулярно рапортовать о прогрессе, ведь именно тут наши проблемы с загрузкой найдут понимание - никто ведь не хочет стать причиной административной ответственности ГД?..
Но, приведенный аспект на самом деле только часть внешнего комплаенса, не стоит забывать о т.н. внешнем комплаенсе развития.. например, мы ИТ-компаний и не будем допущены к тендеру без ISO 27001. Причем, далеко не факт что наш клиент в суматохе разберется на какие процессы и локации наш сертификат, сертификат то есть, заказ мы получили, а там как в анекдоте - Вам шашечки или ехать?... Тут тоже нужно делать А и Б, только не забывать дополнительно делать В) отслеживать\напоминать что без нас вот тех трех заказов (и +30 сотрудников в штате, например) просто бы не было (т.е. мы business enabler и не меньше)
Остался внутренний, а что, собственно, такое внутренний комплаенс, если с регуляторами мы разобрались, и даже с требованиями заказчиков тоже? Возьмем, к примеру, PCI DSS. Читаем - нужны антивирусы, межсетевые экраны, парольная политика такая-то... эээ, а разве мы так же не считаем и этого же не хотим у себя в компании? Чем будет отличаться наш аудит безопасности дочернего предприятия\дивизиона\ЦОДа от PCI DSS если у нас требования такие же? Или пойдем дальше - а как мы вообще можем быть уверены что наша политика безопасности будет реализована, если она не будет документирована, и проверена (т.е. не будет измерена степень соответствия?..), т.к. не будет точки отсчета и все наши проверки будут похожи на "тыканье иголкой в стоге сена", т.е. плохо, но плохо то везде и мы и так об этом знаем..
В общем, получается так - нигде от этого комплаенса не деться, без него у нас ГД административку дадут, заказчики новые не придут, да и бардак у нас в хозяйстве будет отменный..
С другой стороны - пока мы "правильно" напишем все политики, процедуры, инструкции и регламенты, да стандартов безопасности для каждого основного типа устройств - нас уже или поломают, или заразят, или вся эта махина потеряет актуальность (это же годы работы на самом деле). Соответственно, развитие всей этой нормативной базы должно идти параллельно (как ни странно), с безопасной настройкой наших ключевых элементов инфраструктуры и модулей ПО (благо, соответствующих руководств - полно, лично мне больше всего нравятся напрямую от вендоров либо от Center for Internet Security). Конечно, потом придется переделывать, но переделывать и так придется рано или поздно - ПО все обновляется, требования к соблюдению - меняются, да и переезды в новые ЦОДы - случаются.
В идеальном мире, конечно, нужно было бы сперва поставить цели, написать политики и т.п., но в идеальном мире мы были бы не нужны. Просто все злоумышленники сидели бы за решеткой, а все пользователи и продукты вендоров бы ли бы идеальны....
Комментариев нет:
Отправить комментарий