Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Security-Management
[Top] [All Lists]

Re: How to organize a lot of policies?

Subject: Re: How to organize a lot of policies?
Date: Sun, 15 Jan 2006 14:08:30 -0500
In our experience, the ideal world and the real world are drastically 
different places. While I agree that SOX should not have caused major 
policy changes, the fact is that many companies had absolutely no policies 
and were suddenly scrambling to write them. Many companies that had 
policies are still tweaking them based on regulatory requirements and the 
adoption of "best practices" standards, which are also evolving.

A policy is very much a living document. While the high-level statements 
will remain fairly static, the more detailed sections of controls, or 
rules, and procedures will change as the business objectives change and/or 
new infosec threats/technologies emerge. Their applicability can also vary 
depending on user classification, job title, etc, which can pose 
additional challenges without an extremely organized, role-based approach. 
An electronic sign-off should suffice for incremental policy changes as 
they occur.

Awareness is by far the weakest link, and it's usually the result of a 
disconnect between executive management, HR and IT. This responsibility is 
often delegated to technical staff who have very little patience, 
experience or interest in writing policies or training anyone. There has 
to be a concerted effort across the organization to make people understand 
the policy, not just read it. The only way to measure that is through 
ongoing feedback via some sort of testing program. Random sets of 
questions based on specific policies should help to avoid "parroting".

Like anything else, automating and integrating this entire process is the 
key to minimizing time, effort and cost while maximizing effectiveness.


- Rich

 



Fred Cohen <fred.cohen@all.net> 
01/15/2006 09:48 AM

To
Devdas Bhagat <devdas@dvb.homelinux.org>
cc
security-management@securityfocus.com
Subject
Re: How to organize a lot of policies?






As a general rule, policies should change rarely and anyone subjected 
to them should have to read, understand, and agree to them. However, 
often companies create and change policies at a rapid rate, don't 
bother to promulgate them, and don't follow them. Thee are, in my 
view, two reasons companies do this and they are both readily solvable.

- Reason 1: They don't understand what policies vs. control standards 
are or should be
- Reason 2: They don't have very good security training and awareness 
programs and HR tracking in place

The first issue relates to the notion that policy is something 
approved by the board of directors and CEO, that it should impact all 
workers or at least a very large portion of workers, and that it 
should rarely change - certainly no more often than every few years 
for any given policy and often not for decades. Policies should, 
however, point to "control standards" or other similarly named 
documents that cover more specific issues and that change more often, 
usually deal with smaller populations, and are oriented toward more 
timely requirements. For example, when SOX came to be, it should not 
have required any policy changes since a well defined risk management 
governance policy should have been in place and there should already 
have been a policy indicating that laws and regulations should be 
followed. The control standards for risk management might have 
changed significantly to adopt COSO over a prior overall process, but 
this affects far fewer people and likely changes fairly often - on 
the order of every year or two. Some level of governance (policy) 
changes may have occurred if lower level individuals were in charge 
of some aspects now clearly associated with the CFO or CEO, however, 
this typically represents a change that should have happened long ago.

The second issue deals with the fact that people who don't know and 
understand what the policies are can hardly be expected to follow 
them, and as a result, these policies are not really policies at all, 
they are really only liabilities to the enterprise - legal status 
exists for policies that allows the company to be sued for not 
following them - but the benefits of actually doing what the policies 
say are not gained. All policies should be clearly understood by all 
workers subject to those policies. This means that the training and 
awareness program has to not only assure that they are properly 
briefed when they start working there, but also that they are kept up 
to date on changes and that the policies are reiterated in an ongoing 
fashion about every 6 months to a year. Demonstration of the 
"understood" part requires that some sort of feedback from the 
awareness program be used to measure the understanding - usually 
against situational scenarios.

At least that's my view.

FC

On Jan 13, 2006, at 8:42 AM, Devdas Bhagat wrote:

On 10/01/06 12:41 +0530, Lalit Gupta wrote:
Hi,

As such there is no need of asking User's to sign individual 
policies.
Also, if you modify certain policy tomorrow, would you be again 
going to
each individual user and get it signed again?

Why not? If it gets too painful for you to do this, don't change
policies that often.

My dear friend, according to me, best is ask them to sign a document
which clearly states that "I would abide by and follow all
organizational policies". May be you would like to add the 
location of
policies also. This would suffice the job. Later on, if you would 
have
to modify the policies, you can do that easily.

And if the organisational policies change tomorrow, as an end user,
I want to know. Some policies may not be acceptable to me, and I sure
would like to be able to add my comments on those (and optionally 
quit).

Far more importantly, if policies change and I am _not_ informed, I 
can
very well violate an acceptable policy unknowingly.

Organization of policies would be easy, if you create a master policy
document and add all policies as appendix to that. You can get this
master policy itself signed by your user.

This is a good idea.

For the purpose of your Users to READ your policies, introduce 
some kind
of Objective Test based on your policies and make it mandatory to 
pass
in that test to get through the CONFIRMATION PROCESS in your
organization.

Bleh. Not necessarily a good idea. You end up with parrots.

Regards,

Lalit Gupta, Specialist-Information Security

(: 5219



Great LGSI Great Security

-----Original Message-----
From: Neksus [mailto:neksus@gmail.com]
Sent: Tuesday, January 10, 2006 2:35 AM
To: security-management@securityfocus.com
Subject: How to organize a lot of policies?

Hello,

I am currently working on rewriting / re-working security policies 
and
there are a *lot* of policies. I'm thinking it's probably not a good
idea to have users sign them all (especialy if they don't apply to
them). What I would like to do is structure them in an easy to
organize/update scheme.

I have a couple of strategies in mind and would appreciate some 
input.

1. Have a mother-security policiy which will basically say "be nice",
then point to other specific policies (email use, VPN use,
developper's code of conduit, etc.) for more specific details. This
approach is really a "company wide" approach where 1 signature means
the user agrees to all the policies in place. It's easy but there is
no or very low customization possible.


I would go this way. A small, single policy document which works for
everything. Then additional small documents for specific purposes if
needed. Ideally, you should not need much more.
"I will not divulge information proprietary to the company." is a good
clause.

This make policies more general, smaller and more effective.

2. Have a fair usage policies that is wider than the one above and 
ask
the user's supervisor to make sure the users signs the right ones. I
guess this could be seen as a role-based. If a user is a developper,
he would have to sign X number of policies that would apply to him. I
think this is hard to track.

One of the major goal is to be able to have specific
policies/standards/procedures that are easily understandable by the
common user and not just a "sign here" type of document. By focusing
on the role of the user, I hope he/she will take the time to read 
what
applies to himself.

Smaller documents are more likely to be read. Avoid legal language,
avoid documents in ALL CAPS, give real reasons for policies and you 
will
find happier users who will actually be willing to follow policies.

Devdas Bhagat


-- This communication is confidential to the parties it is intended 
to serve --
Security Posture            securityposture.com          tel/fax
University of New Haven               unhca.com        925-454-0171
Fred Cohen & Associates                 all.net      572 Leona Drive
ASP Press                        asp-presss.com    Livermore, CA 94550




<Prev in Thread] Current Thread [Next in Thread>