Please follow us on our new Twitter and like us on our updated Facebook page.  Our new website is located at sharedsecurity.net. Thanks for listening to the podcast over the years and we look forward to many more!

-Shared Security Podcast Hosts, Scott Wright and Tom Eston

The post We’ve Moved! appeared first on The Social Media Security Podcast.

Figure 1 – Location of the Facebook Graph Search on Your Profile Page

The Facebook Graph Search is a new implementation of search which retrieves information that comes from Facebook’s Graph. This new feature brings powerful capabilities for finding out more about your friends’ “likes” and activities. It also provides attackers with a more efficient way to glean information for social engineering attacks and other intelligence gathering activities.

What’s the Facebook Graph?

Think of the Facebook Graph as a very large database of personal information from (literally) a billion Facebook users. This information is categorized by what you and your friends like as well as what you’ve posted, what’s in your profile, locations you’ve visited, and tagged pictures. The Facebook Graph has evolved over the years in order to correlate as much information as possible, making it very easy to search.

What’s the Privacy Concern?

The issue is that anything you’ve ever posted publically, “Liked,” or were ever tagged in can be quickly searched. Additionally, other information that you’ve posted in your profile, such as your hometown, relationship status, and employer now become searchable. For example, those party pictures you were tagged in four years ago doing things you would never do anymore can be searched by your friends and possibly the friends of your friends; or worse, anyone with a Facebook account.

The Graph Search opens up lots of new and interesting search possibilities that we’ve yet to see on a social network. Here’s one example: Suppose you are a single male looking for single females. You can simply search for “photos of friends of my friends who are single and female” and find pictures of all the single females that are friends of your friends. Interesting, huh? How about the intelligence gathering aspects of these types of searches? For example, search for “<Insert Company> employees located in <Insert City> and you will have a list of targets for social engineering or more. For some other eye opening searches, I recommend you read this blog which shows some interesting privacy ramifications of creative searches.

How to Protect Your Privacy

First, check out Facebook’s “Activity Log” (Figure 2) which can be found under Privacy Settings and Tools in your Privacy Settings.

Figure 2 – Location of Facebook’s Activity Log

Next, if you want to change the privacy settings for all posts you’ve shared with Friends of Friends or with the Public, you can select “Limit Past Posts,” which will automatically change the privacy settings on all past posts (Figure 3).

Figure 3 – Selecting “Limit Past Posts” changes privacy settings for all posts set to Friends of Friends or Public

You will also want to make sure you review the following items in your Activity Log (Figure 4): Your Posts (especially those set to Public or Friends of Friends), Posts You’re Tagged In, Posts by Others, and Your Photos. It doesn’t hurt to also review your Likes to make sure there is nothing you liked that you don’t want coming up in a search.

Figure 4 – Items to Review in Your Activity Log

Lastly, carefully review your Facebook Privacy settings especially if you haven’t looked at them in a while. The Facebook Graph Search makes these settings more important than ever. Be sure to download SecureState’s recently revised Facebook Privacy & Security Guide which walks you through the recommended privacy settings while still allowing you to be social. The updated guide includes details on Facebook Graph Search and other important privacy settings. I encourage you to share this guide with friends and family.

Looking For More Information on Social Media Privacy?

SecureState has just released a comprehensive whitepaper by Ken Smith of SecureState’s Profiling & Penetration Team entitled “The Problem with Privacy”. I highly recommend you download and read this whitepaper to find out what the latest threats to your privacy are when using Social Media.

Cross-Posted from the SecureState Blog

The post The New Facebook Graph Search: How to Protect Your Privacy appeared first on The Social Media Security Podcast.

The guide has been a labor of love but also required frequent updates since Facebook has drastically changed the privacy controls as well as the layout within the Facebook platform over the years.  Needless to say it’s been tough to keep the guide updated and also tough to keep it to a single page so that it can be easily distributed.  Today, I’m happy to announce that my company SecureState is now officially sponsoring the guide so that it can be maintained with frequent updates!  Having said that, I’m announcing today the release of the fourth version of the Facebook Privacy & Security Guide, updated with the latest information on Facebook’s privacy and security settings.  Please download and distribute to friends and family.

Also around the same time I started the guide, I started the Social Media Security website and podcast.  The podcast is still being recorded monthly and co-hosted by myself and Scott Wright.  Today we also released our 30^th episode along with a website redesign for socialmediasecurity.com.  I’d like to thank the podcast’s new sponsor SecureState for the new design and support of the podcast.  Special thanks go to DigiP over at Tick Tock Computers for putting together a great site redesign and logo.  I look forward to recording more podcasts and getting the word out on how to safely use social media!

The post Social Media Security Website and Podcast Reloaded! appeared first on The Social Media Security Podcast.

Jack Cheng maps out a positive vision for a “slow” type of web app:

Timely not real-time. Rhythm not random. Moderation not excess. Knowledge not information. These are a few of the many characteristics of the Slow Web. It’s not so much a checklist as a feeling, one of being at greater ease for the web-enabled products and services in our lives.

The post The Slow Web appeared first on The Social Media Security Podcast.

Alexis Madrigal at The Atlantic on Google’s Knowledge Graph:

This is one of those human knowledge projects that is ridiculous in scope and possibly in impact. And yet when it gets turned into a consumer product, all we see is a useful module for figuring out Tom Cruise’s height more quickly. In principle, this is both good and bad. It’s good because technology should serve human needs and we shouldn’t worship the technology itself. It’s bad because it’s easy to miss out on the importance of the infrastructure and ideology that are going to increasingly inform the way Google responds to search requests. And given that Google is many people’s default portal to the world of information, even a subtle change in the company’s toolset is worth considering.

And that’s how I found myself on the phone with John Giannandrea discussing mojitos and semantic graphs.

Sounds like another stab at the Semantic Web. It’ll be interesting to see how Facebook’s Open Graph actions play out in this space as well.

The post Inside Google’s Plan to Build a Catalog of Every Single Thing, Ever appeared first on The Social Media Security Podcast.

http://www.consumerreports.org/cro/magazine/2012/06/facebook-your-privacy/index.htm

The post Facebook Privacy and Security Article on ConsumerReports appeared first on The Social Media Security Podcast.

As always, feel free to distribute this guide to friends and family!  Happy Thanksgiving!

Download v3.0 of the Facebook Privacy & Security Guide here

The post Facebook Privacy & Security Guide Updated to v3.0 appeared first on The Social Media Security Podcast.

