Security Policy

MRT Security September 2019

Implementing security protocols is a balancing act between usability and data protection (Scarfone, Jansen, & Tracy 2008). Too much security can render a web-page unusable, and too little security can lead to unwanted data breaches (Ristić, 2017). To reduce the probability of a data breach, My Research Toolbox (MRT) uses several methods to protect user data from unwanted access. For example, all physical hardware (e.g., server, ram, drives), data at rest and in transit is encrypted. When data is at rest, it is not being transferred from one location to another. The concept of encrypting data at rest is similar to securing documents stored in a file cabinet. Data in transit refers to moving information from one location to another upon request. Securing digital information in motion from unauthorized viewings, modification, or theft is similar to placing documents inside a folder or a brief case while being transported.

The security methods implemented for all content present in MRT were modeled after guidelines published by the National Institute of Standards and Technology (NIST), OpenSSL Cookbook (Ristić, 2013), Bulletproof SSL and TLS (Ristić, 2015), SSL/TLS Deployment Best Practices (Ristić, 2017), Content Security Policy Level 3 (W3C; World Wide Web Consortium, 2018) and Mozilla’s web security guidelines and server side Transport Layer Security (TLS) guidelines (2019). A combination of other resources and third party tools such as ImmuniWeb (High-Tech Bridge SA, 2019), Qualys SSL Labs (2019), TLS/SSL Scanner (2019), Security Headers (2019), HSTS preload (2019), and Mozilla Observatory (2019) were used to evaluate and implement strong security settings while maintaining web-page usability.

After all security methods implemented were evaluated, the next step was to hack our selves to discover security vulnerabilities. The act of “hacking ourselves” is an active monitoring method implemented to discover any new vulnerabilities and patch them as quickly as possible to protect user data. Kali Linux (Version 2019.3; Offensive Security, 2019), penetration testing distribution was the ‘hacking method’ used to discover system vulnerabilities that could be exploited by threats to harm the data at rest or in transport. At the time of testing, only low to medium risk vulnerabilities were discovered and patched (e.g., not all cookies were encrypted).

Researching A Secure Environment

The guidelines provided by NIST Special Publication (SP) 800-series are suggestions for creating and implementing a secure environment to support U.S. Federal Government data and information systems. In some cases, it is not a suggestion but a requirement when hosting federal information (e.g., NIST SP 800-53) contingent on state or federal statutory laws.

Implementing the guidelines provided by NIST SP 800-66 was a voluntary act to create a safe environment that meets Federal Government requirements for hosting Health Insurance Probability and Accountability Act (HIPAA) related information. A combination of other resources and tools were also implemented to provide strong encryption because some cipher suites (algorithms used to encrypt and protect information in transit) approved by NIST but are considered weak according to Qualys SSL Labs (e.g., TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) or lack important features (e.g., TLS_RSA_WITH_AES_256_GCM_SHA384 lacks forward secrecy) to safeguard the data while in transit. Although an up to date system that employs Cipher Block Chaining (CBC) cipher suites meets NIST standards, two vulnerabilities (i.e., padding, lucky thirteen) associated with CBC were discovered.

The collective guidelines are used to create and apply a Risk Management Framework (RMF) to MRT systems. Implementation of the RMF model helps manage security and privacy risk to satisfy the requirements in the Federal Information Security Modernization Act of 2014 (FISMA). A list of NIST special publications that were used as a guide to build a secure environment are as follows:.

• Authorization of systems developed:
  • NIST SP 800-37. Creating an application requires extensive testing, including a track record with the final approval of when the application can be released to the public. The guidelines provided in this publication were used to identify roles, strategies, and procedures to develop and deploy authorized applications. Close adherence to these guidelines helps prevent a potential data breach.
