Applied Security Strategies

Applied Security Strategies
Michael Anderberg Senior Systems Engineer, Windows Platform Microsoft AB

Session Prerequisites
Understanding of enterprise security challenges Knowledge of securing computers by using Group Policy Understanding of remote access basics Knowledge of how to apply security patches Level 300

Agenda Introduction Real-World Patch Management Strategies
Real-World Remote Access Strategies Troubleshooting Security Configurations Student Notes: In this session, you will build on your existing knowledge of server, client, and network security and learn practical strategies for implementing the best practices for security across your environment. Securing your computing environment requires a defense-in-depth strategy, which means that security is applied in layers and all components in your environment must be secured. This session will focus on just three of the strategies that you need to include to create a more secure computing environment. You will learn real-world strategies for patch management and remote access security and how to troubleshoot problems with existing security configurations. This agenda topic is an introduction to applied security strategies. It will include: Defense in depth. Common security challenges.

Policies, Procedures, & Awareness
Defense in Depth Using a layered approach: Increases an attacker’s risk of detection Reduces an attacker’s chance of success Student Notes: A security strategy for an organization is most effective when data is protected by more than one layer of security. A defense-in-depth security strategy uses multiple layers of defense. If one layer is compromised, it does not necessarily follow that your entire organization will be compromised. A defense-in-depth strategy increases an attacker’s risk of detection and reduces an attacker’s chance of success. To minimize the possibility of a successful attack against your organization’s client computers, you need to implement the appropriate level of defense at each layer. There are many ways to protect each individual layer by using tools, technologies, policies, and best practices. For example: Policies, procedures, and awareness layer – Security education programs for users Physical security layer – Security guards, locks, and tracking devices Perimeter layer – Hardware and/or software firewalls, and virtual private networks with quarantine procedures Internet network layer – Network segmentation, IP Security (IPSec), and network intrusion detection systems Host layer – Server and client hardening practices, patch management tools, strong authentication methods, and host-based intrusion detection systems Application layer – Application hardening practices and antivirus software Data layer – Access Control Lists and encryption Additional Information: For more information about the defense-in-depth concept for modeling IT security, see the “Authoritative Security Guidance for the Enterprise” website at: Policies, Procedures, & Awareness Physical Security Data ACL, encryption Application Application hardening, antivirus OS hardening, update management, authentication, HIDS Host Internal Network Network segments, IPSec, NIDS Perimeter Firewalls, VPN quarantine Guards, locks, tracking devices User education

Common Security Challenges
Patch management: beyond the basics Remote access security Troubleshooting security policies Student Notes: Most IT organizations know that most attacks against computers take advantage of insecure configurations and known security problems in software. For enterprise systems, that level of security is not enough. Different methods are needed to help keep computers secure in a larger environment. Windows Update, for example, is an easy method to keep a single computer up-to-date, but it is appropriate only for home computers or very small businesses. Software Update Services (SUS) and Windows Automatic Updates are best for a larger environment. In this session, you will learn the strategies and tools to complement these tools. Many organizations provide remote access by setting up remote access servers and using a firewall. But doing that is only a first step. In this session, you will learn strategies for providing secure access for remote access clients that are not centrally managed. The Group Policy And Security Templates feature in Microsoft® Windows® allows you to centrally configure important security settings. Once you implement these solutions, you might get results that are not what you expected. For example, applications might stop working, or network access might be disrupted. In this session, you will learn how to troubleshoot security policies to get the results you need.

Real-World Remote Access Strategies Troubleshooting Security Configurations Student Notes: In this agenda topic, you will learn about real-world patch management strategies. It will include: Importance of proactive patch management Patch management process Monitoring patch status When to apply patches Microsoft tools for patch management Microsoft Baseline Security and Analyzer (MBSA) benefits MBSA—how it works Automating detection with MBSA MBSA command-line examples Demonstration: Using MBSA Automating patch distribution and monitoring with SUS SUS deployment scenarios Managing a complex SUS environment Software Update Service deployment best practices Using management software to distribute and apply patches SMS—what it does Demonstration: using SMS Third-party solutions Patching Microsoft Office Demonstration: Office Inventory Tool Best practices for successful patch management

Importance of Proactive Patch Management
Attack Name Date Publicly Discovered MSRC Severity MSRC Bulletin MSRC Bulletin Date Days Available Before Attack Trojan.Kaht 5-May-03 Critical MS03-007 17-Mar-03 49 SQL Slammer 24-Jan-03 MS02-039 24-July-02 184 Klez-E 17-Jan-02 N/A MS01-020 29-Mar-01 294 Nimda 18-Sep-01 MS01-078 17-Oct-00 336 Code Red 16-Jul-01 MS01-033 18-Jun-01 28 Student Notes: The time frame available between when an attack is reported and when a patch is available can vary. Because the time frame is not predictable, administrators must be proactive about patch management. In almost all cases, proactive patch management can protect against vulnerabilities before there is an exploit available for it. Note: Some bulletins were released before Microsoft Security Response Center severity ratings were implemented.

Patch Management Process
1. Assess Environment to be Patched Periodic Tasks A. Create/maintain baseline of systems B. Assess patch management architecture C. Review infrastructure/ configuration Ongoing Tasks A. Discover assets B. Inventory clients 2. Identify New Patches Tasks A. Identify new patches B. Determine patch relevance C. Verify patch authenticity and integrity Student Notes: The first step in the patch management process is to assess your environment and create a baseline of your IT environment that you will update periodically. The second step involves identification of patches that need to be deployed and the assets they will go to. This happens when a new patch is available or when systems in the environment are identified as missing appropriate patches. The third step is to evaluate the patch. Verify that it works effectively in your environment, plan the patch release process, get the required sign-offs to deploy the patch, and communicate as necessary the timing and impact of the patch deployment. The final step is to distribute and install the patch on the target systems, review the progress of the deployment, handle any deployment issues, and verify the installation on the target systems. As indicated earlier, this is an ongoing process that’s initiated at periodic intervals, when a new patch is released, or when new information indicates that necessary patches are missing. 1. Assess 2. Identify 3. Evaluate and Plan 4. Deploy the Patch Tasks A. Distribute and install patch B. Report on progress C. Handle exceptions D. Review deployment 4. Deploy 3. Evaluate and Plan Patch Deployment Tasks A. Obtain approval to deploy patch B. Perform risk assessment C. Plan patch release process D. Complete patch acceptance testing

