ITS 4050 - Internet and Web Security

Chapter 2, Security Considerations for Small Businesses

This lesson presents some material from chapter 2. Objectives important to this lesson:

1. From storefronts to the web
2. Becoming an e-business
   
3. Web hosting security and availability
   
4. Risks, threats, and vulnerabilities
5. Payment risks
6. 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:
• Have a good, useful FAQ page.
• Provide downloadable manuals for products.
• Don't make web pages that suck.
• 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 accounting staff 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:

1. The cardholder sends the card number to the vendor. This must be done with a secure process, as must all the steps that follow.
   
2. The vendor requests authorization from vendor's bank/credit institution to place a charge against the card.
3. The vendor's bank sends the vendor's request (as their own) to the bank/credit institution that the card represents.
4. 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:

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.