Outline!
Web Security !
Rattikorn Hewett!
!
NSF-SFS Workshop!
Jul 14-18, 2014!
•
Basic Concepts!
•
Security Types and Perspectives!
•
Attacks and Threats !
•
Some Tools and Research Snapshots!
•
Conclusions!
!
!
!
Texas Tech University
Hewett
Texas Tech University
Web Security in Contexts!
2
Web Security!
•  Aims to secure activities/services on the Webs!
Why should “Web Security” receive special attention?!
•  High publicity
à Attractive target as attack is a public event !
Protects against !
Malicious Acts!
Cyber Security!
Web Security!
Computer Security!
Hewett
Texas Tech University
Malicious Acts + !
Activities on the Web!
•  High exposure/connectivity to users
à Vulnerable!
•  Increasingly crucial for business functions
à Loss of identity/sensitive information/money/reputation!
•  Increased Complexity
à Security flaws!
•  More expensive to fix than to prevent
à Economic impacts!
•  Assumes no Malicious Acts!
•  Protects HW/SW (e.g., OS),!
Operations, Network, Data!
3
Hewett
Texas Tech University
4
1
!
Web Security!
What is a Web Server!
•  A Web Server runs a Website!
•  Involves technologies and practices to protect!
•  Web Servers
(computers that run the websites) !
•  Web Users
(sensitive/proprietary information)!
•  Has a corresponding Name and IP Address!
•  A Web Server delivers !
Adjacent!
Organizations!
(via networks)!
•  Web pages to Web Browsers (to public)!
•  Files to Web applications!
!
A Web Server = A Computer (with Site content files) !
+ Internet Access!
+ Web Server Software (e.g., Apache) !
Hewett
5
Texas Tech University
Hewett
6
Texas Tech University
Web Server Architecture!
Extended Web Server Architecture!
•  Most Web Services are based on the Client/Server model!
•  Web Server: provides Static document (web page, image)!
•  Web Servers!
•  Retrieve files from the serverʼs hard drive!
•  Format the files for the Web browser (by CGI) !
Web server!
•  Send them via the network!
Request for!
•  Application Server: supports Dynamic contents by!
Client Server !
Web Browser!
!
http!
!
•  Running Web Application programs (e.g., looking up
stock price, processing transactions) to conduct business!
• ! Data Base Server: supports Data Base access!
!
IP Address of !
Server: ttu.edu!
Web page in html! Request! ! html!
Server Software: !
http://www.ttu.edu!
http!
DataBase Server!
Apache + CGI+ SSL!
html!
html!
Web Server!
Server Programs:!
Web Server! CGI (Ruby on Rails,
ASP, .Net, J2EE)!
Server Programs:!
Apache + SSL!
!
•  Web Page !
•  Image Files!
Web page!
Texas Tech University
7
Hewett
Texas Tech University
!
Data
Query!
!
Data Base!
Local Files!
Hewett
Server Program:!
MySQL, Oracle!
Web App Server!
•  Pages with Data !
•  Codes/Data!
8
2
Outline!
Security Types!
•
Basic Concepts!
•  Securing Web Servers !
•
Security Types and Perspectives!
•
Attacks and Threats!
•
Some Tools and Research Snapshots!
http!
html!
Conclusions!
•
•  Server is in operation!
•  Data on it is secured!
Web server!
!
Web Browser!
!
!
Hewett
9
Texas Tech University
Hewett
Popular Counter Measures!
Transmission Control
Protocol (TCP/IP)!
Web server!
Web Browser!
Texas Tech University
10
•  User Perspectives:!
How to help users protect themselves during activities on
the Web such as:!
•  Web browsing!
•  Online transactions!
•  Social networking!
à Tools to alert users, educate users of potential attacks!
•  Securing Web Servers !
•  By Anti-Virus!
•  Securing Data Transmission
between Server and Users!
•  By Cryptographic protocols!
E.g., SSL (secure socket layers)!
!
•  Securing Web Userʼs computer!
! •  By Anti-Virus!
•  Developer Perspectives: Assume traditional computer
security technologies (e.g., authentication, authorization),
find techniques to !
•  Prevent/Defend attacks on the Web Server
àTools to detect compromised Web sites/applications!
•  Develop secure software !
! à Software security including Web applications!
Is the system secured?!
Hewett
Texas Tech University
Two Perspectives!
http!
html!
•  Securing Data Transmission
between Server and Users!
•  No eavesdropping (read/listen)!
•  No modification!
!
•  Securing Web Userʼs computer!
! •  Safe download!
•  Safe service transactions!
•  Protect sensitive information!
11
Hewett
!
Texas Tech University
12
3
Outline!
•
Basic Concepts!
•
Security Types and Perspectives!
•
Attacks and Threats!
•
Some Tools and Research Snapshots!
•
Conclusions!
Well-known Web Security Attacks!
Client !
Web Browser!
•  Social Engineering!
•  Malware!
•  CrossSite Scripting!
!
!
Web Server!
•  HeartBleed!
•  Buffer Overflow!
Web Application!
•  SQL Injection!
•  CrossSite Scripting!
Internet Crime!
!
•  Click Fraud!
Hewett
Texas Tech University
13
Hewett
Texas Tech University
14
Malware!
Social Engineering Attacks!
Attacker engages victims thru online social interactions to
obtain useful information!
Malicious Software - various types:!
•  Virus: Malicious code that makes copies of itself and
attaches to other programs!
•  Spam – unsolicited bulk emails!
•  Intentional – e.g., advertising through fraud links!
•  Unintentional – e.g., by infected computers !
•  Worm: Malicious code that makes copies of itself and
attaches to other computers !
•  Spoofing – impersonated e-mails/websites hoping to
“phish” the recipients or for them to open attachment!
E.g., replace “.org” with “.com”!
! replace “l” with “1”!
•  Trojans: Program that appears legitimate but has hidden
damages (e.g., viruses, delete files, create back door for
attacks)!
•  Bots: Automated software to interact with other network
services (e.g., IM). Malicious bots can infect networks
like worms!
•  Phishing – spams or malicious websites intended to get
sensitive information from recipients !
!
http://www.lavasoft.com/mylavasoft/company/blog/the-big-three-email-nuisances-spam-phishing-and-spoofing!
Hewett
Texas Tech University
15
Hewett
Texas Tech University
16
4
Internet Communication!
Heartbleed!
Plain Text!
“My social ID is
123456789”
Internet
“My social ID is
123456789”
“My social ID is
123456789”!
Alice
Bob
Alice sent “My social ID is
123456789” to Bob
Sniffer
Texas Tech University
“Secured” Internet Communication!
Cryptographic protocols that !
Encrypted/Decrypted Texts!
“My social ID is
123456789”
Encrypt
•  Provide secured communication over the Internet !
Internet
“My social ID is
123456789”
“XYABSZED
MI123456”!
SSL (Secure Socket Layer)!
Decrypt
Alice
Bob
Alice sent
“XYABSZEDMI123456”
to Bob
•  Are widely used, e.g., !
•
•
•
•
•
web browsing!
electronic mails!
Internet faxing!
instant messaging!
voice-over-IP (VoIP)!
NO SSL
http://www.cnn.com
http://www.google.com
SSL enabled web browsing
https://www.bankofamerica.com
https://www.facebook.com
Sniffer
5
“Secured” Internet Communication!
OpenSSL!
•  Open-source implementation of the SSL (Secure Socket
Layer) and TLS (Transport Layer Security) protocols!
Encrypted/Decrypted Texts!
Internet
“My social ID is
123456789”
SSL
•  Implements basic cryptographic functions!
“My social ID is
123456789”
“XYABSZED
MI123456”!
•  > 50% of web servers on Internet use functions from
OpenSSL to provide HTTPS (secure connection)
protocol!
SSL
Alice
Bob
Alice sent
“XYABSZEDMI123456”
to Bob
Sniffer
!
37% of HTTP Server
on the internet !
14% of HTTP Server
on the internet !
Heartbeat !
Heartbleed !
•  OpenSSL extension proposed as a standard in
February 2012 by RFC 6520 !
•  Failure of bounds checking in SSL Heartbeat request!
•  Provides tests to keep secure communication links alive
without renegotiation the connection (handshaking)!
Heartbeat
Server, if you are!
there, send me this !
4 letter word, “bird”!
Client Requests 4 letters !
for “bird”!
Server Memory Space!
bird!
Server
Has connected. !
User Bob has !
connected. User Alice !
wants 4 letters: bird. !
Server Master key is !
31331498531054. !
User Carol wants!
to change password to!
“Maddog123”…………!
Heartbleed
Server Memory Space!
bird Server !
Master key!
Has connected. !
User Bob has !
Is 3133149!
Server, if you are!
connected. User Alice !
8531054.!
there, send me this !
User Carol ! wants 4 letters: bird. !
500 letter word, “bird”!
Wants ……! Server Master key is !
31331498531054. !
!
User Carol wants!
!
Server to change password!
Client Requests 500 letters !
To “Maddog123”…….!
for “bird”!
Leaked!
•  Server key!
•  User Password, etc.!
6
Post Heartbleed Recovery!
How to check Heartbleed!
•  Revocation of the compromised keys!
•  Establish Client-Server Handshaking!
•  Reissuing and redistributing new keys!
•  Send Heartbleed request* !
–  Contact Certificate Authority!
No output return or Return Error à SAFE!
–  Reset passwords after new certificates are authorized!
Return content à UNSAFE!
!
!
!
!
!
* Code to check Heartbleed implemented in NodeJS programming
!https://github.com/kphongph/heartbleedjs.git!
Example of buffer overflow!
Buffer Overflow!
A program with buffer of size 10 bytes!
void foo(char *s) {
char buf[10];
strcpy(buf,s);
printf(“buf is %s\n”,s);
}
…
foo
(“thisstringistoolongforfoo”);
Texas Tech University
7
Layout of Program Call!
Smashing the Stack!
Goal: To overwrite the Return Address!
x = 2;
foo
(“12345678901”);
y = 3;
void foo(char
*s) {
int a,b;
char buf
[1000];
strcpy(buf,s);
printf(“buf is
%s\n”,s);
}
“12345678901”! Parameters!
Addressof(y=3)! Return Address!
Calling Stack
Frame!
a, b!
!
!
Bufferof(1000)!
Local Variables!
Buffer Area!
!
!
!
Smashing the Stack in Web Server!
Attacker:!
•  Generates malicious content
(+malicious code) >1000 bytes !
•  Sends it as the user input to
overflow (and take control) the
web server!
void login(char
*user) {
char* username;
char buf[1000];
strcpy
(buf,username);
…
}
Example: Request
“user:ASDFBSDFSAF……
&password:………………..”!
!
How? !
x = 2;
foo
(“12345678901”);
y = 3;
void foo(char
*s) {
int a,b;
char buf
[1000];
strcpy(buf,s);
printf(“buf is
%s\n”,s);
}
“12345678901”! Parameters!
Return Address!
!
!
Local Variables!
!
!
!
!
!
!
Buffer Area!
Smashing the Stack: Example!
var post_data = querystring.stringify({
’username' : ’ASFDSFSFDSFSDDVSFDDS.. .', %% > 1000 bytes
’password' : ’XXX123’
});
var post_options = {
host: ’eraider.ttu.edu’,
From source of web page!
path: ’/authenticate.asp',
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
'Content-Length': post_data.length
}
};
var post_req = http.request(post_options, function(res) {
res.setEncoding('utf8');
res.on('data', function (chunk) {
console.log('Response: ' + chunk);
});
});
post_req.write(post_data);
Send data via “post” command!
8
Login Scenario!
SQL* Injection Attack!
!
SQL syntax:!
Malicious SQL statements are inserted into a
data entry field for execution!
SELECT password
FROM profiles
WHERE user_id = ‘<user input>’
foo
xxx
SELECT password
FROM profiles
WHERE user_id = ‘foo’
!
* SQL (Structured Query Language) is a programming language !
for querying and managing data in the database !
Texas Tech University
Login Scenario Attack!
!
SQL syntax:!
foo; DROP TABLE profiles;
SELECT password
FROM profiles
WHERE user_id = ‘<user input>’
xxx
SQL Injection Defense!
!
foo; DROP TABLE profiles;
xxx
SELECT password
FROM profiles
WHERE user_id=‘foo’;DROP TABLE profiles;
à SQL injection attack eliminates Table “profiles”!
Assumption: Attacker knows the target, e.g., Table “profiles”!
Other names
SELECT password
FROM profiles
WHERE user_id=‘foo’;DROP TABLE profiles;
à SQL Error since TABLE profiles does not exist!
à Moving Target Defense = Randomly generate TABLE names!
What is the target in this example?
9
Other injection possibilities!
Attackers can!
Cross-Site Scripting (XSS)!
•  Inject new data to the database, e.g., !
•  Sell politically incorrect items!
•  INSERT command to input in the data entry!
•  Modify data in the database!
•  Discount price on an expensive item!
•  UPDATE command in the injected SQL!
•  Gain access to other userʼs system by obtaining their
passwords!
!
Texas Tech University
Cross-site Scripting (XSS)!
Example!
•  Enables attackers to inject client-side script into Web
pages viewed by other users!
•  Enables attackers to bypass access controls from the
Clientʼs policy!
Browser
Server
Welcome alice
user_name=“alice”
Cross-Site!
Scripting!
•  “Foreign” scripts sent to the client!
•  Languages
•  Attacker makes Web-Server
delivered malicious script
•  Embedded in Web page (html)!
•  Executed by Web Browser
Welcome alice
…
PRINT ‘Welcome ’ + user_name;
…
Web Application
(e.g., JavaScript, VBScript, ActiveX) !
10
Example of Simple Attack!
Browser
Simple Attack in Blogging!
POST Forum Message
-----------------------------------------Subject: GET Money for FREE!!!
Body:
<script>attack code</script>
Server
Welcome
hijack!
user_name=“<script>
alert(‘hijack’);
</script>”
…
PRINT ‘Welcome ’ + user_name;
…
Welcome <script>
alert(‘hijack’)
</script>
Web Application
Server
Attacker
BlogID = 1
Subject: Help Wanted!!!
BlogID = 2
Body:
Subject: Sale iPhone
I need
help
….
Body:
Subject: GET Money for FREE!!! BlogID = 3
I need
money Vacation Package!!!
Body:
BlogID = 4
Subject:
<script>attack
code</script>
Body:
Want to sell …..
Blogging Web Application
Request BlogID = 3
Browser interpret <script>alert(‘hijack’)</script>
as the executable script and execute it.!
Victim
Blogging user
From XSS attacks …..!
•  Crash Userʼs Browser (e.g., Pop-Up-Flooding, Redirection)!
à Denial-of-service!
•  Access to Userʼs machine and use ActiveX objects !
à Access/upload userʼs local data to attackerʼs machine!
•  Load main frame content from “other” locations!
à Redirect to illegitimate download !
Response from Server
Subject: GET Money for FREE!!!
Body:
<script>attack code</script>
Executed by the client-side
Web Browser!
Impact of XSS attacks!
•  Web server: Access to authentication credentials for
Web applications, Cookies, Username and Password!
à Loss customer trust/reputation/money !
•  Web clients: !
•  Normal Users: Access to personal data (Credit
card, Bank Account), business data, Misuse of the
account (e.g., order expensive goods)!
•  High privileged users !
•  Control over Web application !
•  Control/Access on Web server machine!
•  Control/Access on Backend/Database systems!
XSS is a very harmful flaw !!
11
Outline!
Tools!
•
Basic Concepts!
•  Web application scanners:!
•
Security Types and Perspectives!
•  SpikeProxy (Debian Project)!
•
Attacks and Threats!
•  WebInspect (SPI Dynamics)!
•
Some Tools and Research Snapshots!
•
Conclusions!
•  Penetration Testing tools: conducting security testing for
web applications!
•  Enable crafting of http request/responses!
!
•  Analysis of session Ids, cookies, tokens, etc. for
randomness features and !
!
!
•  WebScarab (OWASP project) Samspade (Samspade)!
•
Hewett
45
Texas Tech University
http://www.slideshare.net/Softwarecentral/software-testing-conference-2005-security-testing-for-web!
Hewett
Texas Tech University
Counter Measures!
46
URL Analysis in Contexts!
Goal: Identify malicious URLs to prevent !
•  Phishing, Spamming and Malicious Download!
Client !
Web Browser!
•  Social Engineering!
Phishing! à URL Analysis!
•  Malware!
•  CrossSite Scripting!
Internet Crime!
•  Click Fraud! à Detection!
Web Server!
Approaches: !
•  HeartBleed!
•  Buffer Overflow!
•  Dynamic Analysis: running script and verify if it is safe
à accurate but expensive !
Web Application!
•  SQL Injection!à Moving Target !
•  Static Analysis:!
Defense!
•  Compare with URL blacklist (e.g., Phishtank) and
whitelist (customized)!
Web Server/Application Software!
à Access Control!
à Security Risks!
•  URL Analysis!
•  Page Analysis!
Hewett
Texas Tech University
47
Hewett
Texas Tech University
48
!
!
!
12
URL Analysis!
Counter Measures!
Use known attack signatures as heuristics for detecting
malicious sites, e.g.,!
•  Obfuscated URLs!
!http://193.08.123.30/www.ebay.com/ws/htm
or more than four periods in directory name space
Client !
•  Social Engineering!
Phishing! à URL Analysis!
•  Malware!
•  CrossSite Scripting!
•  Redirection!
http://usa.visa.com/track/dyredir.jsp?rDirl=http://200.251.251.10/.verified/
•  Mismatched Domain Names!
!<a href = "http://www.fakedomain.net/verifysession.php">
http://secure.bank.com/Ebanking/logon/</a>
Hewett
Texas Tech University
Web Server!
Web Browser!
•  Click Fraud! à Detection!
Hewett
Web Application!
•  SQL Injection!à Moving Target !
Defense!
Web Server/Application Software!
Internet Crime!
49
•  HeartBleed!
•  Buffer Overflow!
à Access Control!
à Security Risks!
50
Texas Tech University
Motivations!
Automatic Click Fraud
Detection in Web
Advertisement !
•  Web advertisement is a major source of revenues for online
services!
•  Pay-per-click model: For each click on an advertisement!
!
Broker passively allows
fraud for profits!
Rattikorn Hewett & Abhishek Agarwal
!
High # clicks!
pays!
Advertiser!
ASE International Conference on Cyber Security
Washington D.C.
Competitors deplete an
advertiserʼs budget!
$
Broker
(e.g., Google)!
 $$$
