Web Development

Ask something
Discussion Locked

Development Security Forum (continued)

0 helpful
11 replies

by maryweilage

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Welcome to the Development Security Forum. This is the place to post your security questions, share your best techniques, and express your opinion on topics that impact IT development. We also encourage you to post your comments about the Development Security Spotlight TechMail.

If you haven't subscribed to the Development Security Spotlight TechMail, visit our e-newsletter subscription center to subscribe to this free e-newsletter:
http://nl.com.com/acct_mgmt.jsp?brand=builder

Also, don't miss the discussion from the previous Development Security Forum. Use the link below to catch up on earlier member comments.
http://builder.com.com/5208-6230-0.html?forumID=26&threadID=118965

Note: When pasting links into your browser, remember to remove any extra spaces that appear.

11 replies

by gshollingsworth

I'm commenting on the DEVELOPMENT SECURITY SPOTLIGHT E-NEWSLETTER for October 28, 2003 titled WHY DEVELOPERS ARE MORE VULNERABLE TO VIRUS ATTACKS.

I agree with the assesment. Another factor which comes into play is frequently developers require higher privleges to accomplish their primary tasks in doing their job. This happens when developing drivers or system level services or when using a poorly designed development tool.

A way to reduce these risks involve using a lesser privileged account most of the time and only using a more priveleged account when needed and only for the task requiring it. Another possibility is to very narrowly relax permissions such as on a config file, scratch folder, or registry key.

A spinoff benefit is the ability to spot permission and privelege conflicts earlier in testing. I know of one version of AutoCAD which stated in the known issues that admin priveleges were required on the Windows platform. A little bit of investigation determined that two registry keys and a folder permission needed to be writable for the low-priveleged user and admin priveleges were no longer required. I think that should have been handled by the install script.

by maryweilage

We received the following comment via e-mail from Builder.com member Steven B. Kovner:

You are correct that developers are more vulnerable to various attacks, but
have left out some of the other reasons, probably due to space. You probably
could write a book with all the reasons.

Many developers do not keep up on patches. Even if the IT department does,
the developers may have software on their systems that IT does not usually
maintain. IIS is a prime example. In my last job, several people had IIS
installed (primarily for its FTP server function), but I was the only one
who kept it patched. So NIMDA was a big problem. (This was a few years ago.)

Even keeping IIS patched is not enough, because developers need debugging
support and other settings that leave IIS vulnerable. A locked-down IIS is
not suitable for development. A firewall is essential, but a corporate
firewall just blocks outside threats from reaching internal servers; once a
worm has gotten inside the firewall, it spreads.

SQL server is another example. I believe that Microsoft got hit by the SQL
Slammer worm because developers had MSDE (it comes with Visual Studio .NET).
But the initial patch, even if developers had known about it, was not
designed to be installed by people who were not experts in SQL server. The
patch needed to be merged with the initial SQL server installation package
"as described in the SQL server documentation", which was not supplied with
Visual Studio. At home, I gave up and relied on my firewall, which did the
job. But at Microsoft, once one copy of the worm got through somehow (one
misconfigured firewall?), it was all over.

And then there are the large numbers of shared drives developers use; lab
systems that are not properly maintained, but that have access to
developer's systems; the fact that developer's accounts usually need
administrator privilege, etc. (Visual Studio must be installed by the user,
as it makes user-specific settings, but needs administrator privileges to be
installed.)

There are also strange interactions between software. We had trouble with
ClearCase, the antivirus software, and Visual Studio. Visual Studio would
just hang, requiring a reboot (killing the process did not fix the problem)
due to interactions between the AV software and ClearCase. The workaround
was to turn off the AV software! IT did eventually solve the problem.

Few developers understand security (which also leaves security holes in
software). But it also seems companies are not interested in hiring
developers with knowledge in both fields. (At least that has been my
experience for somewhat over a year.)

by maryweilage

You're right on track there and you're also right, I am on a tight space budget for the newsletter, we don't want to bore too many readers (GRIN)!

There's no question that companies are lax in hiring security conscious programmers either but I think that's changing as the economic and legal consequences continue to mount for companies
which drop the ball.

You've hit on several points I intended to cover in some later newsletters - but I'd be happy to credit you for also comming up with them if you'd like.

Personally I have MSDN Universal so I must have a dozen major pieces of software installed which no manager in their right mind would want to support!

A quick look shows me that I have both VS 6 and VS .NET on this computer and that's just one of 5 non-networked systems within reach of my chair.

Also, I do daily battle with Norton Internet Security, it seems to cause the same web sites to act differently every time I log on to them.

Sigh. Oh well, if comptuers worked we'd all have to find honest work.

Thanks for writing,
John McCormick

by laman

I think we should bring in those application developers to include a set of security option in their site building application. All books and trainings mostly talk about all the diffenert options and features within the application. If there is a security option where people using the application can select, says 'No Archive' or 'No Index' or 'No Follow' etc., they will talk about it, and people become aware of it.

Regards,
Antonio

by maryweilage

Note from the editor: We received the following feedback about the 1/20 edition of the Development Security Spotlight e-newsletter from Builder.com member Ruari Plint:

Love the article, as a contracting developer I share John's thoughts on the subject, where can I find more of his writings (Ye I know I can use google) but then I'd not have the interaction.

So then who would be used to set up these regulations and standards, considering that in Software today's "Best Practice's" are tomorrows "taboos", can regulatory bodies keep up with how the IT world keeps changing things or will it (also try) curve the speed of change, (which might not necessarily be a bad thing).

I will definably keep en eye on this topic. Thanks

by maryweilage

