Wednesday, June 4, 2008

Spliced feed for Security Bloggers Network

Spliced feed for Security Bloggers Network

ShmooCon 2008 Videos - ONLINE! [Monkey - House]

Posted: 04 Jun 2008 05:32 AM CDT

On the heels of my last post, it appears that the ShmooCon 2008 Videos have now been posted online.

Smartphone: peggio dei Laptop [varie // eventuali // sicurezza informatica]

Posted: 04 Jun 2008 03:38 AM CDT

Secondo lo studio citato in quest'articolo, gli smartphone sono ben più a rischio dei PC portatili:
NetworkWorld // Smartphones 'bigger security risk' than laptops

Numeri: 94% degli intervistati (senior IT staff, 300 intervistati) ha paura dei rischi di sicurezza degli smartphone, mentre circa l'88% si preoccupa in genere dei dispositivi mobili (laptop, mi sembra di capire).

Il problema principale é che più della metà degli intervistati non si preoccupa di mettere una password di utilizzo al dispositivo, e che nove su dieci danno accesso alle risorse aziendali senza "extra security", anche in caso di dispositivi di proprietà degli utenti.

Credant, usato e mal tollerato fra i miei colleghi - io stesso ho scelto un Nokia proprio per l'assenza del software credant a vantaggio del lock di sistema, oltre ad altri fattori - , sostiene che gli smartphone sono "facili da rubare" (come dare torto ?) e quindi buon punto di entrata alle reti aziendali.

E se un telefono é punto di accesso alla rete aziendale, benvenuti nell'era del perimetro scomparso.

Avevo considerato il problema degli smartphone già l'anno scorso (
link, pagina 12) sostenendo che i dispositivi portatili avrebbero cambiato forma e sostanza e che il rischio grosso a mio avviso é che si continua a considerarli dei "non PC". Per inciso, in azienda da me i telefoni più normali che danno sono degli smartphone con su Symbian Terza Generazione.

Links for 2008-06-03 [del.icio.us] [Anton Chuvakin Blog - "Security Warrior"]

Posted: 04 Jun 2008 12:00 AM CDT

Security - Passive versus active response [StillSecure, After All These Years]

Posted: 03 Jun 2008 11:36 PM CDT

Here at the well-heeled Gartner IT Security Conference at the brand new, spectacular Gaylord National hotel.  The hotel is only 2 months old or so, but it is supposedly the largest on the East coast and really first rate.  Also, the Gartner folks put on a first rate show, though it is on the pricey side for everyone from exhibitors to attendees. Vendors who really want to have a big presence are in for big bucks reaching a relatively small number of customers.  It was good to run into a number of StillSecure customers here at the show.  Even though we did not exhibit our presence was felt in several of the tracks discussing security solution areas that we offer products in.

While at the show I had a chance to catch up with several other security vendors.  One fellow I spoke to was Phil Neray of Guardium.  Guardium is best known for providing database security to many of the largest financial institutions and other large companies.  They recently announced a major new release of their flagship product with something they call "S-GATE". I won't bore you with all of the details but the gist of it is that for the first time database security can move from passively reporting or alerting of data access violations to actively blocking such violations. 

For me the active versus passive mode of security is one that transcends different layers of security.  Whether we are talking about IDS passive response versus IPS active response, vulnerability scanning passively assessing and reporting to NAC testing and blocking access, to now database access, ultimately security follows a similar route. First comes the ability to actually detect.  Often times the ability to detect is a major step up from what was available before.  The next evolutionary phase is to be able to prevent or block the dangerous or malicious event from taking place.

This active blocking mode though is often not as readily accepted at first by the market.  Everyone is always afraid of blocking the wrong user, the wrong email message or other request.  I think it is part of human nature that we inherently distrust our technology to block, always thinking it will block legitimate traffic.  This has been true in every security technology I have seen.  Eventually active response does win out, but it takes time and there are always doubters.  It will be interesting if what Guardium has done here is viewed with the same suspicions at first and than catches on or not.  We will have to watch.

Dangerous MySpace Spam [spylogic.net]

Posted: 03 Jun 2008 11:06 PM CDT

I have been doing lots of research over the last few months on online social networking sites to prepare for an upcoming talk that I am going to be giving on the latest threats to social networks...in particular MySpace, Facebook and LinkedIn.

Tonight I received new friend request from someone named "Elysabeth" in my email. Clicking on the link in the email takes you to the legitimate MySpace Friend Request Manager page which shows the below request:

Elysabeth wants to be your friend..really!

Clicking on the picture takes you to the profile of Elysabeth. Check out the picture of what the profile looks like now after clicking on the profile.

EDIT: I didn't edit out the MySpace profile URL in the picture so don't hit up the URL and click on anything if you don't want to risk being infected!

Notice anything strange...like the Windows Update notification pop up? Looks pretty real huh? Clicking anywhere on the first half of the page pops up the dialog you see on the right side to download a .exe file....some nice malware for you to install. Enjoy! (only on a Windows box.... :-) ) Interesting to note that by scrolling down the page past the malware banner it looks like a legitimate MySpace profile. My guess is that this profile was hijacked either through XSS or some other third-party application vulnerability...the real owner probably has no clue.

On a related note, I just read an article on how Paris Hilton Lindsay Lohan just had their private photos downloaded because of a flaw in a Yahoo/MySpace widget. Looks like Yahoo/MySpace fixed this pretty flaw quickly tonight but it goes to show that third-party applications and widgets are another popular attack vector.

