Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Analytics

Security's Three Deadly Sins

It all boils down to sloth, hubris, and greed

People love lists, and I'm no different. I'm a sucker for all those "10 Best Places to Live" sorts of things, even though I know the town where I live won't make the list.

At the beginning of the year, I was looking at a bunch of the "XX Top Threats" and "XX Biggest IT Dangers" lists, and found that I couldn't really disagree with any of them. There is, truly, a lot of stupid activity you can undertake using a computer, and much of that stupidity will have consequences.

Still, as I looked more closely at the lists, I began to feel that they could have been much shorter. Because, in the end, most of the security dangers we see are the result of one or more of three basic problems: sloth, hubris, and greed. Since we've just come through the year's shortest month, then, I offer my own shortened list of dangers to your network.

1. Sloth

No, not the three-toed Amazonian mammal (though I can't image that one would do much good for your NOC). Laziness, dereliction of duty -- call it what you will, it boils down to not taking the time to do things right. Let me give you some examples.

  • Defaults. Every piece of hardware ships with a default username and password. Some have default network names, security keys, or SSIDs. There are lists of these defaults on the Internet, and every hacker has a copy of the list. Take the time to change the defaults unless you want to host a bunch of tenth-grade hackers on your corporate server.

  • Training. No one really likes training, whether they're giving or taking the class. But that doesn't mean training isn't critical. I can't count the number of times I've heard a user say, "I didn't know we weren't supposed to do that!" after allowing criminals to run amok in the enterprise network. Make the time to train every user, and build additional training and refresher courses into the employee system.

  • Bad Passwords. No, Sparky, spelling your username backwards as a password isn't brilliant. It is marginally better than simply repeating your username as the password, but the margin isn't huge. It doesn't take long to create a system of passwords that you can remember, that are long enough to be difficult to brute-force, and that don't involve your name or your birthday. Figure it out.

2. Hubris

Nothing sends a chill down my spine like hearing a corporate official say, "Our network is completely secure." Yes, and I'm quite handsome -- but in each case, keywords are open to interpretation. I find that the folks who are most at ease with their level of security tend to be the ones who know the least about it. But hubris does take some common forms.

  • The magic bullet. "We've installed the DunderWall V19.6, and it makes every device impervious to every attack." If your system is still usable, it's vulnerable. I'm a big believer in the Swiss cheese model of security -- you know, the one where you acknowledge that there are likely to be holes, you've just made the block thick enough so that none of them go all the way through. I've yet to find that magic bullet, and your company is still looking, too.

  • Our programmers are brilliant. They may be, but experience says if they've built a Web-facing application, they've created some vulnerabilities. Depending on their level of sloth, they may leave small, subtle holes or large, gaping holes, but you should count on security issues. This isn't to denigrate the programmers -- they were hired for their strengths in programming, not security. Build additional layers of security around their work, and everyone will sleep better.

  • We remember. You've gotten the old-time password religion and decided that everyone needs a 16-digit strong password with no string that can be found in a three-character dictionary lookup, at least four punctuation marks, and an even distribution of characters and numbers. The password must be changed every 30 days, and no one, under pain of dismissal, can write it down. Oh, yes, you don't believe single sign-on is secure, so every application and network segment has its own password, and they must all conform to the corporate standard. Get real. You've just made things so ridiculous that you practically require your employees to break the rules. Good multi-factor authentication, yes; ludicrous memorization requirements, no.

3. Greed

Take "buy low, sell high" to its logical conclusion, and you want something for nothing. Whether you're on the acquiring end of the transaction or the providing end, it's a dangerous place to be.

  • Free hotspots. Who doesn't love a good, free wireless hotspot? Most corporate security folks could do without them, especially when they're near a bogus hotspot set up by an enterprising hacker. If you haven't taken the time to train your users in the difference between "ad hoc" and "infrastructure" connections, you'll hate free hotspots a lot more.

  • Free software. Software, photos, gadgets. Geegaws. Bright shiny strings. Convincing users that they aren't helping when they bring in the latest freeware can be a full-time job. Train your users that they shouldn't bring random freeware crap to the table, and keep the ports closed.

That's it -- a top-20 list compressed to three of the seven deadly sins. Sometime soon I'll get around to the other four -- but since patience is a virtue, you'll have to wait just a bit.

— Curt Franklin is an enthusiastic security geek who used to be one of the Power Rangers (the red one, we think). His checkered past includes stints as a security consultant, an IT staffer at the University of Florida, security editor at Network Computing, chief podcaster for CMP Technology, and various editorial positions at places like InternetWeek, Byte, and Hog Monthly. Special to Dark Reading.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 6/1/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-13757
PUBLISHED: 2020-06-01
Python-RSA 4.0 ignores leading '\0' bytes during decryption of ciphertext. This could conceivably have a security-relevant impact, e.g., by helping an attacker to infer that an application uses Python-RSA, or if the length of accepted ciphertext affects application behavior (such as by causing exces...
CVE-2020-13758
PUBLISHED: 2020-06-01
modules/security/classes/general.post_filter.php/post_filter.php in the Web Application Firewall in Bitrix24 through 20.0.950 allows XSS by placing %00 before the payload.
CVE-2020-9291
PUBLISHED: 2020-06-01
An Insecure Temporary File vulnerability in FortiClient for Windows 6.2.1 and below may allow a local user to gain elevated privileges via exhausting the pool of temporary file names combined with a symbolic link attack.
CVE-2019-15709
PUBLISHED: 2020-06-01
An improper input validation in FortiAP-S/W2 6.2.0 to 6.2.2, 6.0.5 and below, FortiAP-U 6.0.1 and below CLI admin console may allow unauthorized administrators to overwrite system files via specially crafted tcpdump commands in the CLI.
CVE-2020-13695
PUBLISHED: 2020-06-01
In QuickBox Community Edition through 2.5.5 and Pro Edition through 2.1.8, the local www-data user has sudo privileges to execute grep as root without a password, which allows an attacker to obtain sensitive information via a grep of a /root/*.db or /etc/shadow file.