Основные принципы

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

прозрачность
Вопреки распространенному мнению, самая безопасная система одна, где каждый может видеть каждый аспект его и до сих пор не может сломаться в. Представьте себе сейф, где даже с чертежами вы не можете найти способ, чтобы получить его открытым. Этот принцип один отражается в истории информационной безопасности и криптографии. бесплатные программные системы с открытым исходным кодом и имеет послужной список быстро фиксации проблемы безопасности с такими системами, как OpenBSD, имеющие репутацию тяжелой безопасности. Криптографические алгоритмы, такие как ECDSA (на которых в значительной степени на основе Bitcoin) открыты для осмотра всех, и именно это дает им силу. Более подробную информацию о принципе прозрачности и почему полное раскрытие является идеальным мы отсылаем вас к этой замечательной статье Брюс Шнайер: Полное раскрытие безопасности Уязвимости а 'Чертовски хорошая идея.

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

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

паранойя
Шифровать все, использование запрета по умолчанию на всех брандмауэрах, блокировать списки контроля доступа и доступ к файловой системе, ограничить системные вызовы на процессы демона и доверия никому. Мы предполагаем, что 24/7, кто активно пытается проникнуть в нашу систему, и отчаянно пытается сделать это. Это предположение гарантирует, что в случае, когда плохие парни не так активна наша система встает.

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

Конкретные практики

сканирование безопасности Multiple поставщика
В настоящее время мы используем следующее программное обеспечение и услуги для аудита наших систем: Nessus, Nikto, Snort IDS, checksecurity, TrustGuard сканирование PCI, HackerTarget, птар, натяжной. Эти инструменты работают на ежедневной основе, где это возможно, и какие-либо недостатки, обнаруженные рассматриваются сразу после аудита. В дополнении к ручной проверке, наши сервера ежедневно cronjob, что обеспечивает актуальную информацию и показатели, относящихся к производительности и безопасности. Для предотвращения возможного ущерба от атакующего системы и покрывающие их треки, эти отчеты по электронной почте нашим сотрудникам и резервируются в зашифрованной форме на Amazon S3. Хэш сохраняются в логах с использованием различных алгоритмов (MD5 и SHA512) и регулярные проверки сделаны, что никаких изменений не было сделано.

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

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

Управление Исходный код и конечного пользователя программного обеспечения
Как и любой онлайн-сервис, наше программное обеспечение, что полномочия все. Для каждого фрагмента кода, мы спрашиваем, будет ли это безопасно выпустить этот код для широкой публики или, если это откроет дыры в безопасности, и если отпускание откроет дыры в безопасности, то перепишем его. В качестве поставщика услуг, чей бизнес продает услугу, а не программное обеспечение, включить его, мы не требуем от наших клиентов, чтобы запустить специальное программное обеспечение, кроме современного веб-браузера (мы даже не требует JavaScript - наш сайт будет вообще работать без него, хотя мы рекомендуем это разрешено для простоты использования). Поскольку мы не требуем от наших клиентов, чтобы запускать любое программное обеспечение, мы ограничим наше внимание на сторону сервера и малый класс потенциальных атак против яваскрипта и HTML (XSS и атак инъекций). Наши клиенты могут свободно изучать и проверять любые JavaScript или HTML, посланные нашего веб-сервера и гарантировать, что нет никаких недостатков безопасности, и если какие-либо недостатки обнаружены мы рекомендуем клиент сообщить поддержку.

По умолчанию запретить
Любой из наших систем установлен межсетевой экран с по умолчанию в том, чтобы запретить любые и все соединения. Этот хост межсетевой экран в дополнение к любому потоку брандмауэра, предоставляемых нашим хостинг-провайдера (для контроля за сценарием, в котором скомпрометированы наш хостинг-провайдер). Такой же "запрет по умолчанию" философия относится к файловой системе привилегий и ACL. Всякий раз, когда компонент системы может быть настроен отрицать все по умолчанию, мы делаем это и белый список конкретных разрешено использование.

Мониторинг аномалии системного журнала
Во время обычной работы существуют различные записи журнала, написанные на сервере Linux. Эти записи журнала делятся на 3 основные категории в отношении безопасности. Законное использование, "фоновый шум" и аномалии. определим "фоновый шум" как бесплодные попытки ботнетов и лицами с сканерами портов, чтобы попытаться ворваться в любой хост IP они приходят через, как правило, в виде словарных атак. Фоновый шум в основном раздражение, но мы не рисковать и так IP блоки, из которых этих виды попыток происходят автоматически блокируются нашим брандмауэром. Аномалии целенаправленные попытки или запросы, отправленные на наших серверах, которые не являются ни частью нормального использования или фонового шума. Мы предполагаем, что все аномалии, попытка ворваться и блокировать IP-адреса отправки таких запросов, прежде чем анализировать запросы, чтобы посмотреть на то, что использует (если таковые имеются) были предприняты. Мы предполагаем, что такие попытки будут успешными до проведения проверки не проверить, что они не были.

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

Нет конфигурации производства в системе управления версиями
Мы используем систему подрывная версия управления для разработки кода, но мы используем в .dist шаблон дизайна, в котором файлы конфигурации с именем (например) "importantstuff.cfg.dist" скорее, чем "importantstuff.cfg", Затем мы устанавливаем подрывную игнорировать простые .cfg файлы и выполнять регулярные проверки, чтобы гарантировать, что они никогда не делают свой путь в системе управления версиями. При изменении кода требуется слияние старого файла конфигурации, это делается вручную. Следуя этот образец, мы гарантируем, что если наше хранилище SVN быть скомпрометировано это не приведет к раскрытию важной информации о конфигурации сервера.

Лечение всех ошибок как потенциальные бреши безопасности
Наш код веб-приложение регистрирует HTTP 500 ошибок, вызванных исключениями или других проблем в базовом коде и эти журналы по электронной почте для поддержки в дополнение к генерированию поддержки билетов, которые рассматриваются с высоким приоритетом. Это также позволяет нам быстро реагировать в случае возникновения проблем, влияющих на операцию клиентов, и в теории решения вопросов до того, как клиент, даже есть время, чтобы связаться со службой поддержки по отдельности.