Monitoring Patch Status
Subscribe to notification services Microsoft Security Notification Service Third-party mailing lists Check websites Product-specific pages Third-party sites Implement regular review and deployment schedule Microsoft’s patch release schedule: second Tuesday of each month Exception: customers are at immediate risk Configure automated tools to check for new updates daily Student Notes The most important step in remaining informed is to subscribe to notification services, such as: Microsoft Security Notification Service, which sends notification of new vulnerabilities and patches. Third party mailing lists, such as BugTraq and NTBugTraq. Monitor websites regularly too, such as the Microsoft TechNet Security website, which contains security bulletins and alerts. You can also find information at Web pages for specific products, such as the Office Update website. Implement a regular review and deployment schedule—Microsoft is issuing new security bulletins on the second calendar Tuesday of every month. Microsoft recently switched to this monthly release schedule in response to customer requests. Another benefit of the monthly cycle is that it offers you more time between releases of security patches to evaluate, test, and install patches in your computing environment in a timely manner. You can plan in advance for deploying patches. Note: An exception to this schedule occurs when Microsoft determines that customers are at immediate risk from viruses, worms, attacks, or other malicious activities. In such a situation, Microsoft will release security patches as soon as possible. When using automated tools, such as SUS, configure the tools to check for new updates daily. Additional Information: To subscribe to Microsoft Security Notification Service, see See the Security Bulletin Search at For information about the best practices for applying service packs, hot fixes, and security patches, see For more information about patch management, see “Microsoft Prescriptive Guidance” at

Recommended Patching Time Frame
When to Apply Patches Apply as soon as possible Apply only after testing Implement mitigating measures Apply according to severity rating Severity Rating Definition Recommended Patching Time Frame Critical Exploitation could allow the propagation of an Internet worm such as Code Red or Nimda without user action Within 24 hours Important Exploitation could result in compromise of the confidentiality, integrity, or availability of users’ data or in the integrity or availability of processing resources Within 1 month Moderate Exploitation is serious but has been mitigated to a significant degree by factors such as default configuration, auditing, need for user action, or difficulty of exploitation Wait for next service pack or patch rollup that includes the patch, or deploy the patch within 4 months Low Exploitation is extremely difficult, or impact is minimal Wait for next service pack or patch rollup that includes the patch, or deploy the patch within 1 year Student Notes: There is no single correct answer to the question of when to apply patches. A guideline is to apply the patches as soon as possible but only after you have tested them sufficiently. For most organizations, this means that you will balance the urgency of applying a hot fix with the requirements to ensure business continuity by testing patches sufficiently. Many security bulletins contain information about mitigating measures. For example, you may be able to counter some threats by blocking specific ports at your firewall. Review any such mitigating measures, and assess whether you can use them to secure your network until you apply the patches. When you apply patches depends on the severity rating. The higher the severity rating, the more urgent the patches are. The time frames in the table above are very aggressive. While you should aim for them, you might not be able to meet them if you have a large network. However, a severity rating of Critical dictates utmost urgency in implementing the recommendations of the security bulletin.

Microsoft Tools for Patch Management
Analysis Tools Microsoft Baseline Security Analyzer (MBSA) Office Inventory Tool Online Update Services Windows Update Office Update Content Repositories Windows Update Catalog Office Download Catalog Microsoft Download Center Management Tools Automatic Updates (AU) feature in Windows Software Update Services (SUS) Systems Management Server (SMS) Prescriptive Guidance Patch Management Using SUS Microsoft Guide to Security Patch Management Patch Management Using SMS Student Notes: This table categorizes the various tools and other components you can use for patch management: Analysis tools enable detection of missing security patches. Both MBSA and the Office Inventory Tool can be used to scan a single computer or to scan a range of computers in your network. Online update services allow automated detection and installation of missing patches. Windows Update and Office Update are appropriate tools for updating a single computer. Content repositories allow the ability to manually or selectively download the relevant updates. All of the content repositories allow administrators to download patches that they can then deploy in their organization. This deployment can be done manually to selected computers or by using automated update methods. Third-party tools can also download patches from these locations. Management tools enable patch management within the enterprise. These tools are used to automatically download and install patches. Prescriptive guidance provides process and best practice recommendations regarding patch management. Detailed information, sample scripts, and best practices are available for download. Additional information: For more information about patch management, see Microsoft’s Patch Management, Security Updates, and Downloads website at

MBSA  Benefits Automates identification of missing security patches and security configuration issues Allows administrator to centrally scan a large number of systems simultaneously Works with a broad range of Microsoft software (not just Windows and Office) Student Notes: MBSA allows administrators to assess systems against a common security baseline, to identify missing security patches and some security configuration issues. Administrators can use MBSA to scan a large number of systems simultaneously and create a Web-based report for further analysis. MBSA also works across a wide range of Microsoft software and systems. Security patches and updates: Microsoft Windows NT® 4.0, Windows 2000, Windows Server™ 2003, Windows XP Internet Information Services (IIS) 4.0, IIS 5.0, IIS 6.0 Microsoft SQL Server 7.0, SQL 2000 (includes Microsoft Data Engine) Internet Explorer (IE) 5.01 and later versions Microsoft Exchange Server 5.5, Exchange 2000 Windows Media® Player 6.4 and later versions System configurations: Windows NT 4.0, Windows 2000, Windows Server 2003, Windows XP IIS 4.0, IIS 5.0, IIS 6.0 SQL 7.0, SQL 2000 IE 5.01 and later versions Office 2000, Office XP

