Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Level of detail for Info Security Policy - Internet Security | DShield SANS ISC InfoSec Forums

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Level of detail for Info Security Policy
I'm a techwriter on an assignment developing an IT Security Policy framework for a small to medium company in logistics and storage.

One thing I'm not clear on in respect of Information Security Policy (ISP) is the level of detail required in describing the details of the company network. Should the Security Policy provide specifics of server names, encryption types, network topography, and so on? I have plenty of examples and templates of what should be in an ISP but it's not clear to me how much of this detail would normally be expected.

Any tips or pointers appreciated.

7 Posts
I would say that it depends on the target audience. You can have multiple documents, each with a different level of details. Then apply classification on documents to restrict access to the authorized people only. Xme

478 Posts
ISC Handler
Check if the SANS Policy Templates help:…

But overall,the policy shouldn't so much about describing the details of the network, but more about the rules used to build (and later extend) the network. So there should be policies that mandate certain encryption algorithms based on the data handled by a system, or there should be a policy to use firewalls to segment information of different classification, and hopefully that matches what you find in the network, but a network diagram is not a policy.

3631 Posts
ISC Handler
It's great to see a tech writer asking this question. So often I see pages upon pages of InfoSec Policies that contain detail that is to granular. In my opinion, these policy documents should contain policy statements that are clear an concise and void of references to specific hosts, topologies, networks, technology or standards. One goal of any policy document should be that the content does not need to change that often, granted there should be a policy statement that requires at least annual review of the document. Referencing specifics should be reserved for supporting 'Standards' or 'Procedural' documents that the policy doc could reference if needed. The audience for the InfoSec Policy should not be required to be technical or to be proficient in security. That being said, the best policies set reasonable expectations of the audience and are enforceable.

Just my two-cents.

1 Posts
Thanks! That's all great advice. I have been using the SANS policy templates, that is what lead me to the forum. I've also mentioned the SANS training classes to them.

I know the network documentation is not policy per se but the external consultancy that was brought in to do the initial InfoSec advice, which I am working from, expects detailed network documentation to be done. But it hasn't been, or at any rate, it's sketchy and incomplete. There are some topics like the Incident Response methodology which are pretty generic, but some of the network management info is very specific. So I think what I'm picking up is that they're a bit behind on their procedural and infrastructure documentation to which the policy docs ought to refer. So we are doing some whiteboarding sessions this week where hopefully there is some action on those points which will make my part of the job easier.

7 Posts
Think of the layers like the levels of law. Policy is the Constitution (but hopefully more clearly stated). It should be at a high level, and withstand change over time without needing frequent revision or correction. It should change when the overall organization itself changes.

Standards are the next step down - more flexible, but still able to support and enact policy over an extended period of time. Practices sit at this level as well (though differing definitions of the term 'practices' may cause it to interchange with 'procedures').

Procedures and specifications are the day-to-day, rubber-meets-the-road implementation of policy and standards (though see the terminology note above). They change to reflect what can be obtained from vendors, what is necessary to be consistent with policy in the real world.

In the end, the most important thing of all is to be clear about how the organization understands these terms - and to educate them on the way the terms are used in things like ISO, COBIT, ITIL, FFIEC, and all the rest of the alphabet soup.

8 Posts
Quoting Xme:I would say that it depends on the target audience. You can have multiple documents, each with a different level of details. Then apply classification on documents to restrict access to the authorized people only.

Yes, you are right I think. But one thing target audience and documents changes according to the users and situation.

12 Posts
Generally the 'target audience' are ultimately going to be those who assess bids and tender proposals. So they want to see policies that conform to the standards, in other words, the various controls that 'agencies must obey' and/or 'should obey'. It's not that hard in principle but it in practice, a lot of input and co-operation is required from network and system administrators to make sure that the policy really does mesh with the procedures. Circadian

7 Posts

Sign Up for Free or Log In to start participating in the conversation!