change nav 1-patterns formatting

content/NAVPatterns/1-patterns/security/1-sensitive-data-encapsulation/index.md

@@ -1,9 +1,7 @@
 +++
-title = "1-sensitive-data-encapsulation.md"
+title = "Sensitive Data Encapsulation"
 weight = 120
 +++
-## Sensitive Data Encapsulation
-
 _By Bogdana Botez at Microsoft Development Center Copenhagen_
 
 _  
@@ -40,7 +38,7 @@ To apply this pattern in Dynamics NAV, a table structure similar to Table 1261 S
 Figure 1 describes the definition of a table which is already available in Dynamics NAV. This table can be used for storing sensitive data. As a minimum, the table only needs two fields:
 
 1. The key is of type GUID (Globally Unique Identifier), which is a 128-bit value consisting of multiple groups of hexadecimal digits \[2\]. Each key needs to be unique and will be used for storing and retrieving the protected information.
-2. The value (the actual data to be encapsulated) is of type BLOB (Binary Large OBject) \[3\], which contains the encrypted or un-encrypted data (for encryption, see the related [**Encryption** ][anchor2]pattern).
+2. The value (the actual data to be encapsulated) is of type BLOB (Binary Large OBject) \[3\], which contains the encrypted or un-encrypted data (for encryption, see the related [**Encryption**][anchor2] pattern).
 
 [![Figure 1- Example definition, table used for Data Encapsulation][image1]][anchor3]
 
@@ -72,13 +70,13 @@ _Figure 2 - Data access before and after **Sensitive** **Data** **Encapsulation.
 
 * **Clarity:** when all sensitive data is encapsulated in one place, it is clear which is the information that needs to be protected.
 * **Simplicity:** easier to protect just a limited number of known resources when they are grouped.
-* **Homogeneity: **the same protection can be applied to all data, since it is stored in the same place.****
-* **Separation of concerns: **treat each section of the computer program differently, by separating it and clearly addressing its own requirements and limitations. \[1\]
-* **Performance**: data protection techniques like **Access Control** and **Encryption **can now be applied only to the sensitive data (not to everything), which improves the performance of the system.
+* **Homogeneity: **the same protection can be applied to all data, since it is stored in the same place.
+* **Separation of concerns:** treat each section of the computer program differently, by separating it and clearly addressing its own requirements and limitations. \[1\]
+* **Performance**: data protection techniques like **Access Control** and **Encryption** can now be applied only to the sensitive data (not to everything), which improves the performance of the system.
 
 **Drawbacks:**
 
-* **Single point of failure:** a maliciously intended actor has no longer a need to reverse engineer the places where important data is stored. In the unwanted situation when this actor would have already obtained access to the system, they can more easily locate the sensitive information. This is a step towards information disclosure, but mechanisms like [**Encryption** ][anchor2]and logging can provide further protection.
+* **Single point of failure:** a maliciously intended actor has no longer a need to reverse engineer the places where important data is stored. In the unwanted situation when this actor would have already obtained access to the system, they can more easily locate the sensitive information. This is a step towards information disclosure, but mechanisms like [**Encryption**][anchor2] and logging can provide further protection.
 * **Limited Text Length**: there is a limit on how long the encrypted text can be. This limit is imposed by the OS encryption service and it depends on the composition of the text as well as on the system specifics. In NAV, we had implemented the Encrypted Text for text values of max 250 chars, which is enough to cover passwords, person ID numbers, credit card info, but it might turn insufficient in other future scenarios.
 * **Nomenclature**: the name of the table **Service Password** is too specific, since it started by being used for passwords, but it has the capability and it now contains other sensitive data like API Keys, credit card numbers etc.
 

content/NAVPatterns/1-patterns/security/2-data-encryption/index.md

@@ -1,9 +1,7 @@
 +++
-title = "2-data-encryption.md"
+title = "Data Encryption"
 weight = 140
 +++
-## Encryption
-
 _By Bogdana Botez at Microsoft Development Center Copenhagen_
 
 __
