Poll
image

Wat is security-wise de belangrijkste stap in de SDLC?

dinsdag 3 april 2018, 15:51 door Redactie, 11 reacties
Planning
12.11%
Analysis
11.94%
Design
31.34%
Development
8.13%
Testing
17.25%
Maintenance
19.24%
Aantal stemmen: 603
Reacties (11)
03-04-2018, 15:57 door Anoniem
Ik mis de 'Hodor' stap.
04-04-2018, 08:04 door 5ec5ec
Hoewel alle stappen erg belangrijk zijn, is Maintenance naar mijn idee het belangrijkst. Zonder periodiek onderhoud kunnen al de andere facetten al snel achterhaald zijn, hoe goed je planning, analyse, design, dev en testing ook mogen zijn.
04-04-2018, 10:35 door Anoniem
Door 5ec5ec: Hoewel alle stappen erg belangrijk zijn, is Maintenance naar mijn idee het belangrijkst. Zonder periodiek onderhoud kunnen al de andere facetten al snel achterhaald zijn, hoe goed je planning, analyse, design, dev en testing ook mogen zijn.
Daar staat tegenover dat een ontwerpfout die pas ontdekt wordt als het systeem al gebouwd is vreselijk duur kan zijn om op te lossen. In de pre-agile tijd dat het watervalmodel voor systeemontwikkeling voor zo'n beetje alles werd toegepast werd wel geschat dat je de inspanning die het verhelpen van een fout kost per overgang naar een volgende ontwikkelfase met een factor tien omhoog ging. Hoewel agile methoden die dynamiek (hopelijk) verbeteren tijdens een systeemontwikkelingsproject denk ik dat een fundamentele fout in de architectuur van een systeem nog even duur is tijdens de onderhoudsfase als die bij het watevalmode is.

Ik heb in het verleden, vanuit dat watervaldenken, volop meegemaakt dat gedacht werd dat omdat fouten in latere stappen relatief goedkoop op te lossen zijn die fouten er niet zo veel toe doen. Dat werkte slordig werken in de hand en dus werden waar zo gedacht werd veel fouten gemaakt, en vele kleintjes maken een grote, soms uiteindelijk te groot om nog beheersbaar te zijn.

Dat gaat allemaal niet specifiek over beveiligingsaspecten van een systeem maar elke bug kan een beveiligingslek of onderdeel van een beveiligingslek blijken te zijn, dus ik denk dat de redenatie van toepassing is. Mijn conclusie is dat zorgvuldigheid in elke fase nodig is om robuuste systemen te maken en ze robuust te houden, en ik weet dan ook geen belangrijkste stap aan te wijzen.
04-04-2018, 11:01 door Krakatau - Bijgewerkt: 04-04-2018, 11:05
Door 5ec5ec: Hoewel alle stappen erg belangrijk zijn, is Maintenance naar mijn idee het belangrijkst. Zonder periodiek onderhoud kunnen al de andere facetten al snel achterhaald zijn, hoe goed je planning, analyse, design, dev en testing ook mogen zijn.

Ook belangrijk maar ik ga toch voor Development stap. Want problemen met buffer overflows, array overruns, e.d. ontstaan bij de ontwikkeling van de programma code. Veelal door een onvoldoende niveau van de ontwikkelaars. Ik heb ooit bij een bedrijf gewerkt waar men verlangde dat de pseudo-code in het commentaar boven elke functie werd opgenomen in de C source code. Maar men liet wel in Pascal opgeleide programmeurs de C programmacode maken. Dat resulteerde dus in verschrikkelijke problemen, waar de softwarearchitekten en het management geen enkel benul van hadden. Want zij hadden er geen verstand van en de verplichte code review gebeurde ook door Pascal programmeurs. Ze dachten dat ze goed bezig waren en een geweldig goed softwareontwikkelproces hadden. In realiteit waren ze onbewust onwetend.
04-04-2018, 12:01 door 5ec5ec
Door Anoniem:
Door 5ec5ec: Hoewel alle stappen erg belangrijk zijn, is Maintenance naar mijn idee het belangrijkst. Zonder periodiek onderhoud kunnen al de andere facetten al snel achterhaald zijn, hoe goed je planning, analyse, design, dev en testing ook mogen zijn.
Daar staat tegenover dat een ontwerpfout die pas ontdekt wordt als het systeem al gebouwd is vreselijk duur kan zijn om op te lossen. In de pre-agile tijd dat het watervalmodel voor systeemontwikkeling voor zo'n beetje alles werd toegepast werd wel geschat dat je de inspanning die het verhelpen van een fout kost per overgang naar een volgende ontwikkelfase met een factor tien omhoog ging. Hoewel agile methoden die dynamiek (hopelijk) verbeteren tijdens een systeemontwikkelingsproject denk ik dat een fundamentele fout in de architectuur van een systeem nog even duur is tijdens de onderhoudsfase als die bij het watevalmode is.

