This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
wiki:policies:dualauth [2021/11/24 17:04] katcow |
wiki:policies:dualauth [2023/10/06 21:53] (current) katcow |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Multi-Factor Authentication ====== | ====== Multi-Factor Authentication ====== | ||
- | |||
===== I. Purpose ===== | ===== I. Purpose ===== | ||
- | This policy outlines our plan for authenticating | + | |
+ | This policy outlines our planning related to the implementation of advanced authentication of users who connect to Nested Knowledge | ||
===== II. Scope ===== | ===== II. Scope ===== | ||
- | **Who is affected: ** This policy affects all employees of this Nested Knowledge and its subsidiaries, | ||
- | |||
- | **Affected Systems: ** Server or VPN. | ||
+ | **Who is affected: ** This policy affects all employees, contractors, | ||
===== III. Policy ===== | ===== III. Policy ===== | ||
- | ===Multi-Factor Authentication for Remote Access:=== | ||
- | Nested Knowledge has no internal network for employees, therefore multi-factor application for remote access is not applicable. Should Nested Knowledge establish a network, access to the network through remote access will be managed by a Virtual Private Network (VPN). The VPN will request for username and password or some other form of advanced authentication. Remote access must conform at least minimally to all statutory requirements including but not limited to HCFA, HRS-323C, and HIPAA. | ||
- | Should Nested Knowledge establish a network, access to the network through remote access will be managed by a Virtual Private Network (VPN). The VPN will request for username and password, and it may require dual-factor authentication. | + | Nested Knowledge will require multi-factor authentication (MFA) on all internal systems by default. Nested Knowledge will make exceptions on an ad-hoc basis. We will evaluate the risk and sensitivity or personal and organizational data, such as personal employee data, user data, intellectual property, and financial information, |
+ | |||
+ | ==== Communication ==== | ||
+ | |||
+ | When a change in the scope or the nature of information handled by Nested Knowledge occurs, our technical and operational leads will alert the CTO that multi-factor authentication may be warranted. If client information is handled, a representative from the client organization will be included in discussions on MFA. After discussion and evaluation of security risks, the CTO will decide whether or not to implement multi-factor authentication. | ||
+ | |||
+ | === Multi-Factor Authentication for Remote Access === | ||
+ | |||
+ | Nested Knowledge has no internal network for employees, therefore multi-factor authentication for remote access is not applicable. | ||
+ | |||
+ | === Multi-Factor Authentication for Financial Information === | ||
+ | |||
+ | At present, Nested Knowledge stores financial information via a cloud-based accounting software. Our security measures for protecting such data are determined by the software. At present, it requires MFA of all users. The accounting application is a VeriSign SecuredTM product, which is the leading secure sockets layer (SSL) Certificate Authority. It uses firewall protected servers and the encryption technology (128 bit SSL). | ||
+ | |||
+ | === Authentication with Client Data === | ||
+ | |||
+ | In cases where a client grants Nested Knowledge access to data with the explicit requirement of multi-factor | ||
+ | |||
+ | === Cloud Based Applications === | ||
+ | |||
+ | Our most sensitive systems, such as our cloud resources on AWS do require MFA–we use virtual MFA device authentication (specifically, | ||
+ | |||
+ | ===== Revision History ===== | ||
+ | |||
+ | ^Author^Date of Revision/ | ||
+ | |K. Cowie|10/ | ||
+ | |K. Cowie|11/ | ||
+ | |K. Holub|11/ | ||
+ | |K. Kallmes|11/ | ||
+ | |||
+ | [[: | ||
- | The Nested Knowledge application is run in a VPC (for details, see Network Security Policy). This network is only accessible by release engineers who are granted SSH keys. These keys may be revoked or refreshed at any time, as necessitated by personnel changes or incidents.The VPC is only accessible through a single bastion host. | ||