Secure APEX Development

Secure APEX
Development
Scott Spendolini
President & Co-Founder
Welcome
2 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

ABOUT THE PRESENTER
• Scott Spendolini
• [email protected]
• @sspendol
• Ex-Oracle Employee of 10 years
• Senior Product Manager for Oracle APEX
from 2002 through 2005
• Founded Sumner Technologies

in October 2005
• Co-Founded Sumneva in January 2010
• Oracle Ace Director
• Co-Author,
Pro Oracle Application Express
• “Scott” on OTN Forums

ABOUT SUMNEVA
• Specializing in Oracle Application Express
• Training
• Instructor Led On-Site or Online
• Private & Public
• Consulting
• Anything APEX-related
• Solutions/Products
• sumnevaSERT
• sumnevaFramework

AGENDA
• Overview
• Threats
• Mitigation
• Summary
• Q &A

Overview

OVERVIEW
• Security is hard
• If it’s easy, then it’s wrong

HOW SECURE IS “SECURE ENOUGH”
• It Depends On:
• What you’re protecting
• Who you’re protecting it from
• The likelihood of someone wanting to steal what you are
protecting
• The repercussions you would face if someone did in fact
steal what you’re protecting

EXAMPLE: RURAL HOUSE
• Modest House
• Good neighborhood
• Small, rural town
• Low to no crime
• Before break-in: left front
door wide open
• After break-in: Keep shotgun by the bed

EXAMPLE: URBAN HOUSE
• Not-so-modest House
• Good neighborhood
• Big city
• Some crime
• Before 9/11: Occasionally
see SWAT agents hiding
in the bushes
• After 9/11: They see you first

REACTIVE APPROACH
• Unfortunately, adding layers of security is typically
event-driven

PROACTIVE APPROACH
• Simulate the breach

SIMULATE THE BREACH
• Few organizations do this
• Too expensive
• Too time-consuming
• Too inconvenient
• Too improbable
• Simulation is the single-most effective tool in

discovering weaknesses

APACHE.ORG EXAMPLE
• On April 9th, 2010, someone implemented a
successful cross-site scripting (XSS) attack on one of
Apache.org’s systems
• Which allowed the hackers to gain access to privileged
accounts in their issue tracking system
• Which allowed them to steal other credentials from users logging in
by replacing a key JSP with a hacked version
• Which allowed them to access yet additional servers...
• See this link for details of the attack:

https://blogs.apache.org/infra/entry/apache_org_04_09_2010

APACHE.ORG EXAMPLE
• As a result of the attack, Apache published a list of
steps that are being taken to prevent this from
happening again:
ere
n s w
c t i o 1 0 ?
re a , 2 0
es e l 8 t h
f t h p r i
all o r e A
o r b ef o
o m e o r
i f s o n
ha t n t ed
W em e
p l
im

BLIPPY.COM EXAMPLE

BLIPPY.COM EXAMPLE
• During testing, the developers “hid” credit card
numbers in the HTML source
• Most people would not see this
• Only compromised 4-5 card numbers

• But trust in the site was shaken
• As was privacy concerns in general
• Thus, the HTML pages were cached by Google

and later exposed to the public

BLIPPY.COM EXAMPLE

MAIN SECURITY CONSIDERATIONS
• 1) Security is a Process
• It is NOT an event
• Hackers will never stop trying to break into your site; thus
you can never stop trying to protect it
• 2) Security should be designed on day one

• Building an application and then trying to secure it is foolish
• 3) Security should be similar for external and

internal systems
• Most breaches come from within

THE ENEMY WITHIN
• 1/3 of employees would
steal data if they thought they
could make money on it
• 68% claim that it’s “easy” to steal data
• 88% claim the data they have access
to is “too valuable”
• 2/3 of employees have actually

stolen data when they leave
• Using it as leverage for new positions
Sources: http://www.pcworld.com/businesscenter/article/163797/one_third_of_employees_would_steal_sensitive_data.html
http://www.pcworld.com/businesscenter/article/160041/nearly_twothirds_of_exemployees_steal_data_on_the_way_out.html

Threats

THREATS
• There’s a number of threats that we need to be
concerned with for any web application - APEX
or otherwise
• URL Tampering
• SQL Injection
• Cross Site Scripting
• Unauthorized Data
Access

URL TAMPERING
• Most dangerous form of attack
• All it takes is one working finger to implement
• No code
• No programming knowledge
• No special circumstances
• Worse, most developers - especially

those coming from client/server
environments - are completely
unaware of it

SQL INJECTION
• Attack where malicious user supplies input to a form
that changes the structure of the SQL that executes
• Used to:
• Drop objects
• Create objects
• View unauthorized data
• Analyze a schema for other
weaknesses

