Download - Software Engineering for Security: a Roadmap Presented by Aatash Patel Pangsha Qiu Huanzhong Qiu
23rd October, 2001 CSci599 Fall 2001 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
23rd October, 2001 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
23rd October, 2001 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
23rd October, 2001 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
23rd October, 2001 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
23rd October, 2001 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
23rd October, 2001 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
23rd October, 2001 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
23rd October, 2001 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
23rd October, 2001 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
23rd October, 2001 CSci599 Fall 2001 12
Software Piracy & Protection
Adversary Economics
)(*)(** 1111 nCnPCnCCn chb
bC Cost of one item
hC Cost of first hack the copy protection
cC Cost of each item after hacked
11P Risks of getting caught(prosecution Prob.)
11C Possibly subjective cost of each item(fine)
23rd October, 2001 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 TokensDynamic Decryption of CodeWatermarkingCode Partitioning
bC
11P
hC cC
23rd October, 2001 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.
23rd October, 2001 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.
23rd October, 2001 CSci599 Fall 2001 16
• Watermark: a secret message embedded into a cover message. Image, audio, video, text…
• Visible or invisible marks
• Watermarking1. Discourages theft
2. Allows us to prove theft
• Fingerprinting3. Allows us to trace violators,
increase the prob. of capture
11P
Watermarking and Fingerprinting
23rd October, 2001 CSci599 Fall 2001 17
Code Partitioning
Place a portion of the software in inaccessible memory.License-checking portion “proprietary” portion within ROMPlace 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
23rd October, 2001 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.
23rd October, 2001 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.oCryptographic Coverage verification
oTamper-resistant hardware
23rd October, 2001 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)
23rd October, 2001 CSci599 Fall 2001 21
-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.
app1app2
app3
c1
Version1Version2
…..
Problem occurred
Secured or personal info has been exposed to other people
Secure Software Deployment
23rd October, 2001 CSci599 Fall 2001 22
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.
PDCM (Post-Deployment Configuration Management) Challenges
23rd October, 2001 CSci599 Fall 2001 23
-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
Secure Computations, Not Secure Computers
23rd October, 2001 CSci599 Fall 2001 24
-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.
Conclusion
23rd October, 2001 CSci599 Fall 2001 25
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.
Strengths and Weaknesses
23rd October, 2001 CSci599 Fall 2001 26
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.
Relevance to Embedded Systems
23rd October, 2001 CSci599 Fall 2001 27
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?
Relevance to Embedded Systems (2)