Blog Moved

I've moved my blog to a new location. If you want to learn the latest in the human issues of information security, including building an effective security awareness program, please visit me at the URL below.

http://www.securingthehuman.org/blog

Thanks!

lance

Going Geeky

Every now and then its good to get back to one's geek roots and learn a new technology or two. I've been spending my Christmas and New Years break learning two new controls. First I've been playing with Sguil, a console based system for Network Security Monitoring, a concept that security professional Richard Bejtlich is a big supporter of. Richard has a tremendous amount of experience in this field, so I really respect his opinion. What I like about this tool is it works on the assumption that IDS solutions such as Snort are an indication of something is wrong. Sguil bundles the rest of the tools necessary to quickly dig in more details on specific alerts, including analyzing sessions and pcap analysis. This allows you to learn more about events and truly confirm what happend. Version 0.7 is due out in February and I look forward to playing with this updated tool. One big down side is the installation and configuration process is very time consuming and complicated. However the new version appears to address these issues. I applaud the team's Open Source efforts.

The second tool I'm working on SELinux, primarily on Red Hat Linux / Fedora and derivatives. SELinux is an extremely powerful and flexible Mandatory Access Control List solution, simiar to tools such as systrace but much more flexible and complex. I am extremely excited about SELinux in that its a control designed to protect against unknown vulnerabilities, personally one of my biggest concerns. It operates under the concept of least privileges. Learning SELinux is almost like learning a programing language. There are a variety of GUI based tools to help but I prefer command line. Often servers do not have a GUI installed, also command line gives you a better understanding of what is happening.

In the coming weeks I'll share with you my thoughts and experiences with these tools.

Cyberwarfare and History

I am personally fascinated with Cyberwarfare, not only from a professional point of view but an academic one. The influence of technology on warfare has always fascinated me. In fact, Military History was my major in college (I was especially fascinated with the 1600-1800’s). Then, after I got my degree in History I spent four years as a tank officer in the US Army’s Rapid Deployment Force. Combined that with my passion for information security (I’ve been doing it for ten years now) and you begin to understand my interest. After reading several excellent blogs and articles on Cyberwarfare I got my creative ideas flowing. There are some fundamental issues here that really concern me.

1. First, I really think the organizations that can adapt most easily to Cybewarfare are intelligence organizations. Cyberwarfare is about information, intelligence is about information. If you want to take out a computer, you have to know things about that computer. If you want to infiltrate networks, you have to know things about the network. If you want to steal or modify data, you have to know things about that data. This is going to be hard for combat arms folks to deal with, for example people who fight on tanks or from jet fighters. Those folks are taught to blow things up as fast as possible and as violently as possible. See target, destroy target. In the cyber world there is often nothing to blow up. In fact, when you have achieved your goal and you have successfully attacked your target, you often don't want the enemy to know it. Also, in combat arms you are trained that their is a definite beginning and definite end, which brings me to my second point.
2. Just like in intelligence, in Cyberwarfare there is no beginning or end, just levels of intensity. We are already fighting a global Cyberwar. Its not officially declared, there are no official sides, but its already happening and will continue to happen. There may be times when conventional warfare is fought along with it, but Cyberwar is here and now. In fact, many people today view Cyberwarfare as supporting conventional war, but I feel in the future it may be the other way around, conventional weapons will be supporting Cyberwarfare.
3. Last, I really think things are going to get messier. There have already been several well written articles about the ‘asymmetric’ approach of Cyberwarfare. How one side can attack and there is nothing for the defender to strike back at. There have also been discussions on how Cyberwarfare is the great equalizer. What value are having 12 aircraft carrier groups when someone with a 128Kbps connection to the Internet can theoretically shut those systems down, or the systems supporting the carrier groups. As I said, I think things are going to get worse. Historically there has been one thing constant in warfare since the dawn of time, mercenaries. Soldiers for hire to the highest bidder. Now a third world country can theoretically take out a first world country, not because they have the weapons or expertise, but simply because they happen to have a big bank account at that time and can hire some talent to do the job. The talent for hire is already out there, the underground cyber/criminal economy. The question is, what nations are now taping into that talent not from crime, but to get the jump ahead in Cyberwarefare. Think about it, what better way to hide your Cyberwarfare/intelligence attacks then make it look like common cyber crime.

