Discussion on:
View:
Show:
Was this one too obvious to mention? If you can't see the source, how do you know it meets the criteria in the article?
Remember the provisions of "copyyleft" - if it is open source thet you include in your code then have you just lost copyright on your (or your employer's) assets.
The other question is will it work on the next release of operating system / database / perl... often the biggest hurdle in upgrading package software has been getting all the "tools" to work with the new version. For example Disk Utilities and Communications tools delayed our implementation of Windows XP.
The other question is will it work on the next release of operating system / database / perl... often the biggest hurdle in upgrading package software has been getting all the "tools" to work with the new version. For example Disk Utilities and Communications tools delayed our implementation of Windows XP.
Copyleft refers to the GPL, which is Free Software.
Open Source (http://www.opensource.org ) is slightly different in some regards. The two should not be confused.
Now, to the meat.
What you fail to realize is that the copyleft IS a copyright. When one copyrights something, one has certain rights that one can reserve.
Copyleft allows the users more rights than 'All Rights Reserved'. The employer still maintains the Copyleft. If you want to understand this better, you should check outhttp://www.gnu.org and http://www.opensource.org
Open Source (http://www.opensource.org ) is slightly different in some regards. The two should not be confused.
Now, to the meat.
What you fail to realize is that the copyleft IS a copyright. When one copyrights something, one has certain rights that one can reserve.
Copyleft allows the users more rights than 'All Rights Reserved'. The employer still maintains the Copyleft. If you want to understand this better, you should check outhttp://www.gnu.org and http://www.opensource.org
I agree that it's a dangerous practice to include executables for which you haven't seen the source. There are exceptions, though. For example, if you purchase a set of programming utilities, chances are--you won't get the source code. On the other hand, you're purchasing these from a "trusted source".
Again, it's not a good idea to blindly trust software modules--but common sense has to be applied. You know that if you use Microsoft stuff, you'll need to keep an eye out for vulnerabilities on eeye, securityfocus, etc.
At the risk of going on and on--i mention the practices of shelling out. A lot of these executables require shelling out of the program. Take a look at the top 20 vulnerabilities. The majority of them exploit shells out of a program.
Thanks for the input,
Ron
Again, it's not a good idea to blindly trust software modules--but common sense has to be applied. You know that if you use Microsoft stuff, you'll need to keep an eye out for vulnerabilities on eeye, securityfocus, etc.
At the risk of going on and on--i mention the practices of shelling out. A lot of these executables require shelling out of the program. Take a look at the top 20 vulnerabilities. The majority of them exploit shells out of a program.
Thanks for the input,
Ron
I would think that this would be an article talking about how to avoid buffer overflows and other memory management tips to prevent your code from being eploited. This seems to be a bit dated, and most of the article should be commonsence for protecting information from a dumb user.
A secure application has to go beyond just these standard tests and really need to be part of the design as well.
A secure application has to go beyond just these standard tests and really need to be part of the design as well.
This week has seen many many patches for closed source and open source projects. At least open source gives me a chance to review the code. I will say the coder must be careful libs one uses do not trample on patent rights or make your project itself an open source project. Imagine a company's surprise if they find they must have your source code available due to the license? But if they're ok with this and you are too, help the community. Or know exactly what you're getting into...
I think there's an overall misunderstanding or people not making the difference between Open Source and licenses.
Open source does not mean no rights nor protection, also does not always mean free redistribution of additions to the source. This last point is a licensing requirement from the GPL license, an open source license, the most famous but not the only one.
Open source does not mean no rights nor protection, also does not always mean free redistribution of additions to the source. This last point is a licensing requirement from the GPL license, an open source license, the most famous but not the only one.
Recently I have seen many authors use the word "audit" when I think the proper word is "audit trailing". Audit trail is the word used for many years (even in the software industry) so why is it changing now? An audit is performed using the audit trail to check for possible anomalies. Simply recording information is not an audit. It may sound pedantic but it is annoying to those who are used to the former term.
Concerning the use of audit trails, as much as possible should be able to be audittrailed, and audit trailing should be able to be turned on and off by the user depending on their security needs.
Concerning the use of audit trails, as much as possible should be able to be audittrailed, and audit trailing should be able to be turned on and off by the user depending on their security needs.
Actually, "auditing" was originally introduces as "journaling" by the NIST back in the mid 1970's--as a means of ensuring accountability, and attribution. The term "journaling" later gave way to a similar term "auditing" in the mid-80's, with the publication of the Rainbow Series. Either way, it's a symantics argument. However, if you look at the Tan Book, it's entitled "Understanding Audit".
If you look at the Carnegie-Mellon's software development stuff (put out by the SEI--not that I'm a staunch SEI-kinda guy), they call it auditing, too.
No offense.
If you look at the Carnegie-Mellon's software development stuff (put out by the SEI--not that I'm a staunch SEI-kinda guy), they call it auditing, too.
No offense.
Thanks for the input, I am always willing to learn, but I am not convinced yet.
Yes it is semantics and pendantic. But commandment 5 only explicitely discusses the collection of information (if audit = audit trail), which to me does not sound good.
Commandment 5 says "audit but don't overaudit" - it is talking about the system audit trail, and the actual audit (checking) part or the process is only implied. Information must be both collected and checked.
Also in my opinion I think it is good practice to collect a lot of information (in the audit trail) since you do not always know what to look for. The decision then how much to check then occurs when actually doing the checking (auditing) of the collected records. Of course this is only possible if system resources permit it.
Concerning your reply:
You imply "audit trail" was called journalling by NIST in the 70's, and that in the mid 80's "audit trail" or "journalling" started to get called "auditing".
The "Tan Book" does distinguish between audit and audit trail.
Yes it is semantics and pendantic. But commandment 5 only explicitely discusses the collection of information (if audit = audit trail), which to me does not sound good.
Commandment 5 says "audit but don't overaudit" - it is talking about the system audit trail, and the actual audit (checking) part or the process is only implied. Information must be both collected and checked.
Also in my opinion I think it is good practice to collect a lot of information (in the audit trail) since you do not always know what to look for. The decision then how much to check then occurs when actually doing the checking (auditing) of the collected records. Of course this is only possible if system resources permit it.
Concerning your reply:
You imply "audit trail" was called journalling by NIST in the 70's, and that in the mid 80's "audit trail" or "journalling" started to get called "auditing".
The "Tan Book" does distinguish between audit and audit trail.
The fact is in broad terms, there have been some insecure open source programs created (ie PhpNuke). However, a better way to warn people of this is not to group all open source projects into one lump and make users weary of them. A more true statement would be to use caution when using any software that you did not create yourself.
I would argue that if using open source software to ensure the reputation of the project. Community size, length of existence, and discussions on message boards are all signs that can help you make a judgement on the security of an application. Projects range from those supported by corporations to those led by a zit faced kid looking for something for his resume.
I don't at all think that this is unique to open source, but to all software applications. Don't blindly trust a vendor just because you paid him money. As we are finding out, the price of software doesn't always correlate to it's quality.
I would argue that if using open source software to ensure the reputation of the project. Community size, length of existence, and discussions on message boards are all signs that can help you make a judgement on the security of an application. Projects range from those supported by corporations to those led by a zit faced kid looking for something for his resume.
I don't at all think that this is unique to open source, but to all software applications. Don't blindly trust a vendor just because you paid him money. As we are finding out, the price of software doesn't always correlate to it's quality.
I can't agree with you more. However, I've seen a higher occurence rate of "blind trust" when developers use open source. I based these "rules", if you will, on established trends.
Thanks for the good input.
Ron
Thanks for the good input.
Ron
To me, closed source today is just as risky. To me, "Trojan horse" should apply in computer technology just like it does everywhere: something you acquire or accept as a gift, but brings in the egregious security breach.
Like Palladium, Echelon,Carnivore.. And who makes Palladium? How can you trust a corp that has proved it is willing to test the limits of the law and break all the corporate ethics rules to keep its cash cow (you) feeding it money?
Like Palladium, Echelon,Carnivore.. And who makes Palladium? How can you trust a corp that has proved it is willing to test the limits of the law and break all the corporate ethics rules to keep its cash cow (you) feeding it money?
And remember coders to review all closed-source software. You have even less of an idea who worked on it and how much time and effort they put into it to make it secure.
But wait, you can't review closed-source code. So I guess you are completely at the mercy of someone else. But a company is liable for security holes in their code, right? Well, no. Read the EULA and you will realize that YOU are responsible for their bad code. Utilizing closed source is a COMPLETE act of faith in other humans.
I think I'd rather trust thousands of eyes, some possibly malicious, than trust dozens of eyes, some possibly malicious.
But wait, you can't review closed-source code. So I guess you are completely at the mercy of someone else. But a company is liable for security holes in their code, right? Well, no. Read the EULA and you will realize that YOU are responsible for their bad code. Utilizing closed source is a COMPLETE act of faith in other humans.
I think I'd rather trust thousands of eyes, some possibly malicious, than trust dozens of eyes, some possibly malicious.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
