How to code secure-by-default software


IT Security Thing has been talking to Lorenzo Grespan, a developer with Pentest Limited about secure software development.

Established in 2001, Pentest describes itself as a leading provider of IT security with one of the largest penetration testing teams in Europe. What interested us, though, was that it also runs secure coding workshops for developers.

These are described as being hands-on courses aimed at those developers who wish to gain a greater understanding of common security vulnerabilities and the knowledge to ensure their applications are as safe as possible by developing and testing robust, secure code.

Which sounds good to us, especially in the light of recent research by Risk Based Security suggesting there have been more than 370 vulnerabilities reported in security solutions during 2015. Look at the last six years, and that number rises to more than 1,700 in total.

The latest security vendor to fall victim, at least to a vulnerability being discovered if not a compromise thank goodness, being Trend Micro.

As I said when writing the story about the Trend Micro Password Manager vulnerability for SC Magazine, this isn’t perhaps all that surprising: “By their very nature, antivirus and security solutions have a large attack surface; it goes without saying that there is a lot of code, often running with high privilege, that has the potential to be flawed.”

Why aren’t vendors leveraging existing tools such as sandboxes to enforce the principle of least privilege more often?

Obviously, all sectors need to ensure that their applications are coded in a secure way and that the potential for vulnerabilities is kept to a minimum. Some sectors, however, really can’t be seen to fail and security solutions has to be one of them whichever way you spin it.

“As in any other industry, vendors’ responsibilities and code of conducts are meaningless unless breaking them can have tangible consequences. Ultimately the only factor with enough leverage to improve the development process of commercial security products is a potential loss of profit,” Lorenzo Grespan told IT Security Thing, continuing, “other factors such as government guidelines often lag too much behind: when the rules are out they are already out-of-date and often too vague to be of any practical use.”

Similarly, Lorenzo thinks that security certifications suffer from the same fate. “It’s hard to distinguish the good ones from the bad ones unless you’re an expert,” he says, “but in that case you wouldn’t need the certification anyway.”

So why does insecure software continue to be developed, especially within the security solutions space? And why aren’t vendors leveraging existing tools such as sandboxes to enforce the principle of least privilege more often?

“As a developer I have all best intentions to produce secure software; nobody writes insecure software on purpose unless there are external factors involved such as bribery or secret court orders,” Lorenzo explains. “However, what I’ll ultimately deliver is as secure as my knowledge applied to the tools I use (such as libraries, networking stacks, etc).”

If those tools are ‘insecure by default’ then an inexperienced programmer with no incentive will likely produce insecure software. “Writing good software is already hard,” Lorenzo admits, continuing, “if security is yet another layer of complexity to keep in mind, we can only expect bugs to increase.”

In other words, why would a vendor invest time and money to train their resources if nobody will notice at the point of purchase?

“The previous example shows the two main factors affecting practical security: knowledge, and tools,” Lorenzo told IT Security Thing, “a vendor with limited budgets has little incentive to tackle them; sadly those who do are a fortunate exception.”

And as for the sandboxing and limiting of privileges point? “In an ideal world a security product runs with a set of privileges that is strictly necessary to perform its job,” Lorenzo says, “the operating system is tasked with enforcing them. Some products would need high privileges, because that’s genuinely the only way they can perform their duties. Other (and I suspect most) security products require high privileges because it’s the path of least resistance.”

We asked what Lorenzo meant by the path of least resistance in security? “It’s much cheaper to ask the end-user to grant administrative privileges (thus shifting the blame to them) rather than waste limited man-hours in developing a secure solution that does not require great power, nor great responsibilities,” he explained.

Lorenzo went on to add that how would an end-user know whether all those privileges are really necessary anyway? Android is a good example where new apps that don’t really need access to photos, location or contacts ask for, and are given, permission by the user. Trusting users to make the best security decisions is always going to be walking on dodgy developer ground.

“Can I trust my grandmother to know what the ‘unique phone identifier’ is?” ponders Lorenzo. “Regardless of how security is enforced on paper, ultimately the practical element to make software secure lies in the developers,” he insists.

“This is not a problem we can solve solely with technology,” Lorenzo says, “we need to tackle the root causes of it by tightening the collaboration between developers and security professionals.”

Lorenzo also points out that relying on a single solution makes it a single point of failure. “That’s why the best security is tailored to specific needs and does not put all eggs in the same basket,” he says, “and that’s why all-in-one security solutions are too often a liability more than an asset.”

The ultimate answer on how to improve security in software is to tighten the bond between developers and security professionals

OK, so assuming everyone agrees that security is a process and not a product, and that implementing a process is costly and time-consuming, I guess we can also agree that to reduce the attack surface of an application requires a pretty strong incentive. “This can be achieved by reducing information asymmetry between buyers and sellers,” Lorenzo insists.

Lorenzo would expect that, once vendors and software producers in general have a strong tangible incentive towards improving the security of their product then they’ll look for ways to save on training and hiring costs while increasing their products’ quality. “This is a great opportunity and I hope its effects will trickle down to the developers’ communities,” he told IT Security Thing, continuing, “in fact, for me the ultimate answer on how to improve security in software is to tighten the bond between developers and security professionals.”

He is obviously on to something there. After all, it’s already taken for granted that good software is built by teams including developers, graphic designers and usability experts. “Why can’t security professionals be the new members of such teams?” Lorenzo asked us, adding, “why does security need to be limited to breaking things?”

At this point Lorenzo issued something of a plea to developers, who he sees as naturally inclined puzzle-solvers, to at least start investigating how to produce libraries and toolkits with a secure by default mindset.

“This will be no easy task,” he admits, “in today’s complex ecosystem of continuously changing products and landscapes it is very hard for a developer to also be well-versed in security.”

In fact, Lorenzo says that writing good, secure-by-default software, is no longer a task for the mythical lone developer, let alone when constrained by marketing-imposed deadlines. “That’s where I hope security professionals will come in the picture,” he concludes, “we have everything we need – people, motivation, skills, tools. We just need to put them in the same room and give them a purpose. It’s time to work together if we want to build a world where security is the default option, and not a costly alternative for those who can afford it.”