What Security Threats Mean to an SMB
SMBs have varying levels of understanding of security threats, depending on their experience with security breaches and their implications. When an SMB has experienced the impact of security breaches (for example, DoS attacks or disclosures of confidential information), its view of developing a security policy and implementing security solutions is tempered by those experiences.
For example, take an Internet service provider (ISP) that offers a wide range of Internet-related services to businesses and individuals. This ISP experienced a DoS attack that was intermittent and that lasted several days. Many of the ISP's business clients were frustrated because their communications were severely disrupted.
The ISP's network engineers experienced their own high levels of frustration while trying to determine the source of the attack and how to stop it. (It was probably not the best time for the ISP to be recruiting new clients through glitzy marketing campaigns advertising the high degree of reliability of its services.) The upshot of such an experience is that, in the future, as compared to other ISPs who have never experienced a DoS attack, this ISP will be in a much better position to assess the cost of similar attacks versus the cost of the solution to protect against them. Perhaps the unfortunate ISP lost a few clients, and the salaried staff had to work overtime. But after the frustration subsided, the cost might not have seemed so large.
Trying to determine the actual cost of a security breach is a tricky business. A fundamental principle regarding security is that the cost of a security solution should be less than the cost of recovery from a security breach. The decision of whether to deploy a security solution should be clear, then, if the two costs can be easily compared. But the problem with that fundamental principle is that it is difficult to figure out what the actual cost of a security breach is. An SMB cannot look simply at the immediate monetary cost of a security breach. What about the long-term effects on the SMB's reputation and credibility when the services it offers are disrupted as a result of poor security?
There is no magic bullet to figure out the cost when it comes to intangibles like credibility, trust, or reputation. But decision makers need to consider these types of costs when developing a security policy and considering appropriate security solutions.
Consider the scenarios in the following subsections. They are presented in the form of questions that anticipate different types of security breaches. Each of the scenarios represents a manifestation of a threat from one of the broad categories of security threats discussed earlier in this chapter.
Given the wide range of businesses that fall under the SMB umbrella, the impact of these scenarios—if they occur—will vary from one SMB to another. However, in preparation for the discussion in the section “The Importance of Having a Security Policy” later in this chapter, I attempt to raise issues that are universally applicable across the SMB spectrum and that must be considered when developing a security policy. Without a security policy (explicitly defined or at least implied), an SMB will likely be paying lip service to network security rather than taking it seriously.
What if My Website Is Defaced?
A defaced website can make people laugh, or it can make them lose confidence in the website owner's ability to conduct business. A defaced website represents a form of information corruption. It is also a statement to the whole wide world that someone other than the business has control over the manner in which the business is presenting itself to the public via the Internet.
When faced with the issue of website defacement, consider the following:
The extent of the defacement
How long the defacement lasted before being discovered
Whether or not the defacement had a visual impact only or an operational impact as well
If an SMB uses its website as a glorified business brochure but conducts no business transactions over the web, the defacement is at best a temporary embarrassment. No confidential client information was lost, and no normal activity was disrupted as a result of the defacement. But if an SMB's e-commerce website is defaced, and in the process, confidential client information is stolen and business operations are disrupted, the situation presents an entirely different challenge. There is likely to be an immediate monetary loss and perhaps long-lasting consequences resulting from the compromise of sensitive information.
In general, the perspective that needs to be maintained regarding websites is that they are extremely dynamic. Numerous websites are in a constant state of being updated, revised, and revamped. If someone were to take a really broad view of the concept of website defacement, they might even argue that websites that simply malfunction, point to nonexistent pages or URLs, or present viewers with misleading information are defaced. There is no need for an attack to deface them.
Because the Internet permeates all aspects of modern-day life for individuals and most businesses alike, there is a degree of understanding that websites, just like printed matter (books, newspapers, or magazines), will contain some errors and have navigational problems regardless of any effort made by someone to deliberately deface them. Viewers (browsers, surfers) have developed a degree of familiarity against these conditions. Consequently, unless defacement is absolutely spectacular, the tendency on the part of today's surfers is to take it in stride.
High-Profile Website DefacementWhen hackers defaced the home page of the Central Intelligence Agency (CIA) in 1996, changing the name of the agency to Central Stupidity Agency, it certainly caught the attention and imagination of the public, bringing a chuckle to many. However, the CIA does not fall into the category of an SMB and presents more of a high-profile challenge to the hacking community than, let's say, a local hospital, a car dealership, a community bank, or a grocery store. |
It is also important for an SMB to ask who would want to deface its website. Would it be a hacker, a competitor, or a criminal? Although exact statistics are not available, there are orders of magnitude more websites out there than there are hackers willing to spend time defacing them. Competitors attempting defacement run the risk of being more easily discovered because they most likely do not have the hacking expertise to cover their tracks. And criminals usually need a motive other than a desire for mere fun and a rush of adrenaline.
It takes work on somebody's part to deface a website, and a general human tendency is to want material compensation or at least emotional satisfaction for work performed. So if an SMB is selected for defacement, at least it's a sign that it attracted someone's attention to such a degree that the person felt compelled to exert effort to deface the website.
Because the sport of defacing websites is becoming rather passé, if an SMB's web server implements basic security measures, the odds of being selected for defacement are small. However, the risk still exists and should be taken seriously. Implementing all of the web server's operating system security features and keeping up with ongoing updates is the absolute minimum action that an SMB ought to take to minimize the potential for having its website defaced. Also, having a current backup of all of the HTML files that compose the website allows for its quick restoration after the defacement has been discovered.
What if My Website Is Inaccessible?
Web browsing is a process that is now taken for granted. Every time an SMB's customer accesses its website, myriad low-level events transpire to facilitate that process.
Unless an SMB is an Internet provider, it is going to rely on one or more ISPs for access to the Internet. When an SMB's website becomes inaccessible to some or all of its customers, it's time to engage in a troubleshooting process to determine the cause of the problem. Although website inaccessibility is a form of DoS, having this problem does not mean that the SMB is experiencing a DoS attack. In fact, it's far more likely that the inaccessibility is caused by an equipment malfunction or a traffic jam somewhere along the path between a customer and a web server rather than any form of a security breach.
Consider the potential causes of website inaccessibility:
Web server down due to operating system crash
Web server down due to hardware malfunction (hard drive or NIC, for example)
Problem with router/switch to which a web server is connected. This occurs either at the SMB's or a hosting company's site.
Failed WAN link from the SMB's ISP to the rest of the Internet
DoS attack specifically against the SMB's web server
Major disruption of Internet traffic due to failure of DNS root server(s)
Worm attacks against numerous Internet servers, causing a collective slowdown or near shutdown of Internet activity
An SMB can take reasonable measures to protect against DoS attacks targeting its server(s) or increase website availability by having multiple providers. However, the SMB needs to realize that when you're dealing with the Internet—which consists of more than a hundred thousand networks and millions of computer hosts linked via a vast array of digital pathways—glitches are to be expected.
It is a tribute to the technology companies that manufacture Internet-related equipment and software and to the countless individuals who design the protocols, configure the equipment, and maintain the vast and complex infrastructure that the Internet works at all. Given the magnitude of the Internet as a collective enterprise and the degree of interoperability and cooperation that is required between the numerous ISPs, consider it a kind of a miracle every time it works. Then, when a website becomes temporarily unavailable, it can be perceived as nothing more dramatic than a temporary power blackout, a freeway traffic jam caused by an accident or just a lot of traffic, or being out of range for a cellular phone.
What if Someone Intercepts and Reads My E-Mails?
Ah, the illusion of privacy! Just consider the nature of e-mail. After you click the Send button, that e-mail message must pass through the outgoing mail server and be received on the incoming one. It might also linger in the mailbox of the person who sends it as well as the mailbox of the receiver, and it passes through countless routers and networks in between. If someone wants to read your e-mail, the intrusion can happen at the sending or receiving workstation, at the mail server, or while the e-mail is in transit.
When creating a security policy, you should assume that all unprotected e-mail is potentially subject to inspection by unauthorized prying eyes. If an e-mail sender feels comfortable with his or her message being widely publicized, there is little case for strong security measures relating to e-mail. However, if strict confidentiality must be maintained in an SMB's e-mail communications, stronger confidentiality antidotes like encryption might have to be implemented. Information confidentiality is discussed in the “Security Threat Antidotes” section later in this chapter. SMBs with multiple geographically dispersed locations that are concerned about the confidentiality of internal e-mail communications should consider a virtual private network (VPN) solution.
When considering e-mail confidentiality during the development of a security policy, consider the risks of having e-mail messages exposed to various groups of individuals. Who could possibly want to spy on e-mail communications, what benefit would they derive from it, and what are the consequences to the SMB? If a hacker wants to get into someone's e-mail for the sake of personal satisfaction, the business fallout from that kind of hack is likely to be minimal. But if a competitor gains access to an SMB's e-mail communications, business implications change drastically—for example, planned mergers might fall through, bids could be underbid, and product announcements might be preempted.
What if My Customers Can't Send Me E-Mail?
A poorly maintained in-house mail server is a serious vulnerability for an SMB. If an SMB relies on an ISP's mail servers, it is less vulnerable because the ISP has probably taken steps to harden those servers against attacks and to ensure a degree of redundancy and reliability that would minimize any lengthy e-mail service disruptions.
But what if an SMB gets a domain name and sets up an internal e-mail server that perhaps doubles as a web server? The SMB must take the following reasonable steps to minimize e-mail communication disruptions: maintain the server with all of the latest security updates to the operating system, back up the server and ensure that it can be restored quickly under any circumstances, and place the server in the demilitarized zone (DMZ) of a firewalled network. If the SMB does not take these steps, watch out!
By now, you are probably thinking that if customers can't send you e-mail, it is the result of a DoS attack. And that could certainly be the case. But if it is a DoS attack, it is probably directed against the customers' ISPs, of which there could be many. Coordinated DoS attacks occur, but they require effort and motive on the part of somebody or multiple somebodies.
If an SMB is not receiving e-mail from customers, there is probably a problem with the SMB's ISP or the SMB's incoming e-mail server. If such an event happens, the SMB's IT staff needs to ascertain the following: Are all of the SMB's customers not able to send e-mail to the SMB? Or, better yet, is the SMB able to receive any e-mail? The silver lining in this situation might be the relief on the part of the SMB's employees from unsolicited e-mail, also known as spam.
Loss of e-mail communications, whether incoming or outgoing, can represent a serious disruption to business operations and should be considered a form of denial of service, even if not a DoS attack. However, you always need to maintain the perspective that loss of e-mail communications is typically a temporary problem and that, despite the popularity of e-mail, there are still numerous other means of communicating, even if they are more traditional.
What if Unauthorized Personnel Gain Access to My Internal Databases?
Unauthorized access to internal databases—whether that access is by employees or not—is serious business. It represents a form of information disclosure, and the severity of the compromise depends on the degree of confidentiality of the information being viewed. The degree of damage to the SMB resulting from the disclosure also depends on whether or not the information being viewed can be copied and taken off the SMB's premises for future use.
Two of the broad security threat categories are involved here: information disclosure and lack of authentication and authorization that facilitates repudiation. Consider a scenario in which an outsider with a malevolent intent gains access to the internal databases as a result of gullibility on the part of an SMB employee or, perhaps even worse, as a result of an employee's cooperation. This is not an intercept of an e-mail about the date and time of the next marketing meeting; trade secrets and confidential customer information are at stake. The authentication mechanism that has been compromised relied on strong passwords. What went wrong?
Authentication that cannot be repudiated should be considered by an SMB when the stakes are extremely high regarding sensitive internal information. Although strong password management combined with user education can harden authentication, passwords are inherently problematic:
Easily remembered passwords are also easy to guess and to crack.
More robust passwords that are hard to remember are likely to be written down someplace that an unauthorized individual can find easily.
Using a single password is certainly more convenient than trying to remember a complex password for each system. However, if an individual within an SMB has access to many systems requiring passwords, having the same password for many systems compromises multiple systems.
Employees share passwords for seemingly valid reasons.
If you combine all of the potential problems with passwords, you might conclude that something stronger than passwords is needed when really sensitive internal information needs to be protected.
The trend that is emerging in the area of authentication is biometrics. Not every SMB needs to employ biometrics for network authentication, but it should be considered in high-security environments. Biometrics relies on extremely unique characteristics of an individual, such as fingerprints or retinal pattern. Biometric authentication is considered strong compared to passwords, but you need to clearly understand one thing: With cooperation from authorized individuals, any authentication mechanism, regardless of how sophisticated it is, can be cracked.
What if Unauthorized Employees Get into My Payroll Files?
Human nature being what it is, unauthorized peeking into the payroll files probably happens more often than is actually reported. The danger to an SMB is potential embarrassment if the information is made public, especially if there is a great disparity between salaries of different categories of employees. Conceptually, this is no different from unauthorized access to internal databases. The difference lies in the type of information being compromised.
Even though peeking into the payroll files is often cited as a breach of internal security, the damage to the business from this act of curiosity is likely to be minimal. Should this activity be detected, however, it could indicate that other, perhaps far more sensitive and confidential, information than payroll is being compromised as well. As is the case with gaining unauthorized access to internal databases, snooping around payroll files combines the threat categories of information disclosure and weak authentication.