Asset categorization (or, why I like CVSS)

A security group *must* know the value of the assets that they are protecting. Ideally, you determine this value *before* designing your security infrastructure. You cannot design an optimized security architecture without defining critical assets…yet, I see it happening all the time. Security gets worked in on the back end. That’s a problem.

Along a similar vein, Vulnerability scanners are a great tool if deployed at the correct time and used correctly. However, a vulnerability scanner cannot tell you the monetary worth of the system that it has just scanned. I’ve seen too many companies that crank up Nessus, run a scan of an entire /16 block, and then start remediating from the top of the report to the bottom. Again, that’s a problem.

So, how does that tie into CVSS? Well, CVSS is a system for assigning a numeric value to a specific flaw. There are a number of factors which go into determining this value; however, the end result is just a positive integer between 0 and 10. This information, coupled with the asset value, gives you a clearly defined list of remediation priority. Multiply the asset value with the CVSS ranking. Presto! You have a prioritized list to give to your Compliance team.



Where have all the Security Architects gone?

as Sunshine stated, ‘looking at it from the other side, though, this comes to show some of the ill in our industry. people buying “products” to do security rather than incorporate products in their security strategy and infrastructure.’

he’s dead on the money. i had planned on blogging about this some time in the next month…but, since he brought it up :) the *art* of architecting secure networks seems to have gone the way of the dodo. many current security tools seem to be fixing the symptom and ignoring the cause. the cause of many of our woes is simply poor initial architecture. period. you don’t need an application firewall if you’ve followed the guidelines for architecting good code. you don’t need an ips to only allow x% of your traffic to flow to a certain service if you have correctly implemented traffic-shaping on your edge (or core) router. i could go on and on. many “security” tools are just “second chance” devices. you’ve incorrectly configured your edge router or never really had a clue how to configure it in the first place? that’s ok, put our “security device” (a router with a fancy gui) in front of your servers and try it again. good initial architecture falls into that 80/20 rule. it solves 80% of the problem in 20% (or less) of the time.


Educate your users? Now there’s a novel idea.

I’ve audited organizations which boasted 20 or 30 information security personnel. That’s a decent-sized group. And, when I get to asking them about their User education program, it’s not surprising to hear that they have maybe allocated one-half of a Full time Employee (FTE) to user education. User Education isn’t sexy, stimulating, or fun (usually). However, educating your users is part of COMMUNICATING your policy. You can’t expect people to go the speed limit if you don’t post signs letting them know what the speed limit is.

A well-educated populace can serve as a human IDS, alerting you to possible problems within your network. User education also highlights your security group as the enforcers of the rules. Cars tend to drive closer to the speed limit when they see a police car on the horizon. It’s the same with corporate information security. I try to reach each user at least 4 times a year. This isn’t necessarily a physical act. That is, you can reach your users through snail mail, posters, email, a recorded message, web meeting, interactive demo, a java security game, etc. Primary user education goals would include:

1) VISIBILITY – Simply put, let them know who you are.
2) ASSISTANCE – make the security group available to help the users (your clients, btw) be more secure and productive
3) REWARD – Reward users who have not only adhered to the policies but also helped to make the environment more secure
4) DELEGATE – Appoint a security liason. I choose one per remote location as well as one per business Unit.
5) ACCOUNTABILITY – Remind them of their responsibilities and the Security teams capabilities.
6) SOLICIT – Users aren’t passive participants in Security. Solicit their feedback and suggestions. What suggestions do they have for making the environment more secure? There should be a mechanism which allows *any* user to give feedback. Allow them to give this feedback anonymously, if they wish. You’ll be surprised at what you get.
7) WARN – Tell them what they should be on the lookout for (Phishing, email attachments, malicious sites, etc.)

I delegate 15% of my staff to User Education. It’s *that* important. We sponsor events, give away prizes, give yearly awards, maintain a 24×7 message board, etc. Your dedicated User Education staffers should be highly creative. Don’t tuck them off in a corner. Make yourselves visible and approachable, it’ll pay off in big ways.



Why Security tools are like pr0n to the Security Professional

I love the technical end of Security. Coming from a mathematical background, I crave that buzz that comes from proving a tough theorem. In Security, there is nothing that really matches the buzz of reversing a tough binary, or figuring out some undocumented protocol with nothing but blackbox fuzzers and a packet sniffer, or writing that fuzzer that generates an exception in some popular app. Security research is sexy, fun and stimulating. At the same time, it doesn’t often impact the bottom line (or goal) of a more secure network. It’s mental masturbation – fun, habit-forming, sometimes beautiful but meaningless shortly after complete.

