By John Moran

Editor’s note: Recognizing that “the most serious economic and national security challenges we face are cyber threats,” the Department of Homeland Security, in cooperation with the National Cyber Security Alliance and the Multi-State Information Sharing and Analysis Center, observe National Cyber Security Awareness Month each October. The overarching theme: Our Shared Responsibility. This is a great time to focus your agency on identifying and addressing vulnerabilities in your network. For ideas on how your organization can mark National Cyber Security Awareness Month, visit www.dhs.gov/national-cyber-security-awareness-month.

Public safety agencies are becoming increasingly popular targets for hackers. Following several high-profile data breaches of law enforcement agencies in early 2012, hackers released a statement along with the stolen data:

“EVERY police department is at risk, and will remain that way until police departments start taking notice as to whom they work for. They do not work for corporations, bankers, or governments, they work for the people and we are the people. Expect US!”1

No agency wants to be the subject of the next big headline. Fortunately, there are several steps public safety agencies can take—for little to no cost—that can help mitigate the risk of a data breach and perhaps more importantly, respond when one does occur.
When the worst does happen, there are five questions everyone will want answered immediately:
1.    Who accessed our data?
2.    What data was accessed?
3.    Where is our data now?
4.    When did this happen (and how long has it been going on for)?
5.    How did they get in?

If you’re not prepared ahead of time, the likelihood that you’ll be able to properly answer these questions decreases dramatically.

Reduce User Vulnerability
Everyone understands the importance of good virus protection and a well-configured firewall; however—although these are still important security tools—they are no longer adequate to properly protect your network. To further protect your network, you must start by addressing the largest vulnerability within it: the users.

Attackers are no longer going after your perimeter firewall; they are targeting specific users with carefully crafted e-mails, documents and programs. They have stopped trying to “scale the castle wall” and are instead being led right in the front gate. Several recent high-profile compromises, such as the compromise of RSA, were the result of the unwitting actions of a single employee.

Every agency should have some form of a security policy that details exactly what’s expected from the users. This should include such topics as password requirements, privacy, Internet use, downloads and installations, external drives, remote access and discipline. When developing a security policy, it’s important to balance security and usability. A requirement for 16-character passwords with uppercase and lowercase letters, numbers and symbols sounds very secure until you find that everyone has written their passwords on a sticky note under their keyboard because they cannot remember them. When parts of the policy become too restrictive, users tend to ignore the policy altogether.

Once a policy has been established, train new employees on the policy when they’re hired, and refresh the entire staff on the policy at least once a year. PhishMe (www.phishme.com) provides a unique service that allows network administrators to test their employees on various aspects of their network security policies. Using the PhishMe service, administrators can craft realistic phishing e-mails, documents and applications that can then be sent to users within the agency. PhishMe tracks which users viewed the phishing attempts and offers those users online training on how to avoid such attacks in the future. Although not a free service, PhishMe allows administrators to come as close as possible to replicating real-world scenarios without spending the time and money setting up the infrastructure a real attacker would need.

Develop a Response Plan
Despite all of the preventive controls money can buy, if someone wants to get into your network, given enough time, money and determination, they will. When the worst does happen, it’s important to have the tools and resources available to respond quickly and effectively.

Perhaps the single most important tool in your arsenal is a well-thought-out and thoroughly tested incident response plan. All the other tools discussed in this article will do little good without a plan in place to use the tools properly. Although staff may “know” what to do in the event of an incident, that will likely all go out the window when the pressure is on, so write the plan down and test it often.

The first step in developing an effective incident response plan is to take a high-level look at your network. Some questions to consider:
•    What does your network look like?
•    Where is your network vulnerable?
•    Where is your critical infra­structure located?
•    What data may be of value to an attacker?
•    Where are your strengths and where are your weaknesses?
•    How will your organization cope during and after an incident?

The most effective incident response plans tend to break incidents into numerous phases; these phases may be categorized in a slightly different manner in different plans, but the content of each phase is generally similar.

