Stop Listening to Security People: Focus On The Why Rather Than The What

February 11, 2009 – 1:36 pm

stoplisteningtosecuritypeople3There, I said it: stop listening to information security people. Before you fire your security vendors, disable those perimeter defenses and toss your security development processes to the fire there’s more to this story you should know.

On the front page of MSN.com this morning, there was an article entitled “Stop Listening to Suze Orman” and it reminded me of some of the cardinal lessons I learned in a past life as a semi-successful amateur day-trader (hey, I had to bootstrap my security company Impacta some way :P). For those of you who don’t know about Suze Orman, she has a show on television were people call in, explain their financial problems (stocks, real estate, retirement planning, etc.) and she offers her perspective (<– keyword, remember this for later) to callers. The MSN.com article knit picks at some of Orman’s general trading strategies and former stock picks, but if you boil this article down to the bone there’s a very important lesson to be learned here that can be also be applied to information security.

The mistake I made as a day-trader when I was first starting out was to listen to trading/investment experts. If Joe Expert said buy stock X, I would buy stock X. If that same expert said short stock Y, I would short stock Y. I soon realized that doing this was a sure path to financial disaster. First, trading/investment experts are indeed experts in their respective fields and they deserve all the successes they’ve had. However, there’s one field that they can’t be experts at: you. You see, those experts have much larger bank rolls, higher risk tolerances and much more powerful trading platforms that normal traders/investors won’t. So while they can provide a perspective that makes sense for their own situation (i.e., buy stock X), that perspective may not necessarily be the right one for you. The day that I changed my strategy and used advice from experts as a single input amongst others (my personal risk tolerances, my personal financial goals, my own research, etc.)  to make my own decisions, and not just following their advice blindly, significant successes soon followed (and a lot of them).

I suspect the same lesson could be applied to the information security industry. Take this common scenario where organizations hire security vendors who run tools and do all sorts of weird and wonderful things to uncover  all sorts of information security nasties. A report comes in and organizations blindly follow the remediation steps listed (similar to investors blindly following ‘expert’ advice). Bad idea and here’s why: those reports are based on technical findings and from the perspective of someone who is independent from your business (someone who does not understand your business). For assessing risk that’s a good thing, but when it comes to mitigating risk that’s not always the case. That technical risk perspective may not align well your particular business objectives. Often it does, but in the instances where it doesn’t bad things happen. Applications get crippled due to incompatibilities with recommended patches, money gets wasted on addressing vulnerabilities in areas of the business with lower business priority but high security priority and so on. Potential revenue is lost and the friction between security and every other business function is perpetuated.

Now, organizations are 100% entitled to address risk in whatever fashion they please. That’s not for me to say otherwise. However, what I’ve personally found useful when helping my customers address security risks to help them make better business decisions is to focus on the WHY rather than the WHAT.  When you’re presented with a slew of security vulnerabilities that need to be addressed and you don’t have infinite resources to address them all, ask yourself these helpful questions:

  1. Why does this vulnerability translate to a business risk?
  2. Why does this impacta (<– sorry, slip on my part :P) the business?

Here’s an example, say you get a report finding that says that you have a potential buffer overflow condition in your application.  That’s the what, that you have a buffer overflow condition.  Well buffer overflows are bad right?  We should spend resources to fix it.  Hold on, let’s consider the why.

  1. Why does this vulnerability translate to a business risk?: If a malicious user is able to exploit this buffer overflow, they could gain access to customer data (confidentiality), modify that data (integrity) or degrade the application to legitimate users (availability).
  2. Why does this impact the business?: If a malicious user was able to do the above actions, that could degrade our customers confidence with our service. We could also be subject to fines for not having sufficient security controls. All translates to loss of revenue.

Turns out in our example that the technical risk aligned well with the business risk, but asking questions like the above can help you better ensure that that alignment is consistently there. This small perspective shift I’ve found has been a very useful and powerful tool, and has helped me be more effective in security, trading and other areas.