Microsoft Download Center
MBSA – How It Works MSSecure.xml contains Security bulletin names Product-specific updates Version and checksum info Registry keys changed KB article numbers Run MBSA on Admin system; specify targets Downloads CAB file with MSSecure.xml and verifies digital signature Microsoft Download Center Student Notes: The slide shows how MBSA works. The slide describes security patch scanning capabilities; it does not cover security configuration detection issues. Run the MBSA tool, and specify the target machines to scan. MBSA downloads the CAB file, containing MSSecure.xml, and verifies its digital signature. MBSA will attempt to contact the Microsoft Download Center to obtain this file; alternatively, the file can be copied to local machines. MSSecure.xml contains: Security bulletin names. Product-specific updates. Version and checksum information. Registry keys changed. Microsoft Knowledge Base article numbers. MBSA scans the target systems for operating systems, operating system components, and applications. MBSA parses the MSSecure.xml file to see whether updates are available. MBSA checks the system to see whether required updates are missing. MBSA generates a time-stamped report, listing any updates missing from your system. MSSecure.xml Scans target systems for OS, OS components, and applications Parses MSSecure to see if updates are available Checks if required updates are missing MBSA Computer Generates time-stamped report of missing updates

Automating Detection with MBSA
MBSA Scan (GUI) Performs well for small and medium-size networks MBSA Scan (mbsacli.exe) Performs automated scans using command-line parameters Example: mbsacli /d mydomain /f report.txt MBSA Scan in HFNetChk mode (mbsacli.exe /hf) Checks for missing patches only Example: mbssacli -hf -o tab –f report.txt MBSA and Windows Update might show different results Student Notes: While the GUI-based version of MBSA is useful for small and medium-size networks, it doesn’t meet the needs of many administrators. If you require reports that can be imported into databases or spreadsheets where you can sort the results and analyze requirements, consider using the command-line version of MBSA Scan. It allows you create a tab-delimited report of vulnerable computers that you can import into programs that you use to analyze vulnerabilities. Running MBSA in HfNetChk (Hotfix Network Checking) mode creates a detailed report about missing hot fixes on each computer. You can also save results from running MBSA in this mode in a tab-delimited format. MBSA and Windows Update (WU) might show different results because they analyze systems in different ways. WU, for instance, carries only critical updates for the Windows operating system, whereas MBSA (through HFNetChk) will report missing security updates for the Windows operating system and other Microsoft products such as SQL Server. There are also cases in which security updates are re-released. MBSA will always ensure that you have the latest version of the update installed on your system. If you have the original version of the MS or MS update, MBSA will indicate that the update is not installed because a newer release is available. However, Windows Update might not indicate that a newer version is available because it might be looking for different elements on the system to identify whether this update is present. Additional Information: For more information about automating detection with MBSA, see and

Automating Patch Distribution and Monitoring with SUS
Performs pull installations of service packs, security rollup packages, and critical updates Gives administrators control over software updates Prevents unauthorized installations when SUS is used with Automatic Updates Allows for staging and testing Works only for Windows 2000 and later Student Notes: SUS is a behind-the-firewall patch management product that you can use to automatically download new patches and updates. It will also perform the evaluation and planning steps of the process before approving patches and updates for deployment in your environment. SUS is based on a pull mechanism. The SUS server maintains the list of approved updates, and the SUS client, which is the Automated Updates feature in Windows, periodically checks the SUS server for newly approved updates. It then downloads and installs them on individual systems. In conjunction with the client component and Windows Group Policy capabilities, SUS can be used to enable administrator control over the application of patches in the environment. It does this by preventing users from going directly to Windows Update and installing non-approved updates on their systems. SUS also provide basic logging, bandwidth optimization, and administrative control options. Like Windows Update, SUS provides functionality in the areas of patch and update delivery, identification of missing patches, and deployment or installation of patches. In conjunction with Automatic Updates, it can give administrators complete control over the installation of patches on client computers. SUS 1.0 with Service Pack 1 allows staging and testing of updates before installation. SUS is more limited than Windows Update in two ways. It does not support Windows NT 4 or Windows 98, and it does not deliver non-critical updates and drivers. SUS supports only Windows 2000, Windows XP, and Windows Server 2003 clients. SUS 2.0 is scheduled for release by the end of Q This release will support additional Microsoft products, significantly improve bandwidth optimization through the use of the Background Intelligent Transfer Service (BITS), and support binary delta compression technologies to dramatically reduce the size of update downloads. SUS 2.0 will allow event and update deployment status rollup and aggregate reporting through standard reports. It will also have the ability to create custom reports using SQL queries.

Managing a Complex SUS Environment
Domain Member Server GPO Member Servers SUS Test RO1 GPO HO GPO RO2 GPO HO Workstations RO1 Workstations RO2 Workstations Centrally manage downloading and approving updates Student Notes: Managing a large SUS infrastructure that includes multiple SUS servers requires careful planning. Centrally manage downloading and approving updates. To ensure a consistent security patch management configuration throughout the organization, use one SUS server to download all security patches. If you want to roll out the same patches at the same time to all clients, you should also approve all patches on this server. You can also approve updates on individual child SUS servers to more precisely manage the deployment of the patches. Use the organizational unit (OU) structure and Group Policy Objects (GPOs) to configure client settings. To add the Automatic Update client configuration options to Group Policy, download the AU ADM template (wuau.adm) and add the template using the Group Policy Editor. Configure client settings to indicate which servers clients will use to download updates, configure update scheduling, and configure reboot behavior. Use the OU structure to distribute GPOs. In the example shown in the graphic, you assign one GPO to the Member Servers OU, which will manage the SUS updates for the member servers. The Head Office GPO (assigned to the HO Workstations OU) can use the same SUS server as the Member Servers GPO but a different schedule. Each remote office can have its own SUS server, so a separate GPO is used to configure the workstations in each office. The SUS Test OU is used to perform the initial test of the patch deployment. Use OU structure and GPOs to manage SUS update distribution Use the WUAU.ADM template file to configure AU client settings Assign GPOs to OUs

