Разработчики P2P-мессенджера Firechat из Гонконга говорят, что на создание этого проекта их сподвигла государственная цензура, которая действует в Китае (Гонконг входит в состав Китая). В этой стране заблокированы многие веб-сайты, в том числе Instagram и другие социальные сети. Поэтому у местных пользователей возникают проблемы с поиском способов безопасного общения.

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

Чтобы обойти государственную цензуру, разработчики из компании Open Garden выпустили P2P-мессенджер Firechat, который позволяет общаться напрямую между устройствами, без использования интернета. Зашифрованные соединения устанавливаются по Bluetooth и WiFi. Таким образом, можно избежать слежки со стороны китайских властей, а заодно избежать и надзора со стороны западных спецслужб.

Авторы программы говорят, что за 24 часа аккаунты завели более 100 000 пользователей из Гонконга. Приложение пользуется популярностью и в других странах, где ущемляются свободы граждан, в том числе в Тайване и Иране.

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

Firechat
в каталоге Google Play
Firechat в App Store

Наша интернациональная звездная команда ZeroNights 2014 растет! Сегодня представляем вам трех крутейших докладчиков из трех разных стран.

Знакомьтесь со спикерами из основной программы:

• Peter Hlavaty/Петер Хлаваты (Словакия) поиграет в гонки в ядре Android;
• Rene Freingruber/Рене Фрайнгрубер (Австрия) расскажет, как обстоят дела c EMET 5.0;
• Marco Grassi/Марко Грасси (Италия) поделится опытом использования стероидов (модификации приложений в runtime) при оценке безопасности приложения для iOS и Android.

И, кстати, не стоит тянуть с регистрацией. В этом году мы ждем рекордное число гостей

Специалисты из компаний F-Secure, Британского института по информационной безопасности и немецкой компании SySS провели совместное исследование, насколько обычные пользователи готовы подключаться к бесплатному хотспоту, даже если это подключение представляет потенциальную опасность.

Для проверки, компания SySS оборудовала точку доступа WiFi в деловом центре Лондона. За 30-минутный период к хотспоту подключились 250 устройств. Большинство подключений произошло автоматически, так что владельцы устройств даже не узнали об этом. 33 устройства передавали трафик через точку доступа WiFi, в том числе поисковые запросы и сообщения электронной почты. В общей сложности, за полчаса исследователи получили 32 мегабайта данных (вся информация удалена, во избежание нарушения приватности).

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

«Мы все любим использовать бесплатный WiFi, чтобы сэкономить на передаче данных и роуминге, — говорит Шон Салливан (Sean Sullivan), специалист по безопасности из компании F-Secure, который принимал участие в проведении эксперимента, — но, как показала практика, слишком легко любому желающему установить бесплатный хотспот, дать точке доступа вызывающее доверие название и шпионить за активностью пользователей». По мнению специалиста, такой возможностью могут воспользоваться злоумышленники для копирования чужих паролей и прочих конфиденциальных данных.

14 июля 2015 года завершится поддержка серверных операционных систем Windows Server 2003 и Windows Server 2003 R2. Во многих компаниях, использующих эти ОС, запускаются проекты модернизации ИТ-инфраструктуры и миграции на более современные системы. Именно поэтому ИТ-специалистам будет особенно полезно взглянуть на технологические решения, заложенные в новейшую ОС семейства Windows Server – Windows Server 2012 R2.

В рамках online-мероприятия будут рассмотрены усовершенствования компонент, применяемых практически в любой организации: службы Active Directory, инструменты построения СХД, средства автоматизации административных задач. Кроме того, участники Jump Start смогут познакомиться с решениями по управлению идентификационными данными в гибридных структурах, в частности с сервисом Azure Active Directory Premium.

Дата проведения – 07 октября 2014г. в 12:00 (МСК)

Программа мероприятия

