The first step, and most important aspect, of implementing application (or any other) security measure is receiving buy-in from leadership. The business leaders push down the priorities all across the organization.
If the leadership support stops a level or two below the CEO, your security programs scope will be severely diminished.
A CISO or CIO may have the power to push out requirements to IT, but if you want information security pushed across business units you will need support from the CEO, CFO, or COO.
All leaders are going to agree with the idea of information security. They have seen the results of poor security in the news in the TJX and Heartland cases.
While hearing those types of stories can bring great attention to information security needs, it's not fear mongering we want to do.
We want to move beyond a CYA approach and present the business risks, including the costs of a potential breach versus the costs of a countermeasure, and help our organizations leaders make educated business decisions.
Getting executive leadership to buy off on an integrated security program takes more than a 30 minute meeting filled with horror stories. It takes an ongoing relationship with the InfoSec professionals based on trust, not fear, and an understanding of the scope of the business risks associated with data protection.
The executives do not need to know every detail of how security is implemented. Getting to that level is probably a waste of their time. But they do need to understand the importance of security and how that ties into producing high quality products, and providing high quality service to clients.
Working closely with the highest levels of leadership can be daunting. Their calendars are often full, and difficult to get onto. Work through your chain of command. I am not suggesting you march into the office of your CEO. Build a coalition among your boss and his/her boss.
Step Two: Education
The education of staff is the next step. This starts at a very high level for all employees but gets down into technical curriculum as necessary. Each employee needs to know not to click on phishing emails or send out clients personal information.
But maybe only the development and QA team needs to be trained on the Software Development Life-cycle.
And while the standards for data input validation may be applicable to all, the techniques used for preventing buffer overruns are of no use to the .Net and Java developers. Just like your client/server developers don’t need Cross Site Request Forgery training.
Implementing training that is timely, specific and personally meaningful for each team is critical. Generalized trainings for an entire IT department are going to lose 90% of your audience for 90% of the time.
The QA folks will snooze through the network security talks. The help desk will fall asleep during discussion of development standards.
To manage so many diverse training needs, the tasks of determining curriculum must be handled, at least in part, by a member of each team. An InfoSec professional working with a developer can craft great training that will have targeted impact within that development team.
This type of formal training should be performed at least annually. On top of that, you want to provide learning opportunities more often for team leaders, those in fast moving technologies and other interested parties.
Organizations like ISSA, OWASP, and SANS are great ways to keep the in-the-trenches IT workers interested and up to date on security threats without breaking the bank.
If budget allows, sending employees to training classes can be a great reward and a way to let employees know the organization wants to support their career growth, at the same time increasing the employee’s value to the organization.
Step Three: Process
Build security requirements alongside functional requirements in the business requirements.
Functional requirement:
- “Needs to be viewable in three languages”
- “Must allow users to set their own color theme”
Include security requirements like:
- “Passwords must be changed every 90 days”
- “Only authorized personnel may view data X,Y,Z.”
By including these types of security requirements from the very beginning of the process, the developers know what's expected of them and can be game-planning how to deal with them all along.
Embed security checkpoints into the development cycle. After creating security requirements, you don't want to just assume they'll be successfully implemented and wait for QA to tell you at the end that the application is not meeting the security requirements.
By including security checkpoints in the development cycle, developers will keep these requirements in mind and increase the likelihood that your security is integrated and successful.
Determine metrics for success in secure development. Whether it is bugs per 1000 lines of code, percentage of security requirements met, or another metric that makes more sense in your environment, find a measurable way to report on the effectiveness of secure coding guidelines at your organization.
Implement performance objectives around secure coding. These objectives should be explicitly outlined in the employee's goals. Give ongoing feedback on the developer's success during the year.
Don't surprise him with either success or failure. Seeing these metrics and goals on a regular basis will keep application security top of mind.
Provide rewards. Research shows that in order for negative consequences to impact behavior they have to be applied at a much higher rate than positive consequences.
So, rather than punishing those who do not follow security guidelines, give perks to those who are successful.
A few free iPads will both get a whole development team on-board with security, and it will make the InfoSec guys look more like the good guy instead of the bully with a big stick.
Step Four: Testing
Get security involved at the very first architecture meetings. Talk about how the types of architecture you are using for the project will interact with one another. Figure out what unique vulnerabilities your product is going to have.
Work on threat modeling with not only the application architects and developers, but get the business owners involved as well.
They know better than anyone else what the system is supposed to do and what constitutes an abuse case.
While your developers might be able to prevent code flaws like XSS and SQL injections, they cannot help with all the potential logic flaws in a program. If the business doesn't help think of the threats, even the best developers can't make secure code.
Encourage developers to make unit testing for their code. Unit tests are not the end-all be-all, but in some cases they can help identify exactly when and where code is broken. By continuously running unit tests on their code, developers will be more aware of the impact and breadth of their changes.
Train up your QA team. They need just as much security training as your developers. They must know how to recognize potential security issues and know how to exploit them if they exist.
Find automated tools for QA (you can start with something as simple as Nessus), and teach them how to use the tools. From there you can start offering them training on manual and more complex tools for testing.
A well trained QA team should be the first (and only!) people to find any security issues that make it through development.
A combination of scanning tools, penetration testing tools, and manual testing can help point the development team in the right direction before a vulnerability is exploited and splashed all over the internet.
Get Proactive
Don’t wait for your users or the hackers out there to find the vulnerabilities in your app. You’ve got a good selection of tools at your disposal. Use them all in the right way.
Black box scanning: Don’t count on black box to get you very far, but don’t assume it’s worthless either. These types of scans are usually the easiest and cheapest to run, and you can have them run on a schedule without any human input.
Get used to reading the reports; know what it says, then when something changes in your environment you can pick up on that immediately in the report and research what changed.
Code reviews: Code reviews aren’t the easiest part of the program, but they are one of the most important. Your development team is responsible for all the code it produces.
Code reviews are a good way to ensure that the team sees what it’s releasing. It can be the entire team going over selecting high-impact portions of code, or one individual reading through another’s code before it gets pushed into service.
Figure out a review schedule that works in your work-flow and get it going.
3rd Party Pen Tests: An external pen testing company can be a good way to have the security of your software verified. Get them in the environment and let them see what they can break. Be sure you’re working with good pen testers.
Ask what kinds of activities they’ll be doing. Someone who just runs application testing software against your site, then cleans it up for a report, isn’t giving you a lot of value. Find someone who will be using a combination of tools and manual hacks to go after your site.
Application Firewalls: An application firewall is not a cure-all. You cannot throw this in front of an insecure app and expect to fix the problems with it. But a well configured application firewall can be an effective part of your security.
You will need to tweak the firewall for your application to teach it what normal behavior is. The proper tuning of an application firewall can be as complex as coding the program itself, but it can be worth it.
In the end you get another layer of protection that is programmatically diverse from the application it’s protecting.
Summary: How a good application security program looks in practice
Good application security begins even before the first requirement is written for a project and does not end until the last remnants of the project are end of life.
- Executives who believe in information security push down corporate policies that include security goals for executives, managers, developers and QA.
- Software architects with good security awareness and appropriate technical security training determine the right architecture to meet all business requirements for a project.
- Requirements are documented for the new project and security requirements are right there next to the functional requirements.
- Developers who are trained in the secure coding techniques, and who have been told that creating secure code is a priority, implement secure code.
- QA analysts go through their test script ensuring the application functions appropriately, run their security tools, and use their experience to look for vulnerabilities while they test functionality.
- Regular code reviews, web scans, and penetration tests work to find new vulnerabilities before the bad guys do.
- Internal audit ensures that technical teams are adhering to their stated information security standards and procedures.
Let me know how you’ve implemented AppSec in your organization.
Cross-posted from Enterprise InfoSec Blog from Robb Reck