I choose a volunteer out of the crowd.  Usually a nice looking woman because…why not.  I give a hypothetical situation.  We were dating and things are starting to get serious.  So serious that I take her to meet my mom for the first time. While we are at my ma’s house, I introduce her to my new brother-in-law.  My brother-in-law was in charge of bringing the dinner rolls and once again forgot.  He asks her to go to the Italian (not french) bakery down the road with him to get these rolls.  She says yes.  While they are picking up the rolls he notices that he forgot his wallet and asked her for $4.98 to cover the rolls.  She just happens to have $5.00 in her left pocket.

Would she give him the $5.00 and why?

The answer has always been “yes” and because he is associated or was introduced to her by me.  There is an applied level of trust set prior to them going to the bakery.  Well this level of trust in my opinion can be accomplished within twitter.  If I follow you and we start having a friendly conversation(your favorite sports team) I will then go after your friends and family for a small amount to help me with my “cure/run/walk”.  All I have to do is introduce myself as your friend as they can see our past conversations in twitter.  I  have had a over 90% success rate of getting their followers to click my cause link.  This success is based on the applied trust between two strangers.  So although it is really #kwel to have 70,000 twitter followers it can also cost your friends and family $4.98

For more information feel free…info@unixbox.ws

The post The race for the most personal Twitter followers appeared first on The Social Media Security Podcast.

The policy of company ACME is “no social networking allowed” on internal networks.  Sites are being blocked at the firewall with rules and enforced with a content filtering tool. IT/Security has done its job with social media, right? BUT an exception is made for Marketing because they are special people. A FB page was created as well as an E-Commerce app installed without consulting IT/Security. I know this because after taking over the FB page using our friends Cain and Able, I replaced just one of the “buy now” buttons to redirect it my site and used analytics to see how many people clicked this button.  Showing this to Director of IT he replied “I didn’t even know we had a FB Page.”

Part 2

After this meeting we agreed to stop and allow IT/ Security to be a part of the implementation of this new e-com solution and lock down this new site.  After a couple of months we were given the green light that all social media was secure and our attacks would now #fail.  Well they were wrong!  Here is what happened;  Technology constantly changes and therefor we should also be constantly training/testing these changes.  Yes, all https was checked.  Yes, they read www.socialmediasecurity.com on a regular basis.  But they forgot to monitor their social media accounts like they would an email server.  There is still a core failure in my opinion of Facebook pages.  Who?!? owns the data and when is it okay to monitor the admins personal accounts? Because these users of the pages still enjoy using Facebook for personal use. They do not apply the corporate rules to their personal accounts nor should they if that is how they live.  So, we are either forced to create fake accounts or all share one admin account.  Well with our testing we are still targeting the admins of these pages.  There are many many ways to gain access to their accounts and once in, we only have to create our own evil twin account to keep access.  Example: if Bob Alice is the admin of the page just create another Bob Alice and copy the information including the  profile imagine and allow this new user admin rights to the page.  Most common users will just think this is a Facebook glitch and it is showing their profile twice. But in reality it is a way for us to keep a constant admin account to this system.  If you maintain a Facebook page you know that admins just lose their rights to the page all the time out of the blue.  So constantly adding the same person is a regular process.  If the company was monitoring its data it would see these changes or see that there were in fact 2 different accounts attached to this page.  But we are not monitoring these accounts, yet. Social media security can be a full time job depending on the risk and frequency of the sites.   For more information feel free as always to email me.  info@unixbox.ws

The post Taking over the Facebook Page “buy now” button (Part 2 of 2) appeared first on The Social Media Security Podcast.

For a while now, I have been keeping an eye out for technologies that might help organizations leverage social media securely, within an Intranet environment for business purposes. Recently, I came across a success story about the Canadian Medical Association’s recent implementation of a social Intranet using an out-of-the-box product by ThoughtFarmer. That article (posted on the ThoughtFarmer blog) tapped the CMA project leader, Tanis Roadhouse, for tips on some of the key points in her blue-print for the CMA site’s implementation. So, I decided to check into the story.

The article showed that Tanis, while not being a life-long IT project leader, was pretty well organized, and showed some thought leadership. Here’s a summary of her 7-point blue-print for building a social intranet:

1. Start with an inspiring vision: the value of a collaborative culture
2. Secure executive support
3. Pick a name that matters
4. Gather requirements to learn the business
5. Partner with IT early
6. Treat content owners like royalty
7. Embrace continuous improvement

Click HERE for the entire article.

For each point, the article provides some detailed explanations. I followed up with Tanis via Twitter to see where Risk Management and IT Security fit in, since they weren’t explicitly listed in the explanations. For the most part, she said they addressed these issues in the IT liaison step.

Tanis did mention (over Twitter) that, because the organization is heavily oriented toward finance, a Risk Assessment was performed in order to protect client data. The assessment concluded that there was, “Limited risk, as it is an Intranet site”, and that “Risk to clients was reduced through governance policies.”

I should point out here that you can not infer that an intranet site will be secure simply because you have good governance policies. Any organization that takes on any IT project that will be deployed on their network (internal or external) should do a thorough risk assessment, and use its recommendations to strengthen any identified vulnerabilities. This may result in strengthening policies, technical safeguards, procedures, personnel screening, roles and responsibilities or training. (Disclaimer: I harp on this stuff because it’s a big part of what I do for my clients.)

I think the lesson here is that organizations are starting to see value in using social media tools that they keep under their own control. In the early years of Facebook and Twitter, I saw some organizations embracing the publicly available tools to initiate internal collaboration, which was (and still is), generally a bad idea. This kind of thing led to hackers employing social engineering tactics to join “employee groups” and learn way too much about the vulnerabilities inside the company’s walls and networks, which of course, leads to data breaches.

Now, with some real implementations we can talk about, I’m hoping to get a closer look at how these tools can be deployed securely in an environment where you’re not sharing sensitive corporate data with 700 million of your closest friends (e.g. as would happen on Facebook).

I should also mention that the ThoughtFarmer blog also seems to be a good source of thought leadership. Not only are they kindly publishing meaningful success stories, but they also demonstrate an understanding of how to use social media to help others think through their problems. One of their subsequent posts has a list of “81 Intranet Governance Questions to Ask Yourself.” (Click HERE)

I’m encouraged by this kind of leadership, both in the vendor community (as demonstrated by ThoughtFarmer) and among the project initiators like Tanis. I hope to follow their progress in the future and share any tips I learn with you.

The post Implementing a robust Intranet that leverages social media technology appeared first on The Social Media Security Podcast.

Steve’s conclusions are very compatible with my usual prefered strategy for choosing passwords – like using the first characters from a song or movie quote, and adding some special characters and numbers. But his advice is interesting about how simple the basic password root can be, and how to easily make it much stronger. It’s pretty cool and simple.

