[Nine principles of security architecture]

[Nine principles of security architecture] - Computers

Search Tech-Forums - link takes you to our Forum's search page.

Note: The following is only a text archive!

To view the actual forum discussion, please visit our website at http://www.tech-forums.net

Pages:1

Nine principles of security architecture
(Click here to view the original thread with full colors/images)

Posted by: office politics

[url=http://software.newsforge.com/software/05/11/14/2115222.shtml]Nine principles of security architecture[/url] by bruce byfield

The truth is, anti-virus software, firewalls, and intrusion detection are only the surface of security. They are all reactive measures that attempt to respond to active threats, rather than proactive measures that anticipate threats and try to make them harmless. These applications have a major role to play, but are not enough in themselves.

Behind reactive security measures is the much broader field of architectural security: How to set up a secure system to prevent security breaches, how to minimize breaches if they occur, and how react to an intrusion and recover from it if it happens.

Posted by: office politics

[url]http://adminfoo.net/node/441[/url]

Harlan Carvey runs his own highly informative website and blog, not to mention having written a book called Windows Forensics and Incident Recovery. So we were honored to find his great response to (and clarification of) our earlier article on the Nine Principles of Security Architecture. So great, we had to lift it up to the front page. Here it is, with minor format changes (bullets & bolding).

Many times when we read articles like this one, one of the things that is missing is the *how*. For example, it's all good and fine to tell someone, "practice defense in depth", but it does them no good if you don't tell them how to do that.

I'd like to provide some thoughts, based on my experience, on the bullets:

[b]Set a security policy for your system and know what's on it[/b]
What this amounts to is baselining. Most places have at least an idea of what goes on various systems. User workstations may need Adobe, Visio, Office, etc. A server may need IIS - if it does, does it also need FTP, SMTP, POP, etc? If not, don't install it...or install it, but deactivate/delete it.

"Know what's on it" goes hand-in-hand with documentation. Whether it's electronic or on paper, it has to be done. So, be the first on your block to document your systems!

After knowing what's on it comes checking it later to see what's running. Use a baselining process that can be used for verification later...much like the principle on which Tripwire was built.

(more after the jump)

[b]Actions should be verifiable[/b]
Verifiable actions start with procedures. When a senior sysadmin tells a junior sysadmin to "check" a system, or that she "checked" the system, there should be a procedure there that is verifiable.

This also points to unique logins for each individual, rather than having a communal login.

[b]Always give the least privilege practical[/b]
I once did an assessment of an office associated with law enforcement. I stood in the hallway next to the receptionists desk, and from where I was standing, I could see the monitors on systems in six different offices. I asked the sysadmin (a civilian) if users were allowed to download and install software. His response was an emphatic "No". I could see two systems with non-native screensavers, one user playing a non-native version of Solitaire, and two other users with IM clients installed.

Research for my book showed that user-mode rootkits would not install properly on accounts with user-level privileges and no debug privileges. The same rootkits would install easily on the Administrator account.

[b]Practice defense in depth[/b]
What does this mean? Well, why create a single point of defense, as it is also a single point of failure. Many architectures are connected to the Internet via a router followed by a firewall. Start by putting ACLs on the router to limit inbound traffic. Mirror those ACLs on the firewall rulesets. An example of this would be to tell the router to drop all ICMP requests. Mirror this with an alert on the firewall. If you receive an alert from the firewall that an ICMP packet was dropped, then you know that something must be wrong with the router.

Another example would include defining virtual networks on the switch, or setting ACLs on an internal router. Don't leave that as the only method of protection. Strong passwords on all systems/accounts, A/V and/or IPS software where applicable, IDS, etc...some you have to buy, but others are free and part of your policies.

[b]Auditing the system: keep (and review) system logs[/b]
This one is always a toughy, particularly with Windows systems. If you're not big on commercial systems, there are variety of freeware options. One is to use syslog clients that send new events to a central server. Using either Windows or Linux, you can collect, archive, parse, and analyze those entries in any number of ways.

[b]Build to contain intrusions[/b]
The Navy does this on ships, through compartmentalization. Close a hatch, and entire sections of the ship are cut off. This protects the ship and the sailors. Apply that same principle in your network design. Which systems should be in a DMZ rather than on the internal network? Should Sales and Marketing be on the same subnet as Finance?*

[b]A system is only as strong as its weakest link[/b]
All it takes is one system with a weak Admin/root password, a couple of unmonitored services, and boom! All of your security comes down around your ears. Not even IDS can be relied on at that point, because the bad guy is now identified as a valid user.

Locking the barn door after the horse is gone is ineffective
This goes back to the root cause analysis. A/V products don't do it all...they just tell you when they've found something. Reloading a system from clean media after a possible incident is ineffective, as you have no idea what you're protecting against, and you may very likely be putting a vulnerable system right back into service.

[b]Practice full disclosure[/b]
Rather than fearing reprisals, one should seek improvement, and that's only done through full disclosure. We each may be smart, but no one person is as smart as all of us put together, so work as a team...and let others know what happened, for no other reason than they can protect themselves.
Remember, the bad guys have an advantage. While most sysadmins have multiple systems they are responsible for, as well as multiple tasks that they must complete during the day, the bad guys have a single goal, and will focus like a lazer on a single vulnerability in a single system. Also, the bad guys talk and share information incredibly fast...keeping information to yourself and not asking for help in the face of a potential compromise is just going to end up making you a target in the future.

Keydet89

*The answer to that one is a resounding NO!!