._.

#04

I love how you line up your equals signs.

It really makes the code easier to read.

I noticed that you added a post-commit hook on the repository that rejected my last patch because I had my curly braces on the same line as my conditional statements.

I tried a second patch where I removed the brackets entirely because it was only one line, and that didn’t go through, either.

Thankfully I figured out how to use the return key, and that got the code into the system.

It’s amazing that we have a system that makes it literally impossible for interns like me to push bad code.

I sure am learning a lot.

I did notice, though, that all the requests in the system are GET requests. That seems a little insecure.

You’re right, you’re right. I’m really overthinking things. I’m probably just not understanding it because it’s so innovative.

They definitely didn’t teach this kind of stuff in school.

One minor thing—and I’m sure it’s pretty silly—is that you’re outputting the MySQL database connection details using echo every time the connection doesn’t work.

Oh, you’re right. The user doesn’t see error messages; that’s why we test.

You end a lot of your SQL statements with WHERE $id. I’m pretty sure you want them to be WHERE id=$id, otherwise everything will get selected.

Ah, it’s an abbreviated syntax? Of course. I mean, someone would have caught it before if it were so blatantly broken, right?

Besides, that’s what backups are for.

Really, though. I love how you line up your equals signs.

What other languages have you programmed in? You know, C, Java, Python?

Wow, XML, XSLT, HTML, CSS and jQuery?

You sure do have a broad skill set.

Here I am, taking on massive student loan debt for this CS degree and they glossed over all of those in a single elective.

Really? You didn’t even go to college?

I don’t believe that at all.

#03

“If you’ve never caught yourself overcomplicating things, you’re not paying attention.”

I’m assuming you’re a pretty good developer.

Really, I mean that.

You’re going out of your way right now to read up on your field.

Not everyone does that.

You’re probably pretty good at spotting the good new technologies, the really world-shattering ones.

You clone the repositories, compile the binaries, play with them yourself. Maybe you write an experimental web server and benchmark it against your previous bag of tricks. Maybe you make changes to the source and recompile, just to see what makes the underlying architecture tick.

You read through the code, get to know the quirks of each of the individual developers, watch dramas unfold underneath the pull requests and user-submitted tickets. You lurk the IRC channel, silently watching first, then asking questions as your own projects take you beyond the basics of the README.

As new screen names pop up in the IRC channel, you find yourself wondering where they’ve all come from. Now you’re the guy helping the newbies, critiquing their gists and pastebins, swapping war stories and design patterns with the other veterans.

Finally, the moment of truth arrives: you push a commit. After days of heated debate, enough of the developers are on your side that it’s accepted into the core repository. It’s a small contribution, really, but you wear it like a badge of honor.

You’re not one to boast, but if someone were to introduce you as an expert, you’d probably shrug and say something like, “The more I learn, the more I realize how much I don’t know.”

Your day job isn’t as exciting. The money is good and the people are nice, but you’ve been using the same boring languages and libraries for years. You find yourself doing the same basic tasks over and over again, following the company practices and patterns almost by rote. A glorified typist, but it pays the bills.

The hot new technology has gained enough of a following by this point that your coworkers begin discussing it in passing. You seize the opportunity to share your experience. Most of the annoyances you’d normally deal with don’t even exist anymore. You’ve really started to think differently about the problem space.

Hell, if you were allowed to use your pet technology on your current work assignment, you’d finish it in half the time with fewer bugs, and it would scale ten times as well.

Eventually, the higher-ups catch wind of your hobby. Your supervisor sits you down and tells you about a new team, a new project. It will be cutting edge, succeeding where others have failed. You’ll be given a key role. The opportunity to pick the technology stack.

You walk back to your desk with a new swagger. The first thing you do is close the bloated IDE you’ve been using for the past few years, abandoning all the patterns and practices you’ve had drilled into your head. This project is going to succeed where others have failed.

You hand-pick the rest of your team, choosing the developers whose eyes glazed over the least when you talked about your pet technology. You pull them into a meeting room and give them the whirlwind tour of everything from the underlying platform and its advantages to the major API calls and the little known quirks.