The bottom line is that by adding length to a good, short password (regardless of whether or not they are repeated characters or patterns) you will massively improve resistance to a brute force attack. This is because today’s attacker doesn’t know how long the password is, for sure, and will always start with the easy dictionary words and patterns, and then they will move to the shortest possible character combinations in a brute force attack, followed by the next shortest combinations, and so on… 

As an example, using this logic, a 23 character random password is not “usefully” stronger than a 3 character random password with 21 repeated characters. 

There are some minor caveats in using this approach, to keep the passwords strong, such as having at least one lower, one upper case, one number and one special character in the root of the password. The rest of the characters don’t really matter, as long as you don’t reveal what pattern you use in the repeated characters or patterns.

For example “..B.o.B……….” is a pretty good password, since it would take at least 2 billion centuries with massive cracking array scenario to go through all combinations. So, you don’t need a very long song title or movie phrase. You simply need to keep your simple pattern or strategy a secret.

The Security Now podcast episode (in text or audio format) where the rationale for this approach is described is at the following link:

http://www.grc.com/securitynow.htm (look for Episode 303)

Steve also has a web page that analyzes passwords in terms of how long a given password can be expected to stand up to various brute force attacks. You don’t have to enter your real password, but try entering something that has the same length, and number of upper, lower case, numbers and special characters as your real password, and see how long it would take an attacker to try all combinations using a brute force approach.

http://www.grc.com/haystack.htm

If you aren’t convinced, or if you want to learn more, post a question or comment below.

Something to ponder…

– Scott

I am now offering monthly briefings, tailored to organizations that want to build and sustain security awareness for staff. Just because your security team is too busy to do its own training and awareness doesn’t mean you can’t have an economical way to address human security risks. Please call or email me at the coordinates below…

Scott Wright

The Streetwise Security Coach

Join the Streetwise Security Zone at:
http://www.streetwise-security-zone.com/join.html

Phone: 1-613-693-0997
Email: scott@streetwise-security-zone.com
Twitter ID: http://www.twitter.com/streetsec

To receive weekly security tips and other notices about helpful content available on this site, please make sure you are on my list by clicking HERE, and entering your name and email address.

The post How to easily create a much stronger password than you need to thwart a brute force attack appeared first on The Social Media Security Podcast.

The policy of company ACME is “no social networking allowed” on internal networks.  Sites are being blocked at the firewall with rules and enforced with a content filtering tool. IT/Security has done its job with social media, right? BUT an exception is made for Marketing because they are special people. A FB page was created as well as an E-Commerce app installed without consulting IT/Security. I know this because after taking over the FB page using our friends Cain and Able, I replaced just one of the “buy now” buttons to redirect it my site and used analytics to see how many people clicked this button.  Showing this to Director of IT he replied “I didn’t even know we had a FB Page.” Part two is coming…but I leave you with this..

Who is in charge of these buttons?  Have these tools been tested and approved by IT/Sec before you took the 6 mins to install on your facebook page? What permissions are you giving this solution? HEY! IT/Sec does your company have a FB page?  Have you seen it lately? Is it part of your compliance testing?

The post Taking over the Facebook Page “buy now” button (Part 1 of 2) appeared first on The Social Media Security Podcast.

I know firesheep has lost its shiny coin syndrome with most but the attack is still working quite well in the field.  While the readers/listeners have been doing a good job of enabling secure browsing options in Twitter and Facebook, we still have a long way to go. Please keep spreading the word and keep pleading to social networking sites to enable secure browsing by default.  So, Why the “Firesheep’s Revenge” title?  Well these last month’s, a couple of us have been testing common social media monitoring (SMM) tools.  These tools are generally used by small businesses, internal marketing, or external marketing companies to help update social media accounts without the hassle of logging into every social networking site individually.  We have been testing these SSM’s and found that:

http://hootsuite.com/dashboard#
http://sproutsocial.com/dashboard
http://standard.cotweet.com/channels#

Are not using secure browsing by default, allowing us to hijack sessions.  What does this mean? Well by adding your social media accounts into these SMM tools, you are granting the tool permission or full control over that account(s). By gaining control over the tool we are bypassing all the hard work you did by enabling secure browsing in each of your twitter and facebook accounts.  Try explaining to the VP of Marketing that even though you checked the “defeat firesheep” box it still works. And not only will it work on Facebook/Twitter but now LinkedIn, Foursquare, ping.fm and Ning accounts all in one interface. Most of the time we were looking at full access to the corporations social media strategy. So, we are right back to where we started, teaching the user that security is usually the last thing on the mind of these rapid development firms. If you do not see the option of “secure browsing”, then please be careful of where you update your social media accounts. Ask your tool makers where this option is located.  If they do not have this option then maybe you should look for another tool.

James F. Ruffer III
Unixbox
@jruffer

The post Firesheep’s Revenge appeared first on The Social Media Security Podcast.

The first issue came from a page on the mobile version of Facebook’s site. The interface was a prompt for posting stories to a user’s wall, and the parameter for the text of the prompt did not properly escape output. On March 28, a blogger identifying themselves as “Joy CrazyDaVinci” posted code that demonstrated how the vulnerability could be used to spread viral links:

<iframe id=”CrazyDaVinci” style=”display:none;”
src=”http://m.facebook.com/connect/prompt_feed.php?display=wap&user_message_prompt=’<script>window.onload=function(){document.forms[0].message.value=’Just visited http://y.ahoo.it/gajeBA Wow.. cool! nice page dude!!!‘;document.forms[0].submit();}</script>”></iframe>

This bit of HTML would be included in a viral page. The code sets the content of the wall post to a message that includes a link to a viral page, then submits the prompt automatically. Anyone clicking the link would get the same code executed on their account. The viral page could be used for malware distribution or phishing attacks, but in most cases where I saw this trick used, the page simply loaded advertisements or “offer spam”.

By the next day, several links were spreading virally and caught the attention of security researchers. Facebook moved quickly to patch the issue, and Crazy DaVinci issued an apology for the example code, explaining that versions of it had actually been circulating for several days prior and that the demonstration was intended to push Facebook for a fix.

On April 3, another XSS problem came to light, this time with a Facebook “channel” page used for session management. Both another security researcher and I had previously looked at this interface and found it properly escaped, so it’s likely a code update mistakenly changed the page’s behavior. Facebook again patched the problem soon after news of it spread.

