One of the most pertinent strategies you can implement is one of minimizing the number and of course the severity of Security incidents. One of the biggest issues that I see when looking at security infrastructure is the fact that there is not a great deal of effort put into the possibility that there may even be a problem. In fact, most times when I come to an organization, security is not even something anyone really gave a lot of thought to. Because of this, many security problems linger in the darkness of the networks in questions. It is your role as a security analyst to really look at these possible problems and attack them head on, one by one in a process of identification and elimination so that you can in fact minimize the problems ‘before’ they occur.
Minimizing Security Incidents
“For a complete guide to security, check out ‘Security+ Study Guide and DVD Training System’ from Amazon.com“
Proactive vs. Reactive Security Management
Too many times have I seen it be ‘old hat’ to just deal with a problem as it occurs. Without naming names (for legal purposes), I had come in contact with an enterprise that only worked in reactive mode… that is only dealing with issues as they arose. “Reacting” to problems as they come up never really fixes anything… you wind up only placing a band-aid on a sucking chest wound. You never fully learn what the initial underlying problems were, and worse- you never had the chance to head the problems off at the pass. Consider these differences:
Trying to solve problems before they occur is being proactive. Proactively (a word you need to master as a security analyst) is how you want to work everyday to eliminate problems before they occur. In a security sense, this will result in possible auditing of your systems and creating an incident response plan. When you work to be proactive, you can then master the arts of minimizing security incidents because you would have seen some of them creeping up before they happened (proactively), instead of just dealing with them as they occur reactively.
Because incidents will in fact occur (you cant save the world!), then you need to train yourself to accurately deal with problems and incidents. On a Microsoft based network (or any network for that matter), you should think of the following items, which I call my “top ten incident prevention list”. This list will aid you in minimizing the impact, damage and stress of any incident that you may come in contact with when a security incident does occur as well as how to deal with it when it occurs:
- Create policies that are written out and backed by management. This can include a Security policy, Disaster Recovery policy, a Business Continuity Plan… anything you create needs to be written out, read by employees, backed by management and updated constantly. Without this, you are missing the backbone of all security enforcement for your organization.
- Test everything. Now that you have plans a policies, do they work? In other words, if you have a disaster recovery policy that talks about utilizing a hot site, well – have you actually tried it? Is there a specific time you want to be operational again… and if so, has it been tested or timed? Most times, (90% of the time) the answer I get back is ‘no’. You need to do this.
- Audit constantly and assess your network, systems and staff on a constant basis. Do you know who is accessing your systems? Do you know when they are accessing systems? Do you know who exactly has administrative rights over your entire Active Directory? Who has been delegated rights? Well, you need to know all this. Back in the day when I was a Novell Administrator I would audit the tree constantly to see who had trustee rights that were overly excessive and unneeded. Most times when questioned, the user who may have had the rights didn’t even need them anyway. Now taking that same knowledge and applying it to Microsoft’s directory service, it’s much the same thing. You need to give audit your systems to make sure that you have control over what people can do on your systems.
- Verify your back up and restore solution. You should be aware of where backups are maintained, who can access them, and your procedures for data restoration and system recovery. Make sure that you regularly verify backups and media by selectively restoring data. If you don’t have verifiable backups, then why were you doing them in the first place?
- Implement Defense in Depth. If you think slapping a firewall up on the network is your key to security success then you are seriously mistaken and possible in grave danger. I think that a firewall is probably one of the most important items on a network, but by far, not the only piece of the whole puzzle you need to consider.
- Implement Change management solutions. Total control is needed over your network and systems. When I say this, I tend to get blank stares and lose friends quickly… but that’s ok. As a security analyst responsible for the businesses infrastructure security, prepare yourself now to bump heads and make enemies. Make sure that every change on the network is documented, and backup up with a back out plan. You would be surprised how many times incidents happen based on your own people making mistakes or covering things up, it happens very often.
- Security Training is key to continued excellence. Establishing security-training programs for both IT staff and end users is essential to keep your networks safe. Yes, there is danger in people knowing more than you, but that’s the point… make your users and staff educated, but make sure you are on top of things as well. Some of the best security personnel worked their way up the ranks in all areas of networking, systems, support and development.
- When you are completely locked down, do an independent audit. When you have all your systems to your liking, that’s when you call in an independent auditor. (A supreme being if you will). Have a team come in and test your security. This is the pinnacle of your service to your network and company… you know that a group of security auditors couldn’t get through your systems it should make you proud. If they did get through, that just means you have some more to learn, which is a good thing mind you.
- Build an Incident Response Plan. Now you need to create a single plan for when everything falls apart. You are attacked and an issue comes up, lets say you lose a file server from an attacker breaking the systems and deleting your hard disks. Now what? Make sure you have a documented plan accessible by the right people (your team) when an incident does in fact occur.
- Create a Computer Security Incident Response Team (CSIRT). A CSIRT is a group of people or a team that you build with responsibilities for dealing with any security incident. Your CSIRT should consist of members whose duties are clearly defined to ensure that no area is left uncovered in your response. The link I provided earlier in the chapter will aid you in building a CSIRT if you are interested in starting one.
When reading over the top ten list, you can start to think about ‘other’ areas you may want to peak at. That’s good because that means that your thought processes have been stimulated and motivated towards network security. Other ideas you may want to think about is getting local law enforcement agencies involved when creating your incident response team for minimizing security risks. Remember, you are trying to minimize the possibility of security risks, and by having law enforcement on your side (and known) may deter attackers from even thinking about trying something, especially when trying to thwart internal threats, which are more common than external ones. When internal users think that a company may prosecute for damages, you would be surprised at how quickly games and shenanigans on the network and its systems cease. It also helps to know how the department operates so when a problem does occur, you are at least ‘in the know’ about the departments polices and procedures which could speed things up considerably.