• Selecting, assessing, and implementing security safeguards:
  • NIST SP 800 – 53 and 171. Maintaining high security standards is an active process that requires staying informed. The guidelines provided in these publications were used to evaluate and assess security control methodologies to protect system information from harm (i.e., compromise, corruption, or denial of service). For example, when evaluating our security policy, disabling TLS 1.0 disabled specific protection features. By evaluating and assessing the problems caused by TLS 1.0, an appropriate solution to keep TLS 1.0 disabled was found while restoring the disabled features. Disabling TLS < 1.2 was an important decision to maintain high security for data during transmission. Moreover, both guidelines NIST overlap in key areas such as limiting unsuccessful login attempts and securing login procedures.
  • NIST SP 800-44 and 123. Protecting the server where data is hosted is a crucial step to creating a secure environment. Encryption alone is not enough to deliver a system that closely follows NIST guidelines and satisfies legal statutory requirements (e.g., HIPAA). The guidelines provided in these publications are complementary to SP 800-53. They thoroughly list the appropriate actions an organization should take to safeguard data. For example, being pro-active to apply security patches, update the system, secure the system and proactive with identifying emerging vulnerabilities is crucial to safeguarding the server. Moreover, configuring the server with strong settings decreases the probability of a data breach.
  • NIST SP 800-56A, 56B, 56C, 57B, 131A, 175A, and 175B. Cryptography is a science that is empirical, objective, self-correcting, tentative, and parsimonious with the goal of keeping information confidential, verifying its authenticity, and ensuring its integrity (Ristić, 2015). The guidelines provided in these publications are also complementary to the guidelines provided in SP 800-53. As a collective, the documents focus on how to protect system information and user data using approved cryptography methods. For example, to protect data in transit, Elliptic Curve Cryptography (ECC), and hash functions (e.g., SHA384) should be used while aging Data Encryption Standard (DES) and Triple Data Encryption Algorithm (TDEA) should not be used. Both DES and TDEA at one point were considered secure, but over time the algorithms have been successfully breached. DES was removed from the approved list in 2005 and TDEA was removed in 2017. The self-correcting nature of science and being up to date with cryptography helps keep your data secure.
• Continuous Monitoring:
  • NIST SP 800-137. Selecting, assessing, and implementing security safeguards also requires a continuous monitoring strategy to reduce the probability of a data breach. The guidelines in this publication highlight the importance of policies and procedures to maintaining a secure environment.
• HIPAA Compliance:
  • NIST SP 800-66. Building a secure environment to be HIPAA compliant is not a simple task. To be both HIPAA secure and compliant requires an understanding of electronic personal health information (EPHI) and careful planning for how it will be stored, accessed, and protected. When developing an application, a thorough evaluation is necessary to identify and implement appropriate security controls that are specific to the requirements, capabilities, and features of that application. For example, a PDF document may be simply protected with a password using Advanced Encryption Standard (AES)-256 encryption while a web-application may require being encapsulated with multiple layers of encryption (e.g., TLS_AES_256_GCM_SHA384). The guidelines provided in this publication contains information on security standards to protect EPHI and comply with HIPAA Security Rule. The guidelines consist of the following six categories:  
    • Security standards and general rules
    • Administrative safeguards
    • Technical safeguards
    • Physical safeguards
    • Organizational requirements
    • Policies, procedures, and documentation requirements  
  • The categories focus on required and addressable steps to take when it comes to protecting the confidentiality, integrity and availability of EPHI. Required components must be implemented, and addressable components must be evaluated to determine whether they are appropriate and reasonable to implement.

Applying Security and How Data is Protected

Secure Socket Layer (SSL) security certificate. When building the security system, the architect chose to implement strong settings to protect user data from multiple threats. Starting with ensuring all traffic was encrypted over Hypertext Transfer Protocol Secure (HTTPS). Next, SSL certificate was configured to use Rivest-Shamir-Aldleman (RSA) 4096 vs RSA 2048 because it is estimated that RSA 2048 might be vulnerable by the year 2030 (Barker 2016, Barker & Roginsky 2019). However, multiple sources suggest the use of RSA 2048 or an Elliptic Curve Cryptography (ECC) equivalent because its faster (e.g., Ristić, 2015) than RSA 4096. Athough ECC equivalents execute faster than RSA because their key sizes are much smaller, RSA keys are stronger because they are more resource intensive to break.