I didn’t observe any viral exploitation of the second vulnerability in the wild, but after the first problem came to light, I noted that it was mostly used to submit a form already on the page for posting links. The payload made use of functionality within the vulnerable page, but XSS allows an attacker to do far more. I wondered when we might see a Facebook attack that made greater use of cross-site scripting’s potential.

What a Difference a Space Makes

I didn’t have to wait long. On April 7, I got word via Twitter of a Facebook app that had live XSS, but the app had disappeared before I got to see it in action. At first, I thought this was yet another case of XSS within the context of a Facebook app. But I soon found other version of the app which were still online, and I quickly realized this was actually an XSS problem with the Facebook Platform. Also, the XSS payload being used did much more than submit a form.

The attack used FBML-based Facebook apps, which render in the context of an apps.facebook.com page. Normally, Facebook filters code to prevent any scripts from directly modifying the page’s DOM, but the XSS problem gave attackers a bypass. When a user visited the app page, they would see what appeared to be a fairly benign page with a popular video.

Unlike many Facebook page scams, the promised video actually works – if you click play, the video will load and nothing unusual seems to happen. But as the code screenshot below reveals, that click does much more than load the video.

When the page first loads, the “video” is actually just an image placeholder with a link. Part of the href parameter for that link is shown above. Note the space after the opening quotation mark – that’s where the XSS comes in. Normally, Facebook would block a link to a javascript: URL. Adding the space worked around Facebook’s filters, but the browser would still execute the rest of parameter.

According to Facebook, it turned out that some older code was using PHP’s built-in parse_url function to determine allowable URLs. For example, while parse_url(“javascript:alert(1)”) yields a scheme of “javascript” and a path of “alert(1)”, adding whitespace gives a different result: parse_url(” javascript:alert(1)”) does not return a scheme and has a path of “javascript:alert(1)”. Other PHP developers should take note of the difference if parse_url is being used in security-related code.

A More Advanced Attack

Clicking the link executed an inline script that in turn added a script element to the page. This loaded more code from a remote address and included several parameters in the GET request. The parameters set variables within the remote code that specified what video to load, what URLs to use for viral posts, and so on. Multiple Facebook apps and domains were used for the viral links, but the main script always came from the same host. This helped the attack persist, since blocking one site would not stop it and the central code was loaded dynamically.

The remote code handled actually loading the video, but also included a number of functions which make use of having script access in a facebook.com context. The script would set the user as attending spam events, invite friends to those events, “like” a viral link, and even send IMs to friends using Facebook Chat.

When I came across the attack, one block of code had been commented out, but one blogger discovered a version of the attack a few days prior and saw it in action. This part loaded a fake login form which actually sent the entered username and password to a log interface on the attacker’s server. (Remember, this phishing form would appear in the context of a page with typical Facebook chrome.) Since the attack page would load even if a user was not logged in to Facebook, this could have also been a way to make sure a session was available before launching the other functions.

Fake videos and viral links are nothing new on Facebook, but most of these scams tend to be fairly simple. In fact, it’s not hard to find forums where people offer boilerplate code for launching such schemes – much like the first XSS worm above which simply submitted a form. But the April XSS attack involved multiple domains, multiple user accounts, and multiple methods for spreading and hijacking user accounts. And it still only scratched the surface of what’s possible with an XSS vulnerability. I expect we’ll see more XSS-based attacks and more powerful payloads in the future.

Postscript on Real-Time Research

I came across the April attack late one afternoon as I was preparing to leave work… so I could present on XSS at a local OWASP meeting! Those following me on Twitter saw a somewhat frantic stream of tweets as I tried to find live examples of the attack and sorted through the code while closely watching the clock and wrapping up last-minute presentation details. Earlier this week, I did some searching to review information for this post, and I came across this article from eWEEK: “Facebook Bully Video Actually an XSS Exploit“.

I was a bit surprised by it, as I hadn’t known about it before and saw that it quoted me. I then realized it was quoting my tweets! I then read that I had “confirmed to eWEEK on Twitter” one aspect of the story. At first I was confused, but then remembered that during my flood of tweeting, another user had sent an @ reply asking about the very detail the story talked about. Checking that tweet again, I found out the question had come from the article’s author.

I relate all this not because any of it bothered me, simply because (1) I found it somewhat fascinating that a few quick Twitter updates could become the primary source for a news article and (2) I was humbled to realize that a few quick Twitter updates could become the primary source for a news article! While it’s great that a story can spread so fast, it was certainly gave me a reminder to be careful when discussing topics of interest on a public forum. But I’m glad I can do my part in helping raise awareness of online dangers, particular the implications of XSS.

The post Recent Facebook XSS Attacks Show Increasing Sophistication appeared first on The Social Media Security Podcast.

“Social networks have jumped onto the geolocation bandwagon with location-based tweets, status updates, check-ins, mayorships, and more. This doesn’t take into account EXIF, QR codes, and advancements in HTML 5 geo implementations, which are being built into these location-based services. This is often implemented and enabled without the user even knowing it. In fact, geolocation is one of the hottest technologies being used in everything from web browsers to mobile devices. As social networks throw our location coordinates around like candy, its only natural that bad things will happen and abuse will become more popular. This presentation will cover how social networks and other websites are currently using location-based services, what they plan on doing with it, and a discussion on the current privacy and security issues. We will also discuss the latest geolocation hacking techniques and will release custom code that can abuse all of the features being discussed.”

Slides are on SlideShare below:

The post Social Zombies Gone Wild: Totally Exposed and Uncensored appeared first on The Social Media Security Podcast.

Facebook Pages security is basically in the hands of the personal accounts of the admins.  This is one reason why the CSO should care…

The post Why Should the CSO Care About an Employee’s Personal Social Media Account? appeared first on The Social Media Security Podcast.

To Facebook’s credit, Facebook has made considerable strides over the last few years by implementing new security and privacy controls as well as getting the Facebook security team more visible.  Some of the newer implementations, such as full site SSL and social authentication, will continue to improve the security of Facebook.  Unfortunately, many of these myths will still persist.  This is because users will believe what they want to believe despite new controls and efforts being put in place by Facebook.

Facebook Application Myths

Myth: All Facebook applications are created and managed by Facebook.
Reality: Facebook applications are not developed or maintained by Facebook.  They are all developed, maintained, and managed by third-party companies.  Facebook simply provides an API (Application Programming Interface) for developers to “interact” with Facebook and its data.  For example, Farmville is created by the company Zynga.  Zynga only uses the Facebook API to interact with Facebook.  One common misconception is that these applications “look and feel” like they are part of Facebook so the applications can be trusted.  This is not true.  The Facebook API is designed to allow seamless integration so it provides users with a more integrated Facebook experience. To make matters worse, Facebook recently announced that they will now allow iframes within page tab applications.  This means that a malicious developer can easily do things like redirect users to malicious web sites or use JavaScript to do a host of other things to the user.

