DevOps omgeving en security vraag

[Furion2000]

Ik werk in een DevOps achtige omgeving, alles van k8s configuratie tot de ontwikkeling van software (java/kotlin/angular) wordt bij ons op de afdeling gedaan.

Er wordt ook steeds meer aandacht geschonken aan security en tot dusver was het altijd makkelijk doordat er OF niet over gepraat werd OF er was iemand senior genoeg die ik 'gewoon' geloofde.

Steeds meer en meer beland ik alleen in gesprekken over security, met beperkte kennis vindt ik zelf. Het is alleen wel dat hoe meer ik lees over het onderwerp naar aanleiding van die gesprekken dat ik erg veel lege argumentatie spot in de meer senior/architecture achtige rollen. Mijn conclusie is eigenlijk dat er erg veel over geluld wordt, maar maar weinig tot in de kern kennis aanwezig is EN er maar weinig hands-on uitgeprobeerd word (automatisch gevolg gok ik als je denkt dat je het weet).

Ik blijf redelijk neutraal tot dusver en volg, maar het begint te wringen.

Dingen zoals 'we moeten x gebruiken' en als antwoord op de waarom vraag krijg je -> 'dat is meer secure', dan ga ik lezen en inderdaad eerste 10 google hits zetten dat het secure is, maar met maar bar weinig onderbouwing wat het nou echt secure maakt. Allemaal in de trant van ja dan kunnen we meer data krijgen van wat er door de deur komt, maar het is niet echt een slot op de deur ofzo. (1 voorbeeld als illustratie, gelieve niet hierop inhaken, want ben bang dat dan mijn vraag in het niet verdwijnt)

Vaak krijg ik game of thrones flitsen waarbij ik die dienstmeiden telkens 'it is known' zie zeggen op een of andere bullshit gewoonte

Mijn vragen
- Zien jullie dit ook binnen jullie organisaties?
- Hoe kan ik mijzelf ontwikkelen om echt meer core security kennis te krijgen?


Wat ik al gevonden of geprobeerd heb
Boeken en artikelen omvatten vaak ook te weinig detail om het 'waarom' uit te leggen, zelf zit ik te denken om de werkgever wat tijd met een security expert te vragen zodat hij mij op weg kan helpen. Voordat ik doe wil ik hier eerst even proberen of er nog betere inzichten komen?

@Woy als het niet helemaal devschuur is, kick me dan aub naar de juiste, ik twijfelde

[pennywiser]

Ik vind het al knap dat je je realiseert wat je niet weet. Ik weet niet of het je helpt, maar ik hanteer een zero-trust houding en zoek in de regel de techniek bij datgene waar ik aan werk. Je moet het dan vervolgens juist wel ter discussie stellen om gaten te spotten die jij over het hoofd hebt gezien, of security die niets toevoegt aan veiligheid alleen maar schijn.

Dus ja, blijf je verdiepen in security technieken, kom met argumenten voor en tegen elke keer dat je gevraagd wordt iets te zeggen over de security van een applicatie of toegang, en zorg dat je zelf op wat meer senior kennis niveau komt op dit onderwerp.

Dingen als "meer" secure word ik ook kriegelig van.

Ik moet bij security altijd denken aan de vliegtuig cockpit, captain en co-piloot hebben altijd de onderlinge afspraak dat ze elkaars vergissingen direct bij elkaar melden. In de opleiding wordt dat al aangeleerd. Senioriteit of angstcultuur mag geen issue zijn, je begrijpt denk ik wel waarom. Misschien dat je het kan plaatsen wat ik ermee bedoel.

[ Voor 22% gewijzigd door pennywiser op 24-09-2023 19:05 ]

[CyBeRSPiN]

Hoe groot is het bedrijf waar je werkt? Hebben ze wel specialisten in dienst die de boel reviewen en (laten) testen?
Anders zijn het misschien inderdaad loze kreten..
Als je die kant op wilt ontwikkelen is het wel deze houding die je verder gaat helpen vermoed ik

[The Eagle]

Je stipt denk ik het grootste verschil aan tussen DevOps en devsecops.

Heb je van de week wat te doen? https://cybersecuritycloudexpo.com/europe/
Gewoon rondwandelen, sfeer proeven, meetings bijwonen, gesprekjes aanknopen. Gaat niet diep de inhoud in meestal, geeft wel een leuk beeld

Verder: duik Udemy op, kijk naar een training certified ethical hacker. Niet dat je dat cert moet halen, maar dan snap je de technieken en de motivatie er achter.
* The Eagle wil die ook nog eens doen bedenk ik me net.

