Application-screen Masking: - PowerPoint Presentation

Slide1

Application-screen Masking: A Hybrid Approach

Abigail Goldsteen, Ksenya Kveler, Tamar Domany, Igor Gokhman, Boris Rozenberg, Ariel FarkashInformation Privacy and Security, IBM Research – HaifaPresented by Abigail Goldsteen W2SP Workshop, San Jose, May 2014

©

2014 IBM CorporationSlide2

AgendaProblemExisting approaches

Our approachChallenges and limitationsComparison between approachesSummaryQuestionsSlide3

AgendaProblemExisting approaches

Our approachChallenges and limitationsComparison between approachesSummaryQuestionsSlide4

ProblemHow to share information while safeguarding the

privacy and security of sensitive dataExisting applications New users/use cases

Need to prevent users from viewing information they are not authorized to seeSlide5

Example

Data Center

Outsourced

Call Center

Germany

India

Balance

:

John Smith

35

$127.50

National ID

:

Name

:Slide6

AgendaProblemExisting approaches

Our approachChallenges and limitationsComparison between approachesSummaryQuestionsSlide7

Existing approaches

Redesign applicationCan be very complicated and costlyNot always possible due to lack of skillsMask values in databaseDifficult to maintain several copiesMay “break” the applicationMask application-screensSensitive values are removed/masked after the application has constructed the visual layout of the screen

Application server

Client

MaskingSlide8

Rule types

Content-basedBased on the text value or its formatCan be defined usingRegular expressionsNatural Language Processing (NLP)Other data classification techniquesExample: A regular expression depicting email addresses

Context-based

Based on the

visual structure

of the screen

Can be defined using

UI constructs (labeled fields

, table columns, drop-down boxes, etc

.)

A

relationship between two entities on the screen

A

bsolute locationsExample: Mask all labeled fields in which the label is “Email Address

”Slide9

Existing application-screen masking approaches (1)

At the network level:FastSecureSimplistic content-based rules

Application server

Client

Web Proxy

HTTP request

HTTP response

Masked

HTTP response

HTTP request

Masking

Masked

screenSlide10

Existing application-screen masking approaches (2)

At the presentation level:Context-based rules defined on screenDifficulties in handling complex screensSevere performance issues

Application server

Client

VNC Server

HTTP request

HTTP response

Masked

RFB

Remote

Framebuffer

(RFB)

Masking

OCR

Masked

screen

UnmaskedSlide11

Existing application-screen masking approaches (3)

At the operating system levelContext-based rules defined on screenInstallation on every end-user machineSecurity issues

Application server

Client

HTTP request

HTTP response

Masked

screen

MaskingSlide12

AgendaProblemExisting approaches

Our approachChallenges and limitationsComparison between approachesSummaryQuestionsSlide13

Hybrid approachMasking at the network level

FastSecureEasy rule definition at the presentation levelContext-based rules defined on screenContent-based rules are also supportedSlide14

Some featuresAll sensitive information is removed from the

message and does not reach the browserCannot be viewed on screen or in page sourceMasking server and proxy are placed within the enterprise’s internal networkSensitive information does not leave the premisesClient requests are also intercepted to check if they contain masked dataThe request is reconstructed with the original data before sending to the serverSlide15

Masking rulesRules are expressed in

Javascript1. Mozilla Spidermonkey, https://developer.mozilla.org/en-US/docs/SpiderMonkey

Each rule is executed on a specific HTTP message

Can be filtered based on URL, server or client IP and username

Several possible masking methods

Remove, Replace, Encrypt, etc.

Powerful

Can define any type of context-based rule

Flexible

Can work on many payload formats (e.g., HTML, XML, JSON, etc.)

Fast

Executed using existing, optimized engine

1Slide16

Visual rule authoringCreating Javascript

rules for individual HTTP messages is very difficultEach displayed element (e.g., table) may originate from several different messagesMay have different formatsMay come from AJAX requestsNeed to use several tools to inspect network traffic, understand the underlying DOM and associate between the displayed element and the messages that created itNeed to write scripts that are syntactically correct and validate that masking is performed correctlyNeed some tool to facilitate rule authoring processSlide17