Definitely interesting times ahead, times that are going to radically change military history. And you thought the Roman legion, longbow, the Minnie ball, and the airplane radically changed warfare :)

ROSI

The folks at Intel posted a very interesting paper on ROSI (Return on Security Investment). As I mentioned in my blog on metrics, trying to determine your value for your security investment is very difficult. Some may argue its not even possible. What is so interesting with the Intel report is its both easy to read and its based on past implementation. In other words, they talk about what they did. I think this paper is a wonderful start. However, I'm not sure just how effective the method would be. Overall their approach is you measure all the incidents that happened in the past (they used two years of data), estimate the average cost per incident and then total up the total cost. Then implement your security controls and measure how many incidents you have. The delta is your savings. While a very effective starting point, I have several questions I can't figure out.

1. What happens with this method when your new security program mitigates incidents you never detected in the first place? For example, lets say you counted 400 incidents in your organization last year, but there were really 500. When you implemented your new security measures your incidents drop to zero. Your delta is off by 100 incidents. I'm nit picking here, but your security program actually has far greater ROI. The reason I'm concerned about this is because a good security program mitigates threats/vulnerabilities you did not know about.
   
2. However, what I'm even more concerned about is good security includes good detection. Now, what happens if you start with 400 incidents, then implement security controls which includes good detection. Now all of the sudden you are detecting many more incidents you never would have detected before. Even though the total incidents could have gone down, because of your improved detection capabilities management perceives they have gone up.
   

I commend Intel for what appears to be a great start. However, I just can't believe ROSI is as simple as counting incidents and measuring deltas. Just look at TJX, all they have had is just one security incident in the past 3 years (that we know about).

Metrics - The Puzzle

Security metrics is something I'm having a growing interest in, for several reasons. First, its important to be able to justify the return on investment. If you can't demonstrate value of security, why should anyone implement it? Second, being a security professional I would like to know if what I'm doing is having an effect. Is there anything I can be doing different to improve my approach? Continuing my slug fest of attempting to read (and understand) NIST's SP800 series documentation, I was quite surprised to see alot of value in the SP800-80 "Guide for Developing Performance Metrics for Information Security". As with most of the SP800 papers, you have to fight your way through the government speak and academic noise. I really think you can easily cut many of the SP800 papers by at least 50%. For example, in SP800-80 you have to go through 20 pages before you get to the good stuff. However, there are two key things I REALLY liked about NIST's metrics paper.

1. First, they break metrics down into 3 different categories. This is something I never thought of, there are big differences between areas that can be measured. These are identified on page 15 as follows:

• IMPLEMENTATION: This is the one that I see most commonly used, but I feel has the least value. It tracks how much as been done. For example, how many accounts have a unique identity tied to it, how many desktop computers have been configured to a security standard, or how many end users have received security awareness training.
  
• EFFECTIVENESS: Now this is where the rubber meets the road and things get harder. How do you demonstrate the effectiveness of your security? This is what interests me the most also, what can I do to improve?
  
• IMPACT: For a NIST document, I was impressed to see this metric definition. It is the attempt to measure the impact to your business, your ROI. As discussed on various other blogs and publications, this is easily the hardest thing to measure. In fact, it is often argued if security can even be considered ROI, or is it simply loss prevention.
  

2. The second thing I liked were the examples in the appendix. If SP800-80 only broke down metrics into three categories, I would not have been overly impressed. Where the magic happens is they have examples of these metrics in the 18 different control domains identified in SP800-55 (IS0 27001/AnnexA has 11 such control domains). In addition, what I found very helpful was each security domain not only has metrics, but the overall strategic goal and information security goal of the controls.

All in all, I found this to be one of the most helpful SP800 documents I have read so far for ISMS approach. Even though its FISMA specific (as all SP800 documents are) it can apply to other models as well. However, if you are short on time I suggest skipping all the noise and going straight to the appendix on page 22 where the examples are. That is the true value of this document.

FISMA vs. ISO 27000