Now, all of this uber-technical research leads to … well, it leads to uber-technical security tools. Cool tools – Star-Trek-Cool or Matrix-Cool. We have tools which mimic the human body and tell us when an anomaly occurs within a TCP session, or when a kernel call was followed by some other call which had not been modelled into the norm. We have tools which automatically shut down attacks based on some learned or programmed behavior. We have tools which exploit a flaw and then drop a shell, allowing the clueless user to initiate a second scan from the exploited machine. I could go on and on. We have a veritable CRAPLOAD of tools. We buy these tools, rush them home to our shiny network, deploy them, and at the end of the day there is no discernible increase or decrease in Security Posture. It doesn’t take a Phd in Statistics to tell us that the tools are (at best) a marginal help. They make us *feel* more secure without actually being more secure. Are the tools useless? Some of them are. Are the tools either used wrongly or used at the wrong time in the Security cycle? Many times, yes.

The problem is that the really useful security applications have already been discovered, marketed, and sold. Firewalls, vulnerability scanners and anti-virus are largely useful tools, but that market is already saturated. So, we get these over-engineered, marginally useful security tools. Many vendors would have us buy a tool for it’s technical aesthetic value. Many of these tools are breathtakingly spectacular, complex, and elegant. We, the geeks, gather around a console at SANS, blackhat, or some other show and catch a chubby watching all that arousing, binary pr0n. And, at times, I nearly succumb and buy the product just to reward the original thought and sheer beauty of the engineering. But, I won’t buy a jigsaw if I need a hammer and neither should you. Art is art and a tool is a tool and rarely the two shall meet. A tool should serve a purpose – a specific purpose relative to your infrastructure and policy.

FOCUS. Are you with me? The goal of a Security Professional should be to (here it comes) increase the level of security on the network. As I mentioned in a prior post, securing a network can be as simple as creating, communicating, and enforcing a specific corporate policy. Increased compliance implies an increase in my security posture. The tool(s) that I deploy will be designed to increase compliance with policies and standards.



Empowering yourself to not be an event-driven Security Guy/Gal in 2006!

Hi there. My name is Dmitry. That’s not my real name, but that’s OK. I have more than 10 years of experience in IT Security. I’ve worked for or consulted with many, many large organizations. There are tons and tons of blogs that are dedicated to ‘Security Research’. These blogs, while technically very interesting (to the point of distraction, actually), don’t really help anyone get more secure. Or, if they do help, it’s the raw side of the 80/20 rule (i.e. teaching you to spend 80% of your time solving 20% of the problem). The purpose of my ‘blogging’ is simply to tell the truth about the current state of the Security Industry. Over the course of the next few months, I hope to enlighten at least a few readers into thinking about the difference between perceived security and actual security. So, without further ado:


I ignore XSS bugs. I also ignore most SQL Injection, HTML Injection, header-injection, directory traversal, file upload, and other flaws. In 6 years, the network that I protect has only had two (2) compromises. And, to put things in perspective, the network has 90,000 internal nodes and roughly 400 external IP addresses (DMZ addresses). My budget last year was roughly 3 Million dollars (not a lot, given a staff of 12-15 full timers as well as contractors and part-timers).

You might think that I have a ton of neat toys that keep us safe? Nope. In fact, I don’t have *any* gee-whiz technology. I shun them (more on that later). There is no IPS on my network. I don’t have any software which automatically quarantines worms or trojans. I’m not running host-based anomaly detection. In short, I don’t stay safe by spending millions of dollars on network security equipment and software.

So, maybe I have a crack staff of reverse engineers, TCP/IP ninjas, shellcoders, and vulnerability experts? Nope. The average employee age is 40+. Most of the Security personnel are older IT personnel culled from disparate groups (Mainframes, Rexx programmers, EDI, Sys Admins, HR, Corporate Security, etc.). In short, our technical expertise is probably considerably lower than most other (similar) groups.

Given all this, I’m still not surprised that we have better Security than most other Fortune 100 companies. What’s our ‘magic formula’? It’s easy. We have a strong POLICY and we effectively COMMUNICATE and ENFORCE the policy. This doesn’t mean that we’re policy whores, quoting ISO17799 like its the infallible word. We created a policy which matches our business drivers and infrastructure. Period. It works for us. It might not work for any other single company but it works for us. And, at the end of the day, RESULTS are worth a ton more than INTENTIONS.

In the weeks to come, I hope to enumerate on some “Computer Security Fallacies” (TM)…or, commonly accepted methodologies which are inherently prone to failure. To wrap up this Introduction, I’d like to say that if you don’t have a custom POLICY which has been COMMUNICATED and is being ENFORCED, go ahead and stop reading about that XSS flaw which affects maybe 20 users worldwide. Throw away that stack of vendor slicks. Stop sorting your IDS logs. You’re fussing over a scrape on the knee and ignorning a sucking chest wound.