• 12:00 – 13:00 Модернизация инфраструктуры. Почему Windows Server 2012 R2?
• 13:00 – 13:15 Перерыв
• 13:15 – 14:15 Усовершенствования в Active Directory
• 14:15 – 15:00 Перерыв
• 15:00 – 16:00 Модернизация инфраструктуры СХД
• 16:00 – 16:15 Перерыв
• 16:15 – 17:15 Автоматизация с помощью PowerShell
• 17:15 – 17:30 Сессия вопросов и ответов

Смотрите онлайн-трансляцию Jump start 7 октября в 12:00 и общайтесь с экспертами онлайн!

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

Введение

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

Когда я потерял смартфон, мне сильно повезло, что установленный на него антивор оказался работоспособным и позволил удаленно стереть все данные из памяти девайса. Когда я по невнимательности открыл SSH-порт на домашней машине с юзером без пароля (!) во внешний мир (!!), мне сильно повезло, что на машину пробрались скрипт-кидди, которые кроме смешной истории шелла не оставили никаких серьезных следов своего пребывания в системе. Когда я случайно опубликовал в интернете листинг со своим паролем от Gmail, мне сильно повезло, что нашелся добрый человек, который предупредил меня об этом.

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

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

Пароль!

Все начинается с паролей. Они везде: в окне логина в Linux-дистрибутиве, в формах регистрации на интернет-сайтах, на FTP- и SSH-серверах и на экране блокировки смартфона. Стандарт для паролей сегодня — это 8–12 символов в разном регистре с включением цифр. Генерировать такие пароли своим собственным умом довольно утомительно, но есть простой способ сделать это автоматически:

$ openssl rand -base64 6

Никаких внешних приложений, никаких расширений для веб-браузеров, OpenSSL есть на любой машине. Хотя, если кому-то будет удобней, он может установить и использовать для этих целей pwgen (поговаривают, пароль получится более стойким):

$ pwgen -Bs 8 1

Где хранить пароли? Сегодня у каждого юзера их так много, что хранить все в голове просто невозможно. Довериться системе автосохранения браузера? Можно, но кто знает, как Google или Mozilla будет к ним относиться. Сноуден рассказывал, что не очень хорошо. Поэтому пароли надо хранить на самой машине в зашифрованном контейнере. Отцы-основатели рекомендуют использовать для этого KeePassX. Штука графическая, что не сильно нравится самим отцам-основателям, но зато работает везде, включая известный гугль-зонд Android (KeePassDroid). Останется лишь перекинуть базу с паролями куда надо.

В KeePassX есть свой генератор паролей

Шифруемся

Шифрование — как много в этом слове… Сегодня шифрование везде и нигде одновременно. Нас заставляют пользоваться HTTPS-версиями сайтов, а нам все равно. Нам говорят: «Шифруй домашний каталог», а мы говорим: «Потом настрою». Нам говорят: «Любимое занятие сотрудников Dropbox — это ржать над личными фотками юзеров», а мы: «Пусть ржут». Между тем шифрование — это единственное абсолютное средство защиты на сегодняшний день. А еще оно очень доступно и сглаживает морщины.

В Linux можно найти тонны средств шифрования всего и вся, от разделов на жестком диске до одиночных файлов. Три наиболее известных и проверенных временем инструмента — это dm-crypt/LUKS, ecryptfs и encfs. Первый шифрует целые диски и разделы, второй и третий — каталоги с важной информацией, каждый файл в отдельности, что очень удобно, если потребуется делать инкрементальные бэкапы или использовать в связке с Dropbox. Также есть несколько менее известных инструментов, включая TrueCrypt например.

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

$ sudo apt-get install ecryptfs-utils

И, собственно, включить шифрование:

$ sudo ecryptfs-setup-swap
$ ecryptfs-setup-private

