A web server is a software program that monitors a specific port, normally port 80 or 443, for web requests and provides content for a web client. Web servers support many types of requests and apply various protocols to respond to requests. The two most common protocols that web servers use for normal web traffic are the Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure (HTTPS). The web server receives a message from the inbound port in the form of a request that includes a uniform resource locator (URL). The URL contains information for the web server to know how to handle the request.

For example, suppose you are running a web server at the address www.MicrosoftApplicationSecurityChapter12.com. Your web server may receive a URL that looks like this:

http://www.MicrosoftApplicationSecurityChapter12.com/scripts/wsisa.dll/WService=catlookup?isbn=076372677X

TABLE 12-4 describes the individual parts of a URL.

The web server receives the message and evaluates the web server command. The web server command tells the web server what to do. If your web server executes a command without taking any precautions, any anonymous user can tell it to do many malicious things, such as return private data, delete files, or shut down the server. Any of these actions would violate the server’s security.

Since you don’t want any web server blindly executing commands, you need to restrict what the web server accepts and what it can do. Make a web server more secure by following a few simple strategies. TABLE 12-5 lists some of the main strategies for securing any web server.

The strategies in Table 12-5 represent a few of the tasks necessary to fully secure a web server. Since web servers are often exposed to the Internet and provide an interface into your network, they are attractive targets. Make sure you spend the time securing each web server you deploy.

Microsoft’s web server, Internet Information Services (IIS), has long been a familiar component in Windows environments. The latest version of IIS that ships with Windows Server represents Microsoft’s most secure web server to date. Microsoft learned many lessons from previous versions of IIS and made the latest version secure from the beginning. If you take the time to install IIS with only the options you need, it doesn’t require much additional work to create a secure web server.

The starting point for installing IIS is a computer with Windows Server installed. Install IIS to a standard Windows server or a Windows Core Server installation. You’ll learn about adding IIS to a standard server in this chapter. You install IIS by adding an additional role to the server.

FIGURE 12-2 shows the Add Roles Wizard windows for adding the Web Server (IIS) role to Windows Server 2019.

Notice in Figure 12-2 that Windows provides several resources to help you add IIS to your server. Read through an overview of the role services included with IIS. These services allow you to pick and choose just the services your web server needs to run your websites and applications. This saves you the time and effort of having to disable unneeded services after installation. Microsoft also provides detailed checklists to help you install IIS with the features and security you want. After reviewing the help and documentation, proceed to the role services selection window.

FIGURE 12-3 shows the Select Role Services window for adding the Web Server (IIS) role to Windows Server 2019.

Windows lets you select the services your web server will need before it installs anything. This is the step that can make your web server lean and secure. Carefully review each selection before checking any box. Once you have all of the desired services selected, continue installing IIS. Although IIS installs in a fairly secure state, you should still review the server and the web server software to ensure the highest level of security possible.

Another common server you’ll find in many organizations is an email server. Microsoft’s email server is Microsoft Exchange Server. An email server provides mail services to clients. Clients connect to the email server and either receive email messages from the server or send email messages to the server. One connection could include both operations. Clients can either download messages to read locally or read messages directly from the email server. If you allow it, each client can choose between remote or local message storage.

When considering email server security, cover all three properties of the C-I-A triad. Your email server must be available. One of the most frustrating situations for users to encounter is an email server that is unavailable. Email is such an integral part of daily tasks that access to it is expected. Your email server must also ensure private messages are private and no message changes in transit. While the confidentiality and integrity properties are important for some messages, the overhead generally doesn’t warrant securing all messages.

It is important to secure all email that is stored on your email server. Your email server may store messages for very short periods of time or for months, or even years. Double-check that both your email server software and the operating system protect email message data using file, folder, or drive encryption. Since many people rely on the practice of storing email messages on the email server, have a solid disaster recovery plan (DRP) and business continuity plan (BCP). These plans protect your email in case of data loss.

Unlike IIS, Exchange Server is a separate commercial product. Once you purchase a license, you can acquire and install Exchange Server on your Windows Server computer. During installation, you specify many of the characteristics to secure your email server. Exchange Server allows you to select from several roles that define whether the server will store messages, provide client access to messages, transport messages to other email servers, or even perform a combination of roles. The specific role your email server plays tells the installation process how to configure the software for the most functionality and highest security.

An email server must deal with several vulnerabilities to support secure email exchange. When securing an email server, address these issues:

• Limit operating system logons and administrator rights—Only a limited number of user accounts should have administrator access to the email server computers.

• Enforce strong email user authentication—Require strong authentication for all email clients.

• Use encrypted connections for all communication between Exchange servers—This is the default behavior.

