Quote:
Originally Posted by samengr
I need to formalise the security procedures for the linux servers. I want to make a policy document so that if i can apply this policy to the new servers.
|
Maybe a minorr nit but there's a difference between policies and procedures. Policies are plans or sets of rules (requiring adherence and penalising offences) to reach a goal. Like
"It's kinda time we sorta work on this HIPAA / SOX / Basel II thing." Procedures (SOP's) are sets of specific steps to perform tasks (with regard to standards, quality, efficiency). Like
"Do x, y and *then* Z or this application will b0rk."
Wrt hierarchy see who owns (pays for) the servers and services (home, workplace, colocation), if there's any policies and SLA's in place and such. For instance if there are seven servers located in two data centres that together are "the application" the data centre has to adhere to the network policy of the fat pipe supplier. One level up you are bound by contract to what the data centre sets as policies. On top of that your customers have to adhere to what you set as policies. What I'm saying is that wrt boundaries in policies you don't have to supply what was already defined by the colo provider and in procedures you don't have to supply what is in your SLA with that provider.
Such an assessment is also good to uncover problems. Like if you have an SLA with your colo people but they won't handle incidents the way you want it. Then it's your chance to set an incident handling policy and the accompanying handling and recovery procedures. Or if you're for example a reseller. You'll have lots of newbie customers that play with deprecated software which threathens your servers, other servers (spam, bots, probes) and your company image. You want to make your AUP point out that it's unacceptable, then you follow that up with a formal policy and procedures on how to check and what to do. If you got that you can also make them pay (money, I mean) for added value services since you can guarantee "better" integrity, data safety and stability (to some extent). OTOH things change if these boxen are part of a company or institution network. They should already have policies in place depending on what they have to adhere to so you can focus on specific server and application policies and procedures embedded within those existing policies.
Wrt formalising there's lotsa std docs on the 'net but it is *a lot*. If you really want to make formal policies you should invest time and read
this OR
this OR
this.
Quote:
Originally Posted by samengr
1. Outline documentation
I have a few headlines that can be added to the document, feel free to add, edit and delete as you see fit.
a) Account Management
i) Password policy
b) Services
c) Patching / Updating
d) Kernel Updates
e) Log monitoring / management
f) Intrusion Detection Systems
|
Some phrases to think about
: generic server and network AUP, account management, application testing, application testing, maintenance and rollout, user-requested custom configuration testing, backup and rollback procedures, performance monitoring, redundancy or spare activation, server maintenance, incident handling and risk management.
Having read all this maybe step back a bit and think about your day to day work with those servers and the logged incidents (you do keep admin logs, right?) and how you would want to formulate a simple goal for that. That's all it needs to start off with as
all journeys start with a first step.