Далее достаточно ввести свой пароль, используемый для логина, и перезайти в систему. Да, все действительно так просто. Первая команда зашифрует и перемонтирует своп, изменив нужные строки в /etc/fstab. Вторая — создаст каталоги ~/.Private и ~/Private, в которых будут храниться зашифрованные и расшифрованные файлы соответственно. При входе в систему будет срабатывать PAM-модуль pam_ecryptfs.so, который смонтирует первый каталог на второй с прозрачным шифрованием данных. После размонтирования ~/Private окажется пуст, а ~/.Private будет содержать все файлы в зашифрованном виде.

Не возбраняется шифровать и весь домашний каталог целиком. Производительность при этом упадет не сильно, зато под защитой окажутся вообще все файлы, включая тот же сетевой каталог ~/Dropbox. Делается это так:

# ecryptfs-migrate-home -u vasya

Кстати, места на диске должно быть в 2,5 раза больше, чем данных у vasya, так что рекомендую заранее почиститься. После завершения операции следует сразу войти под юзером vasya и проверить работоспособность:

$ mount | grep Private
/home/vasya/.Private on /home/vasya type ecryptfs ...

Если все ок, незашифрованную копию данных можно затереть:

$ sudo rm -r /home/vasya.*

Ecryptfs предупреждает нас

Заметаем следы

ОK, пароли в надежном месте, личные файлы тоже, что теперь? А теперь мы должны позаботиться о том, чтобы какие-то куски наших личных данных не попали в чужие руки. Ни для кого не секрет, что при удалении файла его актуальное содержимое остается на носителе даже в том случае, если после этого произвести форматирование. Наши зашифрованные данные будут в сохранности даже после стирания, но как быть с флешками и прочими картами памяти? Здесь нам пригодится утилита srm, которая не просто удаляет файл, но и заполняет оставшиеся после него блоки данных мусором:

$ sudo apt-get install secure-delete
$ srm секретный-файл.txt home-video.mpg

Как всегда, все просто до безобразия. Далее, если речь идет о всем носителе, то можно воспользоваться старым добрым dd:

# dd if=/dev/zero of=/dev/sdb

Эта команда сотрет все данные на флешке sdb. Далее останется создать таблицу разделов (с одним разделом) и отформатировать в нужную ФС. Использовать для этого рекомендуется fdisk и mkfs.vfat, но можно обойтись и графическим gparted.

# apt-get install fail2ban

# /etc/init.d/fail2ban restart

Угроза извне

Теперь позаботимся об угрозах, исходящих из недр всемирной паутины. Здесь я должен был бы начать рассказ об iptables и pf, запущенном на выделенной машине под управлением OpenBSD, но все это излишне, когда есть ipkungfu. Что это такое? Это скрипт, который произведет за нас всю грязную работу по конфигурированию брандмауэра, без необходимости составлять километровые списки правил. Устанавливаем:

$ sudo apt-get install ipkungfu

Правим конфиг:

$ sudo vi /etc/ipkungfu/ipkungfu.conf
# Локальная сеть, если есть — пишем адрес сети вместе с маской, нет — пишем loopback-адрес
LOCAL_NET="127.0.0.1"

# Наша машина не является шлюзом
GATEWAY=0

# Закрываем нужные порты
FORBIDDEN_PORTS="135 137 139"

# Блокируем пинги, 90% киддисов отвалится на этом этапе
BLOCK_PINGS=1

# Дропаем подозрительные пакеты (разного рода флуд)
SUSPECT="DROP"

# Дропаем «неправильные» пакеты (некоторые типы DoS)
KNOWN_BAD="DROP"

# Сканирование портов? В трэш!
PORT_SCAN="DROP"

Для включения ipkungfu открываем файл /etc/default/ipkungfu и меняем строку IPKFSTART = 0 на IPKFSTART = 1. Запускаем:

$ sudo ipkungfu

Дополнительно внесем правки в /etc/sysctl.conf:

