Different perspective on SecurID

If there was such effort from criminals to obtain RSA SecurID seeds, we can conclude that two factor authentication has been a real barrier to attackers; otherwise, they wouldn't bother to go after that.

 

Lenny Zeltser on Information Security — 6 Ideas for a Protean Information Security Architecture

6 Ideas for a Protean Information Security Architecture

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.

Related:

• Honeypots as Part of a Modern IT Infrastructure
• Deception Lessons for Information Security from World War II

— Lenny Zeltser

via blog.zeltser.com

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.

Information classification and Threat centric approaches

Always good to follow discussions between smart people in security. I suggest reading this nice pair of posts from Rob Bainbridge and Dominic White (SensePost blog).

 

As Rob said in his comment on Dominic's post, probably both are right. I believe the right approach is a mix of data centric and threat centric security. A good takeaway from Rob's post is the suggestion on working on a basic information categorization instead of using the old sensitivity levels classification model; it's just more natural to people and avoid that "oh my data is too important to me so it's probably top secret".

 

From the other side, a good view about why a threat centric approach is also important is Dominic's comment about pivoting and the consolidation of information containers. Using the threat centric approach helps dealing with that more than just trying to protect stuff according to classification labels.

 

This discussion just reinforces my suggestion of having two separate groups within the organization, each one with different roles (threat and protection) and bringing their findings and suggestions to the CSO (or a security architect) to define prioritization and strategy. That's probably how we could get the best from both approaches.

Good analysis of the LM case

Dave Kennedy wrote a very good post on the Verizon Business Security Blog about how the Lockheed Martin "breach" (was it really a breach?) is being handled. He points to the information being disclosed by Lockheed Martin and RSA and how that allows us to understand what had actually happened there.

The interesting aspect about this episode is that the only reasonable conclusion we can reach is that something really bad happened. If nothing happened LM would be quick to provide enough details to allow people to understand that it wasn't a big deal. On the other hand, an organization that only detects it's been breached after finding malware in its internal network wallowing in gigabytes of highly sensitive data will probably try to release only some vague statements such as "we detected a significant and tenacious attack on its information systems network".

Anyway, details about the attacker methods would allow a lot of other organizations to better protect themselves; not only that, if the detection was really in a early stage it would be quite beneficial (not to say to LM's image too) to others to know where to look for suspicious activity. As Dave says in his post:

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.

These guys are some of the best honeypots the security community has out there; we should be doing something to leverage the information about attacks being gathered there. The first step is sharing that data.

UPDATE: Very good analysis from Dan Kaminsky on the subject here.

SecuriTeam Blogs » Simple passwords are the solution

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).

It’s not just cheap GPUs. Complex passwords are also the problem. Simple passwords are the solution.

via blogs.securiteam.com

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.

Lastpass

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:

http://blog.lastpass.com/

Really, that's how other companies should be working on situations like this.