Traditionally, in early January, there are a raft of predictions from the security industry about what is likely to happen over the next 12 months in terms of emerging threats, consumer and corporate focus in terms of what people will be doing with their technology, and a general amount of crystal ball gazing.

Rather than make predictions that are doubtless going to come back in 12 months’ time and bite us somewhere unpleasant because they haven’t come true, it is perhaps better to focus on a story that has come out early in the year from Japan and is detailed here: http://www.yomiuri.co.jp/dy/national/T120102002799.htm – the headline being that the Japanese Government has entered into a relationship with Fujitsu to create a “good virus”.

Leaving aside the fact that, although this has been widely reported through several channels, there only appears to be one main source for this – the above site – and journalists are normally shy of putting out stories without corroboration from an independent source, this raises a number of questions.

There is, of course, a long standing debate going back many years as to whether there is such a thing as a good virus, and if so how it is defined, for example here: http://www.people.frisk-software.com/~bontchev/papers/goodvir.html. We’ll not get into that here, but looking at the story it seems to be rather light on technical details. Perhaps this is understandable, given that the parties involved would not want the financial investment to go to waste, but there are a few things that can be implied – note that this is supposition on our parts and should not be taken as any insider knowledge!

Firstly, the story reports that the code (let’s call it code, as calling it a weapon gives it some sort of legitimacy, an issue that we’ll get onto momentarily) is capable of identifying both the sources of the attacks and the intermediary hosts used, and indeed states later in the article that this is used for looking at DDoS attacks. Once a host is identified, it would seem as if the code then copies itself to the infected host before running operations to disable the host from being part of the attack – whether this is by disabling a particular executable or by terminating the hosts’ internet connection isn’t specified.

The important part of this is that the code copies itself to the hosts. This means exploiting a vulnerability, presumably the same one that the original code exploited to get itself onto the box in the first place, or the command and control channel that is used by the malware itself. One of the things that both operating system patches and anti-malware vendors try to deal with is ensuring that the vulnerabilities are not exploitable, so that means that (in the case where people have good patching procedures, and let’s be honest don’t we all? Erm…) the vulnerability could no longer exist, and where anti-malware signature updates are applied, and scans are run regularly, the vulnerability may have been flagged already or the malware may have been already removed.

This leads to a situation where the code could be trying to get onto a machine that is already cleaned up or, at the very least, has had the vulnerability patched, and doesn’t even touch on whether there are any self-protection mechanisms written into the malware itself.

Then there arises the question as to whether the methods used by the code will themselves be determined as malicious and stopped by anti-malware vendors – the general gut feeling around WCL is that it probably will be – after all, it is a “virus”.

The testing has taken place in a “closed environment”. No details here are given, but let’s assume that it is mostly Windows based. The first questions that should be being asked about this are: Was the environment used homogenous (ie all the same type of operating system) or heterogenous (different variants of Windows, different patch levels on each)? In order to simulate a large scale DDoS, how large was the environment (number of hosts)? Were they real hosts or virtual hosts? How many of the botnet variants were used? How adaptable is the code to new types of code used in these attacks? How adaptable is the code to non-botnet malware?

In order to get a seriously large replication of a DDoS attack, obviously none of the major industry tools for traffic creation can be used, as they don’t have “real hosts” (including virtual) for the code to go back to and “clean up”. This implies that it works on a small scale and, for something as specific as the operation of this code and the type of malware that it appears to be targeting, there really is no substitute for seeing how it works in the real world.

