Active Security Common Practices Rafal Lukawiecki Strategic Consultant

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 Data Application Host Internal Network Perimeter Physical Security Policies, Procedures, & Awareness ACL, encryption Application hardening, antivirus OS hardening, update management, authentication Network segments, IPSec, NIDS Firewalls, VPN quarantine Guards, locks, tracking devices, HSM User education against social engineering

6 Common Threat Classification Network Host Threats against the network Spoofed packets, etc. Threats against the host Buffer overflows, illicit paths, etc. Threats against the application SQL injection, XSS, input tampering, etc. Application

7 Examples of Network Threats Threat Information gathering Examples Port scanning Using trace routing to detect network topologies Using broadcast requests to enumerate subnet hosts Eavesdropping Using packet sniffers to steal passwords Denial of service (Do. S) SYN floods ICMP echo request floods Malformed packets Spoofing Packets with spoofed source addresses

8 Examples of Host Threats Threat Arbitrary code execution Examples Buffer overflows in ISAPI DLLs (e. g. , MS 01 -033) Directory traversal attacks (MS 00 -078) File disclosure Malformed HTR requests (MS 01 -031) Virtualized UNC share vulnerability (MS 00 -019) Denial of service (Do. S) Malformed SMTP requests (MS 02 -012) Malformed Web. DAV requests (MS 01 -016) Malformed URLs (MS 01 -012) Brute-force file uploads Unauthorized access Resources with insufficiently restrictive ACLs Spoofing with stolen login credentials Exploitation of open ports and protocols Using Net. BIOS and SMB to enumerate hosts Connecting remotely to SQL Server

9 Examples of Application Threats Threat Examples SQL injection Including a DROP TABLE command in text typed into an input field Cross-site scripting Using malicious client-side script to steal cookies Hidden-field tampering Maliciously changing the value of a hidden field Eavesdropping Using a packet sniffer to steal passwords and cookies from traffic on unencrypted connections Session hijacking Using a stolen session ID cookie to access someone else's session state Identity spoofing Using a stolen forms authentication cookie to pose as another user Information disclosure Allowing client to see a stack trace when an unhandled exception occurs

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: 1. Identify the nature of the attack 2. Localize the source 3. Protect and save the evidence 4. Find other compromised machines 5. 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 3 rd party apps E. g. Install. Shield 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, selfdeveloper 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 SP 2 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 You’re 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 SP 2 Extends to 3 rd 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: Spy. Bot Search and Destroy (www. spybot. info) Microsoft Anti. Spyware (in beta) Ad. Aware

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 SP 2 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. High DMZ – De-militarized Zone Between network edge and all protected resources Default Only minimal protection possible DMZ 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) Isolation

35 Goals of Network Security Perimeter Defense ISA Server WF/ICF 802. 1 x / WPA IPSec Client Defense Intrusion Detection Network Access Control Confidentiality Secure Remote Access

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. 1 x or full use of WPA Physical radio coverage modelling Wired Equivalent of 802. 1 x 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 v 5 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 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* 4 Do not log on using a privileged account* 5 Run only trusted programs* 6 Do not open suspicious attachments* 7 Do not fall prey to social engineering 8 Review your organization’s security policies 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