Software Security
Software Security
Karl Lieberherr
OMG-MOF
MOF M3 layer Meta-metamodel M2 layer Metamodels
M1 layer Models
M0 layer Application objects
Objects, etc.
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.
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.
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.
Security Goals
Authentication
Who is it that is trying to do something to the what we want to protect.
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.
29 31 25
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
Output Attacker can produce channel inputs and regular inputs. It can see the corresponding channel outputs and regular outputs.