Using Management Software to Distribute and Apply Patches
System Management Server (SMS) 2003 Gives administrators control over patch management Automates the patch management process Updates a broad range of Microsoft products Updates third-party software Provides flexibility by using scripts Third-Party Solutions Integrates with third-party solutions through scripting Student Notes: In a larger, managed network environment, you can decrease the time and effort that are required to distribute and apply patches by using system management software. You can use either Microsoft System Management Server (SMS) or third-party system management software. SMS provides the following functionality, which is critical to successful deployment: Inventory functions to determine how many computers have been deployed, their locations, their roles, and the software applications and patches that have been installed. Scheduling functions that allow an organization to schedule deployment for patches and hot fixes outside regular working hours or at a time that has the least impact on business operations. Status reporting that allows administrators to monitor the progress of installation. Targeting functions that are based on system inventory, a computer’s position in the Microsoft Active Directory® directory service, or manually created computer groups. Enterprise replication to move files around the network easily and effectively. Support for Microsoft Windows Server 2003. Support for operating systems other than Microsoft Windows 2000, Windows Server 2003, and Windows XP. Patch updates can be integrated into third-party system management solutions, such as such as IBM Tivoli, CA Unicenter, BMC Patrol, and HP OpenView. You can create scripts for both the detection and applications of patches and use these scripts with third-party system management software. Additional Information: For more information about system management software, see

Third-Party Solutions
Company Name Product Name Company URL Altiris, Inc. Altiris Patch Management BigFix, Inc. BigFix Patch Manager Configuresoft, Inc. Security Update Manager Ecora, Inc. Ecora Patch Manager GFI Software, Ltd. GFI LANguard Network Security Scanner Gravity Storm Software, LLC Service Pack Manager 2000 LANDesk Software, Ltd LANDesk Patch Manager Novadigm, Inc. Radia Patch Manager PatchLink Corp. PatchLink Update Shavlik Technologies HFNetChk Pro St. Bernard Software UpdateExpert Student Notes: Microsoft’s top priority is the security and availability of your IT environment. Consequently, if you feel that none of the Microsoft offerings meets your needs, we strongly encourage you to evaluate a patch management solution from another vendor. Some of the solutions listed here provide advanced features that may be useful to your organization, such as targeting of updates, integration with third-party vulnerability assessment databases, and detailed reporting. This slide lists some of the companies that provide patch management products, the names of their products, and their company URLs. This is not an exhaustive list of vendors providing relevant products. It is only to provide a sampling of available products. Patch management capabilities are also included in Enterprise Systems Management products from IBM, Computer Associates, HP, and others. Microsoft does not endorse, recommend, or support any of these products but encourages customers to evaluate non-Microsoft options to determine whether they better meet your needs.

Patching Microsoft Office
Office Inventory Tool Office Update Office patches require the original files Office 2003 caches installation files Installation points patching Student Notes: The Office Inventory Tool is similar to MBSA in that it is a stand-alone tool that identifies missing updates. However, its scanning functionality is restricted to looking for missing office updates. It consists of two components. One detects missing updates on the system and generates a log file containing this information. The other merges this information with the metadata information for the missing updates. It then provides a report of the details for the missing updates that can be used by administrators or SMS to download and install the appropriate updates. Office Update is similar to Windows Update but is limited to scanning for and installing Microsoft Office updates, which include updates for Word, Outlook®, PowerPoint®, Microsoft Access, FrontPage®, Publisher, InfoPath™, OneNote™, Visio®, and Microsoft Project. Office Update is supplemented by the Office Download Catalog, which provides the ability to manually download individual updates for the various components of Office. Microsoft Office patches modify existing Microsoft Office files instead of replacing them. Because of this, the Office patch mechanism requires the original Office media. When applying Office updates, always ensure that the original Office files are available. The easiest way to accomplish this is to install Office from a network location. Office updates always look first in the original installation location for files that are required. Alternatively, you can specify a different network location when prompted. Ensure that the version of the files from which you originally installed is always available. Office 2003 caches some of the required installation files on the local hard disk. Unless you specify during the installation that you want to delete these files to save space, you can apply updates without needing the original media. As with Windows, you can patch the Office installation points. The Readme files that are included with Microsoft Office service packs include instructions about how to use command-line switches to modify installation points so that all new client installations use the updated files.

Best Practices for Successful Patch Management
Use a change control process Read all related documentation Apply updates only as needed Test updates thoroughly Ensure consistency across domain controllers Back up your system, and schedule production downtime Always have a rollback plan Forewarn help desk and key user groups Target non-critical servers first Student Notes: Follow these best practices for successful patch management: Use a good change control procedure that has an identified owner, a path for customer input, an audit trail for any changes, a clear announcement and review period, testing procedures, and a well-understood back-out plan. Before applying any service pack, hot fix, or security patch, read all relevant documentation and have it peer-reviewed. The peer review process is critical because it mitigates the risk of a single person missing critical and relevant points when evaluating the update. Apply only those updates that your environment needs. One of the common misconceptions about Microsoft updates is that they are mandatory, urgent, or both. Regardless of their type (whether they are service packs, hot fixes, or security patches), evaluate them individually and treat them as important optional updates. Service packs and hot fixes must be tested on a representative non-production environment prior to being deployed to production. This will help to gauge the impact of such changes. Service packs, hot fixes, and security patch levels must be consistent on all domain controllers (DCs). Inconsistent update levels across DCs can lead to problems related to synchronization and replication. It is extremely difficult to discover errors caused by DCs being out of sync, so it is critical that consistency be maintained. Where practical, member servers should be updated with the same service packs and hot fixes as the DCs. Server outages should be scheduled, and a complete set of backup tapes and emergency repair disks should be available in case a restoration is required. Make sure that you have a working backup of your system. The only supported method of restoring your server to a previous working installation is from a backup. A rollback plan will allow the system and enterprise to revert to the state they were in prior to the failed implementation. It is important that these procedures be clear and that contingency management has tested them. Then, in the worst case of a faulty implementation, you can activate contingency options. Enterprises might need to exercise their back-out plan in the event of the update not having an uninstall process or the uninstall process failing. The back-out plan can be as simple as restoring from tape, or it might involve many lengthy manual procedures. Forewarn help desk and key user groups of the pending changes so that they are ready for arising issues or outages. If all tests in the lab environment are successful, start deploying to non-critical servers first if possible. Once the service pack has been in production for 10 to 14 days, move to the primary servers. Additional Information: For more best practices, including practices that apply specifically to service packs and hot fixes, see “Best Practices for Applying Service Packs, Hotfixes and Security Patches” at

