Software Engineering for Security: a Roadmap

1. Software Engineering for Security: a Roadmap Presented by Aatash Patel Pangsha Qiu Huanzhong Qiu

2. Outline • Why is Security Important? • Threats to Software Systems • Methods of Attack • Security Policy &Models • Re-engineering for security and challenges • Software Piracy & Protection • Trusting Software Components • Verification of Systems • Secure Software Deployment • Conclusion CSci599 Fall 2001

3. Why is Security Important? • “Is there such a thing anymore as a software system that doesn’t need to be secure?” • Why? • Internet • COTS • Mobile code • High software price • Difficulties • Designing a truly secure system is too expensive • Limited development resources force security compromises CSci599 Fall 2001

4. Threats to Software Systems • Leakage: Acquisition of information by unauthorized recipients • Tampering: Unauthorized alteration of information or programs • Resource stealing: Use of facilities without authorization • Vandalism: Interference with the proper operation of a system CSci599 Fall 2001

5. Methods of Attack • Eavesdropping: Obtaining copies of messages without authority • Masquerading: Sending or receiving messages using identity of another principal without authority • Message Tampering: Intercepting messages and altering contents before passing them on to the intended recipient • Replaying: Storing messages and sending at a later time CSci599 Fall 2001

6. Security Policy • “Security Policy is the set of laws, rules and practices that regulate how an organization manages, protects and distributes sensitive information” • Security Mechanisms are employed to implement security policies • Security requirements • Afterthought • Non-functional CSci599 Fall 2001

7. Security Models • Abstractions used to represent a security policy of an organization • Early formulation of security policies • Mandatory Access Control (MAC) • Security objects and security subjects are assigned to security labels Classification: Confidential < Classified < Secret < Top Secret Clearance: Public < Company Confidential < High Security • Security level of an object O is called its classification, Class(O) • Subject S must be cleared to access sensitive information, Clear(S) • A subject can access an object if the clearance level of the subject is at least as high as the classification of object, Clear(S)Class(O) • Discretionary Access Control (DAC) • Users can protect the data they own • The owner may grant access to others • The owner may define the type of access (read, write, execute) to others • Granting and revoking of access permissions is under the discretion of the user themselves CSci599 Fall 2001

8. Security Models (2) • Multi-level security model • Security level consists of two components: hierarchical list of sensitivity levels & member of a set of compartments • Objects are readable and writable • Subjects and objects with assigned security levels • Successful read access: Clear(S) Class(O) • Successful write access: Clear(S) Class(O) • Challenge in integrating security requirements analysis with the standard requirements process CSci599 Fall 2001

9. Integration Challenges • Unifying Security & System Engineering • System engineer analyzes and selects market-critical features to maximize revenue • Security engineer must develop applicable threat models & select security measures most needed for market success • Unifying Security & System Models • Software engineers use high-level, object- oriented models (UML) for requirements engineering and design activities • Extend standards like UML to include modeling of security features like privacy, integrity, access control etc. • Challenge is to extend syntax and semantics of standards to address security concerns • Develop tools and processes to unify design of systems and security policies CSci599 Fall 2001

10. Re-Engineering for Security • Security, an afterthought • Need to refine requirements and design process to bring an earlier focus on security issues • Internet • Need re-engineering of legacy system to include security concerns • Problems: Architectural Mismatches CSci599 Fall 2001

11. Re-engineering challenges • Legacy Security Mismatches • Mismatch between security framework in legacy and target systems • Need for uniform security policies and mechanisms across different platforms • Separating the Security “Aspect” • Difficult to identify code in legacy system that is relevant to security, changing it, and integrating changes into the system • Aspect-oriented programming: Change the way a system is distributed and isolate security aspect of the code • Software Architecture: Security concerns are placed with architectural connectors CSci599 Fall 2001

12. Software Piracy & Protection • Adversary Economics Cost of one item Cost of first hack the copy protection Cost of each item after hacked Risks of getting caught(prosecution Prob.) Possibly subjective cost of each item(fine) CSci599 Fall 2001

13. Software Piracy & Protection (2) • Then how to protect software? *reduce to zero, free software *increase Prob. of capture *increase and • Hardware and Software Tokens • Dynamic Decryption of Code • Watermarking • Code Partitioning CSci599 Fall 2001

14. Hardware and Software Tokens • Software Tokens: in a “licensed” file or “register key” • Hardware Tokens: a physical “dongle” on a serial or parallel port. • Weakness: • Very easy to remove the protection code by using a debug tool, such as softice. • Can be enhanced by adding the token-checking code in multiple locations or in level style. CSci599 Fall 2001

