Archive for August, 2009

News and Commentary :: by WadeW and You (08/28/2009)

Friday, August 28th, 2009

newsI’m starting a new feature on the blog this week: “News and Commentary :: by WadeW and You“. Yes, it’s another news of the week post, but I wanted to make it something more than a collection of articles that I enjoyed or found interesting. So I decided that I would take each of the news items and provide my commentary on the article or topic in question. I’ve also made a couple upgrades to the blog, including adding DISQUS as the comment platform in hopes that YOU will also provide your commentary/insight/throw Shmoo balls/etc. and voice your opinion. So here’s to a new venture that will hopefully spur some great conversations.

http://ha.ckers.org/blog/20090824/google-safe-browsing-and-chrome-privacy-leak/
One thing that Robert doesn’t really touch on is the ethical responsibility of product and software companies. While I concede that a machine ID and a user ID isn’t much in the grand scheme of things, but it’s yet another data element that Google has tied to our identities. Since I’m an avid Google Reader user, I decided to take a peak at the ever expanding social functionality in the app to connect with a few contacts. Google kept telling me I should customize my profile, so I did. In the portion where you provide your favorite URLs, there was a list of my accounts on various other sites (Twitter, Facebook, LinkedIn, Tumblr, etc). I was a little surprised to see all that information listed right there, even though I’ve searched for my name numerous times before and have seen them returned in results. Still, I can’t help wonder why they need to track that information? And more importantly at what point is aggregating that much public information a privacy issue? Think about it, Google AdSense is on the vast majority of webpages.

http://www.cio.com/article/499829/8_Dirty_Secrets_of_the_IT_Security_Industry
Dirty little secrets? Not so much, mostly just common sense. Companies that spend money on compliance tools end up sending out mass notices to their customers to inform them that their financial information has been stolen – soon enough, that knowledge will be as common as needing a network firewall. I’m not insinuating that compliance with industry guidelines and tools don’t have their place in the picture, but they need to be part of a comprehensive, planned, and human operated solution, not just a hodge podge of red/yellow/green status lights and checkboxes. The same money that is spend on the all ‘fix it fast’ and ‘compliance me’ (TM) solutions that really give you nothing except avoiding a fine can be re-invested into security staff that can plan and execute true solutions that will not only help you avoid fines, but will also give you true enterprise security.

http://danielmiessler.com/blog/from-password-reset-mechanisms-to-openid-a-brief-discussion-of-online-password-security / http://danielmiessler.com/blog/password-reset-mechanisms-the-online-security-threat-nobodys-talking-about
I’m really glad this topic is getting some press. I wrote about ASQs a few months ago and have since been noticing some changes in the options available for password reset functionality. Google allows you to select between secondary email reset, SMS, and ASQ. Additionally, there’s a 24hrs waiting period after the email notification is sent out to the secondary email address before you can leverage the other 2 methods. Very nice. MyOpenID (my OpenID provider) offers password, certificate based authentication, and telephone based authentication – pretty awesome options! Alas, the recover password functionality simply sends an email with a 11 character variable that you click to recover your account. Not too happy about that. There you have it, Google has given some serious thought to security in password recovery, MyOpenID, not so much.

http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1366077,00.html#
Paper – http://conferences.sigcomm.org/sigcomm/2009/workshops/wosn/papers/p7.pdf
I applaud this kind of research. I think it’s critical that those of us who understand the importance of unique identifiers, data aggregation, cookies, URLs, and data privacy need to keep an eye out to the kind of data these sites are forcing our browsers to transmit without our knowledge. That being said, hopefully the majority of you are using AdBlock, RequestPolicy, NoScript and have your browser destroying cookies periodically. I will say that my curiosity got the best of me, and I spent some time running around the social networks with my local web proxy recording traffic and subsequently analyzing a lot of HTTP headers. Yes, there are unique identifiers, yes there are referrers, but at no point did I see any of the beacons even being provided any sort of PII. Do certain applications put PII in URLs? Sure, but I’m a little skeptical about just how much PII could be harvested. None the less, good study.