“Selection tool”Slide18

“Selection tool” close-up

Web-based tool, implemented in

Javascript

A

floating panel

attached to

the original application

Intercepts mouse hovering and click events to enable selectionSlide19

AgendaProblemExisting approaches

Our approachChallenges and limitationsComparison between approachesSummaryQuestionsSlide20

Technical challenges (1)

Automatically creating scripts from user selectionsSlide21

Technical challenges (1)

Our solution: We devised an algorithm for detecting the origin of each screen element while the page is loadingMonitors all web page modifications, compares the DOM before and after the modifications and captures the changes that were initiated by HTTP messagesCreates a map between each visual element and the message it came from, including the message’s URL and the location of the element within the message (e.g., Xpath)Slide22

Technical challenges (2)Interacting with the target application

without changing itNeed to catch DOM changes and add listeners for mouse events in the target applicationBrowsers’ same-origin policy prevents pages/frames from different origins from manipulating each others’ DOMs2This prevents the naïve solution of presenting the target application in its own frame within a larger rule-authoring tool pagePossible solutions:Browser add-onStandalone toolOur solution is based on hidden frames and “injecting” the selection tool code into the application messages using the runtime proxy

2. J. Ruderman, “The same origin policy”, http://www.mozilla.org/projects/security/components/same-origin.html

Both require installation on the rule-author’s machineSlide23

LimitationsC

annot mask information that does not flow over the network, i.e., generated on the client-sideExample: an average that is calculated in the browser using JavascriptCannot mask information that flows in binary formatExamples: images, Java applets, Adobe Flash objects, etc.May fail client-side validationExample: a field that checks for a valid email addressSolution: use

format-preserving masking techniquesSlide24

AgendaProblemExisting approaches

Our approachChallenges and limitationsComparison between approachesSummaryQuestionsSlide25

Comparison of approaches (1)Rule strength and

granularityWe compare our context-based approach with content-based rules and database masking, based on 4 criteria:Masking granularity – the ability to mask exactly what is neededLogical rule coverage - the ability to describe a rule by its logical content (e.g., mask only patient emails)Visual rule coverage - the ability to mask all or part of the elements in a given area of the screenVisual screen context - the ability to create rules in the context of the presentation layerSlide26

ExamplesM

asking granularity:A content-based rule will always mask all phone numbers in the applicationCannot mask only patient phone numbers and not physician phone numbersLogical rule coverage:At the DB layer, any data item can be specified for masking only once, even if it appears on several pages or has several different formatsCannot support cases where a data item in a table

appears in two different contexts, one that should be masked and one that shouldn’t Visual rule coverageOur approach enables masking all items in a given area of the screen, even though there

may not be

any correlation

in the format or

database tableSlide27

Comparison of approaches (2)Rule enforcement

mechanismsWe compare our network-level enforcement with masking at the database level and the at the presentation-layer (using OCR), based on 3 criteria:Application integrity – effects on the proper functioning of the applicationRole-based masking – different masking based on user rolesImpact of screen complexity – do complex screens make masking more difficult?Slide28

ExamplesApplication integrity

At the DB layer, illegal or missing values can result in “breaking” the applicationAt the network layer, client-side validation or calculations may be compromisedImpact of screen complexity Masking at the presentation layer is directly correlated to screen complexityOverlapping or partially visible windows pose a significant challengeNetwork-based masking is somewhat affected by application complexity, e.g., a screen constructed from many different messagesMasking is still possible, but rule definition is more complicatedSlide29

AgendaProblemExisting approaches

Our approachChallenges and limitationsComparison between approachesSummaryQuestionsSlide30

Summary

We showed a hybrid approach that combines context-based rule creation at the presentation level with enforcement at the network levelThis enables: Powerful and flexible rule language Easy and straight-forward rule authoring processMinimal performance impact

at runtimeMasking rules are defined in a simple and intuitive manner while navigating the target application and clicking

on

sensitive

areas

Requires

minimal

changes

to

the existing

environment – no

changes to

the application or databaseSlide31

AgendaProblemExisting approaches

Our approachChallenges and limitationsComparison between approachesSummaryQuestionsSlide32

Questions?Slide33

Thank you