Иллюстрированный самоучитель по разработке безопасности

Введение

Эта книга разбита на четыре части. Ниже представлено их содержимое.

Часть I. Начало работы по правилам.

В главе 1 "Что собой представляет политика информационной безопасности" описывается основная идея правил информационной безопасности и насколько важна их разработка. Правила безопасности подобны плану управления проектом, в котором рассматриваются детали реализации. В главе 1 также обсуждаются обязанности руководства по определению и внедрению правил безопасности, а также обязанности по их разработке. Ко всему необходимо подходить с "должной осмотрительностью". Что же касается инцидентов, то в случае расхождения взглядов на них со стороны администрации и правоохранительных органов отсутствие тщательно задокументированных и внедренных правил может вызвать неприятное судебное разбирательство.

В главе 2 "Определение целей политики" и главе 3 "Обязанности в области информационной безопасности" вводятся основы разработки правил информационной безопасности. В главе 2 говорится о том, что разработчики правил безопасности прежде, чем приступить к их разработке, должны четко определить, что именно необходимо защищать. Кроме того, в этой главе описано, какими должны быть правила безопасности для конкретной системы. В главе 3 определяются роли и обязанности сотрудников в области безопасности организации. Акцент делается на обязанностях руководства и роли тех лиц, которые будут стоять на переднем крае проведения в жизнь политики безопасности. Определение этих групп сотрудников необходимо для успеха программы безопасности. В конце главы обсуждаются вопросы проведения инструктажа и другие меры поддержки процесса внедрения правил безопасности.

Часть II. Разработка правил безопасности.

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

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

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

В главе 7 "Правила безопасности электронной почты" обсуждаются сложные вопросы зашиты электронной почты. Большое количество судебных дел связано с использованием электронной почты в корпоративных объединениях. По причине того, что электронная почта является электронным эквивалентом почтовых отправлений, при разработке правил безопасности требуются особые решения. Организации необходимо рассмотреть множество вопросов при разработке правил безопасности, начиная с инструкций по архивированию и заканчивая процедурами, определяющими содержание сообщений.

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

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

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

Часть III. Сопровождение правил.

В главе 11 "Правила надежной работы" обсуждается важность внедрения правил надежной работы (Acceptable Use Policies – AUPs), а также способы включения в этот документ и других правил. AUP представляет собой документ, в котором собраны все правила безопасной работы пользователей. Обычно, это утвержденный документ, в котором описывается ответственность служащих, подрядчиков и поставщиков в отношении обеспечения безопасности при их доступе к сети организации.

После того, как правила написаны, необходимо определить, кто будет их внедрять. Какие меры нужно принимать при нарушениях правил? Кто будет определять эти меры? В главе 12 "Согласование и внедрение" обсуждаются эти и другие вопросы, которые читатель должен рассмотреть, прежде чем заняться разработкой правил.

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

Часть IV. Приложения.

В приложениях представлена дополнительная информация, которая поможет при осмыслении информационной безопасности вообще и конкретно при разработке отдельных правил. В приложении А "Глоссарий" разъясняется терминология, используемая в данной книге. В приложении Б "Ресурсы" представлены дополнительные источники информации для тех, кому необходима более подробная информация. Здесь также представлены адреса Web-узлов, на которых обсуждаются общие и специфические вопросы безопасности. И, наконец, в приложении В "Примеры правил" представлены образцы правил безопасности, которые можно использовать в качестве "козы" при разработке собственных правил.

Если Вы заметили ошибку, выделите, пожалуйста, необходимый текст и нажмите CTRL + Enter, чтобы сообщить об этом редактору.