Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk //

Compliance

4/23/2012
07:37 PM
50%
50%

Compliance Policy Development Do's And Don'ts

Policies are the keystone to good GRC, but many organizations don't write them well

Compliance fatigue can afflict just about any enterprise facing the growing list of regulatory requirements placing pressuring on their security practices. Sometimes it may seem that there is just not enough money or time to keep up. But governance, risk, and compliance (GRC) experts believe that the key to bringing things into equilibrium is a solid foundation set by unified policies that can guide security standards and procedures to both minimize risk and comply with regulations now and in the future.

Unfortunately, many organizations fail to do a good job establishing effective policies. Dark Reading recently talked to some experts in the industry, who offered helpful tips on what organizations should and shouldn't be doing when developing their security and compliance policies.

Don't Get Bogged Down In Individual Regulations
"Organizations today have numerous government and industry-specific regulations that they need to be mindful of," says Andres Kohn, vice president of technology at Proofpoint. "The evolving regulatory environment becomes even more complicated due to multiregulation and cross-border regulations."

Not to mention that Gartner's predicting that by 2014, 70 percent of IT risk and security officers in Global 2000 organizations will be required to report annually to the board of directors on the state of security, Kohn says. He believes that with so many individual requirements, it can be easy to get mired in the details.

"Don't be bogged down by specific regulations," he says, warning that creating policies off-the-cuff to fit specific regulatory mandates can lead to trouble. It makes more sense to develop a policy framework that can be managed and adjusted as required by all risk considerations — including new mandates.

Do Let Risk Lead Policy Decisions
No matter what industry you're in, Rick Doten, vice president of cybersecurity for DMI, says it is important to always remember security's No. 1 motivator: Cybersecurity is all about managing risk. So let risk considerations lead policy decisions and then map compliance reporting to that, not vice versa.

"For instance, regulatory compliance is considered one of the primary business risks for industries such as the energy utilities. The National Energy Regulatory Commission (NERC) can fine a company up to $1 million a day for noncompliance," Doten says. "Others, such as the large financial institutions, have dozens of regulations they need to follow. They focus on building a security program where controls are appropriate to protect the business, and consider regulatory compliance as merely a reporting exercise to show how their controls map to meet the regulatory criteria."

According to Jeff Schmidt, global head of business continuity, security, and governance for BT Global Services, good policies start with an understanding of one's risk appetite.

"By having a risk appetite defined, you then know and can manage to the risk posture of the business. This creates a foundation for the business metrics of what 'good' looks like for your organization as it relates to security," Schmidt says. "It allows the chief information security officer to report in a meaningful way without jargon and without needing to leverage Fear, Uncertainty, and Doubt [FUD]."

Don't Confuse Policies With Standards Or Procedures
Do you know the difference between a policy, a standard, and a procedure? No? Join the club, says Jeff VanSickel, practice leader for compliance at SystemsExperts.

"This is probably the No. 1 issue in the development of an information security program," VanSickel says. "Simply put, a policy is management's definitive position on a specific issue to ensure consistency. A standard is a specific measurable requirement that governs an operation, configuration, or process in order to satisfy a policy. A procedure is a set of step-by-step instructions required to satisfy a given standard."

Understanding how each feeds into the other will enable your organization to perform better according to directives in each, and it will make it easier to bring clarity to policies.

"Policies are not about technology; they are about defining the objectives of the organization through the description of requirements," says Dave Frymier, vice president and CISO for Unisys.

As he puts it, policies should sit at the top of pyramid of documents that consist not only of standards and procedures, but also end-user guidelines.

"In this manner, security policy can remain constant even if, for example, an organization changes its router vendor," Frymier says. "Only the standards and procedural documents would change, and there may be minor or no changes required for the end-user guidelines."

Do Your Framework Homework
Compliance frameworks are one of the most reliable tools for fleshing out a unified set of policies, even if it takes a considerable amount of tweaking to suit specific needs of your business.

