Problem solving is needed for any branch of software development. Looking at a problem and being able to find a fast, efficient way to solve it is what software development is ultimately about. It takes a whole new level of problem solving skills to design secure systems. Systems that can keep out the most dedicated of intruders and yet be a hassle-free experience for those who truly belong there. Computer Security is a fascinating field with unique challenges but for those of you interested in entering the field, you'll probably need a change in mindset.
First, some terminology. It's not unusual for developers to take on several different positions in a project, such as database admin and programmer for a website or some other project. This means that the developer wears several "hats." As hacking eased itself into existence, "hackers" unknowingly formed two different groups: white-hatters and black-hatters. A black-hatter is what most people erroneously think of when they hear the term "hacker." Black-hatters infiltrate, penetrate and generally abuse a system for their own personal gain, for another person's lose, or sometimes simply because they can. A white-hatter uses all the same tricks and exploits that a black-hatter does except that they do no damage. Sometimes a white-hatter is hired to evaluate the security of a system by attempting to break it and reporting their findings back to whoever hired them. Not all white-hatters make a career out of it though. To some, its about the expansion of knowledge and facing the challenges that hacking presents.
It's very easy to look at a service or system and think about what it explicitly does for you, i.e. it's intended use. Such as an automotive repair company. The general system is that you bring in your car, they work on it, you pay and leave with your repaired car. In a very simplistic view, that's it. In computer security you need to look for ways to abuse the system, once you know it's weaknesses, you can begin repairing them. You'll be looking for unintended happenings that may introduce instability or invalid results. Some repair shops have insecurities though. If a car is to be worked on for an extended period of time, often times the owner can leave and come back and claim the car by using a last name. When the owner comes back, they could be confronted by somebody who won't recognize them, somebody who wasn't working when the car was dropped off and the owner of the car left. In such situations, it's possible for a 3rd party to arrive, claim to be somebody using just a last name, pay the bill and leave. Yes the 3rd party has a cost they have to pay that they normally wouldn't have to pay if they weren't trying to swindle the shop, but it's a small price considering they came with nothing and left with a car. This is an authentication insecurity, where a user of the system is not properly validated and is taken by their word. Small honor system insecurities like these can be found in almost every line of service. Imagine if this same sort of social engineering took place with a child at a nursery and a black-hatter claims to be a parent. This would especially be easy if the child is new to the daycare and dropped off by one parent and expected to be picked up by the other parent. It takes minimal information about the system and the targets to be able to upset the intended use of the system.
A more real example, one that I discovered myself at my own school, would be the website my school makes available to all students and faculty. It keeps track of things like their financial information (like how much they owe the school), signing up for and dropping classes, the school directory and many other services tailored to each student. As with most colleges, students are given an ID number, in our case a 7 digit number. The site starts by making a user sign in using their active directory account name and password. None of the pages were HTTPS and (for whatever reason) they put a lot of information in the query string of each webpage. While browsing around one day doing normal student related activities on the site, I noticed the query string contained the key of xyz and the value of *gasp* my student ID number. I began hunting around and found it was in the query string of almost every page of the site. My science teacher would post grades where everybody in the class could see them, but to prevent associating a name with a grade, he'd put up the student ID along with the score so you'd only be able to determine you're own score and a general understanding of how everybody else did. So I popped in a few of those student IDs into the query string. At first the page came back reporting something went wrong, so I figured that some of the other query string values carried other user information, so I systematically removed name/value pairs out of the query string until it finally worked. I came up with a template where I could insert somebody else's ID and I could see almost any information I wanted on the school's site, including personal financial information. I didn't like the idea of any other student being able to see my information, so I saved a few notes in notepad, including the template URL, and went to my school's IT department.
My school fixed the problem in about a week. Security has since been their top priority. The lesson to be learned here is that authentication information should not be stored client side in query strings or cookies. It's an ASP.Net website; they could easily store authentication information in Session["StudentID"] or some other server side, session based variables. That would move the security hole to the ASP.Net Session ID which is time sensitive and harder to obtain.
Computer Security requires a whole new paradigm of thought. When developing a system, you have to think of how somebody will purposefully misuse your system, along with what they can obtain or do. Security is not something that exists strictly in your own code, either. In my school's example, even simple things like query strings and cookies can render your system insecure. Some simple exercises you can do are design your own system, then try and break it. If you break it, patch the error and try to break it again. After all, the worst case scenario is somebody who knows the system inside and out. There are also many sites out there to help you practice your system penetration skills. The better you are at gaining entry, the better you can become at protecting your own systems.
Computer Security, Misc
security, white hat, black hat