Real-World Remote Access Strategies Troubleshooting Security Configurations Student Notes: In this agenda item, you will learn about real-world remote access strategies. It will include: VPNs and firewalls. VPN server behind a firewall. Using ISA Server as a VPN server and a firewall. Challenges of using IPSec and NAT. Solution model. How NAT-T works. Interoperability issues. NAT-T status for Windows. Enforcing remote access client security. What is Network Access Quarantine Control? Quarantine requirements. The quarantine process. Network Access Quarantine Control limitations. Network Access Quarantine Control tips and tricks. Demonstration: Configuring network quarantine.

RAS Server & Firewall on Same Computer
VPNs and Firewalls Combining a firewall with a VPN server Student Notes: Combining firewalls and remote access can present a challenge to network administrators. There are two options for combining a firewall with a VPN server: 1.The remote access server is located behind the firewall. The advantage of this solution is that the VPN server is protected by the firewall. The disadvantage of this solution is that you must open the ports on your firewall that allow VPN traffic to pass through to the VPN server. 2.The firewall and the remote access server are the same computer. This is how ISA Server 2000 provides VPN access to clients. In this case, VPN terminates at the firewall. The advantages of combining a firewall with a VPN server are as follows: Easier initial administration. Combining RRAS and ISA Server makes the initial setup of RRAS easier. However, any post-configuration administration of RRAS requires you to use the RRAS interface. Single point of inspection. Having a single point where all incoming and outgoing traffic is inspected can increase security because you are less likely to make mistakes or overlook intrusion attempts. Note that ISA Server 2000 does not perform any layer 7 inspection inside VPN connections. Also, using a single device is often more cost effective. The disadvantages of combining a firewall with a VPN Server are: Combining both functions on a single device removes one layer from your defense in depth. It is possible that an attacker can defeat only one security mechanism and gain access to your network. However, you can mitigate this risk by making your border router part of your security strategy. RAS Server Behind Firewall VPN Clients RAS Server & Firewall on Same Computer VPN Clients RAS Server

VPN Server Behind a Firewall
Challenge: Allow the firewall to pass traffic to the VPN server Challenge: Stateful inspection Student Notes: This table lists the ports and protocols that VPN traffic can use across your firewall. If you place your VPN server behind a firewall, you may have to open these ports. The protocols listed are required for PPTP and L2TP over IPsec. If your VPN solution uses different ports, you have to open those ports on the firewall. It can be a challenge is to ensure that the firewall performs stateful inspection. For example, a firewall should allow packets that use the GRE protocol to reach a VPN server only when the client has contacted the server over TCP port 1723 and the initial connection has been successfully established. To do this, a firewall must be able to inspect the connection at the application layer. Simply opening the firewall ports for IP protocol 47 might allow incoming traffic that uses this protocol even when no connection over TCP port 1723 has been established first. Traffic Ports and Protocols PPTP Session Establishment TCP Port 1723 PPTP Session IP Protocol 47 (GRE) IPSec IKE UDP Port 500 IPSec ESP IP Protocol 50 (IPSec ESP)

Using ISA Server as a VPN Server and a Firewall
ISA Server Feature Description Integrated solution Provides application-layer firewall and proxy server Uses RRAS to provide VPN services Provides strong authentication options Includes choice of PPTP or L2TP/IPSec protocols Packet filtering Protects the VPN server Wizards Allow for easy configuration to help avoid mistakes Student Notes: Microsoft Internet Security and Acceleration (ISA) Server 2000 is an integrated solution for your VPN and firewall needs. ISA Server is an extensible enterprise firewall and Web cache server that integrates with the Microsoft Windows 2000 operating system for policy-based security as well as accelerating and managing internetworking. The firewall provides filtering at the packet, circuit, and application layer; stateful inspection to examine data crossing the firewall; and control of access policy and routing of traffic. The cache improves network performance and enhances the end user experience by storing frequently requested Web content. The firewall and cache can be deployed separately on dedicated servers or integrated on the same computer. ISA Server uses RRAS to provide VPN services and at the same time provides firewall protection for the server. ISA Server’s packet filtering protects the VPN server. All incoming network traffic that is not VPN traffic is dropped, and ISA Server logs the traffic. ISA Server can configured to use RRAS for client-to-network VPN connections, for network-to-network VPN connections, or for both. The Local VPN Wizard runs on ISA Server on the local network. The local ISA Server VPN computer connects to its Internet service provider (ISP). The Remote VPN Wizard runs on the ISA Server on the remote network. The remote ISA Server VPN computer connects to its ISP. When a computer on the local network communicates with a computer on the remote network, data is encapsulated and sent through the VPN tunnel. The Client VPN Wizard sets up a clients-to-server VPN. A tunneling protocol (PPTP or L2TP) is used to manage tunnels and encapsulate private data. Data that is tunneled must also be encrypted to be a VPN connection. ISA Server’s wizards allow for easy configuration to help avoid mistakes that create security risks. This is especially important when configuring a VPN server at a remote office where there may be limited expertise for configuring a VPN server. ISA Server’s wizards allow an administrator at a central location to configure all settings and provide them to an administrator at a remote location in a single encrypted file. Using ISA Server’s wizards can eliminate many common configuration mistakes that may compromise security. The wizards to configure RRAS include: Client remote access. Site-to-site, main office side. Site-to-site, branch office side. Additional Information: For more information about ISA Server, see

