Back to newsletter

Previous Issue's Dilemma:

Bad guy or security guy? 

On our development team, I'm "the security guy" in our small organization. Most of the time, I have to clean up security holes others have produced. How do I best motivate my colleagues to have security on their mind during development? Should I point out their code problems and work with them to fix them? Or should I continue to be the Bad Guy and delay the project until they code it right?

-- John B. (company name withheld)

John, you hit the jackpot with your questions. Readers have some detailed suggestions for ways you can address your problem of motivating your colleagues to develop more secure code. Several readers offer step-by-step solutions. You’ll still be the security guy, but maybe not the bad guy if you take their advice, which consists of taking three main actions:

• Create a security-oriented culture.

• Put simple processes into place.

• Remember that management is accountable.

1. Create a security-oriented culture

Security is not the first concern in many companies. Oftentimes staff members who do IT functions are busy setting up new employees or solving software/server problems. The first step in reducing risk is creating a security-oriented culture.

Drexx Laggui, an analyst at L&A LLC, thinks the best way to imbed security consciousness in your developers is to create a security-oriented culture. He recommends doing the following:

•    Be clear about risk assessment: "Show the developers a copy of the risk assessment sheet you may have written before you started coding the security functional requirements. (You know, that piece of paper with three columns that shows assets, threats and controls.) That'll make it easier for them to understand why they're doing these things."

•    The first and last defense: Laggui believes you should occasionally "forward them news articles of security breaches against information assets, and then share with them how you think the company should have prevented it from happening in the first place. Tell them that the security features you put in may well be the first and last defense they have … that their job is to prevent bad things from happening to the organization or business."

•    Implement training sessions: Another way to reinforce this kind of environment is through training. Laggui says, "Tailor educational sessions for your development team(s) across your organization to teach them how they could use static code analysis tools and/or dynamic code analysis tools, if these are available in the enterprise."

2. Put simple processes in place 

Sridhar G., a principal engineer at EMC, sums up the idea of having clear processes in place to protect your organization. He says, "Put a simple, easy-to-follow process in place with a workflow that meshes well with your existing software development life cycle (SDLC)."

The process should consist of the following steps:

• Examine the code: Each developer should examine code on his or her side tree, prior to doing a code repository check-in.

• Examine/audit the results of a periodic scan: Perhaps twice a week, on the full-code basis during the nightly "builds," examine the scan results. Each developer must audit the results of a static code analysis scan pertaining to his or her portion of the code. (This step is the bulk of the work. It is a typical divide-and-conquer approach that spares a centralized audit team from having to audit the entire scan results on a regular basis, which is cumbersome and inefficient.)

• Address issues immediately: Ensure that the appropriate developer or the development team responsible for a portion of the code takes care of any legitimate issue a developer identifies ASAP.

• Prevent repeat errors: Once the team has “fixed" an issue, ensure that the subsequent scan doesn't report the same error.

• Do enough testing: Prior to checking-in the fix, ensure that you do enough unit-testing and/or end-to-end testing to make sure that this change has not caused any regression.

3. Remember that management is accountable

Even if you create a security-oriented culture and put the right processes in place, if you don't have management support, all of your efforts could be in vain.

Laggui continues, "You should ask management to hire people with the right attitude from the beginning. But I think that's all water under the bridge for you now …" Fortunately, no matter whom your managers hire, you still can set an example by keeping security a priority and following established processes.

If management sets a good example -- that's even better.

Richard Lemons, senior DBA at WVDHHR, also thinks that it all comes back to management. "If management chooses to ignore the issues, then it should be responsible for the results."

Hopefully, you've got support from your manager or can educate your manager on how to best support a secure environment.

A carrot on a stick?

Drexx L. adds, "Let your developers know that if they get their software right in the first place, they won't have to spend all those boring hours writing patches and doing regression testing. Instead, they'll be happily developing new and more exciting stuff."