Computer Science and Engineering 1 What these organizations have in common? American Education Services, PA United States Marine Corps / Penn State University

Computer Science and Engineering 1

What these organizations What these organizations have in common?have in common?

• American Education Services, PA

• United States Marine Corps / Penn State University

• St. Vincent Hospital

• Fox News

• SAIC, (San Diego, CA)

• Western Union

• Fidelity National Information Services


What these organizations What these organizations have in common?have in common?

• American Education Services, PA

• United States Marine Corps / Penn State University

• St. Vincent Hospital

• Fox News

• SAIC, (San Diego, CA)

• Western Union

• Fidelity National Information Services

Security BreachesSecurity BreachesJuly 2007July 2007

http://http://www.privacyrights.org/ar/www.privacyrights.org/ar/ChronDataBreaches.htm#200ChronDataBreaches.htm#2007 7




Csilla FarkasAssociate Professor

Dept. of Computer Science and EngineeringUniversity of South Carolina

[email protected]://www.cse.sc.edu/~farkas


Security ObjectivesSecurity Objectives

Secrecy

Prevent/detect/deter improperDisclosure of information

Availability

Prevent/detect/deter improperDenial of access to services

Integrity

Prevent/detect/deter Improper modificationof information


Security TradeoffsSecurity Tradeoffs

COST

Security Functionality

Ease of Use


Achieving Security

PolicyWhat to protect?

MechanismHow to protect?

AssuranceHow good is the protection?


PolicyPolicyOrganizational policy

Information systems policy


Security by ObscuritySecurity by Obscurity

Hide inner working of the systemBad idea!

– Vendor independent open standard– Widespread computer knowledge


Security by LegislationSecurity by Legislation

Instruct users how to behaveNot good enough!

– Important– Only enhance security– Targets only some of the security problems


Security MechanismSecurity Mechanism

Prevention DetectionTolerance and Recovery


Prevention: Access Control

Ensures that all direct accesses are authorized

Protects against accidental and malicious threats


Access ControlAccess Control

Subject: active entity that requests access to an object - e.g., user or program

Object: passive entity accessed by a subject- e.g., record, relation, file

Access right (privileges): how a subject is allowed to access an object- e.g., subject s can read object o


Access Control Models

Discretionary Access Control (DAC) Mandatory Access Control (MAC) Role-Based Access Control (RBAC)


Discretionary Access Control (DAC)

For each subject access right to the objects are defined.

User based Grant and Revoke Problems:

- Propagation of access rights- Revocation of propagated access rights


DAC by Grant and DAC by Grant and RevokeRevoke

Brown (owner)

Black Red

White

GRANT SELECT ON EmployeeTO Red

GRANT SELECT ON EmployeeTO BlackWITH GRANT OPTION ?

Brown revokes grantgiven to Black

?Brown does not want Red to access the Employee relation

GRANT UPDATE(Salary) ON Employee TO White


Mandatory Access Control (MAC)

Security label Dominance (), e.g., Top-Secret Secret

Public Objects: security classification

- File 1 is Secret, File 2 is Public Subjects: security clearances

- Brown is cleared to Secret, Black is cleared to Public

Access rights: defined by comparing the security classification of the requested objects with the security clearance of the subject


MAC – Bell-LaPadula MAC – Bell-LaPadula (BLP) Model(BLP) Model

Single security property: a subject S is allowed a read access to an object O only if label(S) dominates label(O)

Star-property: a subject S is allowed a write access to an object O only if label(O) dominates label(S)

No direct flow of information from high security objects to low security objects!


Role-Based Access Role-Based Access Control (RBAC)Control (RBAC)

Express organizational policies- Separation of duties- Delegation of authority

Flexible: easy to modify to meet new security requirements

Supports- Least-privilege- Separation of duties- Data abstraction


RBACRBAC00

.

.

UUsers

RRoles

PPermissions

. SSessions

User assignment

Permissionassignment


ResearchResearch Secure Semantic WebSecure Semantic Web