$ sudo vi /etc/systcl.conf
# Дропаем ICMP-редиректы (против атак типа MITM)
net.ipv4.conf.all.accept_redirects=0
net.ipv6.conf.all.accept_redirects=0
# Включаем механизм TCP syncookies
net.ipv4.tcp_syncookies=1
# Различные твики (защита от спуфинга, увеличение очереди «полуоткрытых» TCP-соединений и так далее)
net.ipv4.tcp_timestamps=0
net.ipv4.conf.all.rp_filter=1
net.ipv4.tcp_max_syn_backlog=1280
kernel.core_uses_pid=1

Активируем изменения:

$ sudo sysctl -p

Выявляем вторжения

Snort — один из любимейших инструментов админов и главный фигурант всех руководств по безопасности. Штука с долгой историей и колоссальными возможностями, которой посвящены целые книги. Что он делает в нашем гайде по быстрой настройке безопасной системы? А здесь ему самое место, Snort можно и не конфигурировать:

$ sudo apt-get install snort
$ snort -D

Все! Я не шучу, стандартных настроек Snort более чем достаточно для защиты типовых сетевых сервисов, если, конечно, они у тебя есть. Нужно только время от времени просматривать лог. А в нем можно обнаружить строки типа этих:

[**] [1:2329:6] MS-SQL probe response overflow attempt [**]
[Classification: Attempted User Privilege Gain] [Priority: 1]
[Xref => [url]http://www.securityfocus.com/bid/9407][/url]

Упс. Кто-то пытался вызвать переполнение буфера в MySQL. Тут сразу есть и ссылочка на страницу с детальным описанием проблемы. Красота.

Кто-то наследил…

Кто-то особенно умный смог обойти наш брандмауэр, пройти мимо Snort, получить права root в системе и теперь ходит в систему регулярно, используя установленный бэкдор. Нехорошо, бэкдор надо найти, удалить, а систему обновить. Для поиска руткитов и бэкдоров используем rkhunter:

$ sudo apt-get install rkhunter

Запускаем:

$ sudo rkhunter -c --sk

Софтина проверит всю систему на наличие руткитов и выведет на экран результаты. Если зловред все-таки найдется, rkhunter укажет на место и его можно будет затереть. Более детальный лог располагается здесь: /var/log/rkhunter.log. Запускать rkhunter лучше в качестве cron-задания ежедневно:

$ sudo vi /etc/cron.daily/rkhunter.sh
#!/bin/bash
/usr/bin/rkhunter -c --cronjob 2>&1 | mail -s "RKhunter Scan Results" vasya@email.com

Заменяем email-адрес Васи на свой и делаем скрипт исполняемым:

$ sudo chmod +x /etc/cron.daily/rkhunter.sh

Базу rkhunter рекомендуется время от времени обновлять с помощью такой команды:

$ sudo rkhunter --update

Ее, кстати, можно добавить перед командой проверки в cron-сценарий. Еще два инструмента поиска руткитов:

$ sudo apt-get install tiger
$ sudo tiger
$ sudo apt-get install lynis
$ sudo lynis -c

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

$ sudo apt-get install debsums

Запускаем проверку:

$ sudo debsums -ac

Как всегда? запуск можно добавить в задания cron.

rkhunter за работой

В моей системе руткитов нет

За пределами

Теперь поговорим о том, как сохранить свою анонимность в Сети и получить доступ к сайтам и страницам, заблокированным по требованию различных организаций-правообладателей и прочих Мизулиных. Самый простой способ сделать это — воспользоваться одним из тысяч прокси-серверов по всему миру. Многие из них бесплатны, но зачастую обрезают канал до скорости древнего аналогового модема.

Чтобы спокойно ходить по сайтам и только в случае необходимости включать прокси, можно воспользоваться одним из множества расширений для Chrome и Firefox, которые легко находятся в каталоге по запросу proxy switcher. Устанавливаем, вбиваем список нужных прокси и переключаемся на нужный, увидев вместо страницы табличку «Доступ к странице ограничен по требованию господина Скумбриевича».

В тех ситуациях, когда под фильтр попал весь сайт и его адрес внесли в черный список на стороне DNS-серверов провайдеров, можно воспользоваться свободными DNS-серверами, адреса которых опубликованы здесь. Просто берем два любых понравившихся адреса и добавляем в /etc/resolv.conf:

nameserver 156.154.70.22
nameserver 156.154.71.22

Чтобы разного рода DHCP-клиенты и NetworkManager’ы не перезаписали файл адресами, полученными от провайдера или роутера, делаем файл неперезаписываемым с помощью расширенных атрибутов:

$ sudo chattr +i /etc/resolv.conf

После этого файл станет защищен от записи для всех, включая root.

Чтобы еще более анонимизировать свое пребывание в Сети, можно воспользоваться также демоном dnscrypt, который будет шифровать все запросы к DNS-серверу в дополнение к прокси-серверу, используемому для соединения с самим сайтом. Устанавливаем:

$ wget http://download.dnscrypt.org/dnscrypt-proxy/dnscrypt-proxy-1.3.2.tar.bz2
$ bunzip2 -cd dnscrypt-proxy-*.tar.bz2 | tar xvf -
$ cd dnscrypt-proxy-*
$ sudo apt-get install build-essential
$ ./configure && make -j2
$ sudo make install

Указываем в /etc/resolv.conf loopback-адрес:

$ vi /etc/resolv.conf
nameserver 127.0.0.1

Запускаем демон:

$ sudo dnscrypt-proxy --daemonize

Кстати, версии dnscrypt есть для Windows, iOS и Android.

Луковая маршрутизация

Что такое луковая маршрутизация? Это Tor. А Tor, в свою очередь, — это система, которая позволяет создать полностью анонимную сеть с выходом в интернет. Термин «луковый» здесь применен относительно модели работы, при которой любой сетевой пакет будет «обернут» в три слоя шифрования и пройдет на пути к адресату через три ноды, каждая из которых будет снимать свой слой и передавать результат дальше. Все, конечно, сложнее, но для нас важно только то, что это один из немногих типов организации сети, который позволяет сохранить полную анонимность.

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

Тем не менее Tor очень легко установить и использовать:

$ sudo apt-get install tor

Все, теперь на локальной машине будет прокси-сервер, ведущий в сеть Tor. Адрес: 127.0.0.1:9050, вбить в браузер можно с помощью все того же расширения, ну или добавить через настройки. Имей в виду, что это SOCKS, а не HTTP-прокси.

Tor говорит, что он не HTTP-прокси

INFO

Версия Tor для Android называется Orbot.

Чтобы введенный в командной строке пароль не был сохранен в истории, можно использовать хитрый трюк под названием «добавь в начале команды пробел».

Именно ecryptfs используется для шифрования домашнего каталога в Ubuntu.

$ netstat -na | grep ":порт\ " | wc -l

$ netstat -na | grep ":порт\ " | grep SYN_RCVD | wc -l

$ netstat -na | grep ":порт\ " | sort | uniq -c | sort -nr | less

# tcpdump -n -i eth0 -s 0 -w output.txt dst port порт and host IP-сервера

# iptables -A INPUT -s IP-атакующего -p tcp --destination-port порт -j DROP

# iptables -I INPUT -p tcp --syn --dport порт -m iplimit --iplimit-above 10 -j DROP

# iptables -A INPUT -p icmp -j DROP --icmp-type 8

Выводы

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

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

Цели

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

Какие проблемы есть при защите внешнего периметра? Самое очевидное — дыры, через которые можно получить доступ куда не следует. Но само понятие «дыра» очень абстрактно. Дыры бывают разные — в платформе, в приложениях, в инфраструктуре ЦОДа или облака. Во всех этих сценариях возникают особые задачи. А есть еще и проблемы privacy, важно, где и как мы храним данные, за которые отвечаем. Тут мы должны учитывать и локальное законодательство, и требования регуляторов (скажем, Visa/MasterCard).

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

Процессы

Итак, во внешнем периметре мы имеем некую платформу, некий софт и некие данные. Защищаемым активом здесь являются именно данные пользователей, которые мы обрабатываем, и то, что мы «ограниченно предоставляем» особым клиентам.

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

Кроме того, у нас есть сервисы, по сути — приложения, которые мы разрабатываем и предоставляем, в них могут быть дыры как в коде, так и в логике; плюс есть платформа, которую также нужно поддерживать в «защищенном» состоянии. Для простоты разделим все на процессы и подпроцессы:

1. Поддержка privacy:
   • местное законодательство. Информация и то, как мы с ней работаем, не должна нарушать законов;
   • требования регуляторов. Условия обработки информации могут быть продиктованы не только законами, но и требованиями сторонних сервисов, которые мы используем;
   • специфика бизнеса. В компании могут быть свои правила и свое видение работы с той или иной информацией. Например, если мы производим нечто и предоставляем это пользователям (например, платный контент), то это нечто также надо защищать и это тоже становится защищаемым активом.
2. Анализ рисков:
   • классификация информации;
   • анализ возможных проблем. Потенциальный ущерб и прочие «бумажные» темы, которые становятся актуальными в самый неподходящий момент;
   • оценка ресурсов и целесообразности тех или иных проектов по ИБ или иных решений.
3. Построение архитектуры защиты:
   • оценка attack surface;
   • принятие решений по технической реализации. Алгоритмы, технологии, логика защиты должны учитывать возможные векторы атаки, риски и многие вещи. Это тот самый момент стыка бумажников и технарей :);
   • выработка стандартов для проектов, например HttpOnly, SSL требования к ключам, формат лог-файлов их хранения и так далее.
