You're in the Top 25
You're in the Top 25
Nobody wants to write insecure code. Read on to find out an easy way to dodge that bullet.
Join the DZone community and get the full member experience.Join For Free
xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.
You know, over the past few months, I keep running into people talking about checklists. Doctors using them have drastically decreased surgical fatalities. CEOs use them to organize the things they need to do, but may not want to do, to make sure they get done. They make people more effective, faster, and just better. Clearly, I need to get myself some checklist action, and you do too.
So, what would this look like? From a cyber security perspective, what kind of checklist should I have, where would I get it, and what would I use it for?
Well, developers, I have a great checklist for you. Take a look at this. This is the kind of checklist you can use. And it will make you a more secure developer.
Using the Top 25. So, personally, I develop software and I try to break into other people's code. I'm a somewhat anti-social person that way. I use this list in two different ways, depending on what I'm up to.
When I'm developing code, I always go back twice to review the code. I look at the code for two different things—first, for security, and second, for performance (I kind of cheat, because I consider availability to be a performance attribute, when it's arguably a security attribute). I always use the top 25 in the security review.
First, I narrow down the list. No SQL in the code? Great, mark SQL injection checks off the list. Not downloading code? Nice, no worries about downloaded code verification. Am I executing sensitive operations? Yes? Well, then I need to isolate them and make sure they're authenticated and authorized.
This initial homework's important. The same step can be implemented differently depending on the environment. For example, use of a broken encryption algorithm—what does that mean? Is the algorithm broken everywhere? If not, does the library I'm using have a robust implementation? These questions have answers that depend on your production environment.
Once I've finished the initial review of the principles, I then review my code with those principles in hand to try to make sure I didn't screw anything up. And I almost always find something that I did wrong.
...for penetration testing
This list is the best for application analysis. Really. The best. When I use this for code analysis and auditing, I follow the same initial process I do when developing. I look at the context and think about what the top 25 means in the environment I'm working in. Then, I look at the code. Then, after I find flaws (and there are always flaws), I start looking at which ones are exploitable (I wish they were always exploitable).
Still, similar process, different result. In both cases, having a checklist of common software flaws is really helpful, and makes my job much easier. It'll do the same for you.
Opinions expressed by DZone contributors are their own.