http://www.briansolis.com/2009/08/why-authenticity-matters/
This is a very interesting post, especially for those of us in the security community that are largely known by our screen name of choice. When I started blogging and joining up to the various social networks, I was compelled to use my own name…or the wadew variation – Woolwine is sometimes a lot for people to consume. I was determined for folks who read and follow my work online to be able to make the immediate connection should they ever meet me in person. But back to the article at hand, how do YOU know that I’m really Wade Woolwine? Honestly, you don’t. Even though I’ve executed on most of the items in the list (at least the personal blogging part) and have ClaimID, domain registrar, and OpenID, you still “trust” that I’m not John Smith who renamed himself Wade Woolwine to appear at the top of Google search results.

http://www.thetechherald.com/article.php/200935/4323/Criminals-sending-malicious-CDs-to-credit-unions
Social engineering is a required pillar in a number of different attacks. From XSS to SQLi, malware proliferation to CSRF all of these attacks (often) require that the attacker trick the user into visiting a URL crafted for disaster. So what are we (security professionals) doing about it? Security awareness training of course! But ask anyone around your company to give you 3 words to describe that training and you’ll likely hear terms like “boring”, “mandatory”, “pointless”, “waste of time”. How do we change this? How do we become more effective at socializing basic security practices like not clicking on random links without investigating them?

Homegrown Application Security Program

Saturday, August 22nd, 2009

growIn this time of shrinking budgets, reduced staff, and other various financial constraints, security departments world wide are looking for ways to justify the expense of a well rounded application security program. Jeremiah Grossman (WhiteHat Security / OWASP) and Jeff Williams (Aspect Security / OWASP) have collaborated on a fantastic article that is sure to get security engineers, developers, and managers alike lining up at their executives’ door armed with some great arguments in support of creating or expanding their application security programs.

While I fully support and endorse the content of the article, I can already see the responses from some executives:

“Wow, this is really great, and I fully buy into it, but as it stands, there is REALLY no money extra money in the budget.”

What now? Hopefully, there are employees in your company who are responsible for managing servers, the domain, the networks/firewalls/IDS/IPS, and development efforts; but most importantly, you, who is concerned about the state of application security. Why not use some of the best resources from those groups to form an application security working group? I’ve found that no matter what the company, there are ALWAYS people that are interested in being able to devote some time to learning about how those sneaky hackers are able to break into so many systems. Furthermore, what (good) technologist wouldn’t be interested in expanding their skills?

I’m sure that you’ll encounter some resistance from employees and management alike, after all, time is valuable, but remember, Jeremiah and Jeff have already given you all the ammo you need; use it wisely.

Now that you’ve identified folks who are willing to donate some of their valuable time to this effort, your first step will be educating them about the various activities and processes involved with a complete application security program. Here’s a quick reminder:

  • Design and architecture reviews and threat models where you work to identify flaws in the application design and architecture as well as imposing security requirements.
  • Secure coding standards where you work to ensure that developers implement features such as input validation, authentication, authorization, and avoid creating flaws in the business logic as they move through implementation.
  • Code reviews where through either automated or manual means, developers review their code with a focus on identifying any security issues.
  • Testing and validation where you ensure that all requirements have been implemented according to design specs.
  • Deployment and maintenance where you ensure that logs are being monitored, system patches are being kept up to date, and 3rd party libraries used in the application are kept up to date.

The chances are good that some of the folks that have chosen to join the security working group already have some valuable input to provide. For example, the sysadmins might have expertise in Apache, host configuration management, or IPTables. The network folks might have been exposed to web application firewall technology. The developers might have some great security specific libraries that they’ve used on past projects. All of this knowledge is valuable and already at your finger tips. For other topics, search around your social network, if you’re on Twitter, checkout @securitytwits, if you’re a member of OWASP, attend the meetings, talk to folks, try to get an idea of their expertise. Many of the seasoned security professionals who attend these meeting would be happy to come in and present at one of your groups meeting.

So, get out there, talk to people both within and outside of your company, not only will you expand your social network and improve your companies application security program, but you’ll also be giving new opportunities to those who join the security working group.