Software Security

1. Software Security Karl Lieberherr

2. OMG-MOF M3 layer Meta-metamodel M2 layer Metamodels M1 layer Models M0 layer Application objects MOF UML Metamodel, etc. UML Models, etc. Objects, etc.

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

4. Complexity • Inherent, accidental. • Makes systems hard to understand, analyze, and secure. • May hide security risks.

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

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

7. More risks • More networks • Complexity of software • Extensibility of software • Lack of diversity in popular computing environments

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

9. What is Security • Enforcing a policy that describes rules for accessing resources. • Policy may be explicit or implicit. Better to use explicit policy.

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

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

12. Alternative to penetrate and patch approach • Designing system for security • See chapter 2 • Carefully implement system • Test system extensively before release

13. 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)

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

15. 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?

16. Security Goals • Authentication • Who is it that is trying to do something to the what we want to protect.

18. Java Security at IBM Research(Larry Koved: manager) • Automating Security Analysis of Java Components and Programs • Invocation graphs

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

20. 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?

22. 29 31 25

23. Modeling Secure Software • Hansruedi Thomann

24. Secure Software • Software security can be treated by modelling the software as an automaton with a bi-directional 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.

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

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

27. Buffer overflow • Have function

28. Model for security f: Input/channel input -> Output/channel output Input Automaton Attacker channel Output Attacker can produce channel inputs and regular inputs. It can see the corresponding channel outputs and regular outputs.

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