Уважаемые партнеры, Компания Treolan совместно с компанией G&G приглашает вас принять участие в маркетинговой программе. Закупая картриджи G&G со склада Treolan, вы накапливаете баллы, которые по окончании программы вы сможете обменять на подарочные сертификаты федеральных сетей на ваш ...
Уважаемые партнеры! В Merlion действует акция по крупной бытовой технике Hyundai. Приглашаем принять участие! До 31 мая 2024 г. за закупки холодильников и морозильных ларей вам будут начисляться бонусы: 1000 руб. и 1500 руб. за каждую единицу товара. Бонусы начисляются за закупки от 20 до 100 штук ...
Закупая комплекты кухонной техники Shaub Lorenz в период с 12 апреля по 31 мая, вы получаете встраиваемую СВЧ печь в подарок или скидку до 100% на товар в комплекте
Компания Merlion представляет вашему вниманию две акции по продуктам российских производителей: «Кешбэк за заказ ПО» и «Мультивендорная акция по продуктам виртуализации». Период действия акций: 01 апреля 2024 - 30 июня 2024. «Кешбэк за заказ ПО»: - Участвующие товары: все продукты от производителей ...
В компании Merlion действует маркетинговая программа по офисной технике ГЕЛЕОС. Начисляются бонусы до 6% за закупки фокусной продукции (брошюровщики, резаки, обложки и пружинки для переплёта, плёнки для ламинирования). Бонусы будут начисляться на баланс компании или выдаваться в виде ...
Не секрет, что Open Source-продукты (СПО) становятся все популярнее в корпоративной среде. Различные организации, будь то сервисные компании, производственные предприятия или банки, внедряют СПО с целью снижения затрат на разработку, ускорения выпуска продуктов или упрощения развертывания приложений с использованием контейнеров. Поспевать за насущными потребностями бизнеса теперь уже не так сложно. Однако корпоративных пользователей неизменно волнует и будет продолжать тревожить другая сторона СПО — безопасность. С 2014 г. стало известно о шести с лишним тысячах новых уязвимостей СПО. По данным разных опросов, 98% компаний даже не знает, что у них используется ПО с открытым исходным кодом. Поэтому само собой разумеется, что предприятия слабо разбираются в том, как защититься от этой растущей угрозы. У большинства организаций отсутствуют автоматизированные процессы отбора и одобрения нового свободного ПО, а также его инвентаризации и контроля за использованием такого ПО в их кодовой базе и Linux-контейнерах. Еще одной проблемой многих организаций с ростом использования СПО становится идентификация и/или мониторинг известных уязвимостей Open Source (типа Heartbleed и ShellShock). Мы предлагаем ряд советов, которые в нынешнем году следует учитывать организациям для предотвращения неприятных инцидентов с СПО. Они основаны на интервью портала eWeek с представителями компании Black Duck, которая поставляет ПО, идентифицирующее компоненты СПО и отображающее известные уязвимости ... читать далее.
Десять ошибок, которые нужно избегать, чтобы обезопасить СПО. СПО все более популярно в корпоративной среде. Но все чаще слышно о его уязвимостях. Как же предотвратить неприятные инциденты, которые могут быть связаны с СПО?
Помните, что с СПО вы предоставлены сами себе. Большинство используемых вами компонентов СПО вы получаете “как есть” без предоставления поддержки. Не получая их патчи, ваша организация должна самостоятельно идентифицировать, отслеживать и исправлять любые уязвимости свободного кода в своих приложениях и контейнерах. И поскольку современные кодовые базы охватывают десятки миллионов строк кода, это нелегкая задача, особенно с применением ручных методов.
Известные уязвимости прячутся на видном месте. В 2015 г. в базу данных уязвимостей (National Vulnerability Database, NVD) Национального Института стандартов и технологий США (NIST) было внесено более 2300 новых уязвимостей компонентов СПО. Хотя это несколько меньше по сравнению с результатами активной охоты за уязвимостями после обнаружения в 2014 г. ошибки в OpenSSL, данная цифра означает, что на каждые сутки приходится более шести новых выявленных уязвимостей. Организации нуждаются в обозримости используемого ими открытого кода и в возможности его коррекции с учетом постоянно меняющегося пространства угроз, чтобы легко эксплуатируемые уязвимости не оставались неисправленными.
Open Source станет еще популярнее. Сегодня 95% критически важных приложений включают компоненты с открытым кодом, и 98% компаний используют его, не подозревая об этом. При этом ежегодно сообщается о более чем четырех тысячах новых уязвимостей СПО. С годами эти цифры будут только расти, однако преимущества в темпах разработки и выпуска готовой функциональности будут и далее стимулировать использование открытого кода.
Старайтесь работать с активным сообществом. Растущая популярность открытого кода в корпоративной среде стимулирует рост числа СПО-проектов. Сегодня 64% компаний участвуют в Open Source-проектах, и вокруг некоторых из них сложились крупные и активные сообщества. Но есть также проекты, которыми занимаются один-два человека. Если речь идет о критически важной функциональности, убедитесь, что в своей оценке СПО вы учли операционные риски.
Нужно понимать, что могут и чего не могут обеспечить средства статического и динамического анализа. Инструменты статического и динамического анализа полезны для идентификации общеизвестных уязвимостей в создаваемом вами коде. Однако они не умеют находить уязвимости в Open Source-компонентах, даже если эти уязвимости уже были ранее выявлены. Вместе с тем они предоставляют мгновенный снимок безопасности приложения. Поэтому используйте эти инструменты, но помните об их ограничениях. Более эффективным, однако, является ПО автоматизированного мониторинга, которое может постоянно отслеживать известные уязвимости и предупреждать вас в случае их обнаружения, так что вы всегда будете иметь представление об уровне защищенности своего кода.
При внедрении технологии контейнеров безопасность выходит на передний план. Контейнеры позволяют быстро собирать и надежно развертывать приложения. Расслоенная архитектура дает возможность быстро использовать базовые образы новых приложений повторно. Однако и внутри контейнеров открытый исходный код влечет за собой те же потенциальные проблемы, что и при его использовании в любом другом приложении. Только при условии видимости открытого кода в ваших приложениях и контейнерах вы сможете иметь контроль, который необходим для управления этим кодом.
Интернет вещей тоже заставляет задуматься о безопасности открытого кода. Постоянное подключение устройств к Интернету ставит новые задачи в области безопасности перед производителями таких устройств и использующими их предприятиями. Устройства наблюдения за детьми, умные дверные звонки и детские игрушки уже подвергались атакам. Устаревшие версии Linux и Android могут стать шлюзом для доступа ко всему домашнему оборудованию или корпоративной сети. Обновление уязвимых компонентов может потребовать от пользователя установки патчей вручную. Безопасность должна стать неотъемлемой частью каждого устройства Интернета вещей (IoT).
Не все зависит от вас — подумайте о ваших поставщиках. Допустим, ваша организация контролирует внутренние разработки с открытым кодом. Но как обстоят дела у ваших поставщиков? Например, ПО типичного современного автомобиля включает более ста миллионов строк кода от разных поставщиков, и значительная его часть является открытым. Если ваши поставщики не сопровождают свое ПО соответствующей документацией, вы не сможете уберечь себя и ваших клиентов от уязвимостей.
Открытый код и лицензионные конфликты. Серьезно ли относится ваша организация к правам на интеллектуальную собственность, лицензированию и оценке рисков, связанных с возможным нарушением оговоренных в лицензиях условий? При неконтролируемом использовании открытого кода может оказаться, что он распространяется под лицензиями, которые не согласуются с вашими корпоративными политиками или ставят под угрозу вашу собственную интеллектуальную собственность.
Невозможно управлять тем, что невидимо. Без надлежащей просматриваемости СПО в кодовой базе организации вам будут угрожать уязвимости, которые обнаруживаются через месяцы или годы после создания кода. Например, уязвимость ShellShock присутствовала в Bash более двадцати лет, пока ее не обнаружили специалисты в области безопасности, а Heartbleed присутствовала в OpenSSL в течение двух лет. При этом приложения, в которых эти компоненты используются, за прошедшие годы тестировали многократно.