Myth: Facebook reviews all applications for security vulnerabilities, scams, or frauds.
Reality: In general it would be very difficult with Facebook’s current application developer model to review the code for all Facebook applications.  According to Facebook’s official statistics, people on Facebook install 20 million applications every day and according to an older statistics page I found dated November 2010 there were approximately 550,000 active applications.  This is an extremely large amount of applications to check for security issues.  This problem also becomes more challenging when developers release new code or updates to existing applications.  How is Facebook currently addressing this issue?  Facebook made a statement in this recent InformationWeek article talking about how they review applications.  Facebook claimed to have a dedicated security team that “does robust review of all third-party applications, using a risk-based approach.”

“That means that we first look at velocity, number of users, types of data shared, and prioritize,” the statement read. “This ensures that the team is focused on addressing the biggest risks, rather than just doing a cursory review at the time that an app is first launched.”

In other words, they look at applications that fall into specific categories because it would be near impossible to check every single application.  There is also no mention if Facebook conducts a code review of applications selected for review.  The bad news, of course, is that once Facebook shuts down one rogue, malicious application another one is easily right behind it to take its place.

Myth: Facebook applications don’t have typical web security flaws.
Reality:  Facebook applications can be developed insecurely just like any other web based application.  In fact, in 2009 security researcher theharmonyguy conducted the “Month of Facebook Bugs” exposing security flaws in many of the popular Facebook applications at the time.  These flaws included XSS (Cross-Site Scripting) which can be used to attack the users of applications, SQLi (SQL Injection) which can be used to extract personal or private information from the database of applications, and ClickJacking or LikeJacking which can be used to initiate actions without the user’s knowledge. 

Myth: Facebook is responsible for any information you provide to Facebook or third-party applications.
Reality: This is a tricky one.  At the end of the day, you’re responsible for what you post and any information you provide Facebook or third-party applications.  There is no guarantee that Facebook or third-party application developers will not misuse or sell your information.  This has happened in the recent past.

Myth: Facebook allows developers to do whatever they want with their applications and can collect your personal information.
Reality: Facebook has certain policies that you can read for yourself about what a developer can or can’t do.  It’s important to note that Facebook used to be more restrictive with these rules in the past.  For example, application developers could only keep personal data collected for 24 hours.  Facebook has now removed this restriction and has relaxed many other policies so it’s easier for developers to integrate with Facebook.  Having said that, it’s hard for Facebook to truly “enforce” these policies unless a malicious application is reviewed by them or it’s reported to the Facebook security team.  It’s a battle that is going to be very hard to win based on the current way Facebook allows applications to be developed.

Facebook Privacy Myths

Myth: Facebook reviews all third-party companies that collect your personal information.
Reality: In certain cases like when your friends visit an “Instant Personalization” partner like Yelp and the third party can see your information the Facebook privacy policy states that “we require these websites and applications to go through an approval process, and to enter into separate agreements designed to protect your privacy.”  What that means is up for debate but what we do know is that you should be cautious when using Instant Personalization as you may be revealing information about your friends as well.

Myth: Facebook takes user privacy seriously.
Reality: Facebook will try to tell you that they do take your privacy seriously as noted in their privacy policy.  However, Facebook also has a vested interest in collecting your information.  After all, it’s how they make money.  Double edged sword?  It certainly is!  The more information you share the more valuable you are to Facebook.  You should always take your privacy on Facebook seriously as they may not always have your best interest at heart.

Myth: Facebook has very little privacy controls.
Reality: This is false.  In fact, Facebook has made great strides over the years in providing its user base with easier to use privacy controls.  I’ve seen this myself while putting together my Facebook Privacy & Security Guide over the years.  The problem has become that many users don’t know where these settings are or how to use them.  Facebook also hasn’t done a great job of communicating changes to privacy settings in the past.  Users of Facebook and computer users in general have become immune to pop-ups and hard to read sign-in notifications.  It’s simply become easier for users to just “click through” so they can get to what they want in Facebook.

Myth: Facebook makes it easy for users to delete their accounts.
Reality: The truth is that the process of deleting your Facebook account has gotten only slightly better over the years but still remains a confusing one.  For example, here is one guide that walks you through the procedure.  Facebook still has account “deactivation” as the first step in the account deletion process, which many users still find confusing.  Many users are also confused between “deactivation” and “deletion.”  Others think that by successfully deleting their account all the information including pictures they posted are removed from Facebook forever.  While Facebook may say they remove all of your information, you still can’t stop others from copying it or saving those party pictures of you to their hard drive.  The rule to remember is that once you post something on Facebook, you should always think of it as public information.

Facebook Security Myths

Myth: Facebook scams are mostly variations of the same one over the years.
Reality: Many of the Facebook scams found are simple variations of text messaging, promotion give-a-ways (iPads, iPods [insert latest hot gadget here]), who visited your profile (ProfileSpy), and improvements to existing Facebook services like chat and instant messaging.  In fact, one scam I blogged about over a year ago is still being used today.  The basic rule to remember is that if something is popular in our culture, such as tech products that everyone wants, it’s most likely going to be used for scams and frauds.  Remember the old rule: if it sounds too good to be true, it probably is.

Myth: I can’t get a virus or malware by using Facebook
Reality:  All it takes is clicking on a malicious link from one of your friends, installing a rogue application, or falling for one of the many scams that offer “free” stuff.  Facebook is doing a better job of cleaning up malicious links and other related activity.  However, the Koobface worm and associated variants are still a problem and adapt well to attempts by Facebook to rid them from the platform.

Myth: I can trust my friends on Facebook because they would never send me anything malicious.
Reality: It’s always nice to trust your friends but this gets complicated on Facebook.  Social Network worms such as Koobface as well as hijacked or stolen accounts are frequently used to social engineer Facebook users to click on a link or send money to foreign countries.  All of these scams exploit the trust relationships that you have with people you know.  It’s a simple and highly effective technique that’s still being used today.

Myth: Facebook does not have a security team or a way to report security issues/SPAM/scams.
Reality: Contrary to popular belief, Facebook does have a security team and ways to report security and privacy issues.  In the past, many of these types of requests would have met the infamous “Facebook Blackhole” in which emails or support requests were never answered.  Recently, there have been many improvements to help communicate the presence of this team.  For example, you can “like” the Facebook security page, report a compromised account, learn how to report security vulnerabilities, as well as get good tips on what to do when you see security issues.

