- What's New
- Microsoft's New Security Philosophy
- Security Tools
- Encrypting Data
- Common Security Holes
- Developing a Security Strategy
This chapter is from the book
This chapter is from the book
This chapter is from the book
Developing a Security Strategy
As we've mentioned a couple of times already, security is not something you worry about once and never again. It's a constant process, and to make that process as efficient as possible, you need to have a battle plan. We find that the ongoing work of security falls more or less into two areas: auditing and maintenance. That's not to say no other security-related tasks exist; on the contrary, most of what we cover in this book is security configuration. But configuration is more of a one-time thing: You configure some security settings and you're done. Auditing and maintenance, however, are two security-related tasks that are never finished.
Auditing
Auditing is the process of reviewing something—in this case, security-related somethings—to ensure they comply with some standard. Windows Server 2003 provides several types of auditing:
You can configure auditing on file and folder access—This enables you to review who is accessing files. This auditing takes place in the security event log, and you have to decide which files and folders to audit.
You can audit domain events such as user logons—As with file access, you have to decide which events to audit, and the events themselves are listed in the security event log.
You can audit IIS log files to look for errors, potential security problems, and much more—You have to configure IIS to create a log file, and you must manually review the log. It's just a text file (not a regular event log), although you can purchase third-party applications to help summarize log information and call your attention to possible problems.
You can audit the DNS log—This is included in the Event Viewer snap-in. This log can alert you to potential security problems as well as operational errors.
Of course, there are many more. You should also make it a regular habit to audit things other than logs. For example, you might occasionally look at the membership of your company's Enterprise Admins, Domain Admins, and Schema Admins user groups. The members of these groups have powerful built-in permissions, and an occasional check to ensure the groups contain only authorized users is a good practice. Your organization might set up other sensitive groups, and you should check them on a periodic basis, too.
Auditing can be a daunting task, with so many things to look at. Consider creating a checklist that helps you remember which things to look at.
TIP
Remember, only you can prevent forest fires and only you can prevent security breaches. Microsoft has given Windows Server 2003 the capability to be as secure as you need it to be; it's your job to implement those capabilities and to ensure they continue to meet your organization's ongoing needs.
Security Maintenance
Unfortunately, securing your servers isn't a one-time task. Hackers are constantly finding new ways to compromise common security measures, and you'll always need to implement new measures to maintain your environment's security levels. Also, despite Microsoft's Trustworthy Computing initiative, rest assured that Windows Server 2003 does contain bugs, and some of those bugs will affect the product's security. As those bugs are discovered and squashed, you'll need to apply the appropriate fixes to your servers. Bear in mind that Microsoft offers a few types of fixes:
Service packs—These roll up several months' worth of fixes, along with new features, into a single, cumulative package. Each service pack contains all prior fixes, so that installing service pack 2, for example, also installs the fixes contained in service pack 1. Service packs go through an extensive beta-test cycle and are fully regression-tested, so they shouldn't introduce new bugs. In practice, of course, Microsoft rarely releases a perfect service pack; we recommend waiting a few weeks after the release of a new service pack to ensure it's relatively well-behaved.
NOTE
One of the reasons service packs can be buggy is that Microsoft uses them to deploy new features. Every so often, Microsoft resolves to stop doing that and to include only bug fixes. To my knowledge, that has never actually happened and service packs continue to introduce new features and changes to existing features along with a host of bug fixes.
Hotfixes—Also called quick-fix engineering updates (QFEs). These generally correct very specific bugs in the operating system and don't receive the benefit of a full beta-test cycle. Microsoft recommends that you install a hotfix only when you're experiencing the specific problem the hotfix addresses. We concur with this recommendation; don't treat hotfixes as something you casually deploy because they can sometimes break things. If you're not experiencing the specific problem the hotfix solves, wait until the next service pack. Every service pack rolls up the preceding hotfixes and tests them in a full beta-test cycle.
Security updates—These are basically hotfixes that address security issues. One supposes that Microsoft puts a bit more effort into testing these than a typical hotfix, but because security updates are nearly always released too quickly to fix a problem, don't assume a full beta-test cycle has been completed. Nonetheless, given that they fix security holes, you should regularly apply the latest security updates and just take the risk that they might break something, too. SUS can help automate security update deployment to Windows 2000, Windows XP, and Windows Server 2003 computers.
In short, your security maintenance plan must include constant vigilance, constant updates, and constant education about new threats. You can start by signing up for Microsoft's Security Bulletin, a free periodic email newsletter, at http://www.Microsoft.com/security.
For more information on using Software Update Services, see Chapter 14, "Maintenance," p. 231.
For an overview of the Framework, see Chapter 9, "Web Development," p. 145.
For more information on software restrictions, see Chapter 13, "Management," p. 215.
For details on how IIS has been made more secure, see Chapter 7, "Internet Information Services," p. 101.
To learn about Active Directory changes, including Active Directory's role in security, see Chapter 5, "Active Directory," p. 65.
To see what's new and changed in Group Policy, see Chapter 6, "Group Policy Changes," p. 81.