So I recently participated in a web cast regarding the emerging GRC (Governance, Risk, and Compliance) landscape, and how we should all be aware of it as Information Security professionals.
I was hoping that the web cast might cover some of the new compliance drivers out there (such as changes in the rules of civil procedure, or the new federal information security guidelines, or maybe even possible federal breach disclosure legislation). Instead the web cast focused on some very fundamental topics (which while important are items I considered to be well established and understood parts of creating a function and comprehensive security program).
1 - You can't succeed without key executive sponsorship. If you have to spend all of your time trying to justify why you need to spend time/money on security controls or creating a policy, etc. then you may not have the appropriate level of executive sponsorship. Sr. Management must be aware of the program (which should be based on the company goals), should sponsor or charter the policy process, should approve the policies and standards, and should approve the overall budget. If you are trying to implement security without executive sponsorship - it is very unlikely you will succeed. If the company you work for doesn't recognize the value of Information Security/Risk Management and the executives do not support the program, you may need to consider plying your trade elsewhere.
2 - Compliance can't be your only driver - while compliance with various external regulations (SOX, HIPAA, PCI, etc.) are a good starting point, you can't expect that a comprehensive security program will be based only on one input.
Your organization should document all of the drivers, and the specific controls or requirements that these drivers expect, and you should create a program that addresses all of these items, and aligns to the companies business goals and risk tolerance levels.
This is the WHY of your program.
3 - Policies are important and should be where you document the WHO and part of the WHAT of your security program. You should keep the policies achievable and high level.
Get detailed in the standards or procedures, don't reference specific technologies at the policy level, or you will be revising them too frequently. Establish a policy creation and approval process up front that involves your Sr. Management and is consistent and understood, otherwise you will have people trying to work around the system or not following the process to get policies approved.
Policies can be aspirational, but if so you need to be quite clear on the approach you are taking (that the policy encourages the company to consider security at all times, and work toward the best reasonable security controls and practices for instance).
Not going to go into detail about what types of policies to write here, but at the minimum a blanket "Information Security" policy should exist which should also clearly reference how to manage any identified risks that can not be mitigated with a control.
4 - Standards are where you document the specific controls (Process or Technology controls) - for example Deploying a firewall to prevent unwanted access to the network by unapproved individuals, etc.
You should be specific about what groups, departments, roles are responsible for what aspects of the controls.
The Standards should also include a reasonable modification process, and should include details on how they should be measured and assessed.
This is more of the WHO and HOW of your program.
5 - Risk Management - this is where the assessment of the existing controls happens, and the management/escalation of the identified systemic or procedural risks that can not be mitigated by a control (and business justification for why this needs to be allowed, etc.). This is where the program helps to enable business to happen while managing and documenting the risks and helping to create a plan to address the risks. These should then be approved by Sr. Management (at the appropriate governance level) and monitored for compliance. Risk Management should also handle documenting any recommendations for policy or standard changes (based on the current risks, the changing risk profile, etc.)
Let me know your thoughts -
I was hoping that the web cast might cover some of the new compliance drivers out there (such as changes in the rules of civil procedure, or the new federal information security guidelines, or maybe even possible federal breach disclosure legislation). Instead the web cast focused on some very fundamental topics (which while important are items I considered to be well established and understood parts of creating a function and comprehensive security program).
1 - You can't succeed without key executive sponsorship. If you have to spend all of your time trying to justify why you need to spend time/money on security controls or creating a policy, etc. then you may not have the appropriate level of executive sponsorship. Sr. Management must be aware of the program (which should be based on the company goals), should sponsor or charter the policy process, should approve the policies and standards, and should approve the overall budget. If you are trying to implement security without executive sponsorship - it is very unlikely you will succeed. If the company you work for doesn't recognize the value of Information Security/Risk Management and the executives do not support the program, you may need to consider plying your trade elsewhere.
2 - Compliance can't be your only driver - while compliance with various external regulations (SOX, HIPAA, PCI, etc.) are a good starting point, you can't expect that a comprehensive security program will be based only on one input.
Your organization should document all of the drivers, and the specific controls or requirements that these drivers expect, and you should create a program that addresses all of these items, and aligns to the companies business goals and risk tolerance levels.
This is the WHY of your program.
3 - Policies are important and should be where you document the WHO and part of the WHAT of your security program. You should keep the policies achievable and high level.
Get detailed in the standards or procedures, don't reference specific technologies at the policy level, or you will be revising them too frequently. Establish a policy creation and approval process up front that involves your Sr. Management and is consistent and understood, otherwise you will have people trying to work around the system or not following the process to get policies approved.
Policies can be aspirational, but if so you need to be quite clear on the approach you are taking (that the policy encourages the company to consider security at all times, and work toward the best reasonable security controls and practices for instance).
Not going to go into detail about what types of policies to write here, but at the minimum a blanket "Information Security" policy should exist which should also clearly reference how to manage any identified risks that can not be mitigated with a control.
4 - Standards are where you document the specific controls (Process or Technology controls) - for example Deploying a firewall to prevent unwanted access to the network by unapproved individuals, etc.
You should be specific about what groups, departments, roles are responsible for what aspects of the controls.
The Standards should also include a reasonable modification process, and should include details on how they should be measured and assessed.
This is more of the WHO and HOW of your program.
5 - Risk Management - this is where the assessment of the existing controls happens, and the management/escalation of the identified systemic or procedural risks that can not be mitigated by a control (and business justification for why this needs to be allowed, etc.). This is where the program helps to enable business to happen while managing and documenting the risks and helping to create a plan to address the risks. These should then be approved by Sr. Management (at the appropriate governance level) and monitored for compliance. Risk Management should also handle documenting any recommendations for policy or standard changes (based on the current risks, the changing risk profile, etc.)
Let me know your thoughts -
Comments