Szoftvert ad el az Egyesült Államok kormányának? Először ismerje meg a biztonsági tanúsítványt

Az elmúlt hónapokban az Egyesült Államok kormánya számos új követelményt vezetett be a kormányzati szerveknek szoftvereket értékesítő szervezetekre vonatkozóan. Mivel ezek az új követelmények összetettek, sok vezető még nem tudja, hogyan fogják befolyásolni szervezetüket. Ebben a cikkben megosztok néhány legfontosabb fogalmat, amelyeket meg kell értenie, hogy megvédhesse kormányzati vállalkozását és betarthassa a szabályokat.

Új szoftverbiztonsági követelmények: mi változott?

Az elmúlt évek során olyan nagy horderejű biztonsági incidensek történtek, mint amilyeneket érintettek SolarWinds és a nyílt forráskódú csomag log4j fokozott kormányzati figyelmet fordítottak a szoftverbiztonságra. Kezdve ezzel A Fehér Ház 14028-as végrehajtási rendelete Az ország kiberbiztonságának 2021 májusában történő javításával kapcsolatban az elmúlt két évben számos intézkedés eredményeképpen egyértelmű követelmények születtek, amelyek minden kormányzati szoftverszállítót érintenek.

A jövőben minden olyan szervezetnek, amely szoftvert értékesít az Egyesült Államok kormányának, köteles lesz igazolnia, hogy megfelel a kormány által a dokumentumban felvázolt biztonságos szoftverfejlesztési gyakorlatnak. NIST Secure Software Development Framework.

Az egyik legfontosabb dolog, amit meg kell érteni, hogy a szervezeteknek nem egyszerűen azt kell tanúsítaniuk, hogy maguk is követik ezeket a gyakorlatokat az általuk írt szoftverkód esetében, hanem azt is, hogy az alkalmazásaikba beépített nyílt forráskódú összetevők is ezt a gyakorlatot követik.

Június elején a kormány megerősítette ezeket a követelményeket OMB memorandum M-23-16 (PDF), és gyorsan közeledő megfelelőségi határidőket tűzött ki – várhatóan az idei negyedik negyedévben (a kritikus szoftverek esetében) és a jövő év első negyedévében (az összes többi szoftver esetében) megérkezik.

Ez azt jelenti, hogy az elkövetkező néhány hónapban a szervezetek arra törekednek majd, hogy megértsék ezeket az új tanúsítási követelményeket, és meghatározzák, hogyan fog megfelelni szervezetüknek mind a saját maguk által írt kód, mind a szoftvertermékeikbe bevitt nyílt forráskódú összetevők tekintetében.

Az M-23-16 szerint a meg nem felelés súlyos büntetés:

„A [szövetségi] ügynökségnek kell hagyja abba a szoftver használatát ha a hivatal nem találja kielégítőnek a szoftvergyártó dokumentációját, vagy ha nem tudja megerősíteni, hogy a gyártó azonosította azokat a gyakorlatokat, amelyeket nem tud tanúsítani…”

A nyílt forráskód különösen nagy kihívást jelentő esete

Mivel sok szervezet egyre jobban belemerül a tanúsítási követelményekbe, rájönnek, hogy a megfelelés, különösen a szoros határidők betartása mellett, kihívást jelenthet. A NIST SSDF egy összetett biztonsági keretrendszer, és időbe telik, amíg a szervezetek nem csak betartják ezeket a gyakorlatokat, hanem részletesen dokumentálják is.

De még ijesztőbb, hogy a kormány arra kéri a beszállítókat, hogy tanúsítsák a teljes szoftvertermékük biztonsági gyakorlatát, amely magában foglalja a szoftver nyílt forráskódú összetevőit is. Manapság a modern szoftverek gyakran nagyrészt nyílt forráskódú összetevőkből állnak, amelyeket összeépítettek, valamint néhány egyedi szoftvert. Kutatásunk során azt találtuk az alkalmazások több mint 90%-a tartalmaz nyílt forráskódú összetevőket, és sok esetben A nyílt forráskód a kódbázis több mint 70%-át teszi ki.

Szervezete tanúsíthatja saját biztonsági gyakorlatát, de hogyan tudja pontosan tanúsítani a nyílt forráskódú karbantartók által követett biztonsági gyakorlatokat, akik írják és karbantartják az alkalmazásaiban használt nyílt forráskódot?

Ez óriási kihívás, és a szervezetek a nyílt forráskódú karbantartóktól keresnek további információkat biztonsági gyakorlataikról. Sajnos sok ilyen nyílt forráskódú karbantartó nem fizetett önkéntes, akik hobbiból nyílt forráskóddal dolgoznak éjszakánként és hétvégén. Ezért nem praktikus arra kérni őket, hogy tegyenek többletmunkát annak ellenőrzésére, hogy biztonsági gyakorlataik megfelelnek-e a NIST SSDF által meghatározott magas színvonalnak.

Az egyik módja annak, hogy a szervezetek elkerüljék ezt a kihívást, ha nem használnak nyílt forráskódot alkalmazásaikban. És bár ez egy egyszerű megoldásnak tűnik, egyben egyre életképtelenebb alternatíva is, mivel a nyílt forrás sok tekintetben a de facto modern fejlesztési platformmá vált.

A probléma megoldásának jobb módja annak biztosítása, hogy az Ön által használt csomagok karbantartói fizetést kapjanak e fontos biztonsági munka elvégzéséért.

Ez megkövetelheti, hogy további kutatásokat végezzen annak biztosítására, hogy az Ön által használt nyílt forráskódú összetevők mögött karbantartók álljanak, akiket – akár vállalati jótevők, akár alapítványok, akár kereskedelmi erőfeszítések révén – fizetnek azért, hogy ellenőrizzék, hogy csomagjaik megfelelnek ezeknek a fontos biztonsági szabványoknak. Vagy akár saját maga is megkeresheti a karbantartókat, és vállalati szponzora lehet munkájuknak. A megközelítés megtervezésekor ne feledje, hogy a legtöbb nem triviális modern alkalmazás több ezer különálló nyílt forráskódú függőséggel rendelkezik, amelyek mindegyikét más-más személy vagy csapat hozta létre és karbantartja, így ennek a megközelítésnek a méretezésére irányuló manuális erőfeszítések jelentősek.

Kihívó, de szükséges lépés előre

Ezeknek a követelményeknek való megfelelés fájdalmas lehet, de a köz- és magánszektorban súlyos károkat okozó növekvő biztonsági sérülékenységek hátterében ezek szükséges előrelépést jelentenek. Az Egyesült Államok kormánya a világ legnagyobb áru- és szolgáltatásvásárlója, és ez ugyanúgy igaz az IT-re, mint a többi területre. Azzal, hogy vásárlóerejét a szoftverek általános biztonsági szabványának javítására használja, a kormány hozzájárul egy biztonságosabb jövő megteremtéséhez.

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• PlatoData.Network Vertical Generative Ai. Erősítse meg magát. Hozzáférés itt.
• PlatoAiStream. Web3 Intelligence. Felerősített tudás. Hozzáférés itt.
• PlatoESG. Autóipar / elektromos járművek, Carbon, CleanTech, Energia, Környezet, Nap, Hulladékgazdálkodás. Hozzáférés itt.
• BlockOffsets. A környezetvédelmi ellentételezési tulajdon korszerűsítése. Hozzáférés itt.
• Forrás: https://www.darkreading.com/application-security/selling-software-government-know-security-attestation-first