Software security at the organizational level
By: Nyilasy Péter
Tags: Software Engineering, Organizational Culture, Software Development, Software Security, Coding

Security awareness, and knowledge increased a lot recently. More and more developers know what is XSS and they have already heard at least about CSRF, organizations have security departments, and most project leaders understand that security auditors and ethical hackers are their friends not their enemies.

And still, everyone who is involved in the application security business has a typical, recurring experience: that old vulnerabilities, well-known security problems come back again and again, and many applications are still ridiculously easy to hack.

Why is that so?

One obvious answer is that security is a matter of focus.

Photo by Paul Skorupskas on Unsplash

Even if you are a developer who knows about a given vulnerability, you might still introduce it to your code, simply because you focus so much on functionality that you forget to realize the security aspect. When you are running deeply within one track, it is hard to stop, climb out of your pit and look around from a higher perspective. It even happens to security experts, who turn to development, sometimes they introduce vulnerabilities without realizing it, or (more often) realize it only after they look through their code with their “security glass” on.

Another important reason is that at the organizational level security is a typical weakest link problem.

Photo by Shaojie on Unsplash

If there is just one Junior developer in the team, who does not understand SQLi, he can easily introduce several SQLi vulnerabilities before anyone realizes it, and teaches him how to do it better.

Actually there is more about it than just the typical weakest link problem. There is something that we can call the accumulation of knowledge. Some types of knowledge accumulate very well, while others accumulate hardly, or not at all.

If there is one developer who understands graph-algorithms well, she can do all the graph-related tasks, and the quality of those solutions will not depend on the graph-knowledge of other developers. It is enough if others know that she is the right person to find, when there is a graph related problem. If one developer creates a great UI component others can use it even without fully understanding how it works. In many aspects, IT knowledge accumulates extremely well (that’s why we have such a rapid improvement in the software industry).

But alas, security knowledge cumulates hardly. The fact that one developer knows an immense lot about security does not really help other developers who are less knowledgeable. The problem is that those other developers won’t know when to ask a question. After all, if you never heard about XXE, and you use an XML parser, you won’t go and ask your colleague: ‘Hey, is there any possible security issue with using an xml parser with DTD enabled?’. In order to ask such questions you already have to know at least something about XXE.

So to sum it up, there are three problems which help hackers and hinder devs: focusing solely on functionality, the weakest link problem, and that security knowledge does not accumulate well.

How can we address these problems?

I believe (with many other security experts), that a true solution can only be found at the organizational level. You have to create the right processes, roles, practices at organizational level.

Create a code-review system to guarantee that no code of junior developers (or optimally, no code of anyone) can get it’s way into the repo without someone reviewing it first.

to guarantee that no code of junior developers (or optimally, no code of anyone) can get it’s way into the repo without someone reviewing it first. Make it a norm that security questions pop up during the design phase as well as during testing.

as well as during testing. Allocate time for your devs to look at their own code from different angles, checking the code’s overall quality, including security quality . (And you have to make sure that they don’t use that time for something else, even when a deadline is approaching, and the client is eager to see all the new functionalities!)

. (And you have to make sure that they don’t use that time for something else, even when a deadline is approaching, and the client is eager to see all the new functionalities!) Ensure that everyone gets basic education about security as early as possible. Monitor how the onboarding process effectively involves learning your security standards.

about security as early as possible. Monitor how the onboarding process effectively involves learning your security standards. Make security related knowledge and skills refreshment programs a regular part of annual professional improvement.

a regular part of annual professional improvement. Facilitate security knowledge transfer within the organization.

within the organization. Identify the security stuff that everyone has to know within a project, and separate it from the knowledge that only security-experts have to care for.

within a project, and separate it from the knowledge that only security-experts have to care for. Do have security experts with well defined roles and meaningful responsibilities.

These are short bullet points only. I will publish a longer article on the matter with more details soon in the defdeveu journal.

Stay tuned for the next post here introducing how to implement and maintain in a longer term the above in the framework of an advanced security champions program.