4. Безопасная разработка кода:
   • автоматизация. Средства сканирования кода, например статические анализаторы, которые встраиваются в цикл производства;
   • обучение персонала. Выработка единого стиля программирования;
   • аудит кода. Для критичных кусков кода при определенных условиях (неминорный патч, новая версия…) необходимо проводить в том числе и ручную проверку кода.
5. Реагирование на инциденты:
   • поддержка систем IDS;
   • bug bounty;
   • работа с CERT;
   • расследование инцидентов;
   • работа в режиме hotfix с R&D.
6. Поддержка ИБ:
   • patch managment;
   • vulnerability mangment;
   • организация локальных ивентов (например, обучать разработчиков принципам безопасной разработки кода).

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

Люди

Итак, кто нужен для нашего проекта? Какая она, идеальная команда?

Директор

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

Менеджер

Когда бумаг много, процессов тоже становится много и нужен кто-то, кто будет решать задачи на уровне менеджмента всего этого: что в первую очередь, что во вторую, что у нас еще не сделано, а что делается медленно, как переложить ресурсы и где их слишком много. Это абстрактно, конечно, и зависит от конкретной команды, но менеджер — этот тот, кто помогает все держать связанным по времени, срокам и прочим бумажным вопросам. Их может быть несколько в зависимости от размеров работы. Сюда, в принципе, можно внести любого «бумажника», который решает определенные задачи на уровне «надо, чтобы было так», но и который бы понимал, как это сделать на верхнем уровне (задачи 1, 2, 6 — построение процессов, и их планирование весьма тяжелый труд).