Web EvolutionWeb Evolution

• Past: Human usage – HTTP– Static Web pages (HTML)

• Current: Human and some automated usage – Interactive Web pages– Web Services (WSDL, SOAP, SAML)– Semantic Web (RDF, OWL, RuleML, Web databases)– XML technology (data exchange, data representation)

• Future: Semantic Web Services


Research AreasResearch Areas

Access Control for DataMetadataApplication


Secure XML ViewsSecure XML Views<medicalFiles> UC <countyRec> S <patient> S <name>John Smith </name> UC <phone>111-2222</phone> S </patient> <physician>Jim Dale </physician> UC </countyRec> <milBaseRec> TS <patient> S <name>Harry Green</name> UC <phone>333-4444</phone> S </patient> <physician>Joe White </physician> UC <milTag>MT78</milTag> TS </milBaseRec></medicalFiles>

medicalFiles

countyRec

patient

nameJohn Smith

milBaseRec

physicianJim Dale

physicianJoe White

nameHarry Green

milTagMT78

patient

phone111-2222

phone333-4444

View over UC data


Secure XML Views (cont.)Secure XML Views (cont.)

<medicalFiles> <countyRec> <patient> <name>John Smith</name> </patient> <physician>Jim Dale</physician> </countyRec> <milBaseRec> <patient> <name>Harry Green</name> </patient> <physician>Joe White</physician> </milBaseRec></medicalFiles>

medicalFiles

countyRec

patient

nameJohn Smith

milBaseRec

physicianJim Dale

physicianJoe White

nameHarry Green

patient

View over UC data


Secure XML Views (cont.)Secure XML Views (cont.)medicalFiles

countyRec

patient

nameJohn Smith

milBaseRec

physicianJim Dale

physicianJoe White

nameHarry Green

patient

View over UC data

<medicalFiles> <tag01> <tag02> <name>John Smith</name> </tag02> <physician>Jim Dale</physician> </tag01> <tag03> <tag02> <name>Harry Green</name> </tag02> <physician>Joe White</physician> </tag03></medicalFiles>


Secure XML Views (cont.)Secure XML Views (cont.)

<medicalFiles> UC <countyRec> S <patient> S <name>John Smith</name> UC </patient> <physician>Jim Dale</physician> UC </countyRec> <milBaseRec> TS <patient> S <name>Harry Green</name> UC </patient> <physician>Joe White</physician> UC </milBaseRec></medicalFiles>

medicalFiles

countyRec

patient

nameJohn Smith

milBaseRec

physicianJim Dale

physicianJoe White

nameHarry Green

patient

View over UC data


Secure XML Views (cont.)Secure XML Views (cont.)medicalFiles

nameJohn Smith

physicianJim Dale

physicianJoe White

nameHarry Green

View over UC data

<medicalFiles> <name>John Smith</name> <physician>Jim Dale</physician> <name>Harry Green</name> <physician>Joe White</physician></medicalFiles>


<medicalFiles>

<milTag>

<phone>

<milBaseRec>

<countyRec>

<patient>

<physician> <name>

TopSecret

Secret

Unclassified

Multi-Plane DTD GraphMulti-Plane DTD Graph

D,medicalFiles

D, countyRec D, milBaseRec

D, patient D, milTag

D, name D, phone

UC

UC

UC

S

S

S

TS

TSD, physician

MPG = DTD graphover multiple

security planes


TransformationTransformation

name phone

physician

MSCG

MPG

<medicalFiles>

<milTag>

<phone>

<milBaseRec>

<countyRec><patient>

<physician> <name>

TS

UC

S

Security Space Secret



MPG

<medicalFiles>

<milTag>

<phone>

<milBaseRec>


<physician> <name>

TS

S

UC

<emrgRec>

SP

name

physician

MSCG



MPG

<medicalFiles>

<milTag>

<phone>

<milBaseRec>


<physician> <name>

TS

S

UC