• Enable only the protocols your email clients require—Post Office Protocol version 3 (POP3) and Internet Message Access Protocol 4 (IMAP4) are older protocols and are disabled by default. Enable them if necessary, but Exchange allows these connections only if they are encrypted.

• Patch all Exchange Server instances—Frequently check for security updates and install them to all your Exchange servers.

• Use anti-malware software on each server—Windows Defender is just one option that is available.

• Encrypt folders or drives that store email messages—Use EFS or BitLocker.

• Plan for high availability—Develop a solid BCP and DRP that ensure maximum uptime.

Email servers are frequent participants in spreading malware. Good anti-malware software, along with strong access controls, can reduce the potential for your email server spreading malware. Requiring encryption of all connections will greatly increase the overall security of messages exchanged within your organization. Remember that messages that travel outside your organization are not encrypted by default. It is the responsibility of the email clients to agree and encrypt messages. Microsoft Exchange Server goes a long way toward ensuring your email messages are as secure as possible.

Nearly every application needs some type of stored data on which to operate. Some applications use their own internal data storage techniques. The majority of applications use separate database management products to store data. Application developers write application software that interfaces with one or more databases to maintain the data each application needs. Today’s databases are getting larger. It is not uncommon to see database sizes in excess of many terabytes. As applications rely on database management systems more and more to provide access to data, organizations are isolating databases on separate servers. These specially configured database servers are efficient platforms for applications and attractive targets for attackers.

Database management systems routinely store application data for rapid and secure retrieval on demand. Databases can store private and public data. They handle each type of data differently. Separating all of an organization’s data to a database server gives the organization greater control over how to secure those data. Securing a database, like securing any other server software, depends on a secure operating system first. After the basic security needs of the underlying platform have been addressed, databases can help ensure the confidentiality, integrity, and availability of stored data.

Current database management systems have several options and strategies to provide maximum availability. Take frequent backups, archive transactions logs, or implement data replication. Most current database products also provide configuration options that are specific to high availability. One configuration option is using failover clustering to protect from hardware failure. Regardless of the options you choose, research your database management system’s capabilities and deploy the configuration that fits your budget and provides the greatest availability.

The ability of a database management system to provide confidentiality and integrity depends on the quality of the authentication, access controls, and query preprocessing. First, use strong authentication for all database queries. In the database world, a query is any statement that accesses data. A query can read, write, create, or delete data. Each query requests access to data on behalf of a specific user or process. Enforce unique user accounts and strong authentication. Legacy database applications often allowed generic user accounts that multiple users shared. While this practice is acceptable for public data, it is not acceptable for databases that contain sensitive data. Do not allow this practice for databases that contain sensitive data. Each user should have a unique account. Unique user accounts make it possible to grant access privileges to specific users and audit activity more precisely. Just as with hardening the operating system, require the strongest authentication method your clients support.

The next security property is confidentiality. Database management systems use encryption to support confidentiality. To make database access as secure as possible, enforce encrypted connections any time you transfer private data. You can enforce this using VPNs or individual connection encryption. Make sure no private data are transmitting in the clear.

Databases also use encryption to store data. Data at rest have several different encryption options. This list of options includes:

• EFS or BitLocker—Although encrypting a file, folder, or volume does store data in an encrypted format, most database administrators prefer more granular control over what gets encrypted. Encrypting data at the operating system level may lead to far more data being encrypted than what an organization needs.

• Transparent Data Encryption (TDE)—Current database management systems generally offer an option to encrypt either selected database objects or even an entire database. TDE encrypts all data without requiring any user or application action.

• Application encryption—The most fine-grained control is for the application to decide what data to store encrypted and carry out the encryption process directly. This last option provides the most control over encrypted data but at the cost of substantial software development effort.

The last major security property that database management systems protect is data integrity. Although database vendors go to great lengths to ensure internal data integrity, integrity in a security context has a slightly different meaning. To support both confidentiality and integrity, database management systems make certain that no unauthorized user can view or modify data. To enforce these two properties, the database management system must know the identity of the user who submitted the query. Positive identification and authentication provide a trusted user account. The next step is to authorize a user to carry out a data operation. Most of the commercial database management systems support the Structured Query Language (SQL) to access data in a database. SQL defines a security model that grants or revokes access privileges to specific pieces of data. The database management system evaluates each field, or column of data, based on the permissions defined for the current user.

SQL security is quite good. The problem is that it can be cumbersome to manage. SQL security is based on users, and granting data access to anonymous users can allow anyone to access your data. As long as you have unique user accounts, you can secure data in your database at a very detailed level. Doing so requires substantial effort in verifying that all permissions are current and accurate.