Moreover, Let’s Encrypt was selected as the SSL certificate of choice because it provides better encryption than commercial options that are available. Commercial certificates such as extended validation (EV) or organization validation (OV) do not offer any increased benefits in security over a free domain validation (DV) certificate from Let’s Encrypt (Hunt, 2019). While commercial certificate authorities (CA) claim to offer warranties that they will not issue to fraudulent sites, no trusted sites would do so; therefore, there is no added benefit to paying for and implementing EV or OV offered by commercial CA.

Additionally, Let’s Encrypt offers desirable features that are unique, such as certificate short-life span, automatic renewals, and Online Certificate Status Protocol (OCSP) Must-Staple. The benefit to certificate short-life span and automatic renewals are that it reduces the probability of a key compromise and SSL certificates are renewed automatically. OCSP Must-Staple is a feature that has the server check the certificate in question for authenticity. Traditional methods would have the user’s browser query the server and the issuing CA for a Certificate Relocation List (CRL), thus reducing a user’s privacy and delaying authentication.

Protocols and Cipher Suites. A strong SSL certificate alone is meaningless if weak or insecure cipher suites are used or arranged in the wrong sequence (e.g, weak → strong, or strong → weak → strong). The reason cipher suites (e.g., TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) are important is because both the server and the client computer have to negotiate on how information is going to be secured. A weak cipher suite using Message Digest 5 (MD5; i.e., TLS_RSA_WITH_RC4_128_MD5) or Rivest Cipher 4 (RC4; i.e., TLS_RSA_WITH_RC4_128_SHA) is extremely vulnerable. In other words, it violates HIPAA because it fails to properly secure data in transit due to implementing a vulnerability that could be exploited and results in a security breach. MRT only uses cipher suites classified as strong with perfect forward secrecy (PFS).

PFS increase the security of the connection by not depending on the server’s private key to decrypt all information exchanged (Ristić, 2013). For example, when using a non-PFS cipher suite, if the server’s private key is compromised, an attacker (e.g., man in the middle) would be able to decrypt, view, and record all information exchanged between the server and the client during the session. However, with PFS even if the hacker managed to obtain one of the session keys, only one packet of information would be compromised instead of all the packets during the exchange, because new keys are generated for each packet in the communication session.

Moreover, MRT server only enables TLS 1.3 and TLS 1.2 to increase security. Table 1 list the cipher suites which support PFS, are considered strong, and are approved by NIST guidelines.

Table 1: List of security cipher suites

Suites in server-preferred order
TLS 1.3	TLS 1.2
AES_256_GCM_SHA384	ECDHE_RSA_WITH_AES_256_GCM_SHA384
CHACHA20_POLY1305_SHA256	ECDHE_RSA_WITH_AES_128_GCM_SHA256
AES_128_GCM_SHA256	DHE_RSA_WITH_AES_256_GCM_SHA384
	DHE_RSA_WITH_AES_128_GCM_SHA256
	ECDHE_RSA_WITH_ARIA_256_GCM_SHA384
	DHE_RSA_WITH_ARIA_256_GCM_SHA384
	ECDHE_RSA_WITH_ARIA_128_GCM_SHA256
	DHE_RSA_WITH_ARIA_128_GCM_SHA256

Security Grades According to Third Party Scans

The security grades provided by third parties in table 1 are based on non-intrusive query-response scans. Non-intrusive responses are voluntarily returned by the server when it is queried. For example, SSL certificates, cipher suites, and cookies can be confirmed by visiting a web page requesting capabilities without actively hacking the web-page. The non-hostile scanner queries “Hello server, do you support X features and what are your settings” and the server responds with a message saying, “I support X features with Y settings.”

A web-base application that obtains an A+ rating and implements all features recommended by each a third-party query-response scanning product does not guarantee that the web page is secure. However, obtaining grades ≤ B or encountering insecure warnings across third-party scanners, can be indications that the web-application is not adequately secure.

Reports from intrusive scans run by friendly penetration teams to discover previously unidentified or unreported vulnerabilities help developers implement additional security features. Table 2 provides a list of grades received from third parties with comments on the grades received.

