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.

Perimeter

1/25/2013
10:17 AM
Gunnar Peterson
Gunnar Peterson
Commentary
50%
50%

The Three Worst Words In The English Language: Can't We Just?

The road to poor identity and access management architecture is paved with "can't we justs." It's 2013: Find a way

When learning something new, especially a technical something, it's great to hear the words "for example" because you're about to see something more concrete that helps the abstract make more sense.

Conversely, when doing design and development work, it's awful to hear the words "can't we just" because you're about to hear a defense of kicking the can down the road -- more status quo.

"Can't we just" is used to justify all manner of things:

"Can't we just replicate the passwords?"

"Can't we just leave passwords cleartext?"

"Can't we just use one way SSL to solve everything?"

"Can't we just use the same system we have for the last 15 years for our new Cloud?"

"Can't we just use the same system we have for the last 15 years for our new Mobile apps?"

"Can't we just hardcode XYZ?"

What people are really saying when they say "can't we just" is, "Can't we assume tomorrow will look like today?" This may work in some areas of IT (although I am doubtful), but it's flat-out hazardous in security.

The prefix for the majority of suboptimal designs is "can't we just." When you hear that phrase, brace yourself. I am all for being practical, but systems age more like milk than wine. They do not necessarily get better with age, software evolves, and, more importantly, so do attacker's capabilities. To illustrate this latter point, consider Dave Aitel's prediction for 2012 that mobile platforms would fail:

You know what didn't pan out? "Mobile attacks" in commercial attack frameworks. The reasons are a bit non-obvious, but deep down, writing Android exploits is fairly hard. Not because the exploit itself is hard, but because testing your exploit on every phone is a nightmare. There's literally thousands of them, and they're all slightly different. So even if you know your exploit is solid as a rock, it's hard to say that you tested it on whatever strange phone your customer happens to have around.

And of course, iOS is its own hard nut to crack. It's a moving monolithic target, and Apple is highly incentivized by pirates to keep it secure. So if you have something that works in a commercial package, Apple will patch it the next day, and all your hard work is mostly wasted.

Now there are some good reasons why this did not happen; in my view, the fragmentation in mobile is a real issue for developers, testers, and attackers. But it's not a long-term advantage -- it's a delay of game, a speed bump. The point I would like to make here is that you could read those comments as, "Well, it's too hard for attackers. Can't we just live with the same mobile security model in 2013? After all, it was good enough in 2012."

But guess what? It's not a static environment. Attackers don't remain in some little, limited snow-globe world: They learn, and tools get better. What was good enough last year is not good enough this year.

Instead of can't we just kick the can down the road, we should find a way to make improvements in our security architecture.

Gunnar Peterson is a Managing Principal at Arctec Group

Gunnar Peterson (@oneraindrop) works on AppSec - Cloud, Mobile and Identity. He maintains a blog at http://1raindrop.typepad.com. View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
gbaggett750
50%
50%
gbaggett750,
User Rank: Apprentice
1/30/2013 | 3:34:37 PM
re: The Three Worst Words In The English Language: Can't We Just?
Can't we just....- Doesn't always imply kicking the can down the road.- It is also a cry for help and also may lead to a possible solution so DO NOT just dismiss anything that is said after these three words.- To do so outright is showing ARROGANCE toward ... (possibly your user).--

Listen to what they have to say and then explain to them why it may not work withing the confines of the subject.- If you cannot do that then maybe you do not understand well enough yourself to be dismissing his solution outright.--

I have noticed that sometimes in the process of explaining something that-I develop a better undertanding of the situation and have discovered alternate solutions during the process that may or may not involve the solution that I have previously suggested.

Bleeding edge isn't always the best (although some technologists believe so) because sometimes the inconvenience toward the user needs to be balanced with what that user is doing.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-26120
PUBLISHED: 2020-09-27
XSS exists in the MobileFrontend extension for MediaWiki before 1.34.4 because section.line is mishandled during regex section line replacement from PageGateway. Using crafted HTML, an attacker can elicit an XSS attack via jQuery's parseHTML method, which can cause image callbacks to fire even witho...
CVE-2020-26121
PUBLISHED: 2020-09-27
An issue was discovered in the FileImporter extension for MediaWiki before 1.34.4. An attacker can import a file even when the target page is protected against "page creation" and the attacker should not be able to create it. This occurs because of a mishandled distinction between an uploa...
CVE-2020-25812
PUBLISHED: 2020-09-27
An issue was discovered in MediaWiki 1.34.x before 1.34.4. On Special:Contributions, the NS filter uses unescaped messages as keys in the option key for an HTMLForm specifier. This is vulnerable to a mild XSS if one of those messages is changed to include raw HTML.
CVE-2020-25813
PUBLISHED: 2020-09-27
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, Special:UserRights exposes the existence of hidden users.
CVE-2020-25814
PUBLISHED: 2020-09-27
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, XSS related to jQuery can occur. The attacker creates a message with [javascript:payload xss] and turns it into a jQuery object with mw.message().parse(). The expected result is that the jQuery object does not contain an <a> ...