У вступній доповіді 2022 р Black Hat конференція безпеки, Кріс Кребс, колишній директор відділу кібербезпеки Департаменту внутрішніх цінних паперів, заявив, що безпека погіршиться, перш ніж покращиться. чому Кребс сказав, що «програмне забезпечення залишається вразливим, тому що переваги незахищених продуктів набагато переважують недоліки». Замість того, щоб забезпечити безпеку, основна увага на життєвому циклі розробки програмного забезпечення (SDLC) спрямована на перемогу над конкурентами на ринку. Насправді інновації часто суперечать безпеці — перші вважаються швидкими та продуктивними, а другі — перешкодою, яка гальмує швидку розробку додатків. Цей погляд виявляється застарілим у поточному ландшафті загроз.
Оскільки кібератаки зростають, ланцюжок постачання програмного забезпечення є популярною мішенню для кіберзлочинців, які усвідомлюють величезні збої, які вони спричиняють, заражаючи незахищений код. Наприклад, сумнозвісний нині Log4Shell Уразливість створювала такий ризик, оскільки відкритий вихідний код Log4j дуже часто використовується в програмних застосунках і онлайн-сервісах у всьому світі, а використання вразливості вимагає дуже мало досвіду. Зовсім недавно, 25,000 XNUMX шкідливих плагінів на сайтах WordPress підкреслюють ризик кібербезпеки, з яким стикаються багато компаній, незважаючи на те, що вони вірять, що використовують безпечні програми та програми на своїх веб-сайтах.
Тому інновації та безпеку слід розглядати через одну призму; одне неможливе без іншого. Що ще важливіше, безпека більше не може бути обов’язком однієї ізольованої команди. Це має бути пріоритетом для всіх у SDLC.
Дилема AppSec
Незважаючи на збільшення інвестицій у розробку додатків, безпеці не приділяється такого ж значення. У такому конкурентному просторі винагороду, як правило, отримують перші. Ті, хто виходить на ринок зі своїм «першим життєздатним продуктом», швидше за все, дивляться на те, як цей продукт може служити клієнтам, а не на те, як ним можна безпечно користуватися. З такими високими очікуваннями вимоги до коду до розробників зросли 100 раз за останні 10 років, причому 92% відчували тиск, змушений писати код швидше. Поєднайте це з тим, що 53% не мають професійного навчання безпечному кодуванню, тоді як кількість нових уразливостей усередині NIST Національна база даних про вразливості зросла більш ніж на 200% за останні кілька років, і, здається, ми опинились у певній дилемі безпеки програм.
Однак це не нерозв'язна дилема. Рішення потребує повного перемикання з погляду багатьох на кодування та інновації, з особливим акцентом на мисленні людей. Він ставить безпеку на перше місце та визнає, що нормально виходити на ринок повільніше, якщо кінцевий продукт безпечніший. Відповідно до Закон Бема, «вартість пошуку та усунення дефекту зростає експоненціально з часом» — концепція, яка може принести користь організаціям, які з самого початку віддають перевагу безпеці.
Встановлення цього принципу безпеки є надзвичайно важливим — не лише для команди розробників, але й для всіх, хто відіграє певну роль у SDLC. Менеджери продуктів і проектів, DevOps, дизайнери користувальницького досвіду (UX) і професіонали із забезпечення якості (QA) впливатимуть на кінцевий результат і тому повинні усвідомити поточну дилему безпеки додатків і те, як цю проблему можна подолати.
Правильна інтегрована освіта
Якщо команди не розуміють чому підхід до безпеки настільки важливий у розробці додатків, що вони ніколи не підуть на це як це може бути досягнуто. Таким чином, інтегроване та безперервне навчання безпеки додатків для всієї організації, що займається розробкою, ніколи не було настільки важливим. Для тих, хто створює код, важливо надати базові знання перед практичними вправами, які безпосередньо стосуються проблем, з якими вони стикаються щодня. Цю спеціальну освіту для розробників слід проводити паралельно з базовими та розширеними навчальними програмами безпеки додатків для тих, хто виконує ролі в SDLC, яким необов’язково потрібні практичні знання. Такі ініціативи дозволять усій команді мислити інакше, приймати більш обґрунтовані рішення та інтегрувати безпеку в усі аспекти розробки.
Проте важливо, щоб організації розуміли, що безпека програм постійно розвивається та змінюється. Сформувати команду, що дбає про безпеку, яка застосовує ключові принципи AppSec на кожному етапі циклу розробки, неможливо за допомогою навчальної програми «один і готовий». Для того, щоб переконатися, що команди дотримуються такого мислення, що на першому місці безпека, постійна освітня програма, що розвивається, є ключовою.
Багато організацій залучають команди, визнаючи та відзначаючи чемпіонів безпеки, які керують зміною поведінки безпеки в команді. Пропонуючи заохочення або винагороди тим, хто постійно застосовує найкращі методи безпеки у своїй повсякденній роботі, вони заохочують чемпіонів залучати інших і органічно впливати на зміни. Наприклад, шляхом вимірювання результатів — наприклад, кількості вразливостей у коді до та після навчальних програм — і визнання успіху, також набагато легше отримати підтримку від правління та виправдати інвестиції в освіту з безпечного програмування для тих, хто приймає рішення. .
Швидкі інновації та перемога над конкурентами на ринку, водночас ставлячи безпеку на перше місце, є можливими, коли співробітники SDLC роблять безпеку головним пріоритетом. Фактично, оскільки кількість уразливостей зростає, а кібератаки не сповільнюються, безпечне кодування є обов’язковим для успішної роботи будь-якої програми. Поки весь SDLC розглядається в безперервних, індивідуальних і вимірних освітніх ініціативах, безпека не мати стати гірше, перш ніж стане краще.
