Practice Management
CPAs operate in an increasingly connected environment, carrying with them numerous devices that constantly interact with the internet over various connections. These devices also contain more data than most CPAs would have been able to store on all of their firms’ servers just a few years ago.
These devices allow CPAs to more effectively and efficiently serve their clients and are designed to be easy to use. However, their nature of constantly communicating over the web and the amounts of sensitive data they contain mean they also pose significant security risks that some CPAs may not have fully considered.
It is simply not practical to stop using these devices, so CPAs must instead understand the security issues involved and some of the steps they can take to control and minimize these risks. This item highlights some of the issues that should be considered.
Loss of Device
A portable device’s small size and ease of transport are key factors in providing for efficient and convenient access to information, key factors that make them invaluable to a CPA in practice. But the small size carries the inherent risk of losing the device, either accidentally or through theft.
CPAs should consider ensuring that all portable devices, including laptops and USB thumb drives, as well as smartphones and tablets, have their data encrypted, with a strong password or similar high-level security authentication required to decrypt the device’s data. Similarly, the devices should be set to lock themselves (Auto-Lock) after a relatively short period of inactivity, requiring authentication (a password) to be given to regain access to the device.
Smartphones and, to a lesser degree, tablets provide a unique problem with security, since inputting a long password may be tedious on a small touchscreen. Users may be tempted to turn off the security. A “secure” password is a balancing act. Requiring a 12-character password with digits, upper- and lowercase letters, and special characters may be secure, but users will almost certainly severely compromise security in other ways if faced with those stringent requirements.
Devices
that run on Apple’s iOS offer a useful
compromise. Originally, iOS’s security was
limited to a four-digit password. This was
rightfully criticized as being far too short
and pulling from a far too limited set of
characters to be sufficiently secure (there
are, at most, 10,000 possibilities—not many
for an automated system to work through).
But the password is easy to enter and not
terribly obtrusive.
Eventually, Apple implemented two options. First, the devices now allow a “complex” pass word to be set. However, these passwords are still difficult to enter, and firms requiring them will almost certainly find users creatively solving this difficulty with methods that compromise security.
However,
another option is available. The device can
be set to wipe all data on the device after
10 failed attempts to enter either the
password or the four-digit code. When a user
has only 10 attempts to get the code right,
suddenly having 10,000 possible codes
presents a much bigger problem.
All of these settings are found in iOS 6 in the Settings application, in the General Section. The Passcode Lock setting in that section allows setting and changing these options.
Android phones are a bit more varied. One popular option is to draw the unlock code on the screen. Unfortunately, unless a user keeps the screen immaculately clean, he or she will notice that the “pattern” becomes visible quickly as a finger smudge develops across the screen that a thief could trace.
Android phones do allow the password and code options, but unfortunately there is no option to automatically wipe all data after a number of failed attempts. For an Android phone, it may make sense to use something other than a four-digit code. Android allows up to 16 digits, so some additional security is granted because a thief will not necessarily know how long the code is.
In either case, whatever is used should not be simplistic. Codes such as “1-2-3-4” or one that repeats a single digit are extremely poor codes and should never be used. Such overused codes will almost certainly be tested. The code should also not be one that can be derived from other information available about the user such as the user’s birthday or home address.
For laptops, full-disk encryption should be used on all devices. Microsoft’s BitLocker, available with recent versions of Windows, can be used for this purpose, though it is not turned on by default. Also, if the laptop does not contain a Trusted Platform Module (many less expensive ones do not), additional configuration is required to use the system. But it will provide protection. Apple offers a similar full-disk encryption option (called Filevault 2) in OS X 10.7 and 10.8 (Lion and Mountain Lion, respectively). Recent versions of Windows also come with Microsoft’s Encrypting File System for protecting specific files and folders.
Thumb drives are a bit more troublesome. BitLocker and FileVault both encrypt thumb drives, but unfortunately neither is at all cross-platform. That means the key is not readable using another operating system (an issue since a small but significant minority of CPAs’ clients use Apple systems) or in noncomputer devices (such as smartphones or tablets that have USB inputs).
A partial solution may be found in the open source TrueCrypt product ( truecrypt.org ), which provides a cross-platform solution that, in theory, could be implemented in portable devices. CPAs could create USB thumb drives encrypted with TrueCrypt, which also contain the software in an unencrypted area necessary to read the drive under both operating systems.
Public Networks
Almost all connected devices can be used on Wi-Fi networks in addition to cellular networks, and most devices default to using Wi-Fi to reduce the use of cellular network bandwidth, which is often metered, and, if it is not using 4G LTE technology, is often slower than an available Wi-Fi connection. Even if a user is not concerned about the cost or speed of the cellular network, there are many locations (especially in large buildings, such as hotels) where the cellular network will not be available and it will be the Wi-Fi network or nothing.
However, that means that data is now traveling on someone else’s network, a network being used by unknown individuals. Data traveling over a Wi-Fi network, unless encrypted, can be looked at (i.e., “sniffed”) by anyone on the network using widely available software.
Thus, CPAs need to ensure that if at all possible, data is sent over secured mechanisms. A secure connection includes websites that begin with “https://” rather than just “http://.” Frequently, a symbol that looks like a closed padlock appears in the lower-right corner of such a website to show that it is a secure connection. One potential hole may be found in a mail system. Originally, usernames and passwords (as well as the mail itself) were sent unencrypted to log in to mail systems, and some mail servers still do not support encryption, so the devices have to support both encrypted and unencrypted mail handshakes.
For iOS and Android devices, some mail systems are “known” to the devices and are generally set up securely. But unknown systems often default to an unsecure setup for compatibility—the vendors’ main concern is that the mail will work for the user, and security settings are inherently complex.
The obvious danger to sending email usernames and passwords in the clear is that someone with that information could take over the mail account and peruse its contents. That danger becomes even more of a problem since many sites use a person’s email address as a username and even default to sending a password reset link to the email address. This allows a nefarious party to take over access to other accounts, including banking and brokerage accounts or access to various other sensitive sites.
But a less obvious danger may be more significant. Even though users are cautioned not to do so, the reality is that most reuse usernames and passwords, and a significant number use the same username or password for every site and system they can. If the attacker obtains the information by watching a login to what the user considers a low-risk site (e.g., a personal email account that exists mainly to use on websites so the user’s more important email boxes do not fill up), the attacker can quietly access the other sites. At a minimum, users should consider having three different passwords for three levels of security.
For those accounts considered most at risk (e.g., brokerage and bank accounts), a series of complex passwords based on a basic code should be used. A different password, not as complicated as those used for the most sensitive accounts, should be used for accounts where there is some level of security or protection from loss such as store accounts linked to a credit card. A third, fairly simple, password should be used for accounts where access by outsiders might be worrisome or a bother, but the ability of the outsider to harm you financially or professionally is limited. Of course, many online accounts may require the use of certain characteristics and characters, so it would be a good idea to incorporate these characteristics into basic password patterns.
A practical option may be password management systems, such as RoboForm or LastPass. These systems allow the use of a single complex password to “unlock” a vault of unique passwords for each site that can be automatically filled in when a user visits each site. That system eliminates the risk of having a single breach open up the user to losing control of all the sites using that same password. However, securing that single main password is obviously key. Similarly, the underlying security of the password manager is an issue, especially since many of these sites offer access on the cloud or use a cloud-based system to allow use with multiple devices.
Finally, an increasing number of sites offer two-factor authentication options. In such cases, a user logging in needs to provide not only the password but also a unique code. That code may be sent to the user’s cellphone by short message service (SMS) when the login attempt begins, or it can be automatically generated by a small device carried by the user or via an application loaded on the user’s phone. Google and most banks offer these services for their sites, though it may take some research to find how to turn on the option. The key advantage here is that someone without the small device or smartphone will not be able to give the code needed to gain access, even if the person has the password.
Fake Certificates
Another risk involves how data is securely transmitted over the internet. Almost all security protocols revolve around public key authentication systems. Those systems use an interesting encryption system where one key is used to encrypt the data and a second key must be used to decrypt it. Someone possessing only the encryption key cannot decrypt the message—the user must have the second key. And the keys can be used interchangeably—but something encrypted with one must be decrypted with the second.
When a user accesses a secure site, these keys are used. The site gives the user the first key (known as the “public key”), and the machine uses that key to encrypt what it transmits to the other machine. Anyone “snooping” is out of luck, since the snooper would lack the second key needed to unscramble the data—that is being held by the site, and is called the “private key” in this system.
But how does a user know that it really was, say, Amazon that sent out the key and not someone posing as Amazon? That depends on a second use of this technology. The site sends the user a certificate that is “signed” (effectively encrypted) with a key given to it by another entity, known as a certificate authority. The computer’s operating system and/or browser comes with a set of preinstalled keys for authorities that the OS or browser vendor treats as trusted. The user’s browser checks the source of the certificate against a list of trusted sources and, if it is found in the list, uses the key to verify the signature’s validity. If it is verified, then the user’s computer accepts that the user has truly gotten to Amazon, relying on the fact that the signature checked out and the certificate is not expired and is tied to the site in question (both of which are contained as part of the certificate).
What happens if your browser does not find the authority in the list, or the certificate otherwise is not verified? The system warns the user about the flawed certificate and asks what to do. Users discover that if they reject the certificate, they lose access to the site and cannot do whatever they were looking to do. However, if they decide to accept it, unfortunately, the browser assumes the user must know what he or she is doing and that the user knows that he or she really is talking to the proper site, so the browser stops complaining and allows the connection. The hitch is that what may have happened is that the user is being redirected to a fake site or a third party now has inserted himself or herself into the middle of the conversation with the other site.
Especially on public networks, users need to be suspicious if they get a certificate error. Users should be trained to allow a bad certificate only if they are absolutely certain that they are not being compromised. While certificate problems do sometimes occur for innocent reasons (sites sometimes forget to renew certificates when they expire), it is important to understand the implications of accepting a questioned certificate.
CPAs’ Safeguarding Responsibilities
This column highlights only a few of the potential issues facing CPAs in securing data with mobile devices, but it certainly represents the basics every CPA needs to understand. CPAs are responsible for safeguarding their clients’ information, and that means they need to take responsibility for understanding the risks inherent in the tools that they use.
| EditorNotes | |
| Steven Holub is a national director in the Professional Practice Department of Cherry Bekaert LLP in Tampa, Fla., and is a former chairman of the AICPA Tax Division Tax Practice Management Committee. Kenneth Parker is with Parker and Associates, CPAs, in Jackson, Miss. Edward Zollars is a partner with Thomas, Zollars & Lynch Ltd. in Phoenix. Mr. Parker is chairman and Mr. Zollars is a member of the AICPA Tax Practice Management Committee. For more information about “Mobile Information Security Concerns,” contact Mr. Zollars at edzollars@thomaszollars lynch.com. |
