Secure development when working from home — tips and tricks

Secure development while remote

As we brace ourselves to an extended period of working from home, we need to re-evaluate various ways of working - and security is no exception. Remote collaboration, which is new to many, may require some changes to your security practices or priorities.

And so, here are a few suggestions for ways you can adapt your security policies for a newly remote workforce.  Beyond their immediate value, these practices will help you scale your security practices, even when people are back in their office chairs.

Download our handy cheat sheet: Securing Development that's Gone Remote.

Empower (remote) developers through documented guidelines

The key to remote development, especially when disrupted by kids running around, is to allow each developer to make progress on their own, and keep communication async. This means less waiting for approvals and more decision power. For security, this means reviewing your approval processes and seeing how many of those decisions you can pass on to developers. Instead of waiting for approval, the developer can keep things moving forward and keep you informed on their actions and decisions.

Successful empowerment requires alignment on expectations—does everyone understand what they need to do and what successfully executing a task entails?  This means you need to invest in documenting your practices and expectations, making it easier for developers to make the right decisions consistently.

Don’t break the build (as much), fail Pull Requests instead

“Breaking the build” due to a security violation is a very popular CI/CD security measure—but it is also very disruptive. Without a passing build, software can’t progress, and developers are largely stuck. This is especially true when the break is caused by an external cause, like a newly disclosed vulnerability in a library you’re already using.

When working remotely and async, such disruption is far greater as teams will take longer to figure out the problem, assign someone to fix it, and get it resolved. So, make sure you limit such breakage to truly extreme cases, like a critical vulnerability that truly warrants stopping everything to address.

For other issues, fail pull requests instead. Pull requests have several advantages:

• They allow you to test only the new code changes, which should be within the developer’s control to fix.

• They’re more local to the branch where code is modified, maintaining individual developer autonomy.

• You can choose whether a given failure blocks a merge or is just informational, again allowing developers to make the call and proceed.

Invest in security visibility

Developer autonomy is great, but you also need to make sure you stay secure. Instead of roadblocks, address this need through governance and visibility. DevOps has taught us that we can have a higher tolerance for deploying bugs, as long as we can detect and address them quickly. In other words, it’s not very likely you’ll be hacked by a vulnerability as soon as it’s deployed, so a quick response is nearly as good as never introducing the issue and less disruptive.

Visibility comes in many shapes and forms, but here are a few suggestions:

• Instrument builds to capture the dependencies packaged into your app. This is known as aSoftware Bill Of Materials, or SBOM. With an SBOM so you’ll know if a newly disclosed vulnerability affects your project.

• Post vulnerabilities discovered in the build (that weren’t severe enough to break it). A slack channel or notification emails can be used by l, security team members to glance through issues on a regular basis..

• Create leaderboards showing how well are different teams handling security issues. Security achievements (e.g. time to remediate a vulnerability) can be shared across teams. This can be used to gamify the process and create social momentum towards improvement. Teams can also see themselves getting better over time or have the opportunity to course-correct if they aren’t making the progress that they desire. Be sure to keep these leaderboards as informative only and resist the temptation to use them as a performance measure. Going that route can actually be counterproductive in trying to create an open culture of security mindedness.

Improve your individual skills, whether you are in security or development

Working remotely can be an exercise in self-reliance, which can be intimidating at first. However, many remote workers find that they have additional time in their day (once absorbed by commuting) to spend on learning. Use that opportunity to level up your teams, both on the dev and security side.

For developers, invest in security education. You can do so through online content such as MyDevSecOps, OWASP or  DevSecCon conference videos, or through commercial tools like SecureCodeWarrior. Be sure to check out the upcoming AllTheTalks online event whose proceeds go to COVID-19 charities!

For security, use this time to build or improve the team’s coding skills. These skills will be invaluable as we head into a DevSecOps world. Taking the time to learn more about coding will also improve your empathy towards developers. Here are a few resources to get you started:

• Cybrary: Python for Security Professionals

• Lynda/LinkedIn: JavaScript Training and Tutorials 

• Codecademny: Learn Go Programming

Celebrate security wins

