Tue

sday

Oct

ober

25,

200

5

SoBeNeT project User group meeting

14/11/2006

2

Tue

sday

Nov

embe

r 14

, 200

6

Agenda

16:00h Introduction and project status

17:00h Discussion: feedback and opportunities for validation

17:15h Preview of the SoBeNeT2 project

17:50h Conclusion and wrap-up

18:00h Informal gathering and drinks

3

Tue

sday

Nov

embe

r 14

, 200

6

Overview

1. Project context

2. Overview of main results

3. Valorization program

4. Outlook

4

Tue

sday

Nov

embe

r 14

, 200

6

I. Context: project in a nutshell

IWT SBO project (2003-2007)Context: availability of security components

(still evolving but relatively mature)Goal: to enable the development of secure

software applications4 Research tracks:

Programming and Composition Technology Software engineering – “full life cycle” Tamper and analysis resistance Shielding and interception

5

Tue

sday

Nov

embe

r 14

, 200

6

The project’s user group

3E Agfa Alcatel Application Engineers Cryptomatic EMC2

Inno.com Johan Peeters bvba

Microsoft L-SEC NBB OWASP-Belgium Philips PWC Siemens UZ Gasthuisberg Zetes

User group Channel for direct feedback on the execution of

the project Primary audience for dissemination Possible channel for validation and valorization

Composition:

6

Tue

sday

Nov

embe

r 14

, 200

6

Evolution of the user group

Frequent contacts with active members, have also led to collaborative research projects

Still new members showing upCustodixCronos…

Hard to organize plenary meetings

7

Tue

sday

Nov

embe

r 14

, 200

6

II. Project status@End of third project year

Substantial amount of results Academic:

• scientific publications and involvement in national and international events

Broader dissemination : workshops and coursesProject execution is roughly on schedule

Some delay caused by understaffing real finish Feb 08 – target…

Industrial validation: Spin-off projects Online feedback

8

Tue

sday

Nov

embe

r 14

, 200

6

Track 1: Programming and composition - context

Programming models Considering traditional programming languages

• C • C++

Considering state-of-the-art (OO, CB) programming languages• C#, Java

Entering AOSD… Complex composition

Considering component models in state-of-the-art middleware• J2EE• .NET• Web Services

But equally relevant in programming languages Target to be agnostic to both angles, but practical when it comes to

implemented solutions. Component frameworks: ambition to extend state-of-the-art

middleware

9

Tue

sday

Nov

embe

r 14

, 200

6

Track 1: Programming and composition highlights

Programming models Secure memory allocation Language extensions for security

Complex composition Enforcement of security properties:

• CAS, concurrency and data dependencies Aspect-Orientation:

• Dedicated access control interfaces• Security implications of AOP

Component frameworks Middleware and component framework extensions

10

Tue

sday

Nov

embe

r 14

, 200

6

Memory allocation

Buffer overflows are a major vulnerability of applications written in C/C++ Due to bad structuring and protection of run-time information Many solutions have been proposed, often by checking

rather than changing the run-time stack We have designed and implemented a

countermeasure that changes the memory layout separates user and system data (stack, heap, global

variables) [ICICS2006, ACSAC2006] The memory allocator (dnmalloc) has been thoroughly