Once we get past the technical issues, there are other more holistic issues to consider – will AV companies be subjected to pressure by the Japanese government to exclude detection for this code? That has, when tried previously, normally failed, and authorities using “viruses” was recently in the news in Germany in October last year when Federal police admitted to using code to monitor Skype (http://www.theregister.co.uk/2011/10/12/bundestrojaner/).

What are the legal implications for this? After all, the intention seems to be to put a piece of code onto a users’ machine in the same way as malware, without asking the user first, and given that there is no legal jurisdiction over the internet as it is a global network, there are potentially issues if this code gets onto machines in, for example, the US, Russia, China, any of the EU countries, and so on. Fujitsu and the Japanese government could find themselves at the center of a lot of legislation very quickly. Surely, when this project was mooted in 2008, somebody in either Fujistu or the government should have considered that there might be legal implications and started preparing for it then, rather than trying to sort it out after the code is written and ready to be released – any delays here (from a purely technical point of view) mean that the code will be outdated and potentially useless by the time that it actually gets released.

This will be an interesting time as the lawmakers try to sort out whether they can use the code and then, if they can, what subsequently happens with the AV industry and whether the code itself can make any inroads at all into reducing the number of DDoS attacks. Perhaps the one prediction we should make is that we’ll be watching this story with interest.

#3.1

(via PaleoFuture)

Obviously crime is additive, not subtractive.

Reading this, I started out thinking of it as the usual sort of “hey, where’s my flying car!” future-gazing.  But by the end, their description of the current state of malware was not too far off the mark.

Except that “cassette” bit.  That made me giggle.

Because clearly storage media wasn’t going to advance past (very easily destroyed) 1970s technology.

For those of you who freak out about Facebook apps and their privacy problems, will you stop using apps on smart phones as well?  Not that I could blame you.   It’s a thorny issue, balancing profitability and privacy…

We all decide what level of privacy invasion we’re willing to accept – in the form of which country we choose to inhabit, how we do or do not use social networking, how we interact with retail establishments, how we interact with government agencies and banks, how we interact with strangers and acquaintances, even how we interact with friends and family.  But more and more, the decision is being made after our privacy’s already been breached without our knowledge.

This is the part that bums me out more than anything.  It’s the de facto standard now for some third party to discover the breach.  And the outcry is so small that little changes.

Do you think this will change in the future?  If so, how?  Will it involve government regulation such as has been recently been suggested?

Facebook has this feature, which allows you to be incredibly granular about who sees what on your profile page.  Not just status updates in general, but individually.  And your photos, including specifically “tagged photos” of you which other people have uploaded.  And it includes your notes.  And… on and on.  To my mind, Friend Lists are the most widely useful security feature they’ve put on the site, period.

Here’s how I break things down:

1. Close friends:  People I’d discuss pretty much anything with.  Or at least anything I would put in writing on the Eternal Interwebs.
2. Local folks: Anyone I’d share location-based info with, or whose local-info knowledge I would like to plumb.
3. People who I don’t interact with much: This is mostly to keep from spamming people that I don’t think would want to be bombarded with every ridiculous thing I feel like sharing.
4. Work friends: People who I met through work who would likely be interested in my more personal-interest posts.
5. Other work people: People who I’m sociable enough with to keep on a Facebook friend list, rather than strictly interacting with them on LinkedIn/Twitter/etc.
6. Non-people: For whatever reason, a lot of interest-type things show up as “friends”, and I share as little as possible with them.
7. Limited Profile: This is a list which is (was?) created by Facebook, which I find has really, really limited access to our profiles.  I could find no way to allow them access to pictures or most posts, which I vaguely recall was in some message box I read at some distant point in the past.  I couldn’t find a lot by way of explanation either on Facebook or on the wider internet.

I’m sure you’ll have your own break-down based on your own social network.  Family? School? Volunteer groups? Church? Old hometown?  Whatever would make your social life easier to separate out.

The first trick is to separate people out into appropriate groups.  You may wish to have a certain amount of overlap, or certain groups which are subsets of others.  I personally don’t have overlap groups, as I’m not good at calculating who should/shouldn’t see what that way.  You may be better at that, just keep the added calculation in mind.

Now, here’s the tedious bit.  (Or the fun bit, if you’re among those of us who organize their sock drawers for excitement on cold and rainy winter nights!)

• To create new lists, go to the “Edit Friends” friends screen under “Account” up there at the top right of the screen.
• There’s a “Create Lists” button on the top center of the “Edit Friends” screen.
• If you wanna create lists first and then fiddle with who’s on what list after your lists are created, hover over the area just shy of the X button on the right-most area of the “Edit Friends” screen, and an “Edit Lists” menu will show up.

Now, what will those lists be able to see?

• Go into Account Settings.  (You’ve set up what Basic Directory info is visible already, right?)
• In that big box in the middle of the screen, there’s a check list of who sees what.  Down at the bottom of that, there’s a link on the left called “Customize Settings”.   Click that.
• Now go to town on all those little drop-down menus!
  “Custom    Edit” is where those new lists come in handy.  Don’t want your professional contacts seeing your tagged photos?  Exclude them!  Don’t want anyone but your closest peeps to see those photos?  Well then, include just that list.
• Keep in mind, security settings for photos are on a per-album basis for anything you upload.  Same with status and notes.  You can, however, set defaults.

N.B.  I don’t recommend putting anything as “everyone” on a personal (read: non-professional) profile, but that’s my own level of paranoia/privacy.  YMMV.

Now, before you consider the task finished, use that “Preview My Profile” button up top to check how things look to different members of friend lists or people who’re not on your friend list at all.  Are you okay with what’s visible to whom?

Keep in mind that security policies can and do shift site-wide, and I’ll reiterate that you should never put in writing what you don’t want to be showing up on Google under your name.  And you really should be periodically Googling yourself (including any email address you give out to people) to make sure you’ve not got anything out there you don’t want discussed in a job interview.  Consider it a credit check of your credibility.

Oh.  No?

Instead, how about a hefty dose of irritation to underline the incredible quantity of information that gets sent to Google as you surf the web?

I couldn’t help but giggle when I saw the video attached to this article on Mashable.  Oh, the horror!!  The honking!!  Much like the “Autotune Double Rainbow Remix” it combines two totally heinous things in such a way that I can’t help but laugh hysterically.

Nothing is really suggested to help you avoid the information seepage, so maybe the video itself is enough of a wake-up call for people that the alarm would be unnecessary.  But if you’d like to illustrate the point to any disbelievers in your house or office, maybe you could do an extended demonstration.  I’d suggest you bring earplugs for yourself though.

I particularly liked this quote from Brad Arkin, Adobe’s senior director of product security and privacy:

“We’ve done everything we can to build the walls of that sandbox as tall as possible,” Arkin said. “We’re not sure how the offensive community will react. They may move on to a different product and attack QuickTime instead, or they may look at other applications that are easier to attack. Or they may find clever ways to carry out some type of malicious activity against Reader which are quite different than the attack techniques that they use today.”

It’s decidedly not warm and fuzzy, but it tells me they have decently realistic expectations.  Malware authors aren’t going to be stopped by this change; they may focus in the short-term on other products but they may just find new ways in.

I can’t speak for any of the other organizations out there which might wish to squash us for monetary gain, but I can speak for the individuals who make up AMTSO.  The people who make up this organization are, by and large, researchers.  Not “Symantec Researchers” or “Microsoft Researchers” or “McAfee Researchers”, just researchers.  Some don’t work at an anti-malware or testing organization at all, some who who will work at one company today but a different one next year.

That is to say, they’re simply the propeller-heads who are way more interested in doing things in a scientifically correct way than in doing things in the way that maximizes financial gain.  They understand that testing can provide both users and vendors valuable information when they’re done well.  They will argue minutia till everyone’s blue in the face, to make sure that the recommendations they’re making are absolutely accurate and cover every last corner-case.

I say this with the utmost love and respect, of course – many of them are among my favorite people in the world.  It’s hard not to have a deep appreciation of those who look past vendor boundaries, and give up countless nights and weekends, working to protect a world full of users they may never meet.

Having been a propeller-head working for a vendor myself not too long ago, I know how frustrating poorly designed tests are.  They provide little useful information while creating firey hoops to jump through, which is just exhausting.  Every vendor gets burned from time to time.  That’s a large part of why I am where I am now – at West Coast Labs, I’ve been able to help change my little corner of the testing world.  When I first started talking to the fine folks here, I saw the commitment they already had to leading the testing industry by good example.

I tend to agree with David’s point about the “Standards” in AMTSO.  “Standards” tends to bring to mind ISO type organizations, which is not really what AMTSO is intended to be.  No one is going to show up in a suit and brandishing a clipboard, in order to audit testers for AMTSO-compliance.  Instead, maybe “Recommendations”?  “Suggestions”?

I’d like to amend and clarify a couple of points, after reading the comments.  I’m sure this will cause a couple people to shout at their computer due to my oversimplification, but I’m not trying to address every last corner-case.

Malware can be broken down into two basic categories, viruses and trojans.
Malware itself simply means “code created with malicious intent”.

Viruses are self-replicating code.  That means code which copies itself.
Trojans are malicious code which is not what it purports to be.
Worms are viruses which copy themselves over networks (email, IM, web, whatever)

There are viruses and trojans for every major operating system, and for most minor ones.
There is more malware written for Windows machines, this does not mean other OSes are immune or not-targeted.

Most drive-by-downloads and “browser hijacks” are trojans.  Most rootkits are trojans.  Same with scareware, spyware, ransomware and backdoors.

Adware is not strictly speaking malware but a “security concern” or Potentially Unwanted Program as its presence/functions are often poorly documented and many system administrators consider its presence on their network undesirable.

Most malware these days is not intentionally data-destructive.  That’s not to say it isn’t unintentionally data-destructive.  Regular incremental backups are a good safety precaution – malware these days tends to wriggle its way so deeply into systems that many people recommend to just nuke and pave a compromised machine.

Does this clear things up?

Imagine my surprise when it turned out to be a well-balanced and considered view of the future of the malware environment!  And in a main-stream-ish magazine, no less!

It does leave me feeling somewhat optimistic, that perhaps the security industry’s collective wailing and gnashing of teeth have had some impact on hardware and software designers thought processes.  Wouldn’t that be nifty!

I don’t expect, and I don’t think the author expects, that malware will truly come to an end.  What I do think is that malware will begin to be much more difficult for bad-actors to create, and perhaps the profitability for them will decrease if there should be such a time that we move away from the existing/legacy software models (and, of course, assuming we don’t give them a hot new platform).  I certainly won’t happen today, and certainly not tomorrow, but maybe 15 years down the line?

Of course, that says nothing about a decline in the future of phishing, so I’m sure there will still be a security industry even if that comes to pass…

That being said, both of us are pretty privacy conscious.  We’ve been conscious from the outset that “the Internet is forever” and that content has a way of wandering outside its origin.  That picture you post today is now pretty well out of your control, and unlikely to stay where you put it – people can easily copy it and post it elsewhere, no matter the protection in place.

Some of our mutual friends have had to deal with the reality of their web-presence, moving from college to the “real world”.  Yes, that info you posted when you were a young’un can come to bite you in the hindquarters when it comes time to move your life into the professional realm.  If it’s not something you would want to have to explain to your grandma, just don’t post it, m’kay?

I also recently overheard a girl who had worked for the Peace Corps talking about how officials in D.C. had contacted her about information she’d posted on her (then public) blog which they found objectionable.  She was quite shocked that anyone outside her meat-space social circle would be reading her blog.  When she was told by the officials what could be done with the information she was sharing, the girl was absolutely dumbstruck.  It’s tempting to think we’re alone in this vast web-o-sphere, but it’s not analogous to the analog world – India is equally as close as Indiana.

There seems to me to be a few basic issues:

1. The pace of change has way outpaced our ability to properly appreciate their consequences.
2. There has not been a culture of sites offering transparency, but of pushing boundaries until people start screaming.
3. Users have had a “head in the sand” attitude about all things technology:  Until it’s been proven that something is harmful, they’ll use it blindly.

It strikes me that the best thing for the future of social networking is to adopt a “User Bill of Rights” like the one outlined by this San Francisco Chronicle article.

1. Honesty: Tell the truth. Don’t make our information public against our will and call it “giving users more control.” Call things what they are.

2. Accountability: Keep your word. Honor the deals you make and the expectations they create. If a network asks users to log in, users expect that it’s private. Don’t get us to populate your network based on one expectation of privacy, and then change the rules once we’ve connected with 600 friends.

3. Control: Let us decide what to do with our data. Get our permission before you make any changes that make our information less private. We should not have data cross-transmitted to other services without our knowledge. We should always be asked to opt in before a change, rather than being told we have the right to opt out after a change is unilaterally imposed.

4. Transparency: We deserve to know what information is being disclosed and to whom. When there has been a glitch or a leak that involves our information, make sure we know about it.

5. Freedom of movement: If we want to leave your network, let us. If we want to take our data with us, let us do that, too. This will encourage competition through innovation and service, instead of hostage-taking. If we want to delete our data, let us. It’s our data.

6. Simple settings: If we want to change something, let us. Use intuitive, standard language. Put settings in logical places. Give us a “maximize privacy settings” button, a and a “delete my account” button.

7. Be treated as a community, not a data set: We join communities because we like them, not “like” them. Advertise to your community if you want. But don’t sell our data out from under us.