<emrgRec>

SPMSCG



MPG

<medicalFiles>

<milTag>

<phone>

<milBaseRec>


<physician> <name>

TS

S

UC SP

<emrgRec>

medicalFiles

emergencyRec

namephysician

Data Structure


Metadata SecurityMetadata Security

• No security model exists for metadata • Can we use existing security models to protect

metadata?• RDF/S is the Basic Framework for SW• RDF/S supports simple inferences• This is not true of XML: XML Access control cannot

be used to protect RDF /S data


John USC

studiesAt

Person

University

GovAgency

Student

memberAt

studiesAt

inferred rdf:type

rdf:type

rdfs:subClassOf

rdfs:subPropertyOf

Legend

schema

instance

Example Graph Example Graph FormatFormat

RDF Triples:(Student, rdfs:subClassOf, Person)(University, rdfs:subClassOf, GovAgency)(studiesAt, rdfs:domain, Student)(studiesAt, rdfs:range,University)(studiesAt, rdfs:subPropertyOf, memberAt)(John, studiesAt, USC)


John USC

studiesAt

Person

University

GovAgency

Student

memberAt

studiesAt

inferred rdf:type

rdf:type

rdfs:subClassOf

rdfs:subPropertyOf

Legend

schema

instance

Rdfs2 : Fact3 + Fact6 Fact7



John USC

studiesAt

Person

University

GovAgency

Student

memberAt

studiesAt

inferred rdf:type

rdf:type

rdfs:subClassOf

rdfs:subPropertyOf

Legend

schema

instance


Rdfs3 : Fact4+Fact6 Fact8



John USC

studiesAt

Person

University

GovAgency

Student

memberAt

studiesAt

inferred rdf:type

rdf:type

rdfs:subClassOf

rdfs:subPropertyOf

Legend

schema

instance


Rdfs3 : Fact4+Fact6 Fact8




Secure RDFSecure RDF

Entailed Data in RDF can cause illegal inferences:

• (John, studiesAt, USC) [S] + (studiesAt, rdfs:domain, University) [S] (USC, rdf:type, University) [S]• (USC, rdf:type, University) [S]+ (University, rdf:subclassOf, GovAgency) [S] (USC, rdf:type, GovAgency) [TS]

Secret User can infer TS informationSecret User can infer TS information


RDF Access Control RDF Access Control

• Security Policy– Subject– Object – Object pattern – Access Mode

• Default policy• Conflict Resolution • Classification of entailed data • Flexible granularity


Application SecurityApplication Security

Security Policy: – Application semantics (from syntax to semantics)– External requirements– Privacy – Trust management– Compliance checking


How to become information How to become information security professional?security professional?


EDUCATION:

Graduate Certificate Program in Information Assurance and

Security (IA&S)


CNSS CertificationsCNSS Certifications

• National Training Standard for Information Systems Security Professionals, CNSSI No. 4011

• National Training Standard for System Administrators in Information Systems Security, CNSSI No. 4013

• National Training Standard for Information Systems Security Officers, CNSSI No. 4014


Core CoursesCore Courses

• CSCE 522 – Information Systems Security Principles – offered every Fall semester

• CSCE 715– Network Security– offered every Fall semester

• CSCE 727 – Information Warfare– offered every 3rd semester


Elective CoursesElective Courses• CSCE 517 – Computer Crime and Forensics • CSCE 557 – Introduction to Cryptography• CSCE 548 – Secure Software Construction• CSCE 716 – Design for Reliability• CSCE 717 – Comp. Systems Performance• CSCE 813 – Internet Security• CSCE 814 – Distributed Systems Security• CSCE 824 – Secure Databases• CSCE 853 – Formal Models of Information Security


Undergraduate EducationUndergraduate Education

• New undergraduate courses:

– CSCE 201: Introduction to Information Security


Questions?Questions?

Documents

Computer Science and Engineering 1 What these organizations have in common? American Education Services, PA United States Marine Corps / Penn State University