Last: cybersecurity is een breed vakgebied en wordt nog breder als je hem naar informatiebeveiliging doortrekt. Cybersecurity zegt vooral hoe (gebruik https want veiliger); informatiebeveiliging geeft je een waarom.

[Furion2000]

@pennywiser klopt zero-trust is een veelgenoemde term die ik nu en voel er wel wat voor, maar ik wil dus inderdaad het fijne ervan weten.

Wat je noemt is voor mij eigenlijk al devops, die leer cultuur. Die zit snor en vandaar dat de vragen ook steeds meer komen, we willen vooruit en beter

@CyBeRSPiN afdeling van 50 man denk ik, maar dus devops in een veel groter bedrijf. Alles kan in principe, maar alles wat buiten de afdeling gebeurt is traag en binnen de afdeling is geen persoon die echt het fijne ervan af weet.

@The Eagle Was bijna geneigd te gaan, maar krijg het niet in mijn agenda zo kort dag

Enige persoon van wie ik dacht 'ja die snapt het' was bij een presentatie van Frank van Vliet (aanrader) en die is van origine volgens mij ethical hacker dus ik ben wel gevoelig voor je udemy punt.

Dus in mijn verhaal lijkt het erop dat er op de afdeling vooral CyberSecurity word gepraat en dat ik op zoek ben naar informatiebeveiliging antwoorden?

[ Voor 4% gewijzigd door Furion2000 op 24-09-2023 21:05 ]

[The Eagle]

Als jullie een heel DevOps team hebben zitten, loopt er ongetwijfeld een solution architect of Enterprise architect rond. Vraag die eens naar hoe ze bepalen hoe veilig iets moet zijn, welke eisen er dan gelden en wat dat dan impliceert. Als je een goede hebt leer je heel veel van zon gesprek

[The Eagle]

Hele korte versie: zie Wikipedia: BIV-classificatie als uitgangspunt.
In principe heeft iedere applicatie / stuk software een dergelijke codering, of kan die hebben.
Meestal wordt die codering gedaan van 1 tm 4 of 0 tm 3. Op basis van een dergelijke classificatie kun je sturen hoe veilig iets moet zijn, maar ook integriteit (hoe onmogelijk moet het zijn om met de data te knoeien, wie kan er bij en hoe, waarom en wat mag dus niet). Beschikbaarheid hoef ik hopelijk niet uit te leggen
Maar long story short: op basis van een dergelijke codering kun je sturen op standaard regels, controls en technische vereisten per level en per B, I en V. De rest is een kwestie van wat wel en wat niet.
Verder spelen daar, zeker bij grote bedrijven, ook zaken als business continuity, mogelijkheid tot financiële of imagoschade, etc mee. Leuk vakgebied

Al zie je ook dat men vaak van oplossing tot oplossing gaat kijken, en telkens de zelfde discussies heeft. Want ja, budget was x, security implementeren kost meer tijd en dus geld en dat moet een projectleider dan weer ergens vandaan toveren want niet begroot

[Furion2000]

The Eagle schreef op zondag 24 september 2023 @ 21:18:
Als jullie een heel DevOps team hebben zitten, loopt er ongetwijfeld een solution architect of Enterprise architect rond. Vraag die eens naar hoe ze bepalen hoe veilig iets moet zijn, welke eisen er dan gelden en wat dat dan impliceert. Als je een goede hebt leer je heel veel van zon gesprek

Ik zal eens op zoek gaan, want er schiet er geen te binnen

The Eagle schreef op zondag 24 september 2023 @ 21:32:
Hele korte versie: zie Wikipedia: BIV-classificatie als uitgangspunt.
In principe heeft iedere applicatie / stuk software een dergelijke codering, of kan die hebben.
Meestal wordt die codering gedaan van 1 tm 4 of 0 tm 3. Op basis van een dergelijke classificatie kun je sturen hoe veilig iets moet zijn, maar ook integriteit (hoe onmogelijk moet het zijn om met de data te knoeien, wie kan er bij en hoe, waarom en wat mag dus niet). Beschikbaarheid hoef ik hopelijk niet uit te leggen
Maar long story short: op basis van een dergelijke codering kun je sturen op standaard regels, controls en technische vereisten per level en per B, I en V. De rest is een kwestie van wat wel en wat niet.
Verder spelen daar, zeker bij grote bedrijven, ook zaken als business continuity, mogelijkheid tot financiële of imagoschade, etc mee. Leuk vakgebied

Al zie je ook dat men vaak van oplossing tot oplossing gaat kijken, en telkens de zelfde discussies heeft. Want ja, budget was x, security implementeren kost meer tijd en dus geld en dat moet een projectleider dan weer ergens vandaan toveren want niet begroot

