Наши решения

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

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

  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? Не вернется ли организация в предыдущее незащищенное состояние? Не деградирует ли состояние защищенности, качество и эффективность процессов обеспечения ИБ?

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

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

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

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

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

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

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

О компании

SolidLab c 2011 года работает в сфере информационной безопасности и оказывает более 17 видов услуг: от аудита информационных ресурсов до организации процессов разработки защищенных приложений.

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

Команда
 
Основу команды составляют выпускники и аспиранты факультета ВМК МГУ им. Ломоносова. Руководители — действующие научные сотрудники лаборатории, которая занимается вопросами практической кибербезопасности, криптографии и построения сложных информационных систем.
 
Эксперты SolidLab ежегодно выступают с докладами на профильных конференциях, являются активными участниками комьюнити и включены в залы славы по итогам баг-баунти программ от лидеров рынка ИТ.

Доклады на конференциях

2022 год

Positive Hack Days, 2022, Москва, «Анализ клиентского JavaScript-кода для обнаружения HTTP-эндпоинтов», Даниил Сигалов;
 

2019 год

СTF Az, 2019, Баку, «Красные против синих. Анализ защищенности в формате киберучений», Андрей Петухов;
 
Международные учения Cyber Polygon, 2019, Москва, «Атаки на веб-приложения: прошлое, настоящее, будущее», Андрей Петухов;
 
ICC, 2019, Москва, «Острова свободы: как университеты становятся точками роста киберпотенциала», Денис Гамаюнов.
 

2018 год
 
Positive Hack Days VIII, 2018, Москва, «Автоматизируй, если сможешь: как не сойти с ума, внедряя инструментальные контроли в процессы SDLC», Кирилл Самосадный и Андрей Петухов.
 

2017 год
 
Privacy, Security and Trust (PST) 2017, D. Gamayunov, A. Skovoroda, Automated static analysis and classification of Android malware using permission and API calls models.
 

2008-2015 гг.
 
Positive Hack Days V, 2015, Москва, Георгий Носеевич, «Кольцо отжима: identity theft в московском метрополитене»;
 
PDP 2015, Finland, D. Gamayunov, A. Skovoroda, Review of the mobile malware mitigation approaches;
 
Positive Hack Days IV, Москва, 2014, М. Коростелёва, Д. Гамаюнов, «Обеспечение криптографически защищенных групповых коммуникаций с функцией отказуемости»;
 
Hack in the Box, Амстердам, 2014,  «Вы можете быть кем угодно: обход "сертифицированной" криптографической защиты в банковских приложениях», Георгий Носеевич, Андрей Петухов и Денис Гамаюнов;
 
BlackHat EU 2013, Hybrid defense: how to protect yourself from polymorphic; S. Gaivoronski, D. Gamayunov;
 
DefCon USA 2012, Demorpheus: Getting Rid Of Polymorphic Shellcodes In Your Network; S. Gaivoronski, D. Gamayunov;
 
ZeroNights, Москва, 2012, «Ни замков, ни засовов: взлом инфраструктуры OpenAM», Георгий Носеевич и Андрей Петухов;
 
Confidence 2012, Краков, «Сравнительный анализ эффективности сканеров SQL-инъекций», А. Петухов, К. Валиев;
 
DIMVA 2011, Амстердам, «Выявление уязвимостей контроля доступа в веб-приложениях», Георгий Носеевич, Андрей Петухов;

OWASP AppSec Europe 2008, Португалия, «Презентация проекта тестирования контроля доступа в веб-приложениях», Андрей Петухов;

International Symposium on Visualization for Cyber Security 2009, USA, D. Gamayunov., A. Yelizarov, Visualization of Complex Attacks and State of Attacked Network;
 
OWASP AppSec Conference 2008, Бельгия, Гент, «Обнаружение уязвимостей веб-приложений с помощью динамического анализа и тестирования на проникновение»; А.Петухов, Д.Козлов;
 
 
Более 10 лет специалисты SolidLab участвуют в CTF-соревнованиях в составе команды Bushwhackers, которая стабильно сохраняет высокие позиции в мировом рейтинге CTF.
 
 
Продуктовое направление
 
