Блог Александра Башкирова

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

информационная безопасность

Подписаться на эту метку по RSS

Статья на Хабре: Как восстановить утерянный пароль к архиву с помощью видеокарты

Просмотров: 1374Комментарии: 0
Alib.spb.ru

Статья на Хабре с интригующим названием "Как восстановить утерянный пароль к архиву с помощью видеокарты". Если опустить технические подробности, то статья о том, что пароли на архивы - не настолько стойки, как хотелось бы. И в принципе, "ломаются" за 2..3 дня максимум на не самом крутом "железе".

Сама статья вот: https://habrahabr.ru/company/infowatch/blog/352396/

  1. Приведу выдержку из статьи, фактически рекомендации по тому, какие стоит использовать и не использовать пароли:
  2. Не использовать общие слова из ежедневного употребления. Их всего-то несколько тысяч.
  3. Не использовать слова, после которых стоят цифры или буквенные ряды на клавиатуре. Добавив 1231231 к Qwerty, вы не сделаете пароль более защищенным. Весь словарь и маски можно перебрать за полдня.
  4. Стандартные комбинации удваивания слов и т.д. легко разбираются правилами подбора, которые ориентированы на такие приемы.
  5. Не использовать личную информацию. В нашем мире слишком много информации в общем публичном доступе.

То есть пароль PassWorD987 подбирается легко и изящно. А вот комбинация типа As@2Fg:1fr% - может оказаться довольно стойкой. Хотя... как я понял из статьи, вопрос времени всего лишь.

Пост про то, как надо писать ТЗ

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

И часто встречается ситуация, когда в роли ТЗ выступает все, что угодно... кроме, собственно, ТЗ. Почему так? Да потому, что ТЗ - это задание, на основании которого должна быть подготовлена система автоматизации. Не более - но и не менее. В роли ТЗ в общем случае не могут выступать прототипы экранов, список пожеланий и т.д. - потому что в итоге получится нечто, соответствующее ТЗ - но полностью или частично не соответствующее ожиданиям заказчика. Как избежать такой радостной ситуации?

Во-первых, всегда помнить - система, разрабатываетмая по ТЗ, автоматизирует процесс (напомню, речь идет о ТЗ на информационную систему - от интернет-магазина до ERP). Соответственно, в ТЗ обязан быть прописан процесс, который автоматизируется. Иного просто не дано: не понимая процесса, невозможно описать систему.

Второй аспект: ТЗ должно описывать результат "на выходе". И из этого следует еще один очень важный вывод: в ТЗ должны присутствовать варианты использования системы. То есть, должно быть описано, кто (какая роль) выполняет какой надор действий в системе. Да, и это должно коррелироваться с процессами, которые система автоматизирует.

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

Дальше имеет смысл расписать требования к формам и дизайну. Требования к формам, в идеале - это выделение критически важной информации длдя процесса, с анализом - когда, кто и в каком объеме поставляет нужную информацию. Требования к дизайну тут получаются вроде бы как не очень логичны... но логичны, потому что важно не только то, что будет нести форма в себе - но и то, как она будет выглядеть. Хотя требования к дизайну можно вообще поставить в конец ТЗ, или сделать ссылку на brandbook - тут вариантов масса.

Следующее, что нужно для разработки ИС - определить этапность. Что делаем и что запускаем в первую очередь, что - во вторую и т.д. Это очень важно - так как позволяет четко очертить пожелания Заказчика к тому, что должно работать в первую очередь, а что должно быть запущено в последнюю очередь. Кстати, если есть сроки - то им место тут же.

Дальше, собсвтенно, если есть понимание на какой базе строим ИС - нужно расписать это. Если ИС создается "с нуля" (бывает и такое) - то указать, на каком яыке она пишется, какие библиотеки требует и т.д.

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

Дальше, нужно описать, что надо будет сделать, чтобы ввести систему в эксплуатацию.