Технический персонал

Архитекторы, инженеры ИБ идут последними в списке, но именно это самый ценный ресурс. В нормальной команде все держится на их экспертизе, навыках и заключениях. Ни один менеджер или директор не скажет «давайте внедрять то или это» или «риск тут именно такой» без того, чтобы инженер не ПОДТВЕРДИЛ истинность вышесказанного. Потому что менеджеры мало знают о реальных рисках, атаках, уязвимостях… они берут то, что им говорят инженеры и консультанты (если своих инженеров нет). Именно инженеры ИБ смогут точно оценить тонкие риски, связанные с IT, выявить уязвимости как в логике, так и в коде, проводить работы по анализу логов систем ИДС, и вообще это ниндзя (задачи 1, 2, 3, 4, 5, 6 — да эти люди вовлечены во все процессы, если подумать).

В итоге идеальная команда, где менеджеры помогают техперсоналу — инженерам, архитекторам и прочим хакерам своего отдела — координировать их работу и процессы, ну и ресурсы, а те, в свою очередь, помогают менеджеру быть в теме и достигать цели. Директор же контролирует эффективность и счастье бизнеса в целом и команды ИБ в частности, как свое дитя. Тогда эффективность будет расти, а цели достигаться, причем реальные цели, а не отписки. Конечно, проблемы будут всегда и везде, главным образом — далеко не все могут позволить себе иметь такую команду, и даже далеко не всегда она целесообразна. Но все же иметь технаря ИБ в довесок к грамотному менеджеру ИБ сильно повысит адекватность вашей СУИБ, причем в разы. Можно очень тонко комбинировать аутсорс-услуги с применением собственных сил, в зависимости от задач и поставленных процессов, но нельзя полностью уходить на растерзание консультантов и интеграторов. Это чревато потерей контроля над ситуацией и зависимостью от сторонней компании в важных процессах.