@@ -38,9 +36,9 @@ _Figure 1- **Encryption** becomes easier after first applying [**Sensitive Data
 
 Table 1- Encryption functionality in Dynamics NAV (found in codeunit 1266 Encryption Management)
 
-**Procedure******
+**Procedure**
 
-**Description******
+**Description**
 
 **EnableEncryption**
 
@@ -140,7 +138,7 @@ _Figure 6- The administrator chooses a strong password._
 
 In the end, Stan chooses a location for the encryption key on disk, in a standard file save dialog. The layout of the file save dialog depends on the display target used (web browser, rich client etc.).
 
-**NAV Usages. **Encryption examples can be found in NAV in the following places:
+**NAV Usages.** Encryption examples can be found in NAV in the following places:
 
 * Page 1260 Bank Data Conv. Service Setup
 * Page 1270 OCR Service Setup
@@ -154,7 +152,7 @@ In the end, Stan chooses a location for the encryption key on disk, in a standar
 **Anti-patterns:**
 
 * **Performance:** Do not encrypt everything, because it will have a performance impact on the system. Only important information should be encrypted.
-* **System calls and "Do It Yourself" solutions**: Although system calls for encryptions are available in NAV (ENCRYPT, DECRYPT and <action\>ENCRYPTIONKEY), unless there is no other way, refrain from using them directly. Use instead he API in codeunit 1266 Encryption Management, which is safer to use, because it protects against common mistakes (like attempting to encrypt an already encrypted string, enabling encryption in only one company which makes data not usable in another on the same tenant etc.). Use the [**Single Point of Access **][anchor9]pattern to handle sensitive data which needs to be encrypted.
+* **System calls and "Do It Yourself" solutions**: Although system calls for encryptions are available in NAV (ENCRYPT, DECRYPT and <action\>ENCRYPTIONKEY), unless there is no other way, refrain from using them directly. Use instead he API in codeunit 1266 Encryption Management, which is safer to use, because it protects against common mistakes (like attempting to encrypt an already encrypted string, enabling encryption in only one company which makes data not usable in another on the same tenant etc.). Use the [**Single Point of Access**][anchor9] pattern to handle sensitive data which needs to be encrypted.
 * **System-level encryption.** The similar codeunit API 1803 Encrypted Key/Value Management is not intended to be reused by partner NAV developers. Normal NAV users do not have permission to access this resource. This stores sensitive data to be accessed by system NAV functionality.
 
 **References**

content/NAVPatterns/1-patterns/security/3-single-point-of-access/index.md

@@ -1,9 +1,7 @@
 +++
-title = "3-single-point-of-access.md"
+title = "Single Point of Access"
 weight = 160
 +++
-## Single Point of Access
-
 _By Bogdana Botez at Microsoft Development Center Copenhagen_
 
 _[![ ][image0]][anchor0]   
@@ -19,8 +17,8 @@ __
 
 **Forces:**
 
-* **Code duplication: **if each entity attempts to write its own routines for data access, invariably this will bring duplication.
-* **No knowledge reuse: **if a bug is found and fixed in one of the implementations, there is no guarantee that all the other implementations will be updated. For example
+* **Code duplication:** if each entity attempts to write its own routines for data access, invariably this will bring duplication.
+* **No knowledge reuse:** if a bug is found and fixed in one of the implementations, there is no guarantee that all the other implementations will be updated. For example
   * **Double-Encryption**: lack of care or knowledge could lead a NAV developer to attempt to double-encrypt strings, which would render them unusable.
   * **Multi-company configuration \[4\]**: in NAV, it is possible to store multiple companies on the same tenant \[5\] database. A developer who has not investigated such a configuration and its consequences on encryption, can attempt to encrypt data in (for example) a Setup Table \[6\] of only one company, which would make this table unusable from any unencrypted company (since the server will observe that encryption is enabled, and try to retrieve it as it were enabled for all companies and fails).
   * **"Shotgun surgery" \[7\]:** one change in the data access technique (like a new requirement to validate the user's identity before viewing any protected data), calls for updates in every single implementation of data access, if multiple implementations exist. Hence, one change of requirement triggers multiple efforts to update the product.
@@ -33,7 +31,7 @@ You can observe that, in panel 3, each usage needs to access separately the encr
 
 [![ ][image1]][anchor4]
 
-_Figure 1- **Single Point of Access **pattern applied._
+_Figure 1- **Single Point of Access** pattern applied._
 
 This shows how pattern application is an iterative process, where one step follows another. Refactoring \[8\] the code to apply one pattern, cleans and clarifies the code and in some cases, makes clear the possibility of further refactoring.
 
@@ -43,9 +41,9 @@ This shows how pattern application is an iterative process, where one step follo
 
 * **Simplicity**: only one implementation exists.
 * **Knowledge reuse**: if a bug is found and fixed, there is just one place which needs to be repaired. Therefore, there is no risk that some of the usages would still be flawed by the same bug. For example:
-  * **Double encryption**: The**Single Point of Access** API already implements knowledge to avoid encryption of already encrypted strings.
-  * **Multi-company**: The**Single Point of Access** API already implements knowledge for handling encryption in a multi-company setup.
-  * **Easy maintenance**:****a change in specification needs only one code update.
+  * **Double encryption**: The **Single Point of Access** API already implements knowledge to avoid encryption of already encrypted strings.
+  * **Multi-company**: The **Single Point of Access** API already implements knowledge for handling encryption in a multi-company setup.
+  * **Easy maintenance**: a change in specification needs only one code update.
 
 **Consequences:**
 

content/NAVPatterns/1-patterns/security/4-masked-text/index.md

@@ -1,9 +1,7 @@
 +++
-title = "4-masked-text.md"
+title = "Masked Text"
 weight = 180
 +++
-## Masked Text
-
 _By Bogdana Botez at Microsoft Development Center Copenhagen_
 
 _[![ ][image0]][anchor0]  
@@ -25,7 +23,7 @@ __
 
 **Solution:** Use the "Masked" field property to display dots instead of characters on the sensitive text field in the UI.
 
-**Usage: **Figure 1 shows how an unmasked and a masked field look in Dynamics NAV. On page Microsoft Dynamics CRM Connection Setup, the first two fields (Dynamics CRM URL and User Name) are not masked. The next field (Password) is masked. As the user types text into the Password field, the characters are one by one replaced with dots. When the user had finished typing and had left the Password field (moved focus to another page element), then a pre-defined number of dots is showed in the field, no matter what the real length of the password is. This is done so that the length of the text is not disclosed. Hence, no matter if the text had 5, 10 or 20 characters, as soon as the user leaves the masked field, 10 dots will be visible.
+**Usage:** Figure 1 shows how an unmasked and a masked field look in Dynamics NAV. On page Microsoft Dynamics CRM Connection Setup, the first two fields (Dynamics CRM URL and User Name) are not masked. The next field (Password) is masked. As the user types text into the Password field, the characters are one by one replaced with dots. When the user had finished typing and had left the Password field (moved focus to another page element), then a pre-defined number of dots is showed in the field, no matter what the real length of the password is. This is done so that the length of the text is not disclosed. Hence, no matter if the text had 5, 10 or 20 characters, as soon as the user leaves the masked field, 10 dots will be visible.
 
 [![ ][image1]][anchor1]
 
@@ -33,11 +31,11 @@ _Figure 1 - The field "Password" is masked._
 
 To apply this pattern in Dynamics NAV, the developer has two choices:
 
-**1\. ****Mask everywhere**
+**1\.** **Mask everywhere**
 
 Mask the field in all pages which expose it or will expose it in the future. In this case, masking needs to be set at the table level, by opening the table in design mode and setting the field's property ExtendedDatatype=Masked.
 
-**2\. ****Mask only in selected pages**
+**2\.** **Mask only in selected pages**
 
 Mask the field in only a subset of pages. Open the pages where the field should be masked in design mode, open the property page for the field in question, and set ExtendedDatatype=Masked. This option can be used for example when a field should be hidden from most users (in most usual pages), but still visible to administrators in specific pages.
 

content/NAVPatterns/1-patterns/security/5-ssl-in-nav/index.md

@@ -1,9 +1,7 @@
 +++
-title = "5-ssl-in-nav.md"
+title = "SSL in NAV"
 weight = 190
 +++
-## SSL in NAV
-
 _By Bogdana Botez at Microsoft Development Center Copenhagen_
 
 _[![ ][image0]][anchor0]   
@@ -17,7 +15,7 @@ __
 
 **Forces:**
 
-* **Insecure communication: **When the user enters a password, if unprotected, a network sniffer \[12\] could catch and read it. A sniffer is either a software program or hardware device which examine network traffic. Years ago, sniffers were tools used exclusively by professional network engineers, but nowadays, they are also popular with Internet hackers and people just curious about networking.****A****public Wi-Fi network could easily be eavesdropped by an unwanted actor.
+* **Insecure communication:** When the user enters a password, if unprotected, a network sniffer \[12\] could catch and read it. A sniffer is either a software program or hardware device which examine network traffic. Years ago, sniffers were tools used exclusively by professional network engineers, but nowadays, they are also popular with Internet hackers and people just curious about networking. A public Wi-Fi network could easily be eavesdropped by an unwanted actor.
 
 By using data storage patterns like **Sensitive Data Encapsulation**, **Encryption, Single Point of Access** or **Azure Key Vault**, the sensitive data is preserved securely in the implementation of Dynamics NAV. But before it gets into a secure store, this data needs to be transmitted from the user, through a user interface, on a client-server connection and all the way to the database. Is the data safe while being transmitted?
 
@@ -31,9 +29,6 @@ Figure 1 shows data communication between the client (where the user enters data
 
 _Figure 1 - Data transmission before (http://...) and after SSL encryption (https://...)._
 
-_  
-_
-
 **Usage**: the latest information about how to configure SSL for the web client in Dynamics NAV is found online at on MSDN at [https://msdn.microsoft.com/en-us/library/hh167264(v=nav.90).aspx][anchor2].
 
 **Benefits:**

content/NAVPatterns/1-patterns/security/_index.md

@@ -2,12 +2,9 @@
 title = "Security"
 weight = 1030
 +++
-## **Security patterns for NAV  
-**
-
 _By Bogdana Botez at Microsoft Development Center Copenhagen_
 
-### ****
+## **Security patterns for NAV**
 
 ### **Problem statement**