pays!
Publisher!
 $$$
Publishers earn illegal profit!
Texas Tech University
13
Click Frauds!
Click Fraud Detection!
•  Internet crimes where !
•  Why is it hard?!
clicks are deliberately performed !
•  Fraud behaviors evolve over time!
with no real interest in the target ad!
•  Frauds can be performed by both humans and software bots!
to mimic a legitimate user for generating a charge on the ad!
!à may require distinctive behavioral characteristics!
•  Hard to track user identity (IP addresses can change)!
!
•  Detection of click frauds is desirable!
•  How?!
For Broker à To protect reputation!
•  Detection at the brokerʼs side (e.g., Google, Yahoo, etc.)!
For Advertisers à To protect revenues!
•  Detection at the advertiserʼs side!
!à More limited data than that of the brokerʼs!
!
Our Research!
Proposed Approach!
Problem: Given a web serverʼs log data on an advertiserʼs site.!
Dempster-Shafer Theory, a Theory of Evidence, that allows: !
Is there any click frauds on this site?!
!
•  Reasoning about uncertainty based on combined evidences!
•  Probability assignment to a set of hypotheses, e.g., !
Issues: Most existing automated techniques rely on !
!
•  Signature-based !
!à canʼt detect unseen new patterns!
•  Classifier-based !
!à needs a historical training data set that may be outdated!
•  Broker serverʼs data!
!à not publically accessible !
14
Proposed Approach!
Dempster-Shafer Theory, a Theory of Evidence, that allows: !
•  Reasoning about uncertainty based on combined evidences!
•  Probability assignment to a set of hypotheses!
•  Combination of mass functions (measuring a probability and a
belief of a set of hypotheses) from different evidences!
Evidence for Click Fraud Detection!
Evidence 1: On number of clicks!
High number of clicks in a short time  likely fraud!
Evidence 2: On time spent at ad-site!
Spent a long time at the ad-site  likely ~fraud!
Evidence 3: On visit patterns!
Visit ad-site via ad click after visit via URL  likely fraud!
!
Evidence 4: On click origin!
Click where advertiser has no business  likely fraud!
!
Evidence 5: On time of click!
Click during suspicious time of the day  likely fraud!
!!
Illustration!
•  Experiments with Synthetic Data containing information on:!
Data Sample!
IP Address
Click No
Time of click
Page
Referrer
172.16.276.3
1
3/5/2012 1:50
index.htm
adsite.htm
172.16.276.3
2
3/5/2012 1:56
index.htm
adsite.htm
172.16.276.3
3
3/5/2012 2:01
page1.htm
index.htm
•  Time of click!
172.16.276.3
4
3/5/2012 2:07
page2.htm
page1.htm
•  Page requested!
172.16.276.3
5
3/5/2012 2:13
index.htm
google.com
•  Page referred !
172.16.276.3
6
3/5/2012 2:18
page1.htm
index.htm
172.16.276.3
7
3/5/2012 2:23
page2.htm
page1.htm
172.16.276.3
8
3/5/2012 2:33
index.htm
null
172.16.276.3
9
3/5/2012 2:35
page1.htm
index.htm
172.16.276.3
10
3/5/2012 2:37
page2.htm
page1.htm
•  User IP address (also Googleʼs ID – eliminate redundancy)!
! à infer click location!
•  Click number (only in a specified time window)!
!à infer whether the visit is via ad or non-ad!
!
!
!
15
A scenario!
A scenario!
Visit via URL
Visit via
URL
Visit via ad
Visit via
ad
Bel(Fraud) increases
•  Three clicks during three short visits, each is a sec apart
•  One click during a 4 sec visit via URL with “login” + “shopping”
•  Four clicks during four short visits, each is a sec apart
Experimental Results!
# of clicks
Time spent on site
Bel(Fraud) increases
Bel(Fraud) decreases
Limitations!
visit pattern!
•  Experiments with synthetic data since no public data available!
•  Incomplete set of mass functions à can be extended easily!
•  No comparison with related systems à not available!
!
Click origin!
!
!
!
!
!
!
Time of click!
Combined belief values!
16
Conclusions & Future work!
Counter Measures!
•  Present an automated approach to click fraud detection!
•  Based on well-established theory!
Client !
•  Can detect new unseen patterns!
Web Browser!
•  Social Engineering!
Phishing! à URL Analysis!
•  Malware!
•  CrossSite Scripting!
•  On-line computation on new incoming data!
•  Does not require large database!
•  Easily extensible framework!
•  Future work: more experiments to gain understanding of!
Internet Crime!
•  Effectiveness of the proposed approach!
•  Click Fraud! à Detection!
•  Characteristics of other click fraud behaviors!
Hewett
Web Server!
•  HeartBleed!
•  Buffer Overflow!
Web Application!
•  SQL Injection!à Moving Target !
Defense!
Web Server/Application Software!
à Access Control!
à Security Risks!
Texas Tech University
66
Motivations!
Information System Securit!
•  Modern enterprises increasingly rely on !
!information systems to provide their
functionalities!
•  Managing access authorities is critical to
security of the information systems !
Rattikorn Hewett & Phongphun Kijsanayothin
•  Role-based access control (RBAC) models are
widely used to enforce access authorization!
IEEE SMC
Texas Tech University
Hewett
Texas Tech University
68
17
Access Control Models!
Three types of models:
Issues!
Authorized commands
Most existing work in RBAC deals with!
Specifications of security constraints!
Mandatory Models !
Protected
Objects (e.g.,
Discretionary Models
document)
! → The constraints may or may not be satisfied!
Users
•  Prior to run-time: Role Assignment
Roles
(e.g., clerk)
E.g., clerk →{Ann, Bob}
•  At run-time: Role Activation
E.g., clerk → Bob
Role-based Models!
→  Gain flexibility since users roles can be reassigned easily without
changing access control
Hewett
69
Texas Tech University
Hewett
Issues!
Issues!
Most existing work in RBAC deals with!
Most existing work in RBAC deals with!
•  Specifications of security constraints!
•  Specifications of security constraints!
! → The constraints may or may not be satisfied!
! → The constraints may or may not be satisfied!
•  Access authorization enforcement assumed by
logical inferences at run-time
70
Texas Tech University
•  Access authorization enforcement assumed by
logical inferences at run-time
!
!→ When violation occurs, it may be too late to fix !
!→ Delays or operation failures!
!
!→ When violation occurs, it may be too late to fix !
!→ Delays or operation failures!
•  Logic-based systems that tend to be difficult to
understand and do not scale easily!
!
Hewett
Texas Tech University
71
Hewett
Texas Tech University
72
18
Our research!
Separation of Duties (SoDs) !
A systematic technique that supports!
•  Common security policy constraints !
•  Automated verification of security constraints
(instead of specification) !
•  Protect frauds by ensuring that no single user
receives too many authorities!
•  Analysis for authorization enforcement prior to runtime (i.e., before execution of action/operation, role
activation) !
•  Realized by Mutually Exclusive Roles (MER): a
set of pairs of conflicting roles!
! E.g., (Claim clerk, Auditor) ∈ MER!
Type & print
Approve & sign
•  Comprehensibility and scalability by employing setbased algorithms!
A check payment
x should not be both a claim clerk & an auditor ⇒ Static SoD!
Hewett
Texas Tech University
73
Hewett
Types of SoD constraints!
Simple Dynamic
Object-based
Operational
Weak History-based
Hewett
•  Input: a design of RBAC information system!
•  Output: either yes - the design satisfies SD-SoD
or a counter example of role activations causing
a violation - to be fixed!
•  x can t be both r and r
Static
•  x can be both r and r but!
not at the same time!
•  Basic idea:!
•  x can be both r and r at the same time!
but not on the same object !
•  Identify mutually exclusive roles in MER!
•  x can be both r and r at the same time!
but not on the same operation!
•  Annotate each activity of the system operation with
authorized access (role, action, objects) !
•  x can be both r and r at the same time!
but not on the same object or operation !
Texas Tech University
74
Simple Dynamic(SD)-SoD Verification!
!For any mutually exclusive roles r and r and
any user x!
Strong
Texas Tech University
75
•  For each operation, use MER to search for a valid role
activation for each activity in order of the operation
path in a depth first search manner!
Hewett
Texas Tech University
76
19
SD-SoD Verification: An Example!
(clerk, write, claim-info)
(clerk, read, claim-info)
No
Identify &
Retrieve claim
Yes
Enter
New Claim
New Claim?
(clerk, read, insurer-info),
 (clerk, update, claim-info)