LITTLE BOBBY TABLES
Source: http://xkcd.com/327/

SQL INJECTION BY EXAMPLE
• Great article chronicling how a site vulnerable to SQL
Injection attacks can be easily compromised
• Steve Friedl's Unixwiz.net Tech Tips
• http://www.unixwiz.net/techtips/sql-injection.html

CROSS SITE SCRIPTING
• Most sophisticated type of attack of the three
• Malicious code from or on another system
executes as you view a seemingly innocent page
• Most often, you have no idea that this
occurred
• Used to typically steal session
information, so your session can be
hijacked by someone else
• Sophisticated to implement and pull off,
but very devastating when done properly,
as they often go undetected for long periods of time

UNAUTHORIZED DATA ACCESS
• We can do a lot to prevent users from seeing data
they are not authorized to see
• We can do little to prevent users from seeing data
they are not supposed to see
• Thus, there’s almost nothing we can do to prevent
curious users from looking at data they are not supposed to

MISGUIDED TRUST?
• In fact, we trust some of out most sensitive
information with the most complete
strangers
• Bank Tellers
• Loan Officers
• Waiters/Waitresses
• Pharmacists
• Medical Receptionists & Personnel
• Customer Service Call Centers

LAST LINE OF DEFENSE
• Thus, all we can do to prevent this type of “attack” from
occurring is simply audit it
• This will provide a list of who accessed it and when they did, so
that actions can be taken, if necessary
• The Oracle Database provides a robust set of Auditing

Tools that can be used with APEX
• Triggers & Custom Audit tables
• Database Auditing
• Fine Grained Auditing
• Oracle Audit Vault

“OCTOMOM” & KAISER EXAMPLE
pe e k e d a t Oc tom om file s
Kaiser fined - worke rs
| By Vi ct oria Colliver, Chronicle Staff Writer
May 16, 2009
's Be llf lo w er ho sp ita l $2 50 ,000 for failing

r Permanente
State regulators fined Kaise e m ed ic al re co rd s of oc tu plet mother Nadya
accessing th
to prevent employees from
ion.
Suleman without authorizat ac y laws that took effect
unde r ne w st at e pa tie nt pr iv
The fine is the first of its kind
Jan. 1.
23 em pl oy ee s, in cl ud in g two physicians, at the
ed
A Kaiser investigation reveal lit ie s in So ut he rn Ca lif orni a improperly
r Kaiser faci
Bellflower hospital and othe sh or tly af te r th e bi rt hs on Jan. 26. As a result,
al records
accessed the patient's medic re si gn at io ns of 14 ot he rs an d took disciplinary
pted the
Kaiser fired one worker, acce
ees.
actions against eight employ
http://articles.sfgate.com/2009-05-16/business/17200917_1_state-fines-kaiser-kaiser-
spokesman-jim-anderson-kaiser-permanente-s-bellflower-hospital

OBAMA & VERIZON WIRELESS EXAMPLE
November 20, 2008
8:41 PM PST
Report: Obama
's cell records
improperly acce
ssed
President-elect Ba
rack Obama's cell
accessed by emplo phone billing reco
yees of Verizon W rds were improperl
Obama's transition ireless, late on Th y
team was informe ursday.
representatives on d of the breach by
Wednesday, team Verizon Wireless
agency. The Secre spokesman Robert
t Service has been Gibbs told the new
informed, Gibbs sa s
id.
The phone, a voic
e flip-phone with n
used by Obama, th o e-mail access, is
e report said. Lists no longer active o
Obama could have of phone numbers r being
been accessed, b and calls made by
Gibbs is quoted as ut "nobody was m
saying. onitoring voicema
il,"
Verizon Wireless h
as notified federal
Wireless Presiden law enforcement a
t and Chief Execu uthorities, Verizon
company e-mail d tive Lowell McAda
istributed on Wedn m wrote in an inte
esday that CNN o rnal
btained.
http://news.cnet.com/8301-1009_3-10104997-83.html

Mitigation

MITIGATION
• Now that we’re aware of the threats, we need to do
all that we can to mitigate them
• While APEX provides some utilities to help combat
some of the threats, a more sound approach would be
to architect a secure foundation

PROPER ASSESSMENT
• Take time to identify the most likely threat
• Not the most spectacular one
• Devote most resources to mitigate the most

likely threat
• While not totally
ignoring some of
the spectacular
ones

Shadow Schema

SHADOW SCHEMA
• All secure APEX applications should parse as a
limited or no privilege schema
• Can’t use SQL Injection to run DML and/or DDL if the
schema can not execute DML and/or DDL
• This schema should contain only

