Использовать только лицензионное ПО
Тестирование, отладка, документирование
5. ПО СПОСОБУ ВОЗДЕЙСТВИЯ НА ОБЪЕКТ АТАКИ
5.1 Непосредственное воздействие на объект атаки
5.2 Воздействие на систему разрешений
Политика разграничения прав доступа, а именно при вводе нового субъекта, перемещении или увольнении, а также при временном замещении одного субъекта другим
ОРМ по защите пароля
Для администрирования необходимо иметь дополнительный пароль
5.3 Опосредованное воздействие
6. ПО СПОСОБУ ВОЗДЕЙСТВИЯ
6.1 В интенсивном режиме
Использование МСЭ
Использование СОА в сети и на сервере
6.2 В пакетном режиме
Наличие эталонных копий на неизменяемые части, к примеру, для создаваемой системы - эталон на схему БД
7. ПО ОБЪЕКТУ АТАКИ
7.1 На АСОИ в целом через механизм доступа
Наличие одной точки информационного входа в периметр безопасности и её защита при помощи МСЭ
Мониторинг и аудит
Использование сканера уязвимостей
Использование СОА в сети
Наличие эталонных копий на неизменяемые части.
7.2 На объекты АСОИ
на клиенте:
Наличие резерва (временный переход на другую рабочую станцию)
Ремонт/замена
на сервере:
Использование RAID-массива уровень 10
Наличие резервных HDD
в ЛВС:
Наличие резерва (дублирование линий коммуникаций)
7.3 На субъекты АСОИ
при воздействии на пользователя:
Повышение требований на использование паролей (ОРМ)
при воздействии на процессы пользователя:
7.4 На каналы передачи данных
8. ПО ИСПОЛЬЗУЕМЫМ СРЕДСТВАМ АТАКИ
8.1 С использованием штатного ПО АСОИ
Использовать только лицензионное ПО
Обновление функционирующего ПО, отслеживание появления новых «дыр», атак и т.п.
Тестирование, отладка, документирование
8.2 С использованием разработанного ПО
9. ПО СОСТОЯНИЮ ОБЪЕКТА АТАКИ
9.1 При хранении объекта
Наличие резервных копий
Регламент по восстановлению системы после аварии/сбоя
Наличие инсталляционных пакетов с сопроводительной документацией
9.2 При передаче объекта
9.3 При обработке объекта
6. Аварийный план
Аварийный план служит ответом на ряд важных вопросов: Какие причины возникновения аварий/сбоев существуют? Что делать, чтобы снизить возможные последствия аварии? Какие действия выполнять, когда аварийная ситуация находится в стадии развития? Как вернуться к обычной деятельности?
Самое неприятное - это сбои, которые сложно правильно диагностировать и, следовательно, найти способы их устранения. Поражения или разрушения создают более однозначную и поэтому более предсказуемую и планируемую ситуацию. Возможные причинами этих бед являются выход из строя или сбой оборудования, авария электропитания, вирусы, неквалифицированные или небрежные действия обслуживающего персонала, скрытые или явные дефекты информационной системы, стихийные бедствия, злой умысел.
Поэтому для начала необходимо классифицировать возможные события с целью дальнейшего определения последовательности действий восстановления:
1. По типу воздействия:
природные события;
события, зависящие от человеческого фактора;
2. По доступности:
временная недоступность;
постоянная недоступность;
3. По причине возникновения:
нарушение или отказ оборудования/ повреждение линий связи;
нарушение или отказ программ;
нарушение или отказ данных.
Необходимо также оценить объекты по приоритетам восстановления. Для упрощения процесса рассмотрим бизнес-логику организации с верхнего уровня:
Основная цель организации – доставка газа до потребителя и получение оплаты за него;
Обслуживанием потребителей занимаются сотрудники организации;
Учет поставки газа конечному потребителю и учет оплаты осуществляется с помощью автоматизированных систем;
Автоматизированные системы требует приложений и данных;
Приложения и СУБД требуют операционной системы и коммуникаций;
Операционная система требует аппаратного обеспечения;
Коммуникации требуют сетевого обеспечения;
Оборудование требует электропитания и охлаждения;
Электропитание требует источника и средств доставки;
Сотрудники требуют определенных условий труда (помещение, освещение).
Соответственно, при рассмотрении нештатных ситуаций, необходимо для приведенного списка, начиная с последнего пункта, рассмотреть последовательность действий восстановления деятельности организации. При этом после катастрофы для восстановления бизнеса не все информационные/автоматизированные системы потребуются незамедлительно. Необходимо классифицировать системы с точки зрения аварийного плана по их значимости. Ниже приведен список информационных систем, используемых в организации с критерием значимости:
1. Критически важные:
ПК «Реализация газа»;
АИС «Абонент ГРО»;
2. Для вторичных и вспомогательных бизнес-задач:
Создаваемая для ОДС система учета основных объектов и устройств МГ и ГРС;
3. Некритические (но значимые):
1:С Предприятие;
4. Полезные:
Антивирусный комплекс.
В рамках курсового проекта будем рассматривать этапы восстановления относительно создаваемой информационной системы.
Для успешного восстановления информационной системы в максимально возможные короткие сроки в распоряжении организации следует иметь:
Резерв сетевого оборудования (линий передачи данных/конекторы/сетевые интерфейсы и т.п.);
Резерв аппаратного оборудования, либо иметь соглашение с поставщиками об оперативной поставке оборудования;
Инсталляционные копии операционной системы, СУБД, приложения и других программ;
Резервные копии данных (для разрабатываемой системы следует применять резервирование методом наращивания).