April 30, 2015

April 10, 2015

Please reload

Recent Posts

I'm busy working on my blog posts. Watch this space!

Please reload

Featured Posts

Securing Developers

February 19, 2014

 

It’s something we all talk about. It’s something we all wish we did better. It’s something that we all worry about at night: how do we “secure developers?” In this blog post, I’ll address strategies for increasing the security around your development organization, and provide tips for accomplishing your goals.

 

Security is one of the few jobs where we can never say we’re done. A painter looks at the wall and sees color where there was primer. A salesman sees signed contracts. A bus driver sees all his stops were completed. A security professional? Yah, all we see are holes, risks, and incomplete mitigation. Securing our developers is no exception – in fact, for a couple of reasons, securing developers is actually a bigger challenge.

securing developers

 

For starters, developers are as technical (often more technical) than security staff. Sometimes that technical gap is more perceived than real, but it poses challenges nonetheless. The engineering world is generally a meritocracy; good ideas survive by being ripped apart and standing up to close scrutiny. When an inexperience security analyst throws out an idea like enabling local firewalls, developers can generally come up with a couple of dozen technical reasons why that might prevent them from accomplishing their work, or why it might not mitigate every risk. The poor analyst is overwhelmed by evidence (some tangential) and the team skulks away to lick their wounds. Yes, it has happened to me, too. And when a security control is forced in place, many developers have the technical ability to circumvent the control. Process and policy have little sway in the development world, so if a technical work-around exists, it will be used.

 

Related to the technical gap is what I call the “Simba mentality” (quoting from the Lion King, “I laugh in the face of danger”). Many developers fancy themselves dialed into security threats and believe the technical measures typically deployed on an end point simply aren’t necessary because they perceive themselves as savvy enough to identify and avoid common attacks. Security controls such as proxy servers, whitelists, and lack of admin access are often challenged by developers as being unnecessary because, in their view, they have an advanced understanding of threats and therefore aren’t susceptible.

 

It isn’t all about attitude, though. By nature of what they do, developers generally need more administrative access than typical users (although living in an exception-driven world does reinforce developer attitudes). When spiking (an Agile reference to performing research), developers often need to install new development environments, support libraries, and other tools. While most of these resources can be installed and run without admin access, not all of them can. With tight deadlines and an infinite push to do more with less, developers and management are not supportive of security measures which interfere with and slow down projects.

 

All of this reality is balanced by the reality that developers are working on what tends to be the crown jewels of the company: intellectual property which has commercial or business value. That IP needs to be protected – just ask Microsoft, Google, and Adobe (each of whom have suffered IP leaks).So how can security teams succeed in this high-risk, low-compliance environment?

 

Here are three steps which can help you make better inroads:

  1. Agree on the risks
  2. Inform and enlist
  3. Be consistent

 

Agree on the Risks

Agreeing on the risks is the place to start, and that begins with communicating. Bring developers to the table for conversation, and actually listen. Start with a blank whiteboard and begin enumerating and discussing risk. Often developers are aware of and bring up risks the security team hasn’t even considered. This is a time to build relationships and develop a collaborative engagement, so be open to everything and be willing to consider other points of view. This is also a time to be willing to lose (or delay victory on) small battles. If you’re worried about administrative access, but developers raise a concern about better training in secure development practices, take the win—get SDL training started, and come back later to discuss admin access.

 

Inform and Enlist

Nothing puts off a developer like being told what to do – especially by someone not in their management structure or who they deem to be technically less qualified. To succeed in pushing security into the development organization, security leaders need to inform and enlist developers. Make the developers part of the solution, rather than trying to force a solution on them. When the list of risks is agreed to, the next step is to address them in a prioritized manner. Build a focus group of developers (mixed up with managers as well as influential individual contributors), and let them think about possible risk mitigation steps. Half the time, they’ll come up with the same solution you would have recommended. Some of the time, they’ll come up with a better solution. The rest of the time, you’ll be fighting an uphill battle, but at least the battle has been scoped and they are part of the solution.

 

Be Consistent

The worst thing you can do as an IT security leader working with developers is be inconsistent. If your first meeting produces more questions than results, schedule a follow-up meeting and keep driving. If your first stab at removing admin access is a failure, don’t give up—keep researching. If your first idea for network segmentation is shot down, try again. Over time, you will succeed. Given the high-value IP places in their hands, success is critical to the business and you cannot afford to give up.

Share on Facebook
Share on Twitter
Please reload

Follow Us

I'm busy working on my blog posts. Watch this space!

Please reload

Search By Tags