software engineering for security: a roadmap

Software Engineering for Security: a Roadmap

Presented byAatash PatelPangsha 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


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


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


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


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


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


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


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


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


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


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)


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


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.


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 overloadInflexible to the customerCan be attacked by monitoring of the program

memory locations to obtain the decrypted code.


• Watermark: a secret message embedded into a cover message. Image, audio, video, text…

• Visible or invisible marks• Watermarking

1. Discourages theft2. Allows us to prove theft

• Fingerprinting3. Allows us to trace violators,

increase the prob. of capture 11P

Watermarking and Fingerprinting


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


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.


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 verificationoTamper-resistant hardware


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)


-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


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


-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


-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


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


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


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)


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

http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/finaldevanbu.pdf

http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/finaldevanbu.pdf

software engineering for security: a roadmap

Documents