The post Dispelling The Myths Of Facebook Privacy And Security appeared first on The Social Media Security Podcast.

Why would a business want private social networking tools? Isn’t that an oxymoron?

I believe that enterprises can and will eventually begin to use “internal” or “private” social networks to allow for easier real-time collaboration, while avoiding some of the risks of the “public” social networks – such as social engineering attacks, Koobface attacks, etc. I’d really like to learn more about what the options are for businesses to deploy their own social media tools internally, or in a private cloud. Internal deployments would probably tend to be more secure, with potentially more control over access and authentication of users. But a cloud-based implementation by a trusted service provider might also be quite secure. Either way, the facility would be less of an easy target for attackers.

Have you seen or heard of such a thing? If so, where can I learn more about them? Doing a Google search turns up many hits, but I’d like to hear about some success stories and reviews of these kinds of solutions that could benefit the members of the Streetwise Security Zone as we try to figure out how to leverage the power of social media, in a secure and efficient way.

Also, what are your thoughts? What would it take for enterprises to be able to use social networks and social media tools securely? 

I am now offering monthly briefings, tailored to organizations that want to build and sustain security awareness for staff. Just because your security team is too busy to do its own training and awareness doesn’t mean you can’t have an economical way to address human security risks. Please call or email me at the coordinates below…

Scott Wright

The Streetwise Security Coach

Join the Streetwise Security Zone at:
http://www.streetwise-security-zone.com/join.html

Phone: 1-613-693-0997
Email: scott@streetwise-security-zone.com
Twitter ID: http://www.twitter.com/streetsec

To receive weekly security tips and other notices about helpful content available on this site, please make sure you are on my list by clicking HERE, and entering your name and email address.

The post Can enterprises use private social media tools for secure collaboration internally? appeared first on The Social Media Security Podcast.

At first, I started to think Facebook was simply looking to extend its reach by acting as an invisible layer of sorts. Anil Dash once talked about Facebook melting into the larger Web, but perhaps Facebook would end up becoming part of the underlying fabric of the Internet. In past public appearances, Facebook CEO Mark Zuckerberg seemed to be the kind of person who was content to remain in the background, and the company’s strategy seemed to reflect a similar style. I’ve mentioned before the idea of Facebook becoming and identity layer on the Internet, and innovations such as their Graph API have made it easier than ever for sites to integrate with Facebook.

But Facebook’s updated Groups feature changed my perspective, since it added functionality that would drive users back to facebook.com. Of course, the upgrade did enable e-mail as a way of interacting with groups. In some ways, Facebook’s overall strategy could be compared to Google’s. Years ago, many sites focused on “stickiness,” trying to keep users hooked. By contrast, Google drove users away by providing relevant links to other sites. But to see Google as non-sticky would be an oversimplification. In fact, the company built a successful ad network that extended its reach across the web. Also, Google has created a number of other products that many people stay logged into, such as Gmail.

And now, people are expecting Facebook to announce a web-based e-mail client that will compete with Gmail. I’m predicting that Facebook will roll out a new messaging system, but it won’t be a Gmail clone or simply another client for managing traditional POP/IMAP e-mail. That’s not to say there won’t be any e-mail gateway, but I think Facebook’s plans will go much further. I’m guessing that at least part of the new system will involve somehow extending private messaging features across Facebook-integrated websites.

In any event, I think Facebook’s announcement will include at least a few surprises for those who have been discussing the possibilities. Facebook has a history of introducing features that aren’t quite what people expected – and often end up leading to practical implementations of ideas that were previously niche experiments. Personally, I think it’s a bit short-sighted to think that Facebook would simply join the market for web-based e-mail without trying to reinvent it, especially given the service’s cautiousness about past features that allowed or potentially allowed spam-like behaviors.

Facebook has also been accused many times of somehow standing in opposition to “openness.” Personally, I think the term has become a buzzword that’s often used without much specificity. And even though I’ve often been a critic of Facebook, I do think many of the accusations aren’t entirely fair. From RSS feeds to developer APIs, Facebook has opened up data in ways that many other sites can’t claim. Today’s Facebook is certainly far more “open” that years ago – in fact, I would argue that the site has at times been too open lately, such as when some user data became reclassified as “publicly available” last fall. But regardless of Facebook’s degree of openness, the company has always been careful to maintain a high degree of control over information and features on the site. This can be positive, such as quickly removing malware links, or negative, such as controversial decisions to bar users or certain content.

Either way, that control has helped the site build a powerful database of profiles that generally reflects real people and real relationships. That’s part of what fascinated me about the site’s recent spat with Google over contact information. In the past, a list of e-mail addresses was about the only semi-reliable way to identify a group of people across the Internet. Now, many sites rely on Facebook’s social graph for that function. In terms of identity, the value of e-mail addresses has declined, and I don’t think exporting them from Facebook would provide as much value as Google might think. On the other hand, Google may realize this and be so concerned about the shift that they’re trying to curb Facebook’s influence. This would especially make sense if Google intends to introduce a more comprehensive social networking product that would need e-mail addresses as a starting point. Regardless, I’m sure Google feels threatened by the prospect of Facebook providing a better alternative to traditional e-mail – a change that would only bolster the value of a Facebook profile as the primary way to identify a typical Internet user.

The post Looking at Facebook’s Strategy and Possible New Directions appeared first on The Social Media Security Podcast.

The report generated controversy across the Web, and some reactions were strongly negative. On TechCrunch, Michael Arrington dismissed the article as alarmist and overblown. Forbes’ Kashmir Hill surveyed other responses, including a conversation on Twitter between Jeff Jarvis and Henry Blodget, and expressed skepticism over the Journal’s tone.

I’ve been a bit surprised by the degree to which some have written off the Journal’s coverage. Some may disagree with the label of “privacy breach,” but I thought the report laid out the issues well and did not paint the problem as a conspiracy on the part of Facebook or application developers. Either way, I’m glad to see that the article has sparked renewed conversation about shortcomings of web applications and databases of information about web users. Also, many may not realize that information leakage on the Facebook Platform has historically been even worse.

Information leakage via a referrer is not a new problem and can certainly affect other websites. But that doesn’t lessen the significance of the behavior observed in the WSJ investigation. Privacy policies are nearly always careful to note that a service does not transfer personally identifiable information to third parties without consent. Online advertising networks often stress the anonymity of their tracking and data collection. The behavior of Facebook applications, even if unintentional, violated the spirit of such statements and the letter of Facebook’s own policies.