Table 2: Third party scans from September 2019.

Organization	Grade	Comments
Mozilla’s Observatory	B+	Service Description. Checks security headers and other important settings such as securing cookies to prevent cross-site scripting attacks.   Comments: The MRT architects have found Mozilla’s Observatory grading criteria the hardest to achieve an A+ because of how things are scored.   MRT received a rating of 80/100 but it does not add the additional 15 points for implementing other important security features, as required when the score is less is less than 90.   The content security policy criteria when implemented as suggested made the web-page unusable and disabled other security features implemented.   After a thorough evaluation, with all security features implemented that are not mentioned, a B+ grade was considered safe.
securityheaders.com	A	Second opinion on security headers similar to Mozzila Observatory.
Qualys SSL Labs	A+	Grades encryption methodologies and settings to protect data in transit. Classifies cipher suites according to strength (e.g., strong, weak or insecure).   Comments: MRT architects only use strong cipher suites to decrease the probability of a man in the middle gaining easy access to sensitive information.
Hi-Tech Bridge	A+	Grades for encryption methodologies and compliance with PCI-DSS, HIPAA, and NIST. Compared to Qualys SSL Labs, Hi-Tech Bridge does not grade the strength of cipher suites used to secure data in transit.   Comments: MRT is compliant with all three policies.
tls.imirhil.fr	A+	Grades Implementation of TLS/SSL
hstspreload.org	PRELOAD	Checks whether web application is applicable or in a list to instruct browser that the web-page must load over a secure connection (e.g., HTTPS).   Comments: MRT web-page is located in a directory that most major browsers (e.g., Chrome, Firefox) use to instruct the browser to connect to the web page only over HTTPS. This further reduces the probability of an insecure connection if using an up to date browser.
TLS Observatory	INTER MEDIATE	An intermediate score reflects that the web page is compatible with a range of modern to old software.

It is important that web-based applications stay up to date with recommended security settings in order to maintain a secure infrastructure capable of protecting sensitive information (e.g., HIPAA).

The information provided on the MRT web-page was to inform users of the documents and technologies used to build a secure infrastructure without revealing any details that could compromise the system’s security (e.g. admin logins/passwords).

MRT architects are research driven. Building the MRT system architecture required a heavy investment in research and development of system security. It is easy for organizations to tell customers that there web-page is secure and HIPAA compliant without reporting what makes it secure, or verifying that the web-developers have a thorough understanding of security. After considerable research, the MRT team, strongly believes that the SSL security certificates are misleading at best. The grades provided by third party scanning products are probably a better indicator of system security than SSL certificates.

Reference

Barker. E., (2016). Recommendation for key management (NIST Special Publication 800-57B Rev. 4). National Institute of Standards and Technology. Retrieved from: http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4

Barker. E., (2019). Guideline for using cryptographic standards in the federal government: Crytographic mechanism (NIST Special Publication 800-175B Rev. 1). National Institute of Standards and Technology. Retrieved from: https://doi.org/10.6028/NIST.SP.800-175Br1-draft

Barker, E., & Barker, W. C. (2016). Guideline for using cryptographic standards in the federal government: Directives, mandates and policies (NIST Special Publication 800-175A). National Institute of Standards and Technology. Retrieved from: http://dx.doi.org/10.6028/NIST.SP.800-175A

Barker, E., Chen, L., & Davis, R. (2018). Recommendation for key-derivation methods in key-establishment schemes (NIST Special Publication 800-56C Rev. 1). National Institute of Standards and Technology. Retrieved from: https://doi.org/10.6028/NIST.SP.800-56Cr1

Barker, E., Chen, L., Roginsky, A., & Vassilev, A. (2018). Recommendation for pair-wise key-establishment schemes using discrete logarithm cryptography (NIST Special Publication 800-56A Rev. 3). National Institute of Standards and Technology. Retrieved from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Barker, E., Chen, L., Roginsky, A., Vassilev, A., Davis., R & Simon, S. (2018). Recommendation for pair-wise key establishment using integer factorization cryptography (NIST Special Publication 800-56B Rev. 2). National Institute of Standards and Technology. Retrieved from: https://doi.org/10.6028/NIST.SP.800-56Br2

