Select Page

Introduction

This is the second post in our series on Information Security Management. In the first post of the series we discussed the importance of having upper level support for your information security program. In this post we will discuss the actual structure of your information security program and how establishing a logical structure in the very beginning of the program will help you succeed.

program hierarchy

Build your Program around a Policy

The heart of the information security program is a document known as the Information Security Policy. Many people are confused about the relationship between policies, standards, and procedures so it may be helpful to outline those here.

  • Policy - Top level governance document, rarely changes, is very broad and general.
    • Standards - More specific guidance on portions of the program, i.e. Asset Management. Each standard can be a standalone document or integrated into the overall policy document.  It’s sometimes easier for them to be standalone documents for version control and compliance review.
      • Procedures - Highly specific step by step instructions on performing the actions needed to comply with the policy and standards. Multiple procedures will likely apply to each standard. Procedures can be standalone or integrated into the standard, however it’s easier for them to be standalone for the reasons stated above.

The policy is the core of the information security program. At its very beginning, the policy contains a purpose or mission statement that defines the reason that the information security program exists.  Here is a sample purpose statement:

“Implicit Deny takes the security of its sensitive data and information systems very seriously.  Implicit Deny strives to comply with all applicable laws and regulations regarding information security, and will maintain this information security program for the protection of its sensitive business, financial, and user data.”

Support your Policy with Standards

What comes after the purpose statement of the information security policy can vary depending on the needs of your specific business, but the following topics should be included in some form no matter what kind of an organization you are:

  • Policy Management (annual updates and updates upon significant change, revision history)
  • Risk Management (annual risk assessment and risk assessment upon significant change, risk classification, risk treatment)
  • Asset Management (asset classification, asset inventorying, asset ownership)
  • Data Management (data classification, data ownership, data inventorying)
  • Roles and responsibilities (who does what, RACI, reporting structure)
  • Access management (identity, onboarding, role change, termination, user accounts)
  • Vendor management (risk assessment, due diligence, contracting, service monitoring)
  • Systems management (configuration, deployment, maintenance, retirement)
  • Network management (segmentation, perimeter, detection, prevention)
  • Business continuity and disaster recovery (disaster preparedness, recovery plans, alternate sites, plan testing)
  • Vulnerability management (vulnerability scanning, automated patching)
  • Incident response (logging, monitoring, detection, hunt teaming)
  • Physical and environmental security (access control, environmental control, monitoring)
  • Change management (change process, documentation, approval, change review)
  • Compliance (control design, reporting, review)
  • Internal audit (sampling, testing, interview, documentation)
  • Security awareness training (presentations, publications, testing)

Covering these high level topics in your policy ensures that your program at least considers them regardless of what action you decide to take on them, and it looks great to auditors and regulators as well.

Assign Ownership for All Program Elements

Each policy, standard or procedure document should be assigned an owner. This owner is ideally an individual within your organization, but can also be a group of individuals. This assigned owner is the one that is responsible for maintaining the version control of the document, responsible for reviewing its content at least annually (or more often if something changes in the organization that pertains to the document), and is responsible for ensuring that the content of the document is aligned with the overall information security policy and program.

Create your program around a framework

Depending on what industry/business you are engaged in, you will have several pre-built frameworks to leverage to create your program around.  For example, in Banking there are the GLBA and FFIEC regulations: http://ithandbook.ffiec.gov/

For Healthcare, there is HIPAA: http://www.hhs.gov/hipaa/for-professionals/privacy/

For Government, there is FISMA and NIST: http://csrc.nist.gov/groups/SMA/fisma/

And for businesses related to payment cards, PCI: https://www.pcisecuritystandards.org/

Regardless of your business, there are several generic frameworks that can mostly or entirely apply to you:

ISO 27000 is a series of standards published by the International Standards Organization regarding information security management and controls. http://www.iso.org/iso/iso27001

COBIT is a framework published by ISACA that focuses specifically on the governance of enterprise IT (GEIT). http://www.isaca.org/cobit/pages/default.aspx

The CIS (Center for Internet Security) Controls for Effective Cyber Defense is an excellent framework that is focused on breach prevention (the Australian government organization that sponsored it estimated that 85% or more of previously occurring breaches could have been prevented by implementing this controls framework. https://www.cisecurity.org/critical-controls.cfm

Conclusion

An information security program is a complex and intricate construction.  If you don’t lay out a clear framework from the beginning it will quickly become unwieldy and difficult to manage.  By setting clear policy objectives, standards, and rock solid procedures, you ensure that you will be able to comply with regulatory requirements, industry specific frameworks, and create an effective and enduring secure environment.

hatelaugh

hatelaugh

I am a veteran of the IT/InfoSec industry. I've been a technician, sysadmin, pentester, consultant, auditor, engineer, and I currently do InfoSec risk management.
hatelaugh