Just as with investing and trading, you know you best.  Security is just one facet of your business and not the entire story. So in my experience, when you fold in business factors (the ‘why’) when addressing information security issues (the ‘what’), the better off you’ll be. What are some of the techniques that have helped you?

 –Kevin

By Kevin Lam | Posted in Risk Management, Security | Comments (19)

Impacta LLC and Microsoft Corporation work together in January 2009 to protect online customers

February 11, 2009 – 10:58 am

Once again, I am proud to announce that Impacta’s security researchers got recognized again by Microsoft Corporation for helping Microsoft make their online services safer by finding and reporting security vulnerabilities for the month of January 2009.  Impacta has been continually recognized by Microsoft month over month since 2007, and we look forward to continuing our work with Microsoft in 2009.

See Microsoft’s online security researcher acknowledgement page for more information.

–Kevin

By Kevin Lam | Posted in News | Comments (1)

The Dangers of Online Banking: How to Separate the Wheat from the Chaff

February 3, 2009 – 1:13 pm

dangersofonlinebankingscreenshotI opened up my Web browser this morning and on the front page of MSN.com (yes, yes … I confess my default homepage is still set to MSN) was this article about the dangers of online banking. The article was pretty well written, and it brought to light some very practical things people can do to better protect themselves from online threats later in the article. Being in the business of professionally assessing the security of all things online, I’ll be the first to admit that there are indeed risks to online banking (trust me on this one >:P). However, how this article came to that conclusion is what I found a little misleading, and if we go back to our framework for thinking about security in terms of people, process and technology I think there’s a very simple and valuable lesson here on how to quickly make sense of the information (good and bad) that we’re fed about information security. If you’re a home user, it might help you not get suckered into buying and wasting money on some ‘miracle security product’ out of fear, uncertainty and doubt (FUD), or if you’re a CIO, CSO, security manager or otherwise, maybe it will help you not get duped by shady security vendors. Whatever your case may be, I hope this helps.

Onto the article. The position of the article is that online banking can be dangerous, and stories about users get their accounts compromised are discussed to set the stage for further discusion. Here is an article snippet which describes how Joe Lopez’s bank account was compromised and temporarily had to the tune of $90k stolen from it:

What he didn’t realize were the risks (of online banking). A malicious virus had infected his computer and, in a matter of minutes, captured his user name and password — allowing a hacker to transfer $90,348 to a rogue overseas account.

Did you catch it? Did you see what was wrong with the above? If not, see if you can see the problem with this next article snippet which describes another victim named  Mia Joswick who fell prey to a phishing scheme that was impersonating her bank and on top of getting her account compromised, also had her identity compromised (since her password was her social security number):

Mia Jozwick, a student at Wagner College in New York City, was duped by a “phishing” e-mail made to look like a message from her bank. Thinking it was an important financial notification, Jozwick responded by firing off her user name and password; she learned it was a scam only after someone emptied her account.

Hopefully you caught the problem that time. If not, read on.

Here’s what I think is wrong with parts of this article and the way it concludes that online banking is dangerous. Let’s concede for a moment and assume that yes, online banking is indeed dangerous, and look at why online banking would be considered dangerous. For something to be dangerous (or insecure), usually this means that there is some potential for loss (risk), and that the controls implemented to reduce that risk will fail in some fashion. In other words, if you can map a potential for loss (risk) in some system, to a failure in a control for that system caused by some threat agent (or hazard) that causes the loss, then you can reasonably say that using that system poses unmitigated risks or is ‘dangerous’. So for online banking to be dangerous, that means one or more control within the online banking application has to improperly fail. We can further organize this thought pattern and say that some control within the online banking application failed in one or more of the following categories:

  • People
  • Process
  • Technology

Let’s first start with poor Joe. What was the cause of his loss, or why did it happen? According to the article, it was a computer virus that was able to capture his credentials and shuttle them off to some unsavory individual who then stole his money.  Let’s work backwards a little bit. The threat agent (the cause of the loss) here in this case was technology-based (a computer virus) and the possible controls that could have reduced the risk of having Joe’s credentials stolen were:

  • People: Education not to install untrusted executables/binaries
  • Process: n/a
  • Technology: Antivirus program

