Chapter 2, Security Considerations for Small Businesses
This lesson presents some material from chapter 2.
Objectives important to this lesson:
From storefronts to the web
Becoming an e-business
Web hosting security and availability
Risks, threats, and vulnerabilities
Payment risks
Risks related to employees working remotely
Concepts:
Chapter 2
Chapter 2 begins with a reminder that there were electronic
transactions before the World Wide Web demanded a standard. They were
primarily for business entities and banks, however, so they did not
have the almost universal appeal that web transactions have for the
average consumer.
The text proceeds with a short discussion of three phases of
the evolution of e-commerce:
brick-and-mortar model
- This phrase, in case you don't know, rrefers to stores having physical
locations, presumably made of brick and mortar. Many brick-and-mortar
institutions have offered their products by mail for centuries,
although this was not always an option for every business. The text
describes the early days of the web as having many sites that presented
the equivalent of catalog pages
to the viewer. The author makes a good analogy, saying the websites
were like display windows for the store, and the goal was to cause the
customer to be interested enough to travel to the actual store to make
a purchase. Customer information was not typically collected because
transactions did not take place over the web at this time. I recall a
particular store that suggested that I would be safe filling out a form
on their site, including my credit card information. I was assured that
nothing had happened to any of their customers.This was in the early
1990s. Maybe the odds were in the customers' favor at that time.
customer focused e-commerce
- The next phase asked for customer infoormation as soon as a potential
customer entered a website, requesting that the viewer subscribe to
notifications about site updates, to newsletters about the site, and to
coupon related emails that are meant to keep the customer in contact
with the site. Advertisements and offers would appear in the viewers'
in
boxes not just from the site owner, but from advertisers who pay for
access to the website's information about customers. In addition to
asking, many sites simply placed cookies (tokens) on the site viewers'
devices, adding tracking information that was also marketable to other
retailers. It is useful to know that a customer has been to your site
before, what they seemed to want, and what they came for today. The
vendors placing such information on the clients' devices in ways that
anyone might view led to more concerns about security.
distributed e-commerce
- The text tells us that we are approachhing a state where advertisers
will be watching where we go, what we do, what we watch, and so on, to
make offers of products and services based on their perception of our
desires, as well as our statements about preferences. I have
noticed more ads lately, on blogs and news sites, based on
products that I have browsed on commercial sites. It begins to feel a
bit like this scene in Minority Report.
As you might imagine, the situation below is a security nightmare.
The text changes its point of view in the next several pages,
telling us about business goals that present security challenges to IT
security professionals. We are shown each item through the eyes of the
business operator.
basic announcement of our
services - We should not forget that a web presence can exist to
allow the business to be found.
Not so long ago, there were telephone books that were used by
practically everyone to find potential vendors of any product or
service. I am ashamed to call the puny directory that was delivered to
my mailbox this year a copy of the Yellow Pages.
It made perfect sense to advertise in Yellow Page directories (yes,
paper reference books like these were called directories) when everyone
who had a phone was going to use them. It makes sense now to place your
information on the web, because anyone looking for services is probably
going to search the Internet for them.
becoming an e-business
- If your customers are going to browse your catalog and order
products, why not check your inventory database for the products,
update it from the order, send information to the sales and shipping
database, and so on? The text also points out the advantage to posting
current information and prices on the website. This brings up a point
that no one seems to make: If you are going to post product information
and prices, put a date range
on them. Make sure the information is clearly marked as having been posted on a specific date, and that
it is expiring on a specific
date. We can't run a sale forever!
building sites that are
highly available and secure - The text only addresses the
availability portion of this bullet point. We should remember that
everything has down time, and that all hardware fails eventually, so we
need to address "high availability" by making sure of redundant
components and clustered services. The text does not deal with a
technical approach on this page, but it is worth considering that the
business need for 100% up time requires a heavily technical solution.
The business need is to be always open for our customers.
Later in the chapter, the text lists some other causes of down time:
viruses, hacker attacks, failures from our ISP or web hosting service,
power outages, and natural disasters. We can't survive these things if
we do not plan for them.
customer service on an
e-business site - The text presents technical needs based on
business desires: keep the customers on the site longer by chatting
with them, by giving them access to their order information, by letting
them tell us how happy they are (or aren't). Make it easy for customers
to like us on social network sites, which may draw more customers to
us. The text lists some ideas about making customers happier:
Make your site searchable.
Note that I have a search function for mine my home page. It is not
hard to do.
Videos are
usually better than text articles. Make the right choice where you can.
If customers need training, show
them how to do whatever it is.
Troubleshoot and refine your process to check out
(make purchases). The text warns us that many customer problems are
about this process.
The text recommends that we ask for feedback with surveys, forms, and
email. If you do this, get advice from someone who knows how to conduct a survey/write
a form/ask for advice. I have lost count of the number of times I have
filled out a survey only to realize that I hated the entity the survey
was about much more after the survey than before it.
Don't make your customers hate you (or hate you more)!
The text also warns us that full two-way communication
with customers (such as help desk calls) cost more than any other kind of support.
Do it right, but do all the things above right first. That will reduce the number
of hours your staff have to spend on the phone, in chat, etc.
add to our customer list
- Make the customer happy
enough with our site to sign up to be a repeat customer. A lot of websites
get this wrong: don't ask the customer to give us a glowing rating or
to sign up to hear from us daily before we have "wowed" them. Asking
people to become members of our club is ridiculous if they don't have a
reason to love us. Give them a reason, then
ask for their devotion! The page designers seem to think people will
love our sites in the first five seconds of being on them. That is most
unlikely. The text presents three phases of Customer Life-cycle Management (CLM):
acquistion -
Bring people to our site. This may mean that we must advertise on other
sites.
conversion - Turn
visitors into customers. This means having good products, effectives
sales techniques, and secure functions to capture and use customer
information.
retention - Turn
customers into repeat customers. Once they have given us information,
give the customers options about saving it, storing it, allowing it to
be used to our (and their) advantage. Tell the customers the truth
about our data policies, and help them to feel good about them.
Let's move to the major topic on page 37, threats, risks, and
vulnerabilities. The author begins this section with a reminder to
follow the CIA triad: provide confidentiality, integrity, and
availability. To do so, he proposes that we start with the following
features:
authentication -
make sure the users are who we think they
are
authorization -
only allow a user to access what they
should access
encryption - hide
information from eyes that are not
authorized to see it (No, we don't expect it to be stolen, but what if
theft happens anyway?)
auditing - track
what happens and who does it, which takes
us back to authentication
The text continues with the observation that private networks
can be very secure, but public
ones are not. We must do what
we can
with traffic that comes to us from the Internet, and with traffic that
we pass along it. George Martin has it right.
The text reminds us that web sites can fail due to poor
design, poor
check out processes, and poor visitor tracking. More useful to us is
the following section about attacks that web sites are likely to see:
denial of service attacks - knocking us off the Internet
keeps us from conducting the business we intend and need to have
data theft and unauthorized access - actual theft of files
or access to and use of information in them violates the trust we have
in our own data
site alteration - violating our site integrity is bad
enough, but changes to our site by an enemy can range from
embarrassment to ruin
virus problems - infection of our site, or spreading a
virus to our users
On page 40, the text begins a short section about problems
relating to handling payments. It begins with a very short message:
unless you have been given permission to make a transaction public,
assume it should only be seen by those who participated in it. In the
case of payments. that may
extend to actual accountingstaff or
accounting processes, but
certainly not to anyone not involved in
processing the payment.
There is an exception
to this principle that the text does not
address. I recall with a certain amount of ironic fondness the days
just before and just after I became an IT professional. I was already a
state employee in another profession. Having attained a level of
knowledge and college education, I changed professions. In my first
profession, I was forbidden to enter the accounting department in the
building where I worked. I had no authorization to be there. When I
became an IT professional, I was often welcomed into that area as a
person
with business in it. I might be repairing hardware, installing
software, or gathering information to write a program. In any case, I
had access to systems that I previously did not. IT staff are often
given access to hardware, software, data, and more that they have no direct use for. We do not take in
money or issue it, but we run the machines and programs that do. We
have indirect
use for those assets because they are part of the systems we operate.
As such, we have an obligation to maintain the confidentiality of
anything we see, anything we must
see, that does not relate to our duties, but does relate to the duties
of the people we support.
Going back to the text, page 40 lists four major steps in a
payment transaction involving a credit/charge/debit card:
The cardholder
sends the card number to the vendor. This must be done with a
secure process, as must all the steps that follow.
The vendor
requests authorization fromvendor's bank/credit
institution to place a charge against the card.
The vendor's
bank sends the vendor's request (as their own) to the bank/credit
institution that the card represents.
The card issuing
institution generates an approval
or a denial, which makes its
way to the vendor's bank,
the vendor, and the cardholder.
It's actually amazing that it goes so quickly. This process is
different when the customer is using an electronic wallet or electronic
cash, both of which require a preliminary purchase by the customer
which converts "real" cash to electronic cash, which is then stored on a
server or on a smart card. (See page 41.)
The text moves on to address web applications, which we are
told inherit the vulnerabilities of the servers and operating systems on
which they run.
The text recommends updating firmware on such systems,
which is typically a manual process that begins with regularly checking
to see if there are any updates for your systems.
The text also makes the usual recommendations about
updating and patching operating system software and applications.
Security updates are issued for operating systems, major productivity
applications, and major browsers frequently.
Applications that are not major apps can also be updated.
Home grown software, written by developers in your own organization, is
an example of software that may be more at risk. The text cautions us
to watch for SQL injections, the entry of SQL commands in web forms,
which should be something that the application programmer prevents from
happening. The text also mentions injection of data that would crash a
program or cause a buffer overflow, potentially allowing the attacker
to execute code they should not be allowed to execute.
As you might gather, the author believes that there are
problems on most systems that will put us at risk. He takes us into a
discussion of network protocols to recommend the use of secure
protocols wherever possible. The discussion begins by giving us some
history on the TCP and IP protocols. IP
(Internet Protocol) provides
unique addresses for devices on a network, and also provides a service
to find routes from one device to another. TCP (Transmission
Control Protocol) provides guaranteed, acknowledged delivery of
data. Considered together as the key elements of a software suite, TCP/IP is what makes most networks
work. The TCP/IP suite contains lots of other protocols that do many
things on networks. These protocols work. The problem is that many of
these protocols are not secure. Page 45 presents a table of standard
protocols. Each is followed by a more secure protocol that should be
used in its place. The chart actually has two older protocols that have
both been replaced by a single one, so the shading of older ones and
lack of shading of more secure ones ceases to be a reading aid after
Telnet. Let's try our own version:
Old
Protocol
Replacement
Protocol
FTP - File Transfer Protocol
SFTP - Secure File Transfer Protocol
HTTP - Hypertext Transfer Protocol
HTTPS - Hypertext Transfer Protocol
Secure
Telnet - Teletype Network (connect
to a remote system)
SSH - Secure Shell (allows a secure
connection to the remote device)
rsh - Unix protocol to runs a Remote
Shell
RCP - Remote Copy Protocol
SCP - Secure Copy Protocol
SNMPv1 and v2 - Simple Network Management
Protocol
SNMPv3 - Simple Network Management
Protocol; this version allows encryption and authentication
The chart does not address the discussion of IPSec, which is
another set of protocols that are used to encrypt IP transmissions. The following video is more enlightening.
On page 46, the author lists five kinds of attacks that IPSec is helpful in defending against.
eavesdropping - IPSec encrypts the the transmissions, so eavesdropping is less effective.
address spoofing - IPSec makes it less likely that a faked IP address will work by requiring mutual authentication.
man-in-the-middle attack - IPSec establishes a session
between the intended nodes, making it less likely that a
man-in-the-middle attack can succeed.
denial-of-service attack - Windows servers can filter out traffic that is not using IPSec encryption.
sniffer attack - Like other attacks that intercept packets, IPSec encryption can make sniffer attacks less relevant.
The text offers some suggestions about precautions to take
before applying patches and service packs. Sometimes they cause things
to go wrong on your system, so it is best to make a backup before
taking a chance that everything will go well. Take some baseline
measurement on your systems before and after patches to determine the
relative effect of those patches.
The chapter ends with a discussion about VPNs. All Virtual Private Networks
include encryption of data passed across what is an otherwise standard
connection across a public network. The text recommends using VPNs that
use PPTP, L2TP, or IPSec. Note that a VPN connection requires a VPN client, a VPN server, a transmission medium (which the text incorrectly calls a transmission media), and VPN protocols.
Assignments
Continue the reading assignments for the course.
Download the handouts file for this module.
Complete the assignment and class discussion made in
this module.