Challenges of Using IPSec and NAT
Packet header is modified, invalidating packets IKE uses IP fragments NAT devices that assume tunnel mode Student Notes: Many organizations would prefer to use L2TP/IPSec (L2TP over IPSec) rather than use PPTP. They are not able to because there are devices that perform network address translation (NAT) between the VPN server and the VPN client. There are 3 problems with using IPSec over NAT: NAT changes the packet’s header by modifying IP address and port information. This slide shows that the client encapsulates an IP packet inside an IPSec packet. The new packet contains an encrypted hash of the original packet header. In this example, a NAT device connects the client computer to the Internet and changes the packet header. A second NAT device that connects the server to the Internet changes the packet header again. When the VPN server receives the packet, a hash of the packet header no longer matches the encrypted hash in the payload. Because they don’t match, IPSec at the receiving end discards the packet. The Internet Key Exchange (IKE) protocol, which is a component of IPSec, uses packet fragments. Because many firewalls discard IP fragments, IPSec communications might not be possible across such firewalls. Many NAT devices that are designed for IPSec tunnel mode incorrectly process IPSec packets in transport mode. This means that you can have only a single IPSec session through most of these devices. In this case, all incoming IPSec packets are routed to a single computer behind the NAT device. NAT1 Hdr NAT2 Hdr NAT Orig IP Hdr TCP Hdr Data AH Hdr Insert Contains an encrypted hash of the original packet header

Solution Model IETF draft on NAT Traversal (NAT-T) recommends that devices on both ends should: Detect the presence of NAT Use a non-IPSec port so that NAT devices do not interfere with network traffic Encapsulate IPSec in UDP In addition, the Microsoft solution prevents IP fragments Student Notes: When there are common Internet problems that can be solved by making products standard, the Internet Engineering Task Force will draft a standard for product vendors to follow. Because the problems in using IPSec over NAT are widely recognized, there is now an Internet Engineering Task Force (IETF) draft on NAT Traversal (NAT-T) that is awaiting number assignment as a Request for Comment (RFC). When this is standard, there should be increased interoperability between devices from different manufacturers. The general process suggested for the NAT-T traversal standard is that devices on both ends: Detect that they are communicating through one or more devices that use NAT. Use a non-IPSec port to communicate. This is so that NAT devices do not interfere with the network traffic. Encapsulate IPSec traffic in User Datagram Protocol (UDP) packets that use the non-IPSec port. In addition to those standards, the Microsoft solution prevents fragmentation of IP packets. With the Microsoft solution, packets can pass through firewalls that block fragmented packets. This is important because the encapsulation process creates large packets that might be too long for some networks and thus might be fragmented along the way. Fragmentation avoidance is not standards-based, but this does not cause interoperability problems because it is used only between a Windows-based VPN client and a Windows-based VPN server.

How NAT-T Works Orig IP Hdr TCP Hdr Data ESP Hdr Insert Rest…
UDP src 4500, dst 4500 Sent by A Rcvd by B UDP src XXX, dst 4500 NAT1 Hdr NAT2 Hdr Student Notes: NAT-T works as follows: The VPN client attempts to establish connection to the IPSec server. During IPSec main mode setup, the connection fails, but the server and the client detect that an IP header has been changed by a NAT device. The server and the client take this as an indication that there are one or more NAT devices between them. The client reestablishes a connection but this time establishes a connection by using UDP port 4500. The client encapsulates IPSec packets in the NAT-T packets. At this point, an IP packet is encapsulated in an IPSec packet, which itself is encapsulated in a NAT-T packet. The NAT-T packets are standard UDP packets which is why they pass through all NAT devices. When the packets arrive at the server, NAT devices have changed the headers of the packets. The server discards the header and retrieves the IPSec packet. Because the header of the IPSec packet has not been changed, the packet is treated as valid. IPSec decrypts the packet and extracts the original IP packet.

Interoperability Issues
VPN client and VPN server must support NAT-T Issues with third-party devices Better interoperability as time goes on NAT devices do not need any changes Firewall support Allow UDP 4500 traffic Allow UDP 500 traffic Student Notes: To ensure proper NAT-T operations, both VPN clients and VPN servers must support NAT-T. While many of Microsoft’s operating systems support NAT-T today, not all manufacturers of VPN devices support NAT-T yet. If you are using a third-party VPN server or client, contact the manufacturer for more information. Interoperability is expected to improve as more manufacturers adopt the new standard. NAT devices themselves don’t need any change. NAT-T uses communications between servers and clients. It does not impact devices that are located between them. You might have to configure your firewall to support NAT-T traffic. NAT-T uses UDP port 4500 for the source and the destination ports. To support NAT-T, you have to allow this traffic. In addition, you must open UDP port 500 to support IKE. IKE setups are always made outside NAT-T.

NAT-T Status for Windows
Implemented to IETF Proposed Standard Interoperability tested with third-party gateways for L2TP/IPSec Intended for L2TP/IPSec in WindowsXP and earlier Intended for all IPSec uses in Windows Server 2003 Student Notes: The slide shows the current status of NAT-T for different Windows operating systems: The Windows implementation is fully compliant with the IETF proposed standard and has been tested for interoperability with third-party VPN servers that support NAT-T for L2TP/IPSec. For Windows XP and earlier operating systems, NAT-T provides support for L2TP/IPSec. For Windows Server 2003, all IPSec uses are supported. When planning use of NAT-T with Windows, be aware of the following: Windows versions earlier than Windows Server 2003 require an update to the operating system. The method that you use to add this support depends on the version of Windows that you are using. Active FTP across IPSec transport mode does not work. Active FTP does work over L2TP/IPSec. In some cases, NAT-T in Windows XP can’t negotiate the Path Maximum Transfer Unit (PTMU) when using general IPSec transport mode. This may lead to packet fragmentation between the client and the server, which may cause problems with some intermediate firewalls. Additional Information: For more information about the IETF proposed standards for NAT Traversal, see For more information about Windows98/ME/NT 4 NAT-T Web download, see For more information about NAT-T, see and OS Version L2TP/IPSec Support General IPSec Transport Mode Support Windows Server 2003 Yes Yes4 Windows XP Yes1 Not recommended5 Windows 2000 Yes2 No Windows NT 4 Yes3 Windows 98/Me Note 1: Windows Update or hot fix Note 2: With hot fix Note 3: With Web download Note 4: Active FTP does not work Note 5: Some PTMU reductions do not work