One more update...Mediaphyter posted a link tonight on the 10 Social Networking Security Trends To Watch. A must read on the latest online social networking threats.

The Cart Whisperer nominated one of MarketingSherpa's Top 10 Viral Campaigns for 2008 [Tim Callan's SSL Blog]

Posted: 03 Jun 2008 07:18 PM CDT

I think the headline says it all. MarketingSherpa has selected Liberty Fillmore and his avocation of cart rescuology as one of the ten viral campaigns in its Hall of Fame 2008.


In other news, Liberty Fillmore the Cart Whisperer is back in his latest film. Be sure to check it out.

Metasploit.com Attempted Hijack [spylogic.net]

Posted: 03 Jun 2008 06:00 PM CDT

This past Monday, some silly hacker got the idea that he could easily redirect traffic from Metasploit.com to some Chinese forum using some ARP poisoning directed at the router that the metasploit.com domain resides. Basically he did a MITM attack. Here is an excerpt from HD Moore's reply on the Full Disclosure mailing list:

"Problem solved. Someone is ARP poisoning the IP address of the router on which the www.metasploit.com server resides.
I hardcoded an ARP entry for the real router and that seems to solve the MITM issue. It doesn't help the other 250 servers
on that network, but thats an issue for the ISP to resolve..."


Sucks to be those other 250 servers! This hacker should have brought his a-game if he really wanted take on HD Moore...FAIL!

Security Will Not End Up In the Network... [Rational Survivability]

Posted: 03 Jun 2008 04:19 PM CDT

Secdeadend It's not the destination, it's the journey, stupid.

You can't go a day without reading from the peanut gallery that it is "...inevitable that network security will eventually be subsumed into the network fabric."  I'm not picking on Rothman specifically, but he's been banging this drum loudly of late.

For such a far-reaching, profound and prophetic statement, claims like these are strangely myopic and inaccurate..and then they're exactly right.

Confused?

Firstly, it's sort of silly and obvious to trumpet that "network security" will end up in the "network."  Duh.  What's really meant is that "information security" will end up in the network, but that's sort of goofy, too. You'll even hear that "host-based security" will end up in the network...so let's just say that what's being angled at here is that security will end up in the network.

These statements are often framed within a temporal bracket that simply ignores the bigger picture and reads like a eulogy.  The reality is that historically we have come to accept that security and technology are cyclic and yet we continue to witness these terminal predictions defining an end state for security that has never arrived and never will.

Let me make plain my point: there is no final resting place for where and how security will "end up."

I'm visual, so let's reference a very basic representation of my point.  This graph represents the cyclic transition over time of where and how we invest in security.

We ultimately transition between host-based security, information-centric security and network security over time. 

We do this little shuffle based upon the effectiveness and maturity of technology, economics, cultural, societal and regulatory issues and the effects of disruptive innovation.  In reality, this isn't a smooth sine wave at all, it's actually more a classic dampened oscillation ala the punctuated equilibrium theory I've spoken about before, but it's easier to visualize this way.

Youarehere_3

Our investment strategy and where security is seen as being "positioned" reverses direction over time and continues ad infinitum.  This has proven itself time and time again yet we continue to be wowed by the prophetic utterances of people who on the one hand talk about these never-ending cycles and yet on the other pretend they don't exist by claiming the "death" of one approach over another. 
 

Why?

To answer that let's take a look at how the cyclic pendulum effect of our focus on security trends from the host to the information to the network and back again by analyzing the graph above. 

  1. If we take a look at the arbitrary "starting" point indicated by the "You Are Here" dot on the sine wave above, I suggest that over the last 2-3 years or so we've actually headed away from the network as the source of all things security.   

    There are lots of reasons for this; economic, ideological, technological, regulatory and cultural.  If you want to learn more about this, check out my posts on how disruptive Innovation fuels strategic transience.

    In short, the network has not been able to (and never will) deliver the efficacy, capabilities or cost-effectiveness desired to secure us from evil, so instead we look at actually securing the information itself.  The security industry messaging of late is certainly bearing testimony to that fact.  Check out this year's RSA conference...
     
  2. As we focus then on information centricity, we see the resurgence of ERM, governance and compliance come into focus.  As policies proliferate, we realize that this is really hard and we don't have effective and ubiquitous data classification, policy affinity and heterogeneous enforcement capabilities.  We shake our heads at the ineffectiveness of the technology we have and hear the cries of pundits everywhere that we need to focus on the things that really matter...

    In order to ensure that we effectively classify data at the point of creation, we recognize that we can't do this automagically and we don't have standardized schemas or metadata across structured and unstructured data, so we'll look at each other, scratch our heads and conclude that the applications and operating systems need modification to force fit policy, classification and enforcement.

    Rot roh.
     
  3. Now that we have the concept of policies and classification, we need the teeth to ensure it, so we start to overlay emerging technology solutions on the host in applications and via the OS's that are unfortunately non-transparent and affect the users and their ability to get their work done.  This becomes labeled as a speed bump and we grapple with how to make this less impacting on the business since security has now slowed things down and we still have breaches because users have found creative ways of bypassing technology constraints in the name of agility and efficiency...
     
  4. At this point, the network catches up in its ability to process closer to "line speed," and some of the data classification functionality from the host commoditizes into the "network" -- which by then is as much in the form of appliances as it is routers and switches -- and always will be.   So as we round this upturn focusing again on being "information centric," with the help of technology, we seek to use our network investment to offset impact on our users.
     
  5. Ultimately, we get the latest round of "next generation" network solutions which promise to deliver us from our woes, but as we "pass go and collect $200" we realize we're really at the same point we were at point #1.

