| Чтобы знать код ПО, требуется затратить примерно столько же ресурсов, сколько требует его написание |
Осталось убедиться в его истинности, для чего я задал соответствующий вопрос экспертам. И вот что они ответили (разумеется, это исключительно их личное мнение, а не позиция компании, где они работают).
[spoiler]Игорь Бухштаб:
| Проверка кода требует больших ресурсов, чем написание. |
Дмитрий Комиссаров:
| "Атлас" и не проверяет весь код. |
Эдуард Пройдаков:
| 1. Исходники Windows были переданы Атласу по соглашению в рамках программы, которую Microsoft осуществляет с правительствами других стран, чтобы эту ОС сертифицировали для работы с конфиденциальной информацией. 2. Кроме текстов самой ОС они передали и тексты инструментария — компиляторов, загрузчиков и т.п., поскольку можно вставить закладки на этом этапе. 3. Поскольку проверка в этом случае специфическая, то она большей частью может быть разными способами автоматизирована. 4. Безопасность системы при этом всё равно не гарантируется, поскольку не исключается взаимодействие кода с аппаратными закладками. |
Владимир Безмалый (между прочим, единственный в СНГ обладатель статуса Microsoft Security Trusted Advisor):
| Проверять чужой код значительно сложнее чем писать свой. Скорее всего речь идет о проверке на соответствие каким-то критериям, потому как проверить все практически невозможно. |
Разумеется, после этого мои сомнения в том, что НТЦ "Атлас" полностью проверяет код Winodws на наличие там "бомб" только усилились.
А как же сертификаты ФСТЭК? Неужто они не гарантируют отсутствие "бомб"?
Изучить этот вопрос глубоко я пока не успел, но информация с сайта компании "АЛТЭКС-СОФТ" удивила. Там даётся краткая характеристика сертифицированных продуктов:
| Программное средство общего назначения со встроенными средствами защиты от несанкционированного доступа к конфиденциальной информации. |
Подозреваю, что речь идёт не о безопасности вообще, а о так называемой "информационной безопасности". Если воспользоваться аналогией с автомобилями, то гарантируется только то, что при перевозке секретных документов они не выпадут на дорогу. А то, что машина может взорваться или просто сломаться (и документы не попадут по назначению), то тут уж "к пуговицам претензии есть?".
И мне вспомнилась одна история.
Довольно давно, когда само понятие ИБ ещё не было распространённым, в одну достаточно серьёзную СБ искали специалиста, который будет работать с компьютерной техникой. Кандидатам предлагалось простое тестовое задание — провести аудит компьютера. Все включали машину и начинали что-то говорить про антивирусы, открытые порты и т.д., и т.п. И никому не пришло в голову просто открыть системный блок и найти там листок с надписью "нашедший эту бомбу будет принят на работу".
PS. Кстати, недавно благополучно рухнул миф о политической нейтральности "Майкрософт". По сообщению сайта biz.liga.net Генеральный директор "Майкрософт-Украина" Дмитрий Шимкив временно сложил полномочия и взял бессрочный отпуск, чтобы выйти на Евромайдан. Иными словами, руководитель фактически иностранной компании, контролирующей ИТ-инфраструктуру страны, публично заявил о своей нелояльности к существующей власти. Я, разумеется, верю, что сделал это он исключительно по зову души и редмондский офис вообще не в курсе.
Но что означает этот контроль на практике, как-то не раскрывалось.
Попытаюсь заполнить этот пробел одним из вариантов:
Предположим, что сотрудник ИБ, админ, или вовсе простой клерк какого-либо гос. учреждения обнаружил проблему или уязвимость.
Проблема доходит до отдела, курирующего безопасность системы (ОБС).
По идее, далее:
1. ОСБ должны поставить задачу с высоким приоритетом разработчикам.
2. Разработчики в оговоренные сроки проблему устранить и выпустить обновление.
3. ОСБ обновление принять и уведомить подведомственные организации о необходимости установки этого обновления.
В случае СПО вопросы могут возникнуть только со сроками, нужными разрабам для устранения, т. к. код таки в основном «чужой».
Если проблема серьёзная, возможно потребуется разбить её на несколько стадий. Тогда пункты 2 и 3 повторяются несколько раз.
В случае же с Microsoft и прочих Apple, вопросы возникают во всех 3-х пунктах:
1. Не факт, что наш ОСБ может выставлять задачи и влиять на их приоритеты.
Ударяясь в конспирологию - возможно уязвимость планировали использовать «против нас» - тогда её исправление будет спущено на тормозах, пока не найдут замену
2. Разработчики меняются в силу естественных причин, и люди, курирующие подсистему вполне могут так же не владеть кодом как и «наши СПО-шники»
3. Обновление на места поступают в «явочном» порядке, часто без ведома пользователей. Т. о. ОСБ ничего не контролирует - о чём тут уже писали.