Дальше приводятся так называемые "потребительские характеристики системы" (время отклика, число кликов по основным операциям и т.д.). И приводится то, что влияет на эти характеристики - например, конфигурацию серверного оборудования, операционные системы, лицензии и т.д.

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

Финальным аккордом нужно описать процедуру приемки-передачи системы (в целом и по каждоому этапу). А также привести требования к информационной безопасности.

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

В общем, получился почти на тему "как написать ТЗ" :) И, прошу отметить - никакого ГОСТа. Хотя структура получилась в чем-то похожей на то, что трбует ГОСТ 34 от ТЗ. Но, наверное, его проектировали, исходя из аналогичных (или в чем-то похожих) соображений.

Tor: анонимность в Интернет

Вспомнил молодость. Когда-то, давным-давно, мне надо было "ходить" по Сети так, чтобы меня не могли отследить большинством традиционных методов - по IP, Cookie и т.д. Именно тогда я набрел на интересную сеть - TOR, основная направленность которой - анонимность её участников. Сеть построена по децентрализованному распределённому принципу, на добровольных началах, и, как следствие - постоянно нуждается в финансировании (о чем прямо заявлено на сайте проекта).

Так вот, когда я впервые столкнулся с TOR, меня поразило обилие шаманских действий при скудной документации, которые надо было производить для того, чтобы получить работающий TOR, и, как следствие - некоторую защиту. Через некоторое время процесс упростился: появилась Opera with TOR (то есть opera с интегрированным tor клиентом). Кстати, opera + tor - яркий пример того, как не стоит называть приложения и проекты. При поиске в Google по этому запросу выдается ссылка на описание ... оператора, ага. Так вот, в течение нскольких лет я не заходил на сайт TOR, а намедни зашедши - был приятно удивлён, тем, что

  • у сайта и небольшой части документации появился русский язык
  • появился плагин под firefox, который превращает использование tor под windows в необременительное занятие;
  • появился gui инсталлятор под windows;
  • появилась инструкция по установке и использованию tor под linux (небольшая, кстати - всего 3 или 4 шага кажется);

Но самое интересное - на сайте появились разъяснения относительно того, что может и что не может tor, когда и как он защищает и т.д., написанные для пользователей, не обладающих серьёзными знаниями в области сетевых технологий.

В общем, любителям приватного серфинга - welcome: http://www.torproject.org/index.html.ru

PS. Мааленькая цитата для специалистов:

...Tor обеспечивает защиту за счёт маршрутизации вашего сетевого трафика по распределённой сети серверов запущенных добровольцами со всего мира...

В переводе с "русского на русский" - tor это гигансткая сеть по обмену IP адресами. И все. О чем честно заявлено на сайте проекта:

...Tor защищает только те сетевые приложения, которые посылают свой трафик через Tor...
...Плагины браузера, такие как Java, Flash, ActiveX, RealPlayer, Quicktime, Adobe PDF и другие, могут раскрыть ваш IP адрес...
...Если ... сайт выдал вам cookie, то этот сайт сможет узнать вас по этому cookie даже во время последующего использования Tor...
...Tor анонимизирует источник вашего трафика, и шифрует всё внутри сети Tor, но он не может зашифровать ваш трафик между сетью Tor и конечным получателем...

Мораль? 100% защиты нет, и не надейтесь:) Но при соблюдении некоторых простых правил можно обеспечить относительно анонимный серфинг с использованием tor.

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

Введение в ИТ безопасность.

Просмотров: 7801Комментарии: 0
Статьи

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

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

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

Таким образом, угрозы информационной безопасности предприятия можно условно разделить на несколько классов:

  • Угрозы нарушения доступности
  • Угрозы нарушения целостности
  • Угрозы нарушения конфиденциальности

