This is a guest post on the Computer Weekly Developer Network by Brian Chappell, director of engineering for EMEA & India at information security and vulnerability management/assessment company BeyondTrust.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
What drives software?
We all know that the world of software development is driven by many factors including new features, improved functionality, better performance and fast time-to-market.
All rightly so…
… but concerns for security can lag behind and it is often seen as an operational concern.
So does this matter?
Having developed a few apps in my time, I believe that it does.
A niche ASP.NET MVC web app I wrote several years ago still receives an average of 50-60 hacking attempts daily, many of which are looking to target the administrative side of well-known products.
Fortunately, for web apps we usually have security at the forefront of our minds, as these usually a have user login and restricted pages in some form, forcing the developer to consider the user privileges needed.
But, when it comes to what we intend to be short-term applications running on user workstations are we as diligent?
This is not to say that security is the sole responsibility of developers – far from it – but I argue that security becomes easier when everyone involved in the delivery of software puts security near – if not at – the top of their list of priorities.
Two central X-factors
For software developers this can be boiled down into what amounts to probably two main considerations: thinking about the security requirements of the software they are crafting (should be a given); and just as importantly, the security of the systems they are using to write the software.
It’s easy to think of the two aspects as being separate but the truth is that they are very much intertwined.
This brings us to a thorny and topical issue: administrator privileges.
It has long been assumed that developers should have very broad administrator privileges, because they need to be able to attach their debuggers to running processes, install and uninstall applications, install various tools and libraries, and so on.
But – having viewed this from both the developer side and the view of a vendor who has come across some horror stories in the marketplace – I reckon that developers need to consider their often unrestricted administrator privileges as a double-edged sword that they might want to revise.
The admin meltdown syndrome
Not only do admin privileges open up vulnerabilities on the developer’s workstation (over 70% of known vulnerabilities in Windows 7 require admin privilege to be exploited) but they can also introduce additional problems for security down the road.
An example scenario is a piece of software that needs to write or modify files in a privileged folder, for example Program Files on a Windows system or /etc on a *nix box.
This software would run without issue on the developer’s system, probably pass all its tests and be passed onto the operational team for deployment. The application has carried with it the need for admin privilege, the developer has most likely moved onto other projects and so the operational team is left with the need to modify the user privilege to enable it to run.
This is undoubtedly going to involve weakening the system security, either by adding admin privilege to the user, or by lowering the file system security. Both of these actions introduce vulnerability into the system.
The privileged API route
Another scenario would involve the use of a privileged API call that similarly works for the developer but requires additional privilege for every user of the software. Compilers produce errors and warnings when code isn’t correct or following best practices; if we could have a way of doing the same for the examples described then we can prevent these vulnerabilities from being introduced.
Nor is giving developers ‘standard privileges’ in line with other users in anyone’s best interests: sure, the code would then be unable to write to the privileged folder or call the privileged API, but debugging and installing would also be hampered.
The solution is the principle of ‘least privilege’, in other words the granting of only the privileges essential to the user’s work.
For developers, this means granting specific rights such as “Debug Programs” and the ability to install specified applications, tools or libraries. The developer is then able to write his or her software in a context that is close – if not identical – to that of the target user.
This leads to fewer vulnerabilities being introduced and a safe operating environment for the developer.
The principle of ‘least privilege’
Of course, where there is a legitimate need, for example for privileged API calls, then least privilege processes and tools can identify the specific admin privileges necessary, enabling the developer to provide an appropriate policy or rule to the operations team along with the application. This ensures that the principle of ‘least privilege’ is followed through to deployment and without the developer needing to become a security expert.
Of course, there are other security measures that developers could get themselves involved in, but better management of privileges goes a long way towards preventing all kinds of vulnerabilities further down the line.
Starting security from a position of privilege and attempting to manage that down means that control breaks down maximum privilege levels are exposed, whereas, least-privilege always defaults to the safest and most secure scenario of the standard user.
I can summarise it by saying that admin rights shouldn’t be inherently implicit and instead, they should be explicit (in other words, only applied where needed), something that applies not just to developers, but the whole organisation. Small steps, but ones in the right direction.