InfoSec

Компания «InfoSec» была основана в 2011 году и специализируется на оказании услуг по внедрению и сопровождению программно-аппаратных комплексов по информационной безопасности, проведение аудита систем информационной безопасности. Офисы компании открыты в городах Астана и Алматы. Сотрудники компании обладают соответствующей квалификацией, подтвержденные международными сертификатами.

Наши клиенты:

  • АО «Национальные информационные технологии»;
  • АО «Самрук-Энерго»;
  • АО «Алматинские электрические станции»;
  • ТОО «АлматыЭнергоСбыт»;
  • АО «Национальная Компания «Казахстан Инжиниринг»;
  • ГКП «Астана Су Арнасы»;
  • ТОО «Казахойл Актобе»;

ТОО «InfoSec» является партнером статуса Premier ведущего вендора в сфере информационной безопасности компании McAfee(Intel Security), и оказывает следующие услуги:

  • Анализ защищённости (веб-приложений, корпоративных приложений, мобильных решений);
  • Тестирование на проникновение корпоративных систем;
  • Аудит информационной безопасности;
  • Защита персональных данных;
  • Защита базы данных;
  • Защита от утечек информации;
  • Обеспечение безопасности при работе в сети Интернет;
  • Защита от вирусов;
  • Защита от спама;
  • Защита от сетевых атак и вторжений;
  • Контроль уязвимостей;
  • Защита мобильных устройств;

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

Внедрение и сопровождение комплекса систем по информационной безопасности на базе решений компании McAfee(Intel Security):

  • АО «Самрук-Энерго»;
  • АО «Алматинские электрические станции»;
  • ТОО «АлматыЭнергоСбыт»;
  • АО «Национальная Компания «Казахстан Инжиниринг»;
  • ГКП «Астана Су Арнасы»;
  • ТОО «Казахойл Актобе»;

Реализация проектов позволила нашим Заказчикам:

  • Интегрировать комплексы систем информационной безопасности в существующие информационные системы Компании;
  • Создать централизованную консоль управления системами информационной безопасности, которая дает возможность централизованно управлять системами безопасности конечных точек, сети и данных. А это позволяет улучшить общий контроль и сократить время реагирования;
  • Производить постоянный анализ и мониторинг систем информационной безопасности Компании в реальном времени;
  • Выявить ранее не замеченные угрозы и нарушения информационной безопасности, и принять соответствующие меры по устранению их;
  • Контролировать входящий веб-трафик, обеспечивая передовую защиту информации;
  • Контролировать рабочее время и эффективность сотрудников, ограничив возможные злоупотребления доступом в Интернет на посещение сайтов нерабочей тематики;
  • Защитить корпоративную почтовую систему от спама и вредоносных программ, тем самым обеспечить постоянную стабильность и надежность работы почтовой системы;
  • Обеспечить всестороннюю защиту конечных точек, повысить скорость развертывания систем ИБ на конечных точках, тем самым экономить время и деньги Компании;
  • Реализовать систему защиты мобильных устройств, которая дает возможность обеспечивать защиту корпоративных данных на мобильных устройствах и управлять мобильными устройствами, что позволяет минимизировать риски утечки конфиденциальной информации;
  • Обеспечить защиту для критически важных баз данных предприятия от внешних и внутренних угроз;
  • Развернуть комплексное решение, которое дает возможность блокировать новейшие угрозы и ликвидировать нежелательный трафик, обеспечивая безопасность по всей сети;
  • Произвести автоматизированный аудит расположения критически важных и конфиденциальной данных;
  • Обеспечить автоматизированный контроль над всеми каналами передачи конфиденциальной информации (локальные и сетевые способы);
  • Производить обнаружение конфиденциальной информации по расположению и содержимому (независимо от способа каналов передачи данных, расширения и расположения файлов);
  • Блокировать утечку конфиденциальных данных (приостановка отправки электронных сообщений или записи на USB-накопители, если эти действия противоречат принятой в Компании политике безопасности);
  • Обеспечить автоматизацию обработки потоков информации согласно установленным политикам безопасности;
  • Отслеживание общего уровня рисков (на основе отчетов по инцидентам);
  • Получить общую картину перемещения конфиденциальных данных Компании, понимая кто, когда, куда, и какие конфиденциальные данные отправил.

Проведение работ, направленных на выяснение степени защищенности сервисов:

  • «Национальный шлюз Республики Казахстан Таможенного союза»;
  • «Единая нотариальная информационная система» – АО «Национальные информационные технологии».
  • Блог-платформа «eGov.kz», доступная по адресу http://blogs.egov.kz/
  • Официальный Интернет-ресурс Министерства транспорта и коммуникаций Республики Казахстан, доступный по адресу http://mtc.gov.kz/
  • Система электронного лицензирования Республики Казахстан, доступная по адресу http://elicense.kz/
  • Единая информацилнная система обязательного технического осмотра, доступная по адресу https://eisto.kz и https://insp.eisto.kz/
  • Система электронного лицензирования Республики Казахстан, доступная по адресу http://epay.gov.kz/
  • Официальный сайт Правительства Республики Казахстан, доступный по адресу http://www.government.kz/
  • Официальный портал Электронного правительства Республики Казахстан, доступный по адресу http://egov.kz/

