Security Archives - Business Intelligence Info

Tag Archives: Security

DBA in training: Security

October 18, 2020 BI News and Info

The series so far:

By this time, we have discussed the importance of understanding your environment. You should have an idea of which databases support what applications, the SQL Server versions they run on, and the relative importance of each database and instance to the business.

Now, let’s talk about protecting the company from losing data due to security flaws.

Database security is a sub-specialty in and of itself, and you can read in-depth work by people like Denny Cherry, Robert Sheldon, Chip Andrews and numerous blogs. This will be a general discussion to help you get started. To begin the journey of a thousand miles, though, I will give you the first steps, and let you refer to the experts to address your individual needs. I’ll start with the mile-high view and work my way down, which should help you to provide the best measure of protection to your environments.

Physical security: Who can walk in the door?

Start with your physical security. Who has access to your physical servers or data centers? You need this list, and you want it to be as small as humanly possible. If there is no list, make one! Be sure to put policies in place to review this list on a semi-annual basis, and to review procedures for monitoring and auditing physical server/data center access. You should know who was in your server room, when and why. If your physical security is ever breached, your monitoring and auditing procedures will be instrumental in catching the culprit. Data is a company’s most valuable asset. This is worth the investment.

If you are completely in the cloud, you may think you are safe. You aren’t. Even if your servers are not physically accessible, it doesn’t mean they cannot be accessed. Whatever your physical setup, you should at least do an annual (unannounced!) penetration testing to see just how physically secure your company is. A good “pen tester” is worth every penny, because they will show you where the holes are in your security, giving you time to fix them before trouble really hits. You may think, “But I have a small company, where everyone knows everyone! What good will that do?” You will probably be very surprised. You can easily find stories of employees who, out of politeness, held a door open for the person who “just happened” to walk in behind them, thinking they are a new employee (or not noticing that they are unfamiliar at all). Other stories abound of employees who were careless with leaving their monitors unlocked or their badges unsecured at their desks. Perhaps you have heard the one about the person who kept the password to their computer on a Post-It on the monitor (or in their top desk drawer, etc.). Before you think it won’t happen to you, know that pen testers are very good at what they do; people are tricked all the time! So please make this an important line item on your list and do it at least yearly. People can become complacent over time with a false sense of security, so keeping awareness high is key.

Data file security: Who can get in your files?

Now that you are addressing your physical security, start thinking about the security of your data files. Your Infrastructure team may be handling this already. If so, it would be helpful to have an idea of what those measures are. At a minimum, it would be good to know who has access to your data and log files at any level – even if you have encrypted all of your data. What measures are in place to detect and alert you to unauthorized access into your data files? If you aren’t aware of any such measures, now would be the best time to work with Infrastructure to put those steps in place if possible.

What about backups files? Make sure that they are protected just as well as the data and log files. You also need to think about copies of production that might be made for development, QA, or testing. Are backups given to developers to restore on their laptops? To make sure that down level copies are production are protected, think about using a tool like Redgate’s Data Masker to sanitize sensitive data.

You also want to know what measures are in place to protect against malware, bots and the like. If your company allows pretty much anyone to download anything they like, the risk of these threats is higher to your data. The best hackers can get in and out with hardly a trace through some pretty stringent conditions, so don’t make it easier for them. Be the one to suggest some controls to keep at-risk software out of your corporate environment.

Keep your SQL Servers as current as possible

There is a very good chance that you will find a mixture of instances of SQL Server where you work. This is usually due to what vendors will support for their applications. You then ask the vendor to be able to upgrade the SQL Server instance or compatibility level for their database, only to hear a flat-out “no”, or “If you do this, you do it at your own risk – we won’t support it.” Accepting defeat, you go on with life and pray they will be ready to upgrade their product soon. The only problem is that if you run into trouble with the instance and have to open a ticket with Microsoft, the first question from the support staff is going to be, “What version of SQL Server are you running?” If you are running an instance that is in support but not current, they will likely first tell you to patch your instance and bring it current. If an instance is out of support, you are on your own.

Worse, you are vulnerable.

A couple of years ago, the discovery of a couple of processor security bugs called Spectre/Meltdown set the IT world on fire. Microsoft quickly responded with patches – but the patches only went back to 2008. If you had a 2005 instance that was not running on a 2008 + Windows server, you were out of luck. This situation strongly argues for isolating databases for older applications that will not support an upgrade – or for considering the possibility of a different product.

Keeping your patching as up to date as possible is one of the best things you can do to protect your servers. By saying that, I am not advocating to throw the patch on production the day after release. Start by waiting a week or so after the patch comes out to check for reported issues. If there are going to be problems, you should begin to hear about them online within that period, or you will see that Microsoft rolls out a new patch almost immediately. Then begin with a dev environment (after taking a server snapshot for rollback, if you can). See how things go for a week or so. Then patch test (if you have a test environment), and slowly move your way up. By the time you are ready for production, you will have a well-tested patch.

You might be wondering by now how to know when new patches are available. I like https://sqlserverupdates.com/ for this. This part of the site does a great job getting you started with patching and answers some frequently asked questions. Try to build a patching schedule (at least four times a year) and ensure that you stick to it. Your servers will thank you.

If you happen to use SQL Monitor, you can also use the Estate pages to keep track of updates and the current version of all your SQL Server instances.

word image 3 DBA in training: Security

Server and database security

You have done what you can to keep the criminals out of your physical environment and your files. It is time to begin looking to your server and database security.

In SQL Server, you have logins and users. Logins are groups, service accounts or individuals who can get into your server. Users are groups, service accounts or individuals who can access one or more databases. One login can have more than one user name, but they can only use one user name per database. This basic query will get you the login information on your servers:

SELECT *

FROM sys.server_principals;

Querying sys.database_principals will show your database users:

SELECT *

FROM sys.database_principals;

Just as you can have logins who can access the server and users that can access one or more databases, you also have server-level roles, that apply to the whole server, and database-level roles and permissions, that apply only to their specific databases. Permissions may be given through role membership or individually. For instance, to give someone a server-level role:

ALTER SERVER ROLE sysadmin

ADD (DROP) MEMBER <member name here>;

To do a database-level role membership:

ALTER ROLE db_datareader

ADD (DROP) MEMBER <member name here>;

Alternatively, to grant a specific permission:

GRANT (DENY, REVOKE) SELECT ON dbo.Table to [user name here];

These operations can also be done easily through the GUI by going to the properties or a login or user, depending on your scope. Some DBAs prefer the GUI as it can help to reduce errors.

Granting permissions is easy. Keeping a tight lid on them is not so simple. You should regularly review who can do what on your servers. How often is a matter of how much time you have, but try to set a regular schedule if possible. Security monitoring and reporting (which we will discuss later on) can really help you here. Try to be one of the first to know if someone leaves the company, so that you can disable SQL Server access. This is not just a best practice, but also a practicality: disgruntled employees are responsible for some of the worst attacks, so staying on top of this could save you a very bad time later on.

