Active Security Common Practices

1
Active Security Common Practices

• Rafal Lukawiecki
• Strategic Consultant, Project Botticelli Ltd

2
Objectives

• Using Defence-in-Depth overview main security
  problem areas
• Review major security protection technologies
• Briefly look at security checklists for main
  Microsoft servers

3
Session Agenda

• Decomposing the Operating Environment
• Defending
• Applications
• Hosts
• Network
• Microsoft Guidance Checklists

4
Decomposing the Operating Environment
5
Defense in Depth
Policies, Procedures, Awareness
Physical Security
ACL, encryption
Data
Application
Application hardening, antivirus
OS hardening, update management, authentication
Host
Network segments, IPSec, NIDS
Internal Network
Firewalls, VPN quarantine
Perimeter
Guards, locks, tracking devices, HSM
User education against social engineering
6
Common Threat Classification
Network
Host
Application
Threats against the network
Spoofed packets, etc.
Buffer overflows, illicit paths, etc.
Threats against the host
SQL injection, XSS, input tampering, etc.
Threats against the application
7
Examples of Network Threats
8
Examples of Host Threats
9
Examples of Application Threats
10
Typical Pattern of a Targeted Attack

• Enter the network through SQL Injection etc.
• Install or use port proxy software to open
  inbound connections
• Remotely control the host to mount further
  attacks from inside until a domain controller is
  accessible
• Gain control of the desired resources
• Erase traces of attack and remove installed
  software

11
What to Do when under Attack

• Engage your Emergency Operating Procedure
• Or increase the emergency level (yellow to red
  etc.)
• Follow these steps
• Identify the nature of the attack
• Localize the source
• Protect and save the evidence
• Find other compromised machines
• Immunise against this problem as soon as practical

12
Attack Vectors Entrypoints

• That is what attacker is looking for
• You always have them
• You must protect them as well as you can
• Bottom leaves (vectors) on the threat tree
• Tree categories of entry
• Social Engineering
• Unpatched known vulnerabilities
• New, generally unknown vulnerabilities

13
Application-Level Entry

• Social engineering
• Trojan via email or messenger
• Application hardening is required to avoid most
  problems
• Buffer overrun
• Secure Coding Practices for Developers
• Automatic Patching for 3rd party apps
• E.g. InstallShield provides this as service

14
Host-Level Entry

• Patching
• Known vulnerabilities are typically exploited by
  worms and zombies
• Least-privilege Principle
• Most restrictive policies
• Most restricted accounts
• Active Protection
• Future direction for automatic out of pattern
  host behaviour
• Very promising
• Virus Protection
• Attachment Execution
• Spyware Protection

15
Network-Level Entry

• Firewalls
• A must (even with Active Protection)!
• Multiple levels between perimeters
• Weak Infrastructure
• Older, unpatched network equipment
• Domain Controllers
• Special hardening required
• Physical Security a must
• Active Directory
• Consistency with policies needs to be verified
• Any unauthorised changes should be investigated
• Physical Security of backup is crucial

16
Typical Security Levels (Microsoft)

• Based on typical security-usability-cost
  requirements, Microsoft favours three generic
  security levels
• Legacy
• Allowing compatibility with Windows 98, ME etc.
  generally most usable and fairly insecure
• Enterprise
• Typical needs of usability based on Windows 2000
  and XP clients with resilience against all
  popular attacks
• Generally cost-effective
• High Security
• Adds pro-active security against future attacks
  based on highly restrictive policies at the cost
  of loss of use of many applications and other
  usability limitations and may use formal security
  modelling
• Expensive but may be worth the price
• Windows Server 2003 Security Guide and other
  Microsoft security guidance documents make use of
  those terms

17
Defending Applications
18
Why Application Security Matters

• Perimeter defenses provide limited protection
• Many host-based defenses are not application
  specific
• Most modern attacks occur at the application
  layer

19
Developers!

• From operational perspective, the problem is
  caused by the developers, of course ?
• Their applications have access to privileged
  resources
• Through vulnerabilities those resources become
  compromised
• Solving the problem requires an almost intimate
  relationship between development and operations

20
Security Baseline

• Use vendor-recommended security baselines
• Such as Microsoft Exchange Server Security
  Guidelines etc.
• Define a universal security baseline for all
  application servers
• Base your baseline on OS vendor recommendations,
  such as Windows Server 2003 Security Guide
  server roles
• Implement them as a policy
• Active Directory Group Policies are an excellent
  way to manage them
• Use resulting policy tool to verify if policy
  applies to hosts as required
