[Dshield] More secure default configurations?

Miles Stevenson miles at mstevenson.org
Tue Mar 22 15:00:38 GMT 2005


On Saturday 19 March 2005 5:17 pm, Henry Hertz Hobbit wrote:
> I appreciate your comments, but I would say that ALL of the above
> are responsible for security (you omitted the SysAdmin). 

In this sense, you seem to be using the word "security" as a catch-all phrase. 
If that is the case, then I strongly disagree with you (but I don't think 
that is what you intended). One of the points that I made in my post was to 
distinguish some of the specific security practices that vendors are 
responsible for (I mentioned writing secure code and providing security 
functionality in the OS/application) from practices that system users are 
responsible for, such as applying the appropriate security configurations for 
their environment. Simply saying that "ALL parties are responsible for 
security" really doesn't help us get anywhere because there is no way to 
identify clear goals without being specific about what we mean by 
"security".

So, while I would agree that all parties do have security responsibilities, 
there is a need to specify which practices each party is responsible for and 
why.  The argument that I was trying to make is that configuring a system 
with the appropriate security controls is not the responsibility of the 
vendor, but the system owners; because of this, security folks should be 
laying blame on the system owners for insecure configurations instead of 
vendors (provided the functionality exists to configure the system properly).

Also, when I use the term "user", I was describing any user/operator of a 
system, including a Sysadmin if there happens to be one. That's my fault for 
being vague. =)

> [1] The OS vendor should send the OS out with no extra services turned
> on than are necessary. All others should be turned off. 

Necessary...for what? In a hypothetical scenario, what if RedHat does a 
useability study of their OS and finds that running sendmail is one of the 
most popular purposes of their systems? Would it not then be in both RedHat 
and the consumers' best interest to have a base configuration of the service 
active by default? How do you determine what is necessary?

In contrast, I think OpenBSD is pretty good about giving you a very minimal 
and restricted default installation. Of course, the system isn't going to do 
squat until you configure it, but it is more secure. But in a time where OS 
reviews base their ratings on how fast the OS installs and how much 
configuration the user has to do post-installation (less being better), I 
think it's very clear that the majority of the user base out there wants 
everything to "just work" out of the box. Vendors have simply been responding 
to demand here. Underlying services, such as NetBIOS and Windows Indexing 
Service are on by default so things can "just work" from the users' 
perspective.

So again, I think trying to persuade the user-base of minimized, restricted 
configurations is the more appropriate approach. If people stop using RedHat 
because they have poor default file permissions in /usr/bin, I'm sure RedHat 
would respond accordingly.


> [2] Application vendors are responsible for making their applications
> as secure as possible.  

Again, I think this is a vague demand to make on application 
vendors. Application vendors need to understand what it is that we want them 
to secure. Do we want two-factor authentication or is it not a big enough 
security gain for the hassle? Should a company devote 25% of their developer 
hours auditing code for security bugs instead of other features and 
functionality? 15%? 80%? How much application speed are we willing to 
sacrifice for slower but more securely designed code? 

Specifics have to be defined here, with testable, real-world metrics to 
determine positive progress or negative decline.

There are a slew of standards and certifications and accreditations out there 
where third parties test and gauge the security performance of applications, 
appliances, and operating systems. But I don't see any processes out there 
for the most important part of secure software: the development process. Why 
is that?

There are dozens of different style guides for syntactically writing code, and 
even more guides for debugging, testing, and designing applications. Why 
aren't there any gold standards out there that consumers can use to identify 
software companies that design and code their products with security in mind 
at every step of the way?

Because there is not enough demand. Most consumers do not care how much 
security planning goes into the development process. While it is true that 
security is becoming more of a public issue in the software industry, most of 
the focus right now is centered around features, such as anti-spyware, 
anti-virus, firewalls, VPN's, and so on. Consumers are still not showing much 
concern for quality programming, design, and planning.

-- 
Miles Stevenson
Email: miles at mstevenson.org
URL: http://www.mstevenson.org
PGP/GPG Key ID: 329F889D767D2F63




More information about the list mailing list