Security EngineeringDevelopments 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• 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

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.

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

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)

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

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

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.

Architecture: 2005-2008

ExportData/Policy

ComponentData/Policy for Agency A

Data/Policy for Coalition

ExportData/Policy

ComponentData/Policy for Agency C

ComponentData/Policy for Agency B

ExportData/Policy

Trustworthy PartnersSemi-Trustworthy PartnersUntrustworthy Partners

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

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.

Coalition

Policy Enforcement PrototypeDr. Mamoun Awad (postdoc) and students

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.

Semantic web-based Policy Engine

Policies

Ontologies

Rules

Semantic web engine

XML, RDF, OWLDocumentsWeb Pages, Databases

Inference Engine/Rules Processor

Interface to the Semantic WebTechnologyBy UTDallas

Policy Engine – Implementation

Policies

Ontologies

Rules

In RDF

JENA RDF EngineRDF Documents

Inference Engine/Rules Processore.g., Pellet, SWRL

Interface to the Semantic WebTechnologyBy UTDallas

Research Transitioned into AIS MURI – AFOSR

UMBC-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)

AIS Service Oriented ArchitectureImplementing Assured Information Sharing Life Cycle

• 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

semantic events

service calls & interactions

disc

over

y

rele

ase

use

77

Layered Architecture for Grid(UTDallas, Purdue, UTArlington)

Secure DATA/INFORMATION/KNOWLEDGE

GRID UTD/Purdue

GRID APPLICATIOINS: Border security UTA/UTD

GRID APPLICATIONS: NCES (UTD/Purdue)

SECURE GRID MODELS: access control and accountability Purdue/UTD

Secure INFRASTRUCTURE/MOBILE GRID UTA/UTD

Integration

UTD Lead with

others having a

role

CORE:

Policies

SSE -SOA

Security

Infrastructure

Assured

Information

Management Services

Assured

Federation

Management

Service

Assured

Incentive

Management

Service

ApplicationServices

S-SOAG

SecurityServices

InformationManagementServices

StorageServices

Assured

Information

Management Services

Infra-structureServices

ApplicationServices(e.g., NCW, Border Security)

CORE:

Policies

SSE -SOA

Security

Infrastructure

Assured

Information

Management Services

Assured

Federation

Management

Service

Assured

Incentive

Management

Service

ApplicationServices

S-SOAG

SecurityServices

InformationManagementServices

StorageServices

Assured

Information

Management Services

Infra-structureServices

ApplicationServices(e.g., NCW, Border Security)

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 entityThe 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 gridOur approach is based on the notion of accountability agentsWe have developed a simple yet effective language to specify the accountability data to collectWe have implemented a prototype of the accountability system on an emulated grid testbed

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 BillionMalicious code detection: Traditional approach

– Signature based– Requires signatures to be generated by human

experts– So, not effective against “zero day” attacks

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

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

Hybrid Feature Retrieval (HFR)• Training

Testing

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

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

• Select Best K features

• Selection Criteria: Information Gain

• Gain of an attribute A on a collection of examples S is given by

Feature Selection

)(

)(||

||)(),(

AValuesVv

v SEn tro p yS

SSEn tro p yASG a in

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

Results• HFS = Hybrid Feature Set• BFS = Binary Feature Set• AFS = Assembly Feature Set

Results• HFS = Hybrid Feature Set• BFS = Binary Feature Set• AFS = Assembly Feature Set

Results• HFS = Hybrid Feature Set• BFS = Binary Feature Set• AFS = Assembly Feature Set

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

Secure Dependable Information Management

Example: Next Generation AWACS

Technology provided by the project

Technology provided by the project

Hardware

Display Processor

&Refresh

Channels

Consoles(14)

Navigation

Sensors

Data LinksData Analysis Programming

Group (DAPG)

FutureApp

FutureApp

FutureApp

Multi-SensorTracks

SensorDetections

MSIApp

DataMgmt. Data

Xchg.

Infrastructure Services

•Security being considered after the system has been designed and prototypes implemented

•Challenge: Integrating real-time processing, security and fault tolerance

Real-time Operating System

Secure Dependable Information Management: Integration

SensorSensor Data Manager Object

SensorSecurity ServiceObject

SensorFault

ToleranceService Object

SensorReal-time Service Object

SensorQuality ofService

ObjectSensorApplicationObject

Communication SubsystemObject Request Broker / Infrastructure

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

Service requestor

Service providers

UDDI

Publish ServicesQuery

Request

Answer

Response

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.

37

WS-* security Standards framework

Transport level security SSL/TLS

Network level security IPSec

XML security XML Encryption

XML Signature

SOAP foundation

Message security

WS SecurityWS

SecureConversation

Reliable Messaging

WS ReliableMessaging

Security mgmt.

XKMS WS-Trust

XACML SAML

WS-Policy

Policy & Access Control

Identity Mgmt.

WS-federation Liberty SAML

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