- Designing Security for a Microsoft Windows 2000 Directory
- Analyzing Existing Systems and Applications
- Just added
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Analyzing Existing Systems and Applications
A good security design implements an effective security policy. The first step is to determine how effectively the current information systems accomplishes this. There are two goals here: understanding the policy and the rationale behind it, and understanding the current systems and applications.
So just what is "security policy?" Let's first discuss what it is not. Security policy is not a listing of Windows registry hacks, or the application of privileges, resource permissions, or membership in groups. It is most definitely not the blanket application of the latest Microsoft security bulletin "hot fix" or third-party program. Security policy is written direction from management on a wide range of security goals. Operating systems specific configuration, patching, and the use of security products and protocols can fulfill, or implement, these management directives. For example, security policy for the Lawrence Livermore Labs may state that secure areas exist from which no copy of information should be removed. The implementation of this policy may include the exclusion of Palm Pilot systems with wireless capabilities because they might be used to transmit data from computer systems within the secure area by broadcast from one Palm unit inside the area to another outside. While this is a good security implementation for Lawrence Livermore Labs, your organization may choose to have a less strict policy, and the banning of wireless Palm units may never be a part of its implementation. Let's use a Windows 2000-related scenario while considering the following security policy:
How would you implement this policy on Windows 2000 systems? On Windows NT systems? What is the most efficient way to do so?
Your assessment of the impact of this security policy and its place in your security design would be:
To determine which systems in the current environment already follow this policy and how it has been implemented.
To determine which systems do not follow this policy.
To attempt to determine the manner in which new systems and existing systems will follow this policy, and the impact of doing so. (Will it be difficult to implement? Will it require extraordinary efforts to implement it? Will the cost of implementation outweigh the benefits of implementation? What would the cost be if it were not implemented?)
Remember, your job as security architect is not to make the policy, but to design the implementation of the policy, to advise management on the relative ways in which this can be done, and to show the benefits and costs of the options. Ultimately, management will decide if a policy needs to be changed, or a new one added. This does not mean that you ignore your knowledge of specific threats to implemented systems. Management is looking to you to provide the information necessary for the development of new policies. Policies, however, by their nature are usually vaguely defined.
To assist management, your knowledge of the current systems and applications and the environment they exist in will help you in determining where security is good, where it can be improved, and where it is non-existent.
Applications: Are legacy applications being used on Windows NT that require extreme relaxation of file and registry security? Are versions of current applications available that meet strict Windows 2000 application requirements?
Systems: How many of the current workstations run Windows 9x? Windows NT? MS-DOS? Macintosh? Unix? How many of these systems are scheduled for upgrade or replacement immediately? Within six months? A year? What are the roles of servers? File servers? Email servers? Database servers? How are all these systems (workstations and servers) protected? How are they individually configured? Windows NT and/or 9x systems policies? Third-party products? In-house scripts and programs? How are hotfixes and service packs managed? What is the status of current systems? Is a process in place to determine the necessary security updates or configurations?
If you do not have this information, detail the configuration of hardware and software inventories (bios, service packs, policies).
Network: What current connectivity exists? Are there interfaces with branch offices? Remote Access Servers for dial-up? Is Internet connectivity a right or privilege? Do you interface with NetWare? Unix? Mainframe hosts? How are these connections protected?
History: A good source for background on current systems, and the application of or lack of security consideration, is the records kept of past intrusions. Would better security design have prevented a successful attack? How was the information gained used in securing the systems after the fact? Was it successful? How can the implementation of Windows 2000 deal with these issues?
DNS: Determine the capabilities of current DNS servers. Do the servers allow dynamic registration? Can they handle service resource records? Windows 2000 implementations do not require the ability to do dynamic DNS registration, but they do require that DNS servers are capable of storing and using service resource records. BIND 4.97 and BIND 8.x support service resource records. Which DNS are you using? How can this service be secured?
Much of this information may be available as a result of studies carried out during network or Active Directory design and analysis. These topics are specifically presented in other Seattle Pacific University courses. If so, review it with an eye to security. While we are studying security design as a separate component, this is not the best plan in the real world. In fact, the hallmark of a good organization is its recognition of the need to incorporate security into every planning stage.
Your knowledge of planned upgrades and new implementations can be used to avoid costly mistakes, as well as allow you to work these systems into your overall design. For example, if you have no knowledge of the impending implementation of a Public Key Infrastructure using a third-party product, you might design an elaborate Windows 2000 PKI that may not integrate with the third-party PKI; you also might implement other security products or policies that will not be necessary after the third-party PKI is in place. If you are aware of this impending development, you may be able to steer development in ways that will ensure the integration of the third-party PKI with Windows 2000. At the least, you can incorporate this knowledge into your design. The questions to ask should center on helping you gain a knowledge of the third-party PKI, and the reasons for its implementation. Your attitude should ensure cooperation and the free flow of information. You cannot afford to be offensive (calling others "stupid" for not using the free PKI in Windows 2000 will not get you invited to important planning meetings), nor can you afford to be defensive (answering questions on Windows 2000 PKI with half-baked opinions you read in the press, presenting it as inferior but "hey, it's free," etc. will do nothing toward instilling confidence in your Windows 2000 design).