Defining a security policy for a system_问答_开发者

Most of the literature on security talks about the importance of defining a security policy before starting to workout on the mechanisms and implementation. While this seems logical, it is quite unclear as to what defining a security policy really means.

Has anyone here had any experience in defining a security policy, and if so:

1) What is the outcome of such a definition? Is the form of such a policy, for say distributed system, a document containing a series of statements on the security requirements (what is allowed and what is not) of the system?

2) Can the policy take the a machine readable form (if that makes sense) and if so how can it be used?

3) How does one maintain such a policy? Is policy maintained as documentation (as with all the rest of the documentation) on the system?

4) Is is necessary to make references to the policy documen开发者_JS百科t in code?

Brian

You should take one of the standard security policies and work from there. The one that is most common is PCI compliance (Payment Card Industry). It's very well thought out and except for a few soft spots, generally good. I've never heard of a machine readable policy except for a Microsoft Active Directory definition or a series of Linux iptables rules.

https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

EDIT:

Check out SE Linux policies also:

http://en.wikipedia.org/wiki/Security-Enhanced_Linux

The Open Web Application Security Project OWASP is a language-agnostic project to educate about security and provide tools to test and support software. While it is web-centric, many of the core ideas are widely applicable. The website is geared towards both software engineers as well as management.

When people talk about "security policy", they might be referring to two different types of security policy.

One of them are high level ones, usually defined by managements. This security policy's primary readers are human. It is a document defining the goal, context, expectations, and requirements of security in the management's mind. Languages used inside this policy could be vague, but it's the elementary "law" of security in the applying context. Everyone involved should follow such policy.

1) The outcome of such policy is the clearly defined security requirements from the management. With this polices, everyone involved can understand the management's expectation and make security-related judgment accordingly when necessary.

2) As the primary readers of such security policies are human, and the statements are usually very general, it may not be in machine readable form. However, there may be a couple of documents defined base on the policy, namely security guidelines, procedures, and manuals. They are in the order of increasing level of details on how security should actually be implemented. For example, the requirements defined in the security policy may be realized into hardening manuals for different OS, so that the Administrators and Engineers can perform hardening tasks efficiently without spending too much time interpretation the management's thoughts. The hardening manuals may then be turned into a set of machine readable configurations (e.g. min password length, max failure login count before locking the account, etc) automating the hardening tasks.

3) The document should be made accessible to everyone involved, and regularly reviewed by management.

4) Practically it might be hard to make such references. Security policies might be updated from time to time, and you will probably not want to recompile your program if the policy changes just affect some parameters. However, it's nice to reference the policy in development documents like design sepc.

Another type of "security policies" might just refer to those sets of parameters intake be security programs. I found that some security programs really like to use the word "policy" to make their configurations more organized and structures. But anyway, these "security policies" are really just values and/or instructions for security programs to follow. For example, Windows has its own set of "security policies" for user to configure audit loggings, user rights and etc. This type of "security policies" (parameters for programs) is actually defined based on the 1st type of "security policies" (requirements from management) as mentioned above.

I might be writing too much on this. Hope it helps.

If you have to design a security policy, why not think about users and permissions?

So, let's say you have an API to something. Consider some arrangement of users that divides them in what they want to do and what minimum permissions they need to do it. So if someone only has to read documents from a database, the API itself won't let the user do something else.

Imagine this is a web JSON API. The user clicks a button and JS processes a request, and sends it. Normally it works fine, but if someone tampers the request, the server simply returns some error code because it is whitelisting just a few actions the user can do.

So I think it all boils down to users and permissions.