During the third day of MS Ignite 2017, I looked for sessions focusing on security.

In the data protection paradigm, we see MS supporting GDPR compliance by a new tool for SQL Server. It should be obvious for every company that client sensitive data needs to be protected. No company wants the reputational or financial harm a data breach can result to. But the numbers tell different. On a yearly basis 2 billion records are lost which boils down to a staggering 5 million a day. No wonder we distrust companies and the EU started regulating this topic as apparently self-regulation in industry failed.

MS created a model and tooling to support clients to achieve GDPR compliance. The model is a simple 4 step approach going form 1. discover and 2. manage over 3. protect to 4. report. To achieve general GDPR compliance a company must:

• know what data it stores as client can ask for disclosure
• control the access and record the manipulations the data went through
• protect the date it stores against unintended use, malicious manipulation or uncontrolled
• disclosure
• receive consent from the subject the data applies to, to store his data
• have procedures in place that apply and document policies to guarantee the previous mentioned points
• to report on the policies that are in place, the application of the policies (pro-active) and any breach (retro-active) that was detected

For SQL server a lot of the above points are part of generally applied best practices. SQL has centrally managed authentication and authorization capabilities. Data stored in SQL can be encrypted and dynamically masked so the data in rest is not vulnerable when accidently lost. Firewalls can protect the DB to be accessed only by a whitelisted set of applications and endpoints. SQL auditing gives an overview how records were changed and by who. Data in motion can be protected by encrypting communication channels. Date in use can be masked and restricted for a specific set of clients.Although all these earlier mentioned technologies are great, it does not protect against anything if the best practices are not enforced. Here the new SQL Vulnerability Analyzer aka SQL VA comes in the picture. The tool has as a two-fold goal:

•  Scan whether best practices were applied or not
• Scan for sensitive data and apply data protection

The SQL VA scan will give information per table per column on the data category and the protection status. The initial scan forms the baseline on which exceptions (deviations) with regards to best practices can be applied. Later scans will help to identify if policies are enforced correctly and whether we are doing worse than the baseline so mitigation actions are required.

Beside GDPR for the typical authentication – authorization paradigm, MS introduces features for federated security in Office 365. MS Authentication Library (MSAL) allows separated security models for plugins added to Office. This is a more fine-grained approach compared to before, where we had an all or nothing strategy: before either the security was equal to what Office and inherently the user could do or either it could do nothing i.e. It was considered insecure. MSAL allows to implement per component access control by using the component’s host (the place where you downloaded the component from) to implement and host the security middleware in. The host is then seen as an external API requesting authorization for certain business activities.