By Sandy Bacik, Senior Compliance & Cyber Security Auditor, CipherTechs, Inc.
In general, policy[1] is the guidance of behavior for anyone or anything defined in scope. An information security policy architecture (ISPA) is a set of documents designed to demonstrate the business’ course of action to protect the organization’s organization’s customer’s information assets. ISPA is an interlocking set of documents that provide guidance for business information protection requirements. An ISPA is the business’s formal foundation of building blocks for their information security program, see Figure 1.
When we have missing pieces in our ISPA, we do not know the foundation for how our information assets are protected when created, accessed, stored, processed, and transmitted. We can have a mess, like a Figure 2, should something go wrong and we do not know how to respond to validate how we are doing things currently, a baseline.
From these two paragraphs, an ISPA shall guide behavior and document a baseline of configurations and activities of what an organization does to protect the information assets under their control or accountability to protect. Yes, two simple paragraphs that take on huge meaning, value, and, of course, takes time to develop, implement and maintain for an organization.
The ISPA will show your due diligence in protecting the organization’s information assets under their responsibility and accountability. You need to remember that an ISPA is not an absolute. The ISPA will grow and change based on industry regulations and business’ goals and objectives. Now a word of caution, do not write any ISPA document for the sake of writing it, because it may come back to haunt you during an audit, an incident, or during any legal proceedings.
So, what is an ISPA? While your initial implementation or your annual review can be done as a project, your ISPA is a continuous process, see Figure 3. It is the heart of charting your information protection program. An ISPA shows you have documented what you have and do, then during an assessment, you demonstrate you do what you have documented. An ISPA needs to be implemented to strengthen the foundation of the information security program. The other activities perform as part of your information security program and are built to support the ISPA.
A complete ISPA is a set of documents that are comprised of policies, standards[2], guidelines[3], standard operating procedures (run books)[4], memos and forms. An ISPA document set can be limited if you think through what you need to protect the information assets and ensure the topic you are documenting relates to a higher-level document. See Figure 4.
Before any development is done on an ISPA, the information security team needs to remember that information security is an organizational problem. In creating an effective ISPA, you need to remember a few things. First and foremost, the documents need to be written in plain and simple language. Should the organization go or be global, then translating these documents into other languages will make the translation process easier. Using plain and simple language the documents can be communicated to the staff with understanding and no misinterpretation. As you format the documents ensure the formatting is suitable for online use. And lastly and more importantly, ensure that the content is related to the business and business requirements. As an effective ISPA is developed, the following items need to be considered:
- Explain why the issue is important, why a decision needs to be made.
- Provide essential facts and supporting evidence.
- Provide clear courses of action.
- Will be effective over time.
Apply a SMART[5] (Specific, Measurable, Agreeable, Realistic, and Time-bound) principle while developing the ISPA to ensure the ISPA continues to meet the enterprise business and regulatory requirements.
Let’s get started by listing some of the basic topics, not necessarily documents that should be included in a basic ISPA. See Table 1. Topics are listed instead of document names, so an organization can design their ISPA to fit into their culture, framework, organizational documentation, and structure.
Table 1 – Sample ISPA Topics
Your ISPA should be reviewed at least annually, that is the policies, standards, guidelines, procedures, memos, and forms. Policies will be reviewed and may not need changing unless regulations or business goals and objectives change. Standards, guidelines, procedures, and forms should also be review annually and they change when process improves, technology or staff change, and regulatory requirements change.
So far, the article discusses information security assets, what about cyber security? Isn’t it the same? Generally, the two words are used synonymously, but they are similar, yet not the same. Some think that cybersecurity is a subset of information security while others think the opposite is true. Let’s set a foundation here.
Practically, there is no difference in cybersecurity and information security- or is there? Information security is the practice of preventing abuse, unauthorized access, use, disclosure, disruption, modification, inspection, recording or destruction of information during creation, at rest, during transit, and during destruction. The information or data may take any form, including electronic, physical, or oral. Now, cybersecurity is the protection of Internet-connected systems, including hardware, software, and data, from cyber attacks. The network and telecommunication paths and devices. What’s safest to use? It depends on your organization. Protecting information assets or assets, in general, is a combination of logical, administrative, and physical layers from anything that is not authorized. If you name it information security, information protection, cybersecurity, or cyber protection depends upon the verbiage and standard within the information, but stick with one throughout all types of communication. Don’t call it just “security”, because in many manufacturing and other industries where physical protection is very important, they will not even think about information needing protection. You need to decide what to call it based on your organization’s culture.
How do I get started? Remember the questions in the first paragraph? Start answering them, know your customer, internal, and regulatory requirements, and then start mapping them to topics and requirements. And finally, fit it into a document structure. To get started from scratch, what pieces do you already have in whatever format? If it’s limited think about the temporary, contractor, or intern assistance to follow people and documents, then the internal subject matter experts can tweak to really match the environment. Don’t forget to assign a document owner and know the approval process for the various levels needs to be achieved. Try to store the ISPA in a single location for easier research, linking, and maintenance. Publish what you need internally on an Intranet.
Essentially, an ISPA can be large or small depending upon the organization. All information protection guidance and behavior can be put into one long document with simple sections or paragraphs or it can be individual documents per topic. Standards could be placed into one document, but if you have a diverse environment with multiple technologies that may not work out easily. Think it through, take your time, and ensure it aligns with the business to help get the buy-in into the future. This only thing you need to remember is that it needs to be documented to show you do what you say and say what you do.
Reference: Sandy Bacik, Building an Effective Information Security Policy Architecture, CRC Press, 2008.
About the Author
Sandy Bacik, CipherTechs Senior Compliance & Cyber Security Auditor, has over 20 years’ direct information security and audit experience in the areas of IT Audit and Compliance, BCP/DR, Incident Response, Physical security, Privacy, Regulatory Compliance and Audit, Policies/Procedures, Operations, and Management. With an additional 15 years in Information Technology Operations. She has managed, architected and implemented information assurance, privacy, and audit programs in a variety of verticals. She has performed and managed engagements for information privacy, data classification and retention in international environments. Ms. Bacik is the author of Building an Effective Security Policy Architecture (2008) and a contributing author to the Information Security Management Handbook (2009, 2010, 2011, 2012, 2013) and a member of the SecureWorldExpo Advisory Council. Sandy can be reached online at our company website www.ciphertechs.com
[1] A policy is a high-level statement for goals, behaviors, and consequences. Do not forget about the consequences because if you have one that violates the policy without a consequence, how do you know or why would you want to even know whether or not someone violated it. Policies are technology neutral.
[2] A standard set of rules and procedures that are required.
[3] An outline for a statement of conduct. This is a guide as to how something or something should perform, such as acceptable use of the Internet.
[4] Or whatever the term is within your organization are documented step by step instructions to get to a goal.
[5] A mnemonic/acronym, giving criteria to guide in the setting of objectives within documents.
