Strategies for Landing an Oracle DBA Job as a Fresher
IT Architecture Automatic Verification (RCIS 2010)
1. IT
Architecture
Automa/c
Verifica/on:
A
Network
Evidence-‐based
Approach
António
Alegria
(Presen0ng)
Portugal
Telecom
Ins/tuto
Superior
Técnico
–
Universidade
Técnica
de
Lisboa
André
Vasconcelos
Center
for
Opera/onal
Design
and
Engineering
Ins/tuto
Superior
Técnico
–
Universidade
Técnica
de
Lisboa
2. Roadmap
• Problem
Statement
• Proposed
Approach
• Proof
of
Concept
Prototype
• Case
Study
• Results
• Future
Work
2
3. Problem
Statement
Informa5on
Systems
Architecture
(ISA)
Planning
Process
Is
the
expected
model
correct?
Does
the
implementa5on
meet
expecta5ons?
3
4. How
to
Check
the
Reality
of
IT
Architecture?
• Actual
architecture
emerges
from
Informa/on
Systems’
(IS)
func/on
• IS
manifest
themselves
through:
– Input
and
Output
ar/facts
– Interac/ons
with
other
agents
(humans
or
machines)
• Interac/ons
with
other
systems
are
predominantly
through
TCP/IP
networks
• At
the
technology
level
it’s
possible
to
capture
all
IS’
manifesta/ons
in
corporate
networks
– Security
experts
have
been
doing
it
for
a
long
/me
although
with
a
different
purpose
and
at
a
lower
level
of
abstrac/on
4
5. How
to
Check
the
Reality
of
IT
Architecture?
• How
to
infer
evidence
of
the
actual
architecture
through
the
“bits”
captured
in
the
network?
– Protocol
headers
and
applica/on-‐layer
payload
contain
informa/on
that
serve
as
explicit
or
implicit
evidence
for
the
status
quo
of
the
IS
and
their
architecture
• If
we
capture
all
IS’
network
interac/ons
how
can
we
verify
an
IT
Architecture
(ITA)
model?
– By
confron/ng
that
model
with
all
the
evidence
collected
from
the
network
5
6. Research
Ques/on
How
to
automa5cally
verify
if
an
IT
Architecture
model
is
actually
in
sync
with
current
IS,
resor5ng
exclusively
to
the
passive
analysis
of
their
network
traffic?
6
7. Approach
This
subprocess
is
our
main
focus
(at
the
technology
level)
Cap/on
Extensions:
Verifica5on
Process
Extensions:
Verifica/on
Cycle
Extensions:
Lifecycle
Common
ISA
Planning
Process
7
13. Verifica/on
Process
(Simplified)
Described
in
an
ISA
modelling
language.
We
used
and
extended
the
CEO
Framework’s
(CEOF)
UML
profile.
13
14. Verifica/on
Process
(Simplified)
Knowledge
of
how
to
match/map
a
higher-‐ Verifica5on
realized
by
applying
level
ITA
model
with
the
actual
reality
mirrored
these
rules
to
the
domain
of
the
in
the
collected
network
traffic
architecture
model
and
the
collected
real
ITA
evidence
14
15. Mapping
and
Verifica/on
Rules
Representa5on
of
Factual
Reality
Representa5on
of
ITA
Expecta5ons
Ne^acts
Model
ISA
Modeling
Language
(M1)
(M2)
ISA
Model
(M1)
ISA
Model
Instan/a/on
Ne^acts
Model
Instan/a/on
(M0)
(M0)
• Mapping
between
Ne^acts
evidence
and
ITA
concepts
and
rela/onships
• Specify
the
required
collected
evidence
to
declare
an
ITA
model
in
sync
with
reality
• Generic
and
Organiza5on-‐independent
(defined
at
the
ISA
modeling
language
level
–
M2)
• Defined
by
statements
in
a
subset
of
First
Order
Logic
(Horn
clauses)
• The
actual
ITA
Verifica5on
is
realized
by
checking
if
these
rules
hold
for
a
given
domain
15
16. Pucng
it
all
together
Generic
Mapping
Verified
ITA
Model
Rules
ITA
Verifica5on
and
(Logtalk)
(Logtalk)
Inference
Engine
Domain-‐independent
Knowledge
Base
Network
Traffic
Analysis
Engine
Deep
Applica/on-‐layer
Fact
Base
Parser
(ITA)
?
Fact
Base
Streamer
Sub-‐Applica/on-‐layer
Traffic
Classifier
and
Dispatcher
(Network
Evidence)
Inspector
NeVacts
Inference
Engine
IPAudit
p0f
HTTP/SOAP
Parser
(Prolog)
(LogTalk)
Raw
Traffic
PCAP
Superficial
Applica/on-‐ SQL
Parser
User
Interface
layer
Inspector
PADS
Oracle-‐TNS
Parser
Verifica/on
Report
TXT
16
17. Case
Study
• Portugal
Telecom
• Sales
IS
ecossystem
• Applied
approach
to
accurate
and
inaccurate
(with
known
devia/ons)
models
• Traffic
passively
captured
in
several
points
of
the
corporate
network
– ~1
Terabyte
of
data
– 1
workday
• Prototype
applied
to
raw
captured
traffic
17
20. Results:
Correct
Model
• Fully
Iden/fied
architecture
elements:
– «IT
Infrastructure
Block»
– «Opera/ng
System»
– «IT
Applica/on
Block»
– «IT
Services»
– «IT
Services»
Usage
• Par/ally
Iden/fied
architecture
elements
(due
to
lack
of
“built-‐in
knowledge”):
– «IT
Pla^orm
Block»
–
Excep/ons:
§ .Net
Framework
2.0
in
SFAP’s
frontends
§ SQL
Server
2005
in
SFAP’s
data
backends
– «IT
Services»
Realiza/on
–
Excep/ons:
§ One
data
service
supported
by
SQL
Server
2005
(SFAP’s
data
backend)
20
21. Results
(Con/nued…)
• Incorrect
Model:
– All
devia/ons
were
detected
– Most
of
them
explicitly
reported
as
errors
– A
few
cases
were
undecidable
§ Lack
of
evidence
to
support
or
refute
that
architecture
component
§ Prototype
raises
a
“red
flag”
§ Architect
is
lead
to
inves/gate
these
specific
cases
• Knowledge
Discovery
– All
of
the
Ne^acts
evidence
– Undocumented
Architecture
Elements:
§ over
50
«IT
Services»
§ several
«IT
Opera/ons»
and
used
parameters
§ Database
Tables
and
Columns
21
22. Future
Work
• Automa/c
elicita/on
of
ITA
model
Automa/c
Discovery
of
ITA
• From
low-‐level
evidence
infer
high-‐level
model
• Middleware
Complex
IS
Technical
Rela/onships
• Enterprise
Service
Bus
• Applica/on
Logs
Other
Data
Sources
• Ac/ve
Probing
and
Agent-‐based
solu/ons
• Informa/on
Architecture
Other
IS
Architecture
Levels
• Applica/on
Architecture
22
26. Extending
the
CEO
Framework
Cap/on
New
En5ty
New
A^ribute:
«concreteName»
New
A^ribute:
«version»
26
27. Main
Contribu/ons
Passive
Network
Traffic
Automa/c
Analysis
✔
Automa/c
ITA
Unobtrusive
to
the
CEO
ITA
Network-‐
Framework
based
Organiza/on
and
its
Extensions
Verifica/on
Evidence
IS
Process
Model
✔
Organiza/on
Mapping
CEOF2007+
independent
✔
and
Ne^acts
27