Each of us is expected to chip in and maximize the dollars being spent on IT in some fashion, and security's unquestionably...
a big part of this. Whether it's day-to-day system administration, internal audit, or writing code, everyone contributes. When developers don't – or can't – do their part, the security equation becomes unbalanced and business risks continue unfettered.
Yes, security's yet another thing you're responsible for and, frankly, you don't have the time to do it. I'm not a developer but I have written enough code in the past to understand what you're up against. There's syntax, business logic, networking and database integration. Oh, and your code needs to look nice to the user and not contain any obvious bugs.
The problem now is that virtually every part of an application has to be secured as much as possible. Java and C# take a lot of the legwork out of basic application security but there's way more to the equation. You're now tasked with ensuring login mechanisms can't be abused, integrating with third-party multi-factor authentication systems -- or building your own -- ensuring all input is validated, and that every part of the application is protected via SSL.
So how exactly are you expected to contribute as a developer when it comes to keeping security in check?
First of all, it's critical for you to be involved in the design phase. You can help plan out where and how security needs to work within the application, within the development process, and moving forward in the maintenance phase. You can be in charge of the technical implementation of application logic and controls that work in concert to secure sensitive information in transit or at rest. Finally, an issue that's often overlooked is the developer's role in performing code reviews: either manual checks, or preferably, static analysis.
You've also got less technical responsibilities. There's this little thing called compliance. Now you not only have to ensure basic security controls are in place, but you also need to work with other staff members and be able to demonstrate it via policy, procedures, and development practices from start to finish. This doesn't mean you have to become a compliance expert. However, get to know the general security requirements of the Payment Card Industry Data Security Standard (PCI DSS), the Gramm-Leach-Bliley Act (GLBA) and so on you'll definitely an advantage.
When you take the initiative to review the relevant regulations affecting your business allows you to not only set your own expectations but to help you establish or build your security mindset. You may even take a few minutes each week to review the Open Web Application Security Project's Top 10 and even the various software tools that provide a hands-on approach to learning about software security. Make a point to attending security-focused conferences. They can be very beneficial for both learning and networking with your peers. Any way you can expose yourself to information security concepts is going to help tremendously over time.
Now there may be certain situations where you're told not to do anything related to security on a project. Perhaps you're a programmer on a government contract or working within a specific component of an app that merely crunches numbers and thus there's not a security focus. By and large though, most developers in today's business environment have broader responsibilities. Whether or not it's specifically stated, security's almost always a component of all but the most simple coding projects.
So where do you go from here? Well, it's a matter of choice. Whether or not anyone is "making" you write secure code is moot. As a component of quality, secure code is expected in most situations these days. It's what you do beyond what's expected of you that'll really contribute to security. This means choosing to do what's right to not only create well-functioning software but applications that help the business manage risks. And businesses certainly need this help everywhere they can get it these days.
Stepping up your security game will require initiative and leadership on your part. You'll need to get more involved with security across the enterprise. This could mean attending security committee meetings or taking an active role in the business' annual security audit or assessment process. For new projects that come your way, having an open line of communication to the right IT and security personnel is invaluable.
Arguably the most important thing you could ever integrate into your development practices and application logic is learning how the bad guys think and work. Understanding the enemy -- particularly, their motivations and such techniques as web hacking -- provides you with the highest level of knowledge needed to protect against application abuse.
With the growing focus on software security, you're being expected to help lead the way. Establishing yourself as a key supporter and enabler of information security will help you rise above the noise and make yourself a person of value in your job. This is how development managers and CTOs are created. It's also how you can position yourself to not only get the work but to be able to choose the work that is most fulfilling.
About the author: Kevin Beaver, CISSP, is an independent information security consultant, keynote speaker and expert witness with Atlanta-based Principle Logic LLC, where he specializes in performing independent security assessments and information security career counseling for up-and-coming IT pros. Kevin has authored or co-authored seven books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels information security audio books and blog, providing security learning for IT professionals on the go. Kevin can be reached at kbeaver [at] principlelogic.com.