- Identify key data flows
- Understand user interactions
- Examine the network perimeter
- Assess the servers and workstations
- Look at the applications
Here’s some additional thoughts of mine regarding these steps:
- Key data flows. Think about your company’s most sensitive data, such as customer information, engineering designs, or a famous recipe. Follow the data from it’s entry point, through each network device, where it’s stored, how it is transmitted. Determine whether the data is copied to other databases, laptops, mobile devices, including USB drives, and don’t forget off site versions on vendor and home computers. Does the data needs to be protected in each instance?
- User Interactions. Is the data classified as sensitive? If not, how can employees and vendors know what expectations the company has regarding protecting it? Many companies still do not classify their data. If they do, it’s SOX and non-SOX, and that’s as far as it goes (“check the box and move on”).
- Network perimeter. If the perimeter is weak, usually all other risk mitigation strategies are also. Keep in mind, though, most of your risk issues are internal (70-80%). No sense in letting outsiders raise your risk another 10%.
- Assess the servers and workstations. Few companies patch well. It’s labor intensive and boring, and can be risky due to conflicts. However, I believe too many administrators hide behind the “patches could crash the server” lament. In my experience, it doesn’t happen that often (yes, I have been there and had to patch servers and applications myself for a number of years).
While all it takes is one crash to bring down the management house on you, you need to divide and conquer. Start with Internet-facing servers and devices and any other key items (like infrastructure) and test and patch them. Any incremental progress helps, because security is best applied closest to the data (databases, applications, and servers). The more you protect your critical data systems, the less you have to be concerned about the unpatched systems and devices in your organization.
- Applications. Some applications are installed by vendors, and some vendor “experts” know how to follow an installation checklist, but may not understand the implications of the “approved” configuration, especially in your environment.
I remember watching a vendor install a time card application. When he configured the NTFS permissions on the applications folders and shares, I asked him why he did it that way. “It’s the approved config,” he said.
“But do you realize,” I asked, “that those permissions will allow any user of this application to copy the entire database off line, change it as they desire, and copy the altered database back, undetected?”
“I doubt that,” he replied. “Besides, I wouldn’t know how to prevent that.” After he left, I was able to “swap” the database in 15 minutes. It took a bit of testing to determine how to configure the permissions to prevent it.
Tackling even one of these items is a lot of work, and you need policies and all that. Even if you can’t do a full-blown program, you can take baby steps, and start moving in the right direction. Eventually, you might be able to gather steam and take larger steps.
Stop the Bleeding
If you can’t do anything else, try to at least stop the bleeding. Fully patch and test new servers, applications, laptops, and desktops. Analyze the data flow of new processes and ask leading questions. If you can address most of the issues with new technology and new projects, you’ll have less to clean up down the trail. And in the meantime, your new methodology might influence others to follow–at the very least, you’ll have plenty of opportunities to educate others why security is important.
Even if you take only baby steps, time continues to pass—and in 4 years, would it be better to be a few steps further down the path, or still where you are today, trying to get approval for a comprehensive security plan?