One common problem arises with storing secure data in a database. Most database products interpret SQL queries at run time. In other words, the query statement isn’t evaluated until it is time to execute the statement. Many attackers have learned how to trick the database query processor into doing more than intended. It is possible to add SQL statements to input data, and if an attacker is crafty and careful, he or she can make a database server respond to nearly any command. Adding SQL statements to data for the purpose of sending commands to a database management system is called SQL injection.

The best defense against an SQL injection attack is to validate all input before sending it to the SQL query processor. Have your client application validate each input field to ensure it meets your input standards, but make your server validate input as well. Recall that man-in-the-middle attacks sometimes use proxy servers. They also use these servers in injection attacks. If an attacker can intercept network traffic, he or she can also modify the traffic. That means a computer criminal can modify any data that already passed validation on the client. For that reason, never trust data from a client—always validate all input on the server. By validating all input, your database server can detect and remove illegal input such as injected SQL statements.

Keeping all these points in mind, here are the general steps to securing a database server:

• Secure the operating system—Always start with a secure operating platform.

• Install the latest patches—Check that you have the latest security patches and develop a plan to acquire and install all released patches.

• Require strong authentication—Require authentication of all users before processing a query and force the strongest authentication method your clients can support.

• Use separate user accounts for database administration—These are separate system administrators, database administrators, and database user accounts.

• Install only necessary components—Do not install database services or components you don’t need. Review the installation process and remove unneeded components.

• Remove or disable default users—Most database management systems install default user accounts. Attackers know which default users exist in most databases. Remove or disable all of these default accounts.

• Use auditing—Enable auditing for failed logon attempts and possibly access to critical data. Be aware that auditing any data access can create a large number of log entries.

• Change default ports—Never use the default ports to access database services. Attackers know these default ports. Select alternate ports for all database accesses.

• Revoke any developer access to production environments—Developers should have access only to development and testing environments.

• Encrypt private data—Select an encryption method that secures private data.

• Develop and maintain plans for business continuity and disaster recovery—Plan for disruptions and know how to minimize your downtime.

• Validate all input—Never evaluate a database query without validating the query first to ensure that no extra data are in the query.

• Monitor performance—Monitor how well the database is executing queries and be prepared to respond if performance degrades.

Enterprise Resource Planning (ERP) software is an integrated collection of software programs. It manages many aspects of a business, including finances, human resources, assets, and business processes. ERP software generally serves to unite different users and organizational units by sharing and combining data. ERP software provides centralized data storage and functional software capabilities that streamline business processes.

The security concern of ERP software is that a large portion of an organization’s data is centralized. Most, if not all, of the users in the organization access the ERP software as part of their normal business function. That means many users have access to the application and the database. Each software vendor provides specific recommendations for its product, but many strategies to secure ERP software are common among vendors. Follow these guidelines to secure any ERP software application:

• Create unique user accounts—Securing shared data depends on uniquely identifying users. Don’t allow users to share accounts.

• Enforce strong authentication—Since data security depends on user- or group-based authorization, choose the strongest authentication type your application allows.

• Restrict access to application components—Use application security options to restrict function access by user or group.

• Develop ERP acceptable use policy (AUP)—Develop AUPs for the ERP software. Train all users on current AUPs.

• Secure workstations—Follow recommendations for securing any workstation that accesses your ERP application.

• Require encrypted connections—Require secure VPN or other encrypted connection to access the ERP application.

ERP applications address mostly generic business needs. Some organizations have specific business processes that are unique to their market or organization. Many organizations either develop or acquire specialized application software to help them conduct business. Software applications that are specific to a particular process in an organization are called line of business (LOB) software. For example, LOB software can include any of these applications:

• Enterprise project management

• Workflow control

• Service technician tracking and scheduling

LOB software isn’t necessarily unique to an organization, but it isn’t needed by all organizations. The security concerns are the same ones as with ERP applications. The workforce depends on the application’s operation and the data’s security. The application must be available, responsive, and dependable. Follow the same recommendations as in the ERP application section, and you’ll have a secure LOB application.

Most of the application software you have seen so far are on-premises applications. That means they are installed on your computers. Traditionally, that’s the way organizations used applications. You purchase a license for software or write it yourself, and then install and use that software in your organization. That model has already changed. While on-premises software still exists and is in use, more and more enterprise software is cloud-based. Microsoft is a leader in providing cloud-based services to meet enterprise and individual user needs. Microsoft’s three leading cloud-based products are Microsoft Office 365, Microsoft Azure, and Microsoft OneDrive. Each of these software offerings target different users, but provide services that are all based on Microsoft’s cloud.

When it comes to securing cloud-based applications, many of the issues are the same as the on-premises issues you’ve already seen. Even when you use cloud-based software, you should review the options and settings and configure the software to run the way you need it to run. Don’t assume that cloud-based software is secure by default. It isn’t. You still have to harden software, regardless where it runs.