When reviewing internal documentation and interviewing developers, development managers and quality assurance (QA) staff, I tend to find more of the same. It's no wonder software security is still a large contributor to business risk.
The four fundamental areas I believe create the largest gaps in software security are:
- Limited adoption of security models or frameworks such as Microsoft's Security Development Lifecycle or the OWASP Top 10 Project.
- Minimal interaction with IT and security personnel on issues outside of basic system deployment and availability.
- Security controls such as SSL, strong password enforcement and multifactor authentication being treated more like a feature that someone wanted rather than a means of minimizing business risk.
- Software team members being excluded -- sometimes exempt -- from information risk-related policies, assessments/audits and security mitigation strategies.
And these contributors to software security problems are rather consistent across organizations and industries. It doesn't matter if your business is large or small or somewhere in between, odds are you have some operational issues at the root of many of your software security problems.
So, where do you start? How can you even begin to fix such issues that are so deeply embedded in your business operations? Well, it's not simple but it can be done. IT, security, development/QA and management all have to be able to answer the following questions:
- Has any one person or group come to a conclusion on what "software security" actually means in the context of your business? You cannot fix what you don't acknowledge.
- Is there any semblance of documented security standards for not only operating systems, routers and databases but applications as well? Ideas that aren't documented are merely wishes.
- Are development and QA mentioned anywhere in your organization's security policies, plans and procedures? They should be. They have to be for this to work.
- Are periodic and consistent checks being performed (using good tools and smart people) to ensure your software meets a standard set of security controls? Every business should at least have a baseline of what's accepted beyond the overhyped SSL, strong passwords and input validation controls.
- Perhaps most importantly: Who does management have to answer to? Internal auditors, maybe external regulators? Pleasing one group of people may be a whole lot easier than pleasing another. Know what you're up against and it'll be clear what level of software security to shoot for.
As sexy as the technical side of software security can be, it's often the oversights and assumptions on the "boring" business side of things that'll get you into trouble. Get the right people together and ask the tough questions. Once everyone's on the same page you can start working toward gaining and maintaining control of your business's security obligations.
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.
Dig Deeper on Building security into the SDLC (Software development life cycle)