Clearly there was a failure of controls on the technology and the people side since either one of these would have prevented Joe’s computer from getting infected. But let me ask you this: do these controls exist on Joe’s side, or the online banking application’s side?  The answer is Joe’s. The fact that a malicious user was able to use those credentials to steal Joe’s money is a secondary effect of the controls on Joe’s side (not the online banking application) failing. Since no control for the online banking application failed in Joe’s case, it’s unreasonable to conclude that the online banking application is dangerous to use.

Now for Mia. Same thought pattern as before. The controls that failed in her case were:

  • People: Education not to trust emails claiming to be her bank
  • Process: Validating the authenticity of the email
  • Technology: Anti-phishing software (browser, etc.)

 Again, either one of these controls could have prevented her from giving up her bank user credentials, but where was the failure? On Mia’s side, or the online bank application’s side? The answer is Mia’s. So similar to Joe’s case, the online banking application cannot be attributed to this loss and labelling online banking as dangerous based on these anecdotes is unreasonable. 

You could argue that the point of the article was really trying to say that the Web makes doing online banking dangerous, but here’s the question I would ask: If you run a red light and get into an accident, do you blame bad judgement or do you blame the road (i.e., the Web)?

Before I end off, let me at least say that the point of this post was not to slam end-users (I am glad to hear that Joe and Mia were able to recover from their losses).  It was meant to be an opportunity to share with you my thought process, and how we can use the framework of thinking about security in terms of people, process and technology to separate fact from FUD, the wheat from the chaff if you will. What are your thoughts?

–Kevin

By Kevin Lam | Posted in Privacy, Risk Management, Security | Comments (14)

Impacta LLC and Microsoft Corporation work together in December 2008 to protect online customers

January 12, 2009 – 1:46 pm

Impacta’s security researchers gets recognized again by Microsoft Corporation for helping Microsoft make their online services safer by finding and reporting security vulnerabilities for the month of December 2008.  Impacta has been continually recognized by Microsoft month over month since 2007, and we look forward to continuing our work with Microsoft.

See Microsoft’s online security researcher acknowledgement page for more information.

–Kevin

By Kevin Lam | Posted in News | Leave a Comment

Effective Malicious Hacking: Another Case for People, Process, Technology (But Not in the Way You Would Think)

January 9, 2009 – 6:49 pm

My friend emailed me today and said that her company’s IT department was warning users about a phishing email that was circulating around supposedly from IKEA. (This by the way is an example of a great IT department: they don’t rely on just technology – people and process are also part of their security solution, kudos to them!)

Spam and phishing emails are so common these days that we tend not to be surprised anymore by it, let alone inspired by it.  This time was different though. When I heard about this I mentally blurted out in my mind  “how stupid, they (the bad guys) should have sent it a week ago when IKEA was having their year end sale. It would have been much more belieavable then!” This got me thinking.

It became clear to me that while ’good’ security requires a mixture of people, process and technology (i.e., defenders), ‘bad’ security (the stuff for effectively attacking systems/people) also requires a mix of people, process and technology (i.e, attackers). In other words, the success of an attacker or defender is dependent on their ability to exploit a weakness in the other’s strategy from the perspective of people, process and technology.

Let’s take the IKEA email as an example. The phisher’s strategy looked like this:

  • People: None.
  • Process:  Traditional, click on this link to login scheme …
  • Technology: Mass mailers, open mail relays

Now pit this strategy against my friend’s company IT department strategy:

  • People: Education about email-based phishing attacks
  • Process: Education on inspecting the provided login link to see if is legitimate
  • Technology: Spam and phishing filters

Technology versus technology, the phishers won because in this instance they were able to bypass the automated mail filters. However, the phishers lost because of process versus process. My friend’s company’s education on how to inspect links for authenticity was able to uncover the phishing scheme.  Even if the process side failed, then from a people versus people perspective my friend’s company would still win because it would be their education on email-based phishing versus essentially no strategy from the phisher.

