This blog is moving

I'm moving to:

http://www.securitybalance.com
http://www.paesdebarros.com.br/blog/

Changing blog

I'm setting a new blog, "Security Balance". If you are reading this by RSS, please set your feed reader to:

http://feeds.feedburner.com/SecurityBalance

The new website is http://www.securitybalance.com

Another bot prediction that comes true

I've just read this on Network World:

Botnet-controlled Trojan robbing online bank customers

Well, take a look at my presentation in BH Europe this year (March). This was there, as well as the method being used by the malware from that article:

"The Trojan has the ability to use a man-in-the-middle attack, a kind of shoulder-surfing when someone logs into a bank account. It can inject a request for a Social Security number or other information, and it's very dynamic. It’s targeted for each specific bank." (Don Jackson, SecureWorks)

So, another prediction from that presentation has just been confirmed.

New trends, new threats

I've just read about Intel's concept of "portable data centers". Living in a country where people steal ATMs, I'm already seeing cases of "stolen data centers"...as always, new trends bring new threats for us to think about.

Honeytokens on databases

I recently heard about David Litchfield's blog. It was a good surprise to see that he posted today a tip about how to deploy "tripwires", or "honeytokens", on databases. I understand that this kind of resource os very important to help on identifying insiders. If you manage a database for a big company, it's worth a try.

Right on the bullseye about the insider threat

I was planning to talk about one of my favorite resources in my blogroll, Securosis. This post about the insider threat reminded me about it. Look at these remarks from Mr. Mogull and you'll not only understand this "insider threat" better but also about a very good feed to have in your blogroll:

1. "Once an external attacker penetrates perimeter security and/or compromises a trusted user account, they become the insider threat.
2. Thus, from a security controls perspective it often makes little sense to distinguish between the insider threat and external attackers- there are those with access to your network, and those without. Some are authorized, some aren’t.
3. The best defenses against malicious employees are often business process controls, not security technologies.
4. The technology cost to reduce the risks of the insider threat to levels comparable to the external threat are materially greater without business process controls.
5. The number of potential external attackers is the population of the Earth with access to a computer. The number of potential malicious employees is no greater than the total number of employees.
6. If you allow contractors and partners the same access to your network and resources as your employees, but fail to apply security controls to their systems, you must assume they are compromised.
7. Detective controls with real-time alerting and an efficient incident response process are usually more effective for protecting internal systems than preventative technology controls, which more materially increase the overall business cost by interfering with business processes.
8. Preventative controls built into the business process are more efficient than external technological preventative controls."

Number 7 highlight is mine. That's the reason why I believe that monitoring the internal network is sooooo important.

Pete Lindstrom and Linda Stutsman about "best practices"

This post from Mr. Lindstrom is very interesting. Mainly because I totally agree with him on that "there is no such thing as best practices, but I also believe there really should be such a thing". It's very hard to work on a field where you can't show that you performed well. Particularly for me, it's even worse to see very bad professionals claiming that they are selling/deploying "best practices".

I also like when Mrs. Stutsman said that "There may a best practice within an industry but it's tough to go across industries". PCI-DSS is a very good example on that.

Putting this and a last comment from Anton Aylward that I mentioned here together I'm starting to believe that we need to build some kind of "basics best practices". We already know pretty much about how to deal with the basics aspects of Information Security, so let's put aside those things that will always change from business to business and build something that every company can use as a way to ensure that its security doesn't sucks, at least.

Using Anton's words again, "Lets worry about the baseline before we try to address the esoteric".

Finally something good about NAC

I usually don't give much credit to NAC articles and news on Network Computing. They are usually that old crap about new miraculous products. However, this little piece is very good.

Jeff Prince explains quite well which kind of NAC implementations are worth something and which are not. Of course, looking at his signature I noticed it's from a company that sells NAC products, but I agree with his point of view on this article. After performing several security assessments I am a passionate advocate of internal LAN segregation to avoid the "M&M's" syndrome. NAC can make it quite easier.

Spafford and magical solutions

Eugene Spafford is one of the best minds in the infosec field. This post from him is very aligned with that other one from Anton Aylward that I mentioned here yesterday. I personally agree with a great part of what he is saying there. In a nutshell, he says that we usually spend too much time and money looking for "patch-like" solutions when we already know how to do things in the right way. A good example of that is, quoting him, "We spend huge amounts on detecting botnets and worms, and deploying firewalls to stop them, rather than constructing network-based systems with architectures that don’t support such malware.". If we look at the infosec problem as an isolated problem he is more than right. It's just like Marcus Ranum, who usually goes by a similar line.

However, I believe that this approach is too technical, even simplistic. For me it's the same as saying "we already know how to produce electrical cars, so let's replace all the others by them to solve the global warming issue". There are several linked factors on these issues that we simply can't ignore. There are economical factors linked to the environmental issues, just as there are economical issues, compatibility issues, business priority issues, complexity issues, among others, linked to the infosec issue. I wonder if all problems we deal with could be so easily solved as Dr. Spafford suggests. I like to keep my mind open to "out of the box" solutions, but we can't just ignore all the linked matters when talking about security.

Another post on the wall

I've just read another of those posts that should be framed and hanged on a wall.

This post from Anton Aylward is great, even with he just stating something very obvious. Super ninja risk analysis initiatives sometimes make people forget about the basics, even if the expected results of the RA is knowing that those basic things should be treated first!

Some pieces of the post are very interesting, like this analogy: "So it gets to be, if you’ll pardon the analogy, like worrying over the diseases of civilization like Alzheimer’s, Osteoarthritis/Osteoporosis, ALS, Macular degeneration, diseases due to over-rich diets, Senescence in general when you don’t have a adequate diet or clean water to drink."

His closing remark is also simple and perfect: "Lets worry about the baseline before we try to address the esoteric."

This reminds me of a case I saw. I arrived in a place with lots of expectations about deploying risk management processes and policies, but end up starting by removing root access and providing individual accounts to system administrators, enabling logs, installing critical patches on servers and setting passwords for those pesky "sa" users.

Talking about risk management at that time was the same thing as talking about healthy food habits to someone who is dying from a bleeding cut.

And, just to mention, it was funny to deal with problems I mentioned above and hear from the auditors that "users should change their passwords each 30 days and not 90". :-)