The same concept can be used for a secure developer workstation. The developer logs into the more secure physical computer, and must do so using 2FA/MFA logons. This prevents easy password phishing attacks from stealing developer credentials. The developer SAW must be prevented from going to the internet or being contactable by the internet. The develop should also have to open up a less trusted, completely separate virtual computer to do non-developer stuff or connect to the internet.
Developers might argue that they need free rein on the trusted developer SAW to access websites that help their productivity, but it’s that direct access to the internet that presents the most risk. Everything else pales in comparison. If you give in on this point, nothing else really matters. Really, why do any of it at all? This needs to be the line-in-the-sand.
I wouldn’t even allow connections to pre-authorized, trusted web sites (see water hole attacks above), or even trusted vendor websites. Once you start allowing any internet connections to the developer SAW, it will begin the creep of less trusted web sites being added to the exception list. In a year or two you’ll end up with dozens to hundreds of exceptions and kill the whole reason for going to a SAW.
One exception: If the developer develops on and for an internet cloud platform such as Azure or AWS, then obviously those exceptions have to be made.
A developer SAW can have a few other additions as compared to their admin counterparts. One, it is probably wise to include a strict whitelisting application control program on every developer’s workstation. Whitelisting application control programs are great at preventing malicious executions, but developers, as a rule of thumb, are constantly developing new drivers and programs. If the developer doesn’t need to run new kernel code or programs, enforce the whitelisting program.
If they constantly create new executable content, see if you can use what’s called a “path” or digital signature rule to allow legitimate execution. For example, on Windows computers, most developers shouldn’t be creating new executable code for the Windows\System32 folder on their own system.
Central tools server
You can also create a central tools server with all the pre-approved developer tools that aren’t pre-approved for use on the default SAW image. Developers can log onto their SAWs, go to the servers they need for the session, and map a drive share to the tools server.
Disable removable media
Another key factor of a secure developer SAW is to disable the ability for anyone to remove source code in an unauthorized manner. This means disabling removable media (or at least requiring encrypted removable media when it is allowed), disabling cut-and-paste actions, and anything else that would allow a developer to remove source code or data from their authorized locations.
Sign up for Computerworld eNewsletters.