Precious source code
One of the biggest reasons why developers are attacked is their association with lots of source code. Malicious attackers can download it and look for vulnerabilities that they can take advantage of later on, or even more insidious, change the source code to contain a backdoor. Some once even (unsuccessfully) attempted to insert a backdoor into the Linux.
As just as threatening, trusted inside developers may take source code or databases home or to a competitor. When computer security people start talking about insider threats, oftentimes they are most worried about malicious coders with dubious intentions.
The problem is that even though developers agree that they need to be more resistant to attack, they are even more upset if you even think about taking away that elevated access all the time. Many developers are fine with the idea of being more secure, but openly resist if those protections slow them down more than a few seconds. I get that. Their life and paycheck depend on them being fast and proficient. Coding is hard enough without having to jump through too many hoops to get their job done.
Two main traditional solutions for securing developers have persisted. One gived the developer two workstations: one to do coding work on, and one to do everything else. No one likes working, carrying and switching back and forth between two computers.
The other was simply not giving developers admin privileges by default, and making them log onto elevated accounts only when they needed. This latter approach failed because developers need admin privileges all the time. They are updating drivers, source code, and servers as a daily part of their job. Because of these challenges, for a long time many companies simply accepted the risk and made security exceptions for developers. But an acceptable solution has arrived.
Your secure developer workstation solution
Over the last few years, the SAW concept has become nearly ubiquitous for better securing an enterprise’s administrators. A SAW is a specialized, security locked-down computer that admins are required to use to do anything administrative. At the very least, a SAW is prevented from going to the Internet, being contacted from the Internet, and on which normal, higher-risk non-admin activities such as internet browsing, email and file sending are not permitted.
Today’s SAWs often go further by preventing any unauthorized program from executing, usually by using a whitelisting application control program and requiring two-factor (2FA) or multi-factor authentication (MFA) for all logons.
The main difference between a SAW and yesterday’s traditional recommendation of developers using two different computers is that both can be on the same computer. SAWs often contain one or more virtual machines that run the higher risk, non-admin apps and tasks. The admin is forced to run all admin stuff on the highly secured physical computer, and the more open and less trusted “computer” runs as a virtual machine. It’s important that the more trusted and secured computer host the less secure and less trusted virtual machine. Otherwise, the basic tenet of how security trusts should flow would be violated.
Sign up for Computerworld eNewsletters.