Perhaps you remember the public service campaign from 1960’s television that went something like, “It’s 10 p.m. Do you know where your children are?” For IT, we could rephrase it as: “It’s 2009. Do you know where your data is?” You probably don’t, especially if it’s in the hands of your partners or outsourcers. So, the answer to the question in the title of this Advisor is most likely, “I don’t know.”
As business has become more distributed, enterprise ecosystems have expanded, and more and more functions have been outsourced, we are increasingly relying on partners to manage the integrity and privacy of our data. So, how do we know if they are?
One approach is to require your partners, outsourcers, ASPs, SaaS providers, and so on, to demonstrate appropriate security measures to mitigate the risks associated with your information requirements. You need to know that they have thought about and devoted resources to the issues of security; have sufficient policies, procedures, and governance in place; and that you can work with them in the event of a security incident. An objective, industry standard can be of great assistance in making this determination and codifying it into contracts.
Maturity in information security is achieved by implementing a set of controls, including policies, processes, procedures, applications, and technology. A mature organization will have processes to establish, implement, monitor, and revise these controls to ensure that the specific security requirements of your enterprise information are met. ISO 27002 (aka ISO/IEC 17799:2005) “Information Technology – Security Techniques – Code of Practice for Information Security Management” establishes guidelines and general principles for information security in terms of 39 specific control objectives and more than 100 specific controls covering the following areas:
- Security policy
- Organization of information security
- Asset management
- Human resources security
- Physical and environmental security
- Communications and operations management
- Access control
- Information systems acquisition, development, and maintenance
- Information security incident management
- Business continuity management
- Compliance
Of course, you need to determine how important each of these areas is to you. I like to think of this in terms of four different security perspectives:
- Infrastructure/network – The hardware and software (e.g., firewalls, management, monitoring) in place to protect systems, services, databases, networks, etc., and control, detect, and report on incidents.
- Architecture – The extent to which security is addressed by architecture, including an explicit security architecture, and inclusion of security aspects in other architectural domains (business, information, application, technology). Security architecture should address issues such as policies, entitlement, trusted domains, authentication, encryption, auditing, and so on.
- Applications – The security characteristics of the applications that your partners develop and use. This should include secure development practices such as coding standards, reviews, frameworks, and knowledge of security issues such as buffer overflows, SQL insertion, and so on. Again, an independent source such as SANS Institute, Microsoft, or other published coding best practices can be useful in setting these requirements.
- Policies, procedures, and governance – The processes in place to ensure that the security architecture is adhered to.
You should expect your partners to be open about their security practices. They should not have to share proprietary details with you or anything that compromises their security implementation, but they must be able to demonstrate maturity in the areas defined above to a level sufficient to meet your security requirements. Most of the mature organizations I have seen are ready to demonstrate their conformance to standard best practices. If they are not willing to do so, you might evaluate why this is, and seriously consider another partner.
Economic imperatives will continue to extend the enterprise and outsource noncore operations. Your security architects shouldn’t try and stop it, or lose sleep over it. Instead, assess your particular risks, establish the security controls required to mitigate those risks, and take a “show me” and contractual approach to ensure that your partners are carrying out those controls.
I welcome your comments on this Advisor and encourage you to send your insights on enterprise architecture to me at mrosen@cutter.com.