The Six Best Practices of IT Security

By Ed Adams

(Back to article)

In previous articles, I wrote about common information security misconceptions and mistakes organizations make. As valuable and occasionally humorous as those mistakes can be to learn about, the real payoff comes when you understand what proactive steps to take to prevent your organization from making those same mistakes.

View the Entire Series

The Five Most Common Misconceptions of Enterprise Security

Misconception No. 1: Over-Relying on Network Defenses

Misconception No. 2: Believing the Hype of Technology and Tools

Misconception No. 3: Too Many People Assumptions

Misconception No. 4: Assuming Secure Software is Costly

Misconception No. 5: The “Recency” Trap

If you want to comment on these or any other articles you see on CIO Update, we'd like to hear from you in our IT Management Forum. Thanks for reading.

- Allen Bernard, Managing Editor.

FREE IT Management Newsletters

Below I provide six practical tips to get you on your way. Of course, every organization’s mitigating controls are highly contextual, so adopting all six may not be right for you. But if you follow these, even just a little bit, you will be much more informed about information security and better equipped to make decisions on time and resource investment.

This short, six-step plan will help you to integrate security into your information management and application lifecycle and each is a short-term investment for a long-term gain; the best of both worlds as security is fast becoming a non-negotiable business requirement that your customers are demanding.

How to Avoid Mistakes: Six Good Practices

1. Make a Self Assessment

This is quick and inexpensive. It means going through a check list to see if you have incorporated application and information security into your risk management framework and determine whether you have integrated security into each phase of the software development lifecycle.

It is a very simple meeting with your VP of Application Development to have him or her list the different phases of their specific software development process. Then ask how they handle security at each phase and determine whether or not the outputs of those activities are usable in your risk management process.

If the outputs aren’t useful, perhaps you should be measuring something different. In most cases, the answers you get will be something like, “Well, we’ve just started thinking about how to integrate security into our application development, so we don’t really have anything tangible for you at this time.”

That’s OK because that would be an ideal time to discuss your needs with that team. Bridging the gap between application development and risk management is a highly valuable activity and it can be jump-started by this simple self-assessment.

It’s a simple checklist that will give you a quick gap analysis as to where you stand on the information and application security maturity model (see figure 1 on Page 3).

Threat modeling is also an important and valuable step in a self-assessment. It is a more mature and sophisticated approach than the checklist mentioned in the previous paragraph, but the payoffs are substantially greater.

Threat modeling, at the business level and the application level, is part of a risk analysis and risk management that allows you to identify where the biggest threats are to your business. This is the Sun Tzu approach of “To know your Enemy, you must become your Enemy.” The basic idea is to define a set of attacks or negative scenarios and assess the probability, potential harm, priority, and business impact of each threat. This can be done at any stage, e.g., design-through-deployment and yields more valuable results the earlier it is applied. You may need help on your first couple of threat modeling exercises, but there are plenty of good information security consultancies that can provide this.

When you develop a threat model it becomes a tangible, persistent asset for your organization as well. If a new vulnerability or a threat is detected, you can reuse your threat model to determine whether or not you are at a risk increase, decrease or static. The threat model can help you avoid falling into the Recency Trap and will tell you whether or not a newly-identified threat is already mitigated in your system.

2. Believe the Application Security Hype

This is an unfortunately necessary action as there is a lot of hype and fear out there that vendors and media are spreading unnecessarily. However, the application security hype is very real and we have seen it from recent and past headlines: the Lexus-Nexus breach, the recent problems at TJX, and even the incidents at T-Mobile and CardSystems were all information security incidents caused by application security holes.

So how do filter through the chaff to determine what is real and what isn’t? One thing that can help is to focus on the application layer. The network and systems layers represent less than 30% of all security vulnerabilities (according to Gartner Group); this number is less than 10% according to NIST.

Also, consider that network security is much more mature than application security and the investments you have already made here are probably orders of magnitude higher than those you’ve made in application security.

Don’t ignore network security, but try this practical tip: Make a list of the investments and compensating controls you have in place on the network, e.g., anti-virus, IPS, firewalls, etc. and along with that list their costs (initial/purchase cost is fine). Now do the same for your information and application security investments and compare them.

If the application security investments aren’t at least two-to-three times that of network security you have an imbalance in the number of vulnerabilities you’re mitigating.

With that first filter applied, you can now consider where and when is it most costly to address application security. IDC and IBM conducted a study about two years ago that mapped the cost of fixing a problem through the software development lifecycle. The results were roughly exponential with respect to time and phase.