Note from the editor: Member Joel Munt sent us the following comments about the Jan. 27th edition of the Development Security Spotlight e-newsletter entitled, "Making wise security decisions during the planning stage."

"I have to disaggree with the last part of the article. Security more data does not have to make it less secure. You just have to assign the appropriate access rights to the data rather than using one set for it all. People should only have access to the data they need. This can easily be handled with groups and group permissions."

by maryweilage

Hi,
Thank you for writing. You may be correct but I respectfully must disagree and all my experience with computer systems as well as my mathematical background, not to mention my years of security work, leads me to this conclusion.

To respond specifically to your statement, the more different categories you must maintain for data, the greater the chance for an error. Users may be granted the wrong permissions, permissions may fail to get changed with a user changes their
position or assignment, data may be placed in the wrong security category, etc., etc..

In addition, it is simply human nature that the more data you secure, the greater the chance that users will become frustrated and attempt to bypass security features. This is a widely
understood phenomenon in government security work where I have considerable first and second hand experience. Users seldom understand the need for security and therefore work diligently to avoid what they see as time-wasting rules. The smarter the worker, or the more highly placed the executive, the greater the threat. I vividly recall that a recent head of the CIA was
found to have gigabytes of top secret and even code-word computer data in a PC at his home which lacked even a firewall. A low-level clerk would have faced an espionage investigation for the
same action.

Also, shear mathematical necessity shows that the more complex a system becomes the more unstable it is unless there is a feedback mechanism and even then unless everything works exactly right. Unlike many mechanical systems, there is no practical feedback mechanism I know of which is really applicable to this data security problem.

To secure more data, more code is required and as the number of lines of code increases, each one may contain an error; then there is the interaction between lines of code, each of which may be correct in itself.

Complexity theory makes it fairly certain that the more data you must deal with and the more categories you have, the greater the chance for problems.

For all of these reasons it appears to me to be simply inescapable that the more complex a system, the greater the instability.

But that's just my opinion of course.

Thank you very much for your feedback,
John McCormick

by maryweilage

Here's member Joel Munt's response to Mr. McCormick's comments:

"That is true to an extent. However, without a certain level of compexity you will end up with all sorts of people having access to data they should not even know exists. Everything needs to be very carefully thought out before being implemented. And of course you need to have both physical and logical security. 1 is little good without the other. Many places have exceedingly general security, and they are extremely insecure. I have a fair amount of experience with both corporate and government security practices myself. And though saying people will try to bypass security is true, you have to take measures against that for truely important information. Just because places fail to implement proper security procedures doesn't mean it is not possible. Any place that can't do so should not be dealing with that level of data. On the other hand, places should only implement the security they need.

Users should never be granted access rights. Groups should be. That simplifies administration. Secondly you assign rights to levels of secrecy and type of data. This does not have to be a huge number of combinations, but should reflect the needs of the organization. Additionally you must have physical security and proper network design (obviously very sensitive data should not even been accessible on the same network as common data and there should be no means of moving it between them, having worked in such an area it is quite interesting (though anoying at times)).

As for error, well auditing, accountibility and other safeguards can help in this. You could even have a process scan daily for current employee status and access rights, and upon finding errors inform the proper personnel.

I am sure there are thresholds in both directions (probably varying in either direction based on the corporate culture, staff knowledge and data sensitivity needs) in which changes worsen the situation. Proper planning can help prevent this. Failure to plan properly will lead to failed security no matter how simple or complex your scheme. Lax security is increasingly becoming a legal issue and companies and government agencies are going to have to start implementing it properly. No system will ever be perfect, but for a lot of data lax security is criminal (literally)."

by maryweilage

Note from the editor: The following comments from member Laurie Knight are in response to the Feb. 2nd Development Security Spotlight e-newsletter, "How an upcoming IE patch may affect your dev environment."

I'm absolutely outraged that Microsoft in typical style just remove functionality because of a security problem - how much effort would it take to put something in place which warned users what was going on but gave them the option of carrying on or quitting?
This security issue is mostly a problem when used in conjunction with phishing attacks - whereby the phishers web site is disguised as a bank or financial institutions site. Therefore, a better fix than disabling functionality would have been for IE to examine the URL, and warn the user if it contained an @ symbol and told the user the full domain of the site that was about to be visited (it could even warn that the URL contained a @ and this was sometimes used to fool usersr into opening up false URLS) the user would then be presented with the option of continuing or quitting.

Bloody hellfire, more bloody work for no good reason. If Microsoft disabled all mouse and keyboard input, and screen output and disc writing then most security issues in windows would be resolved.

I tell you what - the amount of time I waste because of this and mucking about in outlook because I can no longer open some attachments even though I know where they came from and was expecting it - I think I'm going to bill microsoft for my effort...

Thanks for the heads-up - I wasn't actually aware of this before I read this article. (Well I was aware of the problem but not Microsofts ridiculous "Fix"!!

by tech locksmith

I really wish I could have done more than simply give a warning but I don?t know of any programming work around which would help other than to follow Microsoft?s suggestions on altering URLs.

Unfortunately, the situation has just gotten even worse.

The upgrade cycle for IE was jumpstarted this week because some NT and W2K code was published on the Net. It appears that this was mostly IE code because Microsoft has just made a strong recommendation that everyone upgrade their browser to IE 6 SP1 immediately.

Some major vulnerability (as yet undisclosed) has been discovered in IE 5.5 and earlier versions from examination of the published code.

This will, of course, speed the upgrade cycle meaning that the "@" URL problem will cause problems more quickly than might have occured normally.

John (author of the e-newsletter)

This discussion is closed to new replies.