Uploaded by visiting faculty11

Software Security

advertisement
Software Security
Karl Lieberherr
OMG-MOF
MOF
M3 layer
Meta-metamodel
UML Metamodel, etc.
M2 layer
Metamodels
UML Models, etc.
M1 layer
Models
Objects, etc.
M0 layer
Application objects
Technical Trends Affecting
Software Security
• Software security = risk management
• Malicious functionality that extends its
primary, intended design.
• Malicious and flawed subsystems may
remain invisible to unsuspecting users until
it is too late.
Complexity
• Inherent, accidental.
• Makes systems hard to understand, analyze,
and secure.
• May hide security risks.
Extensible systems
• Good: we can adapt them to our needs.
• Bad: risk of
– Intentional introduction of malicious behavior.
– Unintentional introduction of vulnerabilities.
• Risks are more pronounced now because of
ubiquitous computer networks: an attacker
no longer needs physical access to cause
security problems.
Idea for home work: Extensibility
through aspects
• Show them how an aspect can extend a
system in a bad way.
• Print join point information: printing out the
password.
• Health care system, patient privacy: charge
more than services provided.
More risks
•
•
•
•
More networks
Complexity of software
Extensibility of software
Lack of diversity in popular computing
environments
Ilities
• Security is like dependability, reliabilitiy and any
other software ‘ility.
• Each ‘ility is a sytemwide emergent property that
requires advanced planning and careful design.
• Better to design for security from scratch.
• Context is important: from proprietary networks to
the internet. Internet-specific risks caused the
systems to loose all their security properties.
What is Security
• Enforcing a policy that describes rules for
accessing resources.
• Policy may be explicit or implicit. Better to
use explicit policy.
Isn’t That Just Reliability?
• Reliability: measurement how robust
software is with respect to some definition
of a bug.
• Definition of a bug analogous to a security
policy.
• Example: Know a remotely exploitable
crasher in a web server: DOS attack.
Penetrate and Patch
• Security is not an add-on feature.
• Some vendors only start to worry about
security after their product has been
publically broken: Rush out a patch.
• In economic terms, finding and removing
bugs in a software system before its release
is orders of magnitude cheaper.
Alternative to penetrate and patch
approach
• Designing system for security
– See chapter 2
• Carefully implement system
• Test system extensively before release
Security Goals
• Secure against what and from whom?
• Prevention threough design/implementation
• Traceability and Auditing: A system for
accountability may disuade potential attackers.
– Essential for forensics: show who did what, when.
– Audit log is itself susceptible to attack.
– Auditing is an essential part of software security (hw 1
on logging using AspectJ)
Security Goals
• Monitoring = real-time auditing.
– Intrusion detection. Danger of too many false
alarms.
– Assertions in the code itself.
– Rarely practiced today. Should be used more.
Security Goals
• Privacy and confidentiality
– Avoid storing secrets in your code.
• Multilevel security
• Anonymity
– Often, technology that degrades anonymity and privacy
turns out to be useful for law enforcement.
– Software developers should think carefully about what
may happen to data they collect. Does convenience
outweigh potential privacy issues?
Security Goals
• Authentication
– Who is it that is trying to do something to the
what we want to protect.
Java Security at IBM Research
(Larry Koved: manager)
• Automating Security Analysis of Java
Components and Programs
– Invocation graphs
HP/Sensorware
• The user injects the query into the network
and the query unfolds to reach all the places
where the distributed algorithm should
execute.
LoD and Security
• Can execute software only if secret is
known.
• Secret consists of set of keys, one per class.
• What is security policy? Each object only
gets keys of its authenticated friends (who
share the same concerns???).
• What are the benefits of such a security
policy? Compartmentalize?
• 29 31 25
Modeling Secure Software
• Hansruedi Thomann
Secure Software
• Software security can be treated by modelling
the software as an automaton with a bidirectional channel, an input and an output
tape.
• The channel is defined in the usual manner,
e.g., as a queue equipped with certain
primitives. The attacker is an (inifinitely
powerful) actor connected on the other end of
the channel. He has full access to the
channel, i.e. he receives the output and can
send arbitrary messages.
Secure Software
• The automaton has the task to compute
a certain transfer function of the inputs
(input tape plus input channel) and,
accordingly, to write results on the
output tape and to return messages on
the output channel.
Secure Software
• The security target is the integrity of the
transfer function. I.e. the security objective is
to enforce a certain functionality, i.e. to make
sure that the automaton performs as
intended. The attacker is successful, if he can
make the automaton to compute a different
function. Data integrity, access control, origin
and entity authentication are special cases
comprised in this definition, but not
exhausting it.
Buffer overflow
• Have function
Model for security
f: Input/channel input -> Output/channel output
Input
Automaton
channel
Attacker
Output
Attacker can produce channel inputs and regular inputs.
It can see the corresponding channel outputs and regular outputs.
Why the channel?
• The primary purpose of f is to map inputs to
outputs. The attacker channel is used, e.g.,
to send illegal inputs with the hope to crash
the automaton or with the hope to change
the state so that a wrong f will be computed.
• The channel is also used to model collecting
information about the system, e.g., to break
pseudo random code generators.
Download