Stage 1: Discovery: The first phase is normally the initial discovery of a potential incident. An incident may come to light through a virus scan alert or through a phone call from a concerned citizen about information displayed on your website. This phase may involve almost anyone at your agency, so it should be brief, to the point and well understood. Consider who should be notified if an incident is suspected.

Stage 2: Investigation: During the second phase of an incident, the investigation begins. The first question to answer is whether an incident has actually occurred. And if it has, what is the extent of the incident? Part of this phase of the plan should include who to notify (e.g., information technology (IT) manager, agency director, local government officials) and when to call resources outside your agency. Computer incidents can quickly overtake even the finest in-house IT team, so it’s important to know who to call when you have surpassed the capabilities of your in-house resources. Remember to think outside the IT department; it may be appropriate to notify department heads, human resources, public relations and the legal counsel.

Ensure you’re familiar with applicable laws in your state requiring notifications to be made to affected parties within a certain amount of time. Depending on the type of incident, it may be necessary to involve law enforcement personnel early in this stage as well.

The primary goal of the IT staff will likely be to determine what has occurred so they can quickly rectify the issue; collection and preservation of evidence may be an afterthought at best. Law enforcement or private incident response teams can assist in this phase of the incident to help ensure that evidence is collected in a forensically sound manner and preserved for possible legal action.

Stage 3: Incident Response: Once the full scope of the incident has been determined, the third phase, incident response, can begin. This will be the first time offensive steps are taken to try to mitigate the incident. During some incidents, phases two and three may overlap, but it’s important not to jump to action without fully understanding the scope of the incident beforehand. IT staff in a hurry to rectify the issue at hand, inexperienced in criminal investigations, may unwittingly compromise evidence in their haste to bring the system back to normal operation. Actions as simple as a virus scan or power cycling a system can permanently destroy evidence that may lead to the perpetrator. For these reasons it may be advisable to employ outside law enforcement or private resources during this phase as well.

Stage 4: Recovery: The final phase should involve a recovery plan. The primary concern at this phase is returning your agency to normal operations. Depending on the scope of the incident, you may need to recover data from a backup, replace hardware or even completely wipe the system to ensure that any remnants of the compromise have been completely removed.

If the investigation phase of the incident was completed properly, it’s likely that the initial cause of the incident can be determined. Using this information, the final steps in the recovery plan should include steps to safeguard systems against similar attacks in the future.

Although the size and complexity of incident response plans may vary by agency, even the smallest agency should have at least a rudimentary plan in place.

Consider Additional Security Tools
Many tools available to assist in detecting and responding to a compromise go beyond the basic antivirus and firewall solutions. Network security solutions are generally placed in two broad categories: host-based solutions and network-based solutions. Host-based security solutions monitor an individual system for malicious activity; examples are traditional anti-virus software and Windows firewall. Network-based security solutions monitor the communication between systems as well as what’s entering and leaving your network; examples are network firewalls and content filters.

Before I get into specific products, let’s take a moment to discuss Linux operating systems. To many network administrators, Linux operating systems are a frightening unknown used by hackers and hobbyists and have no place in their network. The reality today could not be further from the truth. Operating systems such as Ubuntu (www.ubuntu.com) and Red Hat (www.redhat.com) offer both desktop and server editions featuring stability on par with Windows. The open-source nature of Linux allows application developers and security researchers to create highly effective security solutions that are often offered free or at a fraction of the price of their Windows counterparts. It’s not necessary to be a Linux expert to get started with many of the tools discussed here. The Linux user community is very active online; chances are someone else has already experienced any problem you may have and the answer is likely only a Google search away.

Complete, accurate information is critical in detecting and responding to a compromise. Your servers, routers and firewalls are most likely collecting massive amounts of information that’s going unused. Even if this information is being recorded, it’s likely being recorded in many different locations and formats, making it more challenging to understand the complete picture during an incident when time is critical.