Now consider what happens if the phisher’s strategy looked like this:

  • People: Send the email right after IKEA advertises on television or some major promotion to establish context.  Say “You may have seen our TV commercials’ya …”
  • Process: Inform the user that they can print some coupons for IKEA at some third party website that is partnering with IKEA for the holiday season. At that site provide a fake coupon image (or even a copied real one) that can be printed, and indicate that they can take this coupon to a store, or click this link to login redeem it online right now.
  • Technology: Mass mailers, open mail relays

We already know that the phishers can bypass the mail filters, so technology versus technology is out the door.  Here’s where it becomes interesting. Process versus process, the phisher has a better chance now, because they are not asking the reader to click on a link to login, just to go to some website to print out some coupons (who doesn’t love coupons?). My friends’s company may have only educated their employees on phishing attacks that want you to login by clicking some link. (I highly doubt that this is the case, since they seem to be so proactive about security already, but let’s pretend for now.) Sure the site wants you to click a link to login, but this is secondary action, maybe even call it a ‘secondary phishing attack’.  People to people, the phisher now stands an even greater chance. Because they can reference something that someone may have seen on TV, what that does is it establishes context. Context leads to trust, whereas a random email out of the blue raises eyebrows.  It’s like an old girlfriend/boyfriend calling you out of the blue after 2-3 years of not talking.  Your first reaction is “what do you want?”, versus someone who you’ve seen last week “oh yeah, I remember you from last week …”.

So again, the success of an attacker or defender is dependent on their ability to exploit a weakness in the other’s strategy from the perspective of people, process and technology.  Now this might not be new to some of you, you might even be thinking “well duh” or “welcome to the 21st century Kevin”, but I think this kind of formalization and frame comparison (technology versus technology, person versus person, …) has significant benefits. It’s basically a more formal way of looking at multi-layered security strategies.

I for one am inspired.  What do you think?

 –Kevin

By Kevin Lam | Posted in Innovations Lab, Security | Comments (4)

A Tip for Getting the Assessing Network Security Book

January 9, 2009 – 3:38 pm
Assessing Network Security book by Kevin Lam, et al.

Assessing Network Security book by Kevin Lam, et al.

Hey everyone, I got several emails recently (in response to this blog posting) regarding how you can get a hold of a copy of Assessing Network Security (ISBN: 9780735620339, Microsoft Press) that myself, David LeBlanc and Ben Smith co-authored a few years back in 2004. 

  • Amazon. Amazon.com has some pretty great reviews of it, however I don’t think you can order it directly from Amazon.com anymore.  They provide some links to other resellers though.
  • Barnes and Noble. Says it’s out of stock, and also provide some links to resellers.
  • Bookpool.  Bookpool.com also says it’s out of stock as well.

Alright what now?  Here’s a little tip for getting this book if your company already has an account with Microsoft.  Ask your Microsoft account manager to order a couple copies for you internally via a tool called ‘msmarket’ (msmarket is called out publicly here on Microsoft.com, so I am not letting out some big internal secret). 

If you can get your hands on a copy, I hope you really enjoy it.  David, Ben and myself set out to write a book that was not your typical ‘hacking book’ based on exploits de jour and hacking tools, but rather on concepts, strategies and processes that are don’t expire or become irrelevant over time. While it may not be as exciting as other books on the ”lastest MS08-067 staging shellcode, exploit this, exploit that,” I think it definitely helped our readers tackle the problem of security in a more systematic, objective and sustainable way  in the long run. Looks like some of the reviewers on Amazon.com understood this vision of ours.

“The best pentesting book I’ve seen”

“An Excellent First Book on Pen Testing”

Anyways, I’ve got the writing bug again, so who knows I might get around to writing a second edition or another book one of these days. 

–Kevin

By Kevin Lam | Posted in Security | Comments (2)

Security: The Number One Technology Failure of All Time

January 3, 2009 – 4:36 pm