'Round and 'round we go.

So, there's no end state.  It's a continuum.  The budget and operational elements of who "owns" security and where it's implemented simply follow the same curve.  Throw in disruptive innovation such as virtualization, and the entire concept of the "host" and the "network" morphs and we simply realize that it's a shift in period on the same graph.

So all this pontification that it is "...inevitable that network security will eventually be subsumed into the network fabric" is only as accurate as what phase of the graph you reckon you're on.  Depending upon how many periods you've experienced, it's easy to see how some who have not seen these changes come and go could be fooled into not being able to see the forest for the trees.

Here's the reality we actually already know and should not come to you as a surprise if you've been reading my blog: we will always need a blended investment in technology, people and process in order to manage our risk effectively.  From a technology perspective, some of this will take the form of controls embedded in the information itself, some will come from the OS and applications and some will come from the network.

Anyone who tells you differently has something to sell you or simply needs a towel for the back of his or her ears...

/Hoff

ISSA European Security Conference [varie // eventuali // sicurezza informatica]

Posted: 03 Jun 2008 04:12 PM CDT

As many of you know, I am one of AIPSI, the Italian ISSA Chapter founders and i'm glad to announce, this year again we decided to host the ISSA European Security Conference in Rome! There will be top level representatives from the industry and associations, as well as vendors and technology users. I'm also glad Howard Schmidt accepted to open the event with a keynote. Don't miss the opportunity if you want to spend some time in Rome. Registration's free and we still have seats available. I'll be the morning chairman introducing the speakers, and I'll be glad to meet many of you.

Link: [Agenda] [Registration], June 11th in Rome

Come molti sanno, sono uno dei soci fondatori di AIPSI, il Capitolo Italiano di ISSA, non posso che essere lieto di annunciare che anche per quest'anno abbiamo deciso di tenere, in concomitanza con Infosecurity Roma la annuale ISSA European Conference. Avremo speaker di livello altissimo come sempre, provenienti dal mondo istituzionale, vendor ed utilizzatori di tecnologia.Anche quest'anno sono felice che la Howard Schmidt abbia accettato di aprire la manifestazione con una Keynote. Come di consueto sarò il chairman della mattinata e presenterò i vari relatori, ovviamente mi fará molto piacere conoscere molti di voi come succede sempre in queste situazioni!

Link: [Agenda] [Registrazione], 11 Giugno a Roma

The Good (Yes, Good) And Bad Of PCI [securosis.com]

Posted: 03 Jun 2008 02:05 PM CDT

I’m still out at SANS, in a session dedicated to PCI and web application security.

Now, as you readers know, I’m not the biggest fan of PCI. The truth is (this is the “bad” part) it’s mostly a tool to minimize the risk of the credit card companies by transferring as much risk and cost as possible to the merchants and processors.

On the other hand (the “good” side), it’s clear that PCI is slowly driving organizations which would otherwise ignore security to take it more seriously. I’ve met with a bunch of security admins out here who tell me they are finally getting resources from the business that they didn’t have before. Sure, many of them also complain those resources are only to give them the bare minimum needed for compliance, but in these cases that’s still significant.

When it comes to web application security, it’s also a mixed bag. On the “good” side, including web application defense in section 6.6 is driving significant awareness that web applications are a major vector for successful attacks. On the “bad” side, 6.6 places code review and WAFs as competing, not complementary, technologies. These tools solve very different problems, something I hope PCI eventually recognizes. I don’t totally blame them on this one, since requiring both in every organization within the compliance deadlines isn’t reasonable, but I’d like to see PCI publicly recognize that the “either/or” decision is one of limited resources, not that the technologies themselves are equivalent.

One take-away from the event, based on conversations with end users and other experts, is that WAFs are your best quick fix, while secure coding is the way to go for long-term risk reduction.

Making The Move To Multiple Browsers [securosis.com]

Posted: 03 Jun 2008 01:42 PM CDT

For a while now I’ve been using different web browsers to compartmentalize my risk. Most of my primary browsing is in one browser, but I use another for potentially risky activities I want to isolate more. Running different browsers for different sessions isolates certain types of attacks. For example, unless someone totally pwns you with malware, they can’t execute a CSRF attack if you’re on the malicious site in one browser, but using a totally separate browser to check your bank balance. Actually, to be totally safe you shouldn’t even run both browsers at the same time.

Last night I was talking with RobertRsnakeHansen of SecTheory about this and he finally convinced me to take my paranoia to the next level.

Here’s the thing- what I’m about to describe may be overkill for many of you. Because of what I do for a living my risk is higher, so take this as an example of where you can take things, but many of you don’t need to be as paranoid as I am. On the other hand, Robert is at even higher risk, and takes even more extreme precautions. I also purposely use a combination of virtualization and browser diversity to further limit my exposure. In all cases there are completely different applications, not just instances of the same platform.

My web browsers break out like this. I won’t list which specific browsers I use except in a few cases:

  1. Everyday browsing: low risk, low value sites. I use one of the main browsers, and even use it to manage my low value passwords.
  2. Everyday browsing 2: slightly higher risk, but even lower value. Basically, it’s the browser in my RSS reader.
  3. Blog management: a third browser dedicated to running Securosis. This is the bit Robert convinced me to start. I use it for nothing else.
  4. Banking: Internet Explorer running in a Windows XP virtual machine. I only use it for visiting financial sites. To be honest, this is as much a reflection of my bank’s web app as anything else. I can deposit using my scanner at home, but only in IE on Windows.
  5. High risk/research: a browser running in a non-persistent Linux virtual machine. Specifically, it’s Firefox running off the Backtrack read-only ISO. Nothing is saved to disk, and that virtual machine doesn’t even have a virtual hard drive attached.

This setup isn’t really all that hard to manage since it’s very task-based. Now the truth is this only protects me from some (major) web based attacks. If my system is compromised at the host OS level, the attacker can just capture everything I’m doing and totally own me. It doesn’t prevent the browser from being that vector, so, like everyone, I take the usual precautions to limit the possibility of malware on my system (but no AV, at least not yet).

For average users I recommend the following if you don’t want to go as far as I have:

  1. One browser for everyday browsing. I like Firefox with NoScript.
  2. Another for banking/financial stuff.
  3. If you go to “those” sites, stick with a virtual machine. Oh, don’t pretend you don’t know what I’m talking about.

Logging Poll #8 Analysis: Needed Log Context [Anton Chuvakin Blog - "Security Warrior"]

Posted: 03 Jun 2008 10:38 AM CDT

In my poll #8, I  asked a question: what information is most important when analyzing a particular log record. Live results are here and final count is also below:

poll-context-results

What can we conclude?

First, good documentation never hurts :-) - indeed, the most popular information to look for when facing a new log record is documentation on what it means. While some software vendors are great in this regard, many other don't bother documenting their logs or document them only when customers complain.

