Talk:Security testing
 | This article is rated Stub-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||
| |||||||||||||||||||
spam
[edit]The links at the bottom should not be there -- they violate the non-commercial aspect of wikipedia. dfhndfnjcdnjfgnn —Preceding unsigned comment added by 220.225.7.9 (talk) 12:22, 10 December 2007 (UTC)
six topics ?
[edit]Waht's the source of the six tpic discussed ? Why 6, the security models in use are either
- based on 3 topics: CIA (Confidentiality, Integrity and Authentication), this model is typically used in e.g. ISO 2700x standards.
- based on 5 topics, in the IA (Information Assurance) model, highlighting in addition to CIA the Authentication and Non-repudiation. The IA model is e.g. used in the US military.
IA basically draws extra attention to two topics, of course more topics can be lifted out og the CIA model and presented next to it, but why would security testing do that at all ? Security testing in the end is a tool to protect, so you're on the defensive team and hence need to protect all problems. 63.84.215.130 (talk) 12:18, 16 June 2008 (UTC)
- Believe it or not, sometimes people who write stuff for the US Military are uninformed about security. Those 5 things are not independent or even fundamental, they are actually nonsense for uninformed people to seem educated. And by the way, it is not an IA Model either. John (talk) 02:39, 24 February 2014 (UTC)
- Or for informed people to seem smarter that editors who have no sources?
- Believe it or not, sometimes people who write stuff for the US Military are uninformed about security. Those 5 things are not independent or even fundamental, they are actually nonsense for uninformed people to seem educated. And by the way, it is not an IA Model either. John (talk) 02:39, 24 February 2014 (UTC)
Needs major rewrite
[edit]This article does not address security testing. The six topic thing is such nonsense. We do not even evaluate those things, we evaluate how well it meets the security requirements. Testing can't even evaluate security anyway. This article is totally lost. John (talk) 07:25, 19 February 2014 (UTC)
- That was not only not more useful to readers, it removed key information. If you want to add material or re-write the lede, feel free to, but don't gut the article. Walter Görlitz (talk) 07:29, 19 February 2014 (UTC)
- And now that I read the content you added I can't believe you made that edit at all. It's not in any way a "form of stress testing". Stress testing is where you put the system under stress by increasing load or removing resources. Security testing is an attempt to find security breaches in the system and to, as the previous lede stated, confirm that the system "protects data and maintains functionality as intended". It's also not a "sort of spot check, or sanity check". It can take days to do correct security testing of a simple website. It often requires code inspection and specific tools to attempt to use known security. The assertion that "The effort to get even 50% evaluated for even simple systems is impractical" is WP:OR at its worst as are the following sentences. There are courses of study and certifications related to the field, all of which you conveniently removed, although the details of the certifications were removed some time ago as self-promotion for the various certifying bodies, so I can't fault you for not knowing about that. Walter Görlitz (talk) 07:39, 19 February 2014 (UTC)
- That is the fallacy of web site security testing. One cannot determine if a web site (or any system) is secure by testing, unless by exhaustive testing, and we don't even know how to identify all unreachable code, let alone define what exhaustive testing even means. It absolutely IS spot checking. Testing is simply not the way to make a system secure. All testing does is point out how flawed our design system was. That nonsense is why we have websites designed by "experts" and tested by this nonsense that still get subverted. The kind of testing you are referring to is software testing. Software cannot enforce security. That is simply uninformed. You can't even inspect code to determine if it meets all requirements, it is too uninformed to propose to inspect code to determine what it will never do. And those 5 things to test for are total nonsense. When you see people list those 5 things you know they are uninformed about the technical foundations of security. The system should be designed with specific and formally derived security requirements, which may or may not address those 5 knee jerk buzz words. That is what is applicable, but specifically NOT applicable to testing. The article is very uninformed and needs to be totally gutted and written in a way that will be helpful. John (talk) 02:30, 24 February 2014 (UTC)
- That's the fallacy of all testing John. You can't do exhaustive testing of anything. No one states that testing is the way to make a system secure, but it may find currently known security issues. I made no reference John. There is static testing as well as automated testing and, oh yeah, were are the sources to support your opinions? Walter Görlitz (talk) 02:45, 24 February 2014 (UTC)
- That is actually not the fallacy of all testing; I can easily test a battery to see if it is good. We can test to see if a system does some function with a high degree of certainty. Security is about something different from other types of requirements, security is about preventing bad things, not allowing x to flow to y, or not allowing z to happen. Those are fundamentally negative requirements and cannot be evaluated the way we evaluate positive requirements, like size, weight or power. That is why there is highly specialized methodology to derive security requirements, and evaluate them. That is why we cannot use testing to evaluate security. That is why this article is such nonsense. It needs to be totally gutted and redirected. There are many articles in the technical literature that are based on this assumption, not sure anyone has ever written a paper that proves JUST THAT point. It seems pretty obvious, duh, maybe I should write one? John (talk) 03:00, 28 February 2014 (UTC)
- We're not talking about testing batteries. You are clearly discussing something other than software testing. Walter Görlitz (talk) 03:40, 28 February 2014 (UTC)
- That is actually not the fallacy of all testing; I can easily test a battery to see if it is good. We can test to see if a system does some function with a high degree of certainty. Security is about something different from other types of requirements, security is about preventing bad things, not allowing x to flow to y, or not allowing z to happen. Those are fundamentally negative requirements and cannot be evaluated the way we evaluate positive requirements, like size, weight or power. That is why there is highly specialized methodology to derive security requirements, and evaluate them. That is why we cannot use testing to evaluate security. That is why this article is such nonsense. It needs to be totally gutted and redirected. There are many articles in the technical literature that are based on this assumption, not sure anyone has ever written a paper that proves JUST THAT point. It seems pretty obvious, duh, maybe I should write one? John (talk) 03:00, 28 February 2014 (UTC)
- That's the fallacy of all testing John. You can't do exhaustive testing of anything. No one states that testing is the way to make a system secure, but it may find currently known security issues. I made no reference John. There is static testing as well as automated testing and, oh yeah, were are the sources to support your opinions? Walter Görlitz (talk) 02:45, 24 February 2014 (UTC)
- That is the fallacy of web site security testing. One cannot determine if a web site (or any system) is secure by testing, unless by exhaustive testing, and we don't even know how to identify all unreachable code, let alone define what exhaustive testing even means. It absolutely IS spot checking. Testing is simply not the way to make a system secure. All testing does is point out how flawed our design system was. That nonsense is why we have websites designed by "experts" and tested by this nonsense that still get subverted. The kind of testing you are referring to is software testing. Software cannot enforce security. That is simply uninformed. You can't even inspect code to determine if it meets all requirements, it is too uninformed to propose to inspect code to determine what it will never do. And those 5 things to test for are total nonsense. When you see people list those 5 things you know they are uninformed about the technical foundations of security. The system should be designed with specific and formally derived security requirements, which may or may not address those 5 knee jerk buzz words. That is what is applicable, but specifically NOT applicable to testing. The article is very uninformed and needs to be totally gutted and written in a way that will be helpful. John (talk) 02:30, 24 February 2014 (UTC)
- And now that I read the content you added I can't believe you made that edit at all. It's not in any way a "form of stress testing". Stress testing is where you put the system under stress by increasing load or removing resources. Security testing is an attempt to find security breaches in the system and to, as the previous lede stated, confirm that the system "protects data and maintains functionality as intended". It's also not a "sort of spot check, or sanity check". It can take days to do correct security testing of a simple website. It often requires code inspection and specific tools to attempt to use known security. The assertion that "The effort to get even 50% evaluated for even simple systems is impractical" is WP:OR at its worst as are the following sentences. There are courses of study and certifications related to the field, all of which you conveniently removed, although the details of the certifications were removed some time ago as self-promotion for the various certifying bodies, so I can't fault you for not knowing about that. Walter Görlitz (talk) 07:39, 19 February 2014 (UTC)
India Education Program course assignment
[edit]
This article was the subject of an educational assignment supported by Wikipedia Ambassadors through the India Education Program.
The above message was substituted from {{IEP assignment}} by PrimeBOT (talk) on 20:03, 1 February 2023 (UTC)