I was reading through an article last night about the 25 greatest blunders in technology history and was happily strolling through memory lane (what are Palm Pilots, PS/2s and Apple Newtons anyways? :p) and then got quite a surprise at the very end of the article.  The number one technology failure of all time according to the article’s author (Neil McAllister) is … security!

First off, Neil is right. From a technology standpoint, security has failed. Neil argues that technology was built on top of an already insecure foundation, and so the result of anything on top of that foundation will be anything but secure. However, I would like to present some additional reasons why security may be the biggest wet blanket of all time. Read on.

In my opinion security is not a single “thing”.  Security has to do with much more than exploited vulnerabilities, hackers, and missing patches. This beast we call security actually has three heads.  They are:

  • People
  • Process
  • Technology

It’s when all three of these work together is when security is most effective. Unfortunately, neither of these three have been playing well together lately, if ever.  Neil did a great job covering the technology piece already, so I’ll talk about the other two. Also, each one of these aspects of security is a long discussion in itself so I am just going to share what I think is the top failure in each of the two remaining categories and would love to hear your thoughts too.

My Top People Reason Why Security Fails: Security Divas

A friend of mine, Steve, put it it best one time when we were hanging out in a bar after a full day of delivering presentations. He wisely noted “Security unfortunately has become something that people try to own, not something you are responsible for or contribute to. People start thinking they are the solution, rather than part of it.” Steve wasn’t using elite-speak (by “own” he didn’t mean ”0Wn” as in compromise or gain root access on), he meant that security was something that people tried to claim as theirs, especially the successes, but none of the failures. These people tend see themselves not as a cog in the wheel, but rather they are the wheel. Their solution/service/thing-a-ma-gig as the only possible security allowed in their eyes. Any attempt not blessed by them to enhance or further security gets elephant stomped. To protect their golden egg they will set political fires behind your back and scratch and claw your face like a cornered cat. Their egos are often highly inflated and they are clouded by their own agendas.  They are the few rotten apples that ruin the rest of the basket. I call these people “security divas“.

It’s ironic that the users of security (desktop users, administrators, and grandmoms) get blamed for the failure of security. Some of the practioners (security divas in particular) could share some of that blame if you ask me.

My Top Process Reason Why Security Fails: Complexity

When I was young, I had problems with very basic math and nearly failed my first year of highschool (ironically I graduated with honors in mathematics and computer science from the University of Waterloo in Canada). The notion of negative numbers was just beyond me for the longest time. My parents would tell me over and over again “you’re making it this more complicated it has to be.” That perfectly describes today’s security processes.  Something that should be simple to solve, is over-thought and consistently complicated. “Attempt by W32.TrojanDropper.A-B/32_884.9 to access protected memory segment located at 0x45ED3FAC.  What would you like to do?” <– huh? How about letting the user know that “A compuer virus tried to infect your computer and we intercepted it, stop it or allow it to do so?” Or how about not even bothering the user at all and just taking care of it?  Give them the satisfaction that this piece of software they bought for $39.99 will make their life easier, rather than more complicated with obscure and cryptic warning messages? Today’s security processes, approaches and especially solutions etc. are often too complex and hard to use that even security experts have trouble with them. How can we then expect non-security experts to use them? Psss … those non-security experts end up not using those processes, approaches or solutions.  Start, Control Panel, Add or Remove Programs has to be one of the most common security key sequences by now.

There’s genius hidden in simplicity and my gut feeling is that someone will come up with a series of security solutions that are so simple and elegant that even if the wrong people are performing security they can still arrive at the right results. Until then, security will continue to stumble and get listed as a failure on lists such as Neil’s.

So there you have it, my top reasons for why security fails today are security divas and unnecessary complexity.  I’ll talk about my take on solutions sometime down the road. What are some of the reasons why you think security has failed?

–Kevin

By Kevin Lam | Posted in Security | Comments (17)

Impacta Donates 10% of its Profits for 2008

January 1, 2009 – 1:06 pm