Some people downplayed the repercussions of such a scenario on the basis that it did not lead to any “private” profile information being transferred to advertisers – a point Facebook was quick to stress. Yet when did that become the bar for our concept of acceptable online privacy? Should other services stop worrying about anonymizing data or identifying users, since now we should only be concerned about “private” content instead of personally identifiable information? Furthermore, keep in mind that Facebook gets to define what’s considered private information in this situation – and that definition has changed over the last few years. At one time in the not-too-distant past, even a user’s name and picture could be classified as private.

Many reactions have noted that a Facebook user’s name and picture are already considered public information, easily accessed via Facebook’s APIs. Or as a Facebook spokesmen put it, “I don’t see from a logic standpoint how information available to anyone in the world with an Internet connection can even be ‘breached.’” But this argument fails to address the real problem with leaked IDs in the referrer. The issue was not simply what data applications were leaking, but when and how that data was leaked. The problem was not that advertisers could theoretically figure out your name given an ID number – it’s that they were given a specific ID number at the moment a user accessed a particular page. Essentially, advertisers and tracking networks were able to act as if they were part of Facebook’s instant personalization program. Ads could have theoretically greeted users by name – the provider could connect a specific visit with a specific person.

Interestingly enough, many past advertisements in Facebook applications did greet users by name. Some ads also including names and pictures of friends. Facebook took steps several times to quell controversies that arose from such tactics, but I’m not sure many people understood the technical details that enabled such ads. Rather than simply leak a user’s ID, applications were actually passing a value called the session secret to scripts for third-party ad networks.

With a session secret, such networks could (and often did) make requests to the Facebook API for private profile information of both the user and their friends, or even private content, such as photos. Typically, this information was processed client-side and used to dynamically generate advertisements. But no technical limitations prevented ad networks from modifying their code to retrieve the information. In fact, a number of advertisements did send back certain details, such as age or gender.

Change to the Facebook Platform, such as the introduction of OAuth earlier this year, have led to the deprecation of session secrets and removed this particular problem. I’m not sure how much this sort of information leakage or similar security problems motivated the changes, but problems with session secrets certainly persisted quite a while prior to them. If the WSJ had conducted their study a year ago, the results could have been even more worrying.

Still, I’m glad that the Journal’s research has led many to look more closely at the issues they raised. First, the story has drawn attention to more general problems with web applications. Remember, the Web was originally designed for accessing static pages of primarily textual information, not the sort of complex programs found in browsers today. (HTML 2.0 didn’t even have a script tag.) Data leaking via referrers or a page’s scripts all having the same scope are problems that go beyond Facebook apps and will likely lead to more difficulties in the future if not addressed.

Second, people are now investigating silos of information collected about website visitors, such as RapLeaf’s extensive database. Several responses to the Journal piece noted that many such collections of data provide far more detail on web users and are worthy of greater attention. I agree that they deserve scrutiny, and now reporters at the Journal seem to be helping in that regard as well.

We’ve entered an age where we can do things never previously possible. Such opportunities can be exciting and clearly positive, but others could bring unintended consequences. I think the availability and depth of information about people now being gathered and analyzed falls into the latter category. Perhaps we will soon live in a world where hardly any bit of data is truly private, or perhaps we will reach a more open world through increased sharing of content. But I think it well worth our time to stop and think about the ramifications of technological developments before we simply forge ahead with them.

Over the last few years, I’ve tried to bring attention to some of the issues relating to the information Facebook collects and uses. They’re certainly not the only privacy issues relevant to today’s Internet users, and they may not be the most important. But I think they do matter, and as Facebook grows, their importance may increase. Similarly, I think it wrong to dismiss the Journal’s investigation as “complete rubbish,” and I look forward to the rest of the dialogue they’ve now generated.

The post Thoughts on the Wall Street Journal’s Facebook Investigation appeared first on The Social Media Security Podcast.

First is some research several of my colleagues and I worked on.  The paper is titled: “Profiling User Passwords on Social Networks”.  The paper discusses the password problem that we all know and love as well as how you can determine passwords by what individuals post on their profiles.  We dive into tools from Robin Wood, Mark Baggett and others that can be used to pull keywords from profiles and other sources to create wordlists.  These wordlists can be used for brute force attacks on user accounts.  Next, we look at password complexity of several popular social networks with some research around brute force controls that some of the social networks have implemented, or in some cases haven’t.  Lastly, we discuss some things that users of social networks can do when choosing passwords.  You can download my paper here.

The other paper released is titled: “Security Gaps in Social Media Websites for Children Open Door to Attackers Aiming To Prey On Children” by my colleague Scott White.  In his paper he looks at the security of social media websites specifically designed for children.  This is some very detailed research and sheds some light on how predators are using these sites to target children as well as some issues that are unique to these types of social media websites.  You can download Scott’s paper here.

Speaking of social media…I’ll be presenting “Social Impact: Risks and Rewards of Social Media” at the Information Security Summit this Friday at 10am.  I’ll have the slide deck posted shortly after the conference.

Share and Enjoy

• Facebook • Twitter • Delicious • Digg • StumbleUpon • Add to favorites • Firs - http://www.spylogic.net/2010/10/two-new-social-media-security-white-papers-released/" title="Email this" rel="nofollow">Email • RSS

The post Two New Social Media Security White Papers Released appeared first on The Social Media Security Podcast.

Soon after that initial roll-out, security researchers noted vulnerabilities on Yelp’s website that allowed an attacker to craft pages which would hijack Yelp’s credentials and gain the same level of access to user data. TechCrunch writer Jason Kincaid reported on the cross-site scripting (XSS) holes, and made this prediction: “I suspect we’ll see similar exploits on Facebook partner sites in the future.”

Kincaid’s suspicions have now been confirmed, as the latest site with instant personalization also had an exploitable XSS vulnerability, which has now been patched. I’ll quickly add that Flixster, the company behind Rotten Tomatoes, has always been very responsive when I’ve contacted them about security issues. They have assured me that they have done XSS testing and prevention, which is more than could be said for many web developers. In posting about this issue, I primarily want to illustrate a larger point about web security.

When I heard about the expansion of instant personalization, I took a look at Rotten Tomatoes to see if any XSS problems might arise. I found one report of an old hole, but it appeared to be patched. After browsing around for a bit, though, I discovered a way I could insert some text into certain pages. At first it appeared that the site properly escaped any characters which could lead to an exploit. But ironically enough, certain unfiltered characters affected a third-party script used by the site in such a way that one could then execute arbitrary scripts. Since I had not seen this hole documented anywhere, I reported it to Rotten Tomatoes, and they promptly worked to fix it.