Реализация проектов позволила нашим Заказчикам:

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

Дополнительно, наша компания оказывает Услуги по поставке и внедрению корпоративной системы службы каталогов Active Directory Domain Services, а также установка корпоративной почтовой системы на базе Microsoft Exchange Server:

  • АО «Алматинские электрические станции»;
  • АО «КазИнжЭлектроникс»;
  • ГКП «Астана Су Арнасы»;
  • ГУ «Управление энергетики и коммунального хозяйства г.Астаны».

Контактная информация

 

Тел./Факс: +7 (499) 705-76-57
Email: 
WWW:  solidlab.ru
ООО «СолидЛаб» (Сколково): 121205, Россия, г. Москва, территория Инновационного центра «Сколково», Большой бульвар, д.42, стр.1.
ООО «СолидЛаб» (Вавилова): 117312, Россия, г. Москва, ул. Вавилова, д. 47А.
ООО «СолидЛаб» (Нижняя): 125040, Россия, г. Москва, ул. Нижняя, д. 14, стр. 1.
 

Community

Наши решения

Какие бывают недостатки в ПО

Классификация программного обеспечения

  1. По уровню, на котором оно работает:
    • сетевое ПО – обеспечивает работу сети и сетевых устройств (стеки протоколов, операционные системы на маршрутизаторах);
    • системное ПО - предназначено для управления работой вычислительной системы (операционные системы, сервисы уровня операционной системы, СУБД);
    • прикладное ПО -  это комплекс программ для решения специфичных задач, т.е. задач определённого класса конкретной предметной области (web-приложения, десктопные приложения).
  2. По источнику (по производителю):
    • стандартное ПО – характеризуется массовым производством и внедрением, автоматизирует общие для всех потребности в IT-технологиях (операционные системы, web-сервера, прикладные утилиты);
    • заказное ПО – производство под заказ, автоматизация процессов конкретной организации, для которых пока еще нет стандартного ПО (различного рода приложения, т.е. прикладное программное обеспечение);
    • собственное ПО – производится собственными силами, автоматизация собственных процессов для которых пока еще нет стандартного ПО.

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

Совместив две классификации (по уровню и по источнику), можно увидеть тенденцию (см. Рис.1.):

  • стандартное ПО обычно коррелирует с системным и сетевым,
  • собственное и заказное программное обеспечение обычно коррелирует с прикладным программным обеспечением, именно по той причине, по которой было рассказано выше.

Рисунок 1. Тенденция корреляции ПО. 

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

Классификация недостатков программного обеспечения

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

  • на уровне проектирования;
  • на уровне непосредственной разработки и кодирования;
  • на уровне внедрения и конфигурирования;
  • на уровне эксплуатации этого программного обеспечения.

Соответственно, в системном, сетевом и прикладном программном обеспечении могут встречаться недостатки этих четырех классов.

На поиск каких недостатков стоит тратить время и деньги

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

При этом необходимо помнить, что:

  • стандартное программным обеспечением чаще всего является системным, сетевым (исключение - стандартное прикладное программное обеспечение, выполняющее типовые прикладные задачи, например, пакет MS Office);
  • заказное и собственное программное обеспечение будет являться практически всегда прикладным.

Поиск недостатков стандартного ПО

Вначале рассмотрим, почему для типовой организации в рамках проекта по анализу защищенности для стандартного ПО не рационально заказывать поиск уязвимостей проектирования и кодирования. Мы не рассматриваем различного рода огромные компании (например, Google или Microsoft), а также службы безопасности государства (например, ФСБ).

Что такое уязвимости кодирования и проектирования стандартного программного обеспечения? Это те самые недостатки, при нахождении которых производитель стандартного программного обеспечения, выпускает патчи.

Представим, что такая уязвимость найдена. Какую пользу с точки зрения защищенности даёт знание уязвимости проектирования или кодирования стандартного программного обеспечения? Самостоятельно нельзя исправить эту уязвимость, можно только сообщить её вендору и ждать выпуска, соответствующего патча. Это так называемые «уязвимости нулевого дня». До момента выхода патчей, для защиты стандартного программного обеспечения от известных уязвимостей, нет никакого надежного способа. Есть только некоторые наложенные способы, которые связаны с конфигурированием средств защиты. Например, системы обнаружения атак. Кроме того, непонятно, почему организация должна платить за поиск уязвимостей в чужих продуктах (речь идет о коммерческих продуктах), если на продаже этих продуктов их производитель зарабатывает деньги. Иначе получается, что организация-заказчик помогает чужому бизнесу.

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

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

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

