Network Security Misconceptions in Government

A couple years ago, we did a series of blogs on common network security misconceptions in local government. Since a lot of that information is still relevant today, we thought we’d go back through as a refresher course.

First, let’s talk about “public” information. Just because some of the data on a government’s network is “public” doesn’t mean there isn’t private information that needs to be protected. It’s important to know the difference. (A good place to start is the Open Government Guide: https://www.rcfp.org/open-government-guide)

Once you’re educated on the difference between public and private data for your organization, you can begin to organize it. A lot of local governments can’t tell HIPAA data from criminal data from Social Security numbers, and this presents two problems. First, without classifying data simply as either public or private, you are making the work of your local clerks twice as hard. Data should be managed in a completely different way: Segmented, segregated, and classified. And second, if you don’t know what information is private, you don’t know what information to protect. You don’t know where to put your stoutest defenses and build your highest walls.

On a related note, a significant precentage of government organizations don’t know exactly where all their data is (let alone have it classified properly). You may believe that you know where your data is, but you might be surprised. With single servers handling multiple departments’ data and applications, knowing where data is to the level of detail that, say, federal agencies do isn’t possible. A single breach of a single server could mean that information from several departments has been compromised.

How to combat this? To some degree, the local officials aren’t necessarily to blame. This is a misconception that can be blamed on dollars and cents. Buying a server for a single department or application is expensive, too expensive for many. One solution? Virtualization. Run virtual machines, splitting up your apps across the VMs, and segmenting the data. For example: If you’re using SQL servers, you are going to need to protect those databases. That means putting something on the wire that can recognize the difference between normal and abnormal calls and then something on the server that can segregate databases and permit only those with permission to access the tables.

Now let’s talk about your people. More and more, hackers aren’t relying on inbound exploits and malware as a sole means of getting into a network. Instead, they are counting on the naiveté of the typical employee. They are using phishing and other social engineering schemes to trick these employees into providing them with legitimate ways to enter the network.

“It’s OK, though, because the training that was held last year covered all that stuff. Our network is safe.” … Well, that’s true if every employee took that training to heart and your organization never hired a new employee after the training. Oh, and if hackers weren’t constantly evolving their methods. Unfortunately, that’s probably not the case.

Employee training needs to be thorough, regular, and ongoing. Unfortunately, for smaller organizations the execution of that training is probably falling to someone in the IT department, and training and educating aren’t really in the skillsets of many in IT. With that in mind, here are some things to know about effective training: Use simplified language every employee can understand; encourage – don’t discourage! – questions; and keep employees up to date on their training.

The more things change, the more they stay the same – if you’re interested in learning more, you can start with the original blog series, or just download our eBook on security misconceptions in network security.