Угрозы нарушения доступности – это угрозы, связанные с увеличением времени получения той или иной информации или информационной услуги. Нарушение доступности представляет собой создание таких условий, при которых доступ к услуге или информации будет либо заблокирован, либо возможен за время, которое не обеспечит выполнение тех или иных бизнес-целей. Рассмотрим пример: в случае выхода из строя сервера, на котором расположена требуемая для принятия стратегического решения информация, нарушается свойство доступности информации. Аналогичный пример: в случае изоляции по какой-либо причине (выход из строя сервера, отказ каналов связи и т.д.) почтового сервера можно говорить о нарушении доступности ИТ услуги «электронная почта». Особо следует отметить тот факт, что причина нарушения доступности информации или информационной услуги не обязательно должна находиться в зоне ответственности владельца услуги или информации. Например, в рассмотренном выше примере с нарушением доступности почтового сервера причина (отказ каналов связи) может лежать вне зоны ответственности администраторов сервера (например, отказ магистральных каналов связи). Также следует отметить, что понятие «доступность» субъективно в каждый момент времени для каждого из субъектов, потребляющих услугу или информацию в данный момент времени. В частности, нарушение доступности почтового сервера для одного сотрудника может означать срыв индивидуальных планов и потерю контракта, а для другого сотрудника той же организации – невозможность получить выпуск свежих новостей.

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

Угрозы нарушения конфиденциальности – это угрозы, связанные с доступом к информации вне привилегий доступа, имеющегося для данного конкретного субъекта. Подобные угрозы могут возникать вследствие «человеческого фактора» (например, случайное делегировании тому или иному пользователю привилегий другого пользователя), сбоев работе программных и аппаратных средств.

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

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

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

На уровне физического доступа к данным рассматриваются механизмы защиты данных от несанкционированного доступа и механизмы защиты от повреждения физических носителей данных. Защита от несанкционированного доступа предполагает размещения серверного оборудования с данными в отдельном помещении, доступ к которому имеет лишь персонал с соответствующими полномочиями. На этом же уровне в качестве средств защиты возможно создание географически распределенной системы серверов. Уровень защиты от физического повреждения предполагает организацию различного рода специализированных систем, предотвращающих подобные процессы. К их числу относят: серверные кластера и back-up (резервного копирования) сервера. При работе в кластере (например, двух серверов) в случае физического отказа одного из них второй будет продолжать работу, таким образом работоспособность вычислительной системы и данных не будет нарушена. При дополнительной организации резервного копирования (back-up сервера) возможно быстрое восстановление вычислительной системы и данных даже в случае выхода из строя второго сервера в кластере.

Уровень защиты от логического доступа к данным предполагает защиту от несанкционированного доступа в систему (здесь и далее по тексту под системой понимается ИТ система, предназначенная для порождения, хранения и обработки данных любого класса – от простых учетных систем до решений класса ERP) как на уровне баз данных, так и на уровне ядра системы и пользовательских форм. Защита на этом уровне предполагает принятие мер по предотвращению доступа к базе данных как из Интернет, так и из локальной сети организации (на последний аспект обеспечения безопасности традиционно обращается мало внимания, хотя этот аспект напрямую связан с таким явлением, как промышленный шпионаж). Защита ядра системы предполагает, наряду с обозначенными выше мерами, вычисление контрольных сумм критических частей исполнимого кода и периодический аудит этих контрольных сумм. Подобный подход позволяет повысить общую степень защищенности системы. (Следует отметить, что указанное мероприятие не является единственным; оно приводится как удачный пример). Обеспечение безопасности на уровне пользовательских форм декларирует обязательное шифрование трафика, передающегося по локальной сети (или через Интернет) между клиентом (пользовательской формой) и приложением (ядром системы). Также безопасность на этом уровне может обеспечиваться вычислением контрольных сумм этих форм, с последующей их проверкой, принятием идеологии «разделения данных и кода». Например, система, построенная по технологии «тонкого клиента» с позиций обеспечения безопасности на данном уровне имеет преимущество перед системой, построенной по технологии «толстого клиента», поскольку на уровне пользовательских форм не предоставляет доступа к коду бизнес-логики (например, путем дизассемблирования исполняемого файла). К этому же уровню защиты относится механизм сертификации, когда в обмене между пользовательской формой и сервером, а также подлинность самой пользовательской формы подтверждается третьим участником обмена – центром сертификации.