Second, I was not sure that the second popular choice would be "Other logs from about the same time (this and other systems)."  This strongly points at huge value of cross-device log analysis (see this recent log entry on that),  where all the logs are consolidated and analyzed together (it goes without saying that time is synchronized OR at least corrected across those logs). Indeed, if you are confused about a log and documentation is not available, reviewing "what else was/is going on?" is smart. Trusting log time stamps across many systems is also key for that.

Third, having IP addresses in logs is great, but human-readable names are better: IPs in logs needs to be mapped to DNS or Netbios names. Indeed, given that often such names reveal where the system is, who might own it, what its function is, etc this information is not just a mapping, but true log information enrichment.

Fourth, so, what's next? The above 3 top responses are indeed universally useful, but the next choice digs deeper: flows, packets, connections and other network information does complement logs and is often studied in combination with logs (e.g. see a strange log entry then go see who connected to the system at that time or where the system itself connected to).

Fifth, next comes a group of pretty much everything else: other logs from the same system, logs about the same system as well as loosely defined 'similar' log entries. These come handy, but are not top choices. In fact,  from this I conclude that a lot of additional context information is needed to make sense of a confusing log entry.

Sixth, what was surprising? I thought that identity lookups (e.g. IP to real name or other user identity information) would score higher.  I also suspect that people were confused by "logs ABOUT the same systems" (what I meant is, for example, use firewall logs that mention the system which log we are now analyzing) and this should score higher.

Seventh, anything fun in the "Other" category? Yes, there were a few insightful ones: first, results of a Google search (supposedly for the info from the log entry in question)! Very true indeed. Also named were logs from the same daemon/program (how can I miss it?),  logs from previous incidents and information on the logging system owner.  All very useful indeed. Thanks for good ideas!


Finally, a brief message to people that work for a certain log-related vendor of ill repute who keep polluting my polls: if I catch you, I will kick you in the butt :-) Or, better, I will hammer you with a big and heavy log (you know, the wooden kind) over your miniscule heads ...

 

