So You Want to Be a Security Expert(schneier.com)
schneier.com
So You Want to Be a Security Expert
http://www.schneier.com/blog/archives/2012/07/how_to_become_a_1.html
60 comments
Adding to your understand and ask questions point; make lots of mistakes on purpose (or not) and see if the results were what you expected. the why (or why not) might be the vulnerability.
Slightly off-topic, but could anyone give a good modern C reference-book or tutorial? I have read through K&R, but all the modern approaches are of course lacking.
I think this is a good list on how to get good at learning to jump between layers of abstraction with gusto, but I think ultimately this all needs to be motivated by a desire to actually exploit or reverse engineer something (as your latter bullets point out).
Learning C super well is important, so is assembly, so is other topics but I think fundamentally, step one needs to be: "I have product X. What is it trusting? What is it trying to protect? How do I get around it?" Then, find similar vulnerabilities and continue on stumbling to the ultimate goal.
Learning C super well is important, so is assembly, so is other topics but I think fundamentally, step one needs to be: "I have product X. What is it trusting? What is it trying to protect? How do I get around it?" Then, find similar vulnerabilities and continue on stumbling to the ultimate goal.
Being able to jump between layers of abstraction --- in both directions, so I'd add "learn the browser JS DOM model inside and out --- has to be in the top 5, probably top 3 all time most useful software security survival skills.
What is the standard reference for DOM mastery?
Another document worthy of some study is http://lcamtuf.coredump.cx/postxss/
Yes! This is a great paper which made surprisingly little noise given how important it is.
The idea is: stipulate that no attacker can ever inject Javascript into a browser. Assume we solve that problem completely. Now, how secure are DOM-based applications? Turns out: not that much more secure. Lots of very clever examples.
The idea is: stipulate that no attacker can ever inject Javascript into a browser. Assume we solve that problem completely. Now, how secure are DOM-based applications? Turns out: not that much more secure. Lots of very clever examples.
This is a very good starting document: http://code.google.com/p/browsersec/
(Also, anything icamtuf touches is probably going to be good.)
(Also, anything icamtuf touches is probably going to be good.)
I'd start with _The Tangled Web_ by Zalewski.
I agree with both daeken and yan. Moving off that, I think a key to "thinking security" is understanding the threat model of a given thing. I believe this is partially what yan was alluding to as well.
Understanding the function, and boundaries, and interactions of a system, application, protocol, device et al and being able to identify who are threat actors, what the assets to protect are, and what the real threats against the entity are will point you at the more valuable things to start. Far, far too many people gloss over threat modeling because they don't equate it with technical work.
Understanding the function, and boundaries, and interactions of a system, application, protocol, device et al and being able to identify who are threat actors, what the assets to protect are, and what the real threats against the entity are will point you at the more valuable things to start. Far, far too many people gloss over threat modeling because they don't equate it with technical work.
To me "Pick a game, write a server emulator for it" is an excellent example of "What is it trusting? What is it trying to protect? How do I get around it?".
But on top of being "a great way to use all your skills up to this point" I think it can also be a strong motivation for picking up new ones.
But on top of being "a great way to use all your skills up to this point" I think it can also be a strong motivation for picking up new ones.
[deleted]
I wonder if we should tighten that first recommendation up: learn C before you learn Ruby or Python.
I've had a lot of trouble bringing people into C that have a strong background in (say) Python, but I don't remember C being all that hard for me --- but that might be because I didn't have any other options, besides Borland Turbo C, when I was getting started.
Also: wow do I hate the OWASP Top 10. Can we just rattle off an HN Top 10 right here? It'll be better.
I've had a lot of trouble bringing people into C that have a strong background in (say) Python, but I don't remember C being all that hard for me --- but that might be because I didn't have any other options, besides Borland Turbo C, when I was getting started.
Also: wow do I hate the OWASP Top 10. Can we just rattle off an HN Top 10 right here? It'll be better.
Totally agreed on everything! Let's do the HN Top 10. my suggestions (in no particular order): SQL injection, XSS, CSRF, force browsing, improper authorization, command injection, arbitrary file reads/writes, remote file inclusion. What else?
My list:
1. DOM Corruption / Javascript Injection
2. CSRF / Clickjacking / Reframing
3. SQL / db-metacharacter Injection
4. Authorization/Forced-Browsing
5. Unauthenticated Encryption and Bad Block Cipher Mode Handling
6. Filesystem/Backend Storage Path Sanitization
7. Exposed Admin/Diagnostic Functionality
8. Memory Corruption Vulnerabilities in Native Code Extensions (cext gems, &c)
9. Shell-out Command Injection
10. Insecure Password Hashes
I feel like mass assignment, resource exhaustion, filter return code mistakes, and wildcard routes all belong somewhere, but they feel too Rails-y for a generic list.
1. DOM Corruption / Javascript Injection
2. CSRF / Clickjacking / Reframing
3. SQL / db-metacharacter Injection
4. Authorization/Forced-Browsing
5. Unauthenticated Encryption and Bad Block Cipher Mode Handling
6. Filesystem/Backend Storage Path Sanitization
7. Exposed Admin/Diagnostic Functionality
8. Memory Corruption Vulnerabilities in Native Code Extensions (cext gems, &c)
9. Shell-out Command Injection
10. Insecure Password Hashes
I feel like mass assignment, resource exhaustion, filter return code mistakes, and wildcard routes all belong somewhere, but they feel too Rails-y for a generic list.
I would love at some point to hear your thoughts on CSRF/clickjacking/etc. From a traditional security background, "validate all input" goes a long way towards making a program secure. But web apps have this little thing called the browser actively conspiring against you. All the inputs are valid in a traditional sense.
Imagine if someone said to write a secure program for some computer. But, btw, there's going to be an attacker logged in via VNC at all times you'll need to defend against. I'd just throw up my hands and walk away.
Imagine if someone said to write a secure program for some computer. But, btw, there's going to be an attacker logged in via VNC at all times you'll need to defend against. I'd just throw up my hands and walk away.
Obviously this is all appsec. It would be interesting to do a consolidated appsec/infrastructure list, with (obviously you need to do all of them, but there are some infrastructure items which cause security and availability issues, and are thus likely to be exposed even before you are attacked).
The problem with the term "security expert" is that it is stupidly vague. You describe a security expert as somebody who knows how to break software. I think Bruce would describe a security expert as somebody who knows what to do once the software is broken (or, perhaps, somebody who knows how to plan for the eventuality of broken software).
Regardless, I think Bruce is right about the mindset: if you want to be good at security (no matter where you want to live in the continuum), you have to think differently. That is why most software engineers are good at writing code that can be easily broken. We think in terms of building up, not tearing down.
I also think you are right: once you decide where you want to live on that continuum, you have to understand it inside and out.
Regardless, I think Bruce is right about the mindset: if you want to be good at security (no matter where you want to live in the continuum), you have to think differently. That is why most software engineers are good at writing code that can be easily broken. We think in terms of building up, not tearing down.
I also think you are right: once you decide where you want to live on that continuum, you have to understand it inside and out.
-Learn x86 assembly (to start).
Or better yet build a single bus architecture in something like Logisim[1]. It's much easier to learn a simple instruction set architecture down to the logic gates then it is to learn x86 assembly.
http://ozark.hendrix.edu/~burch/logisim/
Or better yet build a single bus architecture in something like Logisim[1]. It's much easier to learn a simple instruction set architecture down to the logic gates then it is to learn x86 assembly.
http://ozark.hendrix.edu/~burch/logisim/
Awesome list for self-study! If you work in a sufficiently large organization, or are well-connected enough to sit and chat with the breakers, get them into a room, and drill them about their processes, their information sources, and their mindset.
Beyond the deep, technical knowledge you'll gain following daeken's recipe, there's a whole set of security thought and security models you'll need to learn. It's hard to figure out and differentiate between threats unless you can think like an attacker, then work a system like an attacker does.
Beyond the deep, technical knowledge you'll gain following daeken's recipe, there's a whole set of security thought and security models you'll need to learn. It's hard to figure out and differentiate between threats unless you can think like an attacker, then work a system like an attacker does.
If you want to start doing security, I think it is more important to learn a fundamentally different perspective. It's sort of like learning magic, where the new perspective is 'What will my audience assume automatically? How can I get them to think that a given hat is empty?' (If it's a baseball cap and you drop it or invert it or so, for example.)
In security you're asking a similar question addressed instead at yourself. You're asking, "what am I assuming automatically?" Schneier for example has talked about why pilots don't get reduced screening at airports. The problem is that the pilots who cry out, "this is absurd, I could crash the plane I'm flying, how could I possibly be more of a risk to these people?" don't realize a certain automatic assumption: the assumption that the only people wearing the pilot's uniform are fellow pilots.
I tell this story occasionally, sorry if you've already heard me tell it. I once corrected a major security leak in an application I was paid to help develop -- the leak existed in the dev but not in production (thankfully!). The problem was that the team who had asked me to help out had made an assumption: "logs are good and are one of the only ways to create an audit/revert trail, we should log every request which comes our way just in case." This was built deep into the system. When I heard that, I was almost floored. As a proof of concept of the seriousness of what I'd realized, I looked through the audit logs for my boss's dev password and sent it to him.
It's a fundamental perspective shift: "if I wanted to break this, what assumptions could I use against it?" Whenever you see an implicit assumption you ask "how could that come back to bite us later?"
In security you're asking a similar question addressed instead at yourself. You're asking, "what am I assuming automatically?" Schneier for example has talked about why pilots don't get reduced screening at airports. The problem is that the pilots who cry out, "this is absurd, I could crash the plane I'm flying, how could I possibly be more of a risk to these people?" don't realize a certain automatic assumption: the assumption that the only people wearing the pilot's uniform are fellow pilots.
I tell this story occasionally, sorry if you've already heard me tell it. I once corrected a major security leak in an application I was paid to help develop -- the leak existed in the dev but not in production (thankfully!). The problem was that the team who had asked me to help out had made an assumption: "logs are good and are one of the only ways to create an audit/revert trail, we should log every request which comes our way just in case." This was built deep into the system. When I heard that, I was almost floored. As a proof of concept of the seriousness of what I'd realized, I looked through the audit logs for my boss's dev password and sent it to him.
It's a fundamental perspective shift: "if I wanted to break this, what assumptions could I use against it?" Whenever you see an implicit assumption you ask "how could that come back to bite us later?"
I'm glad he mentioned the importance of doing and showing rather than just studying the material. But be careful-- like many careers, computer security favors specialization, and its easy to get more or less pigeonholed into a few areas. This is further complicated by the rate at which technology changes.
I spent 6 years in computer security right out of college, and most of it was PKI and assessments. To stay on top of other areas of security required constantly learning and doing stuff on my own, outside of work.
Even if you make it a profession, you have to keep learning and doing if you want to be considered an expert or specialist.
I spent 6 years in computer security right out of college, and most of it was PKI and assessments. To stay on top of other areas of security required constantly learning and doing stuff on my own, outside of work.
Even if you make it a profession, you have to keep learning and doing if you want to be considered an expert or specialist.
> But be careful-- like many careers, computer security favors specialization
I agree that this is worthwhile to be careful of, but it very much depends on your employer as well. As with any career, find a good employer. So if you care about being a generalist, find an employer that needs you to be a generalist. I know for a fact that there's plenty of these in the security space.
I agree that this is worthwhile to be careful of, but it very much depends on your employer as well. As with any career, find a good employer. So if you care about being a generalist, find an employer that needs you to be a generalist. I know for a fact that there's plenty of these in the security space.
I would be interested to see what the HN crowd's opinion on certifications are. Mr. Schneier mentions them in his post but they seem to be a sticking point in the community as a whole. I have been on the hunt for ~2-3 months now without luck so far. I am currently working on my CISSP though I don't have the experience to qualify (CISSP requires 5+ I only have 2+) for it so even if I pass I can only qualify for the associate level.
I'm not sure if the CISSP is the way to go but I want to feel as if I am moving forward on a career search so I don't get stuck in a rut.
I'm not sure if the CISSP is the way to go but I want to feel as if I am moving forward on a career search so I don't get stuck in a rut.
IMO, he's seriously wrong about certifications. (and not really on the right track with this article in general; a good background in making stuff is key to knowing the tradeoffs in securing stuff...)
Maybe the perfect cert would be a useful tool for some purposes (corporate hiring, huge projects with consultants doing low-level IT, etc.), but those are crappy jobs (and not really "expert" in any way).
More importantly, the extant certifications are all crap. CISSP in particular. Get it if an employer requires it, but it's independent of your actual knowledge and learning process.
Maybe the perfect cert would be a useful tool for some purposes (corporate hiring, huge projects with consultants doing low-level IT, etc.), but those are crappy jobs (and not really "expert" in any way).
More importantly, the extant certifications are all crap. CISSP in particular. Get it if an employer requires it, but it's independent of your actual knowledge and learning process.
You will never, ever get the time you waste at a bad employer back. Employers that require CISSPs are far more likely to be wasting your time than not. The most important life lesson I've learned over the previous 10 years: be jealously protective of your time.
If you're in the military, you're basically required to get it, and it's not much more of a waste of your time than other things you could be doing there...
I personally got it just so that no one else in my company would ever need to do so; there are stupid companies which won't buy a product without integration, and where they have artificial requirements for integrators being certified. Given that it is only 1% of useless pain to enable 99% useful rewarding stuff, I found the sacrifice worthwhile.
I personally got it just so that no one else in my company would ever need to do so; there are stupid companies which won't buy a product without integration, and where they have artificial requirements for integrators being certified. Given that it is only 1% of useless pain to enable 99% useful rewarding stuff, I found the sacrifice worthwhile.
This comment is a great example of why I'm training myself to be less factional and defensive about people who hold the certificate. The military thing hadn't ever occurred to me.
But to be clear: I believe pretty firmly that for technical / software security, the CISSP is useless.
But to be clear: I believe pretty firmly that for technical / software security, the CISSP is useless.
CCIE Security is probably useful, although that's more CCIE + Security than some abstract security cert, too, and specifically for network security, and specifically the kind of network you get in a corporate environment, not a startup/saas.
I'm not sure how I feel about SANS/GIAC. Absurdly expensive IMO, but potentially actually has some value for sysadmins doing system security. I can't think of what CISSP is actually good for, except maybe trivial pursuit - crappy consultant edition.
I'm not sure how I feel about SANS/GIAC. Absurdly expensive IMO, but potentially actually has some value for sysadmins doing system security. I can't think of what CISSP is actually good for, except maybe trivial pursuit - crappy consultant edition.
Somewhat related - about 2 years ago, my employer had a bunch of us go through the SANS/GIAC GSSP training & certification. Some of the material was pretty boring and of questionable utility, but we had a good instructor and some of the hands-on parts where we were finding vulnerabilities was actually really fun.
I'm under no illusions about the certification's marketplace value and I doubt I would have ever paid for the course/cert on my own, but it felt like one of the better formal trainings I've been through in my professional career (which, granted, isn't saying a whole lot by itself).
Also, the certificate comes mounted on a comically oversized plaque, which provides some entertainment value.
I'm under no illusions about the certification's marketplace value and I doubt I would have ever paid for the course/cert on my own, but it felt like one of the better formal trainings I've been through in my professional career (which, granted, isn't saying a whole lot by itself).
Also, the certificate comes mounted on a comically oversized plaque, which provides some entertainment value.
Strong agree with 'rdl, I recommend avoiding the CISSP altogether. Having a CISSP isn't going to hurt you, except to the extent that it will enable you to get jobs at places you shouldn't be wasting your time with.
What about the CompTIA Security+?
Once upon a time I was a contractor at an insurance company, and I saw that most of the people in their IT department had various certifications hanging on their cubicle walls. I thought, "I want one of those."
So I selected the Security+ certificate, inhaled about two-thirds of a book covering the material, passed the test, framed the certificate and put it on my office wall.
That's about it. It was fun.
Once upon a time I was a contractor at an insurance company, and I saw that most of the people in their IT department had various certifications hanging on their cubicle walls. I thought, "I want one of those."
So I selected the Security+ certificate, inhaled about two-thirds of a book covering the material, passed the test, framed the certificate and put it on my office wall.
That's about it. It was fun.
Security+ is the "easiest" of the big certs (I did CISSP with about 10 hours of prep, and probably didn't even need that, but I had been working in the field for 15y, read the Rainbow Books when I was 11, and enjoy security trivia for its own sake rather than for application only; it normally takes about 5x more time to prep for than Security+ vs. CISSP).
Security+ seems a bit more focused, and obviously vastly less comprehensive (Part of CISSP is some fairly esoteric and never-used theoretical models). In practice I'd say it's on par with CISSP.
https://www.isc2.org/dodmandate/default.aspx DoD considers Security+ to be level I or level II, CISSP to be ok up to level III, although prefers CISM or CISA for certain roles over CISSP.
Security+ seems a bit more focused, and obviously vastly less comprehensive (Part of CISSP is some fairly esoteric and never-used theoretical models). In practice I'd say it's on par with CISSP.
https://www.isc2.org/dodmandate/default.aspx DoD considers Security+ to be level I or level II, CISSP to be ok up to level III, although prefers CISM or CISA for certain roles over CISSP.
Most certifications are pretty meaningless, except to suggest to managers that you probably at least know some basic information about the topic covered. If you're out of work, getting some certifications certainly wouldn't hurt, but if you're not worried about trying to find a job, you generally don't need to worry about certifications.
That said, there are a few certifications that are very hard to fake your way through. --I wouldn't put much stock in a CCNA or CCNP, for example, but someone who has CCIE most likely does know quite a bit about the area covered by the CCIE exam. Likewise, the Microsoft Certified Master program, which not only requires exams, but a certain number of years of experience (varies by product) in the product you want MCM status for, shows that you've been working with the product long enough that you probably actually know something about it (whether or not it really makes you an expert...) But these certifications don't really say much about your software development skills, which is what the Hacker News audience is probably more interested in.
That said, there are a few certifications that are very hard to fake your way through. --I wouldn't put much stock in a CCNA or CCNP, for example, but someone who has CCIE most likely does know quite a bit about the area covered by the CCIE exam. Likewise, the Microsoft Certified Master program, which not only requires exams, but a certain number of years of experience (varies by product) in the product you want MCM status for, shows that you've been working with the product long enough that you probably actually know something about it (whether or not it really makes you an expert...) But these certifications don't really say much about your software development skills, which is what the Hacker News audience is probably more interested in.
As someone who used to be CISSP certified (way back in 2003), here's my advice: don't bother. The only reason I got it in the first place was because, honestly, I had more free time than actual experience. Otherwise it's a great way to bullshit your way into a job you're unqualified for in a shitty company.
Focus your efforts on actual learning, instead of proving through a worthless piece of paper.
edit: Just to drive the point home: 9 years later I still don't know shit about security.
Focus your efforts on actual learning, instead of proving through a worthless piece of paper.
edit: Just to drive the point home: 9 years later I still don't know shit about security.
If you're going to waste your time on a stupid cert, waste it on a vendor cert around your main technology.
I'd trust a RHSE to know redhat security for redhat deployments more than I'd trust a CISSP, mainly because I put close to negative value on the CISSP, and a lot of infrastructure security is actually following best practices, not anything too specific to security.
For networking, Cisco (assuming a Cisco shop).
For virtualization, I've heard the VMware stuff is good if you're enterprise doing VMware. I wonder if there's value in the Amazon AWS courses for AWS deployments; I'd almost take one just to see what they're like.
I'd trust a RHSE to know redhat security for redhat deployments more than I'd trust a CISSP, mainly because I put close to negative value on the CISSP, and a lot of infrastructure security is actually following best practices, not anything too specific to security.
For networking, Cisco (assuming a Cisco shop).
For virtualization, I've heard the VMware stuff is good if you're enterprise doing VMware. I wonder if there's value in the Amazon AWS courses for AWS deployments; I'd almost take one just to see what they're like.
An important thing to note is that there are many different aspects of security, and therefore, there are many different types of security "experts."
Here at HN, many of us tend to view things in terms of how it relates to software development, but there is more to security than computer security, and the author mentions this in some of his other articles.
There are physical security experts, often having an extensive background in military or law enforcement operations. There are COMSEC custodians who are experts at implementing, operating and repairing a wide variety of cryptographic equipment, while also managing a program that generates, issues, maintains and disposes of an organization's crypto keying material. There are also security managers who at one time may have been experts in a specific domain, but are now called upon to maintain a bird's eye view of an organization's entire security strategy in order to develop a cohesive plan for minimizing the treats presented to their employer. There are intelligence analysts who make an organization more secure by using their expertise of social engineering to actively track down those who would wish them harm. Each of these types of employees is a security expert in their own right, yet none of these examples really need any knowledge of programming.
When you look at the content from the Security+, CISSP, and CISM, the classes lean heavily towards information security, but they address the other areas briefly. More specifically, they focus on information security from the perspective of a security manager. In other words, you don't take these certifications to gain technical expertise.
Unfortunately, many businesses fail to understand this, and so they end up making CISSP a requirement for their technical recruits out of ignorance. Does this make the CISSP a worthless piece of paper? Not really. It's just misunderstood by those whom are doing the hiring.
Here at HN, many of us tend to view things in terms of how it relates to software development, but there is more to security than computer security, and the author mentions this in some of his other articles.
There are physical security experts, often having an extensive background in military or law enforcement operations. There are COMSEC custodians who are experts at implementing, operating and repairing a wide variety of cryptographic equipment, while also managing a program that generates, issues, maintains and disposes of an organization's crypto keying material. There are also security managers who at one time may have been experts in a specific domain, but are now called upon to maintain a bird's eye view of an organization's entire security strategy in order to develop a cohesive plan for minimizing the treats presented to their employer. There are intelligence analysts who make an organization more secure by using their expertise of social engineering to actively track down those who would wish them harm. Each of these types of employees is a security expert in their own right, yet none of these examples really need any knowledge of programming.
When you look at the content from the Security+, CISSP, and CISM, the classes lean heavily towards information security, but they address the other areas briefly. More specifically, they focus on information security from the perspective of a security manager. In other words, you don't take these certifications to gain technical expertise.
Unfortunately, many businesses fail to understand this, and so they end up making CISSP a requirement for their technical recruits out of ignorance. Does this make the CISSP a worthless piece of paper? Not really. It's just misunderstood by those whom are doing the hiring.
There are lots of subfields of security. (for instance I really wish I knew more about appsec; by far my weakest area, working on it.)
However, CISSP is a worthless piece of paper for IT security managers, crypto custodians, developers, pentesters, and auditors.
However, CISSP is a worthless piece of paper for IT security managers, crypto custodians, developers, pentesters, and auditors.
This is a good list for getting a job in information security. Becoming an expert? Not so much.
To be fair, though, he is writing it for people who want to get into the field, and you can't become an expert without getting into the field first.
(Well, you can, but it requires dedicating a lot of time and energy to it, more than most people are willing to give up after the normal day job.)
(Well, you can, but it requires dedicating a lot of time and energy to it, more than most people are willing to give up after the normal day job.)
Strong agree.
I have a better idea: Forget becoming a "security expert" and become a security-conscious developer instead. The world needs a lot more of the later.
Disagree. With possibly a few exceptions, secure software development is led by the breakers, not the builders. Some of the best of the breakers start out as competent builders, but either way: you can't defend something if you don't understand how it's going to be attacked, and the history of software security over the last 20 years suggests that we suck at predicting what attackers will come up with. Great example: "buffer overflows are easy to fix; just make the stack non-executable".
One of the best secure developers in the world is Daniel J. Bernstein, and, two things you'd want to know about DJB: (i) he missed LP64 integer overflows, which got flagged by (pure breaker) Georgey Guninski, and (ii) he's a world-class cryptanalyst and breaker in his own right.
There's a reasonable "builders vs. breakers" argument to be had, I'm sure, but my experience suggests that overwhelmingly the people making this "world needs more builders and less breakers" point are people who are annoyed at the prospect of sinking the time into becoming a competitive breaker.
One of the best secure developers in the world is Daniel J. Bernstein, and, two things you'd want to know about DJB: (i) he missed LP64 integer overflows, which got flagged by (pure breaker) Georgey Guninski, and (ii) he's a world-class cryptanalyst and breaker in his own right.
There's a reasonable "builders vs. breakers" argument to be had, I'm sure, but my experience suggests that overwhelmingly the people making this "world needs more builders and less breakers" point are people who are annoyed at the prospect of sinking the time into becoming a competitive breaker.
Disagree. You don't need to be a breaker to learn how things get attacked; being a fixer also works. I've broken a few things over the years, but I've learned far more by fixing things in FreeBSD which everybody else has broken.
(Maybe you don't think I'm a good secure developer, though.)
(Maybe you don't think I'm a good secure developer, though.)
Disagree with your disagree.
As an example I deal with the registries (the people that deal with the registrars such as Verisign, PIR etc.) and I know what security they have in place to prevent a person from imitating a registrar and gaining access. I also know exactly how to circumvent that security (which you don't) and obviously the registries don't (because if they did they would have steps to prevent what I know could do to circumvent their security).
While this only illustrates one example, the mindset of someone whose thought process is excited by how to break into something is not necessarily the same as someone who designs a system (although that could be the same person).
Here's another example that is maybe a little closer to the parent's point. I once got into a medical conference by setting up a website about the medical specialty that the conference was about. They requested I fax them a request on a letterhead (easy to whip up in a graphics program) and was quickly issued press credentials. A domain was also registered called "(Speciality) Treatment News" with a simple banner. Doing that revealed flaws in their system for vetting who should be issued press credentials because the person setting up the system a) didn't think like a breaker does and b) didn't realize the simple skills that are necessary to fake a letterhead that looks legitimate.
The idea is you're not going to be able to think of as many attack vectors unless you also spend time breaking things.
As an example I deal with the registries (the people that deal with the registrars such as Verisign, PIR etc.) and I know what security they have in place to prevent a person from imitating a registrar and gaining access. I also know exactly how to circumvent that security (which you don't) and obviously the registries don't (because if they did they would have steps to prevent what I know could do to circumvent their security).
While this only illustrates one example, the mindset of someone whose thought process is excited by how to break into something is not necessarily the same as someone who designs a system (although that could be the same person).
Here's another example that is maybe a little closer to the parent's point. I once got into a medical conference by setting up a website about the medical specialty that the conference was about. They requested I fax them a request on a letterhead (easy to whip up in a graphics program) and was quickly issued press credentials. A domain was also registered called "(Speciality) Treatment News" with a simple banner. Doing that revealed flaws in their system for vetting who should be issued press credentials because the person setting up the system a) didn't think like a breaker does and b) didn't realize the simple skills that are necessary to fake a letterhead that looks legitimate.
The idea is you're not going to be able to think of as many attack vectors unless you also spend time breaking things.
By definition, fixers aren't leading; they're reacting to what the breakers do. Also: you're a breaker. Face it.
Fixers are reacting, sure, but they're probably reacting to far more vulnerabilities than any one breaker could find. And reacting doesn't mean that you can't be leading -- it's entirely possible for someone to say "gee, OpenSSL seems to have lots of security vulnerabilities, maybe we should avoid using OpenSSL" and thereby pre-emptively immunize themselves against a wide range of yet-to-be-discovered breaks.
As for me being a breaker... I'd say that my security-related time is split roughly 90% building, 9% fixing, and 1% breaking.
As for me being a breaker... I'd say that my security-related time is split roughly 90% building, 9% fixing, and 1% breaking.
A good practice is to have your applications run past an application security specialist. Before it goes into production, the appsec person can break it every way they know how, and the developer can then fix those issues. In this method, the developer is learning with every bit of code they submit, and hopefully will not make the same mistakes again. That's where the role of "security expert" comes in as it relates to the community at HN. HN is developer-oriented, and having a dedicated appsec person fulfills that role that is so often forgotten.
In my role as security engineer for my company (as opposed to being a developer), it's nice finding possible exploits and passing them to our appsec guy for review. Being the guy who both finds (or develops) and also exploits/documents/patches the security flaws leads to a feedback loop far too often. Being a security conscious developer doesn't preclude the need for an application security engineer.
In my role as security engineer for my company (as opposed to being a developer), it's nice finding possible exploits and passing them to our appsec guy for review. Being the guy who both finds (or develops) and also exploits/documents/patches the security flaws leads to a feedback loop far too often. Being a security conscious developer doesn't preclude the need for an application security engineer.
This is a good article, with links to good resources for those interested in security. One good place to learn is IRC. I must say though that a better title would have been, "So, you want to get into Computer Security..."
On a related issue, I'd like to know if there's market for security (mostly appsec I guess) freelancers working remotely? The area interests me, but I have limited time I could contribute to it if it were only a hobby; OTOH, if it could one day transform from a mere hobby into a marketable skill, I'd be much more inclined to make time for it (The "remote" part of my questions comes from the fact that I don't think many interesting jobs will be available in my area, so remote's the pretty much the only option).
i wanna be
- Learn C. Learn it well. That will give you the level of understanding you need of the way the computer works.
- Learn Python or Ruby. If you can automate something, do it. Computers are better than you at repeatable tasks.
- Learn x86 assembly (to start). Write some C code, compile it down to assembly, and read it; understand how the two map to each other. Get your friends to write stuff for you and decompile it back to C, and have them check your work.
- Learn the basics (at least) of web development. Understand how web applications work, understand the constraints it puts in place, understand the interactions between the client and server.
- Internalize the OWASP Top 10. Understand and be able to recognize and mitigate XSS, SQL injection, command injection, arbitrary file reads/writes, etc.
- Grab old versions of open source software and rediscover known vulnerabilities. Grab the latest versions of open source software and discover new ones. Start off looking for simple things, and know it well.
- Reverse-engineer network protocols. Pick a game, write a server emulator for it. This is a great way to use all your skills up to this point. It's also a lot of fun (it's how I cut my teeth).
- Write a debugger. Understand the interaction between hardware, the kernel, and userland.
- Understand, understand, understand. Ask questions. Ask a lot of questions. In my opinion, the key to security is always asking "Why?"
These are in no particular order, and none of these is more important than the other. It also jumps all over the place, perhaps because that's what I do myself; I may be breaking a web app one day and reversing some hardware the next. But these are things I feel are important, and will give you some direction.
If anyone has any questions, wants direction, or anything else, my contact info is in my profile. The world needs more breakers.