• Verification of compliance is an ongoing activity

21
In-House Applications

• Most enterprises use a number of own,
  self-developer applications for a number of key
  business activities
• Those applications rarely meet stringent security
  design requirements
• Developer security education is critically
  important
• Existing applications need to be treated as
  evil until proven to be safe through Threat
  Modelling

22
Treating Unproven Applications

• Until proven to be secure, treat all applications
  as evil
• Restrict access only to users on need-to-use
  basis
• Restrict remote use
• Isolate to dedicated application servers
• Restrict servers through IPSec policies to only
  allow communication that applications explicitly
  require
• Monitor usage pattern to establish a baseline and
  raise alarm when patterns vary
• Enable stringent auditing
• Request a formal threat analysis if above
  restrictions are too severe

23
Developer Relations

• For future in-house and outsourced development,
  formally request that all new application state
  their required security policy and comply with
  baseline policies
• Deal with exceptions very carefully
• Insist that application is tested under
  restrictive security conditions before being
  beta tested or piloted
• Establish an operational point of contact for
  developer queries

24
Secure Development

• .NET applications can use a number of new and
  powerful security techniques
• Advocate that future development should use .NET
  Framework and its security models where possible
• Actual development language is not essential as
  long as the framework is used
• Other middleware environments may require you to
  integrate their security subsystems into OS, Host
  and Network security more manually
• Sometimes this is a significant weakness

25
Recommended .NET Security Mechanisms

• .NET Code Access Security
• .NET Evidence
• Using digital signatures, developers create
  cryptographically strong IDs for their
  applications
• You can use those Strong Names (SNs) for
  creating policies that allow or disallow whole
  classes of applications from running
• You control associated policies
• .NET Isolated Storage
• A new feature allowing applications to create a
  virtual file system in a manner that is more
  resistant to cross-application attacks

26
Defending Hosts
27
OS Hardening

• Use most up-to-date security patches and service
  packs
• Windows XP SP2
• Windows Firewall with application-specific
  settings
• Attachment Execution protection
• Pop-up Blocker
• Memory Protection (only some CPUs)
• RPC/DCOM Improvements
• May cause compatibility problems with legacy
  applications, so you may need to bypass or amend
  this feature
• Apply your policy-based security baseline

28
Patch Management

• Approaches
• SMS (System Management Server)
• Do-it-yourself, time-consuming but most flexible
• Software Update Services
• Youre in control, but only for Windows OS
• Windows Update
• Little enterprise control, only Windows OS, most
  pervasive
• Application-vendor
• Installshield Update, HP Software Update and many
  others
• Use tools, such as MBSA, to discover missing
  patches
• Microsoft Baseline Security Analyser

29
Virus Protection

• Defence in-Depth
• On clients
• On servers
• On firewalls
• Ensure full compliance, especially with signature
  update service
• Consider dual-vendor approach
• Major system on hosts
• Secondary system from a different vendor on
  firewalls and communication servers (email etc.)

30
Attachment Execution

• 1 of Social Engineering attacks (so called
  Layer 8 Vulnerabilities)
• Education is main defence
• Newer software can handle attachments in a
  protected, safer manner
• Outlook 2003
• XP SP2
• Extends to 3rd party applications
• Control via GPOs

31
Spyware (Malware) Protection

• 90 machines have malicious software, on average
  28 separate spyware programs (report by Earthlink
  Webroot)
• Zombies
• Network bandwidth and CPU degradation
• Commercial secrets leaked
• Privacy destroyed
• Best practice
• SpyBot Search and Destroy (www.spybot.info)
• Microsoft AntiSpyware (in beta)
• AdAware

32
Traffic Filtering

• In addition to network firewalls, consider
  enabling incoming and outgoing traffic filtering
  on each host
• Defence in-depth
• Application and user-specific
• Only enable protocols and ports required by
  applications running on the host
• XP SP2 helps in this on workstations
• IPSec rulesets are a great tool for this

33
Defending Network
34
Many Perimeters
Network Edge

• External Network Edge
• Between you and internet etc.
• DMZ De-militarized Zone
• Between network edge and all protected resources
• Only minimal protection possible
• Default Security Zone
• The traditional LAN
• High Security Zone
• Network inside network
• For key assets
• Perimeter (Edge) of Isolation
• Assets physically not connected to networks
• Useful for some key assets (e.g. master keys)

35
Goals of Network Security
36
Intrusion Detection Systems (IDS)

• A reactive and nascent area with only few tools
  available, e.g.