Interessant, ik ben het nog niet tegengekomen of we hebben er onze eigen draai aan gegeven, ik zal eens gaan nazoeken wat de standaarden zijn.

[JJ Le Funk]

je kan wellicht een pen-test uitvoeren tegen een specifieke applicatie en op basis van de uitkomsten gericht verdiepen in het verbeteren van de security.
anders vrees ik dat het onderwerp oneindig diep en breed is.

[Oon]

Ik zou het idee opgooien om concreet met een kleiner groepje een wekelijkse/maandelijkse sessie over security te starten, met daarin voor ieder punt wat expliciete punten die besproken moeten worden; wat is er fout aan de huidige situatie, wat zijn de risico's hiervan, wat is de gesuggereerde oplossing, en hoe lost die oplossing de risico's/fouten op.

Daarmee voorkom je 'dat is meer secure', want dan moet er op z'n minst aangegeven worden dat er bijv. alleen plaintext authenticatie mogelijk is in de huidige situatie, en de oplossing ook public key authenticatie en/of MFA toestaat, of ga je het hebben over concrete exploits die mogelijk zijn.

Daarnaast heb je dan de mogelijkheid om kennis over security te delen en plenair of individueel onderzoek te doen over de opgedragen discussiepunten, in plaats van dat het een grotepiemelgevecht wordt op basis van ego en senioriteit. Als je onderzoek hebt gedaan dat het tegendeel bewijst deel je dat, en iedereen die bij dat groepje zit moet ook de insteek hebben om de situatie te verbeteren en niet alleen z'n gelijk te krijgen.

[ Voor 9% gewijzigd door Oon op 27-09-2023 14:43 ]

[Falcon]

Bij ons greenfield projecten zijn ieder geval de volgende zaken al standaard en volgens mij is dit ook laag hangend fruit wat in ieder ontwikkelclub een investering van tijd/geld/capaciteit geniet:

1. Neem x effort per maand ruimte in de planning voor technisch onderhoud (upgrades van dependencies etcetra valt daar simpelweg onder
2. SonarQube/Cloud heeft plugins, gebruik/configureer die)
3. Dependency-bot is goud waard
4. OWASP scan pipline die gescheduled is, kost je geen tijd bij het opzetten daarvan. Ga de eerste keer eens goed door de resultaten heen en houd het daarna bij.
5. Laat door bijv. een ZeroCopter bij grotere epics een scan uitvoeren op een omgeving waar ze volledige vrijheid krijgen en pak de prio1's gelijk op en analyseer of deze misschien al eens misbruikt zijn.
6. Stel 1 persoon verantwoord binnen het team of teams, die dit als expertise wil ontwikkelen. Verantwoordelijkheid blijft natuurlijk liggen bij iedereen.
7. Ik lees ook steeds meer over A.I. minded extensions die op basis van jouw codebase en infra config scans in je IDE kan uitvoeren. Nadeel is nog dat niet elke organisatie natuurlijk dit zomaar wil. Maar dit is vast de toekomst

Security is allemaal niet zo moeilijk, maar vraagt naast performance als non-functional risico wel gewoon aandacht en is onderdeel van je kwaliteitsproces/risico management.

Maak je vooral niet zelf afhankelijk van 1 persoon in de organisatie, want als shit hits the fan .. uiteindelijk zit jij met je team ook in weekend te werken. Wees kritisch naar elkaar en neem bijv op in de Definition of Ready bij Features/PBI's template zodat het in iedergeval een minuutje aandacht krijgt tijdens een (Pre)- Refinementsessie.

En als iedereen elkaar als apen aan zit te staren.. erken dan dat er kennis/ervarings gebrek is en geef dit aan als risico bij de PO-er/Mgt.

[ Voor 10% gewijzigd door Falcon op 29-09-2023 11:45 ]

[Furion2000]

Falcon schreef op vrijdag 29 september 2023 @ 11:38:
Bij ons greenfield projecten zijn ieder geval de volgende zaken al standaard en volgens mij is dit ook laag hangend fruit wat in ieder ontwikkelclub een investering van tijd/geld/capaciteit geniet:

Zeer praktische aanpak en eigenlijk wat ik eruit pik is het stukje dat je in je aanpak een ethical hacker erbij haalt om je te vertellen wat er nog nodig is. Iemand van wie het zijn werk is om je systeem te hacken en gegevens te stelen.

Dit wordt bij ons nog niet gedaan en dus reageer je in discussies vooral op 'hear say' lijkt het. Wat je zegt, mensen die zich er meer in verdiepen is wel vereist. Bedoel je dan wat praktische kennis opdoen richting ethical hacking of meer in algemenere zin?

Vraag mij nu wel af hoe dit bij banken wordt gedaan. (ik denk dat hier het meest geinvesteerd zal worden in infosec...)

