Welcome to Volume 2, Issue 9 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community. The editorial calendar at this time includes:
For previous Insights issues, click here.
TISC is about sharing clue. So is the newsletter. We promise to provide some- thing useful each issue. If we don't, flame me at mailto:dave@corecom.com.
First, I must apologize for the delay in pushing Issue 9. I received several notes from readers asking if we'd terminated the newsletter. Not true. Following TISC 2000 in April, I decided to take a break. We're back, and will resume our bi-weekly schedule.
Enjoy, and be safe,
Dave
In today's feature column, Diana Kelley and Ian Poynter present a helpful checklist of issues to raise and questions to ask of Application Service Providers should you decide to look into outsourcing back-office and mission-critical applications. It's your data, and your business depends on its availability and integrity. You should also be concerned about who is accessing and managing it. Diana and Ian offer you the top ten on their list of items to grill ASPs *before* you outsource.
The Application Service Provider (ASP) craze is sweeping the industry. ASPs take outsourcing to a new level, moving not just services but equipment, back- office servers and mission critical data off site to be managed outside of your organization. There are many appealing benefits to this trend, including reduced corporate overhead and less worry about the day-to-day management of systems. However many organizations are blinded by the perceived benefits and don't fully consider the security implications of their actions. In this column, we offer important questions that companies should use to probe the security readiness of prospective ASPs.
Tip 1. Do You Have A Security Policy?
First and foremost, we look for a security policy in any organization. The policy is the framework by which we can judge the attention to security of critical data. All procedures should flow from the policy. When an organization that isn't familiar with your corporate policy is handling your mission critical data, it's essential that you review their policy to determine whether they have an understanding of reasonable security practices and to ensure compliance with your requirements.
Your own security policy should define the limits and boundaries for the transmission of information outside your organizational control. ASPs should willingly accommodate your security requirements, and you should be suspicious if they attempt to persuade you to do other than what you have determined to be in the best interest of your company.
Tip 2. How Do You Ensure *My* Security Policy Is Being Enforced?
Policies are useless without enforcement. We look for procedures and controls that show the ASP is able to enforce the individual security policies of each of its customers. Auditing tools and techniques are particularly important here. Look for an ASP that keeps secure logs, proper audit trails and submits itself to internal audits on a regular, at least quarterly, basis. Ask how (and how frequently) you will be able to review audit and log information. Don't be afraid to ask the ASP to allow you to review their procedures as well as their policies: these bear directly on how your security policy will be enforced.
Tip 3. Did You Design And Build Your Applications Environment With Security In Mind?
Effective security usually can't be tacked onto a system after it's complete. Successful security has to be embedded in the overall system design from the beginning. We refer to this concept as building security from the inside out.
Ask ASPs to describe their security philosophy, strategy, design and implementation. In the rush to provide the best possible online interface for their services, ASPs often put security as a secondary or even tertiary priority. While this might sometimes seem to be the right approach for startups, it inevitably leads to insecure systems, and often to unsecurable ones that need to be redesigned completely to be secure.
A corollary to poor strategy and design is the possible compromise of security soundness for technologies selected. How did the ASP choose their tools and techniques? Did the ASP select a particular brand of firewall after completing extensive due diligence on it or because it was inexpensive and had a nice GUI? Do the selected tools adhere to open standards and known systems? Or are they unknown black boxes and proprietary, and therefore not widely tested by the community? Have all cryptographic algorithms been subject to public scrutiny by competent cryptanalysts?
Tip 4. Have Your Architecture and Code Been Independently Reviewed?
Inside audits are good, but they are no substitute for third party review. Because of the tendency to try and add security on after a project is finished, look for ASPs who have taken the time not only to have an audit of their running system, but also an independent architecture review by outside experts. Ideally weíd like to see security-oriented code reviews on any applications or scripts that the ASP has written in-house too, although, due to time and resource constraints, this is something many ASPs donít do yet.
Tip 5. What Are Your Disaster Recovery And Incident Response Procedures?
Disaster recovery (DR) and incident response can be quite similar, so we like to ask about them in the same breath. Your data is at stake here, so you should seriously consider walking away from any ASP who doesn't have a good answer to this one. Specifically, for DR, you need to know how far back you can roll and how quickly the ASP can provide restores of lost or damaged data.
Incident response should be a set of clearly documented procedures that show the ASP knows how to handle everything from a minor network glitch to a major denial of service attack. There should also be clearly defined notification mechanisms to let you know that something happened and how it was handled. We also ask whether the staff handling any incidents are experienced in this area. Incident response isn't something we'd want to see handled by a junior staffer.
Tip 6. How Is My Information Safeguarded From Other Customers?
Your competitors may well be using the same ASP, perhaps even the same server at that ASP, as you are. Avoid ASPs who fail to appreciate the importance of data compartmentalization. Depending on how well the ASP's system has been designed, it may be possible to circumvent their security protections and access someone else's data. Whether this is deliberate or accidental, it can mean big losses for your company. Imagine if one of your competitors got hold of your hot prospects list, or the chemical composition of a new vaccine, a new cancer treatment, etc.
Ask the ASP what steps they've taken to secure their applications, their back- end systems, and your data from the potentially prying eyes of their other customers. You should also ask how and where they store their backups, since these too contain your data.
Tip 7. How Is My Information Safeguarded From Your Employees And Contractors?
As in any organization, ASP's employees and consultants are in the best position to compromise the security or integrity of your data. This ties in with Tip 2 since the best protection against errant staff members is a properly enforced policy, along with audit trails. You need to know who will have access to your data and how they will be controlled. Look for clear change management and administrative policies and procedures.
Tip 8. How Do You Screen Your Employees And Consultants?
Since it's likely that they'll have access to your data, we suggest asking the ASP how they screen their employees and how they choose consultants and outside firms to work on their applications and systems. Chances are this will be an area that they haven't given a lot of consideration to. And due to the tight job market many companies forego good hiring practices just to get bodies in-house. One area in which this particularly is that of relevant previous experience. It may be OK to use a junior staff member for many tasks, but when it comes to security architecture and design, there is no substitute for 5+ years of real world experience.
If theyíre hiring people without doing some background and reference checking, --and this includes verifying authenticity of resume and past work history information--donít trust your data to them. We recommend that you present the ASP with your screening criteria, along with any industry-specific criteria federal or local agencies impose on your company, and ask if they can comply.
You should request resumes not only of the staff that are managing the equipment from an operations standpoint, but also of the people that were involved in designing and building the ASP's system. At the very least, you should be satisfied that experts were involved in ensuring that the system was designed and built securely.
Tip 9. Are You Insured for Loss?
What if the worst happens and your intellectual property is lost or stolen from your ASP? To what extent are they underwritten for loss due to natural disaster, theft, malicious destruction? Who is the underwriter, and what is the underwriter's rating? Will they be able to reimburse you? And if so, have you read and understood their insurance policies to make sure that their idea of quantifiable loss matches yours? Any ASP that isn't willing to at least discuss the possibility of insurance isn't worth depending on to store and manage your company's critical data.
Tip 10. How Available Are You?
Lack of availability can mean loss of revenue and employee downtime. In fact, one of the compelling reasons to use an ASP is to make sure you can get your data when you need it, and to ease the burden of maintaining network uptime from your in-house IT staff. Although this isn't strictly a security requirement, availability issues will definitely affect the security and integrity of your data.
Ask your ASP to show you their hosting and network topology, in detail. Drill down at LAN and especially WAN levels to see whether claims of server and link diversity are truly so (too often, WAN diversity consists of 2 leased lines that terminate in the same Central office or ISP POP). If your ASP doesn't have a highly scalable and available architecture, give them the miss. That goes for their customer support team too, make sure you can get a technical person on the phone 24/7/365.
Conclusions
ASPs can bring many benefits, but along with them come a great many risks. Understanding how to define your business relationship with your ASP and how to manage the risks to your data when it is under the control of an outsider will allow you to carefully choose the situations where an ASP will add the most value.