The Six Best Practices of IT Security
|View the Entire Series|
The Five Most Common Misconceptions of Enterprise Security
Misconception No. 2: Believing the Hype of Technology and Tools
Misconception No. 4: Assuming Secure Software is Costly
Below I provide six practical tips to get you on your way. Of course, every organizations 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 arent useful, perhaps you should be measuring something different. In most cases, the answers you get will be something like, Well, weve just started thinking about how to integrate security into our application development, so we dont really have anything tangible for you at this time.
Thats 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.
Its 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 isnt? 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 youve made in application security.
Dont 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 arent at least two-to-three times that of network security you have an imbalance in the number of vulnerabilities youre 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 its 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 doesnt even factor in things like reputation loss, cost of patching and deploying, and other losses that usually come along with security defectsthings 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; shouldnt you also consider how to mitigate or transfer your risk when youre doing this?
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 dont 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 dont 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 dont 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 Analysts 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 youve 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.