Selge programvare til amerikanske myndigheter? Kjenn sikkerhetsattest først

Selge programvare til amerikanske myndigheter? Kjenn sikkerhetsattest først

Selge programvare til amerikanske myndigheter? Know Security Attestation First PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

I løpet av de siste månedene har den amerikanske regjeringen innført flere nye krav som påvirker organisasjoner som selger programvare til offentlige etater. Fordi disse nye kravene er komplekse, er mange ledere ennå ikke sikre på hvordan deres organisasjon vil bli påvirket. I denne artikkelen vil jeg dele noen av de viktigste konseptene du trenger å forstå, slik at du kan beskytte myndighetene dine og forbli i samsvar.

Nye sikkerhetskrav for programvare: Hva har endret seg?

I løpet av de siste årene har høyprofilerte sikkerhetshendelser som de som har rammet Solarwinds og åpen kildekode-pakken log4j har økt myndighetenes oppmerksomhet på programvaresikkerhet. Starter med Executive Order 14028 i Det hvite hus for å forbedre landets nettsikkerhet i mai 2021, har en rekke handlinger de siste to årene ført til et sett med klare krav som påvirker enhver statlig programvareleverandør.

Fremover vil enhver organisasjon som selger programvare til den amerikanske regjeringen være pålagt å selvattestere at den er i samsvar med sikker programvareutviklingspraksis skissert av myndighetene i NIST Secure Software Development Framework.

Noe av det viktigste å forstå er at organisasjoner ikke bare må attestere at de følger denne praksisen selv for programvarekoden de skriver, men også at open source-komponentene de trekker inn i applikasjonene sine også følger denne praksisen.

I begynnelsen av juni bekreftet regjeringen disse kravene i OMB-notat M-23-16 (PDF), og sett frister for overholdelse som nærmer seg med stormskritt - sannsynligvis kommer i fjerde kvartal i år (for kritisk programvare) og første kvartal neste år (for all annen programvare).

Dette betyr at organisasjoner i løpet av de neste månedene vil streve etter å forstå disse nye attestasjonskravene og bestemme hvordan organisasjonen deres vil overholde, både for koden de skriver selv og åpen kildekodekomponentene som de tar med i programvareproduktene sine.

I følge M-23-16 er straffen for manglende overholdelse streng:

«Det føderale byrået må slutte å bruke programvaren hvis byrået finner programvareprodusentens dokumentasjon utilfredsstillende eller hvis byrået ikke er i stand til å bekrefte at produsenten har identifisert praksisen som den ikke kan attestere ..."

Spesielt utfordrende tilfelle av åpen kildekode

Ettersom mange organisasjoner dykker dypere inn i attestasjonskravene, oppdager de at overholdelse, spesielt mot stramme tidsfrister, kan vise seg å være utfordrende. NIST SSDF er et komplekst rammeverk for sikkerhet, og det vil ta tid for organisasjoner å ikke bare sikre at de overholder denne praksisen, men også dokumentere praksisen deres i detalj.

Men enda mer skremmende er det at myndighetene ber leverandører om å attestere sikkerhetspraksisen til hele programvareproduktet deres, som inkluderer åpen kildekode-komponentene i den programvaren. I dag består moderne programvare ofte i stor grad av åpen kildekode-komponenter som er blitt brosteinsbelagt, sammen med noe tilpasset programvare. I vår forskning har vi funnet det over 90 % av applikasjonene inneholder komponenter med åpen kildekode, og i mange tilfeller åpen kildekode utgjør mer enn 70 % av kodebasen.

Organisasjonen din kan attestere sin egen sikkerhetspraksis, men nøyaktig hvordan kan du attestere sikkerhetspraksisen som følges av åpen kildekode-vedlikeholdere som skriver og vedlikeholder åpen kildekode du bruker i applikasjonene dine?

Det er en stor utfordring, og organisasjoner ser etter åpen kildekode-vedlikeholdere for mer informasjon om deres sikkerhetspraksis. Dessverre er mange av disse åpen kildekode vedlikeholderne ubetalte frivillige, som jobber med åpen kildekode som en hobby på netter og helger. Så det er ikke praktisk å be dem om å gjøre det ekstra arbeidet for å validere at deres sikkerhetspraksis samsvarer med de høye standardene satt av NIST SSDF.

En måte organisasjoner kan unngå denne utfordringen på, er å ikke bruke åpen kildekode i applikasjonene sine. Og selv om det høres ut som en enkel løsning på ansiktet, er det også et stadig mer ulevbart alternativ, ettersom åpen kildekode på mange måter har blitt den de facto moderne utviklingsplattformen.

En bedre måte å løse dette problemet på er å sikre at vedlikeholderne av pakkene du stoler på får betalt for å utføre dette viktige sikkerhetsarbeidet.

Dette kan kreve at du gjør ekstra undersøkelser for å sikre at åpen kildekode-komponentene du bruker har vedlikeholdere bak seg som blir betalt – enten av bedriftens velgjørere, av stiftelser eller av kommersiell innsats – for å validere pakkene deres oppfyller disse viktige sikkerhetsstandardene. Eller du kan til og med nå ut til vedlikeholdere selv og bli en bedriftssponsor for arbeidet deres. Når du designer din tilnærming, husk at de fleste ikke-trivielle moderne applikasjoner har tusenvis av distinkte åpen kildekode-avhengigheter, hver opprettet og vedlikeholdt av en annen person eller team, så den manuelle innsatsen for å skalere denne tilnærmingen er betydelig.

Et utfordrende, men nødvendig skritt fremover

Disse kravene kan være smertefulle å overholde, men på bakgrunn av økende sikkerhetssårbarheter som gjør massiv skade på offentlig og privat sektor, er de et nødvendig skritt fremover. Den amerikanske regjeringen er den største kjøperen av varer og tjenester i verden, og det er like sant for IT som for andre domener. Ved å bruke sin kjøpekraft til å tvinge frem forbedringer av den generelle sikkerhetsstandarden for programvare, bidrar myndighetene til å sikre en tryggere og sikrere fremtid.

Tidstempel:

Mer fra Mørk lesning