Ik heb in het verleden, vanuit dat watervaldenken, volop meegemaakt dat gedacht werd dat omdat fouten in latere stappen relatief goedkoop op te lossen zijn die fouten er niet zo veel toe doen. Dat werkte slordig werken in de hand en dus werden waar zo gedacht werd veel fouten gemaakt, en vele kleintjes maken een grote, soms uiteindelijk te groot om nog beheersbaar te zijn.

Dat gaat allemaal niet specifiek over beveiligingsaspecten van een systeem maar elke bug kan een beveiligingslek of onderdeel van een beveiligingslek blijken te zijn, dus ik denk dat de redenatie van toepassing is. Mijn conclusie is dat zorgvuldigheid in elke fase nodig is om robuuste systemen te maken en ze robuust te houden, en ik weet dan ook geen belangrijkste stap aan te wijzen.

Hoewel je een redelijk solide betoog houdt (design is belangrijk, en beter iets voorkomen dan genezen), kan je design nog zo goed zijn, maar kan deze morgen alweer verouderd zijn. Ik ben het met je eens dat je fouten niet moet negeren om het door te schuiven naar een latere fase, echter denk ik dat naast fixes ook andere aanpassingen gemaakt dienen te worden om het systeem te beschermen tegen actuele vulnerabilities. Daarbij zullen fouten nagenoeg altijd nog voorkomen, omdat niet elke situatie te voorzien is.
04-04-2018, 12:43 door Anoniem
Testen is in elk SDLC de meest belangrijke fase. Daar begin je mee als je erover na gaat denken en alle stappen zijn getoetst door testen, testen en testen. Alle vormen van testen zijn goedgekeurd. Gezien de staat van heul veul software is dit de enige manier waarop de bagger die als goed product opgeleverd wordt eindelijke de status "kwalitatief hoogwaardig" verdient. En daar zijn vakmensen voor nodig. Testers heten die! Dat is een vak, dat doe je er niet even bij. En fouten worden er niet in getest of als je niet test dan zijn er ook geen fouten...Ja, ze bestaan nog steeds ;).
Je koopt wel software van miljoenen wat amper goed getest is, maar een auto vn 10K die niet getest is koop je niet.
Dus samenvattend: testen is de belangrijkste fase in elk SDLC. als je niks test weet je niks van de status en kwaliteit van het product en kun je er ook niks over zeggen. Dus...
<einde>
(en nee, ik ben geen tester...)
04-04-2018, 14:55 door Anoniem
Security by Design.
04-04-2018, 16:14 door Anoniem
Ik kies toch voor Analyse, want het is binnen kwaliteitsmanagement wel PLAN-Do-Check-Act.
Dus eerst Denken en dan Doen.

Oftewel je moet eerst weten WAT je waarom gaat doen, voordat je kunt ontwerpen en de rest vd stappen uitvoeren.
Want het is altijd mogelijk dat datgene waar je voor ontwerpt geen veiligheidsaspect vereist. Dus hoef je niet meer te doen dan nodig...
04-04-2018, 17:06 door MathFox
Kritische discussies en reviews, reviews, reviews. Het ISTQB rekent dat (ook) tot testen.
04-04-2018, 17:09 door Anoniem
Natuurlijk altijd SBD, daarna niet vergeten OLE&E te doen en tot slot OLADL.
Gaat het dan alsnog fout gooi er maar een 8D tegenaan.
05-04-2018, 10:46 door Anoniem
Rare vraag naar mijn idee en dit is niet de eerste die hier wordt gesteld.

Het is een cirkel dat zegt dat je al deze dingen moet doen voor System/Software Development Life Cicle (SDCL). In mijn optiek is er geen belangrijkste, maar zijn ze allemaal even belangrijk. Anders had de maker van dit model dit vast ook wel aangegeven in het model.
Misschien is dat ook wel de fout die gemaakt wordt binnen bedrijven. Dat bedrijven zich op een ding te veel concentreren en dan gaat het fout. De rest wordt vergeten door te veel te kijken naar een ding.

Ik heb niet gestemd op deze vraag!
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search