Security Professionals
- ipfw add deny all from eindgebruikers to any
security eisen externe partij
15-08-2012, 14:02 door michiel1980, 6 reacties
Wij gebruiken regelmatig externe ontwikkelpartijen voor ons bedrijf om code te ontwikkelen.
Nu ben ik zelf gaan zoeken op google of er al richtlijnen of best practices zijn voor requirements die wij stellen aan externe bedrijven alleen kan ik niet snel iets heel gericht vinden.
Zo weet ik dat de ISO 27001 een paar risico vragen stelt maar ben eigenlijk op zoek naar een best practice guide.
Dus zaken zoals:
- zorg er voor dat de code volgens de OWASP top 10 geprogrammeerd is (met duidelijke richtlijnen en voorbeelden hoe bepaalde zaken voorkomen kan worden door de zogenoemde prevention examples)
- zorg er voor dat vertrouwelijke informatie over een veilig medium wordt gecommuniceerd (denk aan FTP over SSL, SSH, PGP met duidelijke voorbeelden)
- Non-Disclosure Agreement clausule
- ?
Hebben jullie hier goede links of zelf informatie over?
En ja ik heb zelf al meerdere malen gezocht maar kom vaak uit op de questionnaire van de ISO 27001 en ik zoek wat meer hands on/best practice informatie.
Bvd!
Michiel
Nu ben ik zelf gaan zoeken op google of er al richtlijnen of best practices zijn voor requirements die wij stellen aan externe bedrijven alleen kan ik niet snel iets heel gericht vinden.
Zo weet ik dat de ISO 27001 een paar risico vragen stelt maar ben eigenlijk op zoek naar een best practice guide.
Dus zaken zoals:
- zorg er voor dat de code volgens de OWASP top 10 geprogrammeerd is (met duidelijke richtlijnen en voorbeelden hoe bepaalde zaken voorkomen kan worden door de zogenoemde prevention examples)
- zorg er voor dat vertrouwelijke informatie over een veilig medium wordt gecommuniceerd (denk aan FTP over SSL, SSH, PGP met duidelijke voorbeelden)
- Non-Disclosure Agreement clausule
- ?
Hebben jullie hier goede links of zelf informatie over?
En ja ik heb zelf al meerdere malen gezocht maar kom vaak uit op de questionnaire van de ISO 27001 en ik zoek wat meer hands on/best practice informatie.
Bvd!
Michiel
Reacties (6)
"zorg er voor dat de code volgens de OWASP top 10 geprogrammeerd is (met duidelijke richtlijnen en voorbeelden hoe bepaalde zaken voorkomen kan worden door de zogenoemde prevention examples) "
Dus risico's die toevallig net niet in de top 10 zijn, die zijn acceptabel, ook al kan dat betekenen dat de gebouwde applicatie zo lek als een zeef is ?
Ik ben geen OWASP specialist, maar ik neem aan dat er frameworks zijn met controls waaraan je moet voldoen om een veilige applicatie te bouwen.
Na het bouwen kan je door een ervaren web application auditor/pentester kijken of de applicatie voldoet aan de controls, of er zwakheden gevonden worden, en of er op basis van die bevindingen nog zaken verbeterd moeten worden.
Dus risico's die toevallig net niet in de top 10 zijn, die zijn acceptabel, ook al kan dat betekenen dat de gebouwde applicatie zo lek als een zeef is ?
Ik ben geen OWASP specialist, maar ik neem aan dat er frameworks zijn met controls waaraan je moet voldoen om een veilige applicatie te bouwen.
Na het bouwen kan je door een ervaren web application auditor/pentester kijken of de applicatie voldoet aan de controls, of er zwakheden gevonden worden, en of er op basis van die bevindingen nog zaken verbeterd moeten worden.
Ik geen manier om sluitend "veilige" code (of uberhaupt "goed geschreven" ) te specificeren.
Je doet er denk ik het beste aan om vaak, vroeg en veel te reviewen, zeker ook in de design fase als protocollen en informatie flows vastgelegd worden.
Als controleerbare eis zou je nog kunnen opnemen dat het resultaat 'schoon' door bv compiler warnings komt en door code analysing tools (coverity e.a.) .
Het zal vast wel mogelijk zijn om desondanks security en andere bugs over te houden, maar daarmee ben je al beter dan de meeste andere software.
Natuurlijk betekend het zo nadrukkelijk mee aan tafel zitten dat het uitbesteden van het ontwikkelwerk minder hands-off is dan verwacht, en dat het (vermeende) "we leggen alle problemen bij de leverancier" dan ook niet zo hard gespeeld kan worden als je intensief betrokken was bij de ontwikkeling.
Je doet er denk ik het beste aan om vaak, vroeg en veel te reviewen, zeker ook in de design fase als protocollen en informatie flows vastgelegd worden.
Als controleerbare eis zou je nog kunnen opnemen dat het resultaat 'schoon' door bv compiler warnings komt en door code analysing tools (coverity e.a.) .
Het zal vast wel mogelijk zijn om desondanks security en andere bugs over te houden, maar daarmee ben je al beter dan de meeste andere software.
Natuurlijk betekend het zo nadrukkelijk mee aan tafel zitten dat het uitbesteden van het ontwikkelwerk minder hands-off is dan verwacht, en dat het (vermeende) "we leggen alle problemen bij de leverancier" dan ook niet zo hard gespeeld kan worden als je intensief betrokken was bij de ontwikkeling.
obv gzv (gezond boeren verstand):
maak ook duidelijke afspraken over:
- wanneer de code gereed is (op basis van produkt? gespendeerde tijd? duidelijke requirements? combi van voorgaande?)
- is een twee of volgende release (aantal bugs zijn verholpen) onderdeel van de prijs? of kost extra?
- wie eigenaar van de code is, tijdens produktie en na oplevering
- indien extern bedrijf (die de code ontwikkelt) failliet gaat, waar is de broncode dan opgeslagen/beschikbaar?
- indien extern bedrijf getroffen wordt door calamiteit (oorzaak kan zijn van fout eigen medewerker t/m natuurramp): wie ontwikkelt dan de code voor jullie? is code op alternatieve locatie (backup?) beschikbaar?
maak ook duidelijke afspraken over:
- wanneer de code gereed is (op basis van produkt? gespendeerde tijd? duidelijke requirements? combi van voorgaande?)
- is een twee of volgende release (aantal bugs zijn verholpen) onderdeel van de prijs? of kost extra?
- wie eigenaar van de code is, tijdens produktie en na oplevering
- indien extern bedrijf (die de code ontwikkelt) failliet gaat, waar is de broncode dan opgeslagen/beschikbaar?
- indien extern bedrijf getroffen wordt door calamiteit (oorzaak kan zijn van fout eigen medewerker t/m natuurramp): wie ontwikkelt dan de code voor jullie? is code op alternatieve locatie (backup?) beschikbaar?
Door Anoniem: "zorg er voor dat de code volgens de OWASP top 10 geprogrammeerd is (met duidelijke richtlijnen en voorbeelden hoe bepaalde zaken voorkomen kan worden door de zogenoemde prevention examples) "
Dus risico's die toevallig net niet in de top 10 zijn, die zijn acceptabel, ook al kan dat betekenen dat de gebouwde applicatie zo lek als een zeef is ?
Ik ben geen OWASP specialist, maar ik neem aan dat er frameworks zijn met controls waaraan je moet voldoen om een veilige applicatie te bouwen.
Na het bouwen kan je door een ervaren web application auditor/pentester kijken of de applicatie voldoet aan de controls, of er zwakheden gevonden worden, en of er op basis van die bevindingen nog zaken verbeterd moeten worden.
Dus risico's die toevallig net niet in de top 10 zijn, die zijn acceptabel, ook al kan dat betekenen dat de gebouwde applicatie zo lek als een zeef is ?
Ik ben geen OWASP specialist, maar ik neem aan dat er frameworks zijn met controls waaraan je moet voldoen om een veilige applicatie te bouwen.
Na het bouwen kan je door een ervaren web application auditor/pentester kijken of de applicatie voldoet aan de controls, of er zwakheden gevonden worden, en of er op basis van die bevindingen nog zaken verbeterd moeten worden.
Misschien moet je de OWASP lijst eerst even doornemen voordat je er iets over roept.
Als je mij reeele bekende programmeerfouten kan noemen die niet genoemd worden, dan hoor ik het graag :)
16-08-2012, 14:20 door
ZeteMKaa
Denk dat je zoiets bedoeld.
https://www.ncsc.nl/dienstverlening/expertise-advies/kennisdeling/whitepapers/ict-beveiligingsrichtlijnen-voor-webapplicaties.html
https://www.ncsc.nl/dienstverlening/expertise-advies/kennisdeling/whitepapers/ict-beveiligingsrichtlijnen-voor-webapplicaties.html
16-08-2012, 15:50 door
michiel1980
Yes!
Thanks :)
Thanks :)
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