One of the developers, Ben, interrupts you. “Don’t you think this might be a bit overkill? We’re just trying to help a handful of internal users create custom slideshows.”

You smile patiently, ponder the question for a moment. You must not have explained everything properly. “It only sounds complex because you haven’t tried it. Trust me, I’ve used this stack for over a dozen projects.”

You watch incoming commits like a hawk, hoping to nip any issues in the bud. Ben is being particularly troublesome. You picked him because he’s a damn good developer, decades of experience, but perhaps he’s too stuck in his old ways to really grok the new platform.

“Ben, we need to talk about your commits.”

“What’s the problem? They’re all tied to feature requests.”

“You’re using the exact same patterns here that you use in your Java code.”

Ben shrugs. “All the tests are passing.”

“The reason we’re using this stack is so that we can accommodate a near-infinite amount of users by utilizing cloud processes in an entirely intuitive, transparent fashion. That’s why the rest of us have been using closures and an event-driven structure, to take advantage of the platform. Otherwise, what’s the point?”

Ben nods, dully. “Where is this in the product requirements document?”

You sigh. Ben is starting to test your patience. Perhaps he’ll never understand what you’re trying to accomplish here. “It’s implied. Unit tests aren’t in the PRD, either. It’s our job to make sure everything is completed to a high standard.”

The projects trudges on. You give up on Ben, but rewriting his code puts everything behind schedule. Now you’re working late nights and weekends to set things right. The deadline creeps closer while deliverables flatline, prompting an awkward meeting with your supervisor.

“I’m the only person who really understands our technology stack,” you explain, calmly. “We need to hire people who are more up-to-date.”

Your supervisor grants the request, and you find yourself with your pick of a stack of resumes. You add three more bodies to the project, all of them young and brilliant.

One of them, Jim, is a little bit distracted, always trying to shoe-horn requirements into an infant open-source project he’s working on with a few friends. He listens to reason when you try to keep him on track, but not before mumbling about how his technology would alleviate all the problems you’re struggling with.

After two months of eighty-hour weeks, you finally hobble across the finish line. You congratulate the team. Your technology stack has proven itself.

You’re ready to deploy.

The initial release is a little rough around the edges due to necessary shortcuts, but in the end, users are now able to create custom slideshows.

Most of the time, anyway.

You take a couple weeks off for some well-deserved R&R. When you get back, your supervisor gives you some good news. You’ve been hand-selected for a new team.

“Listen, guys, this is a cutting-edge product.”

Jim smiles confidently at the front of the conference room, the overhead projector casting an eery, flickering glow over his face.

“We’re going to succeed where other projects have failed.”

#02

“I would watch his TV show.”

“Hey, about that wiretap on your suspect. We’ve got a lot of IRC traffic going on.”

“IRC! Internet Relay Chat. It’s how hackers talk when they don’t want to be overheard.”

“Well, not necessarily hackers. Lots of people use—”

“Think of it like shipping channels in the ocean. You can’t see them until a boat cuts through the water, leaving a wave. If two boats meet in the middle of the ocean to swap a load of illegal drugs, you have to catch them in realtime. Otherwise, there’s no evidence of the meeting left behind.”

“Right. I have the home addresses of all the people connected, but they’re encrypting everything so we can’t pull anything useful from the wiretap.”

“Luckily, I speak l33t.”

“Uhm, what?”

“I can decrypt the messages.”

“No, you can’t. That’s not even— They’re using SSL. Secure Sockets Layer. Picture the information they don’t want us to read. That information is in a box. The box is locked with the strongest padlock in the world.”

“What if we cut a hole in the box? We could circumvent the lock!”

“Imagine the box is also on the moon.”

“How do we get to the moon?”

“Look, I’m not allowed to leave the office, so could you please serve these warrants and get back to me with their machines?”

An hour passes.

“How much longer will the investigation of the computers take?”

“Here are the chat logs going back three years.”

“But you said there was no way to break the encryption!”

“The data gets decrypted on the client machine. This kid, p0wnm4st4h, never turned his computer off and logged everything that happened while he was connected to the server. He stored the logs in ~/logs.”