Most network equipment is capable of exporting information to the standard syslog format, which allows logs from multiple sources to be stored in a single secure location in a standard format. Not only does this allow for easier log aggregation and standard formatting, it also makes it less likely that an attacker will be able to cover their tracks by modifying or deleting logs, since the logs are stored on a secure server separate from the compromised system. Let’s look at a few specific products that can improve your network information collection and analysis.

•    LogAnalyzer by Adison (http://loganalyzer.adiscon.com) is a free syslog collector and analyzer for Linux that provides levels of granularity from overall log statistics to individual logged events.

•    Splunk (www.splunk.com) is the current gold standard in log collection, analysis and more. Splunk offers both free and paid versions for both Linux and Windows systems, as well as many tools to export logs from many different systems including Windows event logs.

•    Malwarebytes (www.malwarebytes.org) offers both free and paid versions that take traditional antivirus solutions to the next level. It’s designed to detect all types of malware, including viruses, Trojans, spyware, adware and rootkits that other antivirus programs may miss. Malwarebytes can be run alongside traditional antivirus systems and is a great addition to your host-based security solution.

•    When it comes to host-based information, Carbon Black (www.carbonblack.com) is second to none in host monitoring and data collection. While not free, it’s reasonably priced and is a must-have if you want to be fully prepared when the worst happens. Carbon Black uses a sensor installed on each host to monitor events such as network connections, registry modifications, file executions and more, which are then logged to a central server. After a suspected incident, this information can be vital in validating whether an incident has occurred and tracing the source of the compromise.

•    Snort (www.snort.org) is a free and open-source, rule-based, network intrusion detection system that can be run on either Linux or Windows. Snort’s flexibility and scalability make it appropriate for home users and large organizations alike. Snort’s large user base also means that it has a large community support network that can assist in the resolution of almost any problem. Snort sensors are deployed at key points within a network (usually routers) and monitor every byte of data that traverses these nodes. As data is received, the sensor attempts to match the data against known attack signatures. If a match is found, an alert is generated and logged. If configured to do so, Snort can also record the exact network data that generated the alert for later analysis. Alerts from multiple sensors can be logged to a single location in a number of ways, including text files, MySQL databases and PostgreSQL. This flexibility allows Snort data to integrate seamlessly in to other security and logging products. There are also a number of third-party user interfaces for Snort, such as Snorby (http://snorby.org); Sguil (http://sguil.sourceforge.net) for Linux, which allows the user to visualize alert data; and IDS Policy Manager (www.net-security.org/software.php?id=5),which allows the user to manage Snort policies across multiple sensors.

In addition to these products, there are numerous network security resources available online, including the U.S. Computer Emergency Readiness Team (US-CERT; www.us-cert.gov), the National White Collar Crime Center (NW3C; www.nw3c.org) and the U.S. Department of Justice (www.cybercrime.gov).

Fortify Your Walls
There’s no magic pill that will make a network immune to any network intrusion, but taking the time to go through some basic steps can make the difference between a compromise that paralyzes your agency, affecting public trust for the long term, and a breach that’s quickly detected and resolved. Protecting your castle doesn’t have to be expensive, but it does require testing for vulnerabilities and developing a plan that will get you through an incident when one inevitably occurs.

About the Author
John Moran has been working in information technology in the public safety sector for the past three years. Before that, he was an emergency dispatcher for five years. He is also a reserve police officer and a volunteer firefighter/EMT-I. He has a bachelor’s degree in computer forensics from Champlain College and holds the following IT certifications: Certified Forensic Computer Examiner through the International Association of Computer Investigative Specialist, EnCase Certified Examiner through Guidance Software, Certified Ethical Hacker through EC-Council and A+, Network+ and Security+ through CompTIA. He also holds Certified Terminal Operator and Emergency Medical Dispatch certifications.

Reference
1.    Hackers attack three more law enforcement-related sites, dump data. (Feb. 8, 2012) In Office of Inadequate Security/DataBreaches.Net. Retrieved June 25, 2012, from www.databreaches.net/?p=23227.

This article originally appeared in October 2012 Public Safety Communications.