Creating a Solid Information Security Program
April 30, 2009
A successful security program is not run like a dictatorship but rather like a partnership, one of the team, all fighting for a common cause. In order to have a successful security program within an organization everyone has to be involved and support it.Over my 10 plus years of security consulting I’ve seen hundreds of different security programs in place, at a variety of different companies, in various industries. Some appear to be very successful, while others...well lets just say at least people are employed – especially in the recession that we are in right now. One thing that I do know though is that a solid security program encompasses three fundamental aspects – upper management support, solid security policies, and user buy in. If one or more of these are missing then the security program is ad hoc at best. So how do you achieve all three and create a solid security program? Let me try to break it down.
- Security Education / User Awareness – First you have to create awareness and the need for security within the organization. One of the best ways to open the eyes of the company employees is through a risk assessment and/or business impact analysis. Get everyone thinking the “what if” scenario and what it could mean for the company if a breach were to occur. What assets are of value in the company? What information is of value to the company? Get everyone on-board with you and create that need within the organization.
- Upper Management Support – now that you’ve got the attention of everyone and focused on the need for security, it’s time to get upper management to buy off on the need for security within the organization. If step one was done successfully, this shouldn’t be a problem. In fact, upper management might be coming to you to ask what needs to be done to prevent such events. With the full support from upper management on your side it’s time to move on to the next step.
- Solid Policies, Procedures, Guidelines and User Buy-In – This is the area that I most often see as the fault in an organizations security program. Typically, upper management supports the project and then the security group forms a bunch of security policies and guidelines and then pushes them out to the company to follow. While the policies and guidelines may be very well written and follow best practices, one key element was left out – the actual users involvement in creating the policies and guidelines. No one like rules and restrictions pushed upon them, and if they are, they tend to not follow them or resent them. Getting the users involved in the process of creating policies, procedures and guidelines will go a long way in implementing a successful security program.
This brings me to a good point, a successful security program is not run like a dictatorship but rather like a partnership. A single team, all fighting for a common cause. All too often I see it run the other way around and the security department ends up being looked at as the enemy within the organization. Now part of this centers around user awareness and education, but a majority of it is due to the way the security department presents itself within the organization. Boy do I have some good stories to tell around this, but those will have to wait for anther time! My point is, going back to the beginning of this post, in order to have a successful security program within an organization everyone has to be involved and support it. Remember, if you’re missing just one of the 3 main parts mentioned above, then the security program will be ad-hoc at best.
Now on to the more technical needs:
- Patch Management Program/Process – While this can be done manually, I found that using an automated solution works best and is the most successful at seeing that systems and applications stay current on patching. I recommend looking for a solution(s) that can do the following:
- Can inventory all applications on a system be it a Windows or a UNIX variant. Choose something that supports all systems running within your environment.
- Has the ability to notify you of not only new patches that need to be install but also on the success and failure of patch installation.
- Can produce reports on not only patching success and failure but also on virus DAT file status, services and patch levels they are running at, and systems that are out of compliance.
Finally, for those applications that aren’t supported by the automated solution, a manual process needs to be put into place to keep tabs on 3rd party applications running within the environment to make sure they are kept current on patching.
Side note – At a previous company that I worked at years ago, we found ourselves paying more attention to the anomalous traffic as we could slowly see trends of potential attackers casing the network looking for that one way in. Back then we were using SANS’ Shadow application and white-listing all known good traffic to spot only the interesting anomalous traffic. Over time you’d start to see the attacker start to focus on one machine at which point we’d block the IP.
- Vulnerability Management Program/Process – As I mentioned in a previous post, Most Common Internal Vulnerabilities Found, while having a general network vulnerability scanner in place is a must, it’s not the end all solution for a good vulnerability management program. Putting together a solid vulnerability management program requires the following:
- Application Vulnerability Scanner – You’re probably wondering why I’ve listed an application scanner first before a network scanner, simple fact, from an external perspective, the attacks now in days are at the application level and less from the network and service level. While network vulnerability scanners have come a long way over the past couple of years, they still aren’t as good as an application specific/focused scanner in my opinion. An application based scanner is a must now in days for any security program. Also the security group doesn’t have to bear all the cost for the scanner either. I you have in-house development of applications then the cost should really be taken on by that department as they should be scanning/testing their applications before deployment as part of they SDLC process.
- Network Vulnerability Scanner – Features to consider include: frequent and timely updates, good reporting (both per scan and trending), built in remediation tracking, ability to do authenticated scanning of all systems/devices within your organization, and scheduling features that will work within your organization.
- Service Specific Tools/Scripts – See the post Most Common Internal Vulnerabilities Found for more insight.
- Wireless Scanner – Yes, even though you may not allow wireless within your network, and you have policies against its deployment, you should still be sweeping/scanning all of your facilities on a regular basis for rogue access points and clients hunting for wireless networks to attach to. Not only is this good practice, but if you fall under PCI, it’s a requirement!
- 3rd Party Assessments – No this is not a pitch to sell our services but rather a part of the process. You always need a second set of eyes on things to make sure you haven’t overlooked anything.
- Monitoring Process/Solution(s) – Monitoring is a monster in and of itself. Unfortunately, and I could be wrong, there is no one solution that can do it all for you. Areas that need to be monitored will include: systems and application logs, network and application threat traffic, anomaly traffic, network and device usage and network load to name a few. Basically, the security group needs to be aware of all activities happening within and directed to the network in order to defend against potential threats. When evaluating solutions it is also important to be aware of secure protocols that are being used within your environment (like SSL) and if the solution is able to decrypt this traffic to monitor it for suspicious activity. Equally important is to monitor for anomalous traffic. Remember, the attacker has all the time in the world on their side. They’re not going to just blast you with threat traffic but rather take their time poking around looking for that one in that will get them what they want.
- Security Education / User Awareness – We’ve now come full circle. Actually, security education and user awareness training should be ongoing from the start. Formal training should be given to all employees (ALL EMPLOYEES) at least once a year. New hires and contractors should also be required to take a security awareness training class before even ever connecting, or getting access to, the network and/or systems or devices. Aside from the once a year formal training class, user awareness should be an ongoing process throughout the year. Things like posters and weekly or monthly security newsletters should be an ongoing training method within the organization. Another successful awareness method is to reward the good through things like gift certificates or awards to those that are showing security awareness throughout their normal work activities. The point is to make security awareness training not only ongoing but also fun.
This has been a high-level overview of how to create a successful security program within an organization. It’s not complete by any means. There are several areas that I could spend all day (or several days) talking about but it is the basis for a good security program that I’ve seen in all of my years doing consulting. Remember, if you don’t have upper management support, solid security policies, and user buy-in, then the security program within your organization will be ad-hoc at best. All three are needed in order for the program to be successful.