How is this different from what is already being done with vuln scanners? How does this find 0-days? The test comes from a particular vector which finds KNOWN vulnerabilities. This will only find Access problems if the limitations of the systems is known. It does nothing to determine trust problems like spoofing, MITM attacks, and attacks from other vectors. What they needed to do is look at it in a new way like in the SCARE project (Source Code Analysis Risk Evaluation) from ISECOM which determines all interactive points, how they are interactive (memory, user, disk), and what controls are there. Since every interactive point will have risk of some sort (like a potential real 0-day), this will tell you not only the Access problems but the Trust ones as well. Take the same methodology in SCARE and apply it to a scanner to look at all interactive points in a network per vector (run it inside, outside, and each perimeter side) and then have a program correlate where the interactive points match. You can get fancy and draw maps of this but really what you want to know is the priority of what you need to close, separate, and add missing controls to. All of this is already outlined in OSSTMM 3 already.
I just don't see how MIT can get away with announcing a tool that is not innovative and leads people down the false path of endless patching.
Wait until somebody spoofs somebody else's IP address and throws "attacks" with it at a few of the networks that submit logs. That would effectively block the IP from the spoofed address as the system would predict that the host is an attacker. Since TCP allows us to spoof almost any IP we want, we could get creative and spoof the addresses of the submitting members or even dshield itself.
All I can say is that I see this problem often enough where a security consultancy is threatened by their client because their portscan which was done during a valid Internet security test has brought down an important system. Realistically, if something like a portscan can bring down a system then that is a real problem. You know how much random garbage comes across the Internet that can cause a similar problem?!
If the monitoring is happening so as to cause a DoS, which appears to be the case, it's an availability threat to your customers and a security threat to you. Since you provided no details on the type of monitoring and specifically how they did it, it's not possible to advise specifically. For example, if they use ICMP, there is a very good possibility that you should have been dropping silently ICMP of all types coming through your gateway router. That is considered best practice for security.
Treat this like a security issue and make it go away like a security issue. That implies using technology controls and policy to clean up this mess. In your case, policy will also include a letter from your lawyer and providing your customers with the uptime data they require.
-pete.
--
You bought all that security for your network, maybe it's time you got something for free. Like the ability to test it. The OSSTMM at www.osstmm.org - Stop talking security and start doing it.
One thing I would like to see is more involvement in all of ISECOM's projects. Besides the OSSTMM, we need someone to take over the Secure Programming Methodology and I would like some grassroots help for Hacker High School. Maybe HHS is a news item in itself. I also think ISECOM needs to reach new areas like India, Japan, China, and African countries outside the Middle East where we have a decent penetration.
Slashdot Mirror
How is this different from what is already being done with vuln scanners? How does this find 0-days? The test comes from a particular vector which finds KNOWN vulnerabilities. This will only find Access problems if the limitations of the systems is known. It does nothing to determine trust problems like spoofing, MITM attacks, and attacks from other vectors. What they needed to do is look at it in a new way like in the SCARE project (Source Code Analysis Risk Evaluation) from ISECOM which determines all interactive points, how they are interactive (memory, user, disk), and what controls are there. Since every interactive point will have risk of some sort (like a potential real 0-day), this will tell you not only the Access problems but the Trust ones as well. Take the same methodology in SCARE and apply it to a scanner to look at all interactive points in a network per vector (run it inside, outside, and each perimeter side) and then have a program correlate where the interactive points match. You can get fancy and draw maps of this but really what you want to know is the priority of what you need to close, separate, and add missing controls to. All of this is already outlined in OSSTMM 3 already. I just don't see how MIT can get away with announcing a tool that is not innovative and leads people down the false path of endless patching.
Wait until somebody spoofs somebody else's IP address and throws "attacks" with it at a few of the networks that submit logs. That would effectively block the IP from the spoofed address as the system would predict that the host is an attacker. Since TCP allows us to spoof almost any IP we want, we could get creative and spoof the addresses of the submitting members or even dshield itself.
All I can say is that I see this problem often enough where a security consultancy is threatened by their client because their portscan which was done during a valid Internet security test has brought down an important system. Realistically, if something like a portscan can bring down a system then that is a real problem. You know how much random garbage comes across the Internet that can cause a similar problem?!
If the monitoring is happening so as to cause a DoS, which appears to be the case, it's an availability threat to your customers and a security threat to you. Since you provided no details on the type of monitoring and specifically how they did it, it's not possible to advise specifically. For example, if they use ICMP, there is a very good possibility that you should have been dropping silently ICMP of all types coming through your gateway router. That is considered best practice for security.
Treat this like a security issue and make it go away like a security issue. That implies using technology controls and policy to clean up this mess. In your case, policy will also include a letter from your lawyer and providing your customers with the uptime data they require.
-pete.
-- You bought all that security for your network, maybe it's time you got something for free. Like the ability to test it. The OSSTMM at www.osstmm.org - Stop talking security and start doing it.
One thing I would like to see is more involvement in all of ISECOM's projects. Besides the OSSTMM, we need someone to take over the Secure Programming Methodology and I would like some grassroots help for Hacker High School. Maybe HHS is a news item in itself. I also think ISECOM needs to reach new areas like India, Japan, China, and African countries outside the Middle East where we have a decent penetration.