1. 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.
2. 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.
3. 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:

1. 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:
   1. 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.
   2. 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.
   3. 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.

   Systems out of compliance – One really cool features that I’ve seen in some of the patch management solutions out on the market today is the ability to also handle configuration management. This is an awesome value add and something that I’d highly recommend looking into.

   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.

1. 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:
   1. 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.
   2. 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.
   3. Service Specific Tools/Scripts – See the post Most Common Internal Vulnerabilities Found for more insight.
   4. 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!
   5. 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.
2. 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.

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.

3. 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.

-Kirk Greene

Below is an overview of the top most common ways I generally find to get in:

• Blank/Weak MS SQL “sa” Account Passwords - Yep, number one way still I typically get in. What’s funny is that lately it’s either a security database that houses proximity card access rights or the companies Blackberry Enterprise Server. Believe it or not, most of your commercial and open source general vulnerability scanners only check for a couple of passwords for this account – typically only a blank password, but I’ve seen some that actually will also check for “sa” and “password” as the account password. As you all may or may not know, give me “sa” access to your MS SQL database and I own the box. Using the same administrator password on all of your servers? Well, I now own them as well! So what do I use to find this common hole, SQLLHF (thanks Matt Wagenknecht!!) with a dictionary file of about only 10 common passwords – does the trick almost every time.
• No Password Assigned on the Oracle TNS Listener Service - When I see an Oracle service running in an environment I start foaming at the mouth. Why you ask? Because 9 times out of 10, if no password is assigned to the listener service, I know I’ll find a default Oracle account. Also I know that if I can’t take over the host OS with that account I’m bound to find some really juicy data being stored in the database that makes taking over the host OS look like peanuts.

Side Note – The most common default Oracle account found is DBSNMP. Why is that? Because just changing the password for this account within the database breaks the Intelligent Agent service if you don’t also change the password in the snmp_rw.ora file. DBA’s will often change the account in the database, see that the Intelligent service stopped working, and then just change it back thinking that since the account isn’t a really privileged account so what’s the harm. Well reality is that this account has just the right amount of privileges to compromise not only the database but also sometimes the host OS itself. No account within an Oracle database is safe to leave with the default password assigned – even the SCOTT account!

• Cached Credentials – By default, Windows stores the last 10 accounts that logged into a system in cache. While cracking these passwords can take some time, it’s generally worth the extra time and effort as typically they are domain admin accounts that will give me the keys to the kingdom. So you might be saying, “OK, well in order to get cached credentials you’d have to be an admin on the box. That means a weak password for an admin account exists and we should have seen that during our scanning and addressed it.” Well, yes and no. How often are you scanning your workstations and mobile devices? It’s funny how when you give users local admin rights to their workstations, or most commonly laptops, how the local accounts (or the local Admin account) have a blank or the username same as the password. All it takes is one bad apple to bring down the entire tree:-)
• Weak/Default Password on Networked Appliances and/or Networking Devices - While this doesn’t directly lead to a compromise of the environment it can be just as damaging. I can’t tell you how many times I’ve run across things like default accounts on an HVAC control system for a datacenter or a central console device to manage networking gear (Often companies don’t put passwords on console access to networking devices because you have to physically be at the console – right?). Wrong! Nowadays administrators try to stay out of the datacenter as much as possible and do everything remotely. Who wants to sit in a freezing room for hours on end when you can remote into the device from the comforts of your office.

Well those are the top things that I typically run across that ruin the day for the client but make it a successful engagement for me:-) The one finding that I stress in just about every report, and also to the client throughout the engagement, is you have to expand your password policy to anything that requires or can be assigned a password – anything! Then you have to educate users on the need for good password usage. If you don’t, then there will always be a way to get in. You can scan all you want and patch systems until you’re blue in the face, but if you don’t use good passwords, you’re just opening the door for an attacker to walk right in.

To enhance your vulnerability management program, I recommend the following tools be added to your arsenal. Without them you could be leaving a door open for an attacker.

• Oscanner – Oracle scanner that tests for default Oracle accounts and passwords
• SQLLHF – MS SQL scanner that allows for dictionary attacks against the “sa” account

Aside from the tools listed above, I’d also recommend updating your system configuration policies and setting the following registry key to 0:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsNTCurrent VersionWinlogon CachedLogonsCount

Finally, investigate all web services identified by your scanners – especially those running in the 8000 range as some of these remote web management services can either be disruptive to the system/device or lead to a direct compromise of the system/device itself. Disable them, or at a bare minimum, change the default password and ensure that they are up to date (of the current release). By making these simple enhancements/changes, the next time I come in for an assessment, you’ll stop me dead in my tracks…Or at least make me work a little harder

-Kirk Greene