One Article Review
| Source |  NoticeBored |
|---|---|
| Identifiant | 5871325 |
| Date de publication | 2022-07-22 17:10:27 (vue: 2022-07-22 07:05:34) |
| Titre | Security in software development |
| Texte |  Prompted by some valuable customer feedback earlier this week, I've been thinking about how best to update the SecAware policy template on software/systems development. The customer is apparently seeking guidance on integrating infosec into the development process, which begs the question "Which development process?". These days, we're spoilt for choice with quite a variety of methods and approaches. Reducing the problem to its fundamentals, there is a desire to end up with software/systems that are 'adequately secure', meaning no unacceptable information risks remain. That implies having systematically identified and evaluated the information risks at some earlier point, and treated them appropriately - but how?The traditional waterfall development method works sequentially from business analysis and requirements definition, through design and development, to testing and release - often many months later. Systems security ought to be an integral part of the requirements up-front, and I appreciate from experience just how hard it is to retro-fit security into a waterfall project that has been runnning for more than a few days or weeks without security involvement.A significant issue with waterfall is that things can change substantially in the course of development: the organisation hopefully ends up with the system it originally planned, but that may no longer be the system it needs. If the planned security controls turn out to be inadequate in practice, too bad: the next release or version may be months or years away, if ever (assuming the same waterfall approach is used for maintenance, which is not necessarily so*). The quality of the security specification and design (which drives the security design, development and testing) depends on the identification and evaluation of information risks in advance, predicting threats, vulnerabilities and impacts likely to be of concern at the point of delivery some time hence.In contrast, lean, agile or rapid application development methods cycle through smaller iterations more quickly, presenting more opportunities to update security ... but also more chances to break security due to the hectic pace of change. A key problem is to keep everyone focused on security throughout the process, ensuring that whatever else is going on, sufficient attention is paid to the security aspects. Rapid decision-making is part of the challenge here. It's not just the method that needs to be agile!DevOps and scrum approaches use feedback from users on each mini-release to inform the ongoing development. Hopefully security is part of that feedback loop so that it improves incrementally at the same time, but 'hopefully' is a massive clue: if users and managers are not sufficiently security-aware to push for improvements or resist degradat |
| Envoyé | Oui |
| Condensat | $20 so whether another prompted reducing the about according accountability address adequacy adequate adequately admin advance agile along also analysis anticipated anything apparently application appreciate approach approaches appropriately architecture are areas aspects assuming attention authorisation/approval aware awareness away backups bad: been begs being best bloat both break bugs business busy but can capabilities challenge challenging chances change changes checkpoints choice choose chosen circumstances classical clue: coding collaborating colleagues common competing complexity concern concerns contrast controls conversely could course cover cover:an critical critically cryptographic customer customers cycle cycles days decision deep deeper definition degradation degrade delivery delve depends depth design designers desire details developed developers developing development development: devops dig down driven drives driving due dynamically dynamics each earlier else end ends engineering ensuring evaluated evaluation ever everyone experience factors feedback find first fit flaws focused from front functions fundamentals general get going guidance hard has have having hectic hence here hopefully how identification identified impacts implications implications; implies improve improvements improves inadequate increased incrementally inform information infosec initially integral integrating investment involved involvement issue issues iterations iterative its just justified keep key later leaders lean least leave less likely little longer loop lurking maintained maintenance makes making management managers many market massive matter matures may meaning method method:the methods metrics mindset mini modify/supplement monitoring months more moves moving necessarily need needed needs next not noted often one ongoing opportunities opportunities;security opportunity order organisation originally other ought out over overall pace pace;progress paid part perfection;flexibility personally planned plus point policies policy possible;sufficient practice predicting present presenting priorities prioritising priority problem procedures process processes project project/team purpose push quality question quick/superficial quickly quite rapid ratchet rather react readily reduce regardless release released reliant remain remaining remains reporting requirements resembling resist resisting resources resourcing responding retro retrograde right risk risks runnning safety same scrum secaware secure security seeking seen seizing sense sequentially settle several short significant slow smaller so* software software/system software/systems some something specification speed spoilt striving substantially such sufficient sufficiently suit suitable suits supporting/enabling system systematically systems take tasks team technology template tendency testers testing tests than them these things think thinking thorough those threats through throughout tight time too top towards traditional treated troublesome turn unacceptable uncomfortable update use used user users usual vain valuable value variety various version very vulnerabilities waterfall week weeks welcome what whatever where which willingness wise wish within without work works would years your |
| Tags | Guideline |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.