two types of objects:
• Read-Only Views
• Synonyms to call APIs (packages)

SHADOW SCHEMA
APEX “Parse As” Schema
SHADOW DATA
• Views GRANT SELECT ON

• Views
• EMP_V • EMP_V
• Synonyms GRANT EXECUTE ON • Procedures
• EMP_API GRANT EXECUTE ON
• EMP_API
• SET_CTX • SET_CTX
• Tables
• EMP

SHADOW SCHEMA WORKSPACE
• Create a new workspace
• As part of this process, also create the SHADOW schema
• Thus, all applications in this workspace will parse as the SHADOW
schema
• All secure applications will live in this workspace
As APEX Admin: Create new workspace “shadow”

TYPICAL APEX SYSTEM & ROLE PRIVILEGES
• A schema created by APEX’s
wizards will contain the
following system & role
privileges
• You should remove ALL
system & role
privileges from the
SHADOW schema
As SYS: revoke_shadow_privs.sql

WHITE LISTING
• Removing all system & role privileges allows us to
mitigate a range of SQL Injection attacks
• If the schema has no privileges, then a hacker can not
maliciously create or modify objects
• We can selectively add views & APIs and

strictly control what this schema will have the
ability to see & do vs. trying to restrict this schema to
only with with a subset of a larger set of objects

PREVENTING DROPPED OBJECTS
• Despite removing these privileges, a schema will still
have the ability to drop its own objects
• Not catastrophic in our case, since they will only be dropping
views & synonyms to APIs
• But still something we need to prevent
• Thus, we can add a system-level trigger to

prevent objects from being dropped by the
SHADOW schema
As SYS: create_table_foo.sql

SYSTEM LEVEL TRIGGER
Allows only SYS, SYSTEM &

SURROGATE schemas to drop
objects owned by SHADOW
CREATE OR REPLACE TRIGGER prevent_shadow_drop
BEFORE DROP ON DATABASE
BEGIN
IF ORA_DICT_OBJ_OWNER = 'SHADOW'
AND ORA_LOGIN_USER NOT IN ('SYS','SYSTEM','SURROGATE')
THEN
RAISE_APPLICATION_ERROR(-20000, ORA_DICT_OBJ_OWNER
|| ' can not drop ' || ORA_DICT_OBJ_TYPE || 'S.');
END IF;
END;
/
As SYS: prevent_shadow_drop.sql

DATA SCHEMA
• All tables, views, packages & other database objects

will reside in the DATA schema
• No APEX application will ever parse as this schema
• All of our tables, data & PL/SQL code will go here
• For this presentation, we’ll stick with the standard

EMP & DEPT Oracle demonstration tables
As SYS: create_data_schema.sql

PROVIDING ACCESS TO DATA
• The shadow schema will need to see at least some
data from the data schema
• Best to grant SELECT on a VIEW vs. the entire table
• Give us the ability to restrict which columns & rows are
exposed to the shadow schema

CREATING A SHADOW VIEW
• First, we’ll create EMP_V in the DATA schema
• It will only reference EMPNO, ENAME, JOB &
DEPTNO
• We’ll grant SELECT on DATA.EMP_V to SHADOW
• Then, we’ll create EMP_V in the SHADOW

schema
• Which will reference all rows & all columns of
DATA.EMP_V
• Last, we’ll build a form & report in our application

As SYS: emp_v.sql

RUNNING OUR APPLICATION
• When we run our application, we
should see all rows of the EMP
table
• But only the specified four columns as
per the secure view definition
• We can click edit/create/delete

• But it will fail when we attempt to save
the changes with ORA-01031:
insufficient privileges, since we
do not have access to update the view

FACILITATING DML TRANSACTIONS
• Since our views are read-only, we can not use the
build in APEX Row Processing processes
• We must create our own APIs with PL/SQL
• In our APIs, we can run additional security checks or
auditing transactions, should we want to
• We can also limit which DML transactions we

support, based on business rules

AUTOMATING API GENERATION
• Little known feature of the Object Browser:
• Create Package with Methods on Database Tables
• Creates a packages based on a list of tables that will

provide insert, update & delete APIs
• With support for lost update detection

AUTOMATING API GENERATION
• In order to do this, you will need to create an APEX
workspace on the DATA schema
• This will be used only to create the APIs
• No applications will be developed here
• Then, create the table APIs for the EMP table

• You can modify the APIs to restrict what they can & can’t do
• Grant EXECUTE on the resulting package to SHADOW
Create APEX Workspace for DATA & Associated APIs for EMP

