Niki Kovacs contact@kikinovak.net wrote:

...

I wonder where to begin. <<

Policy. It's a drag, writing policies, but without policies, you're in the "Ready! Fire! Aim!" school of security. The top tier of policy is the "Enterprise Security Policy", which establishes the security function, roles, responsibilities, budget, etc. It also gives the power to enforce penalties for breaches of policies. At the next tier, you have system- and issue-specific policies, such as the "Use of corporate email" policy, the "Inappropriate content in the workplace" policy. You may then move down to standards (platforms, SOE, etc.) and procedures (e.g. for provisioning user accounts, resetting passwords, etc.).

Everything then flows from a Threats and Risk Assessment. Identify the information assets of the enterprise, value them. Then identify the possible threats, essentially giving them a likelihood of occurring. This is then plugged into a risk matrix: high value asset with almost certain likelihood of compromise = extreme risk; insignificant value asset with rare likelihood of compromise = low risk. Obviously, you focus on the high risk stuff first.

You then put in place controls to mitigate the risk. For some things, you can't mitigate (e.g. data centre hit by asteroid and now a smoking hole in the ground); those you push over into Disaster Recovery Planning and deal with through relocation, equipment replacement, off-site backups, etc.

Your controls could be technical (firewalls, proxies, authentication and authorization/access control, etc.), physical (locked doors, fences, alarms) and administrative (policies/procedures/standards, pre-employment screening, job rotation, segregation of duties, etc.). ISO 27001/27002 are a good guide in this area, or if you're US Gummint, check out the NIST SP800-series publications.

...

I would say first thing is get a series of "auditing" tools such as, for example, the port scanner nmap, to test the firewall on the server. Any other ideas for that? <<

Actually, tools like nmap, Nessus, etc. come in quite late in the day, for assurance that things are configured correctly. You can usually get much better bang from the buck from an internal audit first (it's amazing how often things are documented as being one way, when actually they're configured a completely different way).

...

Maybe some good reads on security? That is, articles that don't require you to be a doctor in computer science to get a grasp of the subject? <<

If you want a rapid overview of Linux security, I recommend the book "Real World Linux Security" by Bob Toxen. If you want a rapid overview of the business aspects of security, I'd recommend you investigate Security+, which is an entry-level security certification - a course or even just a study guide would help you. I'll let others comment on SELinux - I've worked with it, but my experience is definitely atypical.

A closing quote, which I think comes from the old edition of the "Official (ISC)² Guide to the CISSP CBK", but is probably the key point:

"Technical specialists are not the right people to decide how the organization approaches security and what security measures should be implemented. Companies which deal with security at the administrator level do not view security in broad enough terms. Senior management is not sufficiently involved and aware, proper risk management is not performed, security is under-funded and there is no planning and procedures to deal with unanticipated events."

In other words, your top priority in security should be to obtain senior management backing. Without that, you'll just be spinning your wheels. And always remember: you can secure the technology fairly easily - it's the *people* that are the weakest link.

Best,

--- Les Bell, RHCE, CISSP [http://www.lesbell.com.au] Tel: +61 2 9451 1144 FreeWorldDialup: 800909