Sorry hoor, maar waarom ga je beveiligingsbedrijf je broncode in een of andere cloud product zoals Github kwakken? Broncode moet je op je eigen netwerk houden achter een degelijke beveiliging. Github Repo's zijn aan de lopende band zo lek als een mandje (niet Github zelf, maar elke keer liggen er weer credentials op straat en worden repos leeggetrokken).

Okta is specialist in toegangsbeveiliging voor cloud-accounts. Practice what you preach, dat doen ze dus en blijven ze doen (dit was allesbehalve hun eerste breach dit jaar) - petje af.

De vraag die resteert: is "alles in de cloud" wel zo'n goed idee - als het zelfs specialisten niet lukt om ongeautoriseerde toegang te voorkomen?

Integendeel, broncode moet je gewoon openbaren, en wel onder een vrije licentie. Dat is de enige manier om zekerheid over het niveau van beveiliging te kunnen krijgen.

Correct!

Ik denk dat open source software gewoon even lek is als closed source software. Ik dacht zelfs dat er artikels over zijn geschreven. FOSS staat totaal niet gelijk aan veiligheid. Veiligheid van software loopt eerder hand in hand met hoe geavanceerd en uitgebreid deze is, alsook hoeveel mensen interesse hebben in de veiligheid te kraken.

^ zeer belangrijk stukje tekst!

Dat is hoe een deftige passwordmanager moet werken.

Als je wereldwijde ontwikkelaars hebt zul je op een of andere manier toegang tot die repo moeten geven. Of het nu op GitHub, cloud, of op lokale servers staat. Als credentials in verkeerde handen vallen dan blijft het probleem hetzelfde.
Als de ontwikkelaars allen ouderwets op kantoor bij hun code kunnen dan ben je misschien een stukje beter af.

Open source garandeert inderdaad niets over de veiligheid (of andere kwaliteit) van de software. Maar dat is niet wat er beweerd werd.
Opensource is de enige manier om *zekerheid* over het niveau van beveiliging te kunnen krijgen: je kunt het zelf controleren. Dat is iets anders dan vertrouwen op de blauwe ogen van de verkoper van niet-open software

Interessante gedachte om resources in de 'network perimeter' nog steeds als veiligste oplossing te zien. Volgens mij hebben we geleerd dat deze traditionele opvatting de resources juist kwetsbaarder maakt.

Het verschil tussen public cloud en "klassieke" oplossingen (een digitaal fort met een vuurmuur eromheen) is dat je bij de laatste zelf het toegangsbeleid bepaalt. Zo kun je thuiswerkers verplichten om een VPN (niet zo'n publieke dienst, maar device <-> "de zaak") te gebruiken en authenticatiemethodes naar keuze toepassen. Zo elimineer je ook de risico's op corrupte medewerkers van zo'n clouddienst (en mogelijke third parties waar zij weer aan uitbesteden) - die je, in tegenstelling tot jouw eigen personeel, niet zelf kunt uitkiezen, en sanctioneren.

Als je al het netwerkverkeer via de VPM leidt, kun je ook beter monitoren wat er op computers van thuiswerkers gebeurt; ook voor access-logging en anomaly-detection ben je afhankelijk van cloud-providers als je bij hen diensten afneemt.

Een eerdere breach van Okta dit jaar ontstond doordat een (of meer) van hun ontwikkelaars in een phishing-aanval trapte (zie https://security.nl/posting/768888). Okta had moeten weten dat OTP (HOTP/TOTP) MFA je niet beschermt bij dergelijke aanvallen. En dat je er verstandig aan doet om in browsers DV-certificaten te blokkeren en uitsluitend in zee te gaan met partijen die verstand hebben van authenticatie.

Zie ook mijn vorige reactie: https://security.nl/posting/778732.

Aanvulling 14:33, ik zie een nieuwe post:
Ik heb dat niet "geleerd", wel heb ik veel (zo niet alle) publieke cloud-providers dat horen roepen. Naast dat het je minder geld zou kosten, o.a. aan beheerstaken. Met het risico dat je flink je neus stoot als jij verantwoordelijk bent voor de bescherming van vertrouwelijke (persoons-) gegevens en je er klakkeloos vanuit gaat dat cloud-providers dat allemaal wel voor jou regelen.

Kleine nuance:

Die zekerheid heb je enkel en alleen als je die code ook zelf compileert met een vertrouwde compiler.
Hoe kan je je compiler vertrouwen? Goede vraag...

Zie ook de korte publicatie "Reflections on trusting trust" van Ken Thompson uit 1984.
Nog steeds relevant.

Een netwerk perimeter bouwen, oftewel iets isoleren, is nog steeds een heel veilige oplossing en is zowat het enige dat je kan doen om onveilige of niet meer ondersteunde software te beveiligen. (Ook Anti-virus/anti-malware werkt op die manier.)

Het probleem was dat in het verleden vaak de beveiliging van de gegevens zelf ondermaats was. (Authenticatie, authorisatie, ...) Dit is vooral naar boven gekomen toen dergelijke systemen gedeeld moesten worden met verschillende partijen. (Klanten, 3rd parties, suppliers, vendors, ...)

Het cloud (zero-trust) model zet dit op zijn kop en stelt dat de software (API, ...) publiekelijk toegankelijk moet zijn en de beveiliging op niveau van de data moet gebeuren.

Beide zijn natuurlijk extremen, en zoals steeds zit het ideale voor jou ergens in het midden.

Tot nu toe is het vaak echter nog steeds een stuk makkelijker om een netwerk firewall te configureren en dan om fine grained access controls tot data te beheren... Zeker als je ook wil kunnen reageren op de logs.