Starting at the top: Do you know who has sysadmin on your servers? Whoever has sysadmin rights can do anything, including dropping databases and tables, among other disastrous things. These people could take the business down for a protracted length of time. There should be a documented list of who is in this server role and it should be very small, not to mention periodically reviewed.

Sysadmin may be the most dangerous permission, but it is not the only one. You want to know who has these, too:

serveradmin – Members of the serveradmin role can change your server configurations and shut it down.
securityadmin – Anyone in this role can assign most permissions and allow people on to your server in the first place.
processadmin – These guys can end anything running in SQL Server.
setupadmin – Members of setupadmin can spin up or remove linked servers with TSQL (but not using SSMS).
bulkadmin – Bulkadmins can bulk insert data.
diskadmin – Members of this role can manage your disk files.
dbcreator – Just what it says. Anyone in this role can create (but also alter or drop!) any database.
CONTROL SERVER – This is one level below sysadmin. There are some differences, but CONTROL SERVER encompasses all the roles listed above except for sysadmin.

Now, for the database-scoped roles:

db_owner – Can create and drop objects and change configuration and maintenance on the database.
db_securityadmin – Can modify custom role membership and manage permissions – including their own.
db_accessadmin – Can add/remove access for Windows and SQL Server logins/groups.
db_backupoperator – Can backup the database (possibly breaking your backup chains).
db_ddladmin – Can create objects (or remove them) in the database.
db_datawriter – Can INSERT, UPDATE or DELETE data in all user tables.
db_datareader – Can read anything in any user table.
db_denydatawriter – Cannot INSERT, UPDATE or DELETE data in any user table.
CONTROL DATABASE: Encompasses everything in the database roles above.

Note: Server and database roles are fixed by Microsoft and cannot be changed.

These roles apply to every database, but there are some roles that you will only find in the msdb database. The msdb is part of the system databases, which we will discuss in more depth in another article. The msdb controls all agent jobs and stores information on your backups, SQL Server Integration Services (SSIS), data collector, policy-based management and database mail information. The msdb is a unique database for this reason. Because of all of the things it stores and controls, msdb needs some special roles of its own:

db_ssisadmin – Can do anything to any package. Could possibly elevate their own permissions to sysadmin.
db_ssisltduser – Can enumerate all packages, but only view, execute, export, own or delete their own packages. May import packages.
db_ssisoperator – Can see, execute, export and enumerate all packages. Can execute any package in SQL Server Agent.
SQLAgentUserRole – Can create/modify/delete their own local jobs and schedules. They cannot control ownership, and their role does not extend beyond the server where their role membership exists. They can enable or disable their own jobs and schedules, and edit their properties, as well as execute, stop and start them. They cannot delete job history on their own jobs unless they are granted that permission.
SQLAgentReaderRole – Members of the SQLAgentUserRole, the SQLAgentReaderRole can create/modify/delete their own jobs and schedules. They can enable or disable their own jobs and schedules, and edit their properties, as well as execute, stop and start them. They cannot delete job history on their own jobs unless they are granted that permission.
SQLAgentOperatorRole – Also a member of SQLAgentUserRole, the SQLAgentOperator has all of the permissions of the User and Reader roles, and can also view properties for operators and proxies, and see available proxies and alerts. They can start, stop or execute any local job, and they can delete the job history. They have do not have access to the Error Logs.

Finding permissions

I may have frightened you enough by now that you do not even want to give db_datareader permissions. Good! There is a concept called the Principle of Least Privilege which (put succinctly) says not to give any more permissions than what is absolutely needed. So role membership should be sparing!

Now, you may be wondering: how do I find out what permissions everyone has? After all, permissions don’t (and shouldn’t) just come through role memberships, and you may be scaring yourself imagining what your users are doing in your databases – or worse, what they could do, without realizing the danger. For server-level roles, you can use this query from Books Online:

SELECT sys.server_role_members.role_principal_id,

role.name AS RoleName,

sys.server_role_members.member_principal_id,

member.name AS MemberName

FROM sys.server_role_members

JOIN sys.server_principals AS role

ON sys.server_role_members.role_principal_id = role.principal_id

JOIN sys.server_principals AS member

ON sys.server_role_members.member_principal_id = member.principal_id;

For the database permissions and roles, I have a script that can help. It’s based on one that I found on Stack Overflow some time ago, but I modified it to look throughout an entire instance and to allow me to query it by database(s) or user(s). That way, you can get all the permissions on an instance (or database(s)) for a user or group. It will take you all the way down to the column level.

Now, here is the script. It is not fast, especially if you run it with the WHERE clause commented out. You’ve been warned.

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