Т.е. на этапе эксплуатации отсутствие установленных патчей – это уязвимость уровня эксплуатации.

Поиск недостатков заказного и собственного ПО

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

Инструментальный анализ нестандартного ПО

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

Большинство сканеров предназначено для поиска уязвимостей в стандартном программном обеспечении. Они ищут типичные уязвимости конфигурации и типичные уязвимости эксплуатации, а именно отсутствие обновлений.

Для стандартного программного обеспечения такие проверки для сканера можно написать. Например, можно взять web-сервер, Apache, провести анализ его параметров конфигурации и сформулировать правила корректных (т.е. безопасных) параметров конфигурации, а также небезопасных параметров конфигурации. После чего можно создать соответствующую сигнатуру для сканера. Аналогично можно вести базу выхода всех патчей и, устанавливая уровень обновлений в целевом сервисе, делать заключение, установлен последний патч или нет. Таким образом инструментальный анализ уязвимостей конфигурации уязвимостей эксплуатации возможен для стандартного ПО – для ПО, о котором знают производители соответствующих сканеров.

Однако аналогичные инструментальные проверки невозможно сделать для собственного или заказного программного обеспечения. Так как производители сканеров наверняка не знают о Вашем собственном или заказном программном обеспечении.

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

Логические недостатки

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

Резюме

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

Рисунок 2. Рациональный подход к поиску недостатков.

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

Как искать уязвимости

Поиск уязвимостей в стандартном ПО

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

Т.е. имея в штате администратора, которому можно поставить задачу по безопасной конфигурации стандартного программного обеспечения, и проверяя его работу используя сканер безопасности (неважно как он работает в режиме черного ящика или в режиме белого ящика), можно решить задачу наличия уязвимостей в стандартном программном обеспечении.

Поиск уязвимостей в прикладном ПО

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

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

Таким образом, давайте сформулируем и рассмотрим задачу поиска уязвимостей этапов проектирования, а также разработки и кодирования для прикладного ПО (заказного и собственного).

Для собственного ПО

Рассмотрим вначале задачу борьбы с уязвимостями этапов проектирования, а также разработки и кодирования для собственного ПО.

В целом, эта задача неплохо решена уже с методической точки зрения. Компанией Microsoft был придуман особый цикл разработки, который называется Secure Software Development Lifecycle (SDLC), в котором описаны необходимые шаги и мероприятия, позволяющие управляемо контролировать защищенность конечных программных продуктов. Такая разработка становится более дорогой, нежели обычная разработка, которая в основном учитывает только функциональные требования. Тем не менее, на выходе во втором случае получается более качественный продукт и считается, что итоговая стоимость владения программным продуктом в случае применения SDLC меньше за счет снижения средств на поддержку и исправление ошибок в дальнейшем по сравнению со стандартной разработкой, в которой упор делается только на функциональные программные возможности.

Кроме того компания сама обладает экспертизой по разработке и тестированию кода, это значит, что в целом разработчикам достаточно объяснить, как правильно делать, и как неправильно делать. Можно ожидать, что процесс будет в дальнейшем сходиться к нужному результату с точки зрения снижения недостатков этапов проектирования, а также разработки и кодирования.

Для заказного ПО

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

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

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

Резюме

Как же методически правильно бороться с различными классами недостатков в программном обеспечении различного рода?

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

В собственном прикладном программном обеспечении в случае, если программное обеспечение разрабатывается самостоятельно, имеет смысл бороться с этими уязвимостями на этапе разработки и кодирования, внедряя так называемые SDLC. Если же это не целесообразно делать, то, как минимум, необходимо добавлять требования на этапе заказа программного обеспечения, постановки задачи программистам и проверять эти требования на этапе тестирования безопасности продукта.

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

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

Какие услуги когда заказывать?

Все заказчики и потребители сервиса информационной безопасности характеризуются различным уровнем зрелости в вопросах информационной безопасности.

Рассмотрим уровни зрелости ИБ – будем двигаться от менее зрелого уровня к более зрелому. Какие же услуги и на каком этапе имеет смысл и экономически эффективно заказывать? А какие не целесообразно потому что они будут слишком дороги или не дадут положительного эффекта, который они могли бы дать в случае, если бы в самой компании процессы обеспечения ИБ уже были бы выстроены на должном уровне.

Начальный уровень зрелости ИБ

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

За минимальные деньги максимально повысить начальный уровень защищенности.

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

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

Наше решение: Проведение инструментального сканирования

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

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

Однако необходимо помнить про ограничения инструментального сканирования. Ссылка на Инструментальный анализ нестандартного ПО

Средний уровень зрелости ИБ

