Slashdot Mirror
Startup Prepares Cracker Attack Emulator
Startup.Blog writes "A startup company MuSecurity is shipping a product that emulates multitude of known attacks and integrates the security checks into quality assurance processes. The company 'will soon begin selling a new vulnerability assessment product that lets technology vendors and enterprise developers test their products with known hacker techniques, allowing them to fix bugs before products are put into use.'"
How is this anything new? There is open source (and closed) that has been available for a while that does this.
--
United Bimmer - BMW Enthusiast Community
Mu Security would not say whether the product will be hardware- or software-based, but more details will be revealed in March, Furgerson said.
That's not very helpful. If we're talking a tool to check for security flaws already patched against, what good is that? Just keep your systems up to date. On the other hand, if we're talking about things like buffer-overflow checkers, then why not use an existing product?
This thing is going to have to be pretty darn impressive to actually find a niche other than people who don't know any better.
Javascript + Nintendo DSi = DSiCade
... and several other ones already axist.
I'd say that the only interesting thing about this announcement is an opportunity for geeks to analyse this new product and see if it contains any ripped off GPL'ed code.
FP.
Also FatPhil on SoylentNews, id 863
cracker sues Startup over piracy of cracker's trade secrets via emulation.
I read about this a couple days ago and spent some time on the company's site looking for an explanation of what they are doing that is so new. The answer I came up with is "Nothing". There is no information on their websites about specifc products or services. Looks like another snake-oil security startup.
There are other companies and even some academic groups (PROTOS from the University of Oulu, to name one) who have been doing real things in this area for years. There are also companies that take a source-code centric approach.
For several years now, there have been products that check for whole classes of vulnerabilities in applications. Such approaches are not limited to just known vulnerabilities in existing apps -- they check for common programming or configuration errors in custom applications as well. They are making it sound like checking for these things before systems go into production is a new concept. That's the whole point of security auditing.
While most crackers are pretty harmless, saltines are going to give you the most problem. Keep an eye out for Ritz as well, as I've personally had issues with keeping those out of my system.
Does it call fed up employees who are just looking for someone to talk to, exploiting the conversation and getting valuable information necessary to break into the network? :)
Cool concept, but I wonder about how effective it'll be without good admins who know how to watch logs, set up honeypots when necessary, and train employees to shut up. Still, it could have it's uses.
"Better to be vulgar than non-existent" -Bev Henson
"MuSecurity. We hack you first, so the hackers don't have to."
"Pre-root your box for only $19.95"
"Want a bot net? Have you own today!"
Oh, testing for exploits, not actually exploiting the box.. hehe.
Serious? Seriousness is well above my pay grade.
More "keeping up with the hackers" nonsense. How about we just leave nothing permitted that we don't already know is legit?
There's money to be made in treating cancer, but not curing it. And this is the IT equivalent.
vk.
For those of you that want to emulate a cracker attack, I cannot recommended highly enough any of the ABBA albums out there. Turn that on amongst any non-crackers, and you will know rapidly how well things will hold up.
There are limits to this type of stress-testing, though - playing any "Rocky" movie will likely cause excessive bleeding from your ears. There's no reason to go overboard when cracker-testing.
Almost all the staff is ex-Juniper. Talk about running off with corporate assets
Its the unknown ones you really have to worry about.
http://michaelsmith.id.au
N.B. mu is a nice Japanese Zen word which means emptiness of mind, or literally "nothing."
Paul Gillingwater
MBA, CISSP, CISM
Slashdot Editor Duped by Guerilla Marketer
It's a good question, however there is a simple answer.
There are at least 2 parts to each exploit. One is the route in (a buffer overrun, for example), and the other is the payload. You can test vulnerability by using the same route in, but with a harmless, or simply information-gathering payload. Other alternatives can include a patching payload.
FP.
Also FatPhil on SoylentNews, id 863
MuSecurity looks like MicroSecurity (picture the little-mu greek character in front). Or, in ISO units, "very little security". Strange choice for a name.
As mentioned previously, this sort of thing is being/has been done. One project I am familiar with is the Internet-scale Event and Attack Generation Environment (ISEAGE) project at Iowa State University.
Its webpage, has an overview of the project and documentation on its architecture and implementation. I think one of the key aspects of the project can be found in the overview: "Unlike computer-based simulations, real attacks will be played out against real equipment."
ISEAGE is approaching security from a real-world perspective, using real world devices. Sure, your software/hardware might be secure when the attacks are played against it; but is it secure when those attacks when there are dozens of attacks occuring simultaneously? What about when it is being hit by thousands of requests, or is under a DDoS attack? What happens when devices decide to start breaking the protocols, or the rules? What happens if a device physically fails? What is the effect of a device overheating during a DDoS attack? How do you simulate this/test for this other than hooking it up and hammering it with a DDoS attack?
This is the kind of information that is needed to prevent or mitigate an attack, but can't be found by reading code or running a scanner. How did the US figure out how to build rockets? We built some, they blew up, and better ones got built. The real world isn't the same as a lab.
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
No, you are confused. Crackers are/were people who break software copy protection. This is how it's always been. I guess you weren't around "back then", or you were living in some other reality different from the planet Earth's.
This is why 2600 is called the hacker quarterly, why Defcon is a hacker convention, why Phrack is called Phrack (Phreaking/hacking), and so on.
It has never been the way you describe, never.