Software Security

Karl Lieberherr

OMG-MOF
MOF M3 layer Meta-metamodel M2 layer Metamodels

UML Metamodel, etc.

UML Models, etc.

M1 layer Models
M0 layer Application objects

Objects, etc.

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.

Isnt 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.