После проведения сканирования и выявления самых серьезных недостатков, а также их плотности нахождения в информационной системе, перед организацией появляется задача выявить очевидные проблемы, собрать "low hanging fruits", которые с наибольшей вероятностью найдёт потенциальный злоумышленник в первые дни своей работы.

Т.е. необходимо выяснить какие основные процессы ИБ не выполнялись или выполнялись недостаточно качественно – так что организация и её ресурсы пришли в текущее состояние.

Наше решение: оценка уровня защищенности

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

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

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

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

Основные отличия инструментального сканирования от оценки помимо того, что в случае оценки ищутся недостатки, которые не могут быть обнаружены сканерами – это аналитика, которая предоставляется заказчику по результатам работы.

В случае сканирования аналитики нет – это отчет сканера. В случае оценки на основе проведенных проверок делается оценка итогового уровня ИБ.

Высокий уровень зрелости ИБ

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

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

Далее имеет смысл обращаться к услуге «анализ защищенности».

Наше решение: анализ защищенности

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

Все процессы построены. Что дальше?

Далее организация реализует полученные рекомендации. Внутренняя служба обеспечения ИБ представляет карту рисков своей организации, регулярно производит мониторинг угроз и реагирует на возможные инциденты. В целом все рекомендованные процессы реализованы. У организации возникает вопрос: а не деградируют ли выстроенные процессы со временем?

Например, через месяц после проведения предыдущих консультационных работ по анализу защищённости все рекомендации были реализованы. Возникает вопрос: что будет через 3 месяца, через 4, через 6? Не вернется ли организация в предыдущее незащищенное состояние? Не деградирует ли состояние защищенности, качество и эффективность процессов обеспечения ИБ?

Для ответа на эти вопросы этого требуется внешняя проверка. Внешняя – чтобы исключить конфликт интересов, потому что внутренняя безопасность не может рапортовать о снижении защищенности, т.к. она за нее же и отвечает.

В таком случае заказчики прибегают к услуге по тестированию на проникновение.

Наше решение: тестирование на проникновение

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

Цель тестирования на проникновение – достижение поставленной Заказчиком задачи. К таким целям относятся: проникновение во внутреннюю сеть, получение доступа к корпоративной переписке, захват сервера, реализующего какой-либо сервис, например, по проведению платежей и т.д. Проект заканчивается как только поставленная задача будет достигнута.

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

В отличие от анализа защищенности, в ходе тестирования на проникновение вопрос полноты обнаруженных уязвимостей не стоит.

О компании

kodex

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

Наша команда

Основу команды составляют выпускники, аспиранты и исследователи группы, занимающейся актуальными вопросами практической безопасности на факультете ВМК Московского Государственного университета. С 2009 года команда активно участвует в CTF-соревнованиях под именем “Bushwhackers”. По итогам соревнований Bushwhackers стабильно занимает место среди 15 лучших команд мира.

Эксперты из нашей команды выступали с докладами на ведущих конференциях, посвященных практической безопасности: Hack-in-the-Box Amsterdam, BlackHat EU, DefCon (США), Confidence (Польша), OWASP AppSec EU, ZeroNights (Россия), Positive Hack Days (Россия).

Участники команды неоднократно побеждали в специализированных хакерских конкурсах (приведены самые значимые за последние два года):

  • 1-ое место в соревновании Nuit du Hack CTF Finals в 2018 и 2017 году;
  • 1-ое место в соревновании Faust CTF в 2018 и 2017 году;
  • 1-ое место в соревновании RuCTF Finals в 2018 и 2017 году;
  • 1-ое место в соревновании Positive Hack Days VII CTF 2017;
  • 1-ое место в соревновании UCSB iCTF в 2017.

Наши эксперты включены в залы славы по итогам участия в программах по поиску уязвимостей на сайтах таких ИТ-компаний как Yandex, Mail.ru, Qiwi, AT&T имеют благодарности от разработчиков известных платформ и продуктов – ForgeRock OpenAM, Wordpress CMS, Naumen HelpDesk, 1C Битрикс, браузера Opera.

Наши проекты

Самыми крупными проектами в недавнем времени для нас были:

  • кредитно-финансовая сфера: аудит систем ДБО из 8 из ТОП-30 Российских Банков (трех из ТОП-10);
  • ритейл: тест на проникновение и анализ защищенности информационных систем крупного ритейлера (входит в ТОП-3);
  • энергетика: аудит компьютерных сетей крупнейшего оператора в сфере электроэнергетики, аудит онлайн ресурсов крупной нефтедобывающей компании;
  • транспорт: аудит управляющих информационных систем крупнейшего перевозчика грузов;
  • телеком: аудит ключевых онлайн ресурсов оператора «Большой Тройки».
aboutus

 

Мы нацелены на успех! Связаться с нами.

Еще статьи...