“That’s exactly what I suggested. I knew we could just circumvent the lock!”

“You’re right. I couldn’t have done it without your help.”

“How much evidence does this give us?”

“Forty pages of them openly discussing their master criminal plans, and twenty pages where they talk about how the server is ‘totally secure.’”

tl;dr I’m sorry, I’ll write a real essay next time.

#01

“When you get right down to it, most security is based on the honor system.”

Here’s a scene straight from television. Two characters are at a computer terminal when suddenly intrusion warnings flare up.

“No way—I’m getting hacked! They’ve already burned through the NCIS public firewall.”

“Well, isolate the node and dump ‘em on the public side of the router.”

“I’m trying, it’s moving too fast!”

Now both characters are typing on the same computer, trying to outpace the brilliant hacker on the other end.

They blabber on at each other in technobabble, the writers’ communication of the characters’ innate mastery of the entire system as they unleash a formidable arsenal of counter-measures.

The hacker outmatches them at every turn.

“It’s not possible, this is DoD level-nine encryption. It would take months to…”

“I can’t stop him, do something McGee.”

“I’ve never seen code like this!”

The screen goes black. The characters, despite their obvious talents, have been dwarfed by the formidable force on the other end of the connection.

It makes for exciting television, but the truth is even scarier.

In the real world, the majority of hackers don’t brilliantly blast through the defenses of slightly less brilliant computer whizzes.

They don’t win by being faster or smarter or more well-funded.

They win by waiting for smart people to do stupid things.

Modern systems — especially ones as complex as a computer network in a large organization — are not the work of a single brilliant designer. They’re collections of hundreds of smaller systems, each so complex that a person could fill eighty hours a week for the next fifty years maintaining any one of them.

A great system administrator might understand every single component of the system, but he’ll never be able to catch every security flaw. Even in an entirely open-source world, doing so would require the equivalent effort of perfectly proof-reading an entire library full of books for typos and factual inconsistencies.

This is where the hacker has the advantage. He has access to the same books, and all he has to do is identify one short-sighted paragraph before the system administrator. He doesn’t even have to do it himself.

Sure, sure, the system administrator has help. All the other system administrators are looking over the same books. Each one can easily proofread one chapter in a timely manner, and report their findings to everyone else. Hell, they can all double-check an extra chapter to make sure nobody misses anything.

Every time someone says, “Hm, this doesn’t look quite right,” a race starts. System administrators must patch their systems before someone takes advantage of the vulnerability.

If the person who recognizes the issue isn’t a good citizen and decides to keep the information to himself, it could be weeks before someone else finds it. It might only come to light by working backwards from an attack to determine the root cause. Then again, it might never come to light, depending on how busy the administrator is or how easy it is to pass off an alternate scapegoat.

No matter how much bang we can get from the off-the-shelf components of our system, we’re going to need people to cobble together the bits and pieces of those tools to make them handle the tasks specific to our business.

It all boils down to custom data at some point or another. Every organization of a considerable size needs custom applications to handle specific business tasks. This usually boils down to saving and spitting out data at the appropriate times. In the software world, these systems are called CRUD systems, since that’s what they do — Create, Read, Update and Delete.

Being such routine, you would think that every programmer would enter the field with the ability to create a stable, secure CRUD system off the top of their heads while drunk. You might assume that this is a core part of their training.

Not so, as the average programmer is trained not as an operator of simple input-output machines but as a Computer Scientist. And Computer Scientists are very clever. They’ve spent a lot of time and effort in figuring out how to successfully design complex applications.

They also have to justify the forty hours a week they sit at their desks. It simply wouldn’t be feasible for a team of four programmers to finish a six-month project in two weeks. The entire management schedule would be thrown off.

So, we have people specializing in complex systems with a vested interest in taking a large amount of time to create something. They’re faced with a simple problem. Clearly, the goal is to fit the problem into the system and time available, which necessitates taking the simple problem and making it more complex.

And now we have all sorts of nooks and crannies for oversights to hide, and we’re again stuck with the problem that even this small component of the system has become too complex for a single person to comprehend.