IF OBJECT_ID(‘tempdb..#t’) IS NOT NULL

DROP TABLE #t;

CREATE TABLE #t

(

DatabaseName sysname NULL

, UserName sysname NULL

, UserType NVARCHAR(MAX) NULL

, DatabaseUserName sysname NULL

, Role sysname NULL

, PermissionType NVARCHAR(MAX) NULL

, PermissionState NVARCHAR(MAX) NULL

, ObjectType NVARCHAR(MAX) NULL

, ObjectName NVARCHAR(MAX) NULL

, ColumnName NVARCHAR(MAX) NULL

);

DECLARE @dbName sysname;

DECLARE @dbCursor CURSOR;

DECLARE @sql NVARCHAR(MAX);

SET @dbCursor = CURSOR FOR

SELECT name

FROM sys.databases

WHERE source_database_id IS NULL

AND database_id > 4

AND is_read_only = 0

AND state_desc = ‘ONLINE’

ORDER BY name;

OPEN @dbCursor;

FETCH NEXT FROM @dbCursor

INTO @dbName;

WHILE (@@FETCH_STATUS = 0)

BEGIN

SET @sql = N‘

USE [‘ + @dbName + N‘]

INSERT INTO #t

SELECT ‘‘[‘ + @dbName + N‘]’‘ As DatabaseName,

[UserName] = CASE princ.[type]

WHEN ‘‘S’‘ THEN princ.[name]

WHEN ‘‘U’‘ THEN ulogin.[name] COLLATE Latin1_General_CI_AI

WHEN ‘‘G’‘ THEN ulogin.[name] COLLATE Latin1_General_CI_AI

WHEN ‘‘R’‘ THEN ‘‘Database Role’‘

ELSE princ.[type]

END,

[UserType] = CASE princ.[type]

WHEN ‘‘S’‘ THEN ‘‘SQL User’‘

WHEN ‘‘U’‘ THEN ‘‘Windows User’‘

WHEN ‘‘G’‘ THEN ‘‘Windows Group’‘

WHEN ‘‘R’‘ THEN ‘‘Database Role’‘

ELSE princ.[type]

END,

[DatabaseUserName] = princ.[name],

[Role] = NULL,

[PermissionType] = perm.[permission_name],

[PermissionState] = perm.[state_desc],

[ObjectType] = obj.type_desc,–perm.[class_desc],

[ObjectName] = OBJECT_NAME(perm.major_id),

[ColumnName] = col.[name]

FROM sys.database_principals princ

LEFT OUTER JOIN sys.login_token ulogin ON princ.[sid] = ulogin.[sid]

LEFT OUTER JOIN sys.database_permissions perm

ON perm.[grantee_principal_id] = princ.[principal_id]

LEFT OUTER JOIN sys.columns col ON col.[object_id] = perm.major_id

AND col.[column_id] = perm.[minor_id]

LEFT OUTER JOIN sys.objects obj ON perm.[major_id] = obj.[object_id]

WHERE princ.[type] IN ( ‘‘S’‘, ‘‘U’‘, ‘‘G’‘ )

UNION

SELECT ‘‘[‘ + @dbName + N‘]’‘ As DatabaseName,

[UserName] = CASE memberprinc.[type]

WHEN ‘‘S’‘ THEN memberprinc.[name]

WHEN ‘‘U’‘ THEN ulogin.[name] COLLATE Latin1_General_CI_AI

WHEN ‘‘G’‘ THEN ulogin.[name] COLLATE Latin1_General_CI_AI

END,

[UserType] = CASE memberprinc.[type]

WHEN ‘‘S’‘ THEN ‘‘SQL User’‘

WHEN ‘‘U’‘ THEN ‘‘Windows User’‘

WHEN ‘‘G’‘ THEN ‘‘Windows Group’‘

WHEN ‘‘R’‘ THEN ‘‘Database Role’‘

END,

[DatabaseUserName] = memberprinc.[name],

[Role] = roleprinc.[name],

[PermissionType] = perm.[permission_name],

[PermissionState] = perm.[state_desc],

[ObjectType] = obj.type_desc,

[ObjectName] = OBJECT_NAME(perm.major_id),

[ColumnName] = col.[name]

FROM sys.database_role_members members

INNER JOIN sys.database_principals roleprinc

ON roleprinc.[principal_id] = members.[role_principal_id]

INNER JOIN sys.database_principals memberprinc

ON memberprinc.[principal_id] = members.[member_principal_id]

LEFT OUTER JOIN sys.login_token ulogin

ON memberprinc.[sid] = ulogin.[sid]

LEFT OUTER JOIN sys.database_permissions perm

ON perm.[grantee_principal_id] = roleprinc.[principal_id]

LEFT OUTER JOIN sys.columns col ON col.[object_id] = perm.major_id

AND col.[column_id] = perm.[minor_id]

LEFT OUTER JOIN sys.objects obj ON perm.[major_id] = obj.[object_id]

UNION

SELECT ‘‘[‘ + @dbName + N‘]’‘ As DatabaseName,

[UserName] = ‘‘{All Users}’‘,

[UserType] = ‘‘{All Users}’‘,

[DatabaseUserName] = ‘‘{All Users}’‘,

[Role] = roleprinc.[name],

[PermissionType] = perm.[permission_name],

[PermissionState] = perm.[state_desc],

[ObjectType] = obj.type_desc,–perm.[class_desc],

[ObjectName] = OBJECT_NAME(perm.major_id),

[ColumnName] = col.[name]

FROM sys.database_principals roleprinc

LEFT OUTER JOIN sys.database_permissions perm

ON perm.[grantee_principal_id] = roleprinc.[principal_id]

LEFT OUTER JOIN sys.columns col ON col.[object_id] = perm.major_id

AND col.[column_id] = perm.[minor_id]

INNER JOIN sys.objects obj ON obj.[object_id] = perm.[major_id]

WHERE roleprinc.[type] = ‘‘R’‘

AND roleprinc.[name] = ‘‘public’‘

AND obj.is_ms_shipped = 0′;

PRINT @sql;

EXECUTE sp_executesql @sql;

FETCH NEXT FROM @dbCursor

INTO @dbName;

END;

CLOSE @dbCursor;

DEALLOCATE @dbCursor;

SELECT @@SERVERNAME AS ServerName

, DatabaseName

, UserName

, UserType

, DatabaseUserName

, Role

, PermissionType

, PermissionState

, ObjectType

, ObjectName

, ColumnName

FROM #t

WHERE

–(DatabaseName = ‘[DatabaseNameHere]’

–AND

DatabaseUserName = ‘UserNameHere’

–OR (DatabaseName = ‘[DatabaseNameHere]’

–AND DatabaseUserName LIKE ‘%UserName’)

–OR (DatabaseName = ‘[DatabaseNameHere]’

–AND DatabaseUserName LIKE ‘%UserName’)

AND PermissionType <> ‘CONNECT’

ORDER BY DatabaseName

, DatabaseUserName;

REVERT;

If you want to get an overall picture of where things stand with all your databases, you might consider running this with the WHERE clause commented out, so you get everything. Between these two queries, you should begin to build a picture of who can do what.

The first thing you want to look for is sysadmin permissions. Whenever a user or an application insists that it needs sysadmin permissions, question it. Often, that is not the case. For instance, the account running the Agent jobs will need sysadmin. You as a DBA will sometimes need sysadmin (i.e., when working with replication, viewing error logs, reading audit logs in SSMS, etc.). Even then, you will want to restrict when you use those rights, so consider having an alternate account for yourself that has sysadmin for only those occasions, and give your regular account reduced permissions to allow you to do your everyday tasks. If nothing else, it will make you think about what you are doing when you use that sysadmin account and lessen the risk of you making a mistake. Try to narrow that sysadmin membership as low as you possibly can. I have spoken to DBAs who work at companies where everyone has sysadmin. That means every one of those people could, by either mistake or design, drop every table in the enterprise or mess the data up badly enough to bring the business to a halt. If that does not scare upper management, I don’t know what will.

Once you have reviewed the sysadmin membership list, look at the other server role permissions and narrow those down. Then go on to the database permissions. The ultimate goal is to classify your end users into logical groups and give the collective groups only the permissions they need rather than to do individual permissions. In that way, if a person leaves or switches job positions in the company, they can be removed or added to the groups they need without having to do individual permissions auditing. Keep records of your SQL Server users (including any linked server users and the distributor admin for replication) and their passwords securely stored and access to them tightly controlled.

Depending on the state of your instances and databases, this step can take a good deal of time. Be patient – and persistent. Your data’s safety depends on you.

Be your authentic(ated) self

In a perfect world, you would only use Windows authentication on SQL Server. Using Windows authentication means that Windows verifies the user’s credentials in order to log into SQL Server. It is the safer way to go, and what you should do whenever possible.

If you are not there yet, then try to minimize the number of SQL Server accounts you have. Enforce your password policies when you make the accounts and make them change their passwords at least yearly if you can. Disable the sa user if at all possible.

Security monitoring

Now that you know who should be able to do what, think about how you will know if someone is trying to do something on your servers that they shouldn’t. What if a pen tester tried to get into one of your SQL Servers – would you know? Write jobs that look for failed logins and alert you regularly. I am a huge fan of Brent Ozar’s First Responder Kit. Among many other issues, it will catch elevated permissions and other security-related concerns and put them in a table for you to review. You can then report or alert on that data to help keep yourself on top of things.

If you are not ready or able to buy security monitoring tools, you might check out the EPM Framework. It is a free and easy way to set policies in SQL Server and ensure compliance. There is a good course in Pluralsight that will walk you through everything you need to know, should you have questions.

If you do have SQL Monitor in place, you can monitor when an account is added to sysadmin, failed login attempts, or anything you can think of with a custom metric.

word image 4 DBA in training: Security

Dangerous coding practices

Some practices can undermine all the careful work you have done so far without proper precautions. While I do not recommend saying no to all of these out of hand, you should know the risks they can present, and how to use them properly. This list is by no means comprehensive but should get you started.

Dynamic SQL

As a DBA, I have written a metric ton of dynamic SQL over the years. What is dynamic SQL? It is when you use a mixture of parameters and strings to construct and run a query. Sometimes, it is the best way to get things done. I happen to like it for optimizing some problem queries as well. You saw me use it in the query above to get all the permissions on an instance.

The risk here lies not the use of dynamic SQL itself, but in using it wrong. What is the wrong way to write dynamic SQL? This can go off the rails in a few ways:

Using EXEC (string). This is only there for backward compatibility. Use EXECUTE sp_executesql instead. It can be much safer.
Using unparameterized statements.
Using dynamic SQL in ad-hoc statements.
Not reviewing code to find vulnerabilities

Dynamic SQL needs to be tightly controlled, preferably executed by a login-less user that has very tightly restricted permissions and parameters that are sanitized with checks for things like semicolons, double dashes, asterisks, pound signs and keywords like DROP, DELETE, ALTER, TRUNCATE, GRANT, FROM, UPDATE, CREATE, etc.

Why? Two words. SQL Injection.

Unfortunately, if your company is hacked because of SQL injection, the hackers will not be the first to be blamed. You will. Spare yourself a bad day at the office. Erland Sommarskog and Bert Wagner have some great explanations and demos to share if you want to learn more.

xp_cmdshell

Think of granting access to xp_cmdshell as granting access to SQL Server’s OS. Unless there is a good reason to use it (and your security around it is good), this should be disabled in the configuration settings. However, this still requires monitoring (even after disabling). Steve Stedman has a good demo explaining how xp_cmdshell can still be used after disabling it and some preventative measures you can take to reduce your risks.

Remote queries

Any time you allow one SQL Server instance to query another one, you have opened a potential vulnerability for a hacker to jump servers. You may or may not be able to say no to this. If you cannot, ensure that your linked server security is as good and controlled as it can be, and that your network security is as solid as possible, making it as close to impossible for the black hats and the script kiddies as you can. Certainly, try to avoid allowing anyone to do anything but read across a linked server.

CLR

CLR stands for Common Language Runtime. CLR is a way to host .NET code in SQL Server. The possible danger comes as an added vector into your instance and not necessarily knowing what code is executed. You will want to monitor for these (again, sp_Blitz will catch them) and check them to ensure they are expected (and performant).

User-owned schemas, jobs, databases (or anything)

SQL Server users shouldn’t own anything. They are there to work with data, not to own it. When the end-user inevitably leaves the company, at the very least, you won’t be able to drop their accounts until you fix this, but at worst, it gives them a level of access that they just do not need – and you don’t want. Make a low-privileged user without a login or a (disabled!) sa the owner of databases and database objects whenever you can. It’s also possible to rename the sa, disabled or not.

Auditing

SQL Server auditing has been available in all editions at the server level since 2012, and fine-grained auditing became available in all editions with the release of SQL Server 2016 SP1. Take advantage of this feature in SQL Server and keep those records so that you know who did what, when and why. They will be invaluable if something goes wrong, if you are asked who dropped that table, or if other mischief occurs. This article will walk you through it!

Were you born in a barn? Shut the door!

How many times did you hear your mom or dad say that to you when you were a kid? They didn’t want flies in the house (and they certainly didn’t want the electric bill). Do not give the criminals more ways of getting in your servers than you must. Disable SQL Server browser (unless you have more than one instance on a server, in which case it must be on). Additionally, do not install every available feature when you install SQL Server – only put on what you need. You can go back and easily install other features such as Analysis Services or SSIS later, but there is no reason to have them on and to maintain them if no one is using them.

From a different perspective, if you have any individual permissions or users in your databases, you need to know when that person leaves the company, and have their access removed as soon as possible. This includes either disabling or – preferably – dropping the login and user. You have to do both. Dropping the login doesn’t drop the user from the databases; you are better off writing a script to drop the user where it exists in all the databases, then finally dropping the login. This is where you will be glad you didn’t allow users to own objects, because you won’t run into the “Cannot drop schema because it is being referenced by object”, “The database principal owns a schema in the database and cannot be dropped” and the “Login granted one or more permissions” messages that can be painful to unwind after the fact.

What do I do if my company has a data breach?

What if, despite your best efforts, you find that there has been a data breach? As DBAs, we plan for backups to go bad, and we layer our backups to cover it. We plan for disaster recovery, and we have availability options to cover that scenario. Have you ever thought about what to do if you are hacked?

First, if there is not one already, collaborate with other teams to come up with a run book, just as you would for disaster recovery and start writing your steps down. If possible, a response team consisting of people from infrastructure or network services, the DBA team, and business management should spring into action if a suspected breach occurs. This same team should meet periodically to review security standards and practices, to identify holes and how best to fix them, and to ensure that your security is in line with best practices. The Federal Trade Commission has a good set of guidelines to help you get started with your run book. Have the names of some forensic investigators handy so that you can quickly contact them. You want to quickly stop the breach and prevent anything else from happening. Then you are going to be very thankful for all the auditing and monitoring you have set up because it will be vital information to help determine what happened, how it happened, and how to prevent it from happening again.

Conclusion

Believe it or not, this will only get you started. Your server security will never be perfectly where you want it to be. You will find it is an ongoing process – you will no sooner wind up one round of server hardening than new applications, or features come out, or new vulnerabilities are discovered, and you are starting all over again. This is one of the most important parts of the job, though – if the data is hacked or ransomed, it will either not be available, or it will be useless. This makes security worth every bit of time you devote to it.

Let’s block ads! (Why?)

SQL – Simple Talk

Sonrai Security raises $20 million to protect public clouds with automation

October 15, 2020 Big Data

Public cloud security provider Sonrai Security today announced a $ 20 million round that will be used to accelerate R&D and boost global sales and marketing for its identity and data governance products.

Roughly 83% of enterprise workloads have moved to the cloud, according to a 2020 survey from LogicMonitor. But the cloud remains vulnerable to cyberattacks. IBM found last year that the average time to identify a breach was 206 days. Meanwhile, security breaches have increased by 11% since 2018 and 67% since 2014, Accenture reported in a recent study.

Sonrai offers a platform called Sonrai Dig to help companies stay ahead of threats. The platform is built on a graph that identifies and monitors relationships between entities (e.g., admins, roles, compute instances, serverless functions, and containers) and data within public clouds and third-party data stores. An engine automates workflow, remediation, and prevention across cloud and security teams to provide baseline security. At the same time, it provides critical data in object stores like AWS S3 and Azure Blog priority to address suspicious activity and access rights monitoring.

Sonrai’s data governance automation solution helps integrate teams via analyses, alerts, and actions that align with the way organizations use the public cloud. The platform allows customized monitoring and views for development, staging, and production workloads and an API architecture that can be integrated into a continuous integration/continuous development process. Dig also automatically dispatches prevention and remediation bots and provides safeguards in the form of code promotion blocks to provide end-to-end security in public cloud platforms.

Sonrai CEO Brendan Hannigan, formerly a general manager of security at IBM, says improperly configured cloud interdependencies and inheritances can lead to significant security risks. These include excessive access paths to data, over-permissioned identities, and an unwieldy separation of responsibilities. Hannigan estimates that enterprises’ public cloud utilization generates hundreds of cloud accounts, thousands of data stores, and tens of thousands of ephemeral pieces of compute — complexity that legacy cloud security tools have failed to address.

Hannigan won’t disclose Sonrai’s customers, but he says the platform can scale to thousands of roles and compute instances across hundreds of corporate accounts. “The increasing frequency of cloud breaches caused by identity and data access complexity has driven significant traction for our … platform among large enterprises,” Hannigan added. “They see it as the basis of their cloud security model.”

Menlo Ventures led today’s series B round, with participation from Polaris Partners and Ten Eleven Ventures. It brings the New York-based company’s total raised to over $ 38.5 million, following an $ 18.5 million series A round in January 2019.

Let’s block ads! (Why?)

Big Data – VentureBeat

What are Windows virtualization-based security features?

October 11, 2020 BI News and Info

Published: 17 Feb 2020

Windows administrators must maintain constant vigilance over their systems to prevent a vulnerability from crippling their systems or exposing data to threat actors. For shops that use Hyper-V, Microsoft offers another layer of protection through its virtualization-based security.

Virtualization-based security uses Hyper-V and the machine’s hardware virtualization features to isolate and protect an area of system memory that runs the most sensitive and critical parts of the OS kernel and user modes. Once deployed, these protected areas can guard other kernel and user-mode instances.

Virtualization-based security effectively reduces the Windows attack surface, so even if a malicious actor gains access to the OS kernel, the protected content can prevent code execution and the access of secrets, such as system credentials. In theory, these added protections would prevent malware attacks that use kernel exploits from gaining access to sensitive information.

Code examining, malware prevention among key capabilities

Virtualization-based security is a foundation technology and must be in place before adopting a range of advanced security features in Windows Server. One example is Hypervisor-Enforced Code Integrity (HVCI), which examines code — such as drivers — and ensures the kernel mode drivers and binaries are signed before they load into memory. Unsigned content gets denied, reducing the possibility of running malicious code.

Other advanced security capabilities that rely on virtualization-based security include Windows Defender Credential Guard, which prevents malware from accessing credentials, and the ability to create virtual trusted platform modules (TPMs) for shielded VMs.

In Windows Server 2019, Microsoft expanded its shielded VMs feature beyond the Windows platform to cover Linux workloads running on Hyper-V to prevent data leakage when the VM is both static and when it moves to another Hyper-V host.

New in Windows Server 2019 is a feature called host key attestation, which uses asymmetric key pairs to authenticate hosts covered by the Host Guardian Service in what is described as an easier deployment method by not requiring an Active Directory trust arrangement.

What are the virtualization-based security requirements?

Virtualization-based security has numerous requirements. It’s important to investigate the complete set of hardware, firmware and software requirements before adopting virtualization-based security. Any missing requirements may make it impossible to enable virtualization-based security and compromise system security features that depend on virtualization-based security support.

At the hardware level, virtualization-based security needs a 64-bit processor with virtualization extensions (Intel VT-x and AMD-V) and second-level address translation as Extended Page Tables or Rapid Virtualization Indexing. I/O virtualization must be supported through Intel VT-d or AMD-Vi. The server hardware must include TPM 2.0 or better.

System firmware must support the Windows System Management Mode Security Mitigations Table specification. Unified Extensible Firmware Interface must support memory reporting features such as the UEFI v2.6 Memory Attributes Table. Support for Secure Memory Overwrite Request v2 will inhibit in-memory attacks. All drivers must be compatible with HVCI standards.

Dig Deeper on Microsoft Hyper-V management

Related Q&A from Stephen J. Bigelow

Regression testing vs. UAT: Goals and techniques

Regression tests and UAT ensure software quality and both require a sizeable investment. Learn when and how to perform each one, and some tips to get…
Continue Reading

Functional vs. nonfunctional requirements in software engineering

Learn the meaning of functional vs. nonfunctional requirements in software engineering, with helpful examples. Then, see how to write both and build …
Continue Reading

Software performance testing requirements and prerequisites

Just because software passes functional tests doesn’t mean it works. Dig into stress, load, endurance and other performance tests, and their …
Continue Reading

Let’s block ads! (Why?)

SearchSQLServer

China proposes global data security standards

September 8, 2020 Big Data

(Reuters) — China announced an initiative on Tuesday to establish global standards on data security, saying it wanted to promote multilateralism in the area at a time when “individual countries” were “bullying” others and “hunting” companies.

The announcement, by State Councillor Wang Yi, comes a month after the United States said it was purging “untrusted” Chinese apps under a program dubbed “Clean Network”.

China’s initiative calls for technology firms to prevent the creation of so-called backdoors in their products and services that could allow data to be obtained illegally, as well as for participants to respect the sovereignty, jurisdiction and data management rights of other countries.

It also calls for participants to not engage in large-scale surveillance of other countries or illegally acquire information of foreign citizens through information technology.

It did not detail the nature of the initiative or say whether any other country had joined.

“Global data security rules that reflect the wishes of all countries and respect the interests of all parties should be reached on the basis of universal participation by all parties,” Wang said.

“Some individual countries are aggressively pursuing unilateralism, throwing dirty water on other countries under the pretext of ‘cleanliness’, and conducting global hunts on leading companies of other countries under the pretext of security. This is naked bullying and should be opposed and rejected.”

China tightly controls and censors its own cyberspace through the popularly dubbed Great Firewall, which has for years restricted access to firms such as U.S. majors Twitter, Facebook and Google owner Alphabet.

The administration of U.S. President Donald Trump has taken aim at Chinese giants such as Huawei Technologies, Tencent Holdings and TikTok owner ByteDance, citing concerns over national security and the collection of personal data, which the companies have rejected.

It has blocked U.S. exports to Huawei and plans to ban TikTok in the United States this month unless ByteDance sells TikTok’s U.S. operations.

(Reporting by Gabriel Crossley and Ryan Woo in Beijing, Brenda Goh in Shanghai; Editing by Muralikumar Anantharaman and Christopher Cushing)

Let’s block ads! (Why?)

Big Data – VentureBeat

How Do You Know Your Power BI Security Roles are Right?

August 27, 2020 Self-Service BI

You need insights from your data, but you don’t want the wrong people seeing data that’s confidential or outside their responsibilities. In the Power BI service, there’s a robust way of ensuring that the right people get the data that they need for their purposes: row-level security (RLS). It’s a set of filters that only gives people those rows that they need according to their role. These roles are creating in Power BI Desktop and mapped in Power BI Service to users, or better, security groups. I don’t want to talk about the technical aspects of setting up RLS. There’s plenty of resources online on how to set this up (I’ve learned a lot from Reza Rad, for example). Instead, I’d rather open up a discussion about auditing security in Power BI reports.

If you can ask, how do we know that we are improving, you should also be able to ask how do we know that the security roles are implemented correctly. Data culture is not just for the business, but for the reporting team as well. I haven’t seen much discussion of auditing security roles in Power BI circles, so I’m genuinely curious about how others tackle this issue. Does everyone simply work hard and hope for the best? Or do you restrict everything at the database level and use different apps for different groups instead? There may even be regulatory reasons which require you to restrict it at the database level. But even if you do restrict everything at the database level, you still need to validate that security as well.

Personally, I LOVE Power BI RLS (and folks on Twitter agree). It enables me to carve out the data for those who need it without the report creep which happens with maintaining dozens of siloed reports. To ensure that roles are correctly configured, however, I’ve had to do some significant work. Wrong row-level security can be not only embarrassing, but costly as well. It can expose an organization to legal liability or put the organization at a competitive disadvantage. Because security roles can be high stakes, they need a comprehensive suite of approaches to administer them. This is definitely an area for growth in the Power BI offering.

Here are some ways that I’ve reviewed Power BI security roles:

an Excel workbook with each role, table, and DAX rule (Excel to the rescue!).
Double checking in Power BI Desktop that each role is correct by comparing the rules for each role and table to the Excel workbook. Should we take screenshots of each rule?
As report creator, testing as Role for each role in Power BI Desktop.
As administrator testing as Role for each role in Power BI Service.
Create measures specifically for RLS that are put onto a tab in the dataset containing the data (either a hidden tab or a tab on the original dataset). This makes Testing as Role quicker.
Power BI reports that get data from Active Directory to show what users are in what groups, powered by unique naming conventions to show only Power BI security groups. This makes it easy for any team member to notice anomalies. Example: Red Team PBI role is mapped to Red Team PBI security group.
Automatic testing with process automation. There are many possibilities with this tactic.

How would I like to verify role security in Power BI?

View as role in Power BI Service for anyone in a role where there are no filters on any tables. This would enable others who aren’t report authors to check security, making the roles transparent to business users who need to verify the correct roles but aren’t report creators or Power BI administrators.
Export security roles from Power BI Desktop. This would facilitate rapid review at the time of report creation and updating.
Administrators extract the security roles from Power BI Service. This would enable auditing of the security roles in place.

The good news is that I’ve figured out how to do #2. I can now export security roles for Power BI Desktop. I have template file called RLS localhost.pbit on GitHub. It works like this:

Open a report in Power BI Desktop
Open up DAX Studio (the latest version with External Tools makes this a breeze).
Run a query to get the catalog_name and look at the localhost number at the bottom of DAX Studio.
Open up RLS localhost.pbit and put in the localhost number and catalog_name.
You’ll need to authenticate your access with your Office login.
Wait for report to refresh.
Most likely, you’ll want to enable native queries and ignore privacy in the settings to prevent having to ok each native query and to avoid the formula firewall error.

Security role report looks like this:

How Do You Know Your Power BI Security Roles are Right?

The report lets me see if the roles make sense and are consistent. On the page shown, there’s one table for Role Name, with the tables that are directly filtered by that role. If tables filtered is less than the max for roles, then conditional formatting shows the gap. The second table lists each table in the model, how many roles reference it, if it has a direct restriction or not, and what tables indirectly filter it. Date table is highlighted to show that it’s not filtered directly or indirectly. Region and Salesperson tables are both filtered directly by three roles each. Sales is filtered indirectly by Region and Salsesperson tables. The cards at the top of the page show number of roles, total tables, and how those tables are filtered.

The report documents security roles for 1-to-many relationships in Power BI models. Many-to-many relationships not supported. Bi-directional filtering and bi-directional security not supported. Inactive relationships not supported. I can finally export all of my security roles from this report, including a local timestamp of when they were extracted. The report uses a method described by Chris Webb: Analysing Power BI DMV Queries In Power BI Desktop. The report uses a live connection and can only be refreshed in Power BI Desktop.

What about you?

How do you review your security roles? How would you like to review them? Are there things you do that I haven’t mentioned? How can we help each other to be more transparent, more accountable, and more evidence based in our reporting practices?

Let’s block ads! (Why?)

Security and PowerPack Add-ons

August 22, 2020 Microsoft Dynamics CRM

As part of PowerObjects’ ongoing commitment to quality and service, we review our systems on a regular schedule to keep up with security changes in the Dynamics 365 platform. In today’s blogpost, we’re outlining upcoming changes to our PowerPack add-ons that will allow us to meet the current Dynamics 365 security requirements and TLS 1.2 (Transport Layer Security, version 1.2) security protocols.

Source

Let’s block ads! (Why?)

PowerObjects- Bringing Focus to Dynamics CRM

Storage 101: Data Security and Privacy

July 23, 2020 BI News and Info

The series so far:

Most discussions around storage inevitably lead to the topics of data security and privacy. You cannot operate in today’s climate without careful attention to both. If data protection is not built into your storage infrastructure, you’re doing something wrong.

Data protection is an ongoing, organization-wide effort in which storage plays a key role. A secure storage infrastructure is essential to safeguarding sensitive information. Even so, it takes more than secure storage to guarantee the data’s safekeeping throughout its lifespan. For that, an organization needs a comprehensive data protection strategy that takes into account all aspects of data management, including how data is stored.

Securing Data and Protecting Privacy

For many organizations, their most important asset is their data, the bulk of which must be protected against unauthorized access. The data might include intellectual property, legal documents, passwords, encryption keys, personally identifiable information (PII), or a variety of other sensitive material.

An organization that handles sensitive data should have a comprehensive data protection strategy in place to contend with potential threats. Unfortunately, the exact meaning of data protection is not always clearcut and can vary depending on usage and circumstances. It might refer to securing data, safeguarding privacy, protecting storage systems, implementing disaster recovery (DR), or any combination of these.

According to the SNIA (formerly the Storage Networking Industry Association), data protection is the “assurance that data is not corrupted, is accessible for authorized purposes only, and is in compliance with applicable requirements.” In other words, data protection goes beyond just encrypting data or guaranteeing its availability. Data protection ensures that the data remains viable, is safeguarded against all unauthorized access at all times, and is controlled in a way that adheres to applicable compliance laws and regulations, e.g., local, provincial, and federal.

In this view of data protection, storage security is only part of a larger effort to keep sensitive data out of the wrong hands, while ensuring its accuracy and availability to authorized users. To this end, you’ll sometimes see storage security described in terms of confidentiality, integrity, and availability—or CIA—which go hand-in-hand with the larger goal of data protection.

A comprehensive data protection strategy ensures both data security and data privacy. Although the two are related, they’re not the same. Data security protects sensitive information from unauthorized access and from loss and corruption, whether intentional or accidental. Data privacy refers to the appropriate handling of PII and the rights of individuals to control and access their personal information.

With the increasing number of regulations that govern PII, organizations are under greater pressure than ever to protect confidential information and provide a full accounting of how it’s managed. Regulations can vary from region to region and differ significantly. Many organizations operate across multiple regions, making them subject to a mix of governing laws. The General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA), Children’s Online Privacy Protection Act (COPPA), and California Consumer Privacy Act (CCPA) are only some of the regulations that organizations now face. Even if an organization operates in only one region, they can still be subject to a confusing mix of laws.

Despite the differences between regulations, however, they all have one thing in common: to implement strict security controls that ensure personal information cannot be compromised when under the organization’s control. Most also define other obligations, such as retention or auditing requirements, but data protection lies at the heart of each one, which is why data security and privacy are intrinsically linked.

The Cybersecurity Threat Landscape

Data is not only an asset. It’s a burden. A data breach can lead to lost revenue, stiff penalties, downtime, legal liabilities, loss of intellectual property, unexpected expenses, and a tarnished reputation from which a company might never recover. No organization is immune to the potential threats that await them, from both inside and outside their domains.

External threats can come from governments, organized crime, terrorists, cybercriminals, competitors, or everyday hackers looking for a bit of sport or profit. And threats can arrive in many forms, often implemented through social engineering strategies that attempt to introduce malware or ransomware or steal user credentials.

word image 48 Storage 101: Data Security and Privacy

Figure 1. The challenges of data security (image by madartzgraphics)

Attackers might also go after an organization’s networks or systems directly, leveraging vulnerabilities to carry out SQL injections, denial-of-service attacks, or other nefarious acts in an attempt to steal data or bring down operations. Their reasons for attacking an organization can vary. They might want to damage the organization’s credibility, acquire sensitive information for competitive advantages, access government secrets, or make money by selling stolen data or locking up systems until a ransom is paid.

Many organizations and even people have fallen victim to cybercrime, ranging from individuals, household, and small municipalities to multinational corporations, including Twitter, Facebook, Yahoo, Equifax, eBay, LinkedIn, and Marriot International. And the threats don’t only come from external players. Organizations must also guard against internal threats, whether from disgruntled or greedy employees, malicious insiders, or careless staff falling victim to weak IT security policies. Data compromised as a result of internal behavior can be just as devastating as an external attack.

Many organizations are also turning to the cloud to store data and support their workloads. Although cloud platforms can often be more secure than an organization’s own environment, they also add storage and data complexity, while increasing data exposure. An organization must rely completely on the provider to ensure that data is being protected from internal and external threats. At the same time, the cloud raises compliance concerns, especially when spanning multiple regions.

Organizations must also contend with the increased risks that come with a remote workforce, whose numbers have grown dramatically with COVID-19. The more people working offsite, the more difficult it becomes to ensure that sensitive data is not being exposed when it is transferred or stored. A home worker might use an unsanctioned cloud service, mislay a peripheral device that contains business data, collaborate on a project through an unsecure platform, or engage in other risky behavior. Even under the best circumstances, few home offices can achieve the same level of physical security you get in a data center.

Implementing a Data Protection Strategy

To ensure data security and privacy, you need a comprehensive plan that specifies how data will be protected both at rest and in motion. As part of this process, you should develop policies that define where data can be stored, who can access it, and what levels of protection the data requires. The policies should also address such issues as when data is deleted, what happens when an employee is terminated, how to handle a data breach and any other issues related to data protection.

Another important part of the planning process is to conduct a thorough assessment of your current data environment to identify potential risks and the steps that must be taken to mitigate those risks. You need to know where sensitive data is located, how it’s being used, and who can access it. You should also look for issues such as whether sensitive data is being transmitted as cleartext, credentials are being sent in an unencrypted format, or users are accessing internal web services via insecure HTTP.

From this assessment, you’ll have a good sense of what data you have and where it’s located. You can then classify the data based on security and compliance requirements. This will help you determine what levels of access to assign to each data type, as reflected in your security policies. Public data, for example, requires far less security than data covered by HIPAA or the GDPR or data governed by national security laws.

If your organization is subject to multiple regulations, you might consider a protection-by-default approach for personal data, rather than trying to create too many data classifications. For example, one regulation might require that you protect user IP addresses, while another does not. It might be better to create a single category that covers both. Too many data categories, which can complicate data management, may lead to a greater risk for regulatory violations.

A simpler category structure can also make it easier to address other compliance-related issues, such as providing users with visibility into their PII or supporting their deletion requests. At the same time, you must still take into account issues such as data retention and disposal requirements, which might force you to create additional categories.

Another part of the planning process is to ensure that you have the tools you need to safeguard your systems and their data. For example, you might implement a data loss prevention (DLP) solution to help automatically discover, monitor, and protect sensitive data. You might benefit from an intrusion detection system (IDS) that identifies traffic anomalies and warns you if something doesn’t look right.

Essential tools for protecting your data include anti-malware, anti-ransomware, and anti-spyware, as well as protections such as firewalls and proxy servers. And, of course, you want to be sure you deploy the proper storage protections. For example, you might implement RAID and other redundancies to provide storage fault tolerance, which can help protect against intentional or unintentional data destruction.

There are plenty of other tools as well. Just remember that no one solution can address all your data protection requirements, and you’ll have to come up with just the right mix to meet your specific needs.

Protecting Data and Privacy

Data protection must take into account both physical and operational security. Physical security ensures that unauthorized individuals cannot access the physical structures where the data is housed or the equipment within those structures. It also protects against circumstances that could lead to data loss, such as power failures or natural disasters. To implement physical security, an organization might employ backup and restore protocols, CCTV monitoring, biometric readers, geofencing, backup generators, and numerous other protections.

Organizations must also protect the individual systems within their secure structures, such as servers or workstations. No one on the inside should be able to walk off with equipment or get at their internal workings unless they’re authorized to do so. IT teams must also take steps to protect portable devices that leave the premises, such as laptops, tablets, or cell phones. This typically means implementing a mobile device management strategy that supports such features as remote lock or remote wipe.

In addition to ensuring the physical security, organizations must implement operational protections, which provide the technical safeguards necessary to protect the data itself. This starts with using advanced algorithms to encrypt sensitive data both at rest and in motion. In addition, IT teams might consider such tools as tokenization or data masking for further protection. They should also have in place a system for securely storing and managing encryption keys.

Another important component of operational security is role-based access control, which determines who can and who cannot view or modify specific sets of data. Access should be based on the principle of least privilege, that is, individuals should be granted only the access they need to do their jobs—and no more. In conjunction with access control, IT should also implement such safeguards as multi-factor authentication or virtual private networks (VPNs), as appropriate, to further protect data access.

An effective data protection strategy also requires a comprehensive infrastructure for continuously monitoring sensitive data, issuing real-time alerts, and generating comprehensive reports on-demand. All data access and modifications should be logged, with an auditing system in place to determine who accessed what data and when that access took place.

Operational protections also include DR systems that ensure data can be made available in the event of data loss or corruption, no matter what the cause. At the same time, IT must be careful that their DR mechanisms, such as backups or replication, don’t violate applicable regulations. Also, they must ensure that PII can be accessed in a timely manner, if required by law, and that it adheres to retention and disposition rules.

The Ongoing Challenges of Data Protection

To implement effective data protections, an organization must take into account the entire data lifecycle, regardless of how the data is being used or where it resides—whether on a remote workstation, on a mobile device, in a data center, on a cloud platform, at a remote facility, or on a server in an office corner. Data protection must be a unified effort that moves beyond infrastructure boundaries to ensure that data is secure, and privacy is protected at all times and under all circumstances.

One of the most important tools that organizations have for protecting data is an effective training and education program that helps employees understand the risks involved with handling data and the steps they can take to minimize those risks. Everyone in an organization should have a clear understanding of that organization’s data usage policies and how best to protect sensitive data. All it takes is one careless act to create a data nightmare.

Data protection is an ongoing, all-encompassing process that extends from the backend storage systems to the smartphones that employees carry in their pockets. Storage security is an integral part of this process and can serve as your last line of defense against intrusion. That said, storage security cannot protect against all risks, just like a firewall alone can’t eliminate all network threats. Any place where data might reside or that provides a means for its access should be considered a potential risk and dealt with accordingly.

Let’s block ads! (Why?)

SQL – Simple Talk

Why Millennials Prefer the Security of Microsoft Dynamics Over Other CRM Systems

May 16, 2020 CRM News and Info

With so many privacy scandals making headlines, the current workforce well understands the importance of security. Choosing a system that provides this protection for employees and customers is essential for Millennials, who make up the majority of modern employees.

Microsoft Dynamics is a leader in global security. Microsoft delivers layered security in all applications to allow workers to do their best work anywhere with full confidence. Consider briefly how Microsoft Dynamics provides the security needed for any company:

Security anywhere

Microsoft Dynamics provides physical and virtual security. These include access control, encryption, and authentication. This helps protect data on all devices whether it be mobile phones, tablets, or computers. Role-based security defines access to system data no matter where they are working.

Intelligent security

As security risks continue to rapidly grow, modern workers not only want but expect the systems they work with to be protected. Microsoft Dynamics meets these expectations by using billions of data points globally to engineer techniques and apply intelligence to progressively improve security.

Protect customer data

Employees today want to be confident that the data they collect from customers is secure and fully protected. Microsoft Dynamics keeps this data safe by preventing the disclosure of all personal and financial information. This makes it easy to maintain customer loyalty and comply with industry regulations.

Thomas Berndorfer, CEO of Connecting Software trusts Microsoft Dynamics to be completely secure in handling his company’s sensitive information. He says: “Dynamics 365 provides a robust data security model, and add-on products ensure data protection between D365 and other Microsoft apps.”

Would you like to see how they use Microsoft Dynamics’ security could benefit your business?

Read this and 18 other reasons why Millennials prefer Microsoft Dynamics in the workspace by downloading the full eBook “21 Reasons Millennials Prefer Microsoft Dynamics” at www.crmsoftwareblog.com/millennials to read 17 more reasons why Millennials prefer Microsoft Dynamics in the workspace.

Find a Microsoft Dynamics 365 Partner

By CRM Software Blog Writer, www.crmsoftwareblog.com

Let’s block ads! (Why?)

CRM Software Blog | Dynamics 365

Get User Security Role Name from context in Dynamics 365 CE

April 20, 2020 Microsoft Dynamics CRM

Microsoft Dynamics 365 CE/CRM now has a more streamlined method to get the running users security role name without having to make a client-side API call. In the spring of 2020 there has been an update to the SDK to mark the deprecation of userSettings.securityRoles. It has been replaced with userSettings.roles.

Get User Security Role Name from context in Dynamics 365 CE

userSettings.roles provides not only the security role guids from the global context, but the security role names as well.

A common design pattern in use today is to enable/disable or hide/show client-side form attributes as a part of controlling a business logic form flow. This has been achieved with a JavaScript WebResource in several different patterns. The challenge is that quite a few patterns can cause poor client-side performance, especially in high latency environments. Here are some example conversations from the Microsoft Dynamics CRM Forum community on the subject:

If you are fortunate enough to have engaged with a Dynamics 365 CE/CRM DSE or a Microsoft in a Performance Delivery, you may have been provided a sample JavaScript pattern using browser caching that alleviated unnecessary Web API calls.

Hiccup Note: While writing this blog I uncovered a bug where the name values are incorrect when an Owner Team is providing additional security roles. There is already a bug in place and is targeting the 4.4 train (end of May 2020) release. In mean time feel test on a development environment in preparation for the bug fix release. I will be updating this blog to remove this statement one the the fix has reached North America. Please check back and/or follow this blog post for updates.

So let’s take a look at a JavaScript sample that uses the new userSettings.roles

Get User Security Role Name from context in Dynamics 365 CE

Add a JavaScript web resource.

Add the web resource as a reference on a Case form.

Publish the changes.

Identify a test user with security roles for testing.

Open a Case record.

Now we can inspect the Developer Tools (F12) in the browser (example here in Microsoft Edge based on Chromium). Note: you might need to refresh the form with a Shift+F5 to replay the form load.

We see we get the global context and inspect userSettings.roles by hovering the cursor over roles.

5857 Get User Security Role Name from context in Dynamics 365 CE

By expanding _collection: we see the running user security role guids …

8585 Get User Security Role Name from context in Dynamics 365 CE

And if we scroll to the right we see the corresponding security role name …

1185 Get User Security Role Name from context in Dynamics 365 CE

Let’s block ads! (Why?)

Dynamics 365 Customer Engagement in the Field

Tag Archives: Security

Physical security: Who can walk in the door?

Data file security: Who can get in your files?

Keep your SQL Servers as current as possible

Server and database security

Finding permissions

Be your authentic(ated) self

Security monitoring

Dangerous coding practices

Dynamic SQL

xp_cmdshell

Remote queries

CLR

User-owned schemas, jobs, databases (or anything)

Auditing

Were you born in a barn? Shut the door!

What do I do if my company has a data breach?

Conclusion

Code examining, malware prevention among key capabilities

What are the virtualization-based security requirements?

Dig Deeper on Microsoft Hyper-V management

Related Q&A from Stephen J. Bigelow

Here are some ways that I’ve reviewed Power BI security roles:

How would I like to verify role security in Power BI?

Security role report looks like this:

What about you?

Securing Data and Protecting Privacy

The Cybersecurity Threat Landscape

Implementing a Data Protection Strategy

Protecting Data and Privacy

The Ongoing Challenges of Data Protection

Recent Posts

Categories

Archives