Enforcing Remote Access Client Security
Problem: Remote clients might not meet corporate security requirements Insecure computers on the corporate network endanger the entire network Solutions: Disallow remote access Trust users to keep remote clients secure Create a separate network for VPN clients Enforce security settings upon connecting Disconnect clients that are not secure: Network Access Quarantine Control Student Notes: In the preceding section, you saw how to enable remote access to networks in a way that encrypts network traffic as it traverses the Internet. Once VPN clients have established this connection, they have full access to your organization’s network. You can use packet filters and other rules to restrict which computers on your network these clients can access. Be aware that restricting this access may hinder productivity. When client computers that don’t meet your organization’s security standards connect to your corporate network, they constitute a security risk. These client computers may be infected by viruses or be vulnerable to attacks from the Internet, which puts your network at risk. Several solutions to this problem and their drawbacks follow: Disallow remote access. This may hinder productivity of your employees and is often not a viable solution. Trust users to keep remote clients secure. This is not recommended because most users don’t have the required skills. Create a separate network for VPN clients, and place a firewall between this network and the rest of your corporate network. You can then use the firewall to allow only selected traffic between these networks. However, doing this may hinder productivity, and it does not eliminate all dangers. Enforce all security settings when clients connect to your network. This can be done by using a script that runs whenever a client connects to the network. Creating the required scripts and procedures may be time consuming, and it may involve configuring computers that don’t belong to your organization, such as employees’ home computers. Check the security settings of VPN client computers, and disconnect client computers that are not secure. In many cases, that is the best solution when combined with a method that users can use to update their computers to the organization’s requirements. This method is used by Network Access Quarantine Control, which is a new feature in Windows Server 2003. Additional information: For more information about enforcing remote access client security, see:

The Quarantine Process
Internet Quarantine RAS Client RRAS Server IAS Server Connect Authenticate Policy Check Result Quarantine Access Full Access Authorize Quarantine and Other Filters Remove Quarantine Student Notes: The following process describes how Network Access Quarantine Control works when a RADIUS server and the Rqc.exe and Rqs.exe programs are used: The user on the quarantine-compatible remote access client uses the installed quarantine Connection Manager profile to connect with the quarantine-compatible remote access server. The remote access client passes its authentication credentials to the remote access server. The Routing And Remote Access service sends a RADIUS Access-Request message to the IAS server. The IAS server validates the authentication credentials of the remote access client and, assuming that the credentials are valid, checks its remote access policies. The connection attempt matches the quarantine policy. Up to this point, there is no difference from a traditional VPN connection that uses a RADIUS server. The connection is accepted with quarantine restrictions. The IAS server sends a RADIUS Access-Accept message that contains the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout attributes, among others. This example assumes that both attributes are configured in the matching remote access policy. These attributes specify the IP addresses of computers that quarantined client computers are allowed to access, and for how long the quarantine period lasts. The remote access client and remote access server complete the remote access connection, which includes obtaining an IP address and other configuration settings. The Routing And Remote Access service configures the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout settings on the connection. At this point, the remote access client can successfully send only traffic that matches the quarantine filters and has up to the number of seconds specified in MS-Quarantine-Session-Timeout to notify the remote access server that the script has run successfully. While the client is still in quarantine mode, the Connection Manager profile runs the quarantine script as the postconnect action. The quarantine script verifies that the remote access client computer's configuration complies with network policy requirements. If all the tests for network policy compliance pass, the script runs Rqc.exe with its command-line parameters, one of which is a text string for the version of the quarantine script included within the Connection Manager profile. Rqc.exe sends a notification to the remote access server, indicating that the script was successfully run. The notification is received by the listener component (Rqs.exe). If the script was successfully run, and if the script version matches the version that is configured in the remote access server’s Registry, the listener component calls the MprAdminConnectionRemoveQuarantine() API, which causes the Routing And Remote Access service to remove the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout settings from the connection and configure the normal connection constraints. At this point, the remote access client has normal access to the intranet.

Real-World Remote Access Strategies Troubleshooting Security Configurations Student Notes: This section deals with troubleshooting several different security related situations. These include: Resolving security template conflicts. Troubleshooting application failures. Troubleshooting services and processes. Troubleshooting network connectivity issues. Best practices for troubleshooting.

Resolving Security Template Conflicts
Use Resultant Set of Policies (RSoP) tools Active Directory management tools Group Policy Results from the GPMC GPResult Student Notes: In a managed environment, many security settings are applied by using Group Policy. Sometimes this results in security template conflicts. You can use the Resultant Set of Policies (RSoP) tool to troubleshoot the application of Group Policy. RSoP gives administrators the ability to plan, monitor, and troubleshoot Group Policy. With RSoP, administrators can plan how Group Policy changes will affect a targeted user or computer. Or administrators can remotely verify the policies currently in effect on a specific computer. In a troubleshooting situation, RSoP provides detailed information about all security settings that apply to the computer or user and specifies which GPO applies the setting. RSoP can be accessed in a number of different ways: From a Windows XP or Windows Server 2003 computer, you can create a Microsoft Management Console and add the RSoP snap-in. From Active Directory Users And Computers on a Windows Server 2003 or Windows XP computer (with the Administrative Tools Pack installed), you can run RSoP from the All Tasks menu item when right-clicking a user, computer, organizational unit, or domain object. From Active Directory Sites And Services on a Windows Server 2003 or Windows XP computer (with the Administrative Tools Pack installed), you can run RSoP from the All Tasks menu item when right-clicking a site object. From the Group Policy Management Console tool. Use GPResult GPResult is a command-line client–based version of RSOP. When you run GPResult on a workstation, all of the GPOs that apply to the user and the workstation are displayed in a command window.

