In: Computer Science
The RIIOT data-gathering method for technical controls can be as rigorous or exhaustive as needed by the organization. If an organization was wanting to assess all technical controls on every network and system in the organization, then the scope of that assessment would be huge and possibly cost-prohibitive.
The RIIOT method (Review, Interview, Identify, Observe and Test) comprises five different approaches to data gathering and can be applied to the administrative, physical and technical areas when performing the Risk Assessment.
1. Review Documents - The risk assessment team reviews documents regarding the rules, configurations, layouts, architectures, and other elements of security controls all available and relevant documents may be reviewed and can include policies, procedures, network diagrams, architectural stacks, backup schedules, site physical layouts and security awareness training packages and slides.
The problem I have here is that I do not know where to find the documents. I do not know if what the review process has been; who owns them; how many changes or iterations there have been or if they are lacking. I do not even know the approval process or how the documents are governed. In addition, if the documents are sensitive, I need to have security on these documents for add, change, delete, viewing, if they can or cannot be sent out of the most any company network, or if someone tries to send them out, I can prevent this from happening and track this.
2. Interview Key Personnel. The risk assessment team interviews key personnel to determine their ability to perform their duties (as stated in policies), their implementation of duties not stated in policies, and observations or concerns they have with current security controls.
The documentation should define key personnel and the process flow (governance) for the policy review process. I need to map the conversations with key personnel to the documents reviewed to ensure awareness of the documents and track what was said in the interviews. Roles and responsibilities need to be clearly defined here as well as their understanding of the controls as per the documentation as well as any other controls not documented.
3. Identify the Impact of Security Controls - The security risk assessment team members inspect specific implemented security controls such as visitor control, configuration files, smoke detectors, and incident response handling. These controls can be inspected against industry standards, specific checklists of common vulnerabilities, or by using experience and judgments.
The documentation has been great in providing information but I have found that much of the documentation is incomplete and since some of Legal SaaS is new, it has not as yet been created. In addition, there have been many changes to the technology over the past year that has not been identified. I need to define my ‘Enclave Boundaries’ so I know exactly what it is I am assessing and to get a handle on the interfaces and interactions of all the different hardware and software stacks involved in the system.
This will help identify all technical controls and direct me towards process and procedural controls as well as policies. How do I go about discovering what I have out there that is the system? Can I tell where data starts at its inception and when/if it leaves our boundaries and lightens the risk load by transferring some of the risk to a third party?
I should also ensure that the data is stored on the proper devices based upon its sensitivity, properly replicated and virtualized so I have redundancy and resiliency. The data when backed up to tape must be encrypted as well based upon the classification. I sure do not want this data to get out and old versions need to be properly destroyed. I will take a look at what we have for that as well. I want to make sure that any hardware is properly wiped before destruction. That brings me to another potential problem. What if we are placed under a legal hold and eDiscovery rules?
I need to address this with the business as well taking a look at how I store and maintain records. I will also assign a higher priority to any incidents related to these assets and this system so it is addressed accordingly. One more thing. I have not even looked at access management solutions as yet. Should I use two-factor for this? Maybe for external or remote access into the system. Looks like the business wants that as well.
4. Observe Personnel Behavior - The risk assessment team members will observe the behavior of users, the security protective force, visitors, and others during the course of the assessment. These observations can provide keen insight into the effectiveness of the security controls in place.
Observing behavior can be fun but this is serious stuff. Now that I have the documents reviewed and key personnel interviewed, I need to see if they actually follow the policies and procedures in place. Surveillance using CCTV and other tools are not really appropriate for this but I could use DLP and SIEM solutions to watch data flows and check configurations to ensure proper standard are in place. That is a method of observation. Otherwise, I will need to sit in with them as they go through their daily operational activities. I am not sure what other solutions we may have that could help here. I will need to talk to someone in product management. I really wish I had more than just the list of all the products we have. What would be useful is a catalog of controls along the lines of primary, compensating, preventive, detective, software, hardware as well as process and procedure. This would certainly help in my being able to compare this to what is in place and based upon the value of the system to the business as well as the sensitivity of the info, apply the controls necessary (remembering our slogan about the sledgehammer – I don’t want to cost the business more than is necessary). Being able to select from an ala carte menu of controls like say, two from column A and one from both B and C may be of great help!
5. Test Security Controls - The risk assessment team members will test specific security controls such as firewalls, servers, open door alarms and motion sensors. Almost all security risk assessment methods currently account for this approach. Testing involves the use of vulnerability scanners for logical controls, application scanners, and also specific methods for physical controls such as the shuffle test for motion sensors.
Testing controls is the validation I need now that I have the controls cataloged, the enclave boundaries defined, and the documentation together. I will use some third party tools to test the code, test the infrastructure and then analyze the results. I will rerun the discovery and configuration tools to validate that nothing has changed (hopefully). I think there needs to be some training of IT staff as well as the new tools brought in are not well known here. I will store the test results in a central location and communicate out on the overall status in my final risk assessment document. I will need to pretty much re-access all the pieces (technologies) I have in place and validate that all controls are working as billed! I sure wish someone out there had these solutions under one umbrella. I really don’t like having 35 different vendors to deal with; the operational cost model is too high; my staff are jacks of all trades and masters of none; I look at multiple different consoles and have to support multiple different backend databases and agents; this really is costing me too much and vendor management is not happy with the number of vendors since it impacts them as well. Sure hope the business does not hit me on this.
Now that I have all this completed, I will compare the data against the regulations and associated statutes to ensure I do not have any risks that are unacceptable. If I do, I need to communicate this and write a risk letter that follows our governance model.
Here I am taking an example of Classroom / School & Peers:
Classroom / School:
Peers: