Software Engineering for Security: A Roadmap

1. Software Engineering for Security:A Roadmap P. T. Devanbu & S. Stubblebine

2. Motivation • Applications are becoming increasingly network-aware and/or network available • Software Engineering approaches must now consider security as a fundamental application requirement • Software Engineers must recognize security threats and engineer systems with credible defenses

3. Degrees of Security Requirements • Threats from security problems can range from very mild to disastrous • Security protection must be balanced with the requirements of particular applications • Consider the security needs of a control system for a power plant versus a professors course website

4. Policies and Requirements • Security Policy • The set of laws, rules and practices that regulate how an organization manages, protects and distributes sensitive data • Security Requirements • A manifestation of a high-level organizational policy into the detailed requirements of a specific system • Generally security requirements should be specified as NON-FUNCTIONAL Its very hard to properly integrate security into a system afterits been implemented!

5. Security Policies [Has Access To] • Security policies determine how subjects are granted access to objects • Simple Models – CapabilityS > CapababilityO • More Complicated Models – Policy Languages • Example: J2EE Declarative Security, Windows Group Policies Subjects Objects

6. Software Engineering Challenges • Unifying Security with Systems Engineering • Engineering practices balance time, money and resources – how much should be invested in security design • Unifying Security and System Models • System models are used to design software, we need to integrate security into this activity and develop models for security

7. Security and Software Architecture • Given the plethora of software designed with limited security capabilities we need the ability to reengineer security into existing systems • Poor Planning – Insufficient emphasis on security in the software engineering activity • Using Systems in different environments from which they were designed • Making a mainframe system available over the internet • Legacy Mismatches – integrated security capabilities of multiple middleware technologies • Integrating J2EE security with operating system security

8. Aspect Oriented Programs • Security must be integrated into all system components • Maintain security code “scattered” throughout the source • Treat security as an “Aspect”, use an Aspect-Oriented compiler to treat security as a single concern, allowing the compiler to weave the security code into the source prior to compilation

9. Software Piracy and Protection • The cost of software piracy is large, estimated at $15-20 Billion Annually • Must make it harder to pirate software, or dramatically increase the cost associated with getting caught • Breaking software protection techniques is relatively easy

10. Software Piracy Model Given that we need “n” copies of software, the currentsituation is that: • Thus, the disincentive to pirating software is not high enough • Some efforts are being made to reduce this due to the ease of copying these days – consider Kaaza n* Cbuying >> Chacking + n*Ccopying + ProsecutionProbability(n) * Ccaught(n)

11. Protection Approaches • Hardware and/or Software Tokens • Manage license codes • Dynamic Decryption of Code • Decrypt deployed code based on a key • Watermarking • Identify each copy to tie it back to the owner as a means to increase the probability of getting caught • Code Partitioning • Place license checking code into a non-hackable medium such as special ROMs or smart cards

12. Trusting Software Components • Software systems are rarely built from scratch – overall security is only as good as the “weakest link” in the system • Problem: How do we measure the security of COTS components that we integrate into systems • COTS tend to be closed source – to a large degree we must trust or validate the security claims made by the owner of the COTS components

13. Trusting Software Components • What can we do about COTS components • Black Box: Extensively test COTS components within the system context • Gray-Box: Avoid duplicated testing efforts by working with the owner of the COTS software to disclose their security validation approaches without having them compromise much of their intellectual property

14. Secure Software Development • Source code scanning tools to inspect for known security anti-patterns • Eliminate security problems from within the code • Software Configuration Management • Problems caused by COTS software or common components that may be exist in many versions and be used by multiple applications – Consider the Windows Platform

15. A Shameless Plug • Software Security Work by the SERG Lab: • Characterizing the Security Vulnerability Likelihood of Software Functions • Goal: Simplify the auditors job by minimizing the amount of code to be inspected • Using Program Transformations to Secure C Programs Against Buffer Overflows • Goal: Use semantic preserving transformations to replace unsecure buffer allocations with secure buffer allocations • Papers available at http://serg.cs.drexel.edu