Perimeter
Guest Blog // Selected Security Content Provided By Sophos
What's This?
8/13/2013
02:45 PM
Maxim Weinstein
Maxim Weinstein
Security Insights
50%
50%

The More Things Change

Today's malware is more complex than ever, yet it's still based on three basic hacks

I've been working in the tech field for a bit over 15 years now. It's amazing to see how the industry and the technology has changed during that time. In my first job out of grad school, I taught corporate employees how to use Netscape Communicator on their Pentium II desktop PCs, which had just been migrated to Windows NT 4.0. I was the only person in my family with a cell phone -- a large, clunky object with a telescoping antenna and a belt holster. And IBM had just announced a new hard drive for notebook PCs that broke barriers by providing 6.4 GB of storage, three times the average in those days.

Malware has changed a lot, too, since 1998. Back then, floppy disks were just giving way to email as the infection vector of choice. Money was rarely a motivating factor for malware authors and distributors. The stereotype of the nerdy, young man wreaking havoc from his mother's basement probably wasn't too far off in many cases. The volume of new malware was so low that security experts could name and analyze each new sample.

Things look very different now, of course. Our multicore, always-connected devices can be infected via the network, email, SMS, USB, or the Web. Social engineering has advanced well beyond asking users to open a picture of Anna Kournikova naked (though variations of that trick still work). Behind the scenes, malware has "matured from a cottage industry to a Henry Ford style production line funded by organised crime," as my colleague Peter Szabo put it. Analyzing every piece of malware now would be impossible, with several new samples arriving each second of the day. Simon Reed, who runs SophosLabs, describes his team's work as a big data processing and mining operation.

With all the new technology and the rapid growth of "mass market" cybercrime, it may be easy to overlook one constant: Malware depends on finding a way to install or run on its target without the user's informed consent. And, in 15 years in the industry, I've only seen three fundamental ways for that to happen: exploiting a vulnerability, compromising user credentials, and/or tricking the user. That's it. An entire generation's worth of malware -- tens of millions of variants -- reduced to three simple hacks.

Fortunately, as security professionals, we already know how to defend against these three hacks, even if we don't always give them the attention they deserve. We stop exploits by building or buying more secure software, patching vulnerabilities as they arise, and implementing configurations that balance usability and security. We protect user credentials by implementing multifactor authentication, encouraging or enforcing the creation of strong and unique passwords, and securing the credentials in transit and at rest. Users are human, so they'll always be fallible, but security awareness and education -- emphasizing the why, not just the how -- can go a long way in reducing susceptibility to social engineering.

It's easy to describe these defenses, but implementing them properly, consistently, and completely is much harder. Security products help by providing visibility and by leveraging automation and vendors' expertise. They also fill the inevitable gaps in an organization's defenses, detecting threats that slip through. As such, security tools have had to evolve as the threats have evolved. Firewalls have given way to UTMs, antivirus software has developed into multilayer endpoint protection, and Web and email filters have helped users make fewer and better decisions about what to download or open. They may not be perfect, but they're better than their predecessors, and they're a heck of a lot better than nothing.

So, yes, a lot has changed in 15 years. All things considered, I'd rather not go back to my Pentium II and my dumb brick of a cell phone, even if security was simpler then. But going back to the basics of malware protection, with a little help from today's technology? Well, that doesn't seem like a bad idea at all. Maxim Weinstein, CISSP, is a technologist and educator with a passion for information security. He works in product marketing at Sophos, where he specializes in server protection solutions. He is also a board member and former executive director of StopBadware. Maxim lives ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
macker490
50%
50%
macker490,
User Rank: Ninja
8/24/2013 | 1:05:54 PM
re: The More Things Change
....it may have, although it may be that some software builders are less than totally well-intentioned...

when you link that library how do you know what you are getting ?

remember: "zero defects" ...is a responsibility not a right. Zero Defects is what you do, not what you get.
Maxim Weinstein
50%
50%
Maxim Weinstein,
User Rank: Apprentice
8/23/2013 | 1:24:12 PM
re: The More Things Change
Excellent point, Mike. In the case you describe, the malware probably used one of my three core hacks to get in to the original supplier's build. But there's also the potential for deliberate insertion of a backdoor or spyware component by an upstream supplier, or by an insider within an organization, for that matter.
macker490
50%
50%
macker490,
User Rank: Ninja
8/22/2013 | 11:17:04 AM
re: The More Things Change
you missed one: supply system integration.

defending against malware requires authentications and authorizations. when software is presented it must be authenticated: is this what it claims to be? and then it must be authorized by the system administrator. earlier systems didn't even bother to check they just let anything in. oh well.

in supply system integration a reputable supplier un-knowingly integrates malware as he completes his builds. he then signs for his works and forwards it on the supply system or to the customer, signed and sealed, malware unknowingly included.

only a zero-defect program can control this: each builder along the supply line must take responsibility for validating not only his own work -- but -- other inputs he is incorporating into his product. this seems daunting at first but if you start at the beginning and follow through it can be done. when I compile any module I must assume responsibility for it being what I say it is.

the implications are enormous. but I think we've about had it with the un-checked method.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-2184
Published: 2015-03-27
Movable Type before 5.2.6 does not properly use the Storable::thaw function, which allows remote attackers to execute arbitrary code via the comment_state parameter.

CVE-2014-3619
Published: 2015-03-27
The __socket_proto_state_machine function in GlusterFS 3.5 allows remote attackers to cause a denial of service (infinite loop) via a "00000000" fragment header.

CVE-2014-8121
Published: 2015-03-27
DB_LOOKUP in nss_files/files-XXX.c in the Name Service Switch (NSS) in GNU C Library (aka glibc or libc6) 2.21 and earlier does not properly check if a file is open, which allows remote attackers to cause a denial of service (infinite loop) by performing a look-up while the database is iterated over...

CVE-2014-9712
Published: 2015-03-27
Websense TRITON V-Series appliances before 7.8.3 Hotfix 03 and 7.8.4 before Hotfix 01 allows remote administrators to read arbitrary files and obtain passwords via a crafted path.

CVE-2015-0658
Published: 2015-03-27
The DHCP implementation in the PowerOn Auto Provisioning (POAP) feature in Cisco NX-OS does not properly restrict the initialization process, which allows remote attackers to execute arbitrary commands as root by sending crafted response packets on the local network, aka Bug ID CSCur14589.

Dark Reading Radio
Archived Dark Reading Radio
Good hackers--aka security researchers--are worried about the possible legal and professional ramifications of President Obama's new proposed crackdown on cyber criminals.