Need-to-know processes and procedures

[j_M007]

Good day colleagues.

I have been wondering about actual processes and procedures to determine whether someone has a need to know or to access specific documents that I am migrating to a new internal web site.

The documents themselves are classified TLP-Amber for the most part; however, I want to be able to control who can read-write, consult, etc.

Office 365 SaaS - Microsoft Teams; therefore no RBAC , no ACLs just administrator say-so..

So:

• Do any formalized decision trees or procedures exist?
• My suspicion is that some documentation supporting AC-21 from NIST SP 800  53r4 might work.

AC-21 INFORMATION SHARING Control: The organization:

a. Facilitates information sharing by enabling authorized users to determine whether access authorizations assigned to the sharing partner match the access restrictions on the information for [Assignment: organization-defined information sharing circumstances where user discretion is required]; and

b. Employs [Assignment: organization-defined automated mechanisms or manual processes] to assist users in making information sharing/collaboration decisions

[CraginS]

---

@j_M007 wrote:

...

I want to be able to control who can read-write, consult, etc. 

Office 365 SaaS - Microsoft Teams; therefore no RBAC , no ACLs just administrator say-so...

So:

• Do any formalized decision trees or procedures exist?
• My suspicion is that some documentation supporting AC-21 from NIST SP 800  53r4 might work

---

James,

You are probably going to have to write your own procedures, based on the details of your own enterprise. The nature of the information relative to job responsibilities will drive your basic rules on who can read existing documents and who can change or delete them, and who can add new ones. Most of the procedures will be manual, with only minimal automated implementation. 

A few items to consider:

1. Everyone granted any level of access to the sensitive documents should complete a short basic training on the what and why of protecting sensitive information as well as a crib sheet on Traffic Light Protocol. 

2. Each person granted any access level must sign an acknowledgement of the training and acceptance of the responsibilities.

3. The system administrator who controls the actual system level permissions must not also be the approval authority for access.

4. The basic rules for access should be simple. clear, and available for all to read.

5. You need a small pool of appointed approvers who can review requests for access and send approvals to the SysAdmin.

6. Set up a formal process of request by the individual or a supervisor, approval by one of the appointed approvers, and confirmed implementation by the sysadmin, with records of each action preserved. (If your enterprise has a solid workflow system, you can use that system.)

7. Make every approval time-limited, not open ended, so the accesses are checked for currency or departed employees on a regular basis.

8. Audit the process annually, comparing the access records in the system to the records of approvals and dates. This audit is a check for rogue approvals by the sysadmin as well as to cull the list of those no longer needing access.

As you noted, written procedures and records of the above will easily pass a compliance check for AC-21.

[j_M007]

Thank so much for your comprehensive, cogent and informed response Cragin! Leaving aside the SaaS security issues, over which I have no control, I forwarded the matter o the Governance committee for their input. I will formally request a framework within which to operate, taking into consideration your generous advice.

Thank you for your generosity.

Best!