We live in an age where high-profile attacks on data are almost commonplace. Attacks can come from a variety of sources, ranging from cyber-terrorism and modern warfare through to industrial espionage, the “geek” factor, organized crime, and even disgruntled employees, or former employees. In addition, DBAs (Database Administrators) must often consider security from regulatory perspective, with many companies required to comply with SOX (The Sarbanes–Oxley Act in the US) or GDPR (General Data Protection Regulation in the European Union). For these reasons, security is at the forefront of every good DBA’s minds.
In this chapter, we will explore how to model threats, so that risks can be identified, understood, and prioritized. This will lead us into discussing some high-level countermeasures. We will also introduce compliance and discuss the potential impacts on your SQL Server security model.
When considering security, we must also consider ethics. When we see the word “hacker” in the media, it instantly conjures a negative connotation. For those with knowledge of the security industry, however, hackers can be broken down into three categories: black hat, grey hat, and white hat. A black hat hacker is the typical hacker that you will hear about in the mainstream media. He will attempt to penetrate systems and use the attack for his self-gain.
The activities of a grey-hat hacker are still illegal, but slightly less malicious. A grey-hat will attempt to crack a system and then inform the organization of the vulnerabilities found. Often, the grey-hat will demand financial compensation for his discoveries and publish the vulnerability on the internet if his demands are not met.
In contrast, a white-hat hacker will be employed by an organization to attack the organization’s systems in an attempt to find vulnerabilities, so that appropriate countermeasures or risk mitigation strategies can be put in place. This activity is, of course, perfectly legal and ethical.
In the first section of this book, we will focus purely on how to secure SQL Server 2017 by implementing the security technologies provided by Microsoft. In the second section, however, we will examine how attackers will attempt to penetrate SQL Server’s security model for malicious purposes and how to overcome these attacks.
There may be an ethical argument that exposing the methods used by attackers could assist black-hat and grey-hat attackers. The assumption needs to be made, however, that an experienced or determined attacker will either already know of the vulnerabilities or be able to discover them. The most benefit in discussing attack methodologies comes to the conscientious DBA who needs to understand how security can be circumvented in order to harden their applications and platform. Without any context as to how poor practice can lead to security holes, it is often hard for a DBA to understand how security technologies should be implemented in their own environment, which in turn can lead to security holes.
Threat Modeling
All RDBMS (Relational Database Management Systems) have the potential to be exploited with SQL Injection attacks (a full discussion of SQL Injection attacks can be found in Chapter 10), as well as vulnerabilities that are unique to each product. For example, attackers will often attempt to gain elevated access to Oracle by attempting to use default user passwords. While this risk can be mitigated with due diligence, with around 600 default user/passwords, it can be hard for Oracle DBAs to ensure that no stone is left unturned.
In SQL Server, a common attack is to attempt to brute force attack the sa account, on Port 1433. While the sa account can be disabled, or have its name changed, the majority of SQL Server DBAs do not do this, and in many cases, there are poorly written client applications that require an sa account to be present.
In the following sections, we will explore how to perform threat modeling so that the highest priority threats can be identified, and countermeasures taken.
Understanding Threat Modeling
Because every database management platform is vulnerable to many potential threats, it is important to undergo a process of threat modeling in order to mitigate the risks. Threat modeling is the process of identifying threats to a data-tier application (or, in some instances, the entire enterprise) and then classify and rate the threats that have been discovered, in order to determine the most critical to address. You will then be in a position to determine the correct countermeasures in order to mitigate the risks.
In an ideal world, threat modeling should be carried out during the design phase of a project and at the very least at the testing stage. There will already be Enterprise standards and policies in place, for the Enterprise as a whole, and you can ensure that the platform you are constructing meets these standards.
In the real world, however, this often does not happen, due to time or budgetary constraints. Often, there are also no Enterprise standards—specifically for database platforms—against which you can baseline your data-tier. Unfortunately, just like comprehensive backup strategies, many companies and individuals do not put an emphasis on security until it is too late.
Even in companies that have rigorous security management policies, the focus tends to be avoiding external attacks (attacks from sources external to the company) whereas it is estimated that 70% of security breaches are internal (attacks originating from sources within the company network). This is due to employees with malicious intent, employees who unintentionally misuse systems, and also from the theft of employees’ laptops or other devices. Therefore, it is important that companies focus on identifying the risks of attacks from inside their network, as well as outside.
- 1.
Identifying assets
- 2.
Creating an architecture overview
- 3.
Building a security profile
- 4.
Identifying the threats
- 5.
Documenting the threats
- 6.
Rating and prioritizing the threats
Tip
Threat modeling allows you to design and build countermeasures. Building the countermeasures, however, is not part of the threat modeling process. Instead, the countermeasures will be implemented as a separate process.
The following sections will discuss how to perform threat analysis using a fictional application called CarterSecureSafe, which belongs to the fictional company CarterSecurityTools.com and consists of a simple Web application, where customers can shop for security software. The back end of the Web application is a database hosted in a SQL Server instance.
Identifying Assets
The first step in the threat modeling process is to identify valuable assets. From the perspective of the DBA, identifying the valuable assets that must be protected consists of identifying the company confidential information that would have a commercial impact if it were lost (unavailable) or stolen. For example, a high-profile attack against an entertainment company reportedly saw the theft of roughly 76 million user accounts, leading to a cost of around $176 million.
DBAs should look to ensure that customer data, financial data, and sales data are especially secure. Remember that financial repercussions could occur, not just in tangible ways, such as through fines from regulators, or in compensation to customers but also in intangible ways, such as the loss of business reputation, reduced staff morale, or customers moving their business to a rival.
Creating an Architecture Overview
Creating an architecture overview consists of defining the logical architecture of the application and expressing it in diagrammatic form, along with the technology stack that will be (or has already been) used to implement the application. This will help you identify areas of the end-to-end application that are potentially vulnerable, as well as identify any technology-specific vulnerabilities.
Creating the Infrastructure Components
Architecture diagram
Tip
In a real architecture diagram, you will label servers with their name and IP address, as opposed to a description of their usage.
The diagram shows that the application is accessed by both internal and external users. Internal users authenticate to the application server through Active Directory, while external users authenticate through a Web Server, which is located in the company’s DMZ (demilitarized zone).
Note
As well as indicating the servers that are directly used by the application (web server, application server, and database server), we have also included infrastructure touch points—namely, the corporate firewalls that traffic will pass through, the DC (domain controller) used to authenticate internal users and the isolated DMZ, within the domain.
Identifying the Technology Stack
Technology Implementations
Technology | Topology Component | Details |
|---|---|---|
Active Directory (AD) | Authentication | Used to authenticate internal users and administrative teams |
Domain Controller (DC) | Authentication | Server used by AD authenticate users |
Demilitarized Zone (DMZ) | Networking | Subnet that exposes external-facing services |
Domain | Networking | A logical container of users, groups, workstations, servers, and other objects, whose authentication is controlled by a Domain Controller |
IIS | Web Server | Used to authenticate external users and pass traffic to the application server |
.NET | Core Application & Authentication | The core web application has been built using the .NET framework. It also provides forms authentication for internal users. |
SQL Server 2016 | Database Tier | The databases that drive the application are stored and managed on a SQL Server 2016 instance. |
IPsec | Cryptography | Data is encrypted in transit, between the application and database server, using IPsec. |
HTTPS | Protocol | External users access the web application via HTTPS. |
For a DBA, it can be very easy and natural to focus entirely on the SQL Server instance and its direct connections, but it is also important to understand the holistic application and platform, in order to secure and test the data-tier application appropriately.
Creating a Security Profile
When creating a security profile, you will begin to identify data flows, which will, in turn, allow you to define trust boundaries and entry points. The CarterSecureSafe application is a simple solution that has two distinct flows of data.
The first of these flows is when an internet user orders an item from the store. The second is from internal users, who need to update the status of customer’s orders and perform other administrative sales and management tasks, such as reporting on sales trends.
Therefore, there are two clear data paths: first, from the internet, via the web server, through the application server, to the SQL Server instance; second, via the application server, into the SQL Server instance, but originating from within the internal network.
Tip
The CarterSecureSafe application is very simple, but for more complex data paths, you will probably want to create data path diagrams to simplify the process and ensure that there are no gaps. The data path diagram also serves as documentation that will be useful on an ongoing basis, such as when new team members are getting up to speed or when the application is due to be upgraded, or migrated.
The entry points that align to data paths can be identified as the web server (for internet users) and the application server (for internal users). It is important to remember that there is a third entry point, however, which is easy to overlook. Internal users authenticate directly to the SQL Server instance.
Of course, this final entry point is intended for the use of DBAs to manage the instance and its databases, but it is important to remember that around 70% of security breaches are from internal sources.
The trust boundaries for the CarterSecureSafe application map to the Firewalls. The data path from internet users crosses both the perimeter and internal firewalls, whereas the internal data path remains within the internal trust boundary.
Security Profile
Profile Element | Considerations |
|---|---|
Input Validation | The application runs ad-hoc T-SQL, as opposed to calling stored procedures. Therefore, the input cannot easily be validated at the SQL Server level.* |
As the main entry point is the web server, trust boundaries are crossed, and the input cannot be trusted. | |
Authentication | Users authenticate to the database engine via 2nd-tier authentication. No domain authentication is required to access the databases. |
Penetration testing to ensure that the sa account has been either disabled or renamed has not been carried out on the instance. | |
The application server resolves user credentials. The application server uses a single user to authenticate to the database engine. | |
Cryptography | Data is encrypted in transit using IPsec. |
Databases are not encrypted using TDE (Transparent Data Encryption). | |
No column level encryption is used. | |
Auditing | SQL Audit has not been configured; however, the default trace is running, which will capture a limited subset of activity, such as creating new objects or dropping existing objects. |
Identifying Threats
Now that a security profile is in place, we can work to identify potential threats in our application. This will usually involve performing a penetration test.
Tip
A penetration test, also known as a pen test, involves scanning a solution (or in some cases an enterprise) in an attempt to find vulnerabilities that could be exploited by attackers.
Understanding STRIDE
There are many penetration testing tools available, including Qualys, which can be obtained from www.qualys.com ; Metasploit, which can be obtained from www.metasploit.com ; and Kali Linux, which can be downloaded from https://www.kali.org/downloads/ .
Spoofing identity
Tampering with data
Repudiation
Information disclosure
Denial of service (DoS)
Elevation of privileges
Spoofing identity refers to stealing another user’s identity and using this identity to authenticate, as opposed to your own identity. The CarterSecureSafe application is particularly susceptible to this because the application server uses a single user to authenticate to the instance and because inputs cannot feasibly be validated at the database tier.
Tampering with data refers to the practice of maliciously modifying data. In the context of the overall application, this could refer to attacks, including cross-site scripting (where malicious scripts are inserted into seemingly benign websites) and manipulating HTTP headers (meaning that the HTTP headers are dynamically generated, allowing for cross-site scripting and other attacks, such as response splitting and session fixation). From the DBA perspective, however, it refers to maliciously modifying data stored within the database. For example, in the case of the CarterSecureSafe application, a malicious user may attempt to amend the balance of their account to zero.
Repudiation describes a malicious user’s ability to hide or deny their activity. This is critical, because if repudiation is possible, you may not be aware that an attack has even taken place. If you are aware that security has been breached, it may be impossible to prove. Repudiation is an issue for the CarterSecureSafe application because SQL Audit has not been implemented. This means that the only actions that will be captured are those that are captured by the default trace, such as new object creation.
Information disclosure is the classification of threat that springs to most people’s minds when they think of hacking. It refers to data being “stolen.” Data theft occurs when an attacker forces a system to reveal more data than they have the permissions to see. As with spoofing identities and tampering with data, the CarterSecureSafe application is susceptible to this form of attack because the database layer does not validate inputs.
Denial of service (DoS) attacks occur when an attacker attempts to flood a system with so many requests that they either take down the system or make the system appear to be down, due to its inability to deal with the volume of requests received. DoS is one of the most common form of attacks, and in today’s world are becoming increasingly sophisticated. This means that you should always take them into account during every threat modeling exercise.
Elevation of privileges refers to the act of exploiting a system to gain more permissions than you were intended to have. The fact that the security profile has revealed that penetration testing has not taken place around the sa account means that the CarterSecureSafe application is susceptible to this kind of attack.
As with all relational database management systems, SQL Server has known vulnerabilities, which can be exploited. These should be addressed wherever possible, usually through patching the system. If no patching is currently available, then at a minimum, you should consider implementing auditing and alerting, specifically tailored to the vulnerability.
Using STRIDE
STRIDE Classification
Risk | Category | Example |
|---|---|---|
SQL Injection | S,T,I | Attacker types ' OR 1=1-- In password field of the website to spoof the first user identity stored in the users table. |
DoS | D | Attacker uses robots to simultaneously flood the database with resource-intensive requests. |
Stealing sa account credentials | E | An attacker suspects that the sa account has not been disabled or renamed. Therefore, an attack is launched against the password of the sa account. |
DBA performs malicious action | R | A privileged user performs a malicious action and the attack cannot be proven, due to lack of auditing. |
SQL Server Remote Code Execution Vulnerability* | S,T | An attacker runs a malicious query to exploit a vulnerability in SQL Server, where the use of uninitialized memory in some virtual functions is permitted. |
Note
While this type of attack sounds a little farfetched, it is more common than you may think. I am aware of two separate companies that have fallen foul of this in recent times. In one instance, on a DBA’s last day, he dropped a key database. In the other instance, a SQL Server DBA obfuscated all stored procedures before leaving the company.
Rating Threats
Once threats have been identified and classified, you should begin the process of rating these threats, based upon the probability of the attack occurring, compared to the damage that could be inflicted if the threat was realized. There are various methodologies used for rating threats.
Understanding Threat Rating Methodologies
The simplest method for rating threats is a straight High, Medium, Low system. With this system, each threat will be given a rating, based on your opinion. There are two issues with this approach, however. First, it makes the rating system subjective, as opinions are opinions only and are not necessarily correct. Second, opinions often differ; therefore it can be hard to gain a consensus on the priority in which the threats should be addressed.
A slightly more scientific approach is to use a Critical, Important, Moderate, Low system. This system offers more categories, which can aid prioritization, where there are a large number of threats. A critical threat is usually defined as a threat that allows an attacker to penetrate a system without any alerts or warnings being fired and where there is precedence of this attack being performed.
An important threat is usually regarded as a threat where data could be compromised by an attacker and it would be easy for an attacker to exploit the vulnerability if it was discovered. With threats in this category, there is often a precedence for similar vulnerabilities being exploited.
A moderate threat is categorized as a threat where it is possible for an attacker to exploit the vulnerability; however, the risk is mitigated by factors such as integrated authentication, which would be difficult for an attacker to exploit the weakness.
A low threat is normally regarded as a one where the likelihood of the vulnerability being exploited is very low, due to existing infrastructure or countermeasures that are in place. Often, threats that are categorized as low will not be addressed, as it will be decided that the cost of addressing them outweighs the potential costs of the attack being exploited.
Caution
While pragmatically, ignoring a threat with a low rating is sensible because we all understand that budgets and timescales are always important factors, I do like to remind management and budget holders of the analogy involving the Fukushima nuclear disaster in 2011. The risk analysis when building this plant reportedly factored in protection against an earthquake and protection against a tsunami. The risk of two earthquakes and a tsunami occurring at the same time, however, was regarded as unlikely to require consideration. The first earthquake was within the designed tolerance of the reactors, but following the second earthquake and tsunami, the Fukushima plant largely melted in 3 days.
Another common system for threat rating is to use a damage potential * probability formula. Using this technique, you will rate the damage potential of each threat using a scale of 1 to 10, where 1 means that an attack exploiting this particular vulnerability would cause only minimal damage, and 10 indicates that an attack exploiting the particular vulnerability would be a catastrophe.
You will then rate the likelihood of the threat being realized on a scale of 1 to 10. Here, 1 indicates that there is very little chance of the threat being realized and 10 means that it is almost certain. Once the two ratings for each threat have been established, you will multiply the damage potential rating by the probability rating for each threat. This will give your threats a priority score on a scale of 1 to 100.
Understanding DREAD Methodology
Damage potential
Reproducibility
Exploitability
Affected users
Discoverability
Damage potential rates the damage potential of each threat using a scale of 1 to 10, where 1 means that an attack exploiting this particular vulnerability would cause only minimal damage, and 10 indicates that an attack exploiting the particular vulnerability would be a catastrophe.
Reproducibility rates how easy it would be for an attacker to repeatedly reproduce the attack on a scale of 1 to 10, where 1 indicates that is would be almost impossible to reproduce, and 10 means that it would be very easy to reproduce an attack. The easier it is to reproduce an attack, the more likelihood there is of automated attacks, using Bots, being used to systematically attack the system.
Exploitability rates the ease in which an attack could exploit the vulnerability, using a scale of 1 to 10, where 1 indicates that the vulnerability would be extremely difficult to exploit, due to factors such as domain authentication being required. A rating of 10 indicates that an attacker could exploit the vulnerability with ease.
Affected users rates the number of users that would be affected by the threat being discovered on a scale of 1 to 10. To calculate the rating, you should take the percentage of users that would be affected, divide this number by 10, and then round to the nearest whole number. For example, if 80% of users would be affected, then the rating would be 8. If only 25% of users would be affected, then the rating would be 3.
Discoverability rates how easily an attacker could discover the vulnerability on a scale of 1 to 10. A rating of 1 means that the vulnerability is obscure, and an attacker would be unlikely to stumble across it or realize its potential. A rating of 10 would indicate that the vulnerability can easily be discovered. For example, it may be a well-known, documented attack strategy, such as SQL Injection.
Using DREAD Methodology
DREAD Ratings
Risk | Category (STRIDE) | D | R | E | A | D | Threat Rating |
|---|---|---|---|---|---|---|---|
SQL Injection | S,T,I | 10 | 10 | 9 | 10 | 10 | 10 |
DoS | D | 10 | 10 | 10 | 10 | 10 | 10 |
Stealing sa account credentials | E | 6 | 10 | 8 | 10 | 10 | 9 |
DBA performs malicious action | R | 10 | 1 | 1 | 10 | 10 | 6 |
SQL Server Remote Code Execution Vulnerability | S,T | 8 | 5 | 5 | 6 | 1 | 5 |
We can see that the risk of SQL injection attacks, stealing the sa account password, and DoS attacks should be addressed immediately. The risk of DBAs performing malicious actions and the SQL Server Remote Code Execution Vulnerability being exploited should still be addressed, but with a lower priority.
Creating Countermeasures
Our security modeling is now complete, and we should start to consider what countermeasures we can put in place for each of the risks that we have identified, starting with the threats that have the highest DREAD rating.
Mitigating the risk of SQL Injection involves validating the inputs received. This should be performed at the application, but it is important to remember that the DBA is the last line of defense against attacks. Therefore, we should review how the application is interacting with the database. We identified that the application is running ad-hoc queries and we could reduce the risk of SQL Injection attacks by introducing a hosting standard that requires applications to access data within the database using stored procedures, as opposed to ad-hoc SQL. We can then ensure that the stored procedure is validating the values passed to its parameters.
While this will cause rework, both on the application tier and the database tier, the code that is currently being executed by the application can be reused inside stored procedures. This approach may also give other advantages, such as increased reuse of execution plans.
The risk of an attacker gaining elevated privileges by attacking the password of the sa account can be mitigated by disabling or renaming the sa account. If the application is legacy, or third-party, however, then it may have a hard requirement to use the sa account. If this is the case, then you should, at a minimum, introduce SQL Server Audit to increase reputability and preferably a combination of triggers and Policy-Based Management to protect against some common, malicious actions.
Tip
SQL Server Audit is discussed in Chapter 3. A full discussion around Policy-Based Management is beyond the scope of this book. Full details of implementing the technology can be found in the Apress title Pro SQL Server Administration, which can be purchased at http://www.apress.com/9781484207116?gtmf=s .
DoS attacks are one of the most difficult to protect against. This goes part way to explaining why they are one of the most common forms of attack. One way to reduce the risk is to ensure that the database server is not placed in the DMZ and is therefore not directly exposed to the internet. This security best practice is already in place for the CarterSecureSafe application.
We could further reduce the impact of a DoS attack by implementing Resource Governor. This would allow us to limit the resources that were consumed by attacker’s requests. If the application tier were written using Java EE, then we could also use WebLogic server to reduce network traffic. As the application layer is .NET, however, this approach is not feasible in our case.
Tip
A full discussion of Resource Governor is beyond the scope of this book. A full discussion of the technology and how to implement it, can be found in the Apress title Pro SQL Server Administration, which can be purchased at http://www.apress.com/9781484207116?gtmf=s .
If a rogue DBA decided to attack the database, then there is very little that we could do to stop it. What we must do, however, is ensure that we have a reputability strategy in place. This involves using SQL Server Audit (discussed in Chapter 3) to ensure that malicious actions are traceable. This serves two purposes. The obvious reason is that we can prove what happened and take appropriate action. Less obviously, the fact that we can prove and take action against a malicious DBA will potentially act as a deterrent. This is known as a soft security measure. Processes should also be reviewed to ensure that sensible best practices are being followed, such as disabling user accounts when a staff member leaves. Currently the CarterSecureSafe application does not have SQL Server Audit implemented. We should consider implementing fine-grain auditing to ensure reputability.
Because the DREAD rating for the SQL Server Remote Code Execution Vulnerability is low, and specifically due to the obscurity of the vulnerability, we (or management) will likely decide that we should not take immediate action to mitigate the risk, as appropriate countermeasures will likely prove cost-prohibitive, compared to the likelihood of the vulnerability being exploited. We should keep the risk logged in our project’s risk register and patch the instance as soon as a patch becomes available.
Compliance Considerations
Alongside the modeling of threats, when designing the security model for SQL Server, DBAs must also take compliance requirements into consideration. Depending on your organization’s industry, the country in which you work, and the country in which your organization is based, the regulator, and therefore the regulations to which you must comply, will vary considerably. In the following sections, we will glance at SOX compliance and GDPR, as well what impact they may have on your security model.
Introducing SOX for SQL Server
The Sarbanes Oxley Act (often known as SOX) is a U.S. law passed in 2002, in the wake of scandals such as Enron, in an attempt to ensure financial accuracy of companies and avoid corruption. It applies to all public companies in the United States and some aspects of it also apply to private US companies.
The issue with SOX from a technologist’s point of view is that the legislation was written from a business perspective, rather than a technical perspective, so for IT teams, it can be somewhat vague and confusing. Therefore, lets run through some of the key points, from a DBA’s perspective.
Much of the SOX requirement, from the DBA’s viewpoint, revolves around auditing. Critical data access must be audited, along with changes to user permissions, changes to the database structure, and access failures. There should also be extra monitoring of activity by privileged users, such as DBAs themselves, to ensure reputability, in the event that unauthorized changes are made.
Your auditing solution should be able to scale with the organic growth of your enterprise, and you should be able to quickly and easily identify and review any unusual or suspicious activity. The auditing should be transparent to users, and privileged users should not be able circumvent or delete audit logs. SQL Server Audit is discussed in Chapter 3.
There should be a clear separation of duties between DBAs and developers, in order to ensure that unauthorized changes cannot be implemented. This is usually achieved by developers not being granted permissions to production servers. There are circumstances where developers may autonomously try to circumvent this, however, as discussed in Chapter 13.
DBAs must implement, document, and enforce governance controls for database management processes, such as password cycling (including for service accounts), access control, and deployments. DBAs should also perform a regular gap analysis to document and gain sign-off for any exceptions to the database management policies.
Introducing GDPR For SQL Server
GDRP (General Data Protection Regulation) came into force in the EU in 2018, with the intention of ensuring data privacy for EU residents and giving them control over the data that is held about them. The legislation is broad, and with potential penalties of up to 20 million euros, or 4% of global turnover, so it is critical that DBAs ensure that their working practices are compliant.
GDPR states that your data must be protected by design and by default; in other words, you must have control over who can access your data. There are several aspects that you must consider here. The most obvious is authentication. SQL Server database engine can support either Windows authentication, or 2nd-tier authentication. Both of these options are discussed in Chapter 2. Chapter 2 also discusses roles-based security, which is also important when ensuring this requirement is met.
GDPR also states that data should be securely processed and encrypted. Encryption is discussed in Chapter 5, but you should also consider row-level security features for data processing. A discussion around row-level security can be found in Chapter 4.
Under GDPR, companies must have an audit record of data processing activities. This can be achieved in SQL Server, using SQL Server Audit. Chapter 3 has a full discussion around the implementation of SQL Server Audit. Companies must also carry out a risk assessment and be able to demonstrate how they comply with GDPR. You can use the skills you have learned in this chapter to assist with performing risk assessments.
Summary
Threat modeling is not a terribly glamourous task, but it is absolutely essential to creating and maintaining a secure environment. It provides a mechanism for identifying threats and prioritizing the efforts to create countermeasures.
Idealistically, you will want to tackle all threats as quickly as possible; however, a pragmatic approach is required. Due to time and/or budgetary constraints, you may need to record some threats in the project’s risk register, instead of implementing rigorous countermeasures. In some instances, there may also be other reasons for exceptions, such as the requirements or a legacy application.
Spoofing identity
Tampering with data
Repudiation
Information disclosure
Denial of service (DoS)
Elevation of privileges
Damage potential
Reproducibility
Exploitability
Affected users
Discoverability
Threat analysis should be reviewed on a regular basis—often annually, but more frequently, such as quarterly, in some secure environments. Threat analysis should also be reviewed after major application or infrastructure changes.
When considering a security model for SQL Server, consideration should be given to compliance requirements. Regulations that you need to adhere to will vary based upon your organization’s industry and the country where you reside. Common requirements that must be adhered to are SOX in the US and GDPR in Europe.
SQL Server has all of the features required to make sure your organization is compliant with any regulations. This book will guide you through the process of implementing each of these features, including encryption, auditing, and access control.