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)
Three ways to motivate employees
Application Security Over-confidence: Facts & Myths Revealed
Interview with Fortify Software Founder, CTO Roger Thornton
Application security is a key focus of regulatory agencies -- ensuring that financial institutions pay as much attention to third-party applications as they do to those they develop and manage in-house.
In this exclusive interview, Roger Thornton, founder and CTO of Fortify Software, discusses the survey results and his own market perspective, how the survey results compare with what he sees from customers and the disconnect between confidence and processes, as well as some of the proactive, cost-effective ways companies can tackle application security.
Learn More ...
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.
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."
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/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.)
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."