Zusammenfassung der Ressource
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