Tuesday, June 14, 2011
Monday, June 13, 2011
Proteus, a sea god, could change his shape to confuse adversaries and avoid capture. Thinking along these lines, I wonder how the security architecture of networks and applications might incorporate protean properties, making it harder (more expensive and time-consuming) for attackers to compromise our defenses?
An environment that often changes may be harder to attack, but it is also hard to manage. In fact, many vulnerabilities seem to be associated with our inability to securely and timely implement changes, such as deploying security updates or disabling unnecessary services.
To create a protean security architecture, we’ll need to think asymmetrically: what attributes can complicate attackers’ jobs more than they complicate the jobs of defenders? I am not sure how to do this, but I have a few ideas to get started:
- Open “fake” ports on your perimeter firewall using a script, so that an external attacker is misinformed about what services are accessible from the Internet. Redirect the connections to low-interaction honeypots.
- Rather than blocking or dropping traffic on the perimeter firewall, configure the device to send TCP packets that indicate a transmission error, making it hard for the attacker to distinguish between a bad connection and a blocked port.
- Deploy honeytokens on your web server to mimic the appearance of web applications that aren’t actually installed there. This may stall and misdirect the attacker. Vary the type and location of the tokens periodically.
- Mimic the appearance of Internet-accessible servers that seem to be accessible via protocols such as SSH by using honeypots (e.g., Kippo). This can slow down and misdirect the attacker.
- Set up a DNS blackhole to redirect internal infected systems to websites that aren’t actually malicious by using a tool such as DNS Sinkhole. You can use a honeypot such as Dionaea to further learn about malware.
- Use open cloud services to bring up irrelevant web and other servers that seem to be associated with your organization, but don’t host sensitive data. Periodically decommission them and bring up new ones.
My ideas seem to be gravitating towards using honeypots to implement an element of deception, but there should be other ways of creating an infrastructure that is changing slightly to confuse or misdirect attackers and their tools. Do you have any ideas?
Proteus eventually captured by Menelaus, who found a way of ambushing Proteus and chaining him down. (Menelaus had an insider’s help, having received a tip from Idothea—Proteus’ daughter.) So a protean approach to defense isn’t foolproof—it is one of the elements we may be able to incorporate into an information security architecture to strengthen our resistance to attacks.
- Honeypots as Part of a Modern IT Infrastructure
- Deception Lessons for Information Security from World War II
My dear little ugly baby is growing. With the current type of threat organization's are facing, it really makes sense to some more thought on honeytokens.
Friday, June 10, 2011
Wednesday, June 8, 2011
At the end of the day, this could represent an opportunity for Lockheed Martin and EMC/RSA to set positive examples for communications among security professionals. We, the good guys, are all in this together. Many of us frequently express a longing for better defensive information sharing and bemoan how little timely, actionable information sharing there is.
ZDNet has a nice piece on why cheap GPU’s are making strong passwords useless. They are right, of course (though it’s pretty much been that way for 20 years, since the need for /etc/shadow) but they missing the obvious solution to the problem.
The solution is not to make passwords more complex. It’s making them less complex (so that users can actually remember them) and making sure brute force is impossible. We know how to do that, we just have to overcome a generation-old axiom about trivial passwords being easy to break (they are not, if you only get very few tries).
Right on the spot. With the evolution of brute forcing techniques we shouldn't be trying to fight those attacks with complex passwords; properly salted hashes and thorough protection of the offline password (I mean hashes) databases is far more important than that. Online brute forcing can be handled with simple techniques such as timeouts, account locking and CAPTCHAs.
Of course, whenever the residual risk after all those measures is still not acceptable, better to go the two-factor way instead of adding complexity to the passwords. Let's stop trying to improve this control, accept its use cases and limitations and use different controls where context and risk require that.
Tuesday, June 7, 2011
I understand getting cold feet when talking about putting your passwords in the cloud, but I must say that Lastpass's approach and posture regarding security issues is really worth mentioning. For those who don't remember or didn't pay attention, they had a security incident a few weeks ago. Check their blog to see what happened, steps taken, the current action plan and the post-mortem procedures:
Really, that's how other companies should be working on situations like this.