Зачем?

Что же я хотел сказать всем этим? Не скидывайте задачи ИБ в довесок к разработчикам и системным инженерам, если это не часть процесса (например, самоконтроля и правил разработки кода). Но не надо доверять всю техническую часть консультантам со стороны и интеграторам. Если есть менеджер, но ему нечего менеджить, кроме как проекты с интеграторами и аутсорсерами, — это грустно.

Интеграторы и прочие сторонние консультанты заинтересованы в продаже своих услуг. Это не значит, что они не нужны в принципе, — просто надо знать возможности и цену любой работе. Например, проще нанять одного инженера, чтобы он внедрил IDS и настроил правила именно под твою систему, чем нанимать интегратора, который внедрит систему из коробки, а та будет реагировать на кучу false positive, и придется покупать у них еще и мониторинг ивентов как аутсорс.

К тому же часто интеграторы хотят внедрить «несколько» больше дорогих штучек, чем нужно тебе, но так как у тебя нет понимания того, что именно нужно (нет инженеров, архитекторов), то придется верить своему интегратору. Я знаю случаи, когда крупный банк после найма интегратора нанимал стороннего консультанта, чтобы тот оценил адекватность интегратора, и как бы стравливал их. Что ж, главное — платите деньги, а там любые извращения доступны!

Так что посыл мой таков: ИБ — это люди, которые ответственны, профессиональны и инициативны на всех уровнях, будь то бумажная ИБ или IT Security, и комбинация таких людей в вашей команде — залог успеха и счастья :).

Компания Microsoft опубликовала минимальные системные требования для новой операционной системы Windows 10. Они не отличаются от системных требований для Windows 8. В свою очередь, требования Windows 8 не отличались от Windows 7 и Windows Vista. Это одноядерный процессор с тактовой частотой от 1 ГГц и 1 ГБ оперативной памяти.

Когда Windows Vista вышла в январе 2007 года такие системные требования казались чрезмерными, но уже с выходом Windows 7 в 2009 году они стали вполне приемлемыми, а на данный момент практически каждый компьютер подходит для установки Windows 10.

Microsoft предпочла не повышать минимальные системные требования с выходом Windows 8, чтобы сделать операционную систему доступной для мобильных устройств. Сейчас компания приняла такое же решение.

В прошлое время существовало мнение, что Microsoft искусственно завышает системные требования для Windows, чтобы стимулировать продажи новых процессоров своего партнёра Intel. Если это было правдой, то сейчас партнёрство, очевидно, расторгнуто.

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