2008 was an amazing year for Impacta, so I am proud to announce that we donated nearly 10% of gross profits for 2008 to local charities and organizations in and around the Seattle area, including the Seattle Humane Society. Giving back to the community has always been a key tenet of Impacta’s core values, and we look forward to giving again in 2009.

–Kevin

By Kevin Lam | Posted in Community Journal, News | Leave a Comment

“That would require me to actually care about security …”: Inspiring Words From My Developer Friend

December 31, 2008 – 7:22 pm

PinionsAt Impacta, one of the core values we have is to always innovate.  Find new, better and more creative ways to solve today and tomorrow’s online risk (security, privacy, etc.) problems. In fact, our company motto is literally ”Innovations that Inpsire” to speak to that core value. I just had one of those unexpected moments today that got the wheels turning and inspired me to think about the need for new innovation in the security space.  Read on and you’ll see why.

I was emailing an old developer friend of mine earlier today who I was asking if he had a security book that I was sure he had. We’ll call him Brad to protect his identity (call him Brad Pitt to add to the illusion and mystery if you really want). The conversation was short, sweet and inspiring:

  • Kevin Lam: “Hey Brad, do you have that book on threat modeling from way back? I need to borrow it.”
  • Brad Pitt: “Umm no (I don’t have that book). That would require me to actually care about security …”

Now, you have to understand that Brad says stuff like this all the time and we love him for it, but his comment got me really thinking: why would developers care about security? More precisely, should developers have to care about security? The answer I came to is … “no, developers should not have to care about security*” (note the asterisk, since I know this is going to ruffle a lot of feathers real soon). Let me elaborate.

Today, most security regimens looks like this. Developers need to run tools, developers need to analyze vulnerabilities, developers need to fix vulnerabilities, developers need to attend this course, developers need to this and that. 

  • Strike 1. Developers are forced to get involved and spend time on every nitty gritty detail of security, on top of their actual jobs. 
  • Strike 2. We’re also asking them to do their jobs differently than what they are used to.
  • Strike 3. Worse, instead of becoming part of the process, security is the process.

Imagine we started asking major league baseball players to catch line drives with their teeth, instead of with their gloves? That’s a little extreme example, maybe even a bad one, but you get the idea. How jazzed up would you be if someone told you this is how you do your job from now on and gave you more work? Could this be in part why some developers are so resistant to anything security related and possibly why security is still a major struggle for most organizations? Developers should be involved, but do they have to be involved in every little detail? How about engaging developers only when really necessary?

To help drive sustained adoption of security and all that good stuff, my gut feeling is that the next generation of security solutions (tools and people) need to demonstrate value by “look how much easier I (the security solution) made your (the developer) life, because I took care of the majority of work that I could do myself for you, and the few times that I had to derail you from your actual job was because I needed your expertise.” Show developers how security can be a good thing for them and the business. Contrast this value proposition to today’s which says “look how many vulnerabilities I found for you, I am not sure which one ares real and which ones are noise, but look how many I found!” (read: look how much more work is coming down the pipe for you).

I might be completely out in left field with this gut feeling of mine (heck, I may be even out in the far parking lot underneath a car) and the way that security is handled now is the way it should be (constantly butting heads, political plays to get out of fixing vulnerabilities, you versus me, cats versus dogs), but I got a good feeling. Of course I don’t have the complete answer right now, just a little spark in me that makes me think some change is needed. What do you think?

Anyhow, a little humor, a little inspiration and hopefully a lot of innovation in the coming year – what a way to ring in the New Year!  Alright, see you all in 2009 and stay safe — and of course thanks Brad Pitt!

–Kevin

By Kevin Lam | Posted in Innovations Lab, Risk Management, Security | Comments (3)

Impacta LLC and Microsoft Corporation work together in November 2008 to protect online customers

December 15, 2008 – 1:12 am

Impacta’s security researchers gets recognized by Microsoft Corporation for helping Microsoft make their online services safer by finding and reporting security vulnerabilities for the month of November 2008.  See Microsoft’s online security researcher acknowledgement page for more information.

–Kevin

By Kevin Lam | Posted in News | Leave a Comment