1 / 64

SoBeNeT project User group meeting 14/11/2006

SoBeNeT project User group meeting 14/11/2006. Agenda. Overview. Project context Overview of main results Valorization program Outlook. I. Context: project in a nutshell. IWT SBO project (2003-2007) Context: availability of security components (still evolving but relatively mature)

thais
Download Presentation

SoBeNeT project User group meeting 14/11/2006

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SoBeNeT project User group meeting14/11/2006

  2. Agenda

  3. Overview • Project context • Overview of main results • Valorization program • Outlook

  4. 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 applications • 4 Research tracks: • Programming and Composition Technology • Software engineering – “full life cycle” • Tamper and analysis resistance • Shielding and interception

  5. 3E Agfa Alcatel Application Engineers Cryptomatic EMC2 Inno.com Johan Peeters bvba Microsoft L-SEC NBB OWASP-Belgium Philips PWC Siemens UZ Gasthuisberg Zetes The project’s user group • User group • Channel for direct feedback on the execution of the project • Primary audience for dissemination • Possible channel for validation and valorization • Composition:

  6. Evolution of the user group • Frequent contacts with active members, have also led to collaborative research projects • Still new members showing up • Custodix • Cronos • … • Hard to organize plenary meetings 

  7. 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 courses • Project execution is roughly on schedule • Some delay caused by understaffing • real finish Feb 08 – target… • Industrial validation: • Spin-off projects • Online feedback

  8. 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. 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. 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. 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

  12. 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++; } } } } [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’’); } } 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); }

  13. 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

  14. ACI View connector

  15. 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

  16. 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 ?

  17. 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

  18. Track 2: Software engineeringAchievements • In-depth study of available SSE processes • Inception of an integrated methodology • Enablers: • security patterns • threat reduction

  19. Study of available processes • Goal: • Understanding • Strengths and weaknesses • Classification of activities • Application in specific contexts (UP/XP, SME/Corp., …) • 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

  20. 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

  21. 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

  22. 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

  23. 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)

  24. Results of some experiments

  25. Track 3: Tamper and analysis resistance • Goals • Protect software from analysis and tampering • Identification of critical modules in software applications • Approaches • 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

  26. Source code vs. binary obfuscation TTxL/SUIF2 q.c cc p.exe q.exe • Source code obfuscation for binary obfuscation [SERP06] • C transformations • TxL • SUIF2 • Control flow hiding • Flattening • Opaque predicates • Data obfuscation • Array merging • … p.c

  27. Self-encrypting code hash algo guard k cipher hashes calls caller decrypts calls callee • Self-encrypting-code to protect against analysis and tampering [WISSEC06] • Self-checking code: • Data authenticity • No confidentiality • Self-encrypting code • Both • Crypto against analysis • Dependencies against tampering

  28. 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

  29. 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, …

  30. 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)

  31. 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 !

  32. Track 4: (2) global architectures I. 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

  33. Research results must be applied and applicable in a broader scope Between Layers A rich catalog of interceptors to protect APPLICATIONS… Between Tiers “… but if I’m using WPA2, do I need IPSEC, or SSL, or … And how am I going to authenticate?”

  34. security countermeasures are added in various ways Out of stream In stream Non Intrusive interception: Legacy Applications Intrusive interception: New Applications Client Server Application layer X Application layer Y Client Server Client Server Server Client Client Server Client Server Client Server

  35. Interceptors - services Concept: Preferred: Interceptor Thin interceptor Service

  36. Potential to deal with complex Attacks through Advanced Interceptor Coordination Interceptor Interceptor Interceptor Interceptor Interceptor Distributed Security Context • Need to support audit trail • Reactive operations (e.g. forensic research) • Need to support monitoring • Real-time incident response handling

  37. Exploiting distributed security context in a next generation architecture Interceptor Interceptor Interceptor Interceptor Interceptor Distributed Security Context Security Intelligence Architecture for Monitoring and Management Service Oriented Security Architecture

  38. 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

  39. I System A I System B Risk Management Security Intelligence Architecture Policy Management Incident Response Handling Asset Management Association Normalization Security StateSecurity Events ComplianceManagement Correlation Enrichment Knowledge Management Reporting

  40. I System A I System B I System C Service Oriented Security Architecture Authentication Confidentiality Non-Repudiation Authorization Integrity Audit Trail Asset Management Association Translation Distributed Security Context Correlation Enrichment Knowledge Management

  41. Looking Back… Year 1 • Project support activities • Vulnerability 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

  42. 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

  43. 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

  44. 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

  45. 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 networks • Several spin-of projects have been created

  46. Some spin-off projects • TCASE • CROSLOCiS • EHIP • S3MS

  47. 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

More Related