RETROFITTING THE APIS
• Next, we’ll need to retrofit our application with the
new APIs so that we can perform DML transactions
on the EMP table
• Disable or delete the Automated Row Processing
(DML) Process in our application
• Create a synonym for the EMP_DML package in the
SHADOW schema
• Add a new PL/SQL process that calls the EMP_DML
package from the data schema for each supported
transaction
As SYS: emp_dml_synonym.sql; In APEX: emp_dml_process.sql

EMP DML PROCESS
IF :REQUEST = 'CREATE' THEN
emp_dml.ins_emp
(
p_empno => :P2_EMPNO,
p_ename => :P2_ENAME,
p_job => :P2_JOB,
p_deptno => :P2_DEPTNO
);
ELSIF :REQUEST = 'DELETE' THEN
emp_dml.del_emp
(
p_empno => :P2_EMPNO
);
ELSIF :REQUEST = 'SAVE' THEN
emp_dml.upd_emp
(
p_empno => :P2_EMPNO,
p_ename => :P2_ENAME,
p_job => :P2_JOB,
p_deptno => :P2_DEPTNO
);
END IF;

DATA SECURITY
• So far, any user can see any row of data from our view
• This may be fine as per our business requirements
• But what if we need to secure the actual data?

• Virtual Private Database
• Secure Views
• Oracle Label Security

SECURE VIEWS
• Allows us to expose only the rows & columns of data we
want to the shadow schema
• Most URL Tampering attempts will be fruitless, as only
authorized data is displayed in the view
• Create a view in the data schema that filters both the

rows & columns of our records based on some criteria
• Create a view in the shadow schema that references the
secured view in the data schema
• This allows us to grant SELECT against the secure view, not the base table
itself
• Build APEX forms & reports against the view in the shadow schema

VIRTUAL PRIVATE DATABASE
• No-cost feature of Oracle Enterprise Edition
• Most of the same benefits of Secure Views
• Automatically applies a WHERE clause to a specified
table or view
• Other features:
• Column Relevance
• Policy applied only when a specific column is part of the query
• Column Filtering
• Only data in a specific column that are allowed by the policy are
displayed; all other rows in that column appear as NULL

ORACLE LABEL SECURITY
• For-cost option for Oracle Database EE
• Allows each row to be classified
• Only users with the corresponding clearance can see those
rows
• Helps enforce regulatory compliance

• Ability to implement “need to know” access
• Integration with Oracle Database Vault &

Oracle Identity Management

APPLICATION CONTEXT
• Serves as a secure data cache for attribute-value pairs
needed for fine-grained access control (secure views
or VPD)
• Cache eliminated the need to query the database to obtain
this data, thus improving performance dramatically
• APEX provides a hook to set the Application Context

on each page view

INCORPORATING CONTEXTS INTO VIEWS
• We can retro-fit our views to incorporate an
Application Context as part of their WHERE
clause to filter which rows they return
• For example: limiting which rows are returned based on
which department a user is in
As SYS: set_ctx.sql

SET_CTX PROCEDURE IN DATA SCHEMA
CREATE OR REPLACE PROCEDURE set_ctx
(p_user_name IN VARCHAR2,
p_app_session IN VARCHAR2) Get the corresponding DEPTNO
IS for the currently signed on user
l_deptno NUMBER;
BEGIN
-- Fetch the DEPTNO based on the currently signed on APP_USER

SELECT deptno INTO l_deptno FROM emp WHERE UPPER(ename) = UPPER(p_user_name);
-- Set the Context

dbms_session.set_context(
namespace => 'DEMO_CTX', Sets the G_DEPTNO attribute in
attribute => 'G_DEPTNO',
value => l_deptno, the DEMO_CTX system context
username => p_user_name, based on l_deptno
client_id => p_app_session);
EXCEPTION
WHEN no_data_found THEN
-- If no data is found, then clear the context
dbms_session.clear_context('DEMO_CTX', p_app_session) ;
END set_ctx;
/

SECURE EMP_V IN DATA SCHEMA
CREATE OR REPLACE VIEW emp_v AS

SELECT
empno,
ename, Call to SYS_CONTEXT will
job, return corresponding DEPTNO
deptno for the currently logged in user
FROM
emp
WHERE
deptno = SYS_CONTEXT('DEMO_CTX', 'G_DEPTNO')
WITH READ ONLY;

SETTING THE CONTEXT IN APEX
• Application Attributes > Security
Attributes > VPD PL/SQL Call to set
security context
• Can be used with or without VPD
• Will run each time any page is rendered

• Sure, it’s overhead, but it’s necessary and relatively benign
In APEX Authentication Scheme: vpd_context.sql

