10 порад з безпеки волонтерським проєктам, які розробляють софт

Привіт, я Анастасія, я працюю Head of customer solutions / Security software engineer в компанії Cossack Labs. Ця стаття про те, на що варто звертати увагу IT-волонтерам з точки зору безпеки при розробці вебсайтів, мобільних застосунків та ботів для захисту країни. Стаття буде корисна розробникам, менеджерам та вашим кураторам з лав захисників.

Війна для багатьох з нас є не тільки жахами та зруйнованими домівками, але й шансом використати свої професійні навички, щоб допомогти державі. Як компанію, що займається безпекою даних, Cossack Labs запросили до багатьох волонтерських проєктів, де ми допомагаємо власною експертизою.

Один з наших головних фокусів у мирному житті — це сприяння продуктовим командам у розробці безпечних продуктів за допомогою developer tools, спеціалізованих рішень та сервісів. Тож зараз product security oversight часто є нашою роллю у волонтерських проєктах, які швидкоруч розробляють корисний для різних служб і підрозділів софт.

Воєнне IT у 90% випадках — це стартапи «на вчора» з підвищеними вимогами до інформаційної безпеки, реальною моделлю ризиків, стейкхолдерами та користувачами у досить специфічному домені. Тобто життєвий цикл розробки знайомий більшості розробників, але наразі він є більш хаотичним, із багатьма новими незнайомими речами та справжніми ризиками.

Хочу поділитися низкою порад, як таким проєктам почати швидше приносити користь й при цьому не розкривати зайвих деталей та не порушувати жодних таємниць.

Поради для безпеки продукту

  1. Фокус. Спершу фічі, потім інфраструктура, і вже в третю чергу «примочки та покращення». Фічі продукту несуть головну цінність користувачам та рятують життя (часто — у прямому сенсі). Думайте про інфраструктуру як щось непостійне, що вам доведеться швидко підіймати та змінювати, доповнювати, закривати фаєрволами, переміщувати. Примочки можуть почекати.
  2. Software security. Безпека має бути присутня на початкових кроках — ще на стадії дизайну системи, а не з’являтися наприкінці в форматі: «перевірте, що ми тут зробили та чи воно безпечне». Бо інакше буде багато реінжинірингу та компромісів. Долучайте до проєкту інженерів з безпеки якомога раніше.
  3. Risk modeling. Частіше ставте собі питання «що може піти не так?». Ризики здаються знайомими, але наслідки ризиків наразі можуть бути значно гіршими. Якщо раніше ставлення до проблем було легким, як-от «у нас злили дані — то не біда, просто у Facebook пошумлять», то тепер це може змінитися на «у нас злили дані — це може призвести до загибелі конкретних людей» або «недоступність нашого сервісу може призвести до загибелі людей». Ставки дуже зросли.
  4. Безпека даних. Не зберігайте важливі дані. Якщо зберігаєте — шифруйте. Шифруйте при передачі, шифруйте при зберіганні, шифруйте бекапи. Бережіть ключІ шифрування. (Не знаєте як, приходьте, я підкажу.)
  5. Інфраструктура, зокрема фізична, дуже важлива.
    1. Де фізично знаходяться ваші сервери? Чи вони у безпечному місці, чи туди може прилетіти Іскандер? Треба мати reliability plan, що передбачає можливість захоплення фізичної локації або пошкодження лінії зв’язку до неї beyond repair.
    2. Хмарна інфраструктура — це про доступи та бекапи. Перевірте, чи до вашої хмари мають доступ всі розробники (це нє оч) або лише суперадмін (що також нє оч, бо якщо що, наприклад, його ноутбук завалить уламками, до чого це призведе?).
    3. Автоматизована та low-maintenance інфраструктура краща за high-maintenance. Чим стабільніше вона працює та чим менше відволікає захисників, тим краще.
  6. Вибір технологій. Чим більш спеціалізована та складна технологія, тим більше проблем вона завдаватиме кожного разу, коли зламається. Краще обирати щось більш поширене та interoperable. Матимете більше фахівців, швидші результати.
  7. Вузька експертиза. Знайдіть проєкт, що відповідає вашій експертизі — якщо ви багато вмієте в hardware design або AI/ML, то термінове опанування вебфронтенду може стати недоречним марнуванням часу. Ми бачили багато випадків, коли дуже спеціалізованих людей завантажували «низькопрофільною» роботою. Наразі є безліч проєктів, пошукайте той, якому ваш досвід дійсно додасть цінності.
  8. Кооперація. Скоріш за все, хтось вже працює над штукою/ модулем, який вам потрібен. Пошукайте, скоординуйтеся, обміняйтеся досвідом та працюйте разом. Ми допомагали проєктам «знаходити один одного» — і це фантастично — кілька повідомлень в профільних чатах можуть зекономити тижні роботи.
  9. Пріоритети. Намагайтесь зрозуміти, чи проєкт, до якого ви долучилися, має шанс «дійти до продакшену», чи ні. Чи може він допомогти відразу, чи це на «після перемоги». Всі варіанти корисні, але пріоритети різні — оберіть оптимальний вектор зусиль.
  10. Ваш час — це зброя. Якщо у проєкту немає чітких стейкхолдерів та acceptance criteria, можливо, ви витрачаєте час марно. Бережіть його.

Розвиток у воєнний час

Як результат, окрім наближення нашої перемоги, ви можете стати значно кращим фахівцем, а в мирний час ваш досвід й нове ставлення до роботи зроблять вас ще ціннішим спеціалістом будь-де.

Щодо технічних порад: багато відповідей на питання вже написані у OWASP Cheat sheets, OWASP MASVS/MSTG, OWASP ASVS/WSTG та Як не стати кібержертвою. Багато інструментів з безпеки — сервісів, файєрволів, бібліотек шифрування — є безкоштовними та доступними. Але часу обмаль, тож якщо займатися безпекою наразі складно, див. #2.

P.S. Пароль slavaukraini це гарне гасло, але поганий пароль. Slavaukraini2 також. Не скажу, де бачила.

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я бы додав: використовуйте автоматчні системи пошуку вразливостей в коді; використовуйте останні версії бібліотей і фреймворків.

Так, можна підключити багато автоматизованих систем — різні рівні тестів, SAST, слідкувалку за версіями залежностей і тд, але за цими системами треба слідкувати, тріажити, приймати/ігнорувати їхні рекомендації — це все час.

Треба шукати баланс, за яким автоматизовані системи приносять більше цінності, ніж відволікають.

Підписатись на коментарі