В 2014 году группа экспертов по защите веб-приложений была выделена в отдельную компанию SolidSoft, которая вскоре стала резидентом ИТ-кластера инновационного центра «Сколково». 
 
В 2016 году компания выпустила первый релиз SolidWall WAF, сетевого экрана для защиты веб-приложений. Последующие годы компания совершенствовала собственные разработки и сервисы, работая в технологическом партнерстве с ключевыми игроками рынка.
 
В конце 2020 г. сетевой экран SolidWall был включен в Единый реестр российских программ для электронных вычислительных машин и баз данных в соответствии с Приказом Минцифры России № 799.
 
 
Контактная информация
 
Тел.: +7 (499) 705-76-57
E-mail: 
Сайт:  solidlab.ru

Офис в Сколково
121205, Россия, г. Москва, территория Инновационного центра «Сколково», Большой бульвар, д.42, стр.1

Офис на Вавилова
117312, Россия, г. Москва, ул. Вавилова, д. 47А

Офис на Нижней
125040, Россия, г. Москва, ул. Нижняя, д. 14, стр. 1

 

Описание функциональных характеристик SolidLab VMS

Интеллектуальная платформа по управлению уязвимостями SolidLab предназначена для поиска и анализа недостатков и уязвимостей в ИТ-инфраструктуре с целью повышения уровня защищенности обслуживаемого сегмента. Компоненты, входящие в состав сервиса, осуществляют сканирование объектов ИТ-инфраструктуры по заданным алгоритмам, а найденные недостатки передаются в единый интерфейс для автоматического и ручного анализа. Defect Tracker – инструмент, входящий в состав «SolidLab VMS» позволяет ознакомиться с информацией о выявленных проблемах в инфраструктуре, управлять постановкой задач по устранению выявленных проблем, в том числе приоритезировать данные задачи. 

Сервис размещается на стороне Исполнителя и является комплексом технических и программных средств на базе распределённой сети центров обработки данных, предназначенный для оказания услуг по модели облачных вычислений.

Сценарии использования:

  • автоматизация инвентаризации ИТ-инфраструктуры, веб‐приложений и используемого программного обеспечения;

  • выявление уязвимостей, определение уровня критичности и реализация процесса устранения уязвимостей;

  • обучение и поддержка уровня знаний специалистов;

  • автоматизация мониторинга производимых изменений в ИТ-инфраструктуре, веб‐приложениях и используемом программном обеспечении;

  • выделение технических ресурсов для развертывания средств работы с уязвимостями;

  • фильтрация и валидация результатов работ по поиску уязвимостей.

 

Документация

Руководство по эксплуатации

 

Функциональные характеристики

SolidLab VMS (Vulnerability Management service) - интеллектуальная платформа по управлению уязвимостями.

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

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

Платформа состоит из ряда независимых компонент, что даёт возможность для:

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

В зависимости от решаемых задач в состав SolidLab VMS могут входить:

  • DefectTracker – компонент централизованной обработки и хранения собранных данных, а также визуализации результатов работы других компонентов.
  • External Vulnerability Manager – компонент поиска известных уязвимостей внешнего периметра.
  • Open Source Intelligence – компонент автоматизированного пассивного и активного сбора данных об ИТ-инфраструктуре компании из открытых источников.

Функциональные характеристики:

  • Наличие единого интерфейса мониторинга;
  • Инвентаризация ИТ-инфраструктуры, веб‐приложений и используемого программного обеспечения;
  • Сканирование на уязвимости используемых на узле ПО / сервисов (“чёрный ящик”, “белый ящик”, “серый ящик”);
  • Получение общей информации о хосте;
  • Получение информации об отсутствующих обновлениях безопасности (со списком CVE, устраняемых данным обновлением);
  • Возможность поиска конкретных уязвимостей;
  • Широкий набор инструментов для работы со сканированиями (Создание/редактирование задач и расписаний сканирования, запуск одинарного или непрерывного сканирования, настройка профилей и портов сканирования);
  • Выявление уязвимостей конфигурации;
  • Выявление фишинговых сайтов;
  • Работа с хостами (активами) в UI – объединение в группы, категории (по критичности), присваивание меток хостам или группам хостов;
  • Создание дифференциальных отчетов;
  • Создание и редактирование шаблонов дифференциального отчета (template);
  • Возможность синхронизации информации о статусах уязвимостей с внешними системами (SIEM, тикет-системы и т.п.).
  • Оценка уровня критичности и ручная верификация.

