Establishing application security requirements is often a hard-learned lesson. Indeed it's an essential element of software development that many still take for granted. But it's more than just addressing "security". It's about coming up with the right security controls for what the application – and your business – really needs.
It's no longer a matter of addressing the bare essentials and hoping no one will notice like in the days past. Customers are now more aware of information security and privacy and are demanding more responsibility and accountability. Furthermore, business partners know the exact questions to ask about application security. The myriad of information security laws and regulations aren't helping either. The reality is you and your team must step back and look at the bigger picture. If "quality" is indeed a characteristic of your business or a goal for each of your software deliverables, then the right security has to be put in place at the right time. No excuses. No exceptions.
Rather than throwing together some basic application security requirements along the lines of "require strong passwords, use SSL, and validate all user input" it's important to understand the bigger process. As shown in Figure 1, an effective strategy for eliminating the security as a checkbox syndrome is to think longer term and approach application security in a more methodical fashion.
Getting management on board can be one of the most difficult steps but it can be done if you build trust and stay connected. Defining what security means is arguably the most critical step. Keeping risk in mind you, your team members, and other key players have to determine the minimum necessary controls to keep information secure and satisfy the right people. Determining what it's going to take is the actual process of defining specific security requirements. You're going to have technical security requirements, operational security requirements, and business process requirements. More on this below. Acquiring the resources you need may involve training, purchasing security scanners and analyzers, and adjusting your QA process in order to find the security flaws that matter so you can eventually help the rubber meet the road. Some specific considerations are as follows:
- What do your internal security standards and policies require? You may already have what you need to get started.
- What key contract requirements must be adhered to? This is where you have to get your lawyer involved.
- What specific government and industry regulations will your business – or your clients – be subject to by using your application? Your compliance officer (sometimes known as the IT manager) can help with this.
- What other direct and indirect liability issues could arise from an individual or a business using your application? Threat modeling and coming up with various (mis)use cases can help here.
- What claims are you making on your Web site, in your literature, or in sales presentations that set people's expectations about the security of your application?
- Will your security controls apply to untrusted outsiders, trusted users, or both?
- How will you validate that the intended security controls are working? Will you perform manual verification, run a vulnerability scan, or both?
- Have you considered the attack vectors associated with authentication, access controls, and input validation (XSS, SQL injection, etc.)?
- Have you factored in the seemingly simple yet often big-time gotcha of not using CAPTCHAs for publicly-accessible forms?
- Have you considered role-specific flaws such as SQL injection and privilege escalation across all user role levels?
- Have you considered browser-specific flaws all across all mainstream browsers such as how popup windows are handled and how script code is executed?
- Have you considered application logic involving the storage, creation, and transmission of sensitive information?
- How do you plan on handling errors? Will you provide a means for simple – yet in-depth – system monitoring?
- Do you plan to have a catch-all security mechanism such as an intrusion prevention system or web application firewall which can serve as a good last line of defense?
It's been shown by time management experts that one minute of planning can save five minutes in execution. That alone should be incentive enough to plan ahead and do security right the first time. However, it'll take much more. Making things happen with application security requires not only an evangelist but it also requires someone to see things through.
Many people, when approached about application security understand the general gist of it. But support often stops there. It's up to you or another dedicated resource to lead and see things to the end. I'm not just referring to the end of the development/QA phases but over the entire application's lifecycle. This means attending compliance meetings, marketing meetings, customer service meetings, security meetings, internal audit meetings, and so on. Getting involved in all the areas that affect application security is absolutely critical for keeping the momentum of your security requirements rolling.
Somebody's got to do it. Are you up to the challenge?
About the author
Kevin Beaver is an information security consultant, expert witness, author, and speaker with Atlanta-based Principle Logic, LLC. With over 21 years of experience in the industry, Kevin specializes in performing independent security assessments revolving around compliance and minimizing information risks. He has authored/co-authored seven books on information security including the newly-updated Hacking For Dummies, 3rd edition. In addition, he's 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 his website www.principlelogic.com.