Недавно прилетел с Урала, успел написать статью и сил писать что-то в блог нет ;-( Но коль скоро я взял за привычку публиковать какие-то заметки каждый рабочий день (за редким исключением), то сегодня опубликую что-нибудь ненапряжное ;-) Стащил у коллег заметку и перескажу ее своими словами с добавлением отсебятины ;-) Речь идет об аксиомах, о которых надо знать любому практикующему безопаснику и, особенно, выпускнику ИБ-специальности.
1. Инциденты будут происходит. План реагирования на инциденты должен начинаться не со слов "если произошел инцидент", а со слов "когда произошле инцидент". Свести к нулю число инцидентов на предприятии невозможно, да и не нужно никому. Безопасность нужна не ради безопасности и не ради достижения эфемерного показателя абсолютной защищенности. Это злоумышленнику достаточно найти всего один канал проникновения или обнаружить один вектор атаки на вас. Вам же нужно идентифицировать и защищать все каналы. Это задача неподъемная и очень дорогостоящая. Полностью исключить риск невозможно, но можно посчитать некоторые риски приемлемыми и принять их как данность, некоторые переложить на чужие плечи, а вот с оставшимися уже что-то делать.Хорошо спланированный процесс реагирования на инциденты поможет быстро идентифицировать скомпрометрированную систему и нивелировать последствия инцидента. Лучше это сделать заранее, а не пытаться что-то придумать во время происходящего инцидента - хаотические метания из стороны в сторону обойдутся гораздо дороже.
2. Системы будут взламываться. О проактивности в области ИБ говорят много и давно, но так сложилось, что ИБ, несмотря на все потуги, остается дисциплиной реактивной. Мы ставим патчи на уже обнаруженные уязвимости. Мы обновляем базы сигнатур как ответ на уже разработанные вредоносные программы и атаки. Мы разрабатываем правила на межсетевых экранах уже после внедрения новых приложений. Это надо учитывать, занимаясь не только отражением атак, но и расследованием их последствий.
3. Приложения должны быть работоспособными и защищенными одновременно. Если вы не работаете в компании, торгующей средствами защиты, то скорее всего ваша организация больше заинтересована в продвижении/достижении своих деловых интересов, а не в финансировании службы информационной безопасности. Нефтяная компания будет искать нефтянников, архитектурное бюро архитекторов, строительная компания строителей, банк финансистов. Тратить на это деньги гораздо проще и понятнее для бизнеса, чем финансирование такой туманной темы, как безопасность нематериальных активов. Информационная безопасность - это всегда компромиссы. Старые приложения лучше выбросить или переписать заново, чтобы прикрыть все те дыры, которые там есть. Но никто этого не будет делать, если старое (legacy) приложение выполняет поставленную перед ним задачу. Не пытайтесь достичь идеала там, где он недостижим или затраты на его достижение несоизмеримы с выгодами от этого достижения.
4. Люди будут стараться обойти все запреты. Если вы считаете, что что-то не произойдет никогда, это произойдет в самое ближайшее время. В области ИБ есть тоже свои законы Мерфи (я их написал еще в 2003-м году). Если что-то может пойти не так, оно пойдет не так. Никогда не надо недооценивать пользователей. Они люди творческие и пытливые. Вы не сможете (хотя попытаться стоит) спланировать и спрогнозировать все возможные ситуации и сценарии поведения пользователей в случаях, когда система защиты мешает им сделать что-то, что они хотят. Но и закрывать глаза на наличие пользователей нельзя - они часть защищаемой системы. Изучайте поведенческую психологию.
5. Вам нужно быть экспертом в том, чего вы раньше не видели. Вы не можете знать все! Вы не можете быть экспертом во всех технологиях, протоколах, приложениях и оборудовании, которые используются у вас на предприятии. Но этого и не требуется. Как ни парадоксально, но базовые идеи и подходы в области ИБ не меняются уже больше 40 лет. Аутентификация, сегментация, регистрация, разграничение доступа, ролевое управление... Все это было тогда, есть сейчас и будет завтра. Все это применяется почти в неизменном виде в IP, iSCSI, Fiber Channel. Все это применяется в обычных сетях, виртуализованных, в сетях хранения данных, в облаках. Вам, как правило, достаточно знать принципы, а дальше Google в помощь. Не пытайтесь познать все и не ждите, что наступит момент, когда вы скажете себе: "Теперь я знаю все в области ИБ!" Как только наступит такой момент, уходите на пенсию.
6. Законодательство меняется постоянно (это уже от меня лично). В программировании есть такая техника - аджайл (agile), которая исходить из того, что ТЗ меняется постоянно и зафиксировать его в неизменном виде с момента выставления требований и до момента сдачи работы невозможно. В области ИБ-законодательства ситуация аналогичная. Нормативные акты постоянно меняются, выходят новые, отменяют старые... Ждать, что вот-вот все устаканится и можно будет, наконец-то, следовать букве закона и сделать все правильно, не стоит. Этого можно ждать всю жизнь и не дождаться. Внедряйте agile-методологию в security compliance!
Ваша задача - свести риск к приемлемому для бизнеса значению. В этом состоит ключевая идея ИБ, а не в достижении/реализации мало кому понятной триады "конфиденциальность - целостность - доступность", которую сложно монетизировать и вообще представить в численных показателях.
ЗЫ. Ну и вот это тоже можно почитать в пятницу ;-)
1. Инциденты будут происходит. План реагирования на инциденты должен начинаться не со слов "если произошел инцидент", а со слов "когда произошле инцидент". Свести к нулю число инцидентов на предприятии невозможно, да и не нужно никому. Безопасность нужна не ради безопасности и не ради достижения эфемерного показателя абсолютной защищенности. Это злоумышленнику достаточно найти всего один канал проникновения или обнаружить один вектор атаки на вас. Вам же нужно идентифицировать и защищать все каналы. Это задача неподъемная и очень дорогостоящая. Полностью исключить риск невозможно, но можно посчитать некоторые риски приемлемыми и принять их как данность, некоторые переложить на чужие плечи, а вот с оставшимися уже что-то делать.Хорошо спланированный процесс реагирования на инциденты поможет быстро идентифицировать скомпрометрированную систему и нивелировать последствия инцидента. Лучше это сделать заранее, а не пытаться что-то придумать во время происходящего инцидента - хаотические метания из стороны в сторону обойдутся гораздо дороже.
2. Системы будут взламываться. О проактивности в области ИБ говорят много и давно, но так сложилось, что ИБ, несмотря на все потуги, остается дисциплиной реактивной. Мы ставим патчи на уже обнаруженные уязвимости. Мы обновляем базы сигнатур как ответ на уже разработанные вредоносные программы и атаки. Мы разрабатываем правила на межсетевых экранах уже после внедрения новых приложений. Это надо учитывать, занимаясь не только отражением атак, но и расследованием их последствий.
3. Приложения должны быть работоспособными и защищенными одновременно. Если вы не работаете в компании, торгующей средствами защиты, то скорее всего ваша организация больше заинтересована в продвижении/достижении своих деловых интересов, а не в финансировании службы информационной безопасности. Нефтяная компания будет искать нефтянников, архитектурное бюро архитекторов, строительная компания строителей, банк финансистов. Тратить на это деньги гораздо проще и понятнее для бизнеса, чем финансирование такой туманной темы, как безопасность нематериальных активов. Информационная безопасность - это всегда компромиссы. Старые приложения лучше выбросить или переписать заново, чтобы прикрыть все те дыры, которые там есть. Но никто этого не будет делать, если старое (legacy) приложение выполняет поставленную перед ним задачу. Не пытайтесь достичь идеала там, где он недостижим или затраты на его достижение несоизмеримы с выгодами от этого достижения.
4. Люди будут стараться обойти все запреты. Если вы считаете, что что-то не произойдет никогда, это произойдет в самое ближайшее время. В области ИБ есть тоже свои законы Мерфи (я их написал еще в 2003-м году). Если что-то может пойти не так, оно пойдет не так. Никогда не надо недооценивать пользователей. Они люди творческие и пытливые. Вы не сможете (хотя попытаться стоит) спланировать и спрогнозировать все возможные ситуации и сценарии поведения пользователей в случаях, когда система защиты мешает им сделать что-то, что они хотят. Но и закрывать глаза на наличие пользователей нельзя - они часть защищаемой системы. Изучайте поведенческую психологию.
5. Вам нужно быть экспертом в том, чего вы раньше не видели. Вы не можете знать все! Вы не можете быть экспертом во всех технологиях, протоколах, приложениях и оборудовании, которые используются у вас на предприятии. Но этого и не требуется. Как ни парадоксально, но базовые идеи и подходы в области ИБ не меняются уже больше 40 лет. Аутентификация, сегментация, регистрация, разграничение доступа, ролевое управление... Все это было тогда, есть сейчас и будет завтра. Все это применяется почти в неизменном виде в IP, iSCSI, Fiber Channel. Все это применяется в обычных сетях, виртуализованных, в сетях хранения данных, в облаках. Вам, как правило, достаточно знать принципы, а дальше Google в помощь. Не пытайтесь познать все и не ждите, что наступит момент, когда вы скажете себе: "Теперь я знаю все в области ИБ!" Как только наступит такой момент, уходите на пенсию.
6. Законодательство меняется постоянно (это уже от меня лично). В программировании есть такая техника - аджайл (agile), которая исходить из того, что ТЗ меняется постоянно и зафиксировать его в неизменном виде с момента выставления требований и до момента сдачи работы невозможно. В области ИБ-законодательства ситуация аналогичная. Нормативные акты постоянно меняются, выходят новые, отменяют старые... Ждать, что вот-вот все устаканится и можно будет, наконец-то, следовать букве закона и сделать все правильно, не стоит. Этого можно ждать всю жизнь и не дождаться. Внедряйте agile-методологию в security compliance!
Ваша задача - свести риск к приемлемому для бизнеса значению. В этом состоит ключевая идея ИБ, а не в достижении/реализации мало кому понятной триады "конфиденциальность - целостность - доступность", которую сложно монетизировать и вообще представить в численных показателях.
ЗЫ. Ну и вот это тоже можно почитать в пятницу ;-)
