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 hung 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". :-)

Application Security and MS

It's no news that several of the best application security minds are working for MS today. This blog is a live proof of that.There is a very good post there about the first line of defense for web applications, the input validation. I'm participating in a web app development project that has a small part of code audit. I demanded during the project specification that the input validation code was the minimum part that should be verified during the process. There is a picture in that post that show exactly why, input validation problems are in the center of several types of vulnerabilities, from SQL injection to buffer overflows.The post is the first part, according to the author. I hope to see a lot more about the subject there.

Log mining

Anton Chuvakin wrote a nice piece about a log analysis he performed on a compromised box. It was interesting to see some techniques I'm using on my work and on my master thesis. He also mentioned some experience on profiling users (the information that one week to one month is enough was very valuable to me) and some types of analysis that can be made following that concept.I'm trying to build something in that way not only based on users accounts, but also for computers, services, applications, physical locations and many other "entities". My goal is to end with a list of common situations (observables) that can be used to detect anomalies usually linked to the presence of an attacker.And sorry Dr.A, I'm planning to try that in a SIEM way instead of a log analysis approach :-)

Good analogy

This post in Securosis is a very good analogy and also a good piece about the limits of encryption as a security measure. I always liked physical analogies, specially those with armies and military tactics. I'm trying to read a little more about police strategies, as they seem to me as they are a very good option to compare to information security aspects.War is always simple, as you usually can see a very well defined perimeter and where the enemy is. City crime, however, is quite different. I hope to explore this a little more in the future.

Gunnar Peterson and security budget

This post from Gunnar Peterson about security budgets is extremely interesting. The comparison that he suggests between security budgets and IT budgets is a very good way to detect misconceptions about security needs and alignment between the IT strategy and the security strategy.However, it's important to mention that some network solutions can solve problems that have their root cause in other layers. It's also important to perform the comparison in a time line perspective, as you may need to invest more in a specific layer now to address a gap created by past IT investments in that layer without the related security budget.

Killer encryption application

Rob Newby wrote a very nice piece about encryption usage. I believe the most important message there is that the focus should be on key management issues, not algorithm strength and key sizes.