I've been working lately with security models, specifically how you strategically approach security in organizations. Models such as FISMA/NIST and ISO 27000 (just two of many) are designed to help organizations approach this complex problem. After working with these two I wanted to share some observations and comparisons of these and perhaps get your perspective. Just some quick background. FISMA is actually not a model but a law passed in 2002 requiring US government organizations to implement certain information security standards. NIST defines those standards through documents, such as the SP800 series (of which there are over a hundred). ISO 27000 is originally based on the British Standards Institute BS7799 (parts 1-3). ISO now manages this model and standardized the 2700X numbering system.

Readability: First, how easy is it to read and understand the overall documentation and model? ISO 27000 wins this hands down. First, its ordered in a relatively easy to understand fashion. You start with 27001 which is the overall plan (called an ISMS). You then move onto ISO 27002 which gets a bit more detailed (controls, but at a high level). You then have several other 2700X documents to help you (such as with risk assessments). These have not been officially approved yet by ISO. FISMA unfortunately is much more haphazard. NIST has just published SP800-39 to help give an overview, but then you also need to read FIPS-199 and FIPS-200. There are also various other SP800 documents you can read to help get things started. The other problem is how they are written. I'm sure the fine folks at NIST meant well, but their documentation is written in painful government/academic speak, something I've never worked well with. ISO 27000 in comparison is written from a business perspective, much simpler and cleaner. ISO 27000 wins here hands down.

Availability: Okay, this is where NIST shines. Everything is organized by one organization, at one location, and its all for free! ISO 27000 on the other hand, while developed and approved by ISO, is not for free. Each ISO document costs several hundred dollars and can be purchased at various locations (I find the ANSI site to be the cheapest, its in American dollars :). NIST wins this one.

Strategic: This is where I really like ISO 27000. ISO 27001 focuses on how you will manage your strategic security plan (Plan, Do, Act, Check), ISO 27002 is your strategic plan. The NIST documentation simply jumps right in and has you start with IMPACT assessments on your information and information systems. They call it their Risk Management Framework, but its not. There is no analysis of risk, only impact. There doesn't seem to be any real high level plan, strategic goals, organizational reviews, etc. Its confusing and too tactical focused. Its also highly structured, its almost as if the authors do not trust the security professionals involved. ISO 27000 gives much more trust and flexibility. ISO 27000 wins this one.

Tactical: This is where I think NIST shines. While I'm not impressed by its strategic approach, it has a wealth of tactical knowledge. There are numerous SP800 documents (almost a hundred) that focus on just the technical details and recommended controls, such as mobile forensics, intrusion detection systems, or wireless. These standards can greatly help organizations. Also, NIST is just now kicking off their checklist series of documentation. The US government is moving to standardized, secure builds. While the concept of standardize builds is not new, what makes this VERY exciting is the US government is forcing all vendors to support these builds. You want the US government to buy your software, you have to support secured systems. This has already been done for WinXP and Vista and takes effect early next year. NIST wins here.

So, overall which is better? Neither. My preference is use ISO 27000 model for a strategic approach. However, once you get into the details the SP800 series can help. However I suggest staying away from SP800-39, FIPS-200, FIPS-199 I really think that their strategic approach is taking people down the wrong path. I'm interested in your input. Let me know if you agree or disagree with this assessment, and if so why. What is your preferred model or strategic approach to information security?

Phishing in Arabic

Here is an interesting email I received last week. Its a phishing attack, but written in Arabic. The irony of this email is I received the attack while presenting at MEITSEC, one of my favorite conferences in the Middle-East. I could not resist the temptation and asked one of my friends there to help translate (I was surrounded by several hundred native Arabic speaking security professionals at the time, talk about timing). Phishing attacks in other languages is not new, but what I thought was interesting was the translation. My friends had a hard time reading the Arabic, it did not make sense to them. Instead, it looked like an email translated through Babblefish. This was most likely done by cyber criminals who do not understand the language. As the bad guys begin to exhaust the English speaking populations I'm sure they will start targeting emerging countries such as the Middle-East. I'm quite sure over time they will polish and improve their attacks on the Arabic community, just as we have seen here in the West.