Said another way, if a defect found at the design phase costs 1X to repair, the same defect costs 6.5X to fix if found during the coding phase, 15X if it were found in the pre-deployment testing phase, and 100X if it’s found by your customers in the field after it is deployed.

Keep in mind that this only accounts for the time and effort it takes to fix the problem (internal costs). It doesn’t even factor in things like reputation loss, cost of patching and deploying, and other losses that usually come along with security defects—things like loss of market share and stock price.

3. Ask Tough Questions

Tough questions are great because they make you think. The challenge is usually determine what questions are the tough ones. I provide a short list here to get you started. You will see the pattern fairly quickly and can expand on them for your own environment.

These are questions that are useful to ask your vendors before making a software purchase. You should also ask the same questions of yourself as you build and maintain applications for your business to use.

Finally, use these questions to improve your service-level agreements with outsourced partners (especially software development partners). Since you are probably making a purchase or partner contract to automate or transfer some business function; shouldn’t you also consider how to mitigate or transfer your risk when you’re doing this?

  • What is your vulnerability response process?
  • What is your patch release strategy?
  • What methods do you use to inform customers of vulnerabilities?
  • What guidance do you provide for secure deployment/maintenance of your product?
  • What security training does your development team receive?
  • Do you patch all versions of your applications at the same time?
  • What are the terms and period of your security support agreement?
  • Do you practice security reviews at each phase of your software development lifecycle (requirements, design, coding, testing, and deployment)?
  • Do you employ independent 3rd-parties to conduct security assessments on your products?
  • 4. Create an Internal “Red Team” of Ethical Hackers

    This is a term borrowed from the military. The concept here is that you dedicate a small team (usually three people or less) to act as attackers. This can be a permanent role if you can afford the resources, or you can take some nasty-minded testers and make this part of their job at various phases in the development process.

    Their job is to attack your application systems and your networks as if they were evil. I don’t recommend constraining them to act just as "outsiders". The insider threat is often overlooked and you can learn a lot from creating attack scenarios from an inside user perspective.

    If you don’t have the resources or skill set to create Red Teams, there are many third-party consulting shops that can do this for you. Start with your most critical applications and work your way down the risk rank stack.

    By the way, you also need to be certain that any third-party assessments company you use is capable. So ask those same tough questions of them, focusing on things like: methodologies used, credentials, engineers they are going to use on your application, how/if they depend on the use of automated tools, etc.5. Educate Your Teams

    I cannot overstate the value and importance of this practice. Education is the first step toward awareness and, as you will see in the chart from Gartner below, you still have a long way to go after you have become “Aware!”

    The challenge most organizations face here is two-fold: How to best educate their teams, who might be geographically disbursed and of different skill set; and, which team(s) to invest in for security training.

    Deciding which team to train (or in what order) is a highly contextual decision that needs to be made based on your specific organization. However, having helped several companies successfully roll out security awareness programs recently, I have observed a few critical success factors that I will share here:

    Management Buy-In - Security awareness will likely lead to behavior and policy changes at your organization. For that to happen effectively and efficiently, management must be on board. Even better make them part of the change by ensuring that your program has elements that appeal to management.

    Ensure Policies Can Be Enforced - Write clear, understandable, current, and measurable policies. Naturally, the policies need to reflect the corporate, threat and regulatory environment. Awareness and training programs should address the importance of adhering to policies, as well as the potential financial and reputation impact to the organization from security events.

    Measure and Report - Use both qualitative and quantitative metrics to obtain feedback, measure and benchmark the effectiveness of your security awareness and training program. Most importantly, communicate these metrics and results (good or bad) to your management team for their input, support, and insight.

    If at all possible don’t limit education to only security awareness, but also provide technical security training for your engineers, auditors and others. This training is more difficult to find, but you can locate some excellent security specialists that provide training in scalable formats, e.g., eLearning, for both management and technical staff.

    An Analyst’s View of Security Investment

    Below, I provide a chart created by Gartner Group. It describes what they call the "Information Security Maturity Model," or ISMM. The chart shows the progress organizations make as they mature in their information security awareness.

    It tracks the percentage of organizations’ IT budgets allocated to security and shows how it balloons and then contracts as companies move through awareness toward operational excellence.

    I find it interesting that 80% of organizations are still in either the “blissful ignorance,” “awareness,” or “corrective” phase. I suspect that number is substantially higher if this were tracked for only application security. The message I take from this is: GET AWARE. And the best way to start? Well, if you’ve made it this far in the article, you are well on your way!

    Ed Adams is CEO of Security Innovation, an independent provider of application security services that include security testing and training.