What is it and why should I care?
I spend a good bit of time talking about both development and security. I spend a lot of time working with other developers and other security people. There are a precious few that I know of that excel at both development and security. This is a sentiment echoed by many, so I won’t spend time belaboring the point. If you can’t have everyone be an expert in both, how should you structure your team so you have the optimal blend of both? There is some usefulness in discussing the make-up of teams with regards to development and security, as it can heavily affect your security posture long-term.
What should I do about it?
Let’s consider a few different options when it comes to team make-up:
No security people
I thought about leaving this group out, but it’s so prevalent that I just couldn’t. Many small and medium sized organizations haven’t yet added security to their SDLC (another post in the coming weeks on this topic). This is tough. This will take a long time to resolve, and will require changes to developer education and training programs as well as general industry awareness. There’s a lot of work being done to get the information out there, but this will just take time.
Developers with some security training
This is a popular option. Ok, we need to do better on security – send one of the team members to a week’s training! This is better than nothing, but a pretty weak option. Unless the person is passionate about security and spends time coming up to speed on his/her own, you’re going to get little benefit. You may pick up a few of the obvious things, which is certainly helpful, but it does not usually improve your overall security stance. Additionally, this person is not going to have a mentor of any type for the security work they are doing, which can be important in the security field particularly.
Security people at the enterprise level
I think this is a great option for a lot of things, and should certainly be considered depending on the size of the enterprise. Security people at the enterprise level can do things that security people embedded in development organizations just can’t do. They can set high-level standards and policy. They can also build security strategies and architectures for development.
As an organization grows, it becomes more and more important to have consistency (assuming the standard is good) across the enterprise. There’s a lot of time and money being spent in just trying to figure out what organizations have deployed. It quickly becomes a nightmarish problem, particularly for organizations that have lots of legacy software.
Security people on the development team
Having security embedded in the development organization is also a great option for making impactful changes on application architecture, design and implementation. Producing standards at the enterprise is great, but useless if no one follows them. Also, having security folks deployed in the team helps tremendously with training as your “non-security-trained” developers get direct on the job training tailored to your organization. In addition, you have a built-in mentor to ask questions of if something comes up that’s security related. You can also catch issues earlier in the development cycle, since the security person can help do things like code review or design review with an eye for security.
There are a couple of models for this. One options is to have a security minded person doing actual development, but also security stuff, essentially splitting time and focus. Alternatively, you have a security person that round-robins for a few dev teams and functions as a kind of internal consultant. I’ve seen both of these models work, and it often comes down to organizational culture as to which one is a better fit.
A good article related to this (and with REAL data!) is from David Rook (@securityninja) and is found here. In it, David says that their company embeds security people in with the development team. They do code reviews as well as other security related activities. He has tracked their data over time, and has found that 1 security person to 10 developers is a ratio that works well in their organization. Compared to current standards, that’s a LOT. According to BSIMM, there’s a ration of 1.95%. That means on average (for the companies that participated in BSIMM), there are 2 security folks for every 100 developers. That includes people who sit at the enterprise level as well as those are directly related to security in development and architecture teams.
Security people outside the organization
A final option for consideration is the “security consultant”. This can come in lots of forms. It could be paying people to come in and build your code for you in a secure way. It could be someone coming in and reviewing/testing the code you wrote for security. It could be purchasing or using tools/services.
Using outside consultants is often a business decision in many fields. Is it cheaper for us to develop this talent internally or outsource it? However, that’s often not an option in security, though it’s getting closer. At the current moment, a lot of the “security” people are at outside consultancies. There are clearly domains (financials, government, etc.) where there is a lot of security knowledge, but many verticals just don’t have the internal knowledge.
Using and consuming external security knowledge can be a great idea, but IMHO, shouldn’t come at the cost of building at least some of that talent internally. By creating that skill-set internal to your organization, you can tailor your strategy to your organization, a powerful concept.
In conclusion, if you’re developing or deploying software, you should be building security into your process, and that means getting good security people on board. Security talent can come from internal and/or external resources. Considering your organizational model and embedding security in the appropriate places can greatly improve your overall security posture.