By working with ISP's and utilizing honeypots and other methods, they're able to glean an enormous amount of useful data that's making a difference in the fight against cybercrime.
Check them out: http://www.shadowserver.org/wiki/
2012-07-04
Shadowserver Foundation Taking It To The Bad Guys
Shadowserver Foundation Taking It To The Bad Guys:
The Shadowsesrver foundation is a volunteer-run organization that's collecting data on the dark side of the internet and assisting with hunting down the bad guys.
By working with ISP's and utilizing honeypots and other methods, they're able to glean an enormous amount of useful data that's making a difference in the fight against cybercrime.
Check them out: http://www.shadowserver.org/wiki/
By working with ISP's and utilizing honeypots and other methods, they're able to glean an enormous amount of useful data that's making a difference in the fight against cybercrime.
Check them out: http://www.shadowserver.org/wiki/
Kaspersky's Son Kidnapped
Kaspersky's Son Kidnapped: Eugene Kaspersky the founder of "Kaspersky Labs" a leading anti-virus provider, has had his son kidnapped in Moscow over the weekend. Is this kidnapping due to Eugene Kaspersky's wealth? Or a message being sent by the cyber-criminals in Russia?
http://www.heraldsun.com.au/news/breaking-news/it-tycoons-son-kidnapped-in-moscow/story-e6frf7jx-1226043129087
http://www.heraldsun.com.au/news/breaking-news/it-tycoons-son-kidnapped-in-moscow/story-e6frf7jx-1226043129087
Rules for Radicals
Rules for Radicals:
It was written in 1971, but this still seems like a cool book:
It was written in 1971, but this still seems like a cool book:
For an elementary illustration of tactics, take parts of your face as the point of reference; your eyes, your ears, and your nose. First the eyes: if you have organized a vast, mass-based people's organization, you can parade it visibly before the enemy and openly show your power. Second the ears; if your organization is small in numbers, then do what Gideon did: conceal the members in the dark but raise a din and clamor that will make the listener believe that your organization numbers many more than it does. Third, the nose; if your organization is too tiny even for noise, stink up the place.
Always remember the first rule of power tactics: Power is not only what you have but what the enemy thinks you have.
The second rule is: Never go outside the experience of your people. When an action or tactic is outside the experience of the people, the result is confusion, fear, and retreat. It also means a collapse of communication, as we have notes.
The third rule is: Wherever possible go outside the experience of the enemy. Here you want to cause confusion, fear, and retreat.
The fourth rule is: Make the enemy live up to their own book of rules. You can kill them with this, for they can no more obey their own rules than the Christian church can live up to Christianity.
The fourth rule carries within in the fifth rule: Ridicule is man's most potent weapon. It is almost impossible to counterattack ridicule. Also it infuriates the opposition, who then react to your advantage.
The sixth rule is: A good tactic is one that your people enjoy. If your people are not having a ball doing it, there is something very wrong with the tactic.
The seventh rule: A tactic that drags on too long becomes a drag.
[...]
The twelfth rule: The price of a successful attack is a constructive alternative. You cannot risk being trapped by the enemy in his sudden agreement with your demand and saying "You're right--we don't know what to do about this issue. Now you tell us."
The thirteenth rule: Pick the target, freeze it, personalize it, and polarize it.
Security and Human Behavior (SHB 2012)
Security and Human Behavior (SHB 2012):
I'm at the Fifth Interdisciplinary Workshop on Security and Human Behavior, SHB 2012. Google is hosting this year, at its offices in lower Manhattan.
SHB is an invitational gathering of psychologists, computer security researchers, behavioral economists, sociologists, law professors, business school professors, political scientists, anthropologists, philosophers, and others -- all of whom are studying the human side of security -- organized by Alessandro Acquisti, Ross Anderson, and me. It's not just an interdisciplinary event; most of the people here are individually interdisciplinary.
This is the best and most intellectually stimulating conference I attend all year. I told that to one of the participants yesterday, and he said something like: "Of course it is. You've specifically invited everyone you want to listen to." Which is basically correct. The workshop is organized into panels of 6-7 people. Each panelist gets ten minutes to talk about what he or she is working on, and then we spend the rest of the hour and a half in discussion.
Here is the list of participants. The list contains links to readings from each of them -- definitely a good place to browse for more information on this topic. Ross Anderson, who has far more discipline than I, is liveblogging this event. Go to the comments of that blog post to see summaries of the individual sessions.
Here are links to my posts on the first, second, third, and fourth SHB workshops. Follow those links to find summaries, papers, and audio recordings of the workshops.
I'm at the Fifth Interdisciplinary Workshop on Security and Human Behavior, SHB 2012. Google is hosting this year, at its offices in lower Manhattan.
SHB is an invitational gathering of psychologists, computer security researchers, behavioral economists, sociologists, law professors, business school professors, political scientists, anthropologists, philosophers, and others -- all of whom are studying the human side of security -- organized by Alessandro Acquisti, Ross Anderson, and me. It's not just an interdisciplinary event; most of the people here are individually interdisciplinary.
This is the best and most intellectually stimulating conference I attend all year. I told that to one of the participants yesterday, and he said something like: "Of course it is. You've specifically invited everyone you want to listen to." Which is basically correct. The workshop is organized into panels of 6-7 people. Each panelist gets ten minutes to talk about what he or she is working on, and then we spend the rest of the hour and a half in discussion.
Here is the list of participants. The list contains links to readings from each of them -- definitely a good place to browse for more information on this topic. Ross Anderson, who has far more discipline than I, is liveblogging this event. Go to the comments of that blog post to see summaries of the individual sessions.
Here are links to my posts on the first, second, third, and fourth SHB workshops. Follow those links to find summaries, papers, and audio recordings of the workshops.
Teaching the Security Mindset
Teaching the Security Mindset:
In 2008 I wrote about the security mindset and how difficult it is to teach. Two professors teaching a cyberwarfare class gave an exam where they expected their students to cheat:
Excerpt:
Read the whole paper. This is the conclusion:
Here's a Boing Boing post, including a video of a presentation about the exercise.
In 2008 I wrote about the security mindset and how difficult it is to teach. Two professors teaching a cyberwarfare class gave an exam where they expected their students to cheat:
Our variation of the Kobayashi Maru utilized a deliberately unfair exam -- write the first 100 digits of pi (3.14159...) from memory and took place in the pilot offering of a governmental cyber warfare course. The topic of the test itself was somewhat arbitrary; we only sought a scenario that would be too challenging to meet through traditional studying. By design, students were given little advance warning for the exam. Insurrection immediately followed. Why were we giving them such an unfair exam? What conceivable purpose would it serve? Now that we had their attention, we informed the class that we had no expectation that they would actually memorize the digits of pi, we expected them to cheat. How they chose to cheat was entirely up to the student. Collaborative cheating was also encouraged, but importantly, students would fail the exam if caught.
Excerpt:
Students took diverse approaches to cheating, and of the 20 students in the course, none were caught. One student used his Mandarin Chinese skills to hide the answers. Another built a small PowerPoint presentation consisting of three slides (all black slide, digits of pi slide, all black slide). The idea being that the student could flip to the answer when the proctor wasn’t looking and easily flip forwards or backward to a blank screen to hide the answer. Several students chose to hide answers on a slip of paper under the keyboards on their desks. One student hand wrote the answers on a blank sheet of paper (in advance) and simply turned it in, exploiting the fact that we didn’t pass out a formal exam sheet. Another just memorized the first ten digits of pi and randomly filled in the rest, assuming the instructors would be too lazy to
check every digit. His assumption was correct.
Read the whole paper. This is the conclusion:
Teach yourself and your students to cheat. We’ve always been taught to color inside the lines, stick to the rules, and never, ever, cheat. In seeking cyber security, we must drop that mindset. It is difficult to defeat a creative and determined adversary who must find only a single flaw among myriad defensive measures to be successful. We must not tie our hands, and our intellects, at the same time. If we truly wish to create the best possible information security professionals, being able to think like an adversary is an essential skill. Cheating exercises provide long term remembrance, teach students how to effectively evaluate a system, and motivate them to think imaginatively. Cheating will challenge students’ assumptions about security and the trust models they envision. Some will find the process uncomfortable. That is
OK and by design. For it is only by learning the thought processes of our adversaries that we can hope to unleash the creative thinking needed to build the best secure systems, become effective at red teaming and penetration testing, defend against attacks, and conduct ethical hacking activities.
Here's a Boing Boing post, including a video of a presentation about the exercise.
The Failure of Anti-Virus Companies to Catch Military Malware
The Failure of Anti-Virus Companies to Catch Military Malware:
Mikko Hypponen of F-Secure attempts to explain why anti-virus companies didn't catch Stuxnet, DuQu, and Flame:
His conclusion is simply that the attackers -- in this case military intelligence agencies -- are simply better than commercial-grade anti-virus programs.
I don't buy this. It isn't just the military that tests their malware against commercial defense products; criminals do it, too. Virus and worm writers do it. Spam writers do it. This is the never-ending arms race between attacker and defender, and it's been going on for decades. Probably the people who wrote Flame had a larger budget than a large-scale criminal organization, but their evasive techniques weren't magically better. Note that F-Secure and others had samples of Flame; they just didn't do anything about them.
I think the difference has more to do with the ways in which these military malware programs spread. That is, slowly and stealthily. It was never a priority to understand -- and then write signatures to detect -- the Flame samples because they were never considered a problem. Maybe they were classified as a one-off. Or as an anomaly. I don't know, but it seems clear that conventional non-military malware writers that want to evade detection should adopt the propagation techniques of Flame, Stuxnet, and DuQu.
EDITED TO ADD (6/23): F-Secure responded. Unfortunately, it's not a very substantive response. It's a pity; I think there's an interesting discussion to be had about why the anti-virus companies all missed Flame for so long.
Mikko Hypponen of F-Secure attempts to explain why anti-virus companies didn't catch Stuxnet, DuQu, and Flame:
When we went digging through our archive for related samples of malware, we were surprised to find that we already had samples of Flame, dating back to 2010 and 2011, that we were unaware we possessed. They had come through automated reporting mechanisms, but had never been flagged by the system as something we should examine closely. Researchers at other antivirus firms have found evidence that they received samples of the malware even earlier than this, indicating that the malware was older than 2010.
What this means is that all of us had missed detecting this malware for two years, or more. That’s a spectacular failure for our company, and for the antivirus industry in general.
It wasn’t the first time this has happened, either. Stuxnet went undetected for more than a year after it was unleashed in the wild, and was only discovered after an antivirus firm in Belarus was called in to look at machines in Iran that were having problems. When researchers dug back through their archives for anything similar to Stuxnet, they found that a zero-day exploit that was used in Stuxnet had been used before with another piece of malware, but had never been noticed at the time. A related malware called DuQu also went undetected by antivirus firms for over a year.
Stuxnet, Duqu and Flame are not normal, everyday malware, of course. All three of them were most likely developed by a Western intelligence agency as part of covert operations that weren’t meant to be discovered.
His conclusion is simply that the attackers -- in this case military intelligence agencies -- are simply better than commercial-grade anti-virus programs.
The truth is, consumer-grade antivirus products can’t protect against targeted malware created by well-resourced nation-states with bulging budgets. They can protect you against run-of-the-mill malware: banking trojans, keystroke loggers and e-mail worms. But targeted attacks like these go to great lengths to avoid antivirus products on purpose. And the zero-day exploits used in these attacks are unknown to antivirus companies by definition. As far as we can tell, before releasing their malicious codes to attack victims, the attackers tested them against all of the relevant antivirus products on the market to make sure that the malware wouldn’t be detected. They have unlimited time to perfect their attacks. It’s not a fair war between the attackers and the defenders when the attackers have access to our weapons.
We really should have been able to do better. But we didn’t. We were out of our league, in our own game.
I don't buy this. It isn't just the military that tests their malware against commercial defense products; criminals do it, too. Virus and worm writers do it. Spam writers do it. This is the never-ending arms race between attacker and defender, and it's been going on for decades. Probably the people who wrote Flame had a larger budget than a large-scale criminal organization, but their evasive techniques weren't magically better. Note that F-Secure and others had samples of Flame; they just didn't do anything about them.
I think the difference has more to do with the ways in which these military malware programs spread. That is, slowly and stealthily. It was never a priority to understand -- and then write signatures to detect -- the Flame samples because they were never considered a problem. Maybe they were classified as a one-off. Or as an anomaly. I don't know, but it seems clear that conventional non-military malware writers that want to evade detection should adopt the propagation techniques of Flame, Stuxnet, and DuQu.
EDITED TO ADD (6/23): F-Secure responded. Unfortunately, it's not a very substantive response. It's a pity; I think there's an interesting discussion to be had about why the anti-virus companies all missed Flame for so long.
Apple Patents Data-Poisoning
Apple Patents Data-Poisoning:
It's not a new idea, but Apple Computer has received a patent on "Techniques to pollute electronic profiling":
Claim 1:
It's not a new idea, but Apple Computer has received a patent on "Techniques to pollute electronic profiling":
Abstract: Techniques to pollute electronic profiling are provided. A cloned identity is created for a principal. Areas of interest are assigned to the cloned identity, where a number of the areas of interest are divergent from true interests of the principal. One or more actions are automatically processed in response to the assigned areas of interest. The actions appear to network eavesdroppers to be associated with the principal and not with the cloned identity.
Claim 1:
A device-implemented method, comprising: cloning, by a device, an identity for a principal to form a cloned identity; configuring, by the device, areas of interest to be associated with the cloned identity, the areas of interest are divergent from true areas of interest for a true identity for the principal; and automatically processing actions associated with the areas of interest for the cloned identity over a network to pollute information gathered by eavesdroppers performing dataveillance on the principal and refraining from processing the actions when the principal is detected as being logged onto the network and also refraining from processing the actions when the principal is unlikely to be logged onto the network.
9 - String Manipulation
9 - String Manipulation:
In this episode Jon shows you how to manipulate strings using Substring, IndexOf and Split.
In this episode Jon shows you how to manipulate strings using Substring, IndexOf and Split.
10 - Regular Expressions
10 - Regular Expressions:
In this episode Jon walks you through 3 scenarios where Regular Expressions can help - and also hurt. Simple string replacement and matching, as well as a more complicated example of log parsing.
In this episode Jon walks you through 3 scenarios where Regular Expressions can help - and also hurt. Simple string replacement and matching, as well as a more complicated example of log parsing.
16 - Intro to Generics, and var
16 - Intro to Generics, and var:
Jon talks about generics and what they are in a basic sense. We then talk about the need for the "var" keyword as generics add wrist-cramping typing needs. This episode is rather basic - so if you're familiar with generics it might not suit you. We will be moving to more advanced topics in the coming episodes.
Jon talks about generics and what they are in a basic sense. We then talk about the need for the "var" keyword as generics add wrist-cramping typing needs. This episode is rather basic - so if you're familiar with generics it might not suit you. We will be moving to more advanced topics in the coming episodes.
Easily open web pages in Chrome on iOS
MacOSXHints.com Easily open web pages in Chrome on iOS
With the arrival of Google's Chrome web browser on iOS, many are finding this to be a better tool than Safari. Developer Jon Abrams posted a nifty trick to easily open a web page in Chrome. Since iOS doesn't allow you to choose which browser will open links, Safari takes over every time you tap on one. But you can create a bookmarklet for Safari to open the current page in Chrome.To do this, do the following:
- Copy this bit of code: javascript:location.href="googlechrome"+location.href.substring(4);.
- Bookmark this or any web page.
- Open Safari's bookmarks, tap on "edit," and edit the new bookmark.
- Rename it to "Open in Chrome" or whatever name you wist.
- Delete the bookmark's URL in the bookmark and paste in the above code in its place.
http://feeds.macosxhints.com/click.phdo?i=7ec23bcee3df29a581ae60ec26a05e36
Sent with Reeder
-tf-
Find out what's keeping your Mac awake
MacOSXHints.com Find out what's keeping your Mac awake
Have you ever been annoyed to find that your Mac won't got to sleep when you tell it to? It turns out that in Mac OS X 10.6 and later, there's a simple way of finding out what's keeping your Mac awake.Run the following command in your Terminal:
pmset -g assertions
In the first section of output, you'll see the status of two kernel assertions named PreventSystemSleep and PreventUserIdleSystemSleep. An accompanying status of 1 for either of these means that it is currently triggered.
The second section of the output lists the processes which owns any enabled assertions, both by process id (pid) and bundle id. If the verbose bundle id doesn't ring a bell, you can always use ps up <pid>, or look in Activity Monitor, to find the name of the exact command associated with this process.
http://feeds.macosxhints.com/click.phdo?i=b07d5e8a78ead7edf5c99530aaa08566
Sent with Reeder
-tf-
Subscribe to:
Posts (Atom)