Аналогично, на уровне защиты от логического доступа на уровне баз данных доступа целесообразно вычислять контрольные суммы критически важных таблиц, и вести журнал учета доступа объектов к базе данных. В идеальном случае («тонкий клиент») доступ к базе данных имеет лишь серверное приложение (сервер бизнес-логики), а все остальные (сторонние) запросы к БД блокируются. Подобный подход позволит исключить несколько типов атак и сконцентрировать политику защиты БД на обеспечении безопасности «по критическим точкам».

К защите на уровне административных решений относят административные меры, направленные на создание четкой и понятной политики в отношении ИТ, ИС, информационной безопасности и т.д. Можно сказать, что данный уровень является по отношению к пользователю первичным – поскольку именно защита на уровне административных решений способна предотвратить большинство критических ситуаций, связанных с информационной безопасностью.

Следует рассмотреть еще два важных вопроса, связанных с безопасностью – методы и средства аутентификации пользователей и протоколирование событий, происходящих в ИС.

Аутентификация пользователей относится к логическому уровню обеспечения информационной безопасности. Цель этой процедуры состоит в том, чтобы во-первых, сообщить ИС, какой именно пользователь работает с ним, для предоставления ему соответствующих прав и интерфейсов; во-вторых, подтвердить права данного конкретного пользователя по отношению к ИС. Традиционно процедура аутентификации сводится к вводу пользователем имени пользователя (логина) и пароля.

Довольно часто, в критически важных приложениях, форма ввода имени пользователя/пароля представляет собой работающее в защищенном программном (реже – аппаратном) тоннеле приложение, безусловно шифрующее всю передающуюся по сети информацию. К сожалению, наиболее частой является ситуация, когда имя пользователя и пароль передаются по сети в открытом виде (например, по этому принципу работают большинство известных бесплатных почтовых систем в сети Интернет). Кроме программных (ввод комбинации имя пользователя/пароль) существуют и программно-аппаратные и аппаратные решения для аутентификации пользователей. К ним относятся дискеты и USB-носители с ключевым файлом (довольно часто – в комбинации с вводом обычного имени/пароля, для подтверждения полномочий на критичные действия), защищенным от копирования; однократно записываемые USB-носители с ключевым файлом; сканеры радужной оболочки глаза; сканеры отпечатков пальцев; системы антропологии. Одним из вариантов повышения степени защиты ИС является ограничение времени действия пароля и ограничение времени бездействия пользователя в ИС. Ограничение времени действия пароля представляет собой выдачу пароля, который действует лишь определенное число дней – 30, 60 и т.д. Соответственно, с периодической сменой паролей повышается степень защищенности ИС в целом. Ограничение времени бездействия пользователя предполагает автоматическое закрытия сеанса пользователя в случае, если в этом сеансе не была зафиксирована пользовательская активность в течении определенного периода времени.

Протоколирование всех событий, происходящих в ИС, необходимо для получения четкой картины о попытках несанкционированного доступа, либо по неквалифицированным действиям персонала по отношению к ИС. Частой ситуацией является введение в ИС специализированных модулей, анализирующих системные события, и предотвращающих деструктивные действия по отношению к ИС. Подобные модули могут работать, исходя из двух предпосылок: обнаружения вторжений и предотвращение превышения доступности. В первом случае модули статистически анализируют типичное поведение пользователя, и выдают «тревогу» в случае заметных отклонений (например, работа оператора в 22-30 первый раз за два года является безусловно подозрительной); во втором случае на основе анализа текущего сеанса работы пользователя пытаются предотвратить потенциально деструктивные действия (например, попытку удаления какой-либо информации).

Примечание:

ИБ – информационная безопасность

ИТ – информационные технологии

ИС – информационные системы или информационная система (по контексту)