This whitepaper discusses a suggested process to achieve the deployment of host-based intrusion prevention (HIPS) policies in any organization and how the Symantec Data Center Security: Server Advanced Targeted Prevention policy can play a major role in helping the organization gain confidence in Symantec’s intrusion prevention technology.
Symantec Webinar Using Advanced Detection and MITRE ATT&CK to Cage Fancy Bear
Data Center Security: Achieving Prevention & the Targeted Prevention Policy's Role
1. Data
Center
Security:
Server
Advanced
6.x
ACHIEVING
PREVENTION
&
THE
TARGETED
PREVENTION
POLICY’S
ROLE
Daniel
Lopez
Date
published:
June
5th
2015
Document
Version:
1.0
2.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
2
June
5
2015
Contents
Introduction
........................................................................................................................................................................................................
3
The
Challenge
.....................................................................................................................................................................................................
3
Solution
1:
Prevention
deployment
suggested
best-‐practice
process
......................................................................................
4
Phase
1
-‐
Monitoring/IDS
only
..............................................................................................................................................................
4
Phase
2
–
Targeted
Prevention
Policy
...............................................................................................................................................
5
Phase
3
–
Learning
Mode
(log
only)
....................................................................................................................................................
5
Phase
4
–
Full
System
Protection
.........................................................................................................................................................
5
Solution
2:
Gain
confidence
in
prevention
technology
by
using
the
Targeted
Prevention
Policy
................................
6
About
the
Targeted
Prevention
Policy
...............................................................................................................................................
6
How
the
policy
works
................................................................................................................................................................................
7
Use
Cases
........................................................................................................................................................................................................
8
Memory
Protection
................................................................................................................................................................................
9
Resource
Restriction
..........................................................................................................................................................................
10
Network
Control
..................................................................................................................................................................................
11
Privilege
De-‐escalation
......................................................................................................................................................................
12
Blacklist
....................................................................................................................................................................................................
13
SDCSSA
Agent
Self-‐Protection
........................................................................................................................................................
14
Application
Protection
......................................................................................................................................................................
15
Summary
...........................................................................................................................................................................................................
20
Glossary
.............................................................................................................................................................................................................
20
3.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
3
June
5
2015
INTRODUCTION
This
whitepaper
will
discuss
a
suggested
process
to
achieve
the
deployment
of
host-‐based
intrusion
prevention
(HIPS)
policies
in
your
organization
and
how
the
Symantec
Data
Center
Security:
Server
Advanced
Targeted
Prevention
policy
plays
a
major
role
in
helping
your
organization
gain
confidence
in
Symantec’s
intrusion
prevention
technology.
THE
CHALLENGE
The
ultimate
goal
for
an
IT
Security
team
is
to
protect
assets
in
their
environment.
One
way
to
do
this
is
to
deploy
an
intrusion
prevention
solution,
which
will
provide
a
pro-‐active
security
model
rather
than
the
traditional
reactive
model
from
solutions
like
antivirus
products.
Intrusion
prevention
solutions
will
lock
down
systems
and
prevent
zero-‐day
threats
without
the
need
for
updates
like
virus
definitions.
The
main
goal
to
protect
assets
is
something
the
business
units
within
an
organization
will
agree
upon.
Often
however,
when
seeking
to
implement
prevention
technologies
the
security
teams
will
get
push
back.
This
is
due
to
lack
of
confidence
in
the
ability
to
deploy
a
prevention
solution
and
still
allow
for
regular
business
practices
to
continue.
However,
proposing
the
following
two
questions
can
mitigate
this
challenge:
1. What
process
can
the
IT
security
team
set
in
place
to
gradually
introduce
intrusion
prevention
to
the
organization
without
causing
business
disruption?
2. How
can
the
IT
security
team
build
confidence
in
the
technology
so
that
business
units
see
the
benefit
in
their
investment?
4.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
4
June
5
2015
SOLUTION
1:
PREVENTION
DEPLOYMENT
SUGGESTED
BEST-‐PRACTICE
PROCESS
The
graph
below
represents
the
four
recommended
phases
and
suggested
best-‐practice
process
to
achieve
intrusion
prevention:
Figure
1
-‐
Prevention
Deployment
Best-‐practice
Suggested
Process
Phase
1
-‐
Monitoring/IDS
only
SDCSSA
includes
intrusion
detection
policies
with
abundant
security
and
monitoring
intelligence
for
Windows
and
Unix
based
operating
system
environments.
Some
examples
of
such
policy
intelligence
includes
rule
sets
to
detect
Active
Directory
changes,
login
and
access
activity,
OS-‐specific
system
critical
file
monitoring,
privilege
command
and
bash
monitoring,
among
many
others.
Additionally,
based
on
the
operating
system
type
and
version
of
the
SDCSSA
agent
it
is
capable
of
using
real-‐time
file
integrity
monitoring
to
provide
instantaneous
information
about
file
access
and
modifications
proving
extremely
helpful
for
auditing
and
compliance
needs.
The
implementation
of
detection
policies
is
rather
straightforward;
you
must
enable
or
disable
the
specific
rules
for
which
you
wish
to
generate
events
for.
If
there
are
monitoring
requirements
not
met
in
the
out-‐of-‐
box
detection
policies
the
user
can
build
rules
to
fit
their
specific
use
cases.
During
the
server
monitoring
cycles
you
can
generate
alerts
and
notifications
based
on
triggered
events.
These
alerts
and
notifications
can
then
be
fed
into
your
organization’s
information
security
analysis
and
action
process.
5.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
5
June
5
2015
Phase
2
–
Targeted
Prevention
Policy
Moving
beyond
detection,
the
second
and
most
important
phase
to
achieve
intrusion
prevention
is
to
take
advantage
of
the
Targeted
Prevention
policy.
The
Targeted
Prevention
policy
will
allow
you
to
focus
on
specific
uses
cases
(large
or
small)
without
the
risk
of
numerous
false
positives
and
the
need
for
a
major
business
and
administrative
process
around
policy
tuning.
This
policy
is
very
important
because
it
will
help
establish
prevention
technology
confidence
in
the
business
units
and
high-‐level
management;
furthermore,
it
will
help
establish
a
sense
of
priority
in
on-‐going
business
operations
and
revenue
streams
while
solidifying
its
security.
The
section
of
this
whitepaper
named
“Solution
2:
Gain
confidence
in
prevention
technology
by
using
the
Targeted
Prevention
policy”
will
cover
the
Targeted
Prevention
policy
in
detail
with
some
specific
use
case
examples.
Phase
3
–
Learning
Mode
(log
only)
Assuming
that
you
have
successfully
implemented
Targeted
Prevention
use
cases
and
your
organization
now
has
assurance
in
the
intrusion
prevention
technology
it
is
time
to
move
security
capabilities
to
a
higher
level,
by
implementing
additional
prevention
policies.
The
SDCSSA
prevention
policies
have
the
ability
to
run
with
“prevention
disabled”
which
allows
the
SDCSSA
agent
to
detect
and
generate
events
triggered
by
the
prevention
rules
but
not
actually
prevent
(deny)
the
action
from
occurring,
it
merely
reports
on
it.
As
such,
this
prevention
policy
feature
facilitates
a
“learning
mode”
where
it
is
possible
to
understand
the
behavior
of
any
application
or
process/daemon
running
on
the
system.
Ideally
in
this
step
you
have
a
narrow
focus
on
one
or
more
set
of
critical
servers
in
the
organization
(i.e.
domain
controllers,
database
servers,
etc.).
You
will
then
apply
and
leave
the
policy
in
“learning
mode”
for
a
defined
time
period
during
which
you
can
ensure
that
the
machine(s)
have
gone
through
all
possible
operational
iteration.
This
is
a
very
important
step
as
it
provides
visibility
into
the
full
server
threat
landscape
and
identifies
specific
customization
requirements
for
specific
server
workloads
that
will
be
used
in
the
last
phase.
Phase
4
–
Full
System
Protection
The
last
phase
of
the
prevention
deployment
best
practice
suggestion
is
where
you
actually
turn
prevention
on
to
start
pro-‐actively
protecting
your
server
environment.
At
this
point
you
have
a
blueprint
of
the
way
a
server(s)
behaves
thanks
to
the
prevention
policy’s
“learning
mode”.
Taking
advantage
of
this
information
the
prevention
policy
is
then
customized
to
lockdown
down
and
enable
full
protection
of
the
applications/services
running
on
the
server,
ensuring
the
specific
server
use
case
is
accurately
achieved
while
protecting
the
server
operating
system
and
resources
as
a
whole.
Some
additional
comments
to
consider
as
you
step
through
all
four
phases
are:
• Before
starting
with
phase
two
it
is
recommended
that
a
server
risk
assessment
be
executed
to
define
a
good
starting
point
for
protection.
The
goal
of
the
assessment
is
to
establish
a
reachable
and
accountable
asset
protection
plan
that
can
be
presented
to
upper
management.
6.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
6
June
5
2015
• Per
figure
one
above,
there
is
a
trade
off
between
your
desired
security
posture
and
time/effort.
The
more
time
and
effort
you
are
willing
to
put
into
the
SDCSSA
implementation
the
more
protection
it
will
yield
for
your
organization.
• The
policy
tuning
process
effort
is
generally
larger
at
the
beginning
of
the
project.
Overtime
the
effort
and
load
levels
down
as
policy
rules
and
control
can
be
reused
across
different
servers.
• Assuming
that
some
security
is
better
than
no
security,
each
phase
can
be
achieved
individually
but
it
is
highly
recommended
that
you
follow
the
specific
listed
order.
Once
each
phase
is
completed
you
will
be
incrementally
increasing
the
security
stance
of
your
environment
provided
you
have
the
right
business
processes
in
place
to
support
and
administer
the
SDCSSA
implementation.
SOLUTION
2:
GAIN
CONFIDENCE
IN
PREVENTION
TECHNOLOGY
BY
USING
THE
TARGETED
PREVENTION
POLICY
The
Targeted
Prevention
policy
was
introduced
in
Critical
System
Protection
5.28
MP2.
The
policy
was
designed
for
very
specific
customer
scenarios
where
one
specific
prevention
rule
needed
to
be
in
place
without
the
need
of
locking
down
the
entire
system
and
go
through
the
whole
policy
tuning
process.
The
Targeted
Prevention
policy
takes
a
different
approach
than
the
legacy
policy
security
template
and
new
Windows
6.0
security
strategies
in
that
there
are
no
resources
restrictions
that
are
enabled
by
default
on
the
operating
system
or
network
controls.
About
the
Targeted
Prevention
Policy
The
Targeted
Prevention
policy
provides
the
following
options:
Global
Policy
options
-‐
Provides
a
set
of
global
options
that
apply
to
all
the
processes
on
the
system.
When
you
apply
a
global
option
in
the
policy,
it
is
applied
to
all
the
sandboxes
(or
PSETs)
in
the
policy.
Built-‐In
sandbox/PSET
options
-‐
Provides
a
set
of
options
to
configure
the
built-‐in
sandbox.
These
are
only
displayed
when
Show
advanced
options
normally
hidden
in
the
policy
is
selected.
These
built-‐in
sandboxes
include
the
Kernel
Driver
options,
Remote
File
Access
options,
and
the
self-‐protection
sandboxes,
which
include
the
Symantec
Data
Center
Security
Server
agent
and
manager.
Default
sandbox/PSET
options
-‐
With
the
exception
of
built-‐in
sandboxes,
the
policy
routes
all
processes
to
a
default
sandbox.
All
protection
features
are
configurable
in
this
default
sandbox.
My
Custom
Programs
-‐
One
or
more
custom
programs
can
be
defined
within
the
policy,
which
can
override
the
security
settings
in
the
default
sandbox.
Additionally,
custom
lists
can
be
created
and
referenced
elsewhere
in
the
policy.
If
you
set
disable
prevention
at
a
global
level,
then
SDCSSA
protection
disables
prevention
for
all
sandboxes.
You
can
also
enable/disable
prevention
per
individual
sandbox,
be
it
the
default
sandbox
or
any
individual
custom
sandbox.
7.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
7
June
5
2015
How
the
policy
works
The
Targeted
Prevention
policy
takes
a
different
approach
than
the
Core,
Strict
and
Limited
legacy
policy
templates
and
the
newer
security
strategies.
By
default
all
applications
and
services/daemons
are
routed
to
the
default
sandbox.
Figure
2
-‐
Default
Sandbox
Any
restrictions
that
are
placed
at
this
level
will
affect
all
applications
and
services/daemons
running
on
the
system.
If
Buffer
Overflow
and
Thread
Injection
Detection
are
enabled
at
this
level
it
will
apply
to
everything
that
is
running
on
the
system.
In
some
cases
a
customer
might
be
just
looking
to
deploy
a
prevention
policy
to
implement
network
rules
or
restrict
access
to
a
certain
directory.
This
could
easily
be
done
with
this
policy.
To
define
specific
rules
for
individual
applications
or
service/daemon
a
custom
sandbox
can
be
created
and
defined.
When
an
application
or
service
is
placed
in
a
custom
sandbox,
the
restrictions
that
are
placed
at
that
level
will
supersede
anything
set
at
the
global
Policy
Option
level.
There
are
two
different
types
of
custom
sandbox
that
an
application
can
be
placed
in:
8.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
8
June
5
2015
Figure
3
-‐
Two
Custom
Sandboxes
Categories
1. Fully
open
PSET
–
If
an
application
or
service/daemon
is
place
in
this
sandbox
category
there
will
be
no
restrictions
placed
on
that
process,
even
if
a
restriction
was
applied
at
the
global
level.
When
choosing
this
starting
point
you
start
with
a
fully
open
sandbox
and
gradually
close
down
the
security
of
the
process.
2. Fully
closed
PSET
–
If
an
application
or
service/daemon
is
placed
in
this
sandbox
category,
the
process
will
be
completely
denied
access
to
any
resource
including
network,
files,
registries,
etc.
In
other
words,
when
choosing
this
custom
control
as
a
starting
point
you
start
from
a
fully
closed
sandbox
and
you
will
need
to
gradually
open
up
the
security
for
the
process.
Use
Cases
Use
Case
Description
Memory
Protection
The
customer
is
only
interested
in
protecting
their
system(s)
against
zero
day
attacks.
The
Targeted
Prevention
policy
can
be
deployed
with
buffer
overflow
and
thread
injection
detection
enabled
at
the
default
PSET
option
level.
This
will
provide
memory
protection
for
all
applications
and
services
running
on
the
system.
Resource
Restriction
Customer
wants
to
protect
access
to
intellectual
property
on
the
server.
A
resource
restriction
can
be
placed
at
the
Default
PSET
option
level
restricting
access
to
a
directory
or
file.
This
will
apply
to
all
applications
and
services
running
on
the
system.
9.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
9
June
5
2015
Use
Case
Description
Network
Control
Customer
wants
to
limit
network
access
to
a
server.
Network
rules
can
be
written
at
the
Default
PSET
option
level
restricting
inbound
and
outbound
connections
to
and
from
the
box.
Privilege
De-‐
Escalation
Customer
wants
to
restrict
the
movement
and
capabilities
of
an
administrator
or
root
user.
A
resource
restriction
can
be
placed
at
the
Default
PSET
option
level
to
help
determine
what
each
user
or
group
can
access
or
do.
Blacklist
Customer
wants
to
black-‐list
certain
applications
from
running
on
the
server.
A
fully
closed
custom
sandbox
will
be
used
for
this.
SDCSSA
Agent
Self-‐
Protection
Customer
wants
to
only
use
the
intrusion
detection
policies
but
wants
to
protect
the
SDCSSA
agent
from
being
tampered
with.
This
will
apply
to
all
applications
and
services
running
on
the
system
and
can
prevent
an
attacker
from
tampering
with
the
SDCSSA
agent’s
resources
and
services.
Application
Protection
Customer
wants
to
quickly
protect
a
single
application
or
service/daemon
without
having
to
go
through
the
entire
policy
tuning
process.
MEMORY
PROTECTION
Buffer
overflows
and
thread
injection
prevention
to
everything
running
on
the
system
By
enabling
all
the
rules
in
the
memory
controls
section
of
the
default
sandbox
and
applying
the
policy
this
will
protect
all
applications
and
services
running
from
buffer
overflow,
thread
injection,
unusual
memory
permission
changes.
1. Open
the
Targeted
Prevention
policy
2. Click
on
Sandboxes
3. Click
on
Edit[+]
next
to
Default
Sandbox
options
4. Click
on
the
Memory
Controls
section
5. Check
the
boxes
next
to
Enable
Buffer
Overflow
Detection,
Block
unusual
memory
allocations,
Block
unusual
memory
permission
changes,
and
Block
turning
off
Data
Execution
Prevention
(DEP)
6. Save
the
policy
and
apply
it
10.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
10
June
5
2015
Figure
4
-‐
Default
Sandbox
Memory
Controls
RESOURCE
RESTRICTION
Protect
critical
data
without
worrying
about
full
application
or
system
lockdown
The
Targeted
Prevention
policy
does
not
provide
any
sort
of
operating
system
or
application
lockdown
by
default.
This
allows
you
to
focus
on
a
single
protection
goal
without
having
to
worry
about
tuning
the
entire
policy
for
third-‐party
applications
and
unique
operating
system
behaviors.
You
can
use
a
resource
restriction
to
lock
down
critical
files
from
either
being
changed
or
accessed.
To
prevent
changes
to
a
specific
file
using
the
Targeted
Prevention
Policy:
1. Open
the
Targeted
Prevention
policy
2. Click
on
Sandboxes
3. Click
on
Edit[+]
next
to
Default
Sandbox
options
4. Click
on
File
Rules
section
5. Check
the
box
next
to
Block
modification
to
these
files
underneath
the
Read-‐only
Resource
Lists
6. Click
on
Edit[+]
next
to
expand
Read-‐Only
Resource
Lists
7. Click
the
Add
button.
8. Enter
the
path
and
filename
for
Resource
Path.
a. Examples
C:tempflag.txt,
C:temp*,
C:temp*.txt,
C:temp?file.txt
9. Click
OK.
10. Save
the
policy
and
apply
it.
11.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
11
June
5
2015
Figure
5
-‐
Read-‐only
file
resource
NETWORK
CONTROL
Restrict
network
traffic
to
a
critical
servers
Network
rules
can
be
written
to
restrict
traffic
to
and
from
a
server
in
the
Targeted
Prevention
policy.
One
of
the
options
that
can
be
used
is
to
only
allow
systems
within
the
same
subnet
to
communicate.
1. Open
the
Targeted
Prevention
policy
2. Click
on
Sandboxes
3. Click
on
Edit[+]
next
to
Default
Sandbox
options
4. Click
on
the
Network
Controls
section
5. Check
the
box
next
to
Inbound
network
rules
6. Click
on
Edit[+]
next
to
Inbound
network
rules
a. Click
on
Add
b. Create
a
rule
with
the
following
information:
Action
Protocol
Local
Port
Remote
IP
Remote
Port
Logging
Allow
TCP
Any
(0-‐
65535)
Local
Ipv4
Subnet
Addresses
Any
(0-‐
65535)
Log
7. Click
on
Edit[+]
next
to
Default
Inbound
rule
a. Set
the
Default
inbound
rule
action
value
to
Deny
8. Check
the
box
next
to
Outbound
network
rules
12.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
12
June
5
2015
9. Click
on
Edit[+]
next
to
Outbound
network
rules
b. Click
on
Add
c. Create
a
rule
with
the
following
information:
Action
Protocol
Local
Port
Remote
IP
Remote
Port
Logging
Allow
TCP
Any
(0-‐
65535)
Local
Ipv4
Subnet
Addresses
Any
(0-‐
65535)
Log
10. Click
on
Edit[+]
next
to
Default
outbound
rule
11. Set
the
Default
outbound
rule
action
value
to
Deny
12. Save
the
policy
and
apply
it.
Figure
6
-‐
Inbound
Allowed
For
Subnet
Only
PRIVILEGE
DE-‐ESCALATION
Restricting
the
movement
and
capabilities
of
an
administrator
or
root
user
The
Targeted
Prevention
policy
restriction
rules
allow
extreme
granularity
permitting
de-‐escalation
of
privileges
by
locking
resources
to
specific
users,
groups,
and/or
programs;
stopping
insider
abuse
use
cases.
In
the
scenario
shown
below,
a
local
administrator
will
not
have
the
ability
to
access
the
financial
data
on
a
server,
which
he/she
administers.
Instead,
the
only
individuals
who
have
access
to
this
information
will
be
the
“Finance”
group.
Note
that
this
could
also
be
Active
Directory
group,
i.e.
<Domain_name>Finance.
1. Open
the
Targeted
Prevention
policy
13.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
13
June
5
2015
2. Click
on
Sandboxes
3. Click
on
Edit[+]
next
to
Default
Sandbox
options
4. Click
on
the
Files
Rules
section
5. Check
the
box
next
to
Block
all
access
to
these
files
6. Click
on
Edit[+]
next
to
Block
all
access
to
these
files
a. Click
on
Add
button
b. In
the
Resource
Path
file
type
the
name
of
the
file(s)/folder(s)
you
will
like
to
deny
access
to
(example
c:FinanceAppcredit_card_data.txt).
c. Click
OK.
Figure
7
-‐
Restrict
file
resource
7. Check
the
box
next
to
Allow
but
log
modifications
to
these
files
8. Click
on
Edit[+]
next
to
Allow
but
log
modifications
to
these
files
a. Click
on
Add
button
a. In
the
Resource
Path
file
type
the
name
of
the
file(s)/folder(s)
of
the
same
file
you
block
access
to
(example
c:FinanceAppcredit_card_data.txt)
b. In
the
Program
Path
field
type
the
application
which
can
be
used
to
access
this
data
(example:
*notepad.exe*)
c. In
the
Group
Name
field
type
the
name
of
the
group
whom
you
want
to
grant
access
to
modify
this
data
(example:
Finance).
d. Click
OK
e. Save
the
policy
and
apply
it
Figure
8
-‐
Allow
Group
to
Read/Write
File
Resource
BLACKLIST
Restrict
certain
application(s)
from
running
on
a
server
With
the
Targeted
Prevention
policy
a
security
or
system
administrator
can
make
sure
that
if
certain
applications
are
executed
on
the
system
then
they
have
no
rights
to
do
anything.
This
is
done
by
placing
an
application
in
a
fully
closed
custom
PSET
that
prevents
it
from
having
any
access
to
resources
on
the
system.
In
this
scenario,
a
custom
PSET
called
Blacklist
will
prevent
an
application
from
running
in
a
machine.
14.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
14
June
5
2015
1. Open
the
Targeted
Prevention
policy
2. Click
on
My
Custom
Sandboxes
and
Lists
3. Click
on
the
Plus
sign
(Add
a
new
Custom
Control)
4. Enter
Blacklist
in
the
display
name.
This
will
be
the
name
of
this
new
custom
sandbox.
5. For
category,
select
This
custom
program
PSET
is
fully
closed
and
locked
down
by
default.
6. Type
Blacklist
again
for
identifier.
This
is
a
unique
name
for
this
sandbox
(no
spaces
are
allowed).
Figure
9
-‐
New
Fully
closed
custom
PSET
7. Click
Finish
8. Click
on
Edit[+]
next
to
new
Blacklist
custom
PSET
control
9. Check
and
expand
This
custom
program
PSET
is
fully
closed…
10. Click
on
Add
11. Enter
the
path
to
the
program
in
the
Program
Path
field
12. Click
OK
13. Save
and
apply
policy
SDCSSA
AGENT
SELF-‐PROTECTION
Deploy
instrusion
detection
(HIDS)
but
make
sure
that
the
SDCSSA
agent
is
self
protected
The
Targeted
Prevention
policy
includes
controls
to
protect
the
SDCSSA
agent
against
any
attack
to
its
services
and/or
resources.
In
a
scenario
where
only
detection
policies
(HIDS)
will
be
used
you
can
still
deploy
the
Targeted
Prevention
policy
on
the
same
agent
to
include
self-‐protection.
1. Open
the
Targeted
Prevention
policy
2. Click
on
Sandboxes
15.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
15
June
5
2015
3. Click
on
Edit[+]
next
to
Default
Sandbox
options
4. Check
the
box
next
to
Enable
SDCSS
Self
Protection
5. Save
and
apply
policy
Figure
10
-‐
Enable
Self
Protection
APPLICATION
PROTECTION
Customer
wants
to
lock
down
a
single
application
Instead
of
going
through
the
motions
of
tuning
a
policy
for
the
entire
system,
the
Targeted
Prevention
policy
allows
you
to
lock
down
a
single
application
or
service.
In
the
scenario
below,
a
Windows
Apache
webserver
installation
will
be
locked
down.
The
scenario
will
walk
through
how
to
prevent
unauthorized
users
from
making
changes
to
the
web
server
configuration
and
html
files.
Additionally,
it
will
allow
only
the
admin
to
have
access
to
make
changes
to
configuration
files
using
notepad
only.
Step
1:
Block
access
to
apache
folder
Create
a
rule
to
block
modifications
to
the
Apache
configuration
and
html
files.
The
below
option
will
block
modifications
to
all
files
under
the
Apache
directory
1. Open
the
Targeted
Prevention
policy
16.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
16
June
5
2015
2. Click
on
Sandboxes
3. Click
on
Edit[+]
next
to
Default
Sandbox
options
4. Click
on
the
Files
Rules
section
5. Check
the
box
next
to
Block
all
access
to
these
files
a. Click
on
Add
button
b. In
the
Resource
Path
file
type
the
%programfiles%Apache
Software
FoundationApache2.2*
c. Click
OK.
Figure
11
-‐
Block
Access
to
Apache
Files
Step
2:
Allow
modifications
to
Apache
folder
only
by
Administrator
using
Notepad
Create
a
rule
that
allows
only
the
admininstrator
user
to
use
notepad
in
order
to
make
modifications
to
configuration
files
under
the
Apache
directory.
1. Go
back
to
the
Policy
editor
Home
2. Click
on
My
Custom
Sandboxes
and
Lists
3. Click
on
the
Plus
sign
(Add
a
new
Custom
Control)
4. Enter
Notepad
in
the
display
name.
This
will
be
the
name
of
this
new
custom
sandbox.
5. For
category,
select
This
custom
program
PSET
is
fully
open,
it
has
no
default
security
restrictions.
6. Type
Notepad
again
for
identifier.
This
is
a
unique
name
for
this
sandbox
(no
spaces
are
allowed).
7. Click
Finish
8. Click
on
Edit[+]
next
to
new
Notepad
custom
PSET
control
9. Check
and
expand
This
custom
program
PSET
is
fully
open…
17.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
17
June
5
2015
10. Click
on
Add
11. Enter
%systemroot%System32notepad.exe
in
the
Program
Path
field
12. Click
OK
Figure
12
-‐
Notepad
Custom
PSET
13. Expand
the
File
Rules
section
14. Check
and
click
on
Edit[+]
next
to
Allow
Modification
to
these
files
15. Click
on
Add
16. Type
the
following
information
in
the
corresponding
fields
a. Resource
Path:
%programfiles%Apache
Software
FoundationApache2.2*
b. Program
Path:
%systemroot%System32notepad.exe
c. User
name:
admin
17. Click
OK
18.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
18
June
5
2015
Figure
13
-‐
Limit
modifications
to
admin
only
With
this
rule
only
the
admin
user
can
use
notepad
and
to
make
any
changes
to
the
Apache
configuration
files.
Step
3:
Allow
modifications
to
Apache
folder
only
by
Administrator
using
Notepad
Create
a
rule
that
allows
the
Apache
application
to
read/write
to
its
directory
and
configuration
files.
1. Go
back
to
the
Policy
editor
Home
2. Click
on
My
Custom
Sandboxes
and
Lists
3. Click
on
the
Plus
sign
(Add
a
new
Custom
Control)
4. Enter
Apache
in
the
display
name.
This
will
be
the
name
of
this
new
custom
sandbox.
5. For
category,
select
This
custom
program
PSET
is
fully
open,
it
has
no
default
security
restrictions.
6. Type
Apache
again
for
identifier.
This
is
a
unique
name
for
this
sandbox
(no
spaces
are
allowed).
7. Click
Finish
8. Click
on
Edit[+]
next
to
new
Apache
custom
PSET
control
9. Check
and
expand
This
custom
program
PSET
is
fully
open…
10. Click
on
Add
11. Enter
%programfiles%Apache
Software
FoundationApache2.2binhttpd.exe
in
the
Program
Path
field
12. Click
OK
13. Expand
the
File
Rules
section
14. Check
and
click
on
Edit[+]
next
to
Allow
Modification
to
these
files
19.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
19
June
5
2015
15. Click
on
Add
16. Type
%programfiles%Apache
Software
FoundationApache2.2*
for
the
Resource
Path
17. Click
OK
18. Save
and
apply
policy
With
these
three
simple
steps
you
are
constraining
the
ability
of
any
user
or
application
(other
than
the
administration
using
Notepad
and
Apache
itself)
to
access
the
Apache’s
directory,
which
contains
critical
log,
executables,
and
configuration
files.
Any
access
to
these
files
and
directories
will
be
denied
across
the
operating
system
without
compromising
other
less
critical
services.
The
simplicity
of
this
policy
makes
testing
and
implementation
of
these
rules
very
simple
to
achieve
in
either
a
development
or
production
environment
providing
you
have
the
ability
to
disable
prevention
and
still
trigger
events
as
if
prevention
would
have
taken
a
pro-‐active
action.
20.
Achieving
Prevention
and
the
Targeted
Prevention
Policy
Role
Page
20
June
5
2015
SUMMARY
Achieving
least
privilege
access
control
across
your
server
environment
using
Symantec’s
intrusion
prevention
technology
takes
time,
effort,
and
commitment
but
it
will
yield
an
exceptional
security
result.
Using
the
suggested
phased
deployment
approach
explained
in
this
document
along
with
the
Targeted
Prevention
policy
can
help
you
achieve
results
faster
and
help
your
organization
gain
confidence
in
Symantec’s
Data
Center
Security:
Server
Advanced.
GLOSSARY
SDCSSA,
SDCSS,
DCS
-‐
Symantec
Data
Center
Security:
Server
Advanced
PSET,
PS
–
Process
set.
This
is
the
product’s
technical
name
for
sandboxes.