Re: Win NT security

[Andrew K Bressen <bressen@cs.columbia.edu>]

-----BEGIN PGP SIGNED MESSAGE-----

>>  Kevin Phaup, program manager lead of Microsoft's Business Systems
>>Division, put the best spin he could on this first major Windows NT
>>shortcoming. ``Pull the data into a database and then massage it,'' he said.
>>``We have a new product - System Management Server from the Back Office
>>Suite - that could help.''
>>  I agree, but why would I want to buy a brand-new operating system that
>>needs help out of the box?

Because there aren't any that do not.
OS/2 1.x and 2.x had no performance monitoring tools, Windows 3.1 and
3.11 didn't initially come with TCP/IP, Mac owners for the longest
time had to buy suitcase and still buy ramdoubler, VMS doesn't support
RAID out of the box... systems and utility software has been with us
for a long time, and will be for a while yet. 

At one facility where I work (an NYC brokerage) we run at least 200
users each on ultrix, VMS, NT 3.5, WFW 3.11, Windows 3.1, and VM/CMS,
and have about ten OS/2 1.3 servers as well. NT users require less
help with networking than dos users, more than unix users.  Backup is
easier with NT than dos, but harder than VMS.  RAID is easier than
with VMS or unix, but multiple redundantly clustered systems aren't
available for NT. Systems management is slightly harder than VMS or
unix, but much easier than WFW. NT crashes more than VM/CMS, but less
than ultrix 4.2 did and much less than dos windows does.

>>  What's more, the third-party database solution for security administration
>>is a hopeless short-term patch. To be truly effective, it needs a much
>>tighter integration with Windows NT's APIs to permit not only systemic
>>analysis, but also systemic security changes based on selected criteria.

huh? you just specced out what it needs to work; I don't see why this
would be a problem for symantec or some similar firm to deliver. The
API is published and fairly stable, NT users just have to wait for
someone to actually do it.

>>  If administrators want to change the access rights of every user so they
>>can log on at 7 a.m. instead of 8 a.m., they cannot do it with Windows NT
>>3.5. They might be able to do it with a third-party product or with Windows
>>NT 4.0.

they can't do it with unix either without coding some, and with dos
windows you can just forget about it. 

>>  ``If someone builds an administration product like that, they'll make a
>>lot of money,'' Phaup says.

yep. so what makes you say that it is "hopeless"?

>>  A  WEEKEND'S  WORK  Windows NT has other security problems, as well. For
>>example, it does not have data cryptography, which is essential to make sure
>>a network is reasonably secure from eavesdropping and integrity breaches.

um, what OS does, out of the box? especially in a 1.5 release...
heck, I'm not aware of any networkable OS that has end-to-end link and
application level encryption, file acl's, and a key management scheme
that can be both centrally and distributedly administered. Kerberos
and AFS both make a start in these directions, but are not there yet.

>>Microsoft, which knows encryption technology, easily could have included the
>>appropriate algorithms in software to make Windows NT more secure.

please to define easily? the NT 3.5 release slipped enough as it was.

>>  Microsoft's Phaup agrees it would have been simple to add encryption to
>>Windows NT. ``The hooks are all there,'' he said.

so are the hooks for UFS support, and for WINS-DNS integration. the os
has more hooks than a football field covered in velcro. so what?

>>  But Windows NT does not need cryptography for C2 certification. And
>>perhaps even more telling, Microsoft cannot export cryptography outside the
>>U.S. due to export control laws that prohibit it from doing so without
>>licensing. Of course, the company could have made two versions of Windows
>>NT: one with crytography for domestic use and one without cryptography for
>>export.
>>
>>  According to Phaup, Microsoft was reluctant to do so for two reasons.
>>``Security is way down on the list of corporate concerns and desires and
>>wants in an OS. It's in the top 20, but not the top 3,'' he says. ``And the
>>testing cycle would have been a double killer.''

summary: consumers aren't demanding security and it would cost time
and money to put it in, so we didn't make it a priority, but we did
leave hooks for it. so why are you villifying them? overall, this
sounds pretty reasonable.

>>  Windows NT's last major shortcoming lays in the omission of a feature that
>>most security experts consider virtually indispensable: boot control.

um, which security experts would these be? I sure don't consider the
absence of boot control on my 400 VMS and unix workstations to be much
of a concern...

>>  In the DOS/Windows world, third-party PC security is reasonably attempted
>>by forcing users to boot from the C drive and making them log on with IDs
>>and passwords. 

And NT does this.

>>... However, if a bootable DOS diskette is inserted in the A 
>>drive, the PC will boot without a logon, and the A:> will appear.
>>
>>  But if the user attempts to log over to the C drive, the system will come
>>back with a message such as: Invalid drive specification. Security experts
>>recognize this as an inexpensive technique that will keep out casual
>>intruders and nontechnical types.

Well, booting off of a DOS diskette in drive A sure won't let you at
my NTFS C: drive... though I'm not sure how technical an intruder
would have to be to find the users password written down somewhere on
their desk, or to try their initials or first name...

>>  One way to mandate boot control is with a hardware or firmware addition to
>>the PC in the form of an add-on card. 

Or a key lock on the power supply or a passsword lock in the CMOS of the
machine, both of which are available from several major hardware
vendors, and neither of which cares if the machine is dos, nt, unix,
or pick.

>>  In Windows NT, boot control does not even exist as an option. 

Huh? The key lock on my DEC PC works just fine, and the CMOS lock on
the compaqs here doesn't care what the OS is...

>>... Again, this
>>suggests that Microsoft's security effort was driven by C2 certification,
>>not by security itself.

OK, the federal government spends millions of dollars coming up with a
security spec for computers that they buy. Microsoft wants to sell
the fed NT, so they make sure NT can pass the spec. I fail to see the
shortcoming on their part. Out of the box NT is more secure than DOS, Windows,
Windows for Workgroups, and most flavors of unix more than two years
old. A well administered group of NT machines can be more secure than a
poorly administered group of VMS, Novell, or unix systems.

It is not the most secure OS ever devised. It sure isn't B2. This
doesn't strike me as unreasonable, though we could wish for better.

>>  Windows NT must evolve quickly to garner a spot in the secure operating
>>system arsenal or somehow steal market share from the likes of Novell. It

How is Novell more secure or securable than NT?
Comparing an OS to a networking system, strikes me as unproductive;
people run Novell on servers, not desktops. NT can run a 32 bit API on
several 64 bit flavors of hardware, it is multitasking and
multithreaded... comparing it to Novell is apples and oranges.

If you're comparing Novell+DOS (or DOS/Windows) to NT, then right out
of the box, your above statements seem reversed: if the data is on the
desktop, and the PC doesn't have extra security hardware, then I can
floppy boot the pc and get the data, but I'll need a username and
password to get into the NT system. If the data is on the server, then
under either system I'll need a username and password. Neither one
will stop me from taking the hard drive and sticking into a machine I
have control of and getting the data. 

- --a. k. bressen
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLygs0yoZzwIn1bdtAQG/YQF9EpEzsvQvEDdBnoROxlgAUK0YMrFTR35b
FvT1uqcLEqfCo65qJ2qpSmX0SC+Hin5u
=eTTq
-----END PGP SIGNATURE-----