[downtime]

Furion2000 schreef op vrijdag 29 september 2023 @ 14:32:
[...]

Vraag mij nu wel af hoe dit bij banken wordt gedaan. (ik denk dat hier het meest geinvesteerd zal worden in infosec...)

Banken formaliseren dit soort dingen. Zo heb je dedicated security medewerkers, (verplichte) trainingen, maar ook resources die je kunt gebruiken. CIS biedt bijvoorbeeld allerlei checklists voor populaire software die je kunt gebruiken als leidraad.
Het belangrijkste is dat management dit moet trekken, erin moet investeren, en voor een cultuuromslag moet zorgen. Het is heel moeilijk om dat vanaf de werkvloer voor elkaar te krijgen want dan blijft het meestal beperkt tot één afdeling.

Banken hebben ook het voordeel dat ze onder toezicht van allerlei instanties staan en het moeten uitleggen als ze niet actief met security bezig zijn. Ik merkte ook bij voormalige werkgevers dat management steeds meer aandacht voor security kreeg omdat de druk vanuit auditors en toezichthouders steeds groter werd.

[Arch-IT-ect]

Ik sinds anderhalf jaar geleden ook in het security wereldje terecht geraakt. Wat je ik lees bij jou, klinkt het alsof de organisatie nog wat in het ondiepe aan het ploeteren is.

Wanneer je spreekt over security, moet er naar een mature aanpak worden gestreefd. Ik weet niet welk type data je organisatie beheerd, maar op z'n minst een SDLC (Secure Development LifeCyle) laten respecteren van developers is een must. Daarnaast vind je op de website van de OWASP foundation (https://owasp.org/ ) tal van info en best practices. Ik stel voor dat je die bekijkt (ook veel van de initiatieven etc). Je zal hiermee al een heel tijdje zoet zijn, maar het bevat een schat aan informatie.

Ik las hier iets van zero trust... Tijdens de laatste Technorama hier in België zag ik een sessie van iemand uit Finland (naam vergeten) en die zei dat zero trust een bad practice is. Het werkt contraproductief. In plaats daarvan degelijke walled security inbouwen. Zelf met zero trust kan iemand die écht wil binnen zijn, een deur forceren. En als je maar 1 deur hebt die voor niemand open gaat en die gaat toch open, dan zit de bad actor binnen.
Bij walled security creeer je obstakel, na obstakel, na obstakel voor bad actors vooraleer ze binnen raken. Meestal haken ze na een bepaalde tijdspanne reeds af en heeft je infrastructuur stand gehouden. Bij zero trust en weinig controls, zit je soms met een vals gevoel van veiligheid en met 1 gerichtje, slimme aanval, kan heel je security in duigen vallen.

[HenkEisDS]

Furion2000 schreef op zondag 24 september 2023 @ 18:44:

Dingen zoals 'we moeten x gebruiken' en als antwoord op de waarom vraag krijg je -> 'dat is meer secure', dan ga ik lezen en inderdaad eerste 10 google hits zetten dat het secure is, maar met maar bar weinig onderbouwing wat het nou echt secure maakt.

Je kunt al beginnen met voortaan door te vragen. Jij moet het uiteindelijk ook aan de klant die ergens voor betaalt kunnen uitleggen. Een voordeur met 4 sloten is meer secure dan een voordeur met 1 slot, maar als niemand jou uitlegt wat de toegevoegde waarde van die 3 sloten is dan lever je nooit de beste oplossing voor de klant. Eén slot is namelijk voor 99.9999% van de gevallen veilig genoeg en als jij niet kunt uitleggen waarom die 3 extra sloten nodig zijn dan sta je imho flink voor lul. Daarnaast vraag je ook door omdat je een oplossing wil begrijpen. Als ik iets begrijp onthou ik het, als ik iets maar half begrijp niet.

Of om Simon Sinek te quoten:
"Asking questions doesn't mean you're the stupidest person in the room; it usually means you're the only one brave enough to speak up."
YouTube: The Truth about Being the "Stupidest" in the Room | Simon Sinek

[Furion2000]

@Arch-IT-ect en de rest, ik ben redelijk bekend met OWASP, kunnen we stellen dat dit de 80% omvangt als je dit goed in de smiezen hebt?

Zero trust is toch dat je binnen OOK camera's ophangt in het geval van de deur en het huis? Dus eigenlijk ook obstakel na obstakel? Althans zo begreep ik hem. Hoever je daarin wil gaan is 2.

@HenkEisDS klopt, een stukje naïef automatisch respect voor bepaalde functies, maar ook gewoon moeten doorvragen. Het besef begint te komen