What is Code Signing?

Before understanding what “Code Signing” is, let’s try to understand two terms prevalent in computer security – Authenticity and Integrity.

Authenticity – is talked about in all walks of life. We usually ask, if the product that I am buying is authentic or from authentic source. Does the labeling confirm what it claims to be? So, authenticity is one form of validation of identification. For a Code authenticity is nothing but validating authors identity.

Integrity – in humans is taken as quality of being honest. An honest human is trustworthy. Similarly, data/software integrity refers to trustworthiness. It means that the code has not been tempered or altered over the period.

Now that we understand what Authenticity and Integrity is – “Code Signing” is a method which helps validate both authenticity and Integrity!

A signed code is authentic as it validates authors identity and ensures that the code has not been altered with a malicious code that can cause damage to the applications.

In SQL Server, you can Code Sign, procedures, functions, triggers and assemblies. This can be achieved using Digital Certificates or Asymmetric Keys.

Advertisement

Static Data Masking

Data masking as we all know is a data protection layer which replaces/scrambles/masks sensitive data being disclosed to unwanted/unauthorized users. “Static Data Masking” also known as Persistent data masking is a method to protect data at rest. It is a new security feature released in SQL 2019 (available for public preview at the time this blog was written) that helps users create a copy of masked [sensitive] data from production environment. Using this feature, copy of the live data is crated with appropriate masking functions; and the masked copy can be shared with users who intend to work on non-live data. This feature also helps keep organizations compliant which are subject to data protection/privacy regulations such as GDPR.

Data masking process starts with users configuring masking operations for the columns in database which contain sensitive information. Data is copied to a new database during the data copy process from the live system and then masking functions (according to the masking configuration) are applied to mask the data at column level. Unlike dynamic data masking, static data masking is persisted and irreversible (one-way process), original data cannot be retrieved.

Static data masking can be used for development, testing, analytics and business reporting, compliance, troubleshooting, and any other scenario where specific data cannot be copied to different environments.

 

References:

SQL Server 2019 CTP 2.1

SQL Server Security Basics | The Principle of Least Privilege

We need to walk a fine line when granting privileges to a user to perform certain task. Principle of Least Privilege says that a user be granted only those privileges, which are required to perform their task – nothing more, nothing less. This principle is also known as the principle of minimal privilege or the principle of least authority.

We should always follow the principle of least privilege when granting permissions to database users. A database user, whose task is to extract reports, should be granted read permissions to the schema. Image if the same user has write permissions to the database, potentially database can be compromised; sales data can be fudged to make it look great before the management if a user has extra privileges.

There is no direct way or a charter, which lists set of permissions vis-à-vis functional task. It varies from organization to organization. In order to come up with a security model, start by assigning least level of privileges (that may seem appropriate to you) to perform the intended task and then test. As a quick tip try to remove one privilege at a time and check the impact on the task under consideration. This way you will be able to formulate a security model.

I came across an incident recently where a team received a database backup (was in Oracle though not SQL Server) from a customer to fix an issue and a user account that was used to restore the backup actually overwrite password profiles that were set-up internally. It was discovered very late when some of the application users reported passwords being expired after one week of creation.

Security is very important for an organization to sustain for long, and there is no alternative but to conscientiously follow principle of least privilege.

 

References:

• Principle of Least Privilege (Wikipedia)
• Brian Kelley’s post (I consider him a gem in Security field)
• Excerpts from Microsoft documents

SQL Server Security Basics | What is Authorization?

Think of this:

• Whether a stranger is authorized to enter your house without your permission?
• Whether you authorize your friend to take your car whenever he wants to go on a drive?
• Whether a co-employee is authorized to access your confidential information stored with Human Resource department?

You might be getting a hang of it… Authorization is all about “What can a person (or identity in digital world) do?”; have they so called “access rights/privileges” to the desired “resources”.

That being said, Authorization takes a form of access policies that an organization sets forth for the resources being used. These access policies are created and/or controlled by an authority (usually a senior employee or department head).  These policies are formulated based on “principle of least privilege” – which says that a user/identity should only have minimum set of privileges to get their work done.

In SQL Server, Authorization is enforced with Permissions, and we have a freedom to club common permissions into Roles. These permissions are hierarchical in nature and exist both at database and server level.

I will talk more about Authorizations, Permission Hierarchy, and principle of least privilege in upcoming blogs. So stay tuned!

SQL Server Security Basics | What is Authentication?

By definition Authentication means the process of verifying the identity of a user or process. If a user wants to talk to the database, SQL Server asks “Who you are?”, and authenticates you. There are three types of authentication modes available:

• Windows Authentication
• SQL Server Authentication
• Azure Active Directory

Windows Authentication

• This is the default authentication mode and the more secure as compared to SQL Server Authentication.
• Microsoft BOL recommends to use Windows Authentication over SQL Server Authentication.
• This mode is available both on SQL Server running on-premises and Azure Virtual Machine.
• It uses Kerberos security protocol.
• Connection made under this mode is also called “Trusted Connection” as SQL Server trusts Windows credentials.
• Has additional password policy, such as strong password validation, support for account lock and password expiration.

SQL Server Authentication

• Logins here are validated which are created and managed by SQL Server.
• Unlike Windows Authentication, user should provide credentials every time while connecting to SQL Server.
• There are few (optional) password policies also available.
• This mode can be used where there is a requirement to support mixed operating system for applications and users cannot be validated using Windows domain.
• Can be useful with web-applications where users have the provision to create their own identities.
• It does not use Kerberos security protocol, and there is also a risk for applications that connect automatically with the SQL Server may save the password in file in clear text.

Azure Active Directory

• This authentication mechanism validates an identity based on Azure Active Directory (Azure AD).
• It supports token-based authentication, ADFS (domain federation) and/or built-in vanilla authentication without domain synchronization.
• It can also support mechanism of password rotation in a single place.
• Allows management of identities centrally (Central ID), which helps in simplifying user and permission management.

I am going to write a series of blogs on security basics, this one is first one in the row. Stay tuned.

References:

Choosing Authentication Mode

Azure AD Authentication