ROW LEVEL ACCESS
• If we run the application now, we get No Data
Found
• We’re logged in as the ADMIN user; there is no ADMIN
user in the EMP table
• Thus, create a new APEX user called KING and log in

as him
• And try to access another user in a different department by
tampering with the URL
• Blake: 7698
In APEX: Create the KING user and login

SURROGATE SCHEMA
• Since we’ve revoked all system & role privileges from
SHADOW, we can’t even sign on to it - let alone
create the required VIEWs and SYNONYMs
• There’s a couple of options:
• Get access to SYS or SYSTEM
• Unlikely
• Create a surrogate schema

• Which has CREATE ANY VIEW & CREATE ANY
SYNONYM granted to it
As SYS: surrogate_schema.sql

SURROGATE SCHEMA
• All tables, views & procedures will go into the DATA
schema
• The SURROGATE schema will be used to create
the corresponding Views & Synonyms in the
SHADOW schema
• In APEX, simply reference the local Views & Synonyms
As SYS: procedure_example.sql

Configuration

CONFIGURATION
• Having a shadow schema is definitely not
enough security for your environment
• Your security strategy must also include:
• Securing your Infrastructure
• Applying APEX Security Features
• Keeping Up with APEX Versions
• Oracle CPU & Quarterly Patches

SECURING YOUR INFRASTRUCTURE
• Architecture
• HTTP Server(s)
• mod_plsql parameters
• Stale user accounts
• Default passwords
• Unused features
• APEX Instance Settings
• Firewalls

APEX SECURITY FEATURES
• APEX offers a number of built-in security controls to
help lock down your application
• Session State Protection
• Page Access Protection
• Hidden & Protected Items
• Authorization Schemes
• However, most of these need to be enabled

• Its your responsibility as a developer to enable those which
you feel you require

APEX 3.2 SECURITY FEATURES
• APEX 3.2 focused on Oracle Forms Conversions
• There were also a number of new Security Features were
incorporated into APEX 3.2 with much less fanfare
• A competent hacker can determine the version of

APEX in seconds, and then focus on exploiting
security issues that are addressed in newer released
• Reason alone to keep up to date with APEX versions

APEX 3.2 SECURITY FEATURES
• Session Timeout
• Encrypted Session State
• Save Session State before Branching
• Autocomplete
• New Password Item
• Database Monitor Disabled
• Reduced DB Privileges
• Require HTTPS
• Runtime Mode

Summary

SUMMARY
• I hope you’re scared
• Not terrified-enough-to-lose-sleep-and-never-leave-the-house scared, but
scared-enough-to-take-security-seriously scared
• It’s unlikely that your site will be hacked

• But that is absolutely not an excuse to not protect it
• Mitigate the unspectacular yet likely first; then address
the spectacular yet unlikely
• Security is a process
• Hackers don’t sleep; neither can we
• Security is hard
ADDITIONAL RESOURCES
• Sumneva APEX Security Reviews
• Infrastructure Review & Analysis
• sumnevaASR
• APEX Security Review tool
• Built in APEX
• Identifies & advises on how to correct common security issues
• Security Best Practices
• Visit http://sumneva.com/security for more

information

Q &A

http://sumneva.com

Secure APEX Development

Uploaded by

Copyright:

Available Formats

Secure APEX Development

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Secure APEX Development

Uploaded by

Copyright:

Available Formats

Secure APEX

2 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

• Founded Sumner Technologies

3 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

• Private & Public

4 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

5 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

6 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

7 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

8 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

9 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

10 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

11 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

12 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

• Simulation is the single-most effective tool in

13 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

• Which allowed them to access yet additional servers...

• See this link for details of the attack:

14 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

15 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

16 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

• Only compromised 4-5 card numbers

• Thus, the HTML pages were cached by Google

17 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

18 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

• 2) Security should be designed on day one

• 3) Security should be similar for external and

19 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

• 2/3 of employees have actually

20 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

21 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

22 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

• Worse, most developers - especially

23 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

24 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

25 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

26 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

27 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

28 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

29 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

• The Oracle Database provides a robust set of Auditing

• Fine Grained Auditing

• Oracle Audit Vault

30 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

's Be llf lo w er ho sp ita l $2 50 ,000 for failing

31 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

32 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

33 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

34 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

• Devote most resources to mitigate the most

35 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

36 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

• This schema should contain only

37 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

• Views GRANT SELECT ON

38 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

• All secure applications will live in this workspace

As APEX Admin: Create new workspace “shadow”

39 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]

40 Copyright © 2010 Sumneva - All Rights Reserved - http://sumneva.com - [email protected]