15. Dynamic Decryption of Code • Software is stored in encrypted form on some digital media, and is only decrypted prior to execution using an independently stored key. • Weakness: • Performance overload • Inflexible to the customer • Can be attacked by monitoring of the program memory locations to obtain the decrypted code. CSci599 Fall 2001

16. Watermarking and Fingerprinting • Watermark: a secret message embedded into a cover message. Image, audio, video, text… • Visible or invisible marks • Watermarking • 1. Discourages theft • 2. Allows us to prove theft • Fingerprinting • 3. Allows us to trace violators, increase the prob. of capture CSci599 Fall 2001

17. Code Partitioning • Place a portion of the software in inaccessible memory. • License-checking portion • “proprietary” portion within ROM • Place the protected part in a remote server(RPC) • Place the protected part within a tamper-resistant hardware • Problem: • How to select the portion of the code to be protected • Some approaches have been proposed CSci599 Fall 2001

18. Trusting Software Components • COTS(Commercial off-the-shelf software), supported by middleware such as DOM and CORBA. • COTS usage is typically cheaper and less time-consuming • “Any type of COTS component might have an impact on the overall system security…” • Two unpleasant choices: • forego the use of the components • use “black box” components. CSci599 Fall 2001

19. Trusting Software Components (2) • Some approaches when using COTS: • Black box Approaches Most opaque approaches • Grey-box Approaches COTS vendor disclose enough details of her verification practices. • Cryptographic Coverage verification • Tamper-resistant hardware CSci599 Fall 2001

20. Verification of Systems • Latest evaluation criteria for software is the Common criteria. • Apply rigorous formal methods to verify security properties and cryptographic protocols of computer systems.(e.g. access control, authentication) • Formal methods are expensive and base on formal specifications • Challenge: implementation-based verification methods.(e.g., model-checkers and “hostile” library) CSci599 Fall 2001

21. Secure Software Deployment -Different versions of the same software component may cause the malfunction of certain applications. -Resolving this problem may be very time consuming, sometimes it even imposes security problems. app2 app1 app3 Problem occurred Secured or personal info has been exposed to other people Version1 Version2 ….. c1 CSci599 Fall 2001

22. PDCM (Post-Deployment Configuration Management) Challenges Controlled Delegation Of Administration and Privacy Protection: -configuration may have to involve expertise without the organization. -The software may have various trust levels in different published sites. -Administrator needs to constantly update information on source and privilege of PDCM to a user. -PDCM must also hold up users’ privacies. CSci599 Fall 2001

23. Secure Computations, Not Secure Computers -Test oracle is needed to prove whether the system response is correct. *check cryptographic operations *using quorum schemes for distributing trust among servers *use of secure data structures CSci599 Fall 2001

24. Conclusion • Security issues become more and more important as the systems become more and more distributed. • -Security is a relative entity, and it always depends on the context of the environment. • Security increases the complexity of the system and adds more overhead.(Trade offs) • There are lots of challenges for the security systems in the future. CSci599 Fall 2001

25. Strengths and Weaknesses Pros: detailed listed the relationship between system and security. Stated most of the functions that security can perform and how those functions are carried out in those systems. Cons: Author spends too much space talking about the security from the vendor’s perspective.(How about the real user) Authentication is a two way interaction!User authenticate to the server. Server has to authenticate to the user as well. CSci599 Fall 2001

26. Relevance to Embedded Systems The paper never specifically addresses the security requirements for the embedded system. (Open discussion) -Timeliness requires the security concepts to be considered before the actual implementation of the system. (limit afterthoughts add-ons) -Resource constraints will limit the level of security that satisfies the minimum requirements. -Considering trade-offs, more security means more resource and time consumption. -Two way authentication on embedded components and connectors. CSci599 Fall 2001

27. Relevance to Embedded Systems (2) The example of our project: -Connectors can and should be enhanced to be able to do the authentication in both directions (sending and receiving). -How security will affect the timeliness of the whole system? -While adding the security mechanism, will it imposes new problems into the whole system. -What is the best strategy for implementing the security add-ons. (hardware or software in this particular case?) -What are the negative impacts afterwards? CSci599 Fall 2001

28. References • P. Devanbu and S. Stubblebine. Software Engineering for Security: A Roadmap. In The Future of Software Engineering, Anthony Finkelstein (Ed.), pp. 227-239, ACM Press 2000 CSci599 Fall 2001