I’ve long argued that as more sites integrate with Facebook in more ways, we’ll see this type of problem become more common. Vulnerable applications built on the Facebook Platform provided new avenues for accessing and hijacking user accounts; now external websites that connect to Facebook open more possible security issues. As Kincaid noted in May, “Given how common XSS vulnerabilities are, if Facebook expands the program we can likely expect similar exploits. It’s also worth pointing out that some large sites with many Facebook Connect users – like Farmville.com or CNN – could also be susceptible to similar security problems. In short, the system just isn’t very secure.”

Overcoming such weaknesses is not a trivial matter, though, especially given the current architecture of how scripts are handled in a web page. Currently, any included script has essentially the same level of access and control as any other script on the page, including malicious code injected via an XSS vulnerability. If a site uses instant personalization, injected scripts can access the data used by Facebook’s code to enable social features. That’s not Facebook’s fault, and it would be difficult to avoid in any single sign-on infrastructure.

Of course, all of this applies to scripts intentionally included in the page as well, such as ad networks. With the Rotten Tomatoes roll-out, Facebook made clear that “User data is never transferred to ad networks.” Also, “Partner sites follow clear product/security/privacy guidelines,” and I assume Facebook is monitoring their usage. I’m not disputing any of these claims – Facebook is quite correct that advertisers are not getting user data.

But that’s due to policy limitations, not technical restrictions. Rotten Tomatoes includes a number of scripts from external sources for displaying ads or providing various functions. Any of these scripts could theoretically access a Facebook user’s information, though it would almost certainly be removed in short order. I did find it interesting that an external link-sharing widget on the site builds an array of links on the page, including the link to a user’s Facebook profile. This happens client-side, though, and the data is never actually transferred to another server.

I bring up these aspects simply to note the technical challenges involved in this sort of federated system. I think it’s very possible that we will eventually see ad network code on a Facebook-integrated site that tries to load available user data. After all, I’ve observed that behavior in many Facebook applications over the last few years – even after Facebook issued explicit policies against such hijacking.

These dangers are part of the reason why JavaScript guru Douglas Crockford has declared security to be the number one problem with the World Wide Web today. Crockford has even advocated that we halt HTML5 development and focus on improving security in the browser first. While that won’t likely happen, I think Crockford’s concerns are justified and that many web developers have yet to realize how dangerous cross-site scripting can be. Perhaps these issues with instant personalization sites will help increase awareness and understanding of the threat.

Postscript: This morning, an XSS vulnerability on Twitter led to script-based worms (somewhat reminiscent of “samy is my hero”) and general havoc across the site. This particular incident was not related to any mashups, but once again emphasizes the real-world security ramifications of cross-site scripting in a world of mainstream web applications.

Update (Sep. 27): Today news broke that Scribd had also become part of Facebook’s Instant Personalization program. I took a look at the site and discovered within minutes that it has a quite trivial XSS vulnerability. This particular issue should have been obvious given even a basic understanding of application security. It also indicates that Facebook is not doing much to evaluate the security of new instant personalization partners. Update 2: Scribd patched the most obvious XSS issue right about the time I updated this post: entering HTML into the search box brought up a page that loaded it unfiltered. Another search issue remained, however: starting with a closing script tag would still affect code later in the results page. After about half an hour, that problem was also patched. I’m glad Scribd moved so quickly to fix these problems, but I still find it disconcerting they were there to start with. I’ve not done any further checking for other XSS issues.

The post Instant Personalization Program Gets New Partner, Security Issue appeared first on The Social Media Security Podcast.

As each major player in today’s technology and Web-connected world makes a move to get a bigger piece of the social networking pie, they take on new risks they haven’t seen before. But if they only looked around, they’d be able to see and learn from the mistakes of others.

This week Apple launched “Ping”, a new social network that serves the iTunes community. But they don’t seem to have learned much from those that have ventured into this space before them. The Ping forums are being bombarded with spam posts containing phishing links. As blogger Chester Wisniewski, from antivirus maker Sophos points out, “Did they not see this coming?” (click HERE).

While Apple should have anticipated the problems, and tried a bit harder to protect legitimate users from this unwanted content, my advice to users is the same as for any social network: Use good link hygiene.

What is Good Link Hygiene?

Link hygiene is something we all need to practice on a daily basis, whether it’s while we’re reading Email or browsing social networks. It’s about avoiding the risks associated with malicious sites and content, as well as malicious file attachments.

There are many different ways in which hackers and scammers can trick you into giving them access to valuable information and computer resources.

Here are four of the nine items I teach people to check for when it comes to link hygiene which can reduce the risks of becoming a victim from malicious content in Email and websites:

1) Are your Email configuration options set to disable previewing of content or loading of images?

2) Is your computer’s operating system and application software (e.g. browser, Adobe Reader) up to date?

3) Do you have a reputable anti-malware product with up to date patches and virus signatures on your computer?

4) Do you know what your anti-malware product’s alerts look like, so you can recognize most fake virus alerts?

 So, Apple – as well as other social networks – should take some blame for allowing their social network to become polluted with malicious content. However, it’s almost impossible for sites to eliminate these risks entirely. It’s up to us, the users, to stay vigilant, and know how to avoid becoming a victim.

If you’re a Business Premium member of the Streetwise Security Zone, you can download the PDF version of this month’s coaching content on Link Hygiene by clicking HERE. This lesson includes a discussion of the various ways in which hackers and spammers try to trick you into going to malicious sites or entering sensitive information into fake forms.

I am now offering monthly briefings, tailored to organizations that want to build and sustain security awareness for staff. Just because your security team is too busy to do its own training and awareness doesn’t mean you can’t have an economical way to address human security risks. Please call or email me at the coordinates below…

Scott Wright

The Streetwise Security Coach

Join the Streetwise Security Zone at:
http://www.streetwise-security-zone.com/join.html

Phone: 1-613-693-0997
Email: scott@streetwise-security-zone.com
Twitter ID: http://www.twitter.com/streetsec

To receive weekly security tips and other notices about helpful content available on this site, please make sure you are on my list by clicking HERE, and entering your name and email address.

The post Link Hygiene – the same old risks apply to newly launched services like Ping for iTunes appeared first on The Social Media Security Podcast.

Share and Enjoy

• Facebook • Twitter • Delicious • Digg • StumbleUpon • Add to favorites • Email • RSS

The post Hacking Your Location With Facebook Places appeared first on The Social Media Security Podcast.

Download the updated Facebook Privacy & Security Guide here (pdf download).

The post Facebook Privacy & Security Guide Updated to v2.3 appeared first on The Social Media Security Podcast.