Make sure you give developers a virtual pat on the shoulder when they advance the security cause. Developers are people and, like all people, need recognition to keep up their good work. Besides, they’ve earned it!

Working from home makes it doubly important. Social cues like a kind word in the office or high five (or maybe elbow bump…) aren’t an option, so you need to find virtual substitutions. Working from home can feel lonely and isolating, and giving people a boost when they do well can make a big difference.

How can you recognize good work? There are many ways, so get creative!. Here are some suggestions:

• A kind word on Slack or group email. This is simple but important. It can be one-off or some sort of “Security champion of the month”—as long as you keep doing it. You can even recognize their work publicly on your company’s social account if it merits it.

• Special swag, ranging from stickers to t-shirts to hoodies, reserved for those who’ve earned it. There are lots of examples of this on The Secure Developerpodcast.

• Actual monetary value gift, like a SPA day or a trip and ticket to DefCon (if conferences still exist after the dust settles).

Align security partners to dev teams and engage often

Building a relationship is hard enough, and building or maintaining one remotely is harder. To help remote developers know who to turn to when they have a security question, you need clear alignment between dev teams and their security peers.

Alignment doesn’t require org changes, just connecting people in daily working practices. For every member of your Application Security, Product Security or Cloud Security teams (however you divide things), match them up with team leads or directors from dev. Book recurring syncs between those peers, and have the security partner join virtual standups and other activities by those dev teams. These would be in addition to security team meetings, where you can get the bigger org picture. You can listen to Sara describe how Invision does it on The Secure Developerpodcast.

Focus on security hygiene

Our new reality requires focus, ensuring what matters most gets done. In security, that means prioritizing the basics before the esoteric attacks. Scaling how well you handle vulnerable components, configuration mistakes, and leaked tokens should take priority over sophisticated attacks for the vast majority of companies.

Once you successfully scale security hygiene to your remote development teams, you can expand your horizons again. To use COVID-19 terms, make sure everybody washes their hands regularly before you start buying hazmat suits.

Adjust Your Critical Infrastructure Defenses

If you were still relying on privileged networks, now is the time to stop. While employees can VPN, home networks (and equipment) are far less secure than your corporate surroundings, and you should anticipate more attacks coming through them.

Invest in or Expand Multi-Factor Authentication

Embrace this as an opportunity to begin investing in 2-factor authentication infrastructure. Securing the authentication of remote employees will be critical during this time whether you're operating in cloud environments or they’re connecting via VPN to your corporate infrastructure. The good news is, these investments now, while unplanned, will pay dividends for you in the future as you’ll be able to extend that capability to other systems on your network or cloud environment.

Improve SSH Security

You can add security to your SSH connections by enabling mutual authentication and shortening session times. Developers are often given access to production machines via SSH and those endpoints are authenticated by static private keys that are always present on the machines.

As more of those machines go remote, the risk of attack goes up. Increasing the strength of authentication on these interfaces then becomes critical. Adding or shortening session timeouts will also ensure that developer workstations aren’t left logged into critical systems or code repositories while idle.

To further improve, consider using open source systems like Netflix’s BLESS or SmallStep, or commercial options like Okta or others to enable stronger identity-based authentication. More on that in my InfoQ talk, “Developer as a Malware Distribution Vehicle”.

Bug Bounties

As some companies shut down temporarily, there will be many people looking for opportunities in the gig market. This is a great opportunity to strengthen your security assessment strategy via a Bug Bounty program. You’ll be helping create work for those in need of employment while making your software more resilient.

Bug bounties are a good way to add a layer of security assessment capability and provide clear direction for researchers on how to report vulnerabilities to your organization. Check out Hacker One or BugCrowd as platforms to consider. They can guide you through much of the process of setting up your program. If you have some spare time on your hands, you might even want to join in as a hacker too!

Conclusion

As many organizations adjust to the new normal of remote work it’s important to consider how people normally work and structure our security defenses to address those habits directly. Understanding the developer’s day-to-day functions and building security controls that keep them protected but still enabled to complete their jobs will be crucial for getting through these challenging times.