tested and is available for download (http://www.fort-knox.org/) Limited overhead (mem 0% - 84% ; cpu -11% - 5%) Requires linking to a different library

11

Tue

sday

Nov

embe

r 14

, 200

6

12

Tue

sday

Nov

embe

r 14

, 200

6

Security contracts

Goal: specify and enforce security properties as component contracts Rule out unexpected behavior

Initial work has studied different types of security contracts [SESS05]

Different properties have been further elaborated on and are now supported in concrete contracts: Code Access Security [JOT 5(3)] Concurrency [ICFEM06, TV06] Data dependencies [SC06]The properties are being verified statically (ESC/Java2)

Opportunities for other types of security properties ! A general approach for security contracts and secure

composition will be proposed in Y4

13

Tue

sday

Nov

embe

r 14

, 200

6

class Session implements Runnable { shared Counter counter ; int sourceId;

Session(Counter counter , int sourceId) requires counter 2 S; ensures this 2 tid.A ^ this 62 S; { this.counter := counter ; this.sourceId := sourceId; }

public void run() requires tid.A = {this} ^ this 62 S; { for (; ; ) { // Wait for event from source sourceId (not shown) synchronized (counter ) { counter .count++;} } } }

public class EmailNotificationAction extends Action { //@ also //@ requires request != null; //@ requires request.getDataItem(”meeting”) instanceof Meeting; //@ ensures \result == ”success”; public String execute(Request request, Form form);}

[Minimum := {WebPermission}]class Connector { Stream Connect(String url) { requires WebPermission Є s ; { new WebPermission().Demand(); //create the connection }

Stream ConnectToTrusted() requires true; { new WebPermission().Assert(); return Connect(‘’t.com’’); }}

14

Tue

sday

Nov

embe

r 14

, 200

6

AOSD & security

Continuation of efforts to modularize security enforcement

Access interface / view connector approach [AOMD’05, DSOnline 7(6), ACSAC’05] Container-managed service,

configured through deployment descriptor

Further fine-tuning (concepts, specification language)

Prototype implementations in JAC and CaesarJ

15

Tue

sday

Nov

embe

r 14

, 200

6

ObjectInterface CalendarAO{

attribute: CalendarOwnerAS calendarOwner;

action: showEntries;

action: newContinualEntry;

action: newEntry;

action: editEntry;

action: deleteEntry;

}

ObjectInterface ResourceAO{

action: book;

action: cancel;

}

SubjectInterface EmployeeAS{}

SubjectInterface CalendarOwnerAS

extends EmployeeAS{

attribute: SecretaryAS secretary;

}

SubjectInterface SecretaryAS

extends EmployeeAS{}

1. Domain Mapping

type:

object-interface:

Calendar

CalendarAO

2. Information Retrieval

attributes:

calendarOwner Calendar.getOwner()

3. Semantic Action Annotations

actions:

showEntries

newContinualEntry

newEntry

editEntry

deleteEntry

getAllEntries()newContinualEntry(…)newEntry(…)updateEntry(…)deleteEntry(…)

AC

I

Vie

w

con

nec

tor

16

Tue

sday

Nov

embe

r 14

, 200

6

Security implications of AOP

Security risks include [SESS06]: Modification of the logic of a module Influencing the interaction or composition of modules Bad enforcement of the aspect model

Most relevant for weaving based tools, but risk for other mechanisms as well

This can occur intentionally or unintentionally An ignorant developer could introduce security

vulnerabilities without even knowing it Addressing these is key

17

Tue

sday

Nov

embe

r 14

, 200

6

Towards a solution

Language extensions/restrictions have been proposed [Aldrich05, Ongkingco05, Gudmundson01, Larochelle03, …] Run-time enforcement is key Further restrictions might be useful

An aspect permission system could address (some of) these problems as well Logical extension of Java’s permission system

• Support checking aspects for particular permissions Enable control over aspect-specific dynamic actions, such as

cflow or aspect activation An effective way of implementing restrictions

• More secure than a compiler-only language solution Future work, perhaps for SoBeNeT II ?

18

Tue

sday

Nov

embe

r 14

, 200

6

Track 2: Software engineeringContext

SSE processes Fragmentation of partial solutions, e.g. in the area

of risk management (OCTAVE, NIST SP800-30, CORAS, …)

Key resources for full-lifecycle: Microsoft’s SDL and OWASP’s CLASP

Important trends and techniques Contract based development Feature-oriented development (related to AOSD) Model driven engineering Architecture driven design

19

Tue

sday

Nov

embe

r 14

, 200

6

Track 2: Software engineeringAchievements

In-depth study of available SSE processes

Inception of an integrated methodologyEnablers:

security patterns threat reduction

20

Tue

sday

Nov

embe

r 14

, 200

6

Study of available processes

Goal:1. Understanding

• Strengths and weaknesses • Classification of activities

2. Application in specific contexts (UP/XP, SME/Corp., …)3. Gap analysis and improvements

Resources: Started from Microsoft’s SDL, OWASP’s CLASP and

articles Gunnar Peterson Looking further at NIST’s SP800-64, SEI’s TSP & PSP

Knowledge for consulting

21

Tue

sday

Nov

embe

r 14

, 200

6

22

Tue

sday

Nov

embe

r 14

, 200

6

Towards an integrated methodology

Generic steps for secure software (2.3.1): Recent processes do a great job at this

But, limitation/critique of available SSE processes: Mainly set of activities, some of them being a real challenge

• What is the underlying methodology ; is it sound ? Little guidance in formalisms, linking of artifacts Important issues (e.g., security principles) remain largely

unaddressed Many discussions towards an improved methodology

for SSE Very difficult, clearly

• Integrating at least our views on the matter For now: focus on requirements engineering and (software)

architectural design

23

Tue

sday

Nov

embe

r 14

, 200

6

Towards an integrated methodology

Key characteristics Improving the quality of the solution

• Tangible, traceable, verifiable Practical

• Useable, automated Separation of concerns

Trying to answer Security policy lifecycle Security principles and practices beyond

the books …

Identifying major research challenges

=>Report is currently being written

24

Tue

sday

Nov

embe

r 14

, 200

6

Security patterns

I.e. design patterns for security For example: checkpoint [Yoder], limited view [Yoder], demiliterized

zone [Schumacher] Could be very useful in theory; unfortunately in practice

Large and scattered space (objectives, design, mechanisms, …) Quality is varying, no good quality metrics Renewed attention recently ([Steel], [Schumacher])

Our work: In-depth study and survey (80+ patterns) Classification (complexity, quality, taxonomy) Adding meta information (objectives, relationships) Pattern-oriented development process

Applications Validated by means of limited case studies Opportunity for broader validation !

A first part of the work has been submitted to ASIACCS’07

25

Tue

sday

Nov

embe

r 14

, 200

6

26

Tue

sday

Nov

embe

r 14

, 200

6

Threat reduction

Problem: The result of a thorough threat analysis is extensive

• E.g., STRIDE driven threats for the e-publishing case are >600 MUC Which ones should be further implemented ?

Possible approaches: Prioritization, aka risk management (many approaches available) Relations between threats (e.g., equivalence, causality) Abstraction

As a first step, we have studied a number of available methods for risk management (DREAD, CORAS, OCTAVE(-S), NIST SP800-30) Which performs best security-wise and has the best ROI ? Opportunities for early reduction ?

This work will be submitted to SecSE workshop (DASC’07)

27

Tue

sday

Nov

embe

r 14

, 200

6

Results of some experiments

28

Tue

sday

Nov

embe

r 14

, 200

6

Track 3: Tamper and analysis resistance

Goals Protect software from analysis and tampering Identification of critical modules in software

applicationsApproaches

Software security techniques• Problems of software protection• Code obfuscation, white-box crypto, tamper-resistant

software, … Condensed white-box implementations

• Hiding key information in implementation (tables)• Current status: huge time and space costs• Contribution: smaller amount of lookup tables

29

Tue

sday

Nov

embe

r 14

, 200

6

Source code vs. binary obfuscation

Source code obfuscation for binary obfuscation [SERP06] C transformations

• TxL• SUIF2

Control flow hiding• Flattening• Opaque predicates

Data obfuscation• Array merging• …

p.c

p.exe

q.cTTxL/SUIF2

q.exe

cc

30

Tue

sday

Nov

embe

r 14

, 200

6

Self-encrypting code

Self-encrypting-code to protect against analysis and tampering [WISSEC06]Self-checking code:

• Data authenticity• No confidentiality

Self-encrypting code• Both

Crypto against analysisDependencies against

tampering

caller

callee

calls

hash algo

hashescalls

decrypts

kcipher

guard

31

Tue

sday

Nov

embe

r 14

, 200

6

Relevance & future work

Applicability and relevance Obfuscation demanded for J2EE and .NET Active community

Future work Obfuscation library

• Control flow and data transformations• Self-modifying code

White-box crypto meets obfuscation• Data flow analysis• Random mappings• New cipher design

J2EE and .NET obfuscation

32

Tue

sday

Nov

embe

r 14

, 200

6

Publications and deliverables

Publications Condensed white-box implementations (BSIT’05) Source code transformations for binary obfuscation

(SERP’06) Self-encrypting code (WISSEC’06)

Reports Software protection techniques (’04) Critical module identification (’05) J2EE and .NET obfuscation (’06)

Posters and abstracts PA3CT’04, EWSCS’06, …

33

Tue

sday

Nov

embe

r 14

, 200

6

Track 4: shielding and interception

Initial focus: On existing applications Mostly on legacy software

Two tracks: (1) Enabling points solutions (protocol

specific) Leading to powerful interceptors Based on strong methodology Applicability: huge

(2) Global architectures (future for MSS)

34

Tue

sday

Nov

embe

r 14

, 200

6

Track 4: (1) protocol security

Goal: Formally guarantee absence of (certain kinds) of erroneous

behavior for web applications using WAF Requires coupling of WAF policy and application properties

Approach Static verification of application logic for security properties Static verification of adherence of application protocol for

security properties Dynamic enforcement of application protocol (WAF)

Prototype implementation using ESC/Java and J2EE Filters (for WAF)

Applicability: potential is enormous !

35

Tue

sday

Nov

embe

r 14

, 200

6

Track 4: (2) global architecturesI. Towards an integration of point solutions:

empowering a generic interceptor framework Because legacy software is important To leverage existing security products

II. Distributed security context – allows achieving a next level of security

Security monitoring and management architecture directions for a service oriented security

architecture

36

Tue

sday

Nov

embe

r 14

, 200

6

Research results must be applied and applicable in a broader scope

7

6

5

4

3

2

1

Dee

p P

ack

et I

nsp

ecti

on

OS

Lang RT

Libs

GUI App

7

6

5

4

3

2

1

Dee

p P

ack

et I

nsp

ecti

on

OS

Lang RT

Libs

Pres. App

7

6

5

4

3

2

1 D

eep

Pac

ket

In

spec

tion

OS

Lang RT

Libs

Biz. App

7

6

5

4

3

2

1

Dee

p P

ack

et I

nsp

ecti

on

OS

Lang RT

Libs

Data Access

App

7

6

5

4

3

2

1

Dee

p P

ack

et I

nsp

ecti

on

OS

Lang RT

Libs

Data Storage

App

A rich catalog of interceptors

to protect APPLICATIONS…

“… but if I’m using WPA2, do I need IPSEC,

or SSL, or …

And how am I going to authenticate?”

BetweenTiers

BetweenLayers

37

Tue

sday

Nov

embe

r 14

, 200

6

security countermeasures are added in various ways

Client Server Application layer X

Application layer Y

ServerClient

Client

Client

Client

Client

Client

Server

Server

Server

Server

Server

Non Intrusive interception:Legacy Applications

Intrusive interception:New ApplicationsOut of

stream

In stream

38

Tue

sday

Nov

embe

r 14

, 200

6

Interceptors - services

Interceptor

Concept:

Thininterceptor

Service

Preferred:

39

Tue

sday

Nov

embe

r 14

, 200

6

Potential to deal with complex Attacks through Advanced Interceptor Coordination

Distributed Security Context

Interceptor InterceptorInterceptor Interceptor Interceptor

Need to support audit trailReactive operations (e.g. forensic research)

Need to support monitoringReal-time incident response handling

40

Tue

sday

Nov

embe

r 14

, 200

6

Exploiting distributed security context in a next generation architecture

Service Oriented Security Architecture

Security Intelligence Architecture for

Monitoring and Management

Distributed Security Context

Interceptor InterceptorInterceptor Interceptor Interceptor

41

Tue

sday

Nov

embe

r 14

, 200

6

Features of the next generation security architecture

Two key concepts:SIAMM: Security Intelligence

Architecture for Monitoring and Management

SOSA: Service Oriented Security Architecture for policy enforcement

42

Tue

sday

Nov

embe

r 14

, 200

6

System A System BII

Asset Management

Security Intelligence Architecture

Knowledge Management

Security StateSecurity Events

Association Normalization

EnrichmentCorrelation

Policy ManagementRisk

Management

Incident ResponseHandling

Reporting

ComplianceManagement

43

Tue

sday

Nov

embe

r 14

, 200

6

System A System B System CII I

Asset Management

Authentication Non-Repudiation Confidentiality

Authorization Integrity Audit Trail

Service Oriented Security Architecture

Association Translation

EnrichmentCorrelation

Knowledge Management

Distributed Security Context

44

Tue

sday

Nov

embe

r 14

, 200

6

Looking Back… Year 1

Project support activitiesVulnerability study and classification Inception of case studies

Feasibility study of engineering application-level security with AOSD

Study of techniques for tamper and analysis resistance

Study of interception techniques

45

Tue

sday

Nov

embe

r 14

, 200

6

Headlines of Year 2

Model for addressing code injection vulnerabilities Interrelations between point solutions in track I

(Languages and composition) E.g., security contracts as a language extension and a

vehicle for reasoning on composition Focus on component frameworks

Intensifying the software engineering track Study activities (incl. workshops)

Architecture for management and monitoring Survey of attack methods and options in application

protocols

First industrial validations

46

Tue

sday

Nov

embe

r 14

, 200

6

Headlines of Year 3

Release of dnmalloc Support for different types of security contracts

CAS, data dependencies, concurrency Fine-tuning of modularized access control Security implications of AOP Refinement of secure development process activities

(leveraged, among others, by results of other tracks) Improved techniques for tamper and analysis

resistance Security management and monitoring applied to

the .Net platform

47

Tue

sday

Nov

embe

r 14

, 200

6

Some numbers

Over 80 publications in 3 years (>10 researchers involved)

>4 PhD’s coming up (Bart Jacobs, Lieven De Smet, Tine Verhanneman, Yves Younan)

(Co-)organization of >10 dissemination events Project specific workshops International conferences and workshops

>5 spin-off projects with industrial partners Intensive contacts with >10 partners from user

group

48

Tue

sday

Nov

embe

r 14

, 200

6

III. Valorization

Some results are applicable in practical settings C/C++ memory allocator Protocol checking for web applications Study of processes for SSE Survey of practical tamper resistance techniques

National and international contact networksSeveral spin-of projects have been created

49

Tue

sday

Nov

embe

r 14

, 200

6

Some spin-off projects

TCASE

CROSLOCiS

EHIP

S3MS

50

Tue

sday

Nov

embe

r 14

, 200

6

TCASE: Technologies and Capabilities for Service-Enabling

Project summary This project investigates technologies for ICT service

platform middleware and innovative concepts for service enabling in both the service provider domain and end-user domains. Important challenges are:

• which security and policy enforcement techniques are most appropriate for service enabling platform design.

• how to integrate location and context awareness into a service enabling platform.

• which technologies in the user centric domain are best suited for service deployment.

Several proof of concept implementations are built in order to evaluate the feasibility and performance of the various aspects under study.

https://tcase.ibbt.be

51

Tue

sday

Nov

embe

r 14

, 200

6

CROSLOCiS: CROSLOCiS: CReation of Smart LOcal City Services

Research Challenges for Easy Service Creation in a Smarter Environment

Extract! from the technological and business barriers: Too environment-specific enabling services miss common

models and procedures for collecting, storing and exchanging identity, location, presence and profile data in a secure and application-independent way.

Unclear business and value chain roles prevent from composing a more complete service experience involving multiple service providers, posing issues like subscriber “ownership” and federated administration.

Service management and administration is lacking, e.g. for managing service-user relationships, service inventories, resource availability and charging policies.

https://projects.ibbt.be/croslocis/

52

Tue

sday

Nov

embe

r 14

, 200

6

EHIP: E-Health Information Platforms

E-HIP is a research project in the field of eHealth. Its aim is to explore the applications and related architecture to share clinical information of patients among multiple healthcare providers.

(from project summary -in Dutch!)…..De focus van het project ligt op een patiëntgericht regionaal informatieplatform voor de gezondheidszorg. Het verzekert veilige en betrouwbare toegang tot klinische patiëntgegevens voor alle geautoriseerde zorgverstrekkers en is te allen tijde en van op elke werkpost toegankelijk. Het platform moet een vlotte samenwerking verzekeren tussen de huidige data-eilanden met een grote hoeveelheid aan vertrouwelijke data en moet leiden tot een geïntegreerde regionale IT infrastructuur waartoe alle zorgverstrekkers (huisartsen, ziekenhuizen, specialisten, gezondheidscentra...) toegang hebben om een adequate gezondheidszorg te kunnen leveren aan de burgers.

https://ehip.ibbt.be

53

Tue

sday

Nov

embe

r 14

, 200

6

S3MS: Security of Software and Services for Mobile Systems

FP-6 STREP The S3MS Research Project provides a solution by

allowing you to know a-priori if a mobile application is trustable or not…..

….The application will come with a "security contract", which has been checked by your network service provider, your company or a trusted third party, telling you which data or resources the application will use.If you trust nobody… you could even check it yourself off-line.

http://www.s3ms.org/

54

Tue

sday

Nov

embe

r 14

, 200

6

Further Feedback and Validation

User group pollMore focus on validationKey target platforms: J2EE and .NET

(including web services)

SSE questionnaireAgain, many informal contacts

55

Tue

sday

Nov

embe

r 14

, 200

6

Industry segments

System Integrators and consultants (software development on a project base)

Product development companies Traditional Embedded systems Telecom Other (boundaries are vague)

Other stakeholders in software applications: business owner, system manager

56

Tue

sday

Nov

embe

r 14

, 200

6

Upcoming events

26/02-02/03/2007 Secure Application Development course

20/05-26/05/2007 ICSE workshop on Software Engineering for Secure Systems (SESS’07): proposal submitted

10/07-13/07-2007 International Course on the State of the Art and Evolution of Computer Security and Industrial Cryptography

57

Tue

sday

Nov

embe

r 14

, 200

6

IV. Outlook on Year 4

Target headlinesMethodology for secure software

engineering & application to specific contexts

General model for security contracts• Language specification and static verification• Improving support for component frameworks

Realization of techniques for tamper resistance

Incubation of SoBeNeT II (SEC SODA)

Tue

sday

Oct

ober

25,

200

5

Thank you!

http://sobenet.cs.kuleuven.be/

Questions?

59

Tue

sday

Nov

embe

r 14

, 200

6

Backup from here

60

Tue

sday

Nov

embe

r 14

, 200

6

Programming and Composition Track

1.1.1: Literature survey of causes and weaknesses Webservices [Krisvdb] and PalmOS [Goovaerts]

1.1.2: Application case studies E-finance [Lagaisse], E-publishing, KWS

1.2.1: Inventory of solution techniques Formal software security [De Win]

1.2.2: Evaluation SoA programming languages C#

1.2.3: Definition optimal programming model Memory allocators for C/C++ [Younan]

61

Tue

sday

Nov

embe

r 14

, 200

6

Programming and Composition Track

1.3.1: Composition model for security Survey discussion [De Win], CAS for .NET [Smans]

1.3.2: Complex composition scenarios Improving abstractions [Verhanneman], Generic XACML

binding, Dependency scenarios [Desmet]

1.4.1: Definition basic security requirements 1.4.2: Support for contracts in component frameworks

Extending .NET for contracts [Jacobs]

1.4.3: Evaluation of component frameworks Comparison J2EE, CORBA, .NET, WS, Mobile [Goovaerts]

62

Tue

sday

Nov

embe

r 14

, 200

6

Software Engineering Track

2.1.1: Inventory of common security requirements Literature study and case study driven

2.2.1: Study of industry best practice Overview presented in workshop [Ubizen]

2.2.2: Study of mainstream SE processes Focus on UP and XP to be presented in workshop, survey of

relevant research [De Win]

63

Tue

sday

Nov

embe

r 14

, 200

6

Tamper and Analysis Resistance Track

3.1.1: Survey of critical software modules Analysis report [Cappaert]

3.2.1: Development of new software effective efforts Description and testing of first ideas [Wyseur]

All results are available on the project website (http://sobenet.cs.kuleuven.be)

64

Tue

sday

Nov

embe

r 14

, 200

6

Shielding and Interception Track

4.1.3: Study of interception in the software industry Application to KWS case

4.1.6: Study of transfer mechanisms Inventory of transfer mechanisms

4.1.7: Design of interception point coordination SIAMM and SOSA

4.2.1: Study of formal approaches ASM-based specification of application-level protocols for OO

4.2.2: Derivation of security requirements Protocol conformance checker from ASM specification

[Smans]

4.2.3: Study of attack methods Survey of various attack methods [Ubizen]

4.2.4: Study of attack options Survey of various attack options [Ubizen]