Troubleshooting Application Failures
Applying security patches or security templates might prevent applications from working Tools for troubleshooting application failures Network Monitor File Monitor Registry Monitor Dependency Walker Cipher Student Notes: Occasionally, the application of a security patch or a security template might prevent an application from working properly. Use the following tools to troubleshoot “broken” applications: Netmon (Network Monitor) will help you determine any network-level issues with applications that either directly make use of the network or make use of network resources (for example, file shares, Web services, RPC, LDAP, Kerberos). The best use of this tool is to take one working system and a nonworking system, log the network traffic while running the application, and compare the NetMon capture logs line by line to look for any error messages in packet details or to look for looping or missing packets. FileMon (File Monitor from Sysinternals.com) will help you determine which files the application can no longer access. Often the best use of this tool is to compare the logs from a working and a nonworking system to see which file is no longer accessible. RegMon (Registry Monitor from Sysinternals.com) will help you determine registry keys and settings that the application can no longer access. Again, side-by-side comparisons of logs from a working and a nonworking system are often very efficient. Depends.exe (Dependency Walker tool from Debugging Tools, Windows Resource Kit, or Support Tools) can map the DLL dependencies and provide a report when an application can no longer find a DLL that it requires (because of a version mismatch or a permissions issue, for example). This can be useful when an older application requires a certain version of a DLL that has been replaced. Cipher.exe can be used to detect and modify the encryption settings. This is useful when an application (for example, a service or an application that depends on a service on the same system) can no longer access a file that is required and EFS has been enabled on one or more folders on the system. Sometimes the files may have been accidentally encrypted in a context that the application/service cannot access. This happens most often when a folder used for temporary files is encrypted and then, during an application’s installation, files are copied from a temporary location to the intended location.

Troubleshooting Services and Processes
You may need to troubleshoot services: When services and processes fail to start To confirm that all services and processes are legitimate Tools to troubleshoot processes: Tlist.exe or Process Explorer Dependency Walker Examine DLL properties Student Notes: There are two different situations in which you might need to troubleshoot services and processes. Occasionally, a service might fail to start because of a security patch. Or you might need to verify that all of the processes that are running on a server or workstation are legitimate and that none of the processes are malicious code. Use the following tools to troubleshoot services and process issues: tlist.exe (from the Debugging Tools or Windows Resource Kit) or Process Explorer (from Sysinternals.com). Either of these applications can report the path from which processes are launched as well as any command-line parameters that may have been used to run the process. These tools also allow you to find the EXE file used by the service or process. To deal with DLL issues, first track all of the DLLs in %systemroot%\system32 to the application that installed them. Use Process Explorer to detect user-mode applications that have certain loaded DLLs listed. Use Depends.exe (Windows XP Support Tools, Windows 2000 Resource Kit), to map the potential DLLs that the EXE could load. For those DLLs you still haven’t identified, load their properties one at a time and examine the Version tab’s information, including “company”, “internal name”, “product name”, to find out who it reports the DLL was published by (although that information sometimes is not truthfully reported).

Troubleshooting Network Connectivity Issues
Ensure that only required ports are open on the computers Tools for determining port usage: Netstat –o (on Windows XP or Windows Server 2003) Task Manager Test port usage for applications and services Student Notes: One of the tasks you may face when securing workstations and servers is to determine which network ports are used by the computers. You may need to troubleshoot network connectivity when a port is blocked on a firewall, or you may need to validate that a certain port is required. There are many tools for identifying the process responsible for listening on certain TCP or UDP ports: For Windows XP and Windows Server 2003, you can simply run netstat.exe with the -o parameter to determine the PID (Process ID) that has caused that port to be in the LISTENING state. Then launch Task Manager to find out which process is using that PID. For Windows 2000 and earlier (or instead of netstat.exe), you can use a third-party tool such as fport.exe (from foundstone.com) or openports.exe (from diamondcs.com.au). These tools also tend to skip a couple of steps to make it easier for you. Next, to determine whether the ports are opened by applications you’ve run rather than services already running on your computer, close all user applications (including system tray icons and Task Bar applications) and rerun your port mapping tool of choice. The processes no longer in the LISTENING state are the ones responsible for the ports no longer listed in your scan. To determine which of the services running on that system can be shut down to disable the remaining ports in question, shut down services one at a time. Then compare the output from your scanning tool before and after stopping the service in question. Note that some services cannot be stopped by the administrator, so whichever ports are left after you shut down ALL services that you can should be considered mandatory ports. Also, some services might share a port. In that case, shutting down both services might be necessary to stop the computer from listening on some ports. Once you have mapped out exactly which services require which ports, you can determine whether the service is required on the computer. If the service is not required, disable it to prevent it from starting again. If the service is required, document which port is required for the service.

Best Practices for Troubleshooting
Use a formal change and configuration management strategy for all security changes Test all security configuration changes Use RSOP tools in planning mode Document the normal settings Have a rollback strategy Troubleshoot securely Student Notes: Whenever you are troubleshooting security configurations, apply the following best practices: Use a formal change and configuration management strategy. Doing this allows you to find the source of problems more easily and simplifies a rollback strategy. Whenever you make changes to a security configuration setting, test the changes before and immediately after deployment. Ensure that your configuration change was applied correctly and that you did not introduce any other security vulnerabilities. Use RSOP in planning mode—the RSOP tools can be run in planning mode to determine what the effect of applying a security template would be. To troubleshoot obscure problems, you need to understand what a normal configuration is before a security template or patch is applied. Always ensure that you have a rollback strategy. Always troubleshoot securely. This means that you don’t jeopardize your organization’s security as part of your troubleshooting operations. For example, if a security configuration change is not successful, don’t lower other security settings as part of your troubleshooting. Doing so might place the computer that you are troubleshooting at risk.

Session Summary Real-World Patch Management Strategies
Real-World Remote Access Strategies Troubleshooting Security Configurations Student Notes:

For More Information Microsoft Security Site (all audiences)
TechNet Security Site (IT professionals) MSDN Security Site (developers) More technical information for IT professional and developers is available on the following websites: Microsoft Security Site (all audiences) TechNet Security Site (IT professionals) MSDN® Security Site (developers)

Applied Security Strategies

Similar presentations

Presentation on theme: "Applied Security Strategies"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Applied Security Strategies

Similar presentations

Presentation on theme: "Applied Security Strategies"— Presentation transcript:

Similar presentations

About project

Feedback