"Read the basic framework documents from organizations that provide security policy guidance, and then use their major headings as a checklist to tailor a policy for your own situation," Frymier says, suggesting usual suspects such as COBIT and NIST-800. "You’ll find that 90 percent of these frameworks cover the same ground, and the remaining 10 percent is industry-specific. You'll get a great start to your policy by covering that 90 percent."

Don't Maroon Policies On IT Island
Are your policies taking just IT risks into account? Don't get trapped in such myopic thinking, Doten warns.

"Have your policy set at the right level, not just corporate audit or CSO level," Doten says. "Regulatory compliance is part of a larger set of business risks and should be prioritized as such."

According to Frank Villavicencio, executive vice president for Identropy, policies need to align with the strategic direction the organization wants to follow.

"But at the same, make sure they are attainable," Villavicencio says, warning that if procedures will need to change drastically to support a policy shift, then IT needs to gain buy-in from stakeholders on the front-end. "If a new policy requires a significant change in how things are done, you're more likely to get the buy-in you need from any stakeholders before the policy goes into effect. Reaching out to others involved in any procedural change will also open up lines of communication if there are problems or kinks that need to be worked out after the policy is instated."

Do Make Policy Statements Auditable
Policy statements should not only be designed to help mitigate risk, they should also be created with auditability in mind.

"It is very important to ensure that documented security policy and standard statements are auditable, producing evidence to show that controls are operating effectively," VanSickel says. "Since many policies and standards are driven by legal or regulatory requirements, this evidence is useful toward demonstrating compliance whenever the company is audited on those controls."

Once developed, organizations can fine-tune policies and procedures based on frequent audit results, says Michael Hamelin, chief security architect for Tufin.

"When it comes to systems or network management, audit, audit, and then audit again. That way you have the context needed to develop the best policy or set of policies best suited for both operations and compliance," Hamelin says. "The goal should be to maintain compliance, not check the box -- that kind of thinking can potentially land your company with a fine, and perpetuates the reactive culture security pros are working so hard to move away from."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
anon7576865696
50%
50%
anon7576865696,
User Rank: Apprentice
10/22/2013 | 10:10:24 PM
re: Compliance Policy Development Do's And Don'ts
A very well written article with some great pointers on do's and don't of policy and procedure creation.

Some related reading for those interested.

http://www.convergepoint.com/s...

http://www.convergepoint.com/s...
BKIM640
50%
50%
BKIM640,
User Rank: Apprentice
4/24/2012 | 3:48:40 PM
re: Compliance Policy Development Do's And Don'ts
NERC is-North American Electric Reliability Corporation, not National Energy Regulatory Commission.
Tor Weaponized to Steal Bitcoin
Dark Reading Staff 10/18/2019
Data Privacy Protections for the Most Vulnerable -- Children
Dimitri Sirota, Founder & CEO of BigID,  10/17/2019
State of SMB Insecurity by the Numbers
Ericka Chickowski, Contributing Writer,  10/17/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-9501
PUBLISHED: 2019-10-22
The Artificial Intelligence theme before 1.2.4 for WordPress has XSS because Genericons HTML files are unnecessarily placed under the web root.
CVE-2019-16971
PUBLISHED: 2019-10-22
In FusionPBX up to 4.5.7, the file app\messages\messages_thread.php uses an unsanitized "contact_uuid" variable coming from the URL, which is reflected on 3 occasions in HTML, leading to XSS.
CVE-2019-16972
PUBLISHED: 2019-10-22
In FusionPBX up to 4.5.7, the file app\contacts\contact_addresses.php uses an unsanitized "id" variable coming from the URL, which is reflected in HTML, leading to XSS.
CVE-2019-16973
PUBLISHED: 2019-10-22
In FusionPBX up to 4.5.7, the file app\contacts\contact_edit.php uses an unsanitized "query_string" variable coming from the URL, which is reflected in HTML, leading to XSS.
CVE-2015-9496
PUBLISHED: 2019-10-22
The freshmail-newsletter plugin before 1.6 for WordPress has shortcode.php SQL Injection via the 'FM_form id=' substring.