html5-img
1 / 38

Outline

Security Engineering Developments and Directions Dr. Bhavani Thuraisingham The University of Texas at Dallas bhavani.thuraisingham@utdallas.edu July 2009. Outline. Systems Engineering and Security Engineering Steps to Security Engineering

yetta
Download Presentation

Outline

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. Security EngineeringDevelopments and DirectionsDr. Bhavani Thuraisingham The University of Texas at Dallasbhavani.thuraisingham@utdallas.eduJuly 2009

  2. Outline Systems Engineering and Security Engineering Steps to Security Engineering Experience with the design and development of a Multilevel Secure Database Management System Assured Information Sharing System Example for Policy Management, Lifecycle Management Secure Grid Example: Policy Management includes accountability Malicious code detection/Vulnerability analysis example: Security Operations Dependability Example Next Steps: Security Engineering and SOA

  3. Systems Engineering and Security Engineering (Wiki) Systems engineering (also known as Systems design engineering) is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more difficult when dealing with large, complex projects. Systems engineering deals with work-processes and tools to handle such projects, and it overlaps with both technical and human-centered disciplines such as control engineering and project management. Security engineering is a specialized field of engineering that deals with the development of detailed engineering plans and designs for security features, controls and systems. It is similar to other systems engineering activities in that its primary motivation is to support the delivery of engineering solutions that satisfy pre-defined functional and user requirements, but with the added dimension of preventing misuse and malicious behavior. These constraints and restrictions are often asserted as a security policy.

  4. Steps to Security Engineering Security Planning Determine whether you need security or not and what needs to be secured, how much is it going to cost you, what are the risks Security Requirements Analysis After planning, you need to gather the security requirements, what level of assurance do you need Cost/Risk analysis Conduct a more formal analysis of security, costs and risks Security Policy and Model After requirements, you need to determine the security policy, both mandatory policies and discretionary policies Develop a security model Security Architecture Determine the security critical components of the system architecture

  5. Steps to Security Engineering Secure Design Design the security critical components Security Coding Determine how the security critical components should be coded Security testing and verification Depending on the level of assurance, the security critical components have to be tested and/or formally verified Does the design have trojan horses? Security Evaluation The system may have to be evaluated for certain operations (e.g., Military operations) Determine the criteria to be used for evaluation (TCSEC, Federal Critical, Common Criteria)

  6. Steps to Security Engineering Certification and Accreditation NIST document states the following: “Security accreditation is the official management decision given by a senior agency official to authorize operation of an information system and to explicitly accept the risk to agency operations, agency assets, or individuals based on the implementation of an agreed-upon set of security controls. The information and supporting evidence needed for security accreditation is developed during a detailed security review of an information system, typically referred to as security certification. Security certification is a comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security accreditation, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. Security Operations and Maintenance Develop concept of operation of the system, Determine any unanticipated events during the operation of the system, plan for maintenance Vulnerability analysis is carried out throughout the security operational and maintenance processes

  7. Experience Developing a Multilevel Secure Relational Database Management Systems: Lock Data Views (LDV) A1 Systems (based on TCSEC/TDI) hosted on LOCK operating system Modified Bell and LaPadula Policy (read at or below your level, write at your level) Confidentiality policies (called security constraints) based on content, context and time Formal security model Security critical components implemented through pipelines for query, update and metadata management operations Formal verification and testing Evaluation of LOCK according to Orange Book; LDV was not evaluated

  8. Assured Information Sharing (AIS) • Daniel Wolfe (formerly of the NSA) defined assured information sharing (AIS) as a framework that “provides the ability to dynamically and securely share information at multiple classification levels among U.S., allied and coalition forces.” • The DoD’s vision for AIS is to “deliver the power of information to ensure mission success through an agile enterprise with freedom of maneuverability across the information environment” • 9/11 Commission report has stated that we need to migrate from a need-to-know to a need-to-share paradigm • Our objective is to help achieve this vision by defining an AIS Lifecycle and developing a framework to realize it.

  9. Architecture: 2005-2008 Data/Policy for Coalition Export Export Data/Policy Data/Policy Export Data/Policy Component Component Data/Policy for Data/Policy for Agency A Agency C Component Data/Policy for Trustworthy Partners Semi-Trustworthy Partners Untrustworthy Partners Agency B

  10. Our Approach • Integrate the Medicaid claims data and mine the data; next enforce policies and determine how much information has been lost (Trustworthy partners); Prototype system; Application of Semantic web technologies • Apply game theory and probing to extract information from semi-trustworthy partners • Conduct Active Defence and determine the actions of an untrustworthy partner • Defend ourselves from our partners using data mining techniques • Conduct active defence – find our what our partners are doing by monitoring them so that we can defend our selves from dynamic situations

  11. Confidentiality, Privacy and Trust Policies Trust Trust is established between say a web site and a user based on credentials or reputations. Privacy When a user logs into a website to make say a purchase, the web site will specify that its privacy policies are. The user will then determine whether he/she wants to enter personal information. That is, if the web site will give out say the user’s address to a third party, then the user can decide whether to enter this information. However before the user enters the information, the user has to decide whether he trusts the web site. This can be based on the credential and reputation. if the user trusts the web site, then the user can enter his private information if he is satisfied with the policies. If not, he can choose not to enter the information. Confidentiality Here the user is requesting information from the web site; the web site checks its confidentiality policies and decides what information to release to the user. The web set can also check the trust it has on the user and decide whether to give the information to the user.

  12. Policy Enforcement PrototypeDr. Mamoun Awad (postdoc) and students Coalition

  13. Architectural Elements of the Prototype • Policy Enforcement Point (PEP): • Enforces policies on requests sent by the Web Service. • Translates this request into an XACML request; sends it to the PDP. • Policy Decision Point (PDP): • Makes decisions regarding the request made by the web service. • Conveys the XACML request to the PEP. Policy Files: • Policy Files are written in XACML policy language. Policy Files specify rules for “Targets”. Each target is composed of 3 components: Subject, Resource and Action; each target is identified uniquely by its components taken together. The XACML request generated by the PEP contains the target. The PDP’s decision making capability lies in matching the target in the request file with the target in the policy file. These policy files are supplied by the owner of the databases (Entities in the coalition). Databases: • The entities participating in the coalition provide access to their databases.

  14. Semantic web-based Policy Engine Interface to the Semantic Web Technology By UTDallas Inference Engine/ Rules Processor Policies Ontologies Rules XML, RDF, OWL Documents Web Pages, Databases Semantic web engine

  15. Policy Engine – Implementation Interface to the Semantic Web Technology By UTDallas Inference Engine/ Rules Processor e.g., Pellet, SWRL Policies Ontologies Rules In RDF JENA RDF Engine RDF Documents

  16. Research Transitioned into AIS MURI – AFOSRUMBC-Purdue-UTD-UIUC-UTSA-UofMI2008-2013 • (1) Develop a Assured Information Sharing Lifecycle (AISL) • (2) a framework based on a secure semantic event-based service oriented architecture to realize the life cycle • (3) novel policy languages, reasoning engines, negotiation strategies, and security infrastructures • (4) techniques to exploit social networks to enhance AISL • (5) techniques for federated information integration, discovery and quality validation • (6) techniques for incentivized assured information sharing. • Unfunded Partners: Kings College Univ of London and Univ of Insurbria (Steve Barker, Barbara Carminati, Elena Ferrari)

  17. AIS Service Oriented ArchitectureImplementing Assured Information Sharing Life Cycle 7 service calls & interactions discovery release use semantic events An event-based model allowscomponents to share context Shared semantic models fordescriptions, communicationand policies Initial prototype uses ApacheAxis2 SOA Framework Host policy tools as services Enhanced agent-based protocols for advertising, negotiation and argumentation

  18. Layered Architecture for Grid(UTDallas, Purdue, UTArlington)

  19. Accountability Policies for the Grid What is accountability? Accountability is defined as “A is accountable to B when A is obliged to inform B about A’s past or future actions and decisions, to justify them, and to suffer punishment in the case of eventual misconduct” Accountability is an important aspect of any computer system for assuring that every action executed in the system can be traced back to some entity The dynamic and multi-organizational nature of grid systems requires effective and efficient accountability system Contributions (Purdue) We have developed a distributed mechanism to capture provenance information available during the distributed execution of jobs in a grid Our approach is based on the notion of accountability agents We have developed a simple yet effective language to specify the accountability data to collect We have implemented a prototype of the accountability system on an emulated grid testbed

  20. Detecting Malicious Executables using Data Mining: Security Operations What are malicious executables? Harm computer systems Virus, Exploit, Denial of Service (DoS), Flooder, Sniffer, Spoofer, Trojan etc. Exploits software vulnerability on a victim May remotely infect other victims Incurs great loss. Example: Code Red epidemic cost $2.6 Billion Malicious code detection: Traditional approach Signature based Requires signatures to be generated by human experts So, not effective against “zero day” attacks

  21. State of the Art and Our Approach State of the Art Automated detection approaches: Behavioural: analyse behaviours like source, destination address, attachment type, statistical anomaly etc. Content-based: analyse the content of the malicious executable Autograph (H. Ah-Kim – CMU): Based on automated signature generation process N-gram analysis (Maloof, M.A. et .al.): Based on mining features and using machine learning. Our Approach Content -based approaches consider only machine-codes (byte-codes). Is it possible to consider higher-level source codes for malicious code detection? Yes: Diassemble the binary executable and retrieve the assembly program Extract important features from the assembly program Combine with machine-code features

  22. Feature Extraction andHybrid Model Featuere Extraction Binary n-gram features Sequence of n consecutive bytes of binary executable Assembly n-gram features Sequence of n consecutive assembly instructions System API call features DLL function call information Hybrid model Collect training samples of normal and malicious executables. Extract features Train a Classifier and build a model Test the model against test samples

  23. Hybrid Feature Retrieval (HFR) Training Testing

  24. Binary n-gram features Features are extracted from the byte codes in the form of n-grams, where n = 2,4,6,8,10 and so on. Example: Given a 11-byte sequence: 0123456789abcdef012345, The 2-grams (2-byte sequences) are: 0123, 2345, 4567, 6789, 89ab, abcd, cdef, ef01, 0123, 2345 The 4-grams (4-byte sequences) are: 01234567, 23456789, 456789ab,...,ef012345 and so on.... Problem: Large dataset. Too many features (millions!). Solution: Use secondary memory, efficient data structures Apply feature selection Feature Extraction

  25. Assembly n-gram features Features are extracted from the assembly programs in the form of n-grams, where n = 2,4,6,8,10 and so on. Example: three instructions “push eax”; “mov eax, dword[0f34]” ; “add ecx, eax”; 2-grams (1) “push eax”; “mov eax, dword[0f34]”; (2) “mov eax, dword[0f34]”; “add ecx, eax”; Problem: Same problem as binary Solution: Same solution Feature Extraction

  26. Select Best K features Selection Criteria: Information Gain Gain of an attribute A on a collection of examples S is given by Feature Selection

  27. Experiments Dataset Dataset1: 838 Malicious and 597 Benign executables Dataset2: 1082 Malicious and 1370 Benign executables Collected Malicious code from VX Heavens (http://vx.netlux.org) Disassembly Pedisassem ( http://www.geocities.com/~sangcho/index.html ) Training, Testing Support Vector Machine (SVM) C-Support Vector Classifiers with an RBF kernel

  28. Results HFS = Hybrid Feature Set BFS = Binary Feature Set AFS = Assembly Feature Set

  29. Results HFS = Hybrid Feature Set BFS = Binary Feature Set AFS = Assembly Feature Set

  30. Results HFS = Hybrid Feature Set BFS = Binary Feature Set AFS = Assembly Feature Set

  31. Secure Dependable Information Management: Dependability Security, Integrity, Real-0time, Fault Tolerance, Trustworthiness, ??? Conflicts between different features Security, Integrity, Fault Tolerance, Real-time Processing E.g., A process may miss real-time deadlines when access control checks are made Trade-offs between real-time processing and security What are the problems? Access control checks vs real-time constraints Covert channels (Secret process could be a high priority process and an Unclassified process could be a low priority process) Time critical process could be malicious Need Flexible policies Real-time processing may be critical during a mission while security may be critical during non-operational times

  32. Secure Dependable Information Management Example: Next Generation AWACS Technology provided by the project Navigation Display Consoles Data Analysis Programming Processor Data Links (14) Group (DAPG) & Sensors Refresh Channels Sensor Multi-Sensor • Security being considered after • the system has been designed • and prototypes implemented • Challenge: Integrating real-time • processing, security and • fault tolerance Detections Tracks Future Future Future App App App Data MSI Mgmt. App Data Xchg. Infrastructure Services Real-time Operating System Hardware

  33. Secure Dependable Information Management: Integration

  34. Secure Dependable Information Management: Directions for Research Challenge: How does a system ensure integrity, security, fault tolerant processing, and still meet timing constraints? Develop flexible security policies; when is it more important to ensure real-time processing and ensure security? Security models and architectures for the policies; Examine real-time algorithms – e.g.,query and transaction processing Research for databases as well as for applications; what assumptions do we need to make about operating systems, networks and middleware? Data may be emanating from sensors and other devices at multiple locations Data may pertain to individuals (e.g. video information, images, surveillance information, etc.) Data may be mined to extract useful information Privacy Preserving Surveillance

  35. SOA: Service Oriented Architecture Request Response Publish Services Query UDDI Answer Service requestor Service providers 35

  36. Basic Components of SOA/Web Services Security Identification For service requestor to acces a secure service provider it must first provide information that expresses its origin or owner. This is referred to as making a claim Authentiaction A message being delivered to a receipient must prove that the message is in fact from the sender that it claims Authorization Once authenticated, the receipient of a message may need to determine what the requestor is alowed to do Singe sign on It is supported by SAML, .NET Passport and XACML Confidentiality and Integrity Confidentiality is concerned with protecting the privacy of the message content, Integrity ensures that the message has not been altered Transport level and Message level security Transport level securiy is provided by SSL (securing HTTP), message level confidentiality and integrity are provied by XML-Encryption and XML-Signature. 36

  37. WS-* security Standards framework 37

  38. Next Steps Large Scale Systems are going to be based on the SOA Paradigm Security engineering for SOA and web services Incorporate security into the SOA modeling (e.g., SOAD – service oriented analysis and design) Determine how the steps will work for SOA Plan, Requirements, Policy, Architecture, Design, Testing, Evaluation, Certification and Accreditation, Operation and Maintenance Dependability: Integrating security, fault tolerance, Real-time processing

More Related