"You are interrupting Darwin's natural selection process, just like the guy who invented seat belts" - Dwight K. Schrute (disgustedly)
Given the current crush the infosec world has on the APT issue, here are some lessons that can be learned.
The boring stuff is what's important - People get caught up in the glamor of threats and they miss the boring stuff they should have been doing all along - building houses made out of bricks not straw. Then they get mad when the big bad wolf knocks over their straw house, but you know what - if it wasn't the big bad wolf it would have been a fire or a stiff breeze because straw just ain't that strong.
Now you'd say, yes but even bricks can be blown up and if we have a 100 dollars to spend in infosec we should spend a lot more on monitoring our straw house, and yes that's a defensible case.
But the industry is quite susceptible to freaking out over the latest threat and so the important gets lost by chasing the taillights of the latest urgent threat. Don't have time to re-design stuff now, there's (fill in the blank) threat right now! Rinse, repeat.
Here's the bottom line - basically NONE of the F500 ever designed their systems to run on the Web, they just accreted functionality over time and aded layer on top of insecure layer, straw on top of straw, until pretty much everything is connected directly or indirectly to the Web. Now this straw house would not be that big a deal if these enterprises had a half ass dependency on the Web like they did in the early 90s brochure-ware website days, but now the Web runs their businesses.
So until this is reconciled we'll just be on the same hamster wheel looking at different aspects brought on by the same cause.
An average F500 has thousands of developers cranking out code every single day, they have maybe 2 or 3 people doing security architecture and design, the enterprise developers' code is all connected to the Web in some way and its deployed into an environment which is a giant snowball of product marketecture.
There'll always be urgent threats to deal with, but there's an important effort to engineer systems so that they can function in the environment they now find themselves in. This effort currently is a blip on the radar screen of an average CISOs budget, and we never get off the hamster wheel until that changes.
To me the "let's monitor threats to our straw houses" approach is a best case evolutionary approach, its the logical, cost effective incremental approach. My take is that it won't get us where we need to be, currently security is a fire department and you can get better about detecting and responding to fires, but eventually Mrs O'Leary's cow burns down Chicago. Is this the cow's fault or the people who built the whole densely packed, highly connected city out of flammable material?
When they re-built Chicago they didn't use wood, they used brick, and I think we are well past evolutionary approaches because we are evolving as I said from layers and layers of straw, the time is now for a revolutionary approach towards security engineering. Judging from the various security conferences this does not seem as glamorous the infosec industry (probably because engineering looks like real work not golf), but an engineering revolution is what's required. As to what this effort should focus on:
Focus on survivability not threats - bankers like to blame the financial crisis on the housing meltdown ("who could have predicted this? house prices always rise! what do you mean someone with no money and no income can't pay this 6 figure loan?"), but the reality is the housing meltdown was the agent that exposed the weakness in the system - namely that banks had taken on these bad loans and then leveraged up 30 to 1 and 40 to 1. We've had numerous housing meltdowns in the past but they did not trigger anything nearly this severe because the banks were not leveraged.
Don't obsess about Mrs. O'Leary's cow or subprime threats, focus on your own balance sheet, how is it protected, what kind of margin of safety have you built into it. Margin of safety is a central concept in engineering. Where can you learn how to get a margin of safety for your system? Engineers know that you study failures - APT and a zillion other threats SQL Injection, CSRF and so on give us a rich library of failures to learn from. People run their businesses and lives on these networked computer systems and the systems are failing. Stay in ignorance or learn and build something better?
I vote for investing more time in your subjects, objects, sessions and transactions - building safety and survivability into these assets. This means in some cases that ctrl-alt-del is required.
Think of a typical web facing enterprise app transaction, starting with identity - username/password is ludicrous (but infosec blames the user for getting phished), the same scheme we started with in 1993 (when we were running brochure websites) and this is what we use to make all our authentication and authorization decisions on. Not only that the Subject AND the Object AND the SECRET are ALL stored on the server side, anyone see a problem with that? Dynamite and detonator in the same truck anyone?
What happens after this weak authentication process? The server typically/eventually calls to some messaging system like MQ, performs authorization WITHOUT authentication because it "trusts" the server in the DMZ, all its content, anyone else on its internal network, and all the identity
Then MQ posts the message to a mainframe which (of course) "trusts" MQ and executes some transaction on (presumably) the user's behalf.
Does this seem like something you would design for the web? Or does it sound like a mainframe computing back end built to operate in a high trust environment in say 1973 and then someone hacked a little username/password protected web server on the front end?
I have not even mentioned secure coding yet, its design, a broken design. It was a fine quick and dirty 1999 architecture but why would anyone think such a model could succeed over the long haul? When I go to the beach with my kids and we build a sand castle, it looks great but then a wave comes and clears it out, I don't run around screaming and blaming APT. If I am serious I don't build sand castles.
So let's replay that transaction from an identity margin of safety perspective, here are some things we need:
- Better authentication protocols - there are a number out there SAML, Information Cards to name two - infosec needs to engineer them into systems
- Way to propagate verifiable identity in the transaction - proxy, delegate, emissary, federation, and/or impersonation across domains and namespaces
- Way to provide integration security - protect messages and channels from spoofing, replay, and other threats - based on policy not based on what zone they supposedly run in
- Way to create, manage and enforce security policy on objects and sessions
- Way to write human-readable audit logs of the transactional events
Above is not a complete list but it is a completely different way from how security is often approached, there's no reason to accept an incremental improvement in security design. The design that's being incrementally improved is outmoded, threats are just the agent that show how easy that is - as Herb Stein said "anything that can't go on forever, won't". This should be a wakeup call for infosec as to the limits of an incremental evolutionary approach and where a new beginning is required. Don't hit the snooze bar, instead of reading "Building with Straw Level 301" let's do Brick Building 101, we'll come out better in the long run.
Comments