• Certain rule sets for Microsoft Operations
  Manager (MOM) 2005
• Monitored honeypots
• ISS Internet Scanner (www.iss.net)
• Netcat

37
Honeypots

• Hosts (typically servers) left with known
  vulnerabilities
• Disconnected from the rest of the network
• Otherwise a major threat to the enterprise
• Heavily monitored
• Any unauthorised access is allowed to continue in
  a controlled manner
• Provide a great indicator of the source of attack
  and the abilities of the attacker

38
Firewalls

• ISA Server 2004 greatly helps in coping with
  abundant (ab)use of port 80
• Communication between firewalls and servers they
  protect is a growing concern
• Apart from filtering of traffic, consider using
  the firewall for
• Virus scanning
• Intrusion Detection
• Compliance Monitoring

39
Network Device Port Protection

• Wireless
• 802.1x or full use of WPA
• Physical radio coverage modelling
• Wired
• Equivalent of 802.1x for wired networks is
  currently being developed
• Protection against rogue hosts being attached

40
Heterogeneous Systems

• In reality, most enterprises run a bewildering
  array of systems
• Lack of homogeneity creates vulnerabilities in
  inconsistencies
• Authentication
• Multiple PKIs
• Delegation of administration
• Incompatible security
• Can also be a benefit if things go wrong, less
  is affected

41
Single Sign-On

• If possible, strive for a single user identity
  and password (or smartcard) for all security
  needs
• Multiple user accounts with same password are a
  major security hole and administrative nightmare
• Three approaches
• Unified authentication
• E.g. all apps use Kerberos v5 and Microsoft AD
• E.g. use certificates and PKI everywhere
• Synchronised administration
• E.g. Microsoft Identity Integration Server
• Client-based
• Smartcard that automates multiple authentications

42
Unified Delegated Authentication

• Very difficult to impose unless all applications
  have been written to use the same system
• In reality only possible when one system is very
  dominant and others sporadic
• Such as large AD and a small and limited UNIX
  realm
• For web-based applications quite possible
• .NET Passport, or
• WS-Federation and WS-Security in general

43
Distributed PKI Authentication

• Most open and independent solution
• Quite future-proof
• Multiple CAs that recognise each other
• Cross-signing
• Import of each others root certificates
• TLS, WS-Security, CAPI and .NET Fx APIs
• AD Integration
• AD can provide CA autoenrollment and provisioning
• Client certificate properties can automatically
  translate to AD users and roles if needed

44
Recommendation on PKI

• 3-tier structure for resilience and security
• Root CA (offline)
• OU CAs (offline)
• Issuing CAs (online)
• More discussion on PKI problems and issues in
  later sessions today

45
Synchronised Administration

• Microsoft Identity Integration Server
• Changes in one system are translated into a
  meta-directory representation and forced on all
  other participating systems
• Can integrate with HR and other systems
• Fully automated staff provisioning is possible
• Works between AD/AD and AD/other-directories

46
Microsoft Guidance Checklists
47
Application Server Best Practices
Configure security on the base operating system
Apply operating system and application service
packs and patches
Install or enable only those services that are
required
Assign only those permissions needed to perform
required tasks
Applications accounts should be assigned with the
minimal permissions
Apply defense-in-depth principles to increase
protection
48
Top Ten Things to Secure Exchange
1
Install the latest service pack
2
Install all applicable security patches
3
Run MBSA
4
Check relay settings
5
Disable or secure well-known accounts
6
Use a layered antivirus approach
7
Use a firewall
8
Evaluate ISA Server
9
Secure OWA
10
Implement a backup strategy
49
Top Ten Things to Protect SQL Server
1
Install the most recent service pack
2
Run MBSA
3
Configure Windows authentication
4
Isolate the server and back it up
5
Check the sa password
6
Limit privileges of SQL services
7
Block ports at your firewall
8
Use NTFS
9
Remove setup files and sample databases
10
Audit connections
50
Security Guidelines for Users
1
Choose complex passwords
2
Protect passwords
3
Lock unattended computers
Do not log on using a privileged account
4
5
Run only trusted programs
Do not open suspicious attachments
6
7
Do not fall prey to social engineering
Review your organizations security policies
8
9
Do not attempt to override security settings
10
Report suspicious incidents
These security guidelines can be fully or
partially implemented through centralized
policies
51
Summary
52
Summary

• A systematic approach, such as Defence-in-Depth,
  helps to secure every angle
• Education and ongoing research are as important
  as technologies
• Follow the prescriptive security guidance from
  your suppliers