Как, используя диверсионный анализ ТРИЗ, найти критическую уязвимость, грозящую безопасности SAP HANA
ТРИЗ — методология сильного инженерного мышления, ориентированная на целенаправленную, системную выработку инновационных идей (решение технических проблем) при совершенствовании систем
различной природы. ТРИЗ — аббревиатура от ее исторического названия: Теория Решения Изобретательских
Задач.
Введение в метод
Суть и назначение метода
Диверсионный анализ (иначе — Инверсионный Метод) — это один из разделов ТРИЗ1, направленный на выявление и предотвращение вредных явлений в системах различного генезиса — технических, информационных, организационных [6].
Суть метода заключается в том, чтобы снять психологический барьер при выявлении причин вреда путем инвертирования задачи — замены вопроса: «Как найти причину вреда в системе?» на обратный (инвертированный) вопрос: «Как создать вред в системе?» Фактически речь идет о том, чтобы мыслить как «диверсант» и спроектировать «системную диверсию», взломать систему, найдя в ней узкие места — отсюда первое название метода.
Метод позволяет выявить явные и скрытые причины возможных отказов, уязвимостей, рисков, иных вредных явлений в системе. Тем самым появляется возможность спрогнозировать и предотвратить проявление проблем такого рода, предусмотрев соответствующие меры при разработке или модификации системы. Таким образом, метод применяется:
- для поиска причин вредных явлений;
- для прогнозирования возможных вредных явлений.
Соответственно, используются два специализированных подхода:
- Инверсионный Анализ, предназначенный для целенаправленного выявления рисков и определения скрытых механизмов отказов, уязвимостей, сбоев, брака, аварийных ситуаций и других негативных явлений [9, 3].
- Инверсионный Прогноз, обеспечивающий мощную методическую поддержку прогнозирования нежелательных явлений, которые могут появиться у предприятия в будущем; он особенно эффективен при генерации прогнозных гипотез и сценариев, упрощая при этом оценку присутствующих в них рисков [10, 4].
Описываемый здесь случай решался с помощью Инверсионного Анализа.
В рамках этого метода выявлено, что, во‑первых, в организациях и на предприятиях объективно существуют препятствия для свободного обмена информацией об авариях, отказах, рисках и других вредных явлениях. Как правило, все сотрудники организаций склонны избегать разговоров, скрывать информацию о неприятностях и возможных рисках в системе, когда их об этом расспрашивают. Эти информационные препятствия затрудняют устранение проблем в системе.
Во-вторых, традиционные методы анализа и поиска вредных явлений предполагают получить прямой ответ на вопрос: «Как произошло вредное событие?» Учитывая психологическое противодействие таким вопросам, в большинстве случаев нужный ответ не будет получен. Необходимо для начала инвертировать задачу.
Примечание. ТРИЗ — методология сильного инженерного мышления, ориентированная на целенаправленную, системную выработку инновационных идей (решение технических проблем) при совершенствовании систем различной природы. ТРИЗ — аббревиатура от ее исторического названия: Теория Решения Изобретательских Задач. Автор — Г. С. Альтшуллер. [1, 2, 8].
Состав метода
В данной статье мы используем следующие основные стадии Инверсионного Метода:
- Инвертирование задачи.
- Формулирование «диверсионных гипотез».
- Выявление «диверсионных ресурсов».
- Тестирование «диверсионных гипотез».
В более сложных ситуациях может быть использован гораздо более широкий набор инструментов анализа, подробно изложенный в [9, 3, 10, 4].
Стадия 1. Инвертирование задачи
Принцип инвертирования состоит в том, чтобы вместо того, чтобы размышлять: «Как такое вредное явление могло бы случиться?», инвертировать задачу в активный практический вопрос: «Как обеспечить данный вредный результат?» Иными словами: «Как совершить диверсию?»
Такая формулировка обеспечивает три существенных преимущества:
- Намерение действовать и решательная способность человека возрастают. Труднее пытаться разгадать нечто непонятное, и гораздо легче (притом интересней) стремиться к получению ясного результата.
- В инвертированной формулировке вредное явление превращается в нейтральный физический эффект. Пожар становится возгоранием (химической реакцией), неприятный звук — осцилляцией, налипание вредного осадка — адгезией. Такого рода формулировки уже не воспринимаются как оценочные, они становятся объективными, обозначают физические явления как таковые.
- Возможность «обращения вреда в пользу». Многие эффекты, вредные в одной области деятельности, успешно используются в другой. Например, типично «нехорошее» явление — взрыв — имеет разнообразные полезные применения в ИТ:
- Внедрение информационных систем «взрывом» (единовременный отказ от всех старых систем).
- Нагрузочное тестирование системы.
- Crash-test.
При этом информационное поле для поиска «вредных советов» становится гораздо более обширным, поскольку «вредное» в одной ИТ-компании явление вполне может быть использовано на пользу в другой ИТ-компании, которая не будет скрывать информацию об этом достижении.
Итак, инвертируем задачу — переводим ее в «диверсионную» формулировку.
Стадия 2. Формулирование гипотез
Инвертированная формулировка задачи автоматически переключает наше внимание с «вредных явлений, которые случаются» на «результаты, которые нужно получить». Теперь можно выдвигать гипотезы о том, как именно получить нужный (вредный!) результат. Имея активизированное воображение без психологической инерции и будучи нацеленным на область применения эффекта в его нейтральном (физическом) выражении, можно использовать для достижения поставленной цели следующие возможности:
- Изобрести способ получить нужный вредный результат (эффект).
- Выявить все известные процессы, способные обеспечить требуемый вредный эффект.
- Собрать информацию о методах полезного применения указанного вредного эффекта в информационных технологиях.
Полученные таким образом способы, процессы или методы послужат основой гипотез о причине и механизме исследуемого вредного явления.
Стадия 3. Выявление ресурсов
Составив список возможных способов получения рассматриваемого вредного эффекта, т. е. список причинных гипотез, необходимо выявить ту из них, которая описывает реальную причину вредного явления. Это будет та гипотеза, которая имеет все необходимые ресурсы для самопроизвольной реализации.
Например, для возникновения пожара необходим возгораемый материал, кислородная среда и искра. Если хоть один из компонентов отсутствует, пожар не состоится. Это означает, что для самопроизвольного развития аварии все необходимые компоненты вредного механизма уже должны присутствовать в системе или ее ближайшем окружении. Если все они имеются (в этом случае мы называем их ресурсами), компоненты вступят во взаимодействие и произведут соответствующий результат — вредное явление. Авария (отказ, сбой, крах системы) не сможет не произойти, это будет всего лишь вопрос времени.
Стадия 4. Тестирование «диверсионной гипотезы»
После того как диверсионные ресурсы обнаружены, надо проверить механизм их действия в рамках принятой на стадии 2 «диверсионной гипотезы».
Доказать подлинность гипотезы могут только тесты. Поэтому отобранные для работы гипотезы нужно протестировать в реальности, на существующей системе. Результаты тестирования очень важны для успеха Инверсионного Анализа: если тестировщики допустили ошибки или небрежность, весь анализ может быть отвергнут. Поэтому процедуры тестирования должны быть простыми и понятными.
Стадия 5. Устранение вредного явления
К этой стадии механизм вредного явления уже выявлен. Но задача не считается решенной, пока нежелательный эффект не устранен полностью. В большинстве случаев устранить вредное явление, причинный механизм которого раскрыт, уже легко, используя обычную логику: «Вредное явление не может возникнуть, если хоть один из ключевых компонентов его развития отсутствует в ситуации». Это означает, что удаление такого компонента или создание препятствия для его взаимодействия с другими компонентами устранит само вредное явление раз и навсегда.
Конечно, не всякий компонент причинного механизма вреда можно удалить. Некоторые из них, участвуя во вредном процессе, делают и что-то полезное для системы. Поэтому не стоит устранять локальный дефект с помощью радикальных изменений в системе. Если возникает противоречие между необходимостью удалить элемент и его пользой для системы, надо применять
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
ЗарегистрироватьсяУ вас уже есть учетная запись?
Войти
Обсуждения 3
Комментарий от
Олег Точенюк
| 23 июля 2015, 17:35
Да и вообще вы как-то сложно все ломать начали, гораздо проще давайте рассмотрим проблему как что-то поломать получив доступ к серверу БД HANA? И так мы получили доступ к комнате с сервером БД HANA. Теперь необходимо выявить ресурсы для реализации «диверсии», и тут как говорится от простого - молоток, до сложного - электрошокер и никаких ограничений, при этом и тем и другим методом выясняется что мы элементарно можем поломать всю эту кухню. Короче, я тоже тоже подумал, а не отправить ли в SAP AG, кстати она уже давно не AG а вроде как SE, тоже какую бумагу что уж очень не устойчивая у них система при получении физического доступа в серверную.
Комментарий от
Дмитрий Буслов
| 23 июля 2015, 20:41
Олег Точенюк 23 июля 2015, 17:35
Я что-то не понял, а вы каким образом получили собственно говоря пароль системного пользователя HANA?
Да и вообще вы как-то сложно все ломать начали, гораздо проще давайте рассмотрим проблему как что-то поломать получив доступ к серверу БД HANA? И так мы получили доступ к комнате с сервером БД HANA. Теперь необходимо выявить ресурсы для реализации «диверсии», и тут как говорится от простого - молоток, до сложного - электрошокер и никаких ограничений, при этом и тем и другим методом выясняется что мы элементарно можем поломать всю эту кухню. Короче, я тоже тоже подумал, а не отправить ли в SAP AG, кстати она уже давно не AG а вроде как SE, тоже какую бумагу что уж очень не устойчивая у них система при получении физического доступа в серверную.
Доступ к комнате с молотком - это из другой области...
Комментарий от
Олег Точенюк
| 23 июля 2015, 21:51
Дмитрий Буслов 23 июля 2015, 20:41
Я получил доступ к операционной системы <sid>adm имея только права разработчика. Далее, как я описал в статье - возможно сбросить рут доступ для SYSTEM-а. Точнее, ранее можно было(просто запустив скрипт) . В актуальных релизах уже поменяли реализацию сброса пароля, а также закрыли доступ к c-types .
Доступ к комнате с молотком - это из другой области...
Я этот раздел прочитал пару раз, но так и не увидел, где вы в нем написали, что у вас был "доступ к операционной системы <sid>adm имея только права разработчика".
Сейчас как бы понятно, что было дальше.