Check
Eligibility

(examiner, update, claim-info)
Review Medical
Procedure Code
(clerk, update, claim-info)
(examiner, update, claim-info)
Evaluate
coverage
No
Notify
Claimant
Error?
Yes
In
Compliance?
A Health Insurance Claim Process:!
Roles: Clerk, Examiner, Supervisor, Manager, Director !
Actions: read, write, update!
Objects: claim-info, insurer-info, EoB, check!
User Role Assignment (UR):!
!Roles
Personnel
No
Yes
(examiner, update, claim-info)
Authorize
Payment
Yes
Reasonable
Cost ?
No
(supervisor, update, claim-info)
(clerk, write, {check, EOB})
Investigate
Utilization
Prepare check
& EOB report
Mutually exclusive roles:!
(supervisor, update, {claim-info, EOB})
Verify/Approve
payment
No
No
Payment
> $5K ?
Yes
(director, write, check)
Approve Account
& Sign Check
Possible
Litigation?
Yes
✔ (director, update, claim-info)
Review
investigation
report
Approve claim &
Sign Check
✔ (manager, update, {check, EOB})
(clerk, update, claim-info)
Examiner!
x!
Supervisor!
x!
Manager!
Director!
Update claim
status
Hewett
Clerk
A, B
Examiner A, B, C
Supervisor B, C
Manager C, D
Director
C
x!
x!
x!
Clerk!
x!
x!
x!
✔
Examiner! Supervisor! Manager!
77
Texas Tech University
SoD Verification: An Example!
Enter Claim
Clerk: claim-info
Check Eligibility
Clerk: claim-info
Review Med Proc Code
Examiner: claim-info
Evaluate Coverage
Examiner: claim-info
Authorize Payment
Examiner: claim-info
Prepare check & EOB report
Clerk: check, EOB
Verify/Approve Payment
Supervisor: claim-info, EOB
Approve Account, Sign Check
Manager: check, EOB
Investigate Utilization
Supervisor: claim-info
Review investigation Report
Director: claim-info
Update claim status
Clerk: claim-info
Hewett
Role Hierarchy & Delegation!
Claim Processing Director
Claim
Supervisor
Account
Manager
Claim
Examiner
Claim Clerk
Texas Tech University
Obj-SoD
B
A
x!
Director!
x!
Clerk!
B
B
B
A|A
A
C
x!
Manager!
B
B
B
x!
A
A
A
Examiner!
Supervisor!
A
A
C
D
B|B
C|B
C|C
D
x!
x!
x!
x!
Examiner! Supervisor! Manager!
User Role Assignment:!
Roles
Personnel
Clerk
A, B
Examiner
A, B, C
Supervisor B, C
Manager
C, D
Director
C
C
C
D
D
A
A
Texas Tech University
78
Conclusions!
•  Present a systematic approach to analyzing SoD
constraints in RBAC information systems !
User Role Assignment:!
Roles
Personnel
Clerk
A, B C, D
Examiner A, B, C
Supervisor B, C
Manager
C, D
Director
C
•  Advantages of our technique:!
•  Supports automated verification of security
constraints prior to run-time !
•  Changes prior to commitment of role activations
are easy to implement → helps prevent failures of
critical operations!
Simple role hierarchy:
personnel with roles at a higher level!
are qualified to take roles at lower levels!
•  General for reuse in multiple local contexts (e.g.
in distributed systems) → provides building block
capability for scalable enforcement of access
control authorization!
Our approach: !
•  applies the same way when role hierarchy is employed!
•  is useful for verification especially when changes occur!
due to delegation
Hewett
SD-SoD!
79
Hewett
Texas Tech University
80
20
Outline!
Conclusions!
•
Basic Concepts!
•  This talk has covered!
•
Security Types and Perspectives!
•  Basic concepts of Web Security!
•
Attacks and Threats!
•  Attacks !
•
Some Tools and Research Snapshots!
•  State of the arts!
•
Conclusions!
•  Some Research Snapshots!
•  Not likely to find tools to prevent “Attacks”!
!
•  Evolving techniques are necessarily to combat attacks!
!
•  Recent trends are to make attackers work harder to
attack by moving targets à Moving targets defense!
!
Hewett
Texas Tech University
81
Hewett
Texas Tech University
82
21