Making secure code a focus for your development team

Question

How do you go about promoting secure coding practice in a development team?

Answer 1

Education of programmers and peer reviews!

Answer 2

I would recommend code reviews. Security is a tricky thing. The more people you have reviewing code, the more devious minds you have analyzing security problems.

Answer 3

Whatever you do, do NOT punish your programmers for having bugs in their code. Punishing them (even just calling them out derisively in meetings) will only cause them to hide/ignore bugs, and keep their peers from reporting them & harming their friends.

Answer 4

Have a QA department that actually tries to break the code, and make sure the original developer has to fix anything that breaks if possible. Breaking includes compromising security and malicious testing.

Answer 5

If you are looking for books, I recommend Exploiting Software, Software Security, and Building Secure Software. You can also get a boxed set containing all three books. I'm still reading Exploiting Software, but I thumbed through all of them and they seem good.

I personally thinking that good processes would help. A security problem can be introduced at any level, from requirements through maintenance. And once a problem propogates, it becomes that much harder (and more costly) to fix.

Answer 6

always good to have a team member who responsible for advanced penetration testing, while the others considering the general security issues together

Answer 7

Security is a frame-of-mind. You have to get them there. Try "Security Awareness Day" once a month, well just for a few hours and not the entire day. They really have to develop this consciousness in today's world.

Answer 8

This has to be done both from the top-down and bottom-up or nothing will get done; if management doesn't care and reacts to security concerns cavalierly, then it doesn't matter if the developers notice problems, time will never be allocated to deal with them. On the other hand, if the developers don't care, they won't report their concerns to the managers.

In our company, we use peer code reviews and a "rule of three" design process to ensure that we have the greatest possible chance of having eyeballs on potential problems. This additionally offers us the opportunity to show off our skills to our peers, which is powerful motivation to do well.

Answer 9

Code reviews
All code should be reviewed, even if very informally. It helps if the reviewer has some familiarity with vulnerabilities (maybe having just read a decent book on the subject)

Static analysis
There are a number of free tools, a decent book, and if you have the cash on hand you can pay someone to do a very thorough job of it.

Extensive testing
Must include edge conditions.
Automated testing using Fuzzing (book) or Scripted GUI testing (book) can be very helpful

Treating Security Flaws as High Priority Bugs
Security cannot be "stapled on" to a product. It must be considered a core part of the functionality. Thus, vulnerabilities must be considered serious bugs throughout the product life cycle.

Answer 10

From a managers perspective, I think at least one member on the team has to become the champion for this. Telling the team to write secure code might not go very far. I would probably pick someone that has the most excitement on the subject. Give this developer the instruction to evangelize this practice. Have them review the code, make recommendations, point out problems during normal pair programming, code review, etc. Don't make it a big deal requirement. Developers will feel better writing secure code and if they know management is behind it (the champion can point that out too) they might spend the extra time necessary to onboard the discipline.

Answer 11

I think the advice here is good but I am trying to figure out how to apply it in a way that is effective.

I have been toying around with the idea of trying to setup a security team, much the same way Microsoft does it. The purpose of the team would be to enact many of the things mentioned here. But I doubt we are going to be able to have dedicated full time resources to a security team.

What I was thinking was purposing we build a security team from the existing development team. Some subset of the team, I was thinking five or so, would serve on the security team for a period of time. They would only be On duty for one week periods. During that On time they perform code reviews, peform and mitigate security tests, and work with M's, SA's to determine security concerns before a drop of code is written. Then after they have served on the team for a period of time, someone else rotates in.

The advantages I can see is everyone has the potential to get involved in the security process. They learn by doing instead of studying. The others who are not involved are working with their peers instead of some security expert.

Since it is my idea...all I can see currently is the advantages, but I am sure that it has plenty of disadvantages. What do you think?

Answer 12

First stop: Executive buy-in.
If you don't have executive level backing, you wont be able to invest the necessary resources, or make the hard calls when scheduling pressure is building and the systems security looks like swiss cheese.

Next, you have to get the developers interested, but before that - the question should be, WHO is doing all this? It doesnt happen by itself. If you cant have a full blown security team, consider having a single security guru, who should motivate the entire dev team to be his "security team" (more on that in a moment).
If you can't even have a single fulltime security person (either cost or size not relevant), this can be an additional "hat" for one of the senior programmers, as long as he has the drive for it.

If you're in a large or bueracratic org, consider having a "security council", made up of the security lead, senior pms, dev manager, and the executive sponsor. This council provides the final word on disagreements, scheduling issues, and in the (hopefully) rare situation when you knowingly accept the risk of faulty security.

Education.
Programmers usually like doing the right thing, IF they know how. Have a series of educational lectures/workshops for ALL disciplines, each covering the relevant topics, even very technical ones for programmers, and high-level non-technical ones for managers.
Should be intense the first series, maybe half a day for a week, just to kickstart the process, then have periodic refresher courses, or maybe on new subjects or technologies as they come up, at least once or twice a year.
This shouldnt be mandatory (nobody likes to be forced), but it should be made clear that everyone is expected to appear, since otherwise they wont be doing their job right.

Tools. If programmers are given good tools which are easy to use, they will use them. Thats why MS is bundlign a lot of these tools into Visual Studio, such as CodeAnalysis (though not the top of the line, its a decent static analysis tool - most importantly, the programmer can see the results immediately).

Management must provide enough time and resources to include security from the beginning of the dev process, starting even before design, thru threat modeling, guidelines, testing, etc. This entails a great deal of planning, and willingness to take the hit both on resources and on schedule. That executive buyin from step one should help here.

Code reviews. Should be performed constantly, but not negatively - these should be treated more as learning experiences. They should at first be done by the security lead, or someone trained to do security code reviews specifically.

Periodic (weekly?) staff meetings should discuss some of the more interesting or prevailing issues which are found in the CRs.

Security testing - including penetration testing, fuzz testing, etc. Planning should have ensured that this does NOT occur two days before release, when its too late to care...

In general, having a clear, well defined process - whether formal or not - will help the programmers, because it provides structure, and gives guidance as to what to do when. Moreover, its because that says that management cares about security more than rushing the product out the door. That will help their own buyin, especially when they have the capabilities to do something about it.

---

It occurred to me that I did not emphasize that THIS IS NOT SOMETHING YOU SHOULD DO ON YOUR OWN. Having an experienced security professional on your side, one that's already been through this - preferably numerous times, preferably from different angles in different situations - is indispensable.

Answer 13

Another, separate comment regarding books, the best - and first - book ALL your devs should read is Writing Secure Code, 2nd Edition, By Michael Howard, MSPress.
The definitive volume for secure coding.

Answer 14

The best way to educate developers is to encourage them to participate in local user groups such as OWASP. On my side of town, there are multiple ways for developers in different companies to learn and interact with each other that is 100% free of cost.