null
US
Iniciar Sesión
Regístrate Gratis
Registro
Hemos detectado que no tienes habilitado Javascript en tu navegador. La naturaleza dinámica de nuestro sitio requiere que Javascript esté habilitado para un funcionamiento adecuado. Por favor lee nuestros
términos y condiciones
para más información.
Siguiente
Copiar y Editar
¡Debes iniciar sesión para completar esta acción!
Regístrate gratis
801920
Developing Secure Software
Descripción
Mapa Mental sobre Developing Secure Software, creado por lissy93 el 28/04/2014.
Mapa Mental por
lissy93
, actualizado hace más de 1 año
Más
Menos
Creado por
lissy93
hace más de 11 años
15
1
0
Resumen del Recurso
Developing Secure Software
Stages of Security
Security should be factored into every stage of the software development life cycle
Design Phase: a threat model should be drawn up, this will then be refered to and followed throughout the rest of the development process
Security questions should be asked and followed up during interviews
Threat modeling should be a key part of the design process and not rushed
When the design is complete it should be reviewed by the security team
The bug bar and the end-of-line plans should be set too
Implementation phase: the code should be reviewed it it should be formally stated who can modify the code
Test plans must be followed throughout implemntation and development
Testing Phase: testing the security of the application is a crucial part of the testing phase
External Reviews
Security Pushes
Maintainence Phase: The security of the application should continue to be checked and updated
Including a good response service to bug reports
Analiseing a Bug
After a bug is detected a triage process is carried out to determine when how and if a bug is going to be fixed
How many people does this bug affect?
How core is it to the requirements?
How much effort will it take to fix?
How likley is fixing the bug going to cause regression bugs?
(pretty much) All software has bugs in it, just some are so minor or hard to fix, that it's just not worthwhile amending them
Secure by Design, Default and Deployment
Secure by Design
Security should start before the project starts
Guidelines should be produced for all aspects of the project
Learn from project mistakes, and update guidelines and search for similar problems when a potential bug is discovered
Try and work out how the software may be broken, during the design phase (use threat models)
Code that is dificult to maintain should not be used
Secure by Default
Don't give users any higher privalages than is absolutley necissary
Keep it simple
Only include features the are essential
Sensitive data should be treated with care
Secure by Deployment
Provide good security documentation
Patch quickly and well
Provide easy access to safety resources
Additional Principles:
Minimize your attack surface
Use defense in depth
Backwards compatibility can cause issues
Employ secure defaults
Assume external systems are insecure
Plan on failure
Security features are not secure features
Don't mix code and data
Fix security issues correctly
Threat Modeling
You can only defend a system if you have an idea of how people may try an compromise it
Additional benefits of threat modeling
You can understand your code better
You'll find more of the bugs before the users do
They can be used by others to understand your program
They help with testing
Threat modeling is time-consuming, but pretty easy
The process
1. Decompose Application
Must be done in a rigorous and formal manor
Modelling should be used
Data flow diagrams
UML activity diagrams
Capture how information flows through your program
Layered, start at a high level and work down the levels
For each model determine how you and others would break it
2. Determine Threats
STRIDE
Spoofing Identity - can the attacker pretend to be someone there not?
Tampering with data - can the attacker maliciously manipulate data
Repudiation - can the attacker be anonymous
Information Disclosure - can the attacker gain access to information they wearn't supposed to know
Denial of Service - can the attacker use DoS on other users?
Elevation of Privilege - can the attacker access places they shouldn't be
3. Rank Threats
Threat tree's
We can use our threat classification to categorize threats into a tree, and can then model them.
4. Mitigation
Mostrar resumen completo
Ocultar resumen completo
¿Quieres crear tus propios
Mapas Mentales
gratis
con GoConqr?
Más información
.
Similar
Explorar la Librería