Add into the mix hundreds or thousands of employees of the organization. These employees don’t come into work each day with the goal of making the system more secure. They have their own work to get done.

Security is disregarded.

This is a segment of a realistic episode of a crime program. Investigators are working on a big case when they find out that a large portion of the evidence against the ring of criminals in question has mysteriously disappeared.

Our hero, the brilliant computer whizkid who knows everything about everything going on in the computers of the organization, finally cracks the case and tells his boss.

“I’ve been looking over these logs. I think something’s wrong.”

“What?”

“Someone’s been hijacking evidence shipments in order to keep them from being used against certain criminals.”

“How?”

“Well, I spent a few days looking into it, and it turns out that someone added a bit of malicious code into an exhibit description.”

“Wait, wait, XSS?”

“Yes.”

“Why are we letting people post arbitrary code to exhibit descriptions?”

“Well, the clerks writing the descriptions asked for it, so they could include tables of extra data and other images and things. It’s an internal application, so it wasn’t a huge security risk.”

“So it’s an inside job?!”

“No, the hacker got in by guessing one of the clerks’ passwords.”

“That’s not possible, we have a password security policy in place. Brute forcing that kind of thing would take hundreds of thousands of attempts.”

“Well, normally, yes, but the clerk was using the same password for her email, and that server got hacked, and a file with all the usernames and plaintext passwords got dumped.”

“But everyone knows user passwords need to be stored as one-way hashes so that getting the plaintext back out of them is impossible.”

“They were hashed, but only md5! The hackers just used a rainbow table to do the lookups.”

“How did the hacker even know to try the combination on our systems?”

“She used her work email.”

“Even if he knew the username and password, he couldn’t have accessed the system. You have to be on the local network to access that system.”

“Yes, well, I’m not positive on this, but one of the employees might have had too many devices and brought in a wireless hub from home, which wasn’t secured. The range of the hub reached across the street.”

“Why didn’t anyone remove that device?!”

“We tried to, but the department director didn’t see anything wrong with it and didn’t want to jeopardize productivity. After all, everything is secured by username and password. It was his call.”

“Ok, ok, so a hacker got into the system as a clerk and posted a fake evidence item. Big deal, clerks don’t have access to the shipment data.”

“Right, but service agents do.”

“So?”

“The hacker called up the main office pretending to be a lab tech and asked about the evidence item with the malicious code attached to it.”

“Ok, but those are low-level employees, they can only read shipment data, they can’t write to it.”

“Then he escalated the issue until supervisors were involved.”

“So?”

“Supervisors have full permissions in the system to arbitrarily create shipment orders. The supervisor looked up the item in the system, and the malicious code created a new shipment order in the background.”

“Wait, why do supervisors have the power to arbitrarily create shipment orders?”

“Well, because sometimes legitimate shipments to labs get totally fucked up and they need to cancel them and then reroute them by recreating the shipment.”

“So why didn’t the programmers just create some sort of edit mechanism to modify a shipment?”

“Because we contracted out this system and the maintenance request would have taken too much time. One of the interns took initiative and made something that worked, but he could only access permissions configurations, not the application code, since that’s proprietary.”

“Why didn’t anyone stop him?!”

“Why would they? Everyone was very happy with the results. We hired him over that. He’s a team lead now.”

“Isn’t there a paper trail on this? Didn’t someone have to sign to let this evidence leave the warehouse?”

“Sure, but on paper everything’s legit.”

“How do we stop him?”

“What?”

“How do we stop the hacker from destroying this evidence?”

“Well, this all happened weeks ago, so I’m pretty sure there’s nothing we can do. I only found out because some of the investigators were asking about missing items.”

“So what now?”

“I’m writing up a postmortem. Once management reads it, maybe they’ll implement new policies.”

“We already have policies on most of these things!”

“Maybe people will follow the policies.”

That’s it. No valiant showdown between a small number of larger-than-life geniuses. The battle was lost six months ago, against human fallibility.

tl;dr I’m not sure people would watch my TV show.