В работе компонентов платформы используются:

  • Общедоступные базы уязвимостей.
  • Базы уязвимостей российского ПО, в том числе база ФСТЭК.
  • Собственная база уязвимостей.

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

Отчёт может выгружаться в нескольких форматах файлов на выбор (csv, pdf, html). Формат отчёта настраивается в зависимости от задач и может формироваться автоматически и вручную.

Slideset

The Widgetkit Slideset takes your product showcase to the next level. It provides a sleek way to show multiple sets of items and uses smooth effects while looping through them.

Features

  • Clean and very lightweight code
  • Eye-catching transition effects
  • Fully responsive including all effects
  • Support of named custom sets
  • Swipe navigation on mobile phones
  • Built with HTML5, CSS3, PHP 5.2+, and the latest jQuery version
  • Works with Joomla and WordPress

Slide Example

The sets are auto generated (4 items per set), item names are shown and it uses the slide effect and navigation buttons.

  • Icon 01
    Radio
  • Icon 02
    Camera
  • Icon 03
    Calendar
  • Icon 04
    Volume
  • Icon 05
    Chat
  • Icon 06
    Tunes
  • Icon 07
    E-Mail
  • Icon 08
    Google+
  • Icon 09
    Player
  • Icon 10
    Like
  • Icon 12
    Twitter
  • Icon 12
    Weather

Zoom Example

The sets are arranged manually, the sets names are used as navigation and it uses the zoom effect.

  • Icon 01
  • Icon 02
  • Icon 03
  • Icon 04
  • Icon 05
  • Icon 06
  • Icon 07
  • Icon 08
  • Icon 09
  • Icon 10
  • Icon 12
  • Icon 12
  • Icon 13

Drops Example

The sets show the item names and it uses the drops effect and navigation buttons.

  • Icon 01
    Album 1
  • Icon 02
    Album 2
  • Icon 03
    Album 3
  • Icon 04
    Album 4
  • Icon 05
    Album 5
  • Icon 06
    Album 6
  • Icon 07
    Album 7
  • Icon 08
    Album 8
  • Icon 09
    Album 9
  • Icon 10
    Album 10
  • Icon 12
    Album 11
  • Icon 12
    Album 12

Deck Example

This auto generated sets uses prev/next buttons as navigation and the deck effect.

  • Icon 01
  • Icon 02
  • Icon 03
  • Icon 04
  • Icon 05
  • Icon 06
  • Icon 07
  • Icon 08
  • Icon 09
  • Icon 10
  • Icon 12
  • Icon 12

How To Use

The Widgetkit Slideset takes full advantage of the very user-friendly Widgetkit administration user interface. You can create and manage all the slidesets and their different items in one place. After you have created a slideset you can load it anywhere on your website using shortcodes or the universal Widgetkit Joomla module or WordPress widget.

Accordion

The Widgetkit Accordion enables you to display a set of items in a compact space, by clicking on each items header it expands or collapses it's content section.

Features

  • Clean and very lightweight code
  • Responsive design to fit all device resolutions
  • Smooth transitions on content section toggle
  • Option to match automatically the height of varying content
  • Option to auto collapse or allow multiple opened items
  • Built with HTML5, CSS3, PHP 5.2+, and the latest jQuery version
  • Works with Joomla and WordPress

Example

Slide 1

Icon 01

Headline

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Slide 2

Icon 02

Headline

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Slide 3

Icon 03

Headline

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Slide 4

Icon 04

Headline

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

How To Use

The Widgetkit Accordion lets you easily create and manage all the accordions contents through the user-friendly Widgetkit administration user interface. After you have created an accordion you can load it anywhere on your website using shortcodes or the universal Widgetkit Joomla module or WordPress widget.

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