Barker, E., & Roginsky, A. (2019). Transitioning the use of cryptographic algorithms and key lengths (NIST Special Publication 800-131A Rev. 2). National Institute of Standards and Technology. Retrieved from: https://doi.org/10.6028/NIST.SP.800-131Ar2

Content Security Policy Level 3. (2018, October 15). Retrieved September 1, 2019, from https://www.w3.org/TR/CSP3/

Dempsey, K., Chawla, N. S., Johnson, A., Johnston, R., Jones, A. C., Orebaugh A., . . . Stine., K. (2011). Information security continuous monitoring for federal information systems and organizations (NIST Special Publication 800-137). National Institute of Standards and Technology. Retrieved from: https://doi.org/10.6028/NIST.SP.800-137

Helme, S. (n.d.). Security Headers. Retrieved September 1, 2019, from https://securityheaders.com/

hstspreload.org. (n.d.). Retrieved September 1, 2019, from https://hstspreload.org/

Hunt, T. (2019). On the (percieved) value of ev certs, commercial CAs, phishing and Let’s Encrypt [Blog post]. Retrieved from: https://www.troyhunt.com/on-the-perceived-value-ev-certs-cas-phishing-lets-encrypt

National Institute of Standards and Technology (2013). Security and privacy controls for federal information systems and organizations (NIST Special Publication 800-53 Rev. 4). Retrieved from: https://doi.org/10.6028/NIST.SP.800-53r4

National Institute of Standards and Technology (2018). NIST special publication 800-series general information. Retrieved from: https://www.nist.gov/itl/nist-special-publication-800-series-general-information.

National Institute of Standards and Technology (2018). Risk management framework for information systems and organizations: A system life cycle approach for security and privacy (NIST Special Publication 800-37 Rev. 2). Retrieved from: https://doi.org/10.6028/NIST.SP.800-37r2

Ristić, I. (2013). OpenSSL cookbook. London, United Kingdom: Feisty Duck Limited.

Ristić, I. (2015). Bullentproof SSL and TLS. London, United Kingdom: Feisty Duck Limited.

Ristić, I. (2017). SSL and TLS deployment best practices. Retrieved from: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices

Ross, R., Pilliteri, V., Dempsey, K., Riddle, M., & Guissanie, G., (2019). Protecting controlled unclassified information in nonfederal systems and organizations (NIST Special Publication 800-171 Rev 1). National Institute of Standards and Technology. Retrieved from: https://doi.org/10.6028/NIST.SP.800-171r1

Scarfone, K., Jansen, W., & Tracy, M. (2008). Guide to general server security. (NIST Special Publication 800-123). National Institute of Standards and Technology. Retrieved from: https://doi.org/10.6028/NIST.SP.800-123

Scholl, M., Stine, K., Hash. J., Bowen. P., Johnson. A., Smith, C. D., & Steinberg, D. I. (2008). An introductory resource guide for implementing the health insurance portability and accountability act security rule (NIST Special Publication 800-66 Rev 1). National Institute of Standards and Technology. Retrieved from: https://doi.org/10.6028/NIST.SP.800-66r1

Security/Server Side TLS. (n.d.). Retrieved September 1, 2019, from https://wiki.mozilla.org/Security/Server_Side_TLS.

SSL Server Test. (n.d.). Retrieved September 1, 2019, from https://www.ssllabs.com/ssltest/.

Tracy, M., Jansen, W., Scarfone, K., & Winograd, T. (2007). Guidelines on securing public web servers (NIST Special Publication 800-44 Ver. 2). National Institute of Standards and Technology. Retrieved from: https://doi.org/10.6028/NIST.SP.800-44ver2

Web and Mobile Security Testing, Application Penetration Testing, Security Ratings. (n.d.). Retrieved from https://www.immuniweb.com/.

Web Security. (n.d.). Retrieved September 1, 2019, from https://infosec.mozilla.org/guidelines/web_security.html.