Журнал "Information Security/ Информационная безопасность" #4, 2018

Любой новый процесс вызывает отторжение. Сей- час это вопросы безопасно- сти, в свое время такое же неприятие вызывали ново- модные практики ITIL (IT Infrastructure Library – биб- лиотека инфраструктуры информационных техноло- гий). Когда-то для создания почты на своем домене нужно было делать поч- товый сервер и обслуживать его. Теперь же за $5 можно получить все и сразу, и даже без необходимости нанимать системного адми- нистратора. Головная боль СБ – минимизировать риски и повысить стоимость атаки. А бизнес-подразделения вспо- минают про ИТ или СБ толь- ко тогда, когда что-то не работает или же произошел резонансный инцидент (если, конечно, основной бизнес компании не связан с этими направлениями). В это же время практически все современные стандарты и законы в области приват- ности и персональных дан- ных требуют Secure by Design системы. Но как можно сделать это самое Secure, если Design делает- ся другим подразделением на самых модных и не все- гда проверенных техноло- гиях? перевести это с формального сухого языка требований на реальные примеры и техниче- ские требования. К тому же все- гда нужно смотреть шире и оце- нивать проблемы с безопас- ностью не только на уровне веса уязвимости и ее вектора, но и с точки зрения бизнеса. Из лич- ного опыта: практически в каж- дой более-менее крупной и ста- рой компании есть такие систе- мы, на которые даже дышать-то боятся, не то что обновлять. Это не значит, что надо закрыть на эти куски инфраструктуры глаза, следует подумать, какие ком- пенсирующие меры можно при- менить, пока она жива, – запла- нировать и посчитать обновле- ние, провести тесты и т.д. Есть и другая крайность – абсолютно абсурдные требования. К при- меру, включить полный аудит действий на файловой системе для всех пользователей на сер- верах (ну а что, наш производи- тель системы N написал это в своей документации, вендор плохого не посоветует). Если вы сейчас улыбнулись – все хорошо, если нет – у меня для вас плохие новости. Особенно если ваш директор по ИТ вырос из прак- тиков. Быстрее, выше… Сильнее ли? Как хорошо было раньше: не было всех этих CISO и их депар- таментов, в лучшем случае про- водили тесты в тестовой среде, устраняли ошибки и дальше внед- ряли уже на боевой системе. А случись что – откатывали назад. Теперь же туда не ходи, сюда не ходи, ошибку устрани, а после этого еще раз пройди кроме обыч- ного QA еще и тестирование на безопасность или аудит кода. Или и то, и другое. Еще и функции новые попросили для контроля. И на серверы все ходи по ключам и под собой, а не под админом. А у нас сроки жмут. Знакомо? Любой новый про- цесс вызывает отторжение. Сейчас это вопросы безопас- ности, в свое время такое же неприятие вызывали новомод- ные практики ITIL (IT Infrastruc- ture Library – библиотека инфра- структуры информационных технологий). Тем не менее любое внедрение систем без- опасности по классике ведет к усложнению процесса для поль- зователя – неважно, конечного клиента или внутреннего высо- копривилегированного пользо- вателя в лице сисадмина. И все эти нововведения идут вразрез с той скоростью, с которой сей- час живет бизнес. Мы смеемся над "Agile для HR", зачастую упуская из вида причины популярности подобных подхо- дов. А примеры-то у нас все перед глазами: когда-то для создания почты на своем доме- не нужно было делать почтовый сервер и обслуживать его. Теперь же за $5 можно полу- чить все и сразу, и даже без необходимости нанимать системного администратора. То же самое с любыми другими облачными сервисами и серве- рами: зачем платить такие кос- мические деньги за серверы, лицензии и людей, если все можно вот тут быстренько раз- вернуть. А про безопасность отдельный раздел на сайте написан – значит они безопас- ные. Однако в случае форс- мажора вроде блокировок одно- го крупного облака виноваты будут ИТ… Ну или СБ, за то, что не предусмотрели эту, как ее там, доступность. Но это уже совсем другая история. (R)evolution На самом деле в ИТ те же самые проблемы, что и в без- опасности. Новых технологий с низким порогом вхождения все больше (чего только стоит ново- модный Docker, эволюциониро- вавший из LXC… А что такое FreeBSD jail 2000 г. сейчас, наверное, никто и не вспомнит), и проблема человеческого фак- тора начинает стоять острее, чем когда основной угрозой были пользователи с низким уровнем компьютерной грамот- ности. Головная боль ИТ-депар- таментов – чтобы все работало как надо и было доступно. Головная боль СБ – минимизи- ровать риски и повысить стои- мость атаки. А бизнес-подраз- деления вспоминают про ИТ или СБ только тогда, когда что- то не работает или же произо- шел резонансный инцидент (если, конечно, основной бизнес компании не связан с этими направлениями). В это же время практически все современные стандарты и законы в области приватности и персональных данных требуют Secure by Design системы. Но как можно сделать это самое Secure, если Design делается другим под- разделением на самых модных и не всегда проверенных тех- нологиях? Изначальная ИТ-безопас- ность если не умерла, то уже начинает трансформацию. Вер- нее, возвращение к истокам с качественными изменениями. В 2008 г., после ряда громких взломов, институт SANS начал разрабатывать "Критичные контроли безопасности" – мини- мально необходимый набор из 20 контролей для обеспечения базового уровня ИТ-безопасно- сти в организациях. В 2013 г. этот документ был передан 18 • УПРАВЛЕНИЕ