Implementing Application Security in the Enterprise

Tuesday, October 19, 2010

Robb Reck

Step One: Executive Buy-In

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

Possibly Related Articles:
Enterprise Security Application Security
Post Rating I Like this!
Allan Pratt, MBA Good post, Robb.
George Turrentine Robb

Great article. I agree with most of your points - but would add to Step 4 - not all QA departments are created equal. I have seen too many that are made up of ex-developers and the scope of their expertise is in making sure business and functional requirements are adequately met. In a few cases and with the proper training, yes, I would agree a QA department can be an effective force for securing applications.

Black box testing should never be run as a point and shoot technique - in the case of dynamic analysis put that same tool in the hands of a trained user and let them manually crawl before the attack takes place and they will find more areas of concern, policy non-compliance. With QA tools which can be automated for black box testing, unless due care is performed in creating the tests - many aspects will be missed - case in point most developer's test code for positive results - but rarely for complete negative test.

I would also highly encourage that the application be critically reviewed - I created a dynamic questionnaire that can cover all the domains in ISO 27001/27002 or ISC2 CISSP domains and OWASP categories - using this we can easily see if security and data protections are in place and appropriate. This also allows you to quickly scan and find similar applications if a vulnerability is discovered and then appropriately notify and obtain the corrections required.

You really need to have a holistic view of all of your applications and the exposed risk internally and externally. Many companies perform due diligence on their most sensitive applications and yet the much less sensitive application sitting nearby with trusted communications to the trusted application has little or no governance evaluation, guess which one is easily knocked over and used by a hacker.

As for application firewalls - they are a good crutch when you are injured - but the self-defending or secure applications is a much better position to be in. Many companies buy the application firewall and fail to analyze and constantly tweak the firewall rules as vulnerabilities and deficiencies are discovered, that false sense of security that is now inherent to all firewalls - I have it, I deployed it, I am now safe - every hole in any firewall is an attack vector for a insecure application or infrastructure.

I do agree with your education section - developers especially need secure coding training. At the same time a security department must know what vulnerabilities are discovered in the code and through the testing and then create focused training and awareness for the developers that help them create more secure code - it is not a finish line to be achieved but an on-going feedback loop.
Robb Reck George,thanks for taking the time to read this article and provide such insightful feedback.

I agree with all of your points. And I think a fair summary is that; there is no magic bullet. Secure coding is always key, but even with the best written applications there will be new vulnerabilities discovered either in that application, or in the underlying technologies. That's why we strongly suggest a defense in depth strategy, where no single point of failure will mean an attacker has compromised the system.

I want to avoid ranking the different countermeasures in terms of importance because I believe that to create a high quality product security has to be implemented in multiple places and in different ways.

The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.

Most Liked