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 = ‘’
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 = ‘’
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: attack code
Server
Welcome
hijack!
user_name=“ alert(‘hijack’); ”
… PRINT ‘Welcome ’ + user_name; …
Welcome alert(‘hijack’)
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: attack code Body: Want to sell …..
Blogging Web Application
Request BlogID = 3
Browser interpret alert(‘hijack’) 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: attack code
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! ! http://secure.bank.com/Ebanking/logon/
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