Past logging polls and their analysis:

  • Poll #7 "What tools do you use for Windows Event Log collection?" (analysis)
  • Poll #6 "Which Logs Do You LOOK At?" (analysis)
  • Poll #5 "What are your top challenges with logs?" (analysis)
  • Poll #4 "Who looks at logs in your organization?" (analysis)
  • Poll #3 "What do you do with Logs?" (analysis)
  • Poll #2 "Why collect logs?" (analysis)
  • Poll #1 "Which logs do you collect?" (analysis)
  • New Love Malware Outbreak [Commtouch Café]

    Posted: 03 Jun 2008 02:03 AM CDT

    Commtouch detection team identified a new email-borne malware outbreak yesterday, another in the “love” themed attacks. It is a blended threat, with simple love-oriented subjects, and within the body of the email message a hyperlink to a site that downloads a malware file - a Storm worm variant known as Zhelatin or Nuwar. Our lab [...]

    Monthly Blog Round-Up - May 2008 [Anton Chuvakin Blog - "Security Warrior"]

    Posted: 02 Jun 2008 10:54 PM CDT

    I saw this idea of a monthly blog round-up and I liked it. In general, blogs are a bit "stateless" and a lot of good content gets lost since many people, sadly, only pay attention to what they see today. This is what is driving an idiotic campaign of such "news" as "hackers increase hacking", "compliance is hard" or "awareness of virtualization grows."

    So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts and topics.

    1. First time this month, my logging polls took #1 spot!  Specifically, a controversial Windows Log Collection Poll (which is a poll #7) sits highest among the Top5 posts (closely behind are poll #6 about logs that people actually look at as well as poll #5 about logging challenges). Poll #8 analysis is coming up tomorrow, BTW...
    2. As expected, the post called "Reverse Compliance or "Logs as Proof of Incompetence?"" tops the charts as well. It is about, "reverse compliance", which is a motivation to purposefully avoid technologies that have a chance of telling you that you are NOT in compliance.
    3. My quick post on data leak 'prevention' ("In Passing on DLP") is popular as well. Indeed, DLP is a very interesting segment of security market and there is plenty of innovation happening there.
    4. ISO17799/27002 might not be hot in the US, but discussing why it is not IS indeed hot. WTH? Well, "Why Is ISO2700x Hot in UK, but Not in US?" is in Top5.
    5. Again, people googling for "open source SIEM" have pushed this post (this tiny blurb) to top5. This ancient post from 2 years ago (!) years ago explains why an open source SIEM will NOT emerge soon, if ever.

    See you in June!

    Possibly related posts / past monthly popular blog round-ups:

    Technorati tags: , , ,

    Marc Maiffret Starts Invenio Security [Security-Protocols]

    Posted: 02 Jun 2008 07:46 PM CDT

    Marc Maiffret formally of eEye Digital Security has started a new company called Invenio Security. Invenio, is a boutique security consulting firm which will provide security consulting and...

    [[ This is a content summary only. Visit my website for full links, other content, and more! ]]

    Cross-Device-Type Log Management vs Device-Specific Log Management [Anton Chuvakin Blog - "Security Warrior"]

    Posted: 02 Jun 2008 04:38 PM CDT

    Now, I have to first admit that, in general, dealing with logs on a device-specific basis is a cruel joke. What I mean here is when you gather Windows logs in one place, Linux logs in another place, database logs in yet another place; all in different formats, all in different systems not connected to each others, all managed by different people who don't talk to each other (and sometimes hate each other). Yuck! Basically, this situation is "logs at their worst": all different, all disjointed and, as a result, all next to useless.

    However, there are rare situations where you can choose device-specific log management approach (and still not look like a money- and time-wasting and idiot :-)). For example, you might be motivated by the fact that tools that can handle one specific type of log data (e.g. Windows-only, web server-only or Cisco PIX-only) are usually many times less expensive than cross-device log management tools. The table below clarifies it:

    Use Case vs Approach No log consolidation - logs remain on systems they are produced Device-specific log consolidation and analysis Cross-device log consolidation and analysis from all log sources
    Alerting based on log strings (keywords) that indicate security or operational problems Impossible or tremendously hard to manage across many systems Acceptable - alerts on each log type are handled by different teams Superior - all logs are available for analysis when the alert is triggered
    Reviewing logs for troubleshooting server problems Acceptable - server logs are sufficient for Better - one can also look at logs from other similar servers Better - but same as device-specific log analysis since only one type of logs needs to be reviewed
    Log review for compliance with PCI DSS Not acceptable - log management is mandated by Req 10 Impossible or very inefficient - as many types of log data needs to be collected and reviewed Optimal - all PCI relevant logs can be collected and reviewed in one system
    Looking for records of a specific user activity Impossible or tremendously hard since hundreds of systems might need to be searched Inefficient - several different systems needs to be accessed to review all records of user's activities (and then data needs to be manually correlated) Optimal - one query gives all traces of the user activity
    Log review for incident response or forensics investigation Impossible or tremendously hard since hundreds of systems might need to be searched for evidence Inefficient - several different systems needs to be searches for evidence and then data manually correlated Optimal - all log evidence can be found, reviewed and analyzed on one system, neither hundreds, nor several

    Also, while looking at logging tools, one needs to make a distinction between tools that can collect all sorts of logs but only allow you to analyze one log type at a time (e.g. sawmill) vs tools that can collect all sorts of logs AND allow you to analyze all of them together (e.g. LogLogic). The former tools still fall under "device-specific log management" despite their ability to gather hundreds of different log types.

    The bottom line: in most cases, cross-device, uniform log management provides huge value, especially if your motivation for log management is compliance or incident response.

    Technorati tags: , ,

    Security vs Functionality on the Banking platform [Digital Soapbox - Security, Risk & Data Protection Blog]

    Posted: 02 Jun 2008 03:19 PM CDT

    I find it very interesting how some of the larger banking sites (I'm using Bank of Antarctica as the example, but I'm sure they're not the only ones like this) go to extensive lengths to keep their online customers' data secured, yet... there are some very interesting ways to get around all the extra security.

    Let's take a real-world use-case and work it through. Say you're Joe User, and you've just opened an account at Bank of Antarctica. You're excited and can't wait to get home and use all the great features that Bank of Antarctica gives you online. You're also very security-aware (which is rare, I know, but go with me on this one) so you're looking to use as many security features as are available to you. When you login the first time, you set up your "secret questions/answers" and pick your picture for the site verification feature (you don't want to be a phishing victim, after all). You also enable the terriffic feature which requires you to set up your cell phone for SMS, so that when you want to login, or do any kind of transactions such as transfer money, Bank of Antarctica sends your phone a 6-digit SMS to use as a one-time password. So far you're psyched! Everything is working great, and you're feeling like you have a great chance of being secured.

    Your feeling of being secured is unfortunately short-lived. As you discover that Bank of Antarctica has enabled their site for your cell phone's browser (a handy little feature I think is neat!) but since the mobile-code-applet which accepts your one-time password obviously won't load well on a cell phone, that doesn't exist. So you're now down to a username and password again... you can't transfer money *outside* your own accounts though - so that helps with the nagging feeling a little. Hrmm...

    So. That fancy one-time password feature is only valid if I don't send a header that says I'm a cell phone, huh? And we all know that it's rediculously simple to fake browser headers, right?

    So - I'm not necessarily saying this is the fault of Bank of Antarctica, but... maybe an overall flaw in the system. Since we have incompatible devices all over the place we often have to resort to the lower-denominator and that, sadly, is typically devoid of features which enable security. So what do you do as the system architect? Do you disable features since you can't secure them properly, or do you just hope they're not exploited? These are some very tough choices, and often they are not driven from the security office, but rather from the business. I've said it before, we as security professionals have to understand the business lest we become background noise.

    I will pose this question for thought to the audience - What do you do if you're the systems architect? Use this use-case example of Bank of Antarctica. Do you disable mobile banking? Or do you take the risk? Are there other ways to mitigate?

    (intelligent) Thoughts are always welcome.

    So how does EV SSL protect against the classic phish? [Tim Callan's SSL Blog]

    Posted: 02 Jun 2008 02:48 PM CDT

    I recently wrote an entry in which I stated that EV SSL is a powerful mitigator against the classic phishing attack. I have received an e-mail asking me to explain how I know that to be the case. Happy to oblige.


    If you were a reader of The SSL Blog a little over a year ago when VeriSign premiered the Extended Validation SSL Certificate, you know about the Tec-Ed research. For newer readers or in case we all don't exactly remember how it went, here's a recap.

    Usability research firm Tec-Ed created a pair of usage scenarios for test subjects to go through. Each subject was asked to walk through simulated purchasing scenarios on a pair of fabricated but convincing consumer electronics online retailers. One retailer had the interface conventions on an EV certificate, while the other did not. Since IE7 was the only browser to support EV at the time, Tec-Ed performed the tests using images of that browser.

    Tec-Ed gathered feedback from the subjects about these two sites and the browser interface conventions. The full Tec-Ed writeup is here, and there were lots of interesting data the testing company found, but I'll focus on a couple of them here.

    First, 100% of test subjects noticed whether or not a green bar was present on the site. That's important because of course the green address bar is only present when an EV certificate is on the site. And that's important because the EV certificate depends on a high level of authentication that so far has proven immune to trickery by the online fraud community. Therefore the presence of a green bar is a highly visible indicator of a site's authenticity, certainly a useful tool for any participant in the online world.

    Second and more interestingly, 77% of test subjects stated that they would be reluctant to proceed on a site that had previously displayed a green bar and now no longer did so. Let me interpret this statistic and what it means. A popular bank stands up EV on its site. A certain customer (let's call him Sam) uses Internet Explorer 7 to visit this site in order to check his balance, pay his bills, make stock trades, and the like. Since 100% of site visitors notice the EV interface conventions in IE7, we can rely on the fact that Sam sees the green address bar and the name of his bank in the chrome of the browser.

    Now, one day Sam receives an e-mail that appears to be from his bank. It states that there has been suspicious activity on the account and for his own protection the account has been frozen. It includes a link he can use to unfreeze the account. In a panic Sam clicks on the link and access a Web page that appears to be from his bank, a page containing form fields asking for a his login ID and password.

    You and I know it's a phishing page. Ordinarily Sam may or may not clue in as well, but the fact that he already clicked on a link in the e-mail puts him in grave danger of falling for the rest of the scam. However, you may recall that Sam's bank has already used EV to demonstrate its identity unambiguously to him. We know from the Tec-Ed research that there's a 77% chance of Sam stopping and thinking before proceeding at this point. Before proceeding to give his login to an online criminal.

    Now, had it been a real communication from the bank (and many banks won't even send a message like this one, but let's set that aside), the bank would have included EV on the login page, and therefore Sam would have seen the green address bar he expects to see and the name of his bank at the top of his browser. And thus Sam would have been able to proceed with this business worry free.

    BayouSec This Thursday! [Alert Logic]

    Posted: 02 Jun 2008 01:24 PM CDT

      Don't forget BayouSec this Thursday at 6:30 at the Alert Logic Batcave! Farnum has lined up a speaker for us and I am really looking forward to learning about something I know little about: Speaker: Adam Pridgen Title: Reverse Engineering Software with Basic Protections More details on Michael's site here. If you are not yet a "member" of BayouSec, [...]

    Web Application Security: We Need Web Application Firewalls To Work. Better. [securosis.com]

    Posted: 02 Jun 2008 11:46 AM CDT

    Jeremiah Grossman is just finishing up his keynote at the SANS conference on web application security. Jeremiah and I have talked a few times about the future of web application security, and we both agree that many current approaches just can’t solve the problem. It’s increasingly clear that no matter how good we are at secure programming (SDLC) , and no matter how effective our code scanning and vulnerability analysis tools are, neither approach can “solve” our web application security problem.

    We not only develop code at a staggering pace, we have a massive legacy code base. While many leading organizations follow secure software development lifecycles, and many more will be adopting at least some level of code scanning over the next few years thanks to PCI 6.6, it’s naive to think that even the majority of software will go through secure development any time soon. On top of that, we are constantly discovering new vulnerability classes that affect every bit of code written in the past. And, truth be told, no tool will ever catch everything, and even well-educated people still make mistakes.

    Since these same issues affect non-web software, we’ve developed some reasonably effective ways to protect ourselves on that side. The key mantra is shield and patch. When we discover a new vulnerability, we (if possible) shield ourselves through firewalls and other perimeter techniques to buy us time to fix (patch) the underlying problem. No, it doesn’t always work and we still have a heck of a lot of progress to make, but it is a fundamentally sound approach.

    We’re not really doing this much in the web application world. The web application firewall (WAF) market is growing, but has struggled for years. Even when WAFs are deployed, they still struggle to provide effective security. If you think about it, this is one big difference between a WAF and a traditional firewall or IPS. With old school vulnerabilities we know the details of the specific vulnerability and (usually) exploit mechanism. With WAFs, we are trying to block vulnerability classes instead of specific vulnerabilities. This is a HUGE difference. The WAF doesn’t know the details of the application or any application-specific vulnerabilities, and thus is much more limited in what it can block.

    I don’t think stand-alone external WAFs will ever be effective enough to provide us the security we need for web applications. Rather, we need to change how we view WAFs. They can no longer be merely external boxes protecting against generic vulnerabilities; they need tighter integration into our applications. In the long term, I’ve branded this Application and Database Monitoring and Protection (ADMP) as we create a dedicated application and database security stack that links from the browser on the front end, to the DB server on the back.

    There are a few companies exploring these new approaches today. Jeremiah’s company, WhiteHat Security, has teamed up with F5 to provide specific vulnerability data from a web application to the F5 WAF. Fortify is moving down the anti-exploitation path with real-time blocking (and other actions) directly on the web application server. Imperva is tying together their WAF and database activity monitoring. (I’m sure there are more, but these are the web-application specific companies taking this path I can remember offhand). They are all taking different approaches, but all recognize that “static” WAFs or code scanning alone are pretty limited.

    Live at SANS WhatWorks: App Sec and Pen Testing [securosis.com]

    Posted: 02 Jun 2008 11:03 AM CDT

    I’m out in Vegas at the SANS WhatWorks Summits on application security and penetration testing. I like the format of these events, which mix a few expert talks with a whole slew of user panels. I’ve previously spoken at the DLP and Mobile Encryption Summits.

    If you’re in Vegas, drop me a line. Otherwise, stay tuned for some posts on these topics. One of the nice things about these events is there are actually power outlets for the audience; so between that and my EVDO card I can write live at the event.

    Right now I’m sitting in Jeremiah Grossman’s keynote session. His statistics on the probable number of 0-days in web applications are simply astounding. I’ve seen this content before, and it never ceases to stun me. More on that in a minute as I dedicate a post to how we need to change our perspective on web applications…

    The best laid plans....... [Andy, ITGuy]

    Posted: 02 Jun 2008 07:32 AM CDT

    Growth can hit you square in the mouth if you are not careful. Growth can even kill you if you aren't prepared for it. Growth is good but like most things it needs to happen in a controlled manner. Not an easy thing to do when you are talking about your business and the success of a plan or product that takes you by surprise, even beyond your wildest dreams. Yet without a plan to address growth, even unexpected growth it can damage your business beyond repair.

    In the last few months I've seen several incidences of growth that happened unexpectedly and quicker than expected. In many of these instances the companies have been sent reeling as their technology has not been able to keep up with the demand that is being put on it. Twitter is a perfect example. It's been around for a couple of years but as of late it has seen significant growth. Growth that it isn't prepared for. Growth that has all but taken it off line for much of the last week. Growth that may send users running to other similar services. Already within the security community there is a push to use FriendFeed as well as Twitter. Maybe even to replace Twitter.

    I have a friend who works for a company that worked for years to build a business and they did build it. It was small but growing. A few months back growth hit them suddenly and their databases had a hard time handling the new load put on them. They have had a couple of outages but more importantly they have had several features of their application quit working properly. They had not planned (nor tested a plan) to handle growth to this degree. In the past as they experienced growing pains they just dealt with/ them as they arose. Now they are faced with/ potential crisis because they can't continue to operate this way. They have to fix the problems and put into place a practical plan that will address them and prepare so that they don't happen in the future.

    With gas prices pushing $4 a gallon here in the US transit agencies are seeing big increases in riders. Many of them are experiencing growth related problems in regards to database usage, storage space, and scheduling routes for buses and trains. Increased routes means that there are more trains and buses on the road and rails that have to be tracked to ensure that they are where they need to be WHEN they need to be. Especially when dealing with trains being too early can cause real problems. Also you have to know when to stop, slow down, go and speed up. Technology is what allows the train operators know when these things need to happen. Last week Boston and Chicago (I think) both experienced passenger rail accidents. Were they due to growth issues? I don't know for sure but it's highly likely that growth did play a part in them.

    How does this relate to Information Security? It has the potential to fall under the A in the CIA triad. These issues affect the availability of services and systems and although this type of availability issues are not usually security issues they can lead to security issues. If you database is under undue stress and heavy load then it makes it more likely that someone with malicious intent can sneak in and do something that they are not usually allowed to do. While under heavy load trying to process data it may allow a window where an attacker can bypass a security measure. If your service is off line or only sporadically available it could allow for someone to impersonate you and lure your users to their site where all sorts of bad things could happen. Not to mention that when you are focused on a issue that affects your users then security often gets overlooked or ignored. You are concerned with getting back up and running even if it means that you do something insecure.

    I'm one of these who believes that information security touches EVERY part of the enterprise and needs to be included in all aspects of planning. This is just another example of how not only good business planning but also good security planning can save you lots of headaches.

    Scam Squared [Commtouch Café]

    Posted: 02 Jun 2008 07:27 AM CDT

    What do you get when a scammer scams a scammer? I guess you could call that scam squared. Perhaps there used to be honor among thieves, but not anymore. Check out this spam message targeted at, no, not unsuspecting purchasers of fake meds, but at those people who are selling the stuff! Now, it’s not so [...]

    Drive, Not Spot [Commtouch Café]

    Posted: 02 Jun 2008 07:21 AM CDT

    Blogspot has been a popular hosting site for spammers, and even malware distributors, but Arik from the detection team informs me that we are now starting to see outbreaks using hyperlinks to a different, less popular blog site, known as blogdrive. This particular outbreak uses misspelled pornographic subject lines of around four words each; it seems [...]

    Stumbling upon Security Issues [spylogic.net]

    Posted: 02 Jun 2008 05:00 AM CDT

    Seriously...I don't go looking for web site security issues or vulnerabilities but sometimes you do "stumble" upon them. :-P

    Several weeks ago I was looking for an online schedule of events at one of the local community centers where I live so I did what anyone would do and typed in the URL of the city's web site into my browser, but without typing "www" first. The actual URL starts with "www" but many times just by typing the URL without "www" will take you to the web site. So to my surprise instead of getting the main index page of the city's web site I get a web form prompting for login credentials to what looked like an HVAC system attached to the Internet! The header of the page had some information about a system version so I did what any other security guy would do and launched a Google search to find out more details about this system. Yep, it was an HVAC system alright. So I thought no big deal right....out of curiosity I hit the 'enter' key thinking that there was no way that there was an anonymous login on this baby...low and behold, it logged me in! I was able to view the HVAC system configuration and potentially manage the HVAC for not only the community center but the city hall and other facilities. Looked like I could have caused some mischievous outages like changing the temperatures and even shutting down the HVAC system. At this point many scenarios entered my head, including why someone would put an HVAC system that should be on the company "Intranet" on the "Internet" with an anonymous administrator level account...nahh...I'm a pen tester so this isn't shocking to me at all!

    Being the ethical person that I am I emailed the city that manages this domain letting them know of the issue...today a received an email that said they were looking into the issue and it should be resolved shortly. So here are the questions. What would you have done (put your non-evil hat on please...yes, methodically messing with the temperature in the mayors office would be a blast...)? Do you just forget that you stumbled upon this vulnerability or do you believe in more of a full disclosure policy to the people running the web site? In talking to some others...attempting to contact the site owners is the best option (which I agree with) yet some others may take a different approach. Some "grey-hat" hackers might even resort to causing havoc with the HVAC system just to prove a point, then disclose the vulnerability the right way. Thoughts from the community?

    Webcast June 4th: DLP Content Discovery [securosis.com]

    Posted: 01 Jun 2008 08:07 PM CDT

    Yes, it’s one of those weeks, with two webcasts and a conference (SANS Pen Testing and Application Security in Vegas).

    For this one we’ll be talking about DLP content discovery for Vontu/Symantec. It’s not just me; there will be a customer case study (yes, an honest to goodness security person willing to talk about what they’ve done). Here’s the official description, and you can register here:

    Where Is Your Confidential Data and How Do You Protect It? A Real Life Customer Success

    Do you know where your confidential data is stored and how to protect it? Industry analysts predict that data discovery will be the single fastest-growing segment of the Data Loss Prevention (DLP) market in 2008 and beyond. In this webcast, you will get the opportunity to hear firsthand how Sharp HealthCare implemented a DLP solution to secure their sensitive customer data stored across the organization, and what business results they are seeing today. Join Rich Mogull, founder of Securosis LLC and former Gartner analyst, and Starla Rivers, Technical Security Architect at Sharp, as they address how to easily deploy DLP and quickly realize the solution benefits.

    Webcast On Tuesday: Encryption And Key Management [securosis.com]

    Posted: 01 Jun 2008 08:03 PM CDT

    This Tuesday I’ll be giving a webcast for RSA on encryption and key management. It’s heavy on the data center side; focusing on SAN/NAS/Tape, Databases, and Applications. Not much discussion of mobile or email, but a bit of file and folder (server based).

    Here’s the official description, and you can register here:

    Encryption Considerations for the Enterprise

    Business Trends, Impact, and Solutions

    Government regulations and internal policies drive your need to secure information wherever it lives and travels. Get the facts on Encryption and Key Management technologies during this seminar series and Q&A featuring Rich Mogull, founder of Securosis.com, who will discuss:

    • Why encrypt data? Where to encrypt data? What are the pros and cons of different solutions?
    • What role should enterprise key management play as part of an overall encryption strategy?
    • What is the value of centralizing encryption key management?

    Emergency SunSec This Wednesday! Rothman Hits Phoenix! [securosis.com]

    Posted: 01 Jun 2008 07:57 PM CDT

    The legendary Mike Rothman will be in Phoenix this week, so we’re going to call an emergency session of SunSec on Wednesday to celebrate the occasion. Rumor is we might also have another surprise guest or two.

    I realize I’ve been a total slacker on organizing these; we really need to figure out a regular schedule at some point.

    We’ll be starting at Furio in Old Town Scottsdale for happy hour at 6 (we’ll probably head down early at 5), and possibly move someplace cheaper after happy hour ends.

    As always, email me with any questions, and we hope to see you there. SunSec is an informal gathering of anyone with an interest in security. We hang our, drink beverages, and just generally socialize.

    No comments: