1995-01-26 - An article on Windows (in)security

Header Data

From: Rich Salz <rsalz@osf.org>
To: cypherpunks@toad.com
Message Hash: 5ee0a0edd856b9a5b9de315fb6163c1f5409bda7844e50c4eccd3ccbe801b51f
Message ID: <9501261717.AA08133@sulphur.osf.org>
Reply To: N/A
UTC Datetime: 1995-01-26 17:23:02 UTC
Raw Date: Thu, 26 Jan 95 09:23:02 PST

Raw message

From: Rich Salz <rsalz@osf.org>
Date: Thu, 26 Jan 95 09:23:02 PST
To: cypherpunks@toad.com
Subject: An article on Windows (in)security
Message-ID: <9501261717.AA08133@sulphur.osf.org>
MIME-Version: 1.0
Content-Type: text/plain


---------- Begin Forwarded Message ----------
>From: first@individual.com (An Information Service of INDIVIDUAL Inc.) (by
>way of
[Some initial stuff seems missing, sorry.]

>  ``No.''
>
>  And so it went. Once the security configuration is established and the
>security profiles are put in a database-like protected file system,
>accessing that data to get a full view of the security policy implementation
>is near impossible. An administrator must retrieve individually each piece
>of data stored in the security database, then manually collate and compile
>it into a usable form.
>
>  In a large operation, the security administrator will build a security
>database by virtue of the number of objects and characteristics assigned to
>each object during configuration. But Windows NT offers little way to access
>and manipulate that database for analysis, rapid reconfiguration or global
>views. It appears, and Microsoft engineers agree, someone will have to build
>a utility program to take advantage of the security database via the maze of
>APIs available to third-party developers.
>
>  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?
>
>  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.
>
>  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.
>
>  ``If someone builds an administration product like that, they'll make a
>lot of money,'' Phaup says.
>
>  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.
>Microsoft, which knows encryption technology, easily could have included the
>appropriate algorithms in software to make Windows NT more secure.
>
>  Microsoft's Phaup agrees it would have been simple to add encryption to
>Windows NT. ``The hooks are all there,'' he said.
>
>  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.''
>
>  Windows NT's last major shortcoming lays in the omission of a feature that
>most security experts consider virtually indispensable: boot control.
>
>  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. 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.
>
>  One way to mandate boot control is with a hardware or firmware addition to
>the PC in the form of an add-on card. The hardware boot process is
>interrupted, and then even access to the A drive can be restricted until the
>actual logon process through the legal boot drive has been successfully
>completed.
>
>  In Windows NT, boot control does not even exist as an option. Again, this
>suggests that Microsoft's security effort was driven by C2 certification,
>not by security itself.
>
>  In its defense, there is a lot to like about Windows NT and the plethora
>of functionality it offers from the application standpoint. But Windows NT
>sorely lacks in security, so much so that it almost would be safer not to
>use any security.
>
>  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
>just is not there yet. But Microsoft's Phaup left me with one closing
>thought. ``Have you talked to the Cairo [Windows 95.5] guys yet?''
>
>  2Schwartau is an independent consultant, writer and lecturer on network
>security topics. He can be reached at Interpact, Inc. at (813) 393-6600, or
>via electronic mail at P00506@psilink.com.
>